From nobody Fri Oct 2 06:33:59 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24FE1ACF56 for ; Fri, 2 Oct 2015 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfiBsGfqpqer for ; Fri, 2 Oct 2015 06:33:56 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 5D1C01ACDFB for ; Fri, 2 Oct 2015 06:33:56 -0700 (PDT) Received: by lbbmp1 with SMTP id mp1so26575428lbb.1 for ; Fri, 02 Oct 2015 06:33:54 -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:content-type; bh=ESR5j5U0Wu8vKZExezdCVpFDtrqta8Q2E9e+/0nw5sM=; b=ZLtk054MzxmdygnU7hmx3uEqH+ctr/IWYrTf6JXVi+aTTpaC5lPpV9NL2rYvpa76L2 U/7VHoo0YL2r8Gj8RnJ1xNZtEFpVyawQ3ZtHVT9iTm8f1afj1T0O3DBeIcUEiPHK4Z73 h10TXeLe6AlOpDfzy1scJHwS5m04fmz9YO+Cyl9yzuQRN4WzvOUGmOEWi/zAnTji+JOI JwDzS9nCADP+Olzby899M9qYNOzw5aomW6QcngEAiR6ZfUicjUJsz+AhNnbmbgb1Bd+t iDI0+8/JGP2LPFr4j55GKuDDFPkckpNm0Oj1Um69f1ygAa1Kbvt2d3ddZchCVh7hhvS0 s/Yg== MIME-Version: 1.0 X-Received: by 10.25.22.77 with SMTP id m74mr3731735lfi.10.1443792834441; Fri, 02 Oct 2015 06:33:54 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Fri, 2 Oct 2015 06:33:54 -0700 (PDT) Date: Fri, 2 Oct 2015 09:33:54 -0400 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=001a114070b206b80d05211f3785 Archived-At: Subject: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 13:33:58 -0000 --001a114070b206b80d05211f3785 Content-Type: text/plain; charset=UTF-8 Hello WG participants, The above referenced draft seems to have addressed all of the outstanding WG comments to date. Therefore, it's time for a Working Group Last Call (WGLC) on this document. The WGLC period will close on October 16. Please read and review the document, and provide comments, prior to that time if possible. Regards, Stan --001a114070b206b80d05211f3785 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello WG participants,=C2=A0

The above = referenced draft seems to have addressed all of the outstanding WG comments= to date. Therefore, it's time for a Working Group Last Call (WGLC) on = this document. The WGLC period will close on October 16. Please read and re= view the document, and provide comments, prior to that time if possible.=C2= =A0

Regards,
Stan
--001a114070b206b80d05211f3785-- From nobody Sun Oct 4 20:38:10 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCA51B4277 for ; Sun, 4 Oct 2015 20:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 MupHKy2SE5Rl for ; Sun, 4 Oct 2015 20:38:07 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id CFD0E1B427B for ; Sun, 4 Oct 2015 20:38:06 -0700 (PDT) Received: (qmail 31601 invoked by uid 0); 5 Oct 2015 03:38:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 5 Oct 2015 03:38:00 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw4 with id RFHx1r00Q2Yhrsa01FJ0mj; Sun, 04 Oct 2015 21:18:00 -0600 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=KWLd9SN1AAAA:8 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=5lJygRwiOn0A:10 a=N1z6yVdWAAAA:8 a=2nFGiysaSxI39FQ3E40A:9 a=Rh7rr6szFAc_Sdjn:21 a=lEO8T01ZNlk0eX9g:21 a=QEXdDO2ut3YA:10 a=l9YQt7dNOTcA:10 a=LuuTxNwEefwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Z1pC1sGu7I6a0sG6rayfEWC/5hFN7hV40U34RoUF1lk=; b=GNIOiCJWgmFril6i9Gx+PcSE2yHU3AWcbLaZ31fUrO+kGGSMqsQYO/KrXt/p0YmeATErWeXmhW1jetdlLOl1jnLVNCBfEgWq6Moql4RYksD3fHGE+yGDvsDmmCPQSNCI; Received: from localhost ([127.0.0.1]:41453 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZiwHl-0005WR-QJ for manet@ietf.org; Sun, 04 Oct 2015 21:17:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 04 Oct 2015 21:17:55 -0600 From: Jackie Blanco To: manet@ietf.org Message-ID: <6f36f12796de0f9c7827395919c84152@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.5 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: Subject: [manet] Approaching Deadline: ICGCTI2015 - Malaysia X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 03:38:08 -0000 The Third International Conference on Green Computing, Technology and Innovation (ICGCTI2015) Universiti Putra Malaysia, Selangor, Malaysia 8-10 December 2015 http://sdiwc.net/conferences/icgcti2015/ The proposed conference on the above theme will held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICGCTI2015 aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: - Benefits of, and barriers to, adopting greener IT practices - Carbon metering and user feedback - Climate and ecosystem monitoring - Energy harvesting, storage, and recycling - Energy-aware high performance computing and applications - Energy-aware software - Energy-efficient network services and operations - Green IT metrics, maturity models, standards, and regulations - Green computing models, methodologies and paradigms - Green networking and communication - Life-cycle analysis of IT equipment - Management and profiling tools for energy efficient systems - Modeling-representations, simulation and validation for energy consumption optimization problems - Online dynamic optimization for energy efficient systems - Power-aware algorithms and protocols - Power-efficient delivery and cooling - Renewable energy models and prediction - Smart buildings and urban development - Smart homes, buildings, offices, streets - Stability of smart energy systems - Using IT to reduce carbon emissions - Carbon management policies and ecology- related issues with ICT - Characterization, metrics, and modeling - Creating green awareness using IT - Energy-aware computing - Energy-aware large scale distributed systems, such as Grids, Clouds and service computing - Energy-efficient mass data storage and processing - Governments’ roles in fostering and enforcing green initiatives - Green business process reengineering and management - Green design, manufacture, use, disposal, and recycling of computers and communication systems - Green software engineering - Low-power electronics and systems - Matching energy supply and demand - Network design optimization - Optimization of energy-efficient protocols - Power-aware software and hardware - Reliability, thermal behavior and control - Robustness and performance guarantees - Smart grid and microgrids - Smart transportation and manufacturing - Sustainable computing Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Deadline : November 8, 2015 Final Notification : November 20, 2015 Camera Ready Deadline : November 28, 2015 Registration Deadline : November 28, 2015 Conference Dates : December 8-10, 2015 Drop us an email at icgcti15@sdiwc.net From nobody Mon Oct 5 14:12:07 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF6E1A1EFC; Mon, 5 Oct 2015 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GadBCPE_PTTh; Mon, 5 Oct 2015 14:12:03 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3841A1EB7; Mon, 5 Oct 2015 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12890; q=dns/txt; s=iport; t=1444079523; x=1445289123; h=from:to:cc:subject:date:message-id:mime-version; bh=A+yNLZnt7i2pVzmUGXGiSySjfnG1lmB5K6WO87iPxMk=; b=a00ki8vI724LNdksJtUe1tOXHnC6I9PvowSi2fwv+uyrf9LY7Yp3L/vN Q1ACcUSKhcAtlmeqT/IdyN1EeRRrEPKiCtpGpglTpGDJQNYQBE4F+ay/M xrZor8vy751momPogfmPOpNtkf/ZSntg/Vy4F2eSyvA7/uK8GLtDHWCye o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzBQC75hJW/5FdJa1eglpNgUi+HIFahhqBOTkTAQEBAQEBAX8LhCcEZxISAYEAJwQOiDO+HwEBAQEBBQEBAQEBARyGcwGKCoQzBZJJgzMBjRaBVoQ4gyOJbIhGIwM9hAKIKoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,640,1437436800"; d="scan'208,217";a="194668639" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 05 Oct 2015 21:12:02 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t95LC2Te004864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2015 21:12:02 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 5 Oct 2015 16:12:01 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-rcd-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 5 Oct 2015 16:12:01 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Mon, 5 Oct 2015 16:12:01 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-manet-olsrv2-dat-metric@ietf.org" Thread-Topic: AD Review of draft-ietf-manet-olsrv2-dat-metric-06 Thread-Index: AQHQ/7J6yFlrc7+VEEqp4R7ewhD+oQ== Date: Mon, 5 Oct 2015 21:12:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.14] Content-Type: multipart/alternative; boundary="_000_D2385FDCD6883aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" , "manet-chairs@ietf.org" Subject: [manet] AD Review of draft-ietf-manet-olsrv2-dat-metric-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 21:12:06 -0000 --_000_D2385FDCD6883aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reading this draft. Thank you for the background and histo= ry. I identified some Major issues that should be easy to fix. But in general = I found the document relatively easy to read and understand. Once you addr= ess the comments (and post an update, as needed) for the Major items I will= start the IETF Last Call. Thanks! Alvaro. Major: 1. What are the parameters of this experiment? Being an Experimental do= cument, there should be some guidance as to what type of information wants = to be collected, what type of topologies should be used, etc..to eventually= declare the experiment a success. This information can be used later to c= hange the track and (for example) use it to move the DAT into the Standards= Track. 2. Section 9.2. (Requirements for using DAT metric in OLSRv2 implementat= ions) * What happens to packets that don't meet these requirements? I'm a= ssuming that they're just not used to calculate the DAT, is that true? Is = it ok if some packets on a link meet the requirements and others don't? * The INTERVAL_TIME TLV doesn't have to be in every HELLO (according= to rfc6130), and Section 9.4 accounts for that already. So it looks like = that is not really a requirement. 3. There is some rfc2119 language in Section 9.3. (Link Loss Data Gather= ing) that is not clear. * "For each incoming [RFC5444] packet, additional processing SHOULD = be carried out after the packet messages have been processed as specified i= n [RFC6130] and [RFC7181]." Which additional processing? Are you just ref= erring to what is specified later in this section? Please be specific. * "[RFC5444] packets without packet sequence number MUST NOT be proc= essed in this way by this metric." I'm guessing here you also are referrin= g to what's specified in the rest of the section, right? 4. Even though this document doesn't formally (because it is Experimenta= l) Update rfc5444, rfc6130 and rfc7181, it would be a good idea to include = a section (maybe around Section 5) that summarizes the changes/updates done= here. Minor: 1. In Section 2. (Terminology), "diff_seqno(new, old)" is defined. However, S= ection 9.3 uses "seq_diff" instead. * Section 3. (Applicability Statement): the references to OLSRv2 see= ms to not be correct. 2. Section 6. (Protocol Parameters) * This section starts by talking about "two constants", and then lis= ting "these constants", but the list actually has 4 parameters. Section 7 = also seems to talk about constants. Should these two sections be merged in= to one?? * s/DAT_MEMORY_LENGTH - Queue length=85within the queue are used to= calculate the cost of the link./DAT_MEMORY_LENGTH - Queue length=85within= the queue length are used to calculate the cost of the link. 3. In Section 6.1. (Recommended Values) the recommended value for DAT_RE= FRESH_INTERVAL is 1; the first paragraph says that "mobile networks might r= equire shorter DAT_REFRESH_INTERVAL". The only thing lower than 1 is 0; wo= uld that mean that in a mobile network the recommendation is to continuousl= y recalculate the metric? 4. References: * RFC3626, RFC7182 and RFC7183 can be Informative. 5. Do you want to reference the appendixes (B, C and D) somewhere in the= main text? Nits: 1. Introduction: s/OLSR networks gathered since the publication of OLSR/= OLSR networks gathered since its publication 2. The DLEP reference is out of date. 3. Section 4: * s/dijkstra/Dijkstra * "=85already gathered link loss data=85" A reference to Section 9 = would be nice. 4. Appendix A. * B.A.T.M.A.N. Reference? * "consists of 400 routers (around 600 routes)" 400 or 600? 5. Idnits identifies some line spacing issues, please take a look. --_000_D2385FDCD6883aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

I just finished reading this draft.  Thank you for the background and = history.

I identified some Major issues that should be easy to fix.  But in gen= eral I found the document relatively easy to read and understand.  Onc= e you address the comments (and post an update, as needed) for the Major it= ems I will start the IETF Last Call.

Thanks!

Alvaro.


Major:
  1. What are the parameters of this experiment?  Being an Experimental doc= ument, there should be some guidance as to what type of information wants t= o be collected, what type of topologies should be used, etc..to eventually = declare the experiment a success.  This information can be used later to change the track and (for example) use it= to move the DAT into the Standards Track.
  2. Section 9.2. (Requirements for using DAT metric in OLSRv2 implementati= ons)  
    • What happens to packets that don't meet these requirements?  I'm assum= ing that they're just not used to calculate the DAT, is that true?  Is= it ok if some packets on a link meet the requirements and others don't?
    • The INTERVAL_TIME TLV doesn't have to be in every HELLO (according to rfc61= 30), and Section 9.4 accounts for that already.  So it looks like that= is not really a requirement.
  3. There is some rfc2119 language in Section 9.3. (Link Loss Data Gatheri= ng) that is not clear.
    • "For each incoming [RFC5444] packet, additional processing SHOULD = be carried out after the pack= et messages have been processed as specified in [RFC6130] and [RFC7181]."  Which additional processing?  = ;Are you just referring to what is specified later in this section? &n= bsp;Please be specific.
    • &q= uot;[RFC5444] packets without pack= et sequence number MUST NOT be processed in this way by this metric."  I'm guessing here you a= lso are referring to what's specified in the rest of the section, right?  
      • <= /ul>
    • Even though this document doesn'= t formally (because it is Experimental) Update rfc5444, rfc6130 and rfc7181= , it would be a good idea to include a section (maybe around Section 5) tha= t summarizes the changes/updates done here.

Minor:
  1. In Section 2. (Terminology), "diff_seqno(new, old)" is defin= ed.  However, Section 9.3 uses "seq_diff" instead.
    1. Section 3. (Applicability Statement): the references to OLSRv2 seems to not= be correct.
  2. Section 6. (Protocol Parameters) 
    • This section starts by talking about = "two constants", and the= n listing "these constants", but the list actually has 4 paramete= rs.  Section 7 also seems to talk about constants.  Should these two sections be merged into one??
    • s/DAT_MEMORY_LENGTH=  - Queue length=85within the queue are used to calculate the cost of = the link./DAT_MEMORY_LENGTH  - Queue length=85within the queue length = are used to calculate the cost of the link.
  3. In Section 6.1. (Recommended Values) the recommended value fo= r DAT_REFRESH_INTERVAL is 1; the first paragraph says that "mobil= e networks might require shorter DAT_REFRESH_INTERVAL".  The only= thing lower than 1 is 0; would that mean that in a mobile network the recommendation is to continuously recalculate the metric?
  4. References:
    • RFC3626, RFC7182 and RFC7183&nbs= p;can be Informative.
  5. Do you want to reference the appendixes (B, C and D) somewhere in = the main text?

Nits:
  1. Introduction: s/OLSR networks gathered since the publication of OLSR/OLSR n= etworks gathered since its publication
  2. The DLEP reference is out of date.
  3. Section 4: 
    • s/dijkstra/Dijkstra
    • "=85already gathered link loss data=85"  A reference to Sect= ion 9 would be nice.
  4. Appendix A.
    • B.A.T.M.A.N. Reference?
    • "consists of 400 routers = ;(around 600 routes)"  400 or 600?
  5. Idnits identifies some line spac= ing issues, please take a look.
--_000_D2385FDCD6883aretanaciscocom_-- From nobody Tue Oct 6 12:14:25 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77A01B2A2C for ; Tue, 6 Oct 2015 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNy8Sx6WOQSK for ; Tue, 6 Oct 2015 12:14:18 -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 5F9E81B2A1A for ; Tue, 6 Oct 2015 12:14:18 -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 esmtp (envelope-from ) id <1ZjXgm-001Gpl-PO>; Tue, 06 Oct 2015 21:14:16 +0200 Received: from [95.144.178.182] (helo=frankenbook-pro.default) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (envelope-from ) id <1ZjXgl-000iPJ-TV>; Tue, 06 Oct 2015 21:14:16 +0200 From: Lotte Steenbrink Content-Type: multipart/alternative; boundary="Apple-Mail=_AB847D83-9518-4B0C-BCD9-5CDF91A9E680" Message-Id: <54EC4DED-0D11-4635-B1FB-1CD2DF9F08F8@fu-berlin.de> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 6 Oct 2015 20:15:43 +0200 References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> To: manet@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 95.144.178.182 X-ZEDAT-Hint: A Archived-At: Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 19:14:23 -0000 --Apple-Mail=_AB847D83-9518-4B0C-BCD9-5CDF91A9E680 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, I realize vacation season and/or other circumstances have slowed most of = us down at one point or another, but I was wondering if one of the = authors could give us a very brief update on how the work on this draft = is doing?=20 I'm particularly interested in an answer to my earlier question = concerning section 4.6., i.e.: if a message needs to be regenerated to = be forwarded, and this message contains TLVs that the regenerating 5444 = parser/builder doesn't recognize, should it add the unknown TLVs to the = message (which would mean that =93MUST NOT remove suchTLVs or values=94 = applies, which should imo be clarified in the draft) or should the = unknown TLVs be discarded (which would need clarification too, imo)? If the answer is =93we're working on it, hold on for a few more days=94, = that's completely fine, I'd just like to know if/when I can find out how = to do this correctly. :) Regards, Lotte Am 09.06.2015 um 16:26 schrieb Lotte Steenbrink = : > Hi Ulrich, Thomas, Chris and Henning, >=20 > Am 31.05.2015 um 13:33 schrieb Ulrich Herberg : >=20 >> As we announced previously, we have been working on a document = specifying rules for how to use RFC5444 in MANET protocols. Well, here = it is (at least in a -00 version).=20 >> We'd appreciate reviews and will soon ask for WG adoption. >=20 > first of all, thank you so much for publishing this much-needed draft. = I'm also in favor of WG adoption. While reading through the document, I = wrote down some nitpicks and suggestions that I'd like to share. > (Just in case my writing sounds harsh, I fear that's due to = language/cultural differences. I'm really happy about this document and = would like to see it flourish.) >=20 > =3D=3D General notes =3D=3D > - If I didn=92t misunderstand it, the document addresses two groups of = people: Those who want to design RFC5444 messages for their protocol, = and those wo want to implement a RCF 5444 builder/parser. Imo, The = former group needs more of an outside view (i.e. what can/should I put = where), while the latter needs the inside view (i.e. how do I arrange = and process everything efficiently). To my mind, these are two very = different goals, but while reading the document, it wasn=92t always = instantly clear to me which bit addresses which group=85 I realize the = two can=92t always be separated completely, but would it be possible to = make it more clear which group is addressed currently? Maybe the = document could be organized into two big sections (one for each group), = or there could be a recurring pattern of =93first outside then inside = view=94 for each (sub)section? >=20 > - A lot of the examples are very NHDP/OLSR-specific. While I think = it=92s great to have pointers to where a certain technique has already = been used, from an outsider=92s perspective, the examples don=92t always = help me understand the technique that=92s being illustrated, since I = have to familiarize myself with the details referenced first=85 I=92m = wondering if it would be possible to keep the examples which illustrate = a point more generic, and then briefly point to existing instances of = this situation in case the reader wants to follow up on that? >=20 > =3D=3D Section by section =3D=3D > Section 1.2., Page 4: > =93A packet is designed to as travel [=85]=94 I think the =93as=94 = doesn=92t belong here. >=20 > Section 4.2., Page 8: > =93Outgoing messages MAY be created by owning protocol=94 I think = there=92s a =93the=94 missing. >=20 > Section 4.3., Page 8: > If I understand it correctly, the last paragraph on this page is = talking about multi-value TLVs without actually saying =93multi-value = TLV=94. Maybe that could be stated explicitly for clarity and in case = somebody=92s searching for advice by this keyword? >=20 > Section 4.4., Page 9/10: > The last paragraph on page and the first two on page 10, more = specifically these parts: > =20 > Such an example already exists (but within the basic = specification, rather =20 > than as an extension) in the use of LOST values in the = LINK_STATUS =20 > and OTHER_NEIGHB TLVs to report that an address is of a = router known =20 > not to be a neighbor. A future example might be to list an = address =20 > to be added to a "blacklist" of addresses not to be used. > =20 > This example can be taken further. NHDP must also not = reject a HELLO =20 > message because it contains an unrecognized TLV. This also = applies > to unrecognized TLV values, where a TLV supports only a = limited set > of values. >=20 > were a bit hard to read for me. Imho, the example is very = specific and contains details which aren=92t necessary to understand the = issue at hand (such as the fact that this extension is technically not a = completely independent extension, or possible future other extensions). = It took me about 4 re-reads to really grasp what=92s going on there... >=20 > Also, I would=92ve expected the last paragraph of this section to = clearly state that relying on address order *will* break your messages = if you don=92t have control over all 5444 builders that are used to = implement your protocol ever. >=20 > Section 4.5.: > I'm assuming that this is the response to our (the AODVv2 Author = team and possibly others) complaints that RFC5444 lacks a clear "API" = which tells it what we can and cannot set manually in an RFC 5444 = packet, and that there's no (at the risk of sounding really pretentious = now) "visual language" to describe the contents of a 5444 message and = their relationship to each other. To be honest, I'm a bit puzzled by = this section.... The mapping that is presented is a bit vague and = introduced very promptly. And while I strongly agree with the statement = that writing down an actual API is too language- and = implementation-specific to belong in a document like this, it would be = really helpful to have a comprehensive "these are the things that your = protocol can set in a RFC5444 message. Your packet builder/parser will = figure out the rest." List in this section rather than some examples. > Along with this list, it would be great to have a clear specification = on how to specify which Addresses and TLVs a specific message has, and = how their relationship to each other are. (i.e. how to make clear which = address TLVs are associated with which addresses). I don=92t care if = this ends up being a very visual approach (like the debugging output of = Henning=92s oonf API [1]), or the tables that OLSRv2 uses, or something = completely different, but it would be helpful to be able to read and = write messages down in a way that is clear to everyone. >=20 > Section 4.6: > =93[=85] and MUST NOT remove such TLVs or values=94 > A question I=92ve been wanting to ask for a while now: Does this = rule also apply for message regeneration? AODVv2 regenerates all = messages per hop. Should implementations keep track which unknown TLVs = of a message are associated with which addresses, and put them back in = their place when regenerating the message? >=20 > Section 6.1.: > (I=92m not terribly familiar with compression, so my questions = are probably very naive, but maybe they can help clear things up) > Would this very straightforward to implement compression = algorithm still produce interoperable messages? The rest of the section = reads as if the =93compression algorithm=94 mentioned in the = introduction is mainly a way to cleverly arrange addresses so that they = are still understood by all parsers, but take up a minimal amount of = space. I think that=92s a very good tip in itself, but is that really = all there is to compression? Would it make sense to say =93Here=92s how = you should arrange addresses cleverly, you can also implement a more = elaborate compression algorithm, but that=92s out of the scope of this = document=94? > Also, any mention of the word =93straightforward=94 makes me very = suspicious, but that might just be me. >=20 > Section 6.1.: > =93RECOMMNDED=94 in the first paragraph is missing an E. >=20 > Regards, > Lotte >=20 >=20 > [1] Random one pulled out of my logfiles for illustration: >=20 > ,------------------ > | PACKET > |------------------ > | * Packet version: 0 > | * Packet flags: 0x0 > | ,------------------- > | | MESSAGE > | |------------------- > | | * Message type: 11 > | | * Message flags: 0x40 > | | * Address length: 16 > | | * Hop limit: 20 > | | ,------------------- > | | | Address: fe80::ff:fe00:1719 > | | | | - TLV > | | | | Flags =3D 0x50 > | | | | Type =3D 0 > | | | | Value length: 2 > | | | | 0000: 0100 > | | `------------------- > | | ,------------------- > | | | Address: fe80::ff:fe00:16fe > | | | | - TLV > | | | | Flags =3D 0x50 > | | | | Type =3D 1 > | | | | Value length: 2 > | | | | 0000: 0100 > | | | | - TLV > | | | | Flags =3D 0xd0 > | | | | Type =3D 3; Type ext. =3D 3 > | | | | Value length: 1 > | | | | 0000: 00 > | | `------------------- > | `------------------- > `------------------ >=20 >>=20 >> Best regards >> Ulrich=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: May 28, 2015 at 11:12:35 GMT+3 >>> To: "Christopher Dearlove" , "Henning = Rogge" , "Thomas Clausen" = , "Henning Rogge" = , "Ulrich Herberg" = , "Thomas H. Clausen" , = "Christopher Dearlove" , "Ulrich Herberg" = >>> Subject: New Version Notification for = draft-clausen-manet-rfc5444-usage-00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt >>> has been successfully submitted by Thomas Clausen and posted to the >>> IETF repository. >>>=20 >>> Name: draft-clausen-manet-rfc5444-usage >>> Revision: 00 >>> Title: Rules For Designing Protocols Using the RFC5444 = Generalized Packet/ Message Format >>> Document date: 2015-05-28 >>> Group: Individual Submission >>> Pages: 17 >>> URL: = https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.= txt >>> Status: = https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/ >>> Htmlized: = https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00 >>>=20 >>>=20 >>> Abstract: >>> This document updates the generalized MANET packet/message format, >>> specified in RFC5444, by providing prescriptive guidelines for how >>> protocols can use that packet/message format. In particular, = these >>> mandatory guidelines prohibit a number of uses of RFC5444 that = have >>> been suggested in various proposals, and which would have lead to >>> interoperability problems, to impediment of protocol extension >>> development, and to inability to use generic RFC5444 parsers. >>>=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 >> _______________________________________________ >> 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=_AB847D83-9518-4B0C-BCD9-5CDF91A9E680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all,
I realize vacation season and/or other circumstances have = slowed most of us down at one point or another, but I was wondering if = one of the authors could give us a very brief update on how the work on = this draft is doing? 

I'm particularly = interested in an answer to my earlier question concerning section 4.6., = i.e.: if a message needs to be regenerated to be forwarded, and this = message contains TLVs that the regenerating 5444 parser/builder doesn't = recognize, should it add the unknown TLVs to the message (which would = mean that =93MUST NOT remove = suchTLVs or values=94 applies, = which should imo be clarified in the draft) or should the unknown TLVs = be discarded (which would need clarification too, = imo)?

If the answer is =93we're working on it, = hold on for a few more days=94, that's completely fine, I'd just like to = know if/when I can find out how to do this correctly. = :)

Regards,
Lotte

Am 09.06.2015 um 16:26 schrieb Lotte Steenbrink <lotte.steenbrink@fu-berlin.d= e>:

Hi Ulrich, Thomas, Chris and = Henning,

Am 31.05.2015 um 13:33 schrieb Ulrich Herberg = <ulrich@herberg.name>:

As we announced previously, we have been working on a = document specifying rules for how to use RFC5444 in MANET protocols. = Well, here it is (at least in a -00 version). 
We'd = appreciate reviews and will soon ask for WG = adoption.

first of all, = thank you so much for publishing this much-needed draft. I'm also in = favor of WG adoption. While reading through the document, I wrote down = some nitpicks and suggestions that I'd like to share.
(Just = in case my writing sounds harsh, I fear that's due to language/cultural = differences. I'm really happy about this document and would like to see = it flourish.)

=3D=3D General notes = =3D=3D
- If I didn=92t misunderstand it, the = document addresses two groups of people: Those who want to = design RFC5444 messages for their protocol, and those wo want to = implement a RCF 5444 builder/parser. Imo, The former group needs = more of an outside view (i.e. what can/should I put where), while the = latter needs the inside view (i.e. how do I arrange and process = everything efficiently). To my mind, these are two very different goals, = but while reading the document, it wasn=92t always instantly = clear to me which bit addresses which group=85 I realize the = two can=92t always be separated completely, but would it be possible to = make it more clear which group is addressed currently? = Maybe the document could be organized into two big = sections (one for each group), or there could be a recurring pattern of = =93first outside then inside view=94 for each = (sub)section?

- A lot of the examples are very = NHDP/OLSR-specific. While I think it=92s great to have pointers to where = a certain technique has already been used, from an outsider=92s = perspective, the examples don=92t always help me understand the = technique that=92s being illustrated, since I have to familiarize = myself with the details referenced first=85 I=92m wondering if it would = be possible to keep the examples which illustrate a point more generic, = and then briefly point to existing instances of this situation in case = the reader wants to follow up on that?

=3D=3D = Section by section =3D=3D
Section 1.2., Page = 4:
     =93A packet is designed to as = travel [=85]=94 I think the =93as=94 doesn=92t belong = here.

Section 4.2., Page = 8:
     =93Outgoing messages MAY be created by = owning protocol=94 I think there=92s a =93the=94 = missing.

Section 4.3., Page = 8:
     If I understand it correctly, the last = paragraph on this page is talking about multi-value TLVs without = actually saying =93multi-value TLV=94. Maybe that could be stated = explicitly for clarity and in case somebody=92s searching for advice by = this keyword?

Section 4.4., Page = 9/10:
     The last paragraph on page and the = first two on page 10, more specifically these = parts:
     
     =      Such an example already exists (but within = the basic specification, rather  
     =      than as an extension) in the use of LOST = values in the LINK_STATUS  
     =      and OTHER_NEIGHB TLVs to report that an = address is of a router known  
     =      not to be a neighbor.  A future = example might be to list an address  
     =      to be added to a "blacklist" of addresses = not to be used.
     
          This example = can be taken further.  NHDP must also not reject a HELLO =  
  =         message because it contains = an unrecognized TLV. This also applies
     =      to unrecognized TLV values, where a TLV = supports only a limited set
          of = values.

     were a bit = hard to read for me. Imho, the example is very specific and = contains details which aren=92t necessary to understand the issue at = hand (such as the fact that this extension is technically not = a completely independent extension, or possible future other = extensions). It took me about 4 re-reads to really grasp what=92s going = on there...

     Also, I = would=92ve expected the last paragraph of this section to clearly = state that relying on address order *will* break your messages if you = don=92t have control over all 5444 builders that are used to = implement your protocol ever.

Section = 4.5.:
     I'm assuming that this is = the response to our (the AODVv2 Author team and possibly others) = complaints that RFC5444 lacks a clear "API" which tells it what we can = and cannot set manually in an RFC 5444 packet, and that there's no (at = the risk of sounding really pretentious now) "visual language" to = describe the contents of a 5444 message and their relationship to each = other. To be honest, I'm a bit puzzled by this section.... The mapping = that is presented is a bit vague and introduced very promptly. And while = I strongly agree with the statement that writing down an actual API is = too language- and implementation-specific to belong in a document like = this, it would be really helpful to have a comprehensive "these are the = things that your protocol can set in a RFC5444 message. Your packet = builder/parser will figure out the rest." List in this section rather = than some examples.
Along with this list, it would be great to = have a clear specification on how to specify which Addresses and TLVs a = specific message has, and how their relationship to each other are. = (i.e. how to make clear which address TLVs are associated with which = addresses). I don=92t care if this ends up being a very visual = approach (like the debugging output of Henning=92s oonf API [1]), or the = tables that OLSRv2 uses, or something completely different, but = it would be helpful to be able to read and write messages down in a = way that is clear to everyone.

Section = 4.6:
     =93[=85] and MUST NOT remove such = TLVs or values=94
     A question I=92ve been = wanting to ask for a while now: Does this rule also apply for message = regeneration? AODVv2 regenerates all messages per hop. Should = implementations keep track which unknown TLVs of a message are = associated with which addresses, and put them back in their place when = regenerating the message?

Section = 6.1.:
     (I=92m not terribly familiar with = compression, so my questions are probably very naive, but maybe they can = help clear things up)
     Would this very = straightforward to implement compression algorithm still produce = interoperable messages? The rest of the section reads as if the = =93compression algorithm=94 mentioned in the introduction is mainly a = way to cleverly arrange addresses so that they are still understood by = all parsers, but take up a minimal amount of space. I think that=92s a = very good tip in itself, but is that really all there is to compression? = Would it make sense to say =93Here=92s how you should arrange addresses = cleverly, you can also implement a more elaborate compression algorithm, = but that=92s out of the scope of this document=94?
Also, any = mention of the word =93straightforward=94 makes me very suspicious, but = that might just be me.

Section = 6.1.:
     =93RECOMMNDED=94 in the first = paragraph is missing an = E.

Regards,
Lotte

<= div>
[1] Random one pulled out of my logfiles for = illustration:

     ,------------------
     |  = PACKET
     = |------------------
     | * Packet version:    = 0
     | * Packet = flags:      0x0
     = |    ,-------------------
     = |    |  MESSAGE
     = |    |-------------------
     = |    | * Message = type:       11
     = |    | * Message flags:      = 0x40
     |    | * Address = length:     16
     = |    | * Hop = limit:          = 20
     |    |    = ,-------------------
     |    |    = |  Address: fe80::ff:fe00:1719
     = |    |    |    | - = TLV
     |    |    = |    |     Flags =3D = 0x50
     |    |    = |    |     Type =3D = 0
     |    |    = |    |     Value length: = 2
     |    |    = |    |       0000: = 0100
     |    |    = `-------------------
     |    |    = ,-------------------
     |    |    = |  Address: fe80::ff:fe00:16fe
     = |    |    |    | - = TLV
     |    |    = |    |     Flags =3D = 0x50
     |    |    = |    |     Type =3D = 1
     |    |    = |    |     Value length: = 2
     |    |    = |    |       0000: = 0100
     |    |    = |    | - TLV
     |    |    = |    |     Flags =3D = 0xd0
     |    |    = |    |     Type =3D 3; Type ext. =3D = 3
     |    |    = |    |     Value length: = 1
     |    |    = |    |       0000: = 00
     |    |    = `-------------------
     |    = `-------------------
     = `------------------


Best = regards
Ulrich 

Begin forwarded = message:

From: internet-drafts@ietf.org
<= b>Date: May 28, = 2015 at 11:12:35 GMT+3
To: "Christopher Dearlove" = <chris.dearlove@baesystems.co= m>, "Henning Rogge" <henning.rogge@fkie.fraunh= ofer.de>, "Thomas Clausen" <t.clausen@computer.org>, = "Henning Rogge" <henning.rogge@fkie.fraunh= ofer.de>, "Ulrich Herberg" <ulrich@herberg.name>, "Thomas = H. Clausen" <T.Clausen@computer.org>, = "Christopher Dearlove" <chris.dearlove@baesystems.co= m>, "Ulrich Herberg" <ulrich@herberg.name>
Subj= ect: New = Version Notification for = draft-clausen-manet-rfc5444-usage-00.txt


A new version of I-D, = draft-clausen-manet-rfc5444-usage-00.txt
has been = successfully submitted by Thomas Clausen and posted to = the
IETF = repository.

Name:       =  draft-clausen-manet-rfc5444-usage
Revision:   =  00
Title:        Rules For = Designing Protocols Using the RFC5444 Generalized Packet/ Message = Format
Document date:   =  2015-05-28
Group:       =  Individual Submission
Pages:       =  17
URL: =            https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5= 444-usage-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/=
Htmlized:       = https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00


Abstract:
&nb= sp; This document updates the generalized MANET packet/message = format,
  specified in RFC5444, by providing = prescriptive guidelines for how
  protocols = can use that packet/message format.  In particular, = these
  mandatory guidelines prohibit a number = of uses of RFC5444 that have
  been suggested = in various proposals, and which would have lead = to
  interoperability problems, to impediment = of protocol extension
  development, and to = inability to use generic RFC5444 = parsers.




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
= --Apple-Mail=_AB847D83-9518-4B0C-BCD9-5CDF91A9E680-- From nobody Wed Oct 7 00:44:21 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877031A8AEC; Wed, 7 Oct 2015 00:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gxg8CmY69k8; Wed, 7 Oct 2015 00:44:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6531D1A1A1D; Wed, 7 Oct 2015 00:44:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007074419.27563.38861.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 00:44:19 -0700 Archived-At: Cc: draft-ietf-manet-olsrv2-multitopology@ietf.org, manet@ietf.org, manet-chairs@ietf.org Subject: [manet] Benoit Claise's No Objection on draft-ietf-manet-olsrv2-multitopology-07: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 07:44:20 -0000 Benoit Claise has entered the following ballot position for draft-ietf-manet-olsrv2-multitopology-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and Sue's points. Editorial comments: Section 12 "If the MANET may contain non-MT-OLSRv2 routers," This is weird sentence. The next bullet point contains a similar sentence which I believe is more appropriate: "Note that if there is any possibility that there are any routers not implementing MT-OLSRv2" The following sentence could also be improved (may or may not) "If a packet is created for a destination that is not part of the corresponding topology then it may or may not be delivered (if the originating router is a non-MT-OLSRv2 router) or will not be transmitted (if the originating router is an MT-OLSRv2 router). Routers SHOULD be managed so that this does not occur." Regards, Benoit From nobody Wed Oct 7 14:53:27 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507901A1BDF; Wed, 7 Oct 2015 14:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHVCXC2bvKGP; Wed, 7 Oct 2015 14:53:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E639F1ACE0A; Wed, 7 Oct 2015 14:53:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151007215315.30775.87776.idtracker@ietfa.amsl.com> Date: Wed, 07 Oct 2015 14:53:15 -0700 Archived-At: Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Document Action: 'Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)' to Experimental RFC (draft-ietf-manet-olsrv2-multitopology-07.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:53:24 -0000 The IESG has approved the following document: - 'Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)' (draft-ietf-manet-olsrv2-multitopology-07.txt) as Experimental RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ Technical Summary This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFC 7181 by creating an interoperable extension to it. This specification updates RFC 7188 and RFC XXXX (draft-ietf-manet-tlv-naming) by modifying and extending TLV registries and descriptions. Working Group Summary: There were no particular points of contention in the WG process, and the consensus behind publication of this document as an Experimental RFC appears solid. Document Quality: There are two experimental implementations of the specification. There have been good discussions of the document among the WG participants, in general (reflected in the acknowledgements section). There have been no specific MIB doctor, Media Type or other expert reviews done. This document hit a bump when the AD raised some issues about the IANA considerations (see History). The document was put on hold while draft-ietf-manet-tlv-naming was written and became adopted by the MANET working group. Unusually, this document includes an update to an I-D that is behind it in the publication process. draft-ietf-manet-tlv-naming is a normative reference and is shown as RFC XXXX in this document. This situation arises from the bump described above, and more directly from a desire not to completely rework this document or hold it up any further in the approval process (clearly it *will* be held in the RFC editor queue pending draft-ietf-manet-tlv-naming. Personnel: The Document Shepherd is Ulrich Herberg. The Responsible Area Director is Alvaro Retana. RFC Editor Note Please replace XXXX with the RFC number assigned to draft-ietf-manet-tlv-naming From nobody Fri Oct 9 06:44:52 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB01B3E7F for ; Fri, 9 Oct 2015 06:44:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q1ALHpZjN4Q for ; Fri, 9 Oct 2015 06:44:45 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450: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 C5AFD1B3E81 for ; Fri, 9 Oct 2015 06:44:44 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so68861411wic.1 for ; Fri, 09 Oct 2015 06:44: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eTysCJZvP7DUawa+DGJndKThDMVQo8lovowltL+I5+w=; b=WDvg48IO3S6k1uU92TIvlCwCy7e7Oze2qqOomCLN7+LN+TXXMeWpag60c4szZZ/8zV pfjxarfYXEnXHEvhYa64V/RHn5xb9O8XSywR7PBS5w/9uariRNvBMPj4AxtNt+pr/RKh c7g7pAaqXWA+mmmzttlZsOSqfgwrkW7uDG02On7h9ueWTCrAqXE6GB6IMSqeG15UTIsi nbEYipUszKbhzPIE1mA0UdZ08BtVQWs3Dd7HRX0Dg+NX9I3y7T1ZrEFdXGZ/2VHsIgR0 apvgAWvVfkb8bplXXiX5cQuBUI2FuE7SRb3/mCwzHC5mRxo8aSlCb1NPoF7fSXK28b/T gveQ== X-Received: by 10.194.116.106 with SMTP id jv10mr16302068wjb.0.1444398283391; Fri, 09 Oct 2015 06:44:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.81.81 with HTTP; Fri, 9 Oct 2015 06:44:13 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 9 Oct 2015 15:44:13 +0200 Message-ID: To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AD Review of draft-ietf-manet-olsrv2-dat-metric-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 13:44:49 -0000 Hi and thank you for the long review. I will see that I post a new revision of the draft next week and/or come back with a few questions for clarification. Henning Rogge On Mon, Oct 5, 2015 at 11:12 PM, Alvaro Retana (aretana) wrote: > Hi! > > I just finished reading this draft. Thank you for the background and > history. > > I identified some Major issues that should be easy to fix. But in genera= l I > found the document relatively easy to read and understand. Once you addr= ess > the comments (and post an update, as needed) for the Major items I will > start the IETF Last Call. > > Thanks! > > Alvaro. > > > Major: > > What are the parameters of this experiment? Being an Experimental docume= nt, > there should be some guidance as to what type of information wants to be > collected, what type of topologies should be used, etc..to eventually > declare the experiment a success. This information can be used later to > change the track and (for example) use it to move the DAT into the Standa= rds > Track. > Section 9.2. (Requirements for using DAT metric in OLSRv2 implementations= ) > > What happens to packets that don't meet these requirements? I'm assuming > that they're just not used to calculate the DAT, is that true? Is it ok = if > some packets on a link meet the requirements and others don't? > The INTERVAL_TIME TLV doesn't have to be in every HELLO (according to > rfc6130), and Section 9.4 accounts for that already. So it looks like th= at > is not really a requirement. > > There is some rfc2119 language in Section 9.3. (Link Loss Data Gathering) > that is not clear. > > "For each incoming [RFC5444] packet, additional processing SHOULD be carr= ied > out after the packet messages have been processed as specified in [RFC613= 0] > and [RFC7181]." Which additional processing? Are you just referring to > what is specified later in this section? Please be specific. > "[RFC5444] packets without packet sequence number MUST NOT be processed i= n > this way by this metric." I'm guessing here you also are referring to > what's specified in the rest of the section, right? > > Even though this document doesn't formally (because it is Experimental) > Update rfc5444, rfc6130 and rfc7181, it would be a good idea to include a > section (maybe around Section 5) that summarizes the changes/updates done > here. > > > Minor: > > In Section 2. (Terminology), "diff_seqno(new, old)" is defined. However, > Section 9.3 uses "seq_diff" instead. > > Section 3. (Applicability Statement): the references to OLSRv2 seems to n= ot > be correct. > > Section 6. (Protocol Parameters) > > This section starts by talking about "two constants", and then listing > "these constants", but the list actually has 4 parameters. Section 7 als= o > seems to talk about constants. Should these two sections be merged into > one?? > s/DAT_MEMORY_LENGTH - Queue length=E2=80=A6within the queue are used to = calculate > the cost of the link./DAT_MEMORY_LENGTH - Queue length=E2=80=A6within th= e queue > length are used to calculate the cost of the link. > > In Section 6.1. (Recommended Values) the recommended value for > DAT_REFRESH_INTERVAL is 1; the first paragraph says that "mobile networks > might require shorter DAT_REFRESH_INTERVAL". The only thing lower than 1= is > 0; would that mean that in a mobile network the recommendation is to > continuously recalculate the metric? > References: > > RFC3626, RFC7182 and RFC7183 can be Informative. > > Do you want to reference the appendixes (B, C and D) somewhere in the mai= n > text? > > > Nits: > > Introduction: s/OLSR networks gathered since the publication of OLSR/OLSR > networks gathered since its publication > The DLEP reference is out of date. > Section 4: > > s/dijkstra/Dijkstra > "=E2=80=A6already gathered link loss data=E2=80=A6" A reference to Secti= on 9 would be nice. > > Appendix A. > > B.A.T.M.A.N. Reference? > "consists of 400 routers (around 600 routes)" 400 or 600? > > Idnits identifies some line spacing issues, please take a look. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Fri Oct 9 08:40:35 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428A81B444B; Fri, 9 Oct 2015 08:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BmnfyowrQTM; Fri, 9 Oct 2015 08:40:32 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8301A906A; Fri, 9 Oct 2015 08:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1500; q=dns/txt; s=iport; t=1444405232; x=1445614832; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bchhM5qG3EiFMm/72J71LcXWSNpdV/3tO40YTdepGx4=; b=SXrFPr7Iv2+gQEw35WJCHk8b7lMt80Ij17cdblWm5Uf18GSo2Z0cul9L WygyLWqIhbUY3ux8S82aj8whkMA0sgWRzBUE44yfOD3NsFx7AQXjL42N5 DOokukjerYWzj0FS07K8t+2sKdb20kbZSC8raF+LlqNcNRBlM50hGTyvZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BoAgAw3xdW/5BdJa1egyZUbga9YAENgVoXCoJyggo1SgKBRTgUAQEBAQEBAYEKhCcBAQQBAQE3NBsCAQgkEgULJwsbAQYDAgQBEoguDcNeAQEBAQEBAQEBAQEBAQEBAQEBARUEhnMBhH2EKQERAViELgWFRI0Qgz4BhRiFSoI3gViEOpVtHwEBQoIMOIE+cYYqOoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,658,1437436800"; d="scan'208";a="195727994" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 09 Oct 2015 15:40:31 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t99FePRA016657 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2015 15:40:30 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 9 Oct 2015 10:40:26 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 9 Oct 2015 10:40:26 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 10:40:28 -0500 From: "Alvaro Retana (aretana)" To: "pim@ietf.org" , "manet@ietf.org" Thread-Topic: New Non-WG Mailing List: 5gangip -- Discussion of implications of the upcoming 5th Generation (fixed and) Mobile communication systems on IP protocols. Thread-Index: AQHRAgVDymvUQriiUke0E/kP/hEjG55jXliA Date: Fri, 9 Oct 2015 15:40:27 +0000 Message-ID: References: <20151008200914.12173.16905.idtracker@ietfa.amsl.com> In-Reply-To: <20151008200914.12173.16905.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <996933DB14955E4CAA3A2C516845867A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [manet] FW: New Non-WG Mailing List: 5gangip -- Discussion of implications of the upcoming 5th Generation (fixed and) Mobile communication systems on IP protocols. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 15:40:33 -0000 FYI.. May be of interest to some of you. Alvaro. On 10/8/15, 4:09 PM, "IETF-Announce on behalf of IETF Secretariat" wrote: >A new IETF non-working group email list has been created. > >List address: 5gangip@ietf.org >Archive: https://mailarchive.ietf.org/arch/search/?email_list=3D5gangip >To subscribe: https://www.ietf.org/mailman/listinfo/5gangip > >Purpose: > >5G Aspects of Next Generation Internet Protocols > >This list is intended for discussions relating the use of Internet >Protocols, e.g. IPv6, IP Multicast, etc. in 5G networks. As the fifth >generation mobile technology (5G) begins to draw more attention in all >major standards development organizations (SDOs) as well as in IETF, many >are interested in work around 5G. Typical use cases are in 50+ Mbps >Everywhere, Massive Internet of Things (IoT), Extreme Real-Time >Communications, Lifeline Communication, Ultra-reliable Communications, >Broadcast-like Services. > >Major design criteria are technology independence and a modular >interoperable approach to allow for full service flexibility. This group >is expected to concentrate especially on 5G aspects of next generation >Internet Protocols (IP) including IP Multicast. As such, the work does >not have a clearer scope than this yet. 5Gangip is a place to organize >this discussion.=20 > > >For additional information, please contact the list administrators. > From nobody Sat Oct 10 07:49:37 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B451B3D88 for ; Sat, 10 Oct 2015 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxDQpUAyALa for ; Sat, 10 Oct 2015 07:49:34 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7492E1B3D8B for ; Sat, 10 Oct 2015 07:49:34 -0700 (PDT) Received: from [99.51.72.56] (helo=[192.168.1.68]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ZkvSg-0004Ez-Qu for manet@ietf.org; Sat, 10 Oct 2015 10:49:26 -0400 References: <20151005200239.11929.39227.idtracker@ietfa.amsl.com> To: Mobile Ad Hoc Networks mailing list From: "Charles E. Perkins" Organization: Blue Skies X-Forwarded-Message-Id: <20151005200239.11929.39227.idtracker@ietfa.amsl.com> Message-ID: <56192564.1090207@computer.org> Date: Sat, 10 Oct 2015 07:49:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151005200239.11929.39227.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070800040005010800010803" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78e62dd463f8d030c2ba3d8ae79b5292b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.56 Archived-At: Subject: [manet] Fwd: New Version Notification for draft-perkins-manet-tdpb-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 14:49:36 -0000 This is a multi-part message in MIME format. --------------070800040005010800010803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Here is a draft for a cost metric to help with selection of a route with the highest end-to-end bandwidth. It is short and has a simple section showing definitions for Cost() and LoopFree() as used with AODVv2. There are other such cost metrics which have other advantages, but this basic metric will be very helpful I think for simple devices. I will soon provide a latency metric which will be even easier to calculate. Regards, Charlie P. -------- Forwarded Message -------- Subject: New Version Notification for draft-perkins-manet-tdpb-00.txt Date: Mon, 05 Oct 2015 13:02:39 -0700 From: internet-drafts@ietf.org To: Charles E. Perkins , Charles E. Perkins A new version of I-D, draft-perkins-manet-tdpb-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-manet-tdpb Revision: 00 Title: Transmission Duration Per Bit Cost Metric Document date: 2015-10-05 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-perkins-manet-tdpb-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-manet-tdpb/ Htmlized: https://tools.ietf.org/html/draft-perkins-manet-tdpb-00 Abstract: The Transmission Duration Per Bit metric is a simple cost metric that enables selection of a route with the highest end-to-end bandwidth. 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 --------------070800040005010800010803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello folks,

Here is a draft for a cost metric to help with selection of a route with the highest end-to-end bandwidth.  It is short and has a simple section showing definitions for Cost() and LoopFree() as used with AODVv2.  There are other such cost metrics which have other advantages, but this basic metric will be very helpful I think for simple devices.

I will soon provide a latency metric which will be even easier to calculate.

Regards,
Charlie P.



-------- Forwarded Message --------
Subject: New Version Notification for draft-perkins-manet-tdpb-00.txt
Date: Mon, 05 Oct 2015 13:02:39 -0700
From: internet-drafts@ietf.org
To: Charles E. Perkins <charliep@computer.org>, Charles E. Perkins <charliep@computer.org> 


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

Name:		draft-perkins-manet-tdpb
Revision:	00
Title:		Transmission Duration Per Bit Cost Metric
Document date:	2015-10-05
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-perkins-manet-tdpb-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-manet-tdpb/
Htmlized:       https://tools.ietf.org/html/draft-perkins-manet-tdpb-00


Abstract:
   The Transmission Duration Per Bit metric is a simple cost metric that
   enables selection of a route with the highest end-to-end bandwidth.

                                                                                  


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


--------------070800040005010800010803-- From nobody Sat Oct 10 12:23:06 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6F51B44BD for ; Sat, 10 Oct 2015 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCpywCARyC3c for ; Sat, 10 Oct 2015 12:23:03 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 649BF1B44BC for ; Sat, 10 Oct 2015 12:23:03 -0700 (PDT) Received: by lbos8 with SMTP id s8so109251098lbo.0 for ; Sat, 10 Oct 2015 12:23: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:content-type; bh=bf2R9AziygzpUAxWTFQUvMytwtfeoNGhsd+vIPx/Ii0=; b=u2QbLzuDUWOE8EHzuu/LWKR5kkYKB+rOXIEaxeTN4uxI20oEKOX1XoSfTBuB2lBGCd namKAfsNZvtxahr4F1ZdV6qoEjTIcV56elUoQwRKbIQjlhAyjZxJUdbcA+tK3aO/VCt7 0svV5cTSIHn5OSB8hG/efZCWHLVo7rtzR0FA+3B4oeBkoAndgXunUZslIr391Mt/mPrm 6T2LQ9uqWHhxox0qMbuC7tixg3I3eV8z0nhSeUXsY7OOoXiUy6swXRblsibjMOu2eryR CIxWXUJg1+YXGwJ4asqRrZxsxKXcEuHE8xqxUICzXsXBWXnew4S43Hsxs32/Sl3ExhBz sO5w== MIME-Version: 1.0 X-Received: by 10.112.130.70 with SMTP id oc6mr9443041lbb.32.1444504981641; Sat, 10 Oct 2015 12:23:01 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Sat, 10 Oct 2015 12:23:01 -0700 (PDT) Date: Sat, 10 Oct 2015 15:23:01 -0400 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=047d7b34310a4ea4700521c506d3 Archived-At: Subject: [manet] No MANET Meeting Scheduled for Yokohama X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 19:23:05 -0000 --047d7b34310a4ea4700521c506d3 Content-Type: text/plain; charset=UTF-8 Hello WG participants, Just an FYI - there's no MANET meeting scheduled for the upcoming IETF in Yokohama. The consensus amongst the chairs was that we need to progress the AODVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, the thought was that a face-to-face isn't necessary; the work can and should progress on the list. Both of the pending drafts (AODVv2 and DLEP) have new revisions coming - most likely this next week. Please stay tuned for updates, and your review & comments will be welcome and appreciated. Regards, Stan --047d7b34310a4ea4700521c506d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello WG participants,

Just a= n FYI - there's no MANET meeting scheduled for the upcoming IETF in Yok= ohama. The consensus amongst the chairs was that we need to progress the AO= DVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, the tho= ught was that a face-to-face isn't necessary; the work can and should p= rogress on the list.

Both of the pending drafts (AODVv2 = and DLEP) have new revisions coming - most likely this next week. Please st= ay tuned for updates, and your review & comments will be welcome and ap= preciated.

Regards,
Stan
--047d7b34310a4ea4700521c506d3-- From nobody Sat Oct 10 12:58:02 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0771E1B463D for ; Sat, 10 Oct 2015 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTRK3zlsfIy7 for ; Sat, 10 Oct 2015 12:57:59 -0700 (PDT) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85C11B4639 for ; Sat, 10 Oct 2015 12:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 90B8F52037C; Sat, 10 Oct 2015 12:57:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.160] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 41DC41C0471; Sat, 10 Oct 2015 12:57:59 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <72796CAF-F7CD-4DCE-9F83-859E596050D0@thomasclausen.org> Date: Sat, 10 Oct 2015 21:57:59 +0200 References: In-Reply-To: To: Stan Ratliff , manet@ietf.org, manet-ads@tools.ietf.org X-Mailer: iPad Mail (13A452) Archived-At: Subject: Re: [manet] No MANET Meeting Scheduled for Yokohama X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 19:58:01 -0000 Given the significant volume of outstanding unresolved, and raised-but-un-ad= dressed, issues with current WG deliverables, and given that rechartering ha= s been announced but never discussed on the list, it would have been more th= an reasonable to agree with the WG (by way of the mailing list) in well in a= dvance -- rather than for the chair to unilaterally decide to cancel any fur= ther discussions at the WG meeting *after* the deadline for "final agenda" h= as lapsed. As far as I understand, in the IETF WG decisions are made by way of consensu= s among a populace larger than the WG chairs. Thomas > On 10 Oct 2015, at 21:23, Stan Ratliff wrote: >=20 > Hello WG participants,=20 >=20 > Just an FYI - there's no MANET meeting scheduled for the upcoming IETF in Y= okohama. The consensus amongst the chairs was that we need to progress the A= ODVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, the tho= ught was that a face-to-face isn't necessary; the work can and should progre= ss on the list.=20 >=20 > Both of the pending drafts (AODVv2 and DLEP) have new revisions coming - m= ost likely this next week. Please stay tuned for updates, and your review & c= omments will be welcome and appreciated.=20 >=20 > Regards, > Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sat Oct 10 17:02:01 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721A61B2DC8 for ; Sat, 10 Oct 2015 17:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 u7wGFgDC2POh for ; Sat, 10 Oct 2015 17:01:57 -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 C545A1B2DA7 for ; Sat, 10 Oct 2015 17:01:56 -0700 (PDT) Received: by vkat63 with SMTP id t63so70139177vka.1 for ; Sat, 10 Oct 2015 17:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JoDeorNGXfqJXo9TzZHWP3qGTi25io7d+6CCktAnl9c=; b=k7qv9y8ppC0fixRGxUUgWYDmIfGEHj3/isSc1rduKDtvz+nvvKq+P0ttaSdJYGCWrh H9kbZcI7xTmWWAv5RzAI4gb0e4B93QAzlczOqqnwp1mHM17WISKkq72UGa+XEZJixT+8 cbRRRz3qaMMTlisRxe72iWLAEAPxpGCHCk7Iw= 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-type :content-transfer-encoding; bh=JoDeorNGXfqJXo9TzZHWP3qGTi25io7d+6CCktAnl9c=; b=cX5rhuZ9cl+BZ40apFbI3zAW6nprqJ/8spG+oPvazsg6zD4jCmG/smyXoJev5FYDNs 8yt2CvSR1ranEH3jzVD+aD7+N+g4VcuIaKymIpav6lblhINL30hsVfoONIN3sqYoHW8u DVeHQWUfGuOlJhbfrzTdU70DlrS3RscYoLvl3h4+goo5tEglx2zRZi5P/EFPSqk6HNH5 PtM+8aje43/Z9qvsDXVz4TEC2soZtDObXNd8zkCd1V2Ii6vhs4Td6X/vdM+bcmL+QoMc 12NFd2LqOY7b/TRL4R3JixDNkUrRWby5Slzcu4UZ1xK+psEyjxvgf/133X/5cu6/zBQJ Ua7Q== X-Gm-Message-State: ALoCoQnnJG51rSAwkP3aSD3/CiFBwXHPmEneub3r41/sUSWgPrtErCc86/pGjoH3mH03LQuTVENf MIME-Version: 1.0 X-Received: by 10.31.180.79 with SMTP id d76mr13817600vkf.111.1444521715801; Sat, 10 Oct 2015 17:01:55 -0700 (PDT) Received: by 10.31.97.194 with HTTP; Sat, 10 Oct 2015 17:01:55 -0700 (PDT) In-Reply-To: <54EC4DED-0D11-4635-B1FB-1CD2DF9F08F8@fu-berlin.de> References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> <54EC4DED-0D11-4635-B1FB-1CD2DF9F08F8@fu-berlin.de> Date: Sat, 10 Oct 2015 17:01:55 -0700 Message-ID: From: Ulrich Herberg To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet@ietf.org Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 00:02:00 -0000 Dear Lotte, I apologize for the delay responding to your email. Life always seems to get in the way of IETF work... ;-) See below: > [...] > I'm particularly interested in an answer to my earlier question concernin= g section 4.6., i.e.: if a message needs to be regenerated to be forwarded,= and this message contains TLVs that the regenerating 5444 parser/builder d= oesn't recognize, should it add the unknown TLVs to the message (which woul= d mean that =E2=80=9CMUST NOT remove suchTLVs or values=E2=80=9D applies, w= hich should imo be clarified in the draft) or should the unknown TLVs be di= scarded (which would need clarification too, imo)? First of all, I think that "regenerating" is the wrong word. That would imply that you consume the incoming message, erase it, allocate new memory and create a new message with the same content. While that is certainly possible, it does not seem a very good idea doing that; in addition, it is also counter-intuitive to understand. The idea of RFC5444 is really: - packet: container for zero or more messages; travels exactly one hop; is not "owned" by any particular protocol; may contain TLVs for, e.g., security credentials - message: owned by a particular protocol; travels multiple hops (end-to-end), contains information about the message itself (message TLV), as well as a list of addresses with associated information (address block TLV) In my implementation of RFC5444 (actually, I built multiple, since I was changing employer at some point and didn't have the IP to reuse the code), I would have a general RFC5444 generator and parser that can communicate via an API with one more protocols (e.g., NHDP). Protocols would register themselves with the parser, and so when the parser receives an incoming packet, it checks for each contained message if the message type is "owned" by one of the protocols. If not, the message is discarded. If it is, then parse the message to interpret the information and hand up to the protocol (but keep the actual byte array). The protocol can then do whatever it likes to do with the message, including dropping, consuming or forwarding. In that process, the byte array may be modified (but again, not regenerated, since that would be very inefficient). After the protocol is done modifying the message, it hands the message back down to the RFC5444 generator/parser, which in turn forwards it to the specified (multicast) IP address. One more important argument why "regenerate" is not a good word (IMO) is that it could imply that end-to-end securing a message (e.g., with RFC7182) is not possible. In order to allow to use digital signatures to verify inte= grity of a message multiple hops away, it must not be modified along the path towards its destination (that is modulo fields such as hop-count/limit, which can be set to 0, as done for example in OLSRv2). If a router regenera= tes a message this would for example imply that it could change order of TLVs. However, that would break such a security mechanism. Now, regarding dropping the TLVs, the process is similar to the way the protocols register with the RFC5444 module; the protocol will have a list of "known" TLVs that it recognizes. Additional TLVs that it does not know about will be ignored (but not dropped). Other extensions may be able to parse the information of these TLVs. Also, in terms of end-to-end integrity protection, it is evident that we cannot drop these TLVs without breaking said protection. I re-read the section 4.6, and I think the paragraph is concise and specifies exactly what I wrote above (a little less verbose and using different words). One other thing that I wanted to mention, since I used the word "API" in the above description: I remember that there were some requests to have an "API" document for RFC5444. This is clearly not the intention of the RFC5444-usage document, and it would be outside of IETF scope (as well as a bad idea, in my personal opinion). The API I mentioned above in my implementation was written in Java and had a particular signature. Writing that down in a document would be unhelpful for, say, Thomas' COBOL60 implementation. He may have completely different constraints of the language as well as way of calling the API. Also, since the bytes sent between these two software modules do not go over the network, there are no interoperability problems (which is the whole point of having the IETF), and it unnecessarily constrain vendors in designing efficient APIs. Best regards Ulrich On Tue, Oct 6, 2015 at 11:15 AM, Lotte Steenbrink wrote: > Hi all, > I realize vacation season and/or other circumstances have slowed most of = us > down at one point or another, but I was wondering if one of the authors > could give us a very brief update on how the work on this draft is doing? > > I'm particularly interested in an answer to my earlier question concernin= g > section 4.6., i.e.: if a message needs to be regenerated to be forwarded, > and this message contains TLVs that the regenerating 5444 parser/builder > doesn't recognize, should it add the unknown TLVs to the message (which > would mean that =E2=80=9CMUST NOT remove suchTLVs or values=E2=80=9D appl= ies, which should > imo be clarified in the draft) or should the unknown TLVs be discarded > (which would need clarification too, imo)? > > If the answer is =E2=80=9Cwe're working on it, hold on for a few more day= s=E2=80=9D, that's > completely fine, I'd just like to know if/when I can find out how to do t= his > correctly. :) > > Regards, > Lotte > > Am 09.06.2015 um 16:26 schrieb Lotte Steenbrink > : > > Hi Ulrich, Thomas, Chris and Henning, > > Am 31.05.2015 um 13:33 schrieb Ulrich Herberg : > > As we announced previously, we have been working on a document specifying > rules for how to use RFC5444 in MANET protocols. Well, here it is (at lea= st > in a -00 version). > We'd appreciate reviews and will soon ask for WG adoption. > > > first of all, thank you so much for publishing this much-needed draft. I'= m > also in favor of WG adoption. While reading through the document, I wrote > down some nitpicks and suggestions that I'd like to share. > (Just in case my writing sounds harsh, I fear that's due to > language/cultural differences. I'm really happy about this document and > would like to see it flourish.) > > =3D=3D General notes =3D=3D > - If I didn=E2=80=99t misunderstand it, the document addresses two groups= of people: > Those who want to design RFC5444 messages for their protocol, and those w= o > want to implement a RCF 5444 builder/parser. Imo, The former group needs > more of an outside view (i.e. what can/should I put where), while the lat= ter > needs the inside view (i.e. how do I arrange and process everything > efficiently). To my mind, these are two very different goals, but while > reading the document, it wasn=E2=80=99t always instantly clear to me whic= h bit > addresses which group=E2=80=A6 I realize the two can=E2=80=99t always be = separated > completely, but would it be possible to make it more clear which group is > addressed currently? Maybe the document could be organized into two big > sections (one for each group), or there could be a recurring pattern of > =E2=80=9Cfirst outside then inside view=E2=80=9D for each (sub)section? > > - A lot of the examples are very NHDP/OLSR-specific. While I think it=E2= =80=99s > great to have pointers to where a certain technique has already been used= , > from an outsider=E2=80=99s perspective, the examples don=E2=80=99t always= help me understand > the technique that=E2=80=99s being illustrated, since I have to familiari= ze myself > with the details referenced first=E2=80=A6 I=E2=80=99m wondering if it wo= uld be possible to > keep the examples which illustrate a point more generic, and then briefly > point to existing instances of this situation in case the reader wants to > follow up on that? > > =3D=3D Section by section =3D=3D > Section 1.2., Page 4: > =E2=80=9CA packet is designed to as travel [=E2=80=A6]=E2=80=9D I th= ink the =E2=80=9Cas=E2=80=9D doesn=E2=80=99t belong > here. > > Section 4.2., Page 8: > =E2=80=9COutgoing messages MAY be created by owning protocol=E2=80= =9D I think there=E2=80=99s a > =E2=80=9Cthe=E2=80=9D missing. > > Section 4.3., Page 8: > If I understand it correctly, the last paragraph on this page is > talking about multi-value TLVs without actually saying =E2=80=9Cmulti-val= ue TLV=E2=80=9D. > Maybe that could be stated explicitly for clarity and in case somebody=E2= =80=99s > searching for advice by this keyword? > > Section 4.4., Page 9/10: > The last paragraph on page and the first two on page 10, more > specifically these parts: > > Such an example already exists (but within the basic > specification, rather > than as an extension) in the use of LOST values in the LINK_STA= TUS > and OTHER_NEIGHB TLVs to report that an address is of a router > known > not to be a neighbor. A future example might be to list an > address > to be added to a "blacklist" of addresses not to be used. > > This example can be taken further. NHDP must also not reject a > HELLO > message because it contains an unrecognized TLV. This also appl= ies > to unrecognized TLV values, where a TLV supports only a limited > set > of values. > > were a bit hard to read for me. Imho, the example is very specific a= nd > contains details which aren=E2=80=99t necessary to understand the issue a= t hand > (such as the fact that this extension is technically not a completely > independent extension, or possible future other extensions). It took me > about 4 re-reads to really grasp what=E2=80=99s going on there... > > Also, I would=E2=80=99ve expected the last paragraph of this section= to clearly > state that relying on address order *will* break your messages if you don= =E2=80=99t > have control over all 5444 builders that are used to implement your proto= col > ever. > > Section 4.5.: > I'm assuming that this is the response to our (the AODVv2 Author tea= m > and possibly others) complaints that RFC5444 lacks a clear "API" which te= lls > it what we can and cannot set manually in an RFC 5444 packet, and that > there's no (at the risk of sounding really pretentious now) "visual > language" to describe the contents of a 5444 message and their relationsh= ip > to each other. To be honest, I'm a bit puzzled by this section.... The > mapping that is presented is a bit vague and introduced very promptly. An= d > while I strongly agree with the statement that writing down an actual API= is > too language- and implementation-specific to belong in a document like th= is, > it would be really helpful to have a comprehensive "these are the things > that your protocol can set in a RFC5444 message. Your packet builder/pars= er > will figure out the rest." List in this section rather than some examples= . > Along with this list, it would be great to have a clear specification on = how > to specify which Addresses and TLVs a specific message has, and how their > relationship to each other are. (i.e. how to make clear which address TLV= s > are associated with which addresses). I don=E2=80=99t care if this ends u= p being a > very visual approach (like the debugging output of Henning=E2=80=99s oonf= API [1]), > or the tables that OLSRv2 uses, or something completely different, but it > would be helpful to be able to read and write messages down in a way that= is > clear to everyone. > > Section 4.6: > =E2=80=9C[=E2=80=A6] and MUST NOT remove such TLVs or values=E2=80= =9D > A question I=E2=80=99ve been wanting to ask for a while now: Does th= is rule > also apply for message regeneration? AODVv2 regenerates all messages per > hop. Should implementations keep track which unknown TLVs of a message ar= e > associated with which addresses, and put them back in their place when > regenerating the message? > > Section 6.1.: > (I=E2=80=99m not terribly familiar with compression, so my questions= are > probably very naive, but maybe they can help clear things up) > Would this very straightforward to implement compression algorithm > still produce interoperable messages? The rest of the section reads as if > the =E2=80=9Ccompression algorithm=E2=80=9D mentioned in the introduction= is mainly a way to > cleverly arrange addresses so that they are still understood by all parse= rs, > but take up a minimal amount of space. I think that=E2=80=99s a very good= tip in > itself, but is that really all there is to compression? Would it make sen= se > to say =E2=80=9CHere=E2=80=99s how you should arrange addresses cleverly,= you can also > implement a more elaborate compression algorithm, but that=E2=80=99s out = of the > scope of this document=E2=80=9D? > Also, any mention of the word =E2=80=9Cstraightforward=E2=80=9D makes me = very suspicious, > but that might just be me. > > Section 6.1.: > =E2=80=9CRECOMMNDED=E2=80=9D in the first paragraph is missing an E. > > Regards, > Lotte > > > [1] Random one pulled out of my logfiles for illustration: > > ,------------------ > | PACKET > |------------------ > | * Packet version: 0 > | * Packet flags: 0x0 > | ,------------------- > | | MESSAGE > | |------------------- > | | * Message type: 11 > | | * Message flags: 0x40 > | | * Address length: 16 > | | * Hop limit: 20 > | | ,------------------- > | | | Address: fe80::ff:fe00:1719 > | | | | - TLV > | | | | Flags =3D 0x50 > | | | | Type =3D 0 > | | | | Value length: 2 > | | | | 0000: 0100 > | | `------------------- > | | ,------------------- > | | | Address: fe80::ff:fe00:16fe > | | | | - TLV > | | | | Flags =3D 0x50 > | | | | Type =3D 1 > | | | | Value length: 2 > | | | | 0000: 0100 > | | | | - TLV > | | | | Flags =3D 0xd0 > | | | | Type =3D 3; Type ext. =3D 3 > | | | | Value length: 1 > | | | | 0000: 00 > | | `------------------- > | `------------------- > `------------------ > > > Best regards > Ulrich > > Begin forwarded message: > > From: internet-drafts@ietf.org > Date: May 28, 2015 at 11:12:35 GMT+3 > To: "Christopher Dearlove" , "Henning Rogg= e" > , "Thomas Clausen" > , "Henning Rogge" > , "Ulrich Herberg" , > "Thomas H. Clausen" , "Christopher Dearlove" > , "Ulrich Herberg" > Subject: New Version Notification for > draft-clausen-manet-rfc5444-usage-00.txt > > > A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt > has been successfully submitted by Thomas Clausen and posted to the > IETF repository. > > Name: draft-clausen-manet-rfc5444-usage > Revision: 00 > Title: Rules For Designing Protocols Using the RFC5444 Generalized > Packet/ Message Format > Document date: 2015-05-28 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00= .txt > Status: > https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/ > Htmlized: > https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00 > > > Abstract: > This document updates the generalized MANET packet/message format, > specified in RFC5444, by providing prescriptive guidelines for how > protocols can use that packet/message format. In particular, these > mandatory guidelines prohibit a number of uses of RFC5444 that have > been suggested in various proposals, and which would have lead to > interoperability problems, to impediment of protocol extension > development, and to inability to use generic RFC5444 parsers. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Mon Oct 12 14:58:41 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E891A21AA for ; Mon, 12 Oct 2015 14:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02vXMQfaGOYV for ; Mon, 12 Oct 2015 14:58:32 -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 1BC231A1BAF for ; Mon, 12 Oct 2015 14:58:32 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Zll6z-003288-JZ>; Mon, 12 Oct 2015 23:58:29 +0200 Received: from [95.144.178.182] (helo=frankenbook-pro.default) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Zll6y-003xoQ-Lk>; Mon, 12 Oct 2015 23:58:29 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_4B3575C5-461F-47E8-87AD-B64E3C77D1DB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: Date: Mon, 12 Oct 2015 23:00:13 +0200 Message-Id: <7EE87D17-C6E1-44BA-BA1F-10B62D103C40@fu-berlin.de> References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> <54EC4DED-0D11-4635-B1FB-1CD2DF9F08F8@fu-berlin.de> To: manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 95.144.178.182 X-ZEDAT-Hint: A Archived-At: Subject: Re: [manet] New Version Notification for draft-clausen-manet-rfc5444-usage-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 21:58:39 -0000 --Apple-Mail=_4B3575C5-461F-47E8-87AD-B64E3C77D1DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Ulrich, Am 11.10.2015 um 02:01 schrieb Ulrich Herberg : > Dear Lotte, >=20 > I apologize for the delay responding to your email. Life always seems > to get in the way of IETF work... ;-) See below: No worries, thank you for the very detailed and helpful response! >=20 >=20 >> [...] >=20 >> I'm particularly interested in an answer to my earlier question = concerning section 4.6., i.e.: if a message needs to be regenerated to = be forwarded, and this message contains TLVs that the regenerating 5444 = parser/builder doesn't recognize, should it add the unknown TLVs to the = message (which would mean that =E2=80=9CMUST NOT remove suchTLVs or = values=E2=80=9D applies, which should imo be clarified in the draft) or = should the unknown TLVs be discarded (which would need clarification = too, imo)? >=20 >=20 > First of all, I think that "regenerating" is the wrong word. That = would > imply that you consume the incoming message, erase it, allocate new > memory and create a new message with the same content. While that is > certainly possible, it does not seem a very good idea doing that; in > addition, it is also counter-intuitive to understand. The idea of > RFC5444 is really: > - packet: container for zero or more messages; travels exactly one > hop; is not "owned" by any particular protocol; may contain TLVs for, > e.g., security credentials > - message: owned by a particular protocol; travels multiple hops > (end-to-end), contains information about the message itself (message > TLV), as well as a list of addresses with associated information > (address block TLV) >=20 > In my implementation of RFC5444 (actually, I built multiple, since I > was changing employer at some point and didn't have the IP to reuse > the code), I would have a general RFC5444 generator and parser that > can communicate via an API with one more protocols (e.g., NHDP). > Protocols would register themselves with the parser, and so when the > parser receives an incoming packet, it checks for each contained > message if the message type is "owned" by one of the protocols. If > not, the message is discarded. If it is, then parse the message to > interpret the information and hand up to the protocol (but keep the > actual byte array). The protocol can then do whatever it likes to do > with the message, including dropping, consuming or forwarding. In that > process, the byte array may be modified (but again, not regenerated, > since that would be very inefficient). After the protocol is done > modifying the message, it hands the message back down to the RFC5444 > generator/parser, which in turn forwards it to the specified > (multicast) IP address. =F0=9F=92=A1 That makes much more sense... For some reason I'd just = assumed that manipulating any part of a message other than the header was illegal, thank you for clearing that up! >=20 > One more important argument why "regenerate" is not a good word (IMO) = is > that it could imply that end-to-end securing a message (e.g., with = RFC7182) > is not possible. In order to allow to use digital signatures to verify = integrity > of a message multiple hops away, it must not be modified along the = path > towards its destination (that is modulo fields such as = hop-count/limit, > which can be set to 0, as done for example in OLSRv2). If a router = regenerates > a message this would for example imply that it could change order of = TLVs. > However, that would break such a security mechanism. >=20 >=20 >=20 > Now, regarding dropping the TLVs, the process is similar to the way > the protocols register with the RFC5444 module; the protocol will have > a list of "known" TLVs that it recognizes. Additional TLVs that it > does not know about will be ignored (but not dropped). Other > extensions may be able to parse the information of these TLVs. Also, > in terms of end-to-end integrity protection, it is evident that we > cannot drop these TLVs without breaking said protection. >=20 > I re-read the section 4.6, and I think the paragraph is concise and > specifies exactly what I wrote above (a little less verbose and using > different words). >=20 Agreed. >=20 > One other thing that I wanted to mention, since I used the word "API" > in the above description: I remember that there were some requests to > have an "API" document for RFC5444. This is clearly not the intention > of the RFC5444-usage document, and it would be outside of IETF scope > (as well as a bad idea, in my personal opinion). The API I mentioned > above in my implementation was written in Java and had a particular > signature. Writing that down in a document would be unhelpful for, > say, Thomas' COBOL60 implementation. He may have completely different > constraints of the language as well as way of calling the API. Also, > since the bytes sent between these two software modules do not go over > the network, there are no interoperability problems (which is the > whole point of having the IETF), and it unnecessarily constrain > vendors in designing efficient APIs. I'm afraid my use of the term "API" was a poor choice of words... As = I've said in my initial E-Mail and in Prague, I really didn't mean to say = "tell me which functions I can implement/rely on being implemented, and which signatures they have". I agree that that request would be silly in many ways. What I meant by my request was that, when working on the packet format = for AODVv2, we had a very specific perspective: we needed to tell people who want to implement AODVv2 what to put in their packets *without getting into too much detail about what happens under the bonnet in the RFC5444 generator/parser*, since that is RFC5444's realm, and not AODVv2's. In other words, if someone with a working RFC5444 generator/parser (that = they didn't implement themselves) and a rough understanding of RFC5444 wants to implement AODVv2, they need to know which Addresses and TLVs to feed their generator/parser, and which header fields to set, but they really don't need to care about header flags and multi-value TLVs and all the nifty tricks that their RFC5444 generator/parser does internally. It was really hard to write this down in the draft, because after = careful inspection of the RFC, all of us had a different idea of which bits our potential implementor has to care about and which are handled by the generator/parser and thus don't have to (or can't) be specified manually by the protocol. If we had had a list of things that we, as protocol = authors, were allowed to tell other people to set, that would've been very very helpful and saved us a lot of time. Again, I'm not asking for this this = list to be in code form. It could for example be something along the lines of: Protocols using RFC5444 MAY define the following=20 properties of a RFC5444 message. :=3D ? ? ? ? :=3D (?)? :=3D * * All other values and properties are to be set by the=20 RFC5444 generator/parser handling the message, and=20 SHOULD NOT be tampered with by any protocol handling the message. Now, I'm sure there are many ways to do this more elegantly[1], but = maybe this sketch helps to illustrate what I'm trying to say... Best Regards, Lotte [1] And correctly. At the very least, my address block sketch is a = bit... dodgy. But you get the idea. >=20 > Best regards > Ulrich >=20 > On Tue, Oct 6, 2015 at 11:15 AM, Lotte Steenbrink > wrote: >> Hi all, >> I realize vacation season and/or other circumstances have slowed most = of us >> down at one point or another, but I was wondering if one of the = authors >> could give us a very brief update on how the work on this draft is = doing? >>=20 >> I'm particularly interested in an answer to my earlier question = concerning >> section 4.6., i.e.: if a message needs to be regenerated to be = forwarded, >> and this message contains TLVs that the regenerating 5444 = parser/builder >> doesn't recognize, should it add the unknown TLVs to the message = (which >> would mean that =E2=80=9CMUST NOT remove suchTLVs or values=E2=80=9D = applies, which should >> imo be clarified in the draft) or should the unknown TLVs be = discarded >> (which would need clarification too, imo)? >>=20 >> If the answer is =E2=80=9Cwe're working on it, hold on for a few more = days=E2=80=9D, that's >> completely fine, I'd just like to know if/when I can find out how to = do this >> correctly. :) >>=20 >> Regards, >> Lotte >>=20 >> Am 09.06.2015 um 16:26 schrieb Lotte Steenbrink >> : >>=20 >> Hi Ulrich, Thomas, Chris and Henning, >>=20 >> Am 31.05.2015 um 13:33 schrieb Ulrich Herberg : >>=20 >> As we announced previously, we have been working on a document = specifying >> rules for how to use RFC5444 in MANET protocols. Well, here it is (at = least >> in a -00 version). >> We'd appreciate reviews and will soon ask for WG adoption. >>=20 >>=20 >> first of all, thank you so much for publishing this much-needed = draft. I'm >> also in favor of WG adoption. While reading through the document, I = wrote >> down some nitpicks and suggestions that I'd like to share. >> (Just in case my writing sounds harsh, I fear that's due to >> language/cultural differences. I'm really happy about this document = and >> would like to see it flourish.) >>=20 >> =3D=3D General notes =3D=3D >> - If I didn=E2=80=99t misunderstand it, the document addresses two = groups of people: >> Those who want to design RFC5444 messages for their protocol, and = those wo >> want to implement a RCF 5444 builder/parser. Imo, The former group = needs >> more of an outside view (i.e. what can/should I put where), while the = latter >> needs the inside view (i.e. how do I arrange and process everything >> efficiently). To my mind, these are two very different goals, but = while >> reading the document, it wasn=E2=80=99t always instantly clear to me = which bit >> addresses which group=E2=80=A6 I realize the two can=E2=80=99t always = be separated >> completely, but would it be possible to make it more clear which = group is >> addressed currently? Maybe the document could be organized into two = big >> sections (one for each group), or there could be a recurring pattern = of >> =E2=80=9Cfirst outside then inside view=E2=80=9D for each = (sub)section? >>=20 >> - A lot of the examples are very NHDP/OLSR-specific. While I think = it=E2=80=99s >> great to have pointers to where a certain technique has already been = used, >> from an outsider=E2=80=99s perspective, the examples don=E2=80=99t = always help me understand >> the technique that=E2=80=99s being illustrated, since I have to = familiarize myself >> with the details referenced first=E2=80=A6 I=E2=80=99m wondering if = it would be possible to >> keep the examples which illustrate a point more generic, and then = briefly >> point to existing instances of this situation in case the reader = wants to >> follow up on that? >>=20 >> =3D=3D Section by section =3D=3D >> Section 1.2., Page 4: >> =E2=80=9CA packet is designed to as travel [=E2=80=A6]=E2=80=9D I = think the =E2=80=9Cas=E2=80=9D doesn=E2=80=99t belong >> here. >>=20 >> Section 4.2., Page 8: >> =E2=80=9COutgoing messages MAY be created by owning protocol=E2=80=9D= I think there=E2=80=99s a >> =E2=80=9Cthe=E2=80=9D missing. >>=20 >> Section 4.3., Page 8: >> If I understand it correctly, the last paragraph on this page is >> talking about multi-value TLVs without actually saying =E2=80=9Cmulti-v= alue TLV=E2=80=9D. >> Maybe that could be stated explicitly for clarity and in case = somebody=E2=80=99s >> searching for advice by this keyword? >>=20 >> Section 4.4., Page 9/10: >> The last paragraph on page and the first two on page 10, more >> specifically these parts: >>=20 >> Such an example already exists (but within the basic >> specification, rather >> than as an extension) in the use of LOST values in the = LINK_STATUS >> and OTHER_NEIGHB TLVs to report that an address is of a = router >> known >> not to be a neighbor. A future example might be to list an >> address >> to be added to a "blacklist" of addresses not to be used. >>=20 >> This example can be taken further. NHDP must also not = reject a >> HELLO >> message because it contains an unrecognized TLV. This also = applies >> to unrecognized TLV values, where a TLV supports only a = limited >> set >> of values. >>=20 >> were a bit hard to read for me. Imho, the example is very = specific and >> contains details which aren=E2=80=99t necessary to understand the = issue at hand >> (such as the fact that this extension is technically not a completely >> independent extension, or possible future other extensions). It took = me >> about 4 re-reads to really grasp what=E2=80=99s going on there... >>=20 >> Also, I would=E2=80=99ve expected the last paragraph of this = section to clearly >> state that relying on address order *will* break your messages if you = don=E2=80=99t >> have control over all 5444 builders that are used to implement your = protocol >> ever. >>=20 >> Section 4.5.: >> I'm assuming that this is the response to our (the AODVv2 Author = team >> and possibly others) complaints that RFC5444 lacks a clear "API" = which tells >> it what we can and cannot set manually in an RFC 5444 packet, and = that >> there's no (at the risk of sounding really pretentious now) "visual >> language" to describe the contents of a 5444 message and their = relationship >> to each other. To be honest, I'm a bit puzzled by this section.... = The >> mapping that is presented is a bit vague and introduced very = promptly. And >> while I strongly agree with the statement that writing down an actual = API is >> too language- and implementation-specific to belong in a document = like this, >> it would be really helpful to have a comprehensive "these are the = things >> that your protocol can set in a RFC5444 message. Your packet = builder/parser >> will figure out the rest." List in this section rather than some = examples. >> Along with this list, it would be great to have a clear specification = on how >> to specify which Addresses and TLVs a specific message has, and how = their >> relationship to each other are. (i.e. how to make clear which address = TLVs >> are associated with which addresses). I don=E2=80=99t care if this = ends up being a >> very visual approach (like the debugging output of Henning=E2=80=99s = oonf API [1]), >> or the tables that OLSRv2 uses, or something completely different, = but it >> would be helpful to be able to read and write messages down in a way = that is >> clear to everyone. >>=20 >> Section 4.6: >> =E2=80=9C[=E2=80=A6] and MUST NOT remove such TLVs or values=E2=80=9D= >> A question I=E2=80=99ve been wanting to ask for a while now: Does = this rule >> also apply for message regeneration? AODVv2 regenerates all messages = per >> hop. Should implementations keep track which unknown TLVs of a = message are >> associated with which addresses, and put them back in their place = when >> regenerating the message? >>=20 >> Section 6.1.: >> (I=E2=80=99m not terribly familiar with compression, so my = questions are >> probably very naive, but maybe they can help clear things up) >> Would this very straightforward to implement compression = algorithm >> still produce interoperable messages? The rest of the section reads = as if >> the =E2=80=9Ccompression algorithm=E2=80=9D mentioned in the = introduction is mainly a way to >> cleverly arrange addresses so that they are still understood by all = parsers, >> but take up a minimal amount of space. I think that=E2=80=99s a very = good tip in >> itself, but is that really all there is to compression? Would it make = sense >> to say =E2=80=9CHere=E2=80=99s how you should arrange addresses = cleverly, you can also >> implement a more elaborate compression algorithm, but that=E2=80=99s = out of the >> scope of this document=E2=80=9D? >> Also, any mention of the word =E2=80=9Cstraightforward=E2=80=9D makes = me very suspicious, >> but that might just be me. >>=20 >> Section 6.1.: >> =E2=80=9CRECOMMNDED=E2=80=9D in the first paragraph is missing an = E. >>=20 >> Regards, >> Lotte >>=20 >>=20 >> [1] Random one pulled out of my logfiles for illustration: >>=20 >> ,------------------ >> | PACKET >> |------------------ >> | * Packet version: 0 >> | * Packet flags: 0x0 >> | ,------------------- >> | | MESSAGE >> | |------------------- >> | | * Message type: 11 >> | | * Message flags: 0x40 >> | | * Address length: 16 >> | | * Hop limit: 20 >> | | ,------------------- >> | | | Address: fe80::ff:fe00:1719 >> | | | | - TLV >> | | | | Flags =3D 0x50 >> | | | | Type =3D 0 >> | | | | Value length: 2 >> | | | | 0000: 0100 >> | | `------------------- >> | | ,------------------- >> | | | Address: fe80::ff:fe00:16fe >> | | | | - TLV >> | | | | Flags =3D 0x50 >> | | | | Type =3D 1 >> | | | | Value length: 2 >> | | | | 0000: 0100 >> | | | | - TLV >> | | | | Flags =3D 0xd0 >> | | | | Type =3D 3; Type ext. =3D 3 >> | | | | Value length: 1 >> | | | | 0000: 00 >> | | `------------------- >> | `------------------- >> `------------------ >>=20 >>=20 >> Best regards >> Ulrich >>=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Date: May 28, 2015 at 11:12:35 GMT+3 >> To: "Christopher Dearlove" , "Henning = Rogge" >> , "Thomas Clausen" >> , "Henning Rogge" >> , "Ulrich Herberg" = , >> "Thomas H. Clausen" , "Christopher Dearlove" >> , "Ulrich Herberg" = >> Subject: New Version Notification for >> draft-clausen-manet-rfc5444-usage-00.txt >>=20 >>=20 >> A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt >> has been successfully submitted by Thomas Clausen and posted to the >> IETF repository. >>=20 >> Name: draft-clausen-manet-rfc5444-usage >> Revision: 00 >> Title: Rules For Designing Protocols Using the RFC5444 = Generalized >> Packet/ Message Format >> Document date: 2015-05-28 >> Group: Individual Submission >> Pages: 17 >> URL: >> = https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5444-usage-00.= txt >> Status: >> https://datatracker.ietf.org/doc/draft-clausen-manet-rfc5444-usage/ >> Htmlized: >> https://tools.ietf.org/html/draft-clausen-manet-rfc5444-usage-00 >>=20 >>=20 >> Abstract: >> This document updates the generalized MANET packet/message format, >> specified in RFC5444, by providing prescriptive guidelines for how >> protocols can use that packet/message format. In particular, these >> mandatory guidelines prohibit a number of uses of RFC5444 that have >> been suggested in various proposals, and which would have lead to >> interoperability problems, to impediment of protocol extension >> development, and to inability to use generic RFC5444 parsers. >>=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 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 --Apple-Mail=_4B3575C5-461F-47E8-87AD-B64E3C77D1DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Ulrich,

Am 11.10.2015 um 02:01 schrieb Ulrich Herberg = <ulrich@herberg.name>:

Dear = Lotte,

I apologize for the delay responding to your email. Life = always seems
to get in the way of IETF work... ;-) See = below:

No worries, thank you for the very = detailed and helpful response!



[...]

I'm = particularly interested in an answer to my earlier question concerning = section 4.6., i.e.: if a message needs to be regenerated to be = forwarded, and this message contains TLVs that the regenerating 5444 = parser/builder doesn't recognize, should it add the unknown TLVs to the = message (which would mean that =E2=80=9CMUST NOT remove suchTLVs or = values=E2=80=9D applies, which should imo be clarified in the draft) or = should the unknown TLVs be discarded (which would need clarification = too, imo)?


First of all, I think that = "regenerating" is the wrong word. That would
imply that you consume = the incoming message, erase it, allocate new
memory and create a new = message with the same content. While that is
certainly possible, it = does not seem a very good idea doing that; in
addition, it is also = counter-intuitive to understand. The idea of
RFC5444 is really:
- = packet: container for zero or more messages; travels exactly one
hop; = is not "owned" by any particular protocol; may contain TLVs = for,
e.g., security credentials
- message: owned by a particular = protocol; travels multiple hops
(end-to-end), contains information = about the message itself (message
TLV), as well as a list of = addresses with associated information
(address block TLV)

In = my implementation of RFC5444 (actually, I built multiple, since I
was = changing employer at some point and didn't have the IP to reuse
the = code), I would have a general RFC5444 generator and parser that
can = communicate via an API with one more protocols (e.g., = NHDP).
Protocols would register themselves with the parser, and so = when the
parser receives an incoming packet, it checks for each = contained
message if the message type is "owned" by one of the = protocols. If
not, the message is discarded. If it is, then parse the = message to
interpret the information and hand up to the protocol (but = keep the
actual byte array). The protocol can then do whatever it = likes to do
with the message, including dropping, consuming or = forwarding. In that
process, the byte array may be modified (but = again, not regenerated,
since that would be very inefficient). After = the protocol is done
modifying the message, it hands the message back = down to the RFC5444
generator/parser, which in turn forwards it to = the specified
(multicast) IP = address.

=F0=9F=92=A1 That makes = much more sense... For some reason I'd just assumed that
manipulating = any part of a message other than the header was illegal,
thank you = for clearing that up!


One more = important argument why "regenerate" is not a good word (IMO) is
that = it could imply that end-to-end securing a message (e.g., with = RFC7182)
is not possible. In order to allow to use digital signatures = to verify integrity
of a message multiple hops away, it must not be = modified along the path
towards its destination (that is modulo = fields such as hop-count/limit,
which can be set to 0, as done for = example in OLSRv2). If a router regenerates
a message this would for = example imply that it could change order of TLVs.
However, that would = break such a security mechanism.



Now, regarding dropping = the TLVs, the process is similar to the way
the protocols register = with the RFC5444 module; the protocol will have
a list of "known" = TLVs that it recognizes. Additional TLVs that it
does not know about = will be ignored (but not dropped). Other
extensions may be able to = parse the information of these TLVs. Also,
in terms of end-to-end = integrity protection, it is evident that we
cannot drop these TLVs = without breaking said protection.

I re-read the section 4.6, and = I think the paragraph is concise and
specifies exactly what I wrote = above (a little less verbose and using
different = words).


Agreed.


One other thing that I wanted to mention, since I = used the word "API"
in the above description: I remember that there = were some requests to
have an "API" document for RFC5444. This is = clearly not the intention
of the RFC5444-usage document, and it would = be outside of IETF scope
(as well as a bad idea, in my personal = opinion). The API I mentioned
above in my implementation was written = in Java and had a particular
signature. Writing that down in a = document would be unhelpful for,
say, Thomas' COBOL60 implementation. = He may have completely different
constraints of the language as well = as way of calling the API. Also,
since the bytes sent between these = two software modules do not go over
the network, there are no = interoperability problems (which is the
whole point of having the = IETF), and it unnecessarily constrain
vendors in designing efficient = APIs.

I'm afraid my use of the term = "API" was a poor choice of words... As I've
said in my initial E-Mail = and in Prague, I really didn't mean to say "tell
me which functions I = can implement/rely on being implemented, and which
signatures they = have". I agree that that request would be silly in
many ways.
What = I meant by my request was that, when working on the packet format = for
AODVv2, we had a very specific perspective: we needed to tell = people who
want to implement AODVv2 what to put in their packets = *without getting
into too much detail about what happens under the = bonnet in the RFC5444
generator/parser*, since that is RFC5444's = realm, and not AODVv2's.

In other words, = if someone with a working RFC5444 generator/parser (that they
didn't = implement themselves) and a rough understanding of RFC5444 wants
to = implement AODVv2, they need to know which Addresses and TLVs to = feed
their generator/parser, and which header fields to set, but they = really
don't need to care about header flags and multi-value TLVs and = all the
nifty tricks that their RFC5444 generator/parser does = internally.

It was really hard to write this down in the = draft, because after careful
inspection of the RFC, all of us had a = different idea of which bits our
potential implementor has to care = about and which are handled by the
generator/parser and thus don't = have to (or can't) be specified manually
by the protocol. If we had = had a list of things that we, as protocol authors,
were allowed to = tell other people to set, that would've been very very
helpful and = saved us a lot of time. Again, I'm not asking for this this list = to
be in code form. It could for example be something along the lines = of:


   Protocols using = RFC5444 MAY define the following 
   properties of a RFC5444 = message.

       <msg-hea= der>    :=3D = <msg-type>
         =             &n= bsp;    <msg-orig-addr>?
   &n= bsp;           &nbs= p;          <msg-hop-= limit>?
          =             &n= bsp;   <msg-hop-count>?
    &n= bsp;           &nbs= p;         <msg-seq-num>= ;?
       <tlv> =           :=3D = <tlv-type>
         =             &n= bsp;    <tlv-type-ext>
   &nbs= p;            =           (<length>= ;<value>?)?
       <address= -block> :=3D = <mid>*
         &nbs= p;            =     <prefix-length>*

   All other values and properties are = to be set by the 
  =  RFC5444 generator/parser handling the message, = and 
   SHOULD = NOT be tampered with by any protocol = handling
      the = message.


Now, I'm sure there are many ways to do this more = elegantly[1], but maybe
this sketch helps to illustrate what I'm = trying to say...

Best Regards,
Lotte


[1] And = correctly. At the very least, my address block sketch is a = bit...
dodgy. But you get the idea.


Best regards
Ulrich

On Tue, Oct 6, 2015 at = 11:15 AM, Lotte Steenbrink
<lotte.steenbrink@fu-berlin.d= e> wrote:
Hi all,
I realize = vacation season and/or other circumstances have slowed most of = us
down at one point or another, but I was wondering if one of the = authors
could give us a very brief update on how the work on this = draft is doing?

I'm particularly interested in an answer to my = earlier question concerning
section 4.6., i.e.: if a message needs to = be regenerated to be forwarded,
and this message contains TLVs that = the regenerating 5444 parser/builder
doesn't recognize, should it add = the unknown TLVs to the message (which
would mean that =E2=80=9CMUST = NOT remove suchTLVs or values=E2=80=9D applies, which should
imo be = clarified in the draft) or should the unknown TLVs be = discarded
(which would need clarification too, imo)?

If the = answer is =E2=80=9Cwe're working on it, hold on for a few more days=E2=80=9D= , that's
completely fine, I'd just like to know if/when I can find = out how to do this
correctly. :)

Regards,
Lotte

Am = 09.06.2015 um 16:26 schrieb Lotte Steenbrink
<lotte.steenbrink@fu-berlin.d= e>:

Hi Ulrich, Thomas, Chris and Henning,

Am = 31.05.2015 um 13:33 schrieb Ulrich Herberg <ulrich@herberg.name>:

As= we announced previously, we have been working on a document = specifying
rules for how to use RFC5444 in MANET protocols. Well, = here it is (at least
in a -00 version).
We'd appreciate reviews = and will soon ask for WG adoption.


first of all, thank you so = much for publishing this much-needed draft. I'm
also in favor of WG = adoption. While reading through the document, I wrote
down some = nitpicks and suggestions that I'd like to share.
(Just in case my = writing sounds harsh, I fear that's due to
language/cultural = differences. I'm really happy about this document and
would like to = see it flourish.)

=3D=3D General notes =3D=3D
- If I didn=E2=80=99= t misunderstand it, the document addresses two groups of = people:
Those who want to design RFC5444 messages for their protocol, = and those wo
want to implement a RCF 5444 builder/parser. Imo, The = former group needs
more of an outside view (i.e. what can/should I = put where), while the latter
needs the inside view (i.e. how do I = arrange and process everything
efficiently). To my mind, these are = two very different goals, but while
reading the document, it wasn=E2=80= =99t always instantly clear to me which bit
addresses which group=E2=80= =A6 I realize the two can=E2=80=99t always be separated
completely, = but would it be possible to make it more clear which group = is
addressed currently? Maybe the document could be organized into = two big
sections (one for each group), or there could be a recurring = pattern of
=E2=80=9Cfirst outside then inside view=E2=80=9D for each = (sub)section?

- A lot of the examples are very = NHDP/OLSR-specific. While I think it=E2=80=99s
great to have pointers = to where a certain technique has already been used,
from an = outsider=E2=80=99s perspective, the examples don=E2=80=99t always help = me understand
the technique that=E2=80=99s being illustrated, since I = have to familiarize myself
with the details referenced first=E2=80=A6 = I=E2=80=99m wondering if it would be possible to
keep the examples = which illustrate a point more generic, and then briefly
point to = existing instances of this situation in case the reader wants = to
follow up on that?

=3D=3D Section by section =3D=3D
Sectio= n 1.2., Page 4:
    =E2=80=9CA packet is = designed to as travel [=E2=80=A6]=E2=80=9D I think the =E2=80=9Cas=E2=80=9D= doesn=E2=80=99t belong
here.

Section 4.2., Page 8:
=     =E2=80=9COutgoing messages MAY be created by = owning protocol=E2=80=9D I think there=E2=80=99s a
=E2=80=9Cthe=E2=80=9D= missing.

Section 4.3., Page 8:
    If I = understand it correctly, the last paragraph on this page is
talking = about multi-value TLVs without actually saying =E2=80=9Cmulti-value = TLV=E2=80=9D.
Maybe that could be stated explicitly for clarity and = in case somebody=E2=80=99s
searching for advice by this = keyword?

Section 4.4., Page 9/10:
    The = last paragraph on page and the first two on page 10, = more
specifically these parts:

=          Such an example = already exists (but within the basic
specification, rather
=          than as an = extension) in the use of LOST values in the LINK_STATUS
=          and OTHER_NEIGHB = TLVs to report that an address is of a router
known
=          not to be a = neighbor.  A future example might be to list an
address
=          to be added to a = "blacklist" of addresses not to be used.

=          This example can = be taken further.  NHDP must also not reject a
HELLO
=          message because it = contains an unrecognized TLV. This also applies
=          to unrecognized = TLV values, where a TLV supports only a limited
set
=          of values.

=     were a bit hard to read for me. Imho, the = example is very specific and
contains details which aren=E2=80=99t = necessary to understand the issue at hand
(such as the fact that this = extension is technically not a completely
independent extension, or = possible future other extensions). It took me
about 4 re-reads to = really grasp what=E2=80=99s going on there...

=     Also, I would=E2=80=99ve expected the last = paragraph of this section to clearly
state that relying on address = order *will* break your messages if you don=E2=80=99t
have control = over all 5444 builders that are used to implement your = protocol
ever.

Section 4.5.:
    I'm = assuming that this is the response to our (the AODVv2 Author team
and = possibly others) complaints that RFC5444 lacks a clear "API" which = tells
it what we can and cannot set manually in an RFC 5444 packet, = and that
there's no (at the risk of sounding really pretentious now) = "visual
language" to describe the contents of a 5444 message and = their relationship
to each other. To be honest, I'm a bit puzzled by = this section.... The
mapping that is presented is a bit vague and = introduced very promptly. And
while I strongly agree with the = statement that writing down an actual API is
too language- and = implementation-specific to belong in a document like this,
it would = be really helpful to have a comprehensive "these are the things
that = your protocol can set in a RFC5444 message. Your packet = builder/parser
will figure out the rest." List in this section rather = than some examples.
Along with this list, it would be great to have a = clear specification on how
to specify which Addresses and TLVs a = specific message has, and how their
relationship to each other are. = (i.e. how to make clear which address TLVs
are associated with which = addresses). I don=E2=80=99t care if this ends up being a
very visual = approach (like the debugging output of Henning=E2=80=99s oonf API = [1]),
or the tables that OLSRv2 uses, or something completely = different, but it
would be helpful to be able to read and write = messages down in a way that is
clear to everyone.

Section = 4.6:
    =E2=80=9C[=E2=80=A6] and MUST NOT = remove such TLVs or values=E2=80=9D
    A = question I=E2=80=99ve been wanting to ask for a while now: Does this = rule
also apply for message regeneration? AODVv2 regenerates all = messages per
hop. Should implementations keep track which unknown = TLVs of a message are
associated with which addresses, and put them = back in their place when
regenerating the message?

Section = 6.1.:
    (I=E2=80=99m not terribly familiar = with compression, so my questions are
probably very naive, but maybe = they can help clear things up)
    Would this = very straightforward to implement compression algorithm
still produce = interoperable messages? The rest of the section reads as if
the = =E2=80=9Ccompression algorithm=E2=80=9D mentioned in the introduction is = mainly a way to
cleverly arrange addresses so that they are still = understood by all parsers,
but take up a minimal amount of space. I = think that=E2=80=99s a very good tip in
itself, but is that really = all there is to compression? Would it make sense
to say =E2=80=9CHere=E2= =80=99s how you should arrange addresses cleverly, you can = also
implement a more elaborate compression algorithm, but that=E2=80=99= s out of the
scope of this document=E2=80=9D?
Also, any mention of = the word =E2=80=9Cstraightforward=E2=80=9D makes me very = suspicious,
but that might just be me.

Section 6.1.:
=     =E2=80=9CRECOMMNDED=E2=80=9D in the first = paragraph is missing an E.

Regards,
Lotte


[1] = Random one pulled out of my logfiles for illustration:

=     ,------------------
=     |  PACKET
=     |------------------
=     | * Packet version:    0
=     | * Packet flags: =      0x0
    | =    ,-------------------
    | =    |  MESSAGE
    | =    |-------------------
    | =    | * Message type: =       11
    | =    | * Message flags: =      0x40
    | =    | * Address length:     16
=     |    | * Hop limit: =          20
=     |    | =    ,-------------------
    | =    |    |  Address: = fe80::ff:fe00:1719
    |    | =    |    | - TLV
=     |    |    | =    |     Flags =3D 0x50
=     |    |    | =    |     Type =3D 0
=     |    |    | =    |     Value length: 2
=     |    |    | =    |       0000: 0100
=     |    | =    `-------------------
    | =    |    ,-------------------
=     |    |    | =  Address: fe80::ff:fe00:16fe
    | =    |    |    | - TLV
=     |    |    | =    |     Flags =3D 0x50
=     |    |    | =    |     Type =3D 1
=     |    |    | =    |     Value length: 2
=     |    |    | =    |       0000: 0100
=     |    |    | =    | - TLV
    | =    |    |    | =     Flags =3D 0xd0
    | =    |    |    | =     Type =3D 3; Type ext. =3D 3
=     |    |    | =    |     Value length: 1
=     |    |    | =    |       0000: 00
=     |    | =    `-------------------
    | =    `-------------------
=     `------------------


Best = regards
Ulrich

Begin forwarded message:

From: internet-drafts@ietf.org
D= ate: May 28, 2015 at 11:12:35 GMT+3
To: "Christopher Dearlove" <chris.dearlove@baesystems.co= m>, "Henning Rogge"
<henning.rogge@fkie.fraunh= ofer.de>, "Thomas Clausen"
<t.clausen@computer.org>, = "Henning Rogge"
<henning.rogge@fkie.fraunh= ofer.de>, "Ulrich Herberg" <ulrich@herberg.name>,
"Thoma= s H. Clausen" <T.Clausen@computer.org>, = "Christopher Dearlove"
<chris.dearlove@baesystems.co= m>, "Ulrich Herberg" <ulrich@herberg.name>
Subject= : New Version Notification = for
draft-clausen-manet-rfc5444-usage-00.txt


A new version = of I-D, draft-clausen-manet-rfc5444-usage-00.txt
has been = successfully submitted by Thomas Clausen and posted to the
IETF = repository.

Name: =        draft-clausen-manet-rfc5444-usag= e
Revision:    00
Title: =        Rules For Designing Protocols = Using the RFC5444 Generalized
Packet/ Message Format
Document = date:    2015-05-28
Group: =        Individual = Submission
Pages: =        17
URL:
https://www.ietf.org/internet-drafts/draft-clausen-manet-rfc5= 444-usage-00.txt
Status:
https://datatracker.ietf.org/doc/draft-= clausen-manet-rfc5444-usage/
Htmlized:
https://tools.ietf.org/html/d= raft-clausen-manet-rfc5444-usage-00


Abstract:
 This = document updates the generalized MANET packet/message format,
=  specified in RFC5444, by providing prescriptive guidelines for = how
 protocols can use that packet/message format.  In = particular, these
 mandatory guidelines prohibit a number of = uses of RFC5444 that have
 been suggested in various proposals, = and which would have lead to
 interoperability problems, to = impediment of protocol extension
 development, and to inability = to use generic RFC5444 parsers.




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

_______________________________________________
mane= t mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
<= br>

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

= --Apple-Mail=_4B3575C5-461F-47E8-87AD-B64E3C77D1DB-- From nobody Tue Oct 13 00:51:27 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A886D1B3A9E; Tue, 13 Oct 2015 00:51:24 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW0RlelCOlKJ; Tue, 13 Oct 2015 00:51:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3DD1B3A88; Tue, 13 Oct 2015 00:51:20 -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.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151013075120.3815.94362.idtracker@ietfa.amsl.com> Date: Tue, 13 Oct 2015 00:51:20 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 07:51:24 -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 Working Group of the IETF. Title : Ad Hoc On-demand Distance Vector Routing Version 2 (AODVv2) Authors : Charles E. Perkins Stan Ratliff John Dowdell Lotte Steenbrink Victoria Mercieca Filename : draft-ietf-manet-aodvv2-12.txt Pages : 105 Date : 2015-10-13 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, offering rapid convergence in dynamic topologies. 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-12 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 ie2016.workshops@gmail.com Tue Oct 13 06:53:15 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6E1B3FCD for ; Tue, 13 Oct 2015 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=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 Mx_Y7o35_Ziw for ; Tue, 13 Oct 2015 06:53:13 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002: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 B45681B3FCC for ; Tue, 13 Oct 2015 06:53:12 -0700 (PDT) Received: by ykoo7 with SMTP id o7so16872305yko.0 for ; Tue, 13 Oct 2015 06:53:12 -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:content-type; bh=8A9Zy6BVyL8PiKeZgebOGCjB+3jsGQw+eRFjPitsUpc=; b=mn6sZmv/8j1KNXNWMopZ90lMBxeUYvNvQZrD8NIGGafCGaC52wqJ5RCVodv+THKQg5 ecQP49J/y3zRz0QLOd4islWcxhCMBskXqEYVShKBquSn/9zcnZLvq0CcBdYlVMJXdIW5 ZMiLiwwfARoK81FULXR02SGUGVMPlePpUBMs6GsOQzXU8hGI9vvHnpm7JAX0RoNSEVXh mY1rFuedU7v8lGC1GIRddFEI8cTgGNflG3uOWiF/xq+H3/FB6nB/ynAE+btSZqi9TF6M xs/VFol6UKdPcP7naRcNHdl8jp7XnR+X4zr1Q+Y+BAyhSdHZ6664wKyxS3XZoYyVfm0Z w4tQ== MIME-Version: 1.0 X-Received: by 10.129.92.138 with SMTP id q132mr1658753ywb.307.1444744391989; Tue, 13 Oct 2015 06:53:11 -0700 (PDT) Received: by 10.37.24.214 with HTTP; Tue, 13 Oct 2015 06:53:11 -0700 (PDT) Date: Tue, 13 Oct 2015 14:53:11 +0100 Message-ID: From: IE2016 Workshops To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a114d802446a3270521fcc4a1 Archived-At: Subject: [manet] IE'16 - Call for Workshop Proposals X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:03:17 -0000 --001a114d802446a3270521fcc4a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Apologies for multiple postings] * * * * * * * * * * * * * * * * * * * * * * * * * * * * Call for Workshop Proposals 12th International Conference on Intelligent Environments (IE=E2=80=9916) 12-16 of September 2016, London - UK http://www.intenv.org/ Intelligent Environments (IEs) refer to physical spaces in which IT and other pervasive computing technology are woven and used to achieve specific goals for the user, the environment or both. IEs have the ultimate objective of enriching user experience, better manage, and increase user awareness of that environment. The 12th International Conference on Intelligent Environments (IE=E2=80=9916) will be held in London, U.K., one = of the most influential cities in the modern world, with a rich range of cultural offerings to visitors. The beginning of the conference will be preceded by a series of workshops on topics related to the main conference. The workshop program will be co-located and run in parallel with the tutorials programme. The workshops at IE=C2=B416 will be a very useful tool in order to compleme= nt the regular program with new or emerging topics of particular interest in the field of Intelligent Environments and related areas. Workshops that emphasize multi-disciplinary and transversal aspects, as well as cutting-edge topics, are especially encouraged and welcome. Workshop Acceptance Rules: The decision on which proposed workshops get accepted will be carried-out through a two-stage process. Initially some of the workshops proposed will be short-listed, based on the quality of the proposal and the relevance of the topics covered. These workshops will later be confirmed at the Final Selection Stage (see section =E2=80=9CImpor= tant Dates=E2=80=9D) if they have successfully attracted a sufficient number of submissions and registrations. These workshops can last for a half day, a whole day or (in exceptional cases) for a one and a half days. Financial Support: some degree of financial support will be given to the workshop organizers. That will be related to the success of the workshop. Each workshop proposal should contain the following information: workshop title, a description of the specific scientific/technical scope of the workshop, a list of topics of interest, the reasons why the workshop should be held within IE=C2=B416, details of all the members of the Organizing Committee (OC), relevant experience of the organizers, identification of the member of the OC who is the contact person, the list of members of Workshop Program Committee, a preliminary version of the Call for Papers, the proposed structure of the workshop and planned forms of publicity. Proceedings: Proceedings: all papers accepted in the Workshops program will be published as a volume of the Ambient Intelligence and Smart Environments Series by IOS Press, and made electronically available through ACM Digital Library. These Proceedings will be submitted for indexation by the Conference Proceedings Citation Index from Thomson Reuters (CPSI-S). Please take into account the following workshops when submitting your proposal: . SOFIEE - Symposium on Future Intelligent Educational Environments and Learning . WoRIE - Workshop on the Reliability of Intelligent Environments . SOOW - International Workshop on Smart Offices and Other Workplaces Workshops Chairs Paulo Novais (University of Minho, Portugal) Shin'ichi Konomi (University of Tokyo, Japan) General Chairs Juan Carlos Augusto (Middlesex University, UK) Gordon Hunter (Kingston University, London, UK) Important Dates: Receipt of workshop proposals: 1st December 2015 Informing proposers of selected workshops: 10th December 2015. Workshop Chairs to receive papers from authors: 16th May 2016. Workshop days: 12th-13th of September, 2016. For further enquiries and submission of proposals contact: wc@intenv.org --001a114d802446a3270521fcc4a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

[Apologies for multiple postings]

=C2=A0

* * * * * * * * * * * * * * * * * * * * * * * * * * * *


Call for Workshop Proposals

12th International Conference on Intelligent Environments (IE=E2=80=9916)= =C2=A0
12-16 of September 2016, London - UK
http://www.intenv.org/


Intelligent Environments (IEs) refer to physical spaces in which IT and oth= er pervasive computing technology are woven and used to achieve specific goals= for the user, the environment or both. IEs have the ultimate objective of enric= hing user experience, better manage, and increase user awareness of that environment. The 12th International Conference on Intelligent Environments (IE=E2=80=9916) will be held in London, U.K., one of the most influential c= ities in the modern world, with a rich range of cultural offerings to visitors. The beginning of the conference will be preceded by a series of workshops on to= pics related to the main conference.=C2=A0 The workshop program will be co-locat= ed and run in parallel with the tutorials programme.

The workshops at IE=C2=B416 will be a very useful tool in order to compleme= nt the regular program with new or emerging topics of particular interest in the f= ield of Intelligent Environments and related areas. Workshops that emphasize multi-disciplinary and transversal aspects, as well as cutting-edge topics,= are especially encouraged and welcome.

Workshop Acceptance Rules: The decision on which proposed workshops get accepted will be carried-out through a two-stage process.=C2=A0 Initially s= ome of the workshops proposed will be short-listed, based on the quality of the proposal and the relevance of the topics covered.=C2=A0 These workshops wil= l later be confirmed at the Final Selection Stage (see section =E2=80=9CImpor= tant Dates=E2=80=9D) if they have successfully attracted a sufficient number of submissions and registrations. These workshops can last for a half day, a whole day or (in exceptional cases) for a one and a half days.

Financial Support: some degree of financial support will be given to the workshop organizers. That will be related to the success of the workshop. =C2=A0
Each workshop proposal should contain the following information: workshop title, a description of the specific scientific/technical scope of the workshop, a list of topics of interest, the reasons why the workshop should= be held within IE=C2=B416, details of all the members of the Organizing Commit= tee (OC), relevant experience of the organizers, identification of the member of the = OC who is the contact person, the list of members of Workshop Program Committe= e, a preliminary version of the Call for Papers, the proposed structure of the workshop and planned forms of publicity.

Proceedings: Proceedings: all papers accepted in the Workshops program will= be published as a volume of the Ambient Intelligence and Smart Environments Se= ries by IOS Press, and made electronically available through ACM Digital Library.=C2=A0 These Proceedings will be submitted for indexation by the Conference Proceedings Citation Index from Thomson Reuters (CPSI-S).

Please take into account the following workshops when submitting your propo= sal:

. SOFIEE - Symposium on Future Intelligent Educational Environments and Learning
. WoRIE - Workshop on the Reliability of Intelligent Environments
. SOOW - International Workshop on Smart Offices and Other Workplaces

Workshops Chairs
Paulo Novais (University of Minho, Portugal)
Shin'ichi Konomi (University of Tokyo, Japan)

General Chairs
Juan Carlos Augusto=C2=A0 (Middlesex University, UK)
Gordon Hunter (Kingston University, London, UK)


Important Dates:
Receipt of workshop proposals: 1st December 2015
Informing proposers of selected workshops: 10th December 2015.
Workshop Chairs to receive papers from authors: 16th May 2016.
Workshop days: 12th-13th of September, 2016.


For further=C2=A0 enquiries and submission of proposals contact:=C2=A0
wc@intenv.org

--001a114d802446a3270521fcc4a1-- From nobody Tue Oct 13 07:42:42 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0081B44C1 for ; Tue, 13 Oct 2015 07:42:40 -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, 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, SPF_PASS=-0.001] autolearn=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 TqndyXuXYdP6 for ; Tue, 13 Oct 2015 07:42:39 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 1CB231B44C0 for ; Tue, 13 Oct 2015 07:42:39 -0700 (PDT) Received: by lbwr8 with SMTP id r8so22841335lbw.2 for ; Tue, 13 Oct 2015 07:42:37 -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:content-type; bh=TgsttH0KNQvD9dTaVHOM8nacgATKsWVfJVhagjngM6Y=; b=BYpDL19hMt5DeFACFAEx+kJHAKupQNO/Ayr78/sq1zqmzWQ7rfzZp19ZwK4aAAGs+G j72Bc7ZH3EZIl9lWAcehicvxiQILDpXoIzGvNq6YlfTa1ocvtuZjkyw6tzlBKS+OgQQ0 DhadvNSWFg9vSr5UnZYZFnXrQPiu1xi7WzvC2tFeLn23e0GkQrVBcoY07r9WeF6qk4K7 Kgk9byAjUokpZbcN32rx9lfIjyiHqNLq0IqRF6iJqJ4kRnzV1eGLw/xJoJpFadF6jT70 oVuhG45pZz/FzGtqo9WAQq19FuAiK+ikz1L4IcbiCiEeGkPxGBvn0c5mbkOhQ/FyxmSd mcHw== MIME-Version: 1.0 X-Received: by 10.25.26.71 with SMTP id a68mr9997489lfa.109.1444747356876; Tue, 13 Oct 2015 07:42:36 -0700 (PDT) Received: by 10.112.200.201 with HTTP; Tue, 13 Oct 2015 07:42:36 -0700 (PDT) Date: Tue, 13 Oct 2015 15:42:36 +0100 Message-ID: From: Victoria Mercieca To: manet Content-Type: multipart/alternative; boundary=001a11403a04ff37820521fd7418 Archived-At: Subject: [manet] AODVv2 Draft 12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 14:42:40 -0000 --001a11403a04ff37820521fd7418 Content-Type: text/plain; charset=UTF-8 Hello all, Today we released the new version of AODVv2. Here is a summary of the main changes, based on the Discussion Points I raised previously: Lists or Sets We have explained the reasoning behind using lists for the AODVv2 representation but it should be clear that we require no dependence on position from the RFC 5444 representation. Router Client We have updated the definitions to try to avoid any confusion. We did not think Local Attached Network Set was the right term for AODVv2 and have for the moment, retained Router Client. Adjacency and Neighbor We have updated the text to try to avoid more confusion. Using Multiple Sequence Numbers Allowing one sequence number per router to simplify. Multiple IP addresses, and Same IP Address on Different Interfaces Summarized in previous email. Hosts cant use same IP address on multiple interfaces (ie with multiple routers having that IP address as a router client). Routers can use same IP address on multiple interfaces. Hosts and routers can all have multiple IP addresses per interface. AODVv2 wont realise they are the same interface, or even the same device. Forwarding plane interaction We have written a section to show which signals are required between AODVv2 and the forwarding plane. AODVv2 Routing Set / FIB AODVv2 refers to "valid routes" which can be used for forwarding, and these should be inserted into the RIB. When AODVv2 refers to "the routing table" it includes the collection of all routes learned by AODVv2. This does not HAVE to be separate to the RIB but if an implementation wishes to store the AODVv2 routing information separately, then it should transfer "valid" routes to the RIB based on the signals given in the "forwarding plane interaction" section. However, the update for separating AODVv2 routing information from the RIB is likely to be soon. Applicability statement Has been updated in many areas. Directional metrics, asymmetric links We've decided to limit to directional (symmetric) metrics at this stage. This should now be clear in the draft. New metric types We've updated the Metrics section to be more generic, to deal with cost metrics. We've clearly identified what is necessary to introduce a new metric type. MAX_TIME and route timeouts We changed MAX_TIME to INFINITY_TIME and updated the text to avoid confusion. We hope you get a chance to read it soon, and we invite your comments and feedback. Kind regards, Victoria. --001a11403a04ff37820521fd7418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

Today we relea= sed the new version of AODVv2. Here is a summary of the main changes, based= on the Discussion Points I raised previously:

Lists or Sets
We h= ave explained the reasoning behind using lists for=20 the AODVv2 representation but it should be clear that we require no=20 dependence on position from the RFC 5444 representation.

Router Clie= nt
We have updated the definitions to try to avoid any confusion. We did not=20 think Local Attached Network Set was the right term for AODVv2 and have=20 for the moment, retained Router Client.

Adjacency and Neighbor
We= have updated the text to try to avoid more confusion.

Using Multipl= e Sequence Numbers
Allowing one sequence number per router to simplify.<= br>
Multiple IP addresses, and Same IP Address on Different InterfacesSummarized in previous email. Hosts cant use same IP address on multiple=20 interfaces (ie with multiple routers having that IP address as a router=20 client). Routers can use same IP address on multiple interfaces. Hosts=20 and routers can all have multiple IP addresses per interface. AODVv2=20 wont realise they are the same interface, or even the same device.

F= orwarding plane interaction
We have written a section to show which sign= als are required between AODVv2 and the forwarding plane.

AODVv2 Rou= ting Set / FIB
AODVv2 refers to "valid routes" which can be used for forwarding, and t= hese=20 should be inserted into the RIB. When AODVv2 refers to "the routing=20 table" it includes the collection of all routes learned by AODVv2. Thi= s=20 does not HAVE to be separate to the RIB but if an implementation wishes=20 to store the AODVv2 routing information separately, then it should=20 transfer "valid" routes to the RIB based on the signals given in = the=20 "forwarding plane interaction" section.
However, the update fo= r separating AODVv2 routing information from the RIB is likely to be soon.<= br>
Applicability statement
Has been updated in many areas.

Di= rectional metrics, asymmetric links
We've decided to limit to direct= ional (symmetric) metrics at this stage. This should now be clear in the dr= aft.

New metric types
We've updated the Metrics section to be more generic, to deal with cost=20 metrics. We've clearly identified what is necessary to introduce a new = metric type.

MAX_TIME and route timeouts
We changed MAX_TIME to = INFINITY_TIME and updated the text to avoid confusion.

We hope= you get a chance to read it soon, and we invite your comments and feedback= .

Kind regards,
Victoria.
--001a11403a04ff37820521fd7418-- From nobody Tue Oct 13 15:19:02 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C051C1A90A9 for ; Tue, 13 Oct 2015 15:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8uA0V66nr2UF for ; Tue, 13 Oct 2015 15:18:57 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 43D8D1A90A2 for ; Tue, 13 Oct 2015 15:18:57 -0700 (PDT) Received: by wicge5 with SMTP id ge5so212204911wic.0 for ; Tue, 13 Oct 2015 15:18: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:content-type; bh=scOziXyvZjgy3YtBrD0iHzgJ7236g2Pp0WN6q7PYMgg=; b=jvsiOpPx3M23h0+1TslagzlYPrAmy59MOoQ96P7RaTQzgjATDHL/zWYbcluEHPxN2a lb7vr0OwbqaKjQV03R3d5sySq+om5hFPfmXtBAECgx4ch92qJn2zSeZ1cpav9gNDmewC YlKjGI6dZTvuppJmRsKIwOfPJqA8tCEBBy1b7wwWEtuIrCKPZWFmr9I4hL7qm59E+lS0 yf0G150IBVfxePsCxB90Qziy62xVSSRZ/P4zBl488xd9PqvgkoFc/TbAjBLhrJ2szqdF Yx2ELEJa5z01oKdfjjISex07xrQjUbTNREXUgQ3IA7Or7lbsrGsO97q1AE4vf1O6Gm3N jbHw== MIME-Version: 1.0 X-Received: by 10.180.76.177 with SMTP id l17mr384005wiw.16.1444774735863; Tue, 13 Oct 2015 15:18:55 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.43.7 with HTTP; Tue, 13 Oct 2015 15:18:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Oct 2015 00:18:55 +0200 X-Google-Sender-Auth: K9i8nbFPN9hgixvHBMNFoSD15hQ Message-ID: From: Jiazi YI To: MANET IETF Content-Type: multipart/alternative; boundary=f46d0438937be965d7052203d4fd Archived-At: Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 22:18:58 -0000 --f46d0438937be965d7052203d4fd Content-Type: text/plain; charset=UTF-8 Dear all, As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 ( https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) will be closed on Oct. 16. Your comments on the document will be highly appreciated :) cheers Jiazi On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff wrote: > Hello WG participants, > > The above referenced draft seems to have addressed all of the outstanding > WG comments to date. Therefore, it's time for a Working Group Last Call > (WGLC) on this document. The WGLC period will close on October 16. Please > read and review the document, and provide comments, prior to that time if > possible. > > Regards, > Stan > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --f46d0438937be965d7052203d4fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

As a reminder, the WGLC= of=C2=A0draft-ietf-manet-olsrv2-multipath-06 (https://datatracker.iet= f.org/doc/draft-ietf-manet-olsrv2-multipath/) will be closed on Oct. 16= .=C2=A0

Your comments on the document will be high= ly appreciated :)

cheers

= Jiazi

= On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:

--f46d0438937be965d7052203d4fd-- From nobody Wed Oct 14 10:12:57 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE41ACED3 for ; Wed, 14 Oct 2015 10:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 bRjY-x51nENw for ; Wed, 14 Oct 2015 10:12:54 -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 F25311A88E8 for ; Wed, 14 Oct 2015 10:12:53 -0700 (PDT) Received: by vkat63 with SMTP id t63so33800971vka.1 for ; Wed, 14 Oct 2015 10:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2l7cVZuccf/w8jcFy8dozeViP6hF5SgV8OaLHLB5kU4=; b=piOI4Du/HvtyEK0t6i/N27dfRkNBwrLN/3Z0QfkQCx32aL7f9sfamoECo1urHyyknd WIcLZtyD3BoOV1jI3iX523CWRB0CMfvKI5rSjoWb+wetXZkQZDlSO53F6szKFHrpJ96u UA2/jl5A/rKmFidiqip8vrFgbLm0+5AIXDWik= 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-type; bh=2l7cVZuccf/w8jcFy8dozeViP6hF5SgV8OaLHLB5kU4=; b=bME8Gg6zAjpqRFwB6vn4PGh689MlSEG5sa5i062B9IChG0R4PAWM1yWqcgwZ/yMvzm g0CzpljktM2Hbelm/JsSCeoplv6fTAzI/Hp4jG3p49i5RCIlZWiLOPJ6G9e97kJ3mTZo G7JXcL43I/oR8P9AnUTwHfcoDifWNLZyiGXXjRVeWKrGKvuEJgNZrIXlK2qs2n4imW0B e2TS+rtXMEvQE20stxxvfumfW9DOHLkp4HaATKx0fQF0iLYuKMPzfTt0LoOiSfntJLkX EB1367IQU6/v/I3oOXRF6Dl/g3+GBaUA8TbawNgSLr6MKSeuszitFcMirsg8DGzfubQg 3vnA== X-Gm-Message-State: ALoCoQnuTPvEZxlQn4r6eEHhLdPRaA9/lwO0xtpeoid4f0CraKw3jbHs2pJ13Y8RgUklrirFfDg8 MIME-Version: 1.0 X-Received: by 10.31.179.83 with SMTP id c80mr2536665vkf.68.1444842772429; Wed, 14 Oct 2015 10:12:52 -0700 (PDT) Received: by 10.31.96.85 with HTTP; Wed, 14 Oct 2015 10:12:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Oct 2015 10:12:52 -0700 Message-ID: From: Ulrich Herberg To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 17:12:56 -0000 Jiazi, thanks for the reminder. I read the draft and have a few comments and questions. Overall, I think that the draft is well written, but lacks some details that would have to be specified before I'd feel comfortable implementing this in an interoperable fashion. - section 5.1. (router parameters). o NUMBER_OF_PATHS: Is this a constant? Can it change during router operations? If so what are the constraints, and how does the change impact existing routes? Is this a constant per router, or could I have, say, 3 paths for a certain destination that I need a lot, but only 1 for others? o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two parameters have to be negotiated between all routers or are there no interop problems if routers use different values in the network? o fp/fe: This is a function (of what?). I am not sure I understand why this is listed under a section Parameters. How can I implement this? - section 6: "To support source routing, a source routing header is added to each datagram routed by this extension." I think there is a section missing about interaction with FIB/RIB. Somewhere else it is said that "[...] the MP-OLSRv2 routing process receives a datagram from upper layers or interfaces connecting other routing domains". How does this work? This may also need some additions to the applicability statement section. - section 7.2: How does this interact with the Routing Set in OLSRv2? Is this used instead? Does the MR_valid_time have to be the same as the timeout on the Routing Set? - "PT_cost - the cost of the path to the destination" Cost in what? Hops? Does this support metrics other than hop count? - "PT_address[1...n] - the addresses of intermediate routers to be visited numbered from 1 to n." A router may have multiple addresses for each of its interfaces. Does it matter which addresses are used in this list? Is loop-freedom guaranteed? - Section 8.2.: SR_OLSR_HOLD_TIME What is the relationship with other OLSRv2 information sets? Could there be a situation where I still have an SR-OLSR Router Tuple, but the same destination is not present anymore in other OLSRv2 sets (Routing Set, Topology Set etc). Since the hold_time can be chosen independently, that seems possible. - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram from upper layers or interfaces connecting other routing domains..." How does this work, "other routing domains"? How would a router determine this? - " o If the length of the path (n) is greater than MAX_SRC_HOPS, only the key routers in the path are kept. By default, the key routers are uniformly chosen in the path." What are key routers? How does this work? o The routers with higher priority (such as higher routing willingness defined in [RFC7181]) are preferred. How? - Section 8.4: This doesn't use the information bases that have been defined before. How can I implement this using the existing information form the protocol? (without all that abstraction) - Section 8.5. This seems to be quite intrusive into the IP stack. I thought it would be enough to add the source route header at the first router along the path, and then just use standard source routing. Or is the path changed during forwarding the packet? - Security: "Compared to OLSRv2, the use of source routing header in this specification introduces vulnerabilities related to source routing attacks, which include bypassing filtering devices, bandwidth exhaustion of certain routers, etc. Those attacks are discussed in Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the source routing header MUST be used only in the current routing domain." Is this enough to let this pass the Sec ADs? How is this enforced, "only in the current routing domain"? Best regards Ulrich On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: > Dear all, > > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) will > be closed on Oct. 16. > > Your comments on the document will be highly appreciated :) > > cheers > > Jiazi > > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff wrote: >> >> Hello WG participants, >> >> The above referenced draft seems to have addressed all of the outstanding >> WG comments to date. Therefore, it's time for a Working Group Last Call >> (WGLC) on this document. The WGLC period will close on October 16. Please >> read and review the document, and provide comments, prior to that time if >> possible. >> >> 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 > From nobody Thu Oct 15 02:21:49 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463441A913A for ; Thu, 15 Oct 2015 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uVNyIPyJ4Jr for ; Thu, 15 Oct 2015 02:21:47 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960C11A9135 for ; Thu, 15 Oct 2015 02:21:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,684,1437433200"; d="scan'208";a="18503380" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 15 Oct 2015 10:21:44 +0100 X-IronPort-AV: E=Sophos;i="5.17,684,1437433200"; d="scan'208";a="119905181" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 15 Oct 2015 10:21:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 10:21:44 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBw== Date: Thu, 15 Oct 2015 09:21:44 +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] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 09:21:48 -0000 I've read DLEP draft 16, but not so far with a critical eye to specific rev= iew comments - other than that the IANA section isn't what's needed (but th= e authors already know that and I understand have already written a replace= ment) and a few editorial comments I'll make below. In particular I haven't= formed a view on the security considerations section - but I may wait for = this and most other points to see -17 which I understand is mostly written. My minor points: - I really would prefer "radio" to "modem" throughout. As someone who once = wrote some modem software, for me modem is what it says, modulation and dem= odulation (and the inseparable channel coding), i.e. converting between bit= streams and modulated signals (for a digital radio).There are many parts o= f a radio that are outside that, and everything DLEP is outside the modem. - Where there are various time and other values (timeouts, repeat periods, = number of retries) I'd use a symbolic name and collect suggested default va= lues in one place. That is after all, as we all write software. - Currently describes some code points as "Reserved for future extensions".= This is not the correct terminology. From RFC 5226: Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. (The Reserved for 0 and 65535 is however presumably correct.) As I know the IANA considerations section is done, this may already have= been caught, but I'll say it in case not. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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 Thu Oct 15 04:30:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA101B2B81 for ; Thu, 15 Oct 2015 04:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA_-fU9FvHGU for ; Thu, 15 Oct 2015 04:30:31 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3851B2B86 for ; Thu, 15 Oct 2015 04:30:30 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,685,1437433200"; d="scan'208,217"; a="18535709" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 15 Oct 2015 12:30:27 +0100 X-IronPort-AV: E=Sophos;i="5.17,685,1437433200"; d="scan'208,217";a="119935375" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 15 Oct 2015 12:30:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 12:30:27 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI , MANET IETF Thread-Topic: [manet] draft-ietf-manet-olsrv2-multipath-06 Thread-Index: AQHQ/RcIaOApGv8hQ0eKbF7z5TP2fZ5p/1qAgAJklyA= Date: Thu, 15 Oct 2015 11:30: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_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA4CF0GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:30:35 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA4CF0GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 U2hvcnQgdmVyc2lvbjogSSBkbyBub3QgdGhpbmsgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgV0dM QyBhY2NlcHRhbmNlLiBUaGVyZSBhcmUgYXQgbGVhc3QgdHdvIG1ham9yIGlzc3VlcyBmb3IgbWUs IGFuZCB2YXJpb3VzIGRldGFpbHMgSSBoYXZlbuKAmXQgZHVnIGludG8uDQoNCk15IG1haW4gcmVz ZXJ2YXRpb24gYWJvdXQgdGhpcyBkcmFmdCBoYXMgYWx3YXlzIGJlZW4sIGFuZCByZW1haW5zLCB0 aGF0IE9MU1J2MiwgYnkgZGVzaWduLCBtYWludGFpbnMgYSBzdWJzZXQgb2YgdGhlIG5ldHdvcmsg dG9wb2xvZ3kgc3VmZmljaWVudCBmb3IgYSBiZXN0IHJvdXRlIHRvIGVhY2ggZGVzdGluYXRpb24u IFBpY2tpbmcgbXVsdGlwbGUgcGF0aHMgZnJvbSB0aGF0IHN1YnNldCB3aWxsIG5vdCBndWFyYW50 ZWUgdG8gZmluZCBhbGwgYWx0ZXJuYXRpdmUgcGF0aHMgdGhhdCBtYXkgZXhpc3QuDQoNClRoZXJl IHdhcyBhIG1lY2hhbmlzbSBpbiBPTFNSdjEgKGNvdmVyYWdlIHBhcmFtZXRlciB3aGVuIGNyZWF0 aW5nIE1QUnMpIHRoYXQgd291bGQgaGF2ZSBlbnN1cmVkIHRoYXQuIEJ1dCBpdCBjb2V4aXN0ZWQg dmVyeSB1bmVhc2lseSB3aXRoIGxpbmsgbWV0cmljcyBpbiBwYXJ0aWN1bGFyLCBhbmQgaXQgZGlk buKAmXQgZW5kIHVwIGluIE9MU1J2Mi4NCg0KQWxzbywgYmVmb3JlIGdldHRpbmcgdG8gdGhlIGRy YWZ0IGl0c2VsZiwgdGhlIHBvaW50IGFib3ZlIGFib3V0IGxpbmsgbWV0cmljcyBhcHBsaWVzIGhl cmUuIFdpdGggYXJiaXRyYXJ5IGxpbmsgbWV0cmljcywgYWx0ZXJuYXRpdmUgcGF0aHMgaGF2aW5n IGV4YWN0bHkgdGhlIHNhbWUgbGluayBtZXRyaWMgbWF5IG9mdGVuIGJlIHJhcmUgb3IgYWNjaWRl bnRhbC4gV2hpY2ggbGVhZHMgdG8gdGhlIHF1ZXN0aW9uIHdoZXRoZXIgYWx0ZXJuYXRpdmUgcGF0 aHMgbXVzdCBoYXZlIHRoZSBzYW1lIG1ldHJpYyAoc28gbWF5IG9mdGVuIG5vdCBleGlzdCkgb3Ig bWF5IGhhdmUgYSBkaWZmZXJlbnQgbWV0cmljIOKAkyBhbmQgaWYgc28gaG93IHRvIGRlY2lkZSBh IGN1dG9mZi4gKEFuZCBob3cgdG8gYXZvaWQgbG9vcGluZyDigJMgdW5sZXNzIHVzaW5nIHNvdXJj ZSByb3V0aW5nLCB3aGljaCBtYXkgYWxzbyBiZSBuZWVkZWQgdG8gZW5mb3JjZSB1c2luZyB0aGUg YWx0ZXJuYXRpdmUgcGF0aHMuKQ0KDQpTbyBvbiB0byB0aGUgZHJhZnQNCg0KU2VjdGlvbiAxLjEs IGZpcnN0IGxpc3QsIHBvaW50IDMuIEkgZG9u4oCZdCBzZWUgdGhpcyBhcyBhIG1vdGl2YXRpb24g Zm9yIG11bHRpcGxlIHBhdGggcm91dGluZy4gSWYgcm91dGVycyBhcmUgbm90IHRvIGJlIHVzZWQs IHRoYXTigJlzIGFuIGlzc3VlIGZvciBzaW5nbGUgcGF0aCByb3V0aW5nIHRvby4NCg0KU2VjdGlv biAxLjEsIHNlY29uZCBsaXN0LiBTb21lIG9mIHRoZSB3b3JkaW5nIGlzbuKAmXQgcmVhbGx5IGZv Y3Vzc2VkIG9uIHdoYXQgZXhwZXJpbWVudHMgYXJlIHJlcXVlc3RlZCB0byBhZHZhbmNlIGJleW9u ZCBleHBlcmltZW50YWwuIFRoZSBtb3N0IG9idmlvdXMgY2FzZSBpcyB0aGUgcGVudWx0aW1hdGUg cG9pbnQgd2hpY2ggZGlzY3Vzc2VzIHdoYXQgd291bGQgYmUgaW50ZXJlc3RpbmcuIFNvbWUgYXJl IG1vcmUgaW1wb3J0YW50IHRoYW4gb3RoZXJzLiBJIGRvbuKAmXQgbGlrZSB0aGUgaW1wbGljYXRp b24gb2YgdGhlIHRoaXJkIHBvaW50IHRoYXQgaG9wIGNvdW50IGlzIG5vcm1hbC4gTWV0cmljcyBv dGhlciB0aGFuIGhvcCBjb3VudCBhcmUgd2hhdCB3ZSBhcmUgYWxsIGFzc3VtaW5nIHRoZXNlIGRh eXMgSSB0aGluaywgYW5kIGlmIHRoaXMgb25seSB3b3JrcyB3ZWxsIHdpdGggaG9wIGNvdW50IChh bmQgSSBoYXZlIG15IGNvbmNlcm5zIHRoZXJlLCBhcyBpbmRpY2F0ZWQgYWJvdmUpIGl0IGlzIGZv ciBtZSBhIG5vbi1zdGFydGVyLg0KDQpJIHNlZSB0aGUgY29tbWVudCBhYm91dCBpbnRlcm9wZXJh YmlsaXR5IHdpdGggT0xTUnYyLiBUaGlzIGlzIG1hbmFnZWQgYnkgcmVxdWlyaW5nIGEgU09VUkNF X1JPVVRFIE1QUiBpbiBhbGwgVEMgbWVzc2FnZXMgZnJvbSByb3V0ZXJzIHRoYXQgc3VwcG9ydCB0 aGlzLiAoSSBoYXZlbuKAmXQgeWV0IGNoZWNrZWQgZGV0YWlscy4pIE5vdGUgaG93ZXZlciB0aGF0 IG5vdCBhbGwgcm91dGVycyBjcmVhdGUgVEMgbWVzc2FnZXMsIGFuZCB0aG9zZSB0aGF0IGRvbuKA mXQgYXJlIGJlY2F1c2UgdGhlcmUgaXMgYW4gYWx0ZXJuYXRpdmUgcm91dGUuIChUaGF04oCZcyB0 aGUgZWZmZWN0LCB0aGUgYWN0dWFsIHJ1bGUgaXMgdG8gZG8gd2l0aCBoYXZpbmcgYWR2ZXJ0aXNl ZCBuZWlnaGJvdXJzLCBhdCBsZWFzdCBNUFIgc2VsZWN0b3JzLikgQnV0IHRoYXQgYWx0ZXJuYXRp dmUgcm91dGUgbWF5IGJlIG5vdCBzb3VyY2Ugcm91dGVkLiBUaGUgbmV0IGVmZmVjdCAoYSBzcGVj aWFsIGNhc2Ugb2YgdGhlIGxpbWl0ZWQgdG9wb2xvZ3kgcHJvYmxlbSBJIG5vdGUgYWJvdmUpIGlz IHRoYXQgYWx0aG91Z2ggdGhlcmUgbWF5IGJlIGEgc291cmNlIHJvdXRhYmxlIHJvdXRlIHRvIGEg ZGVzdGluYXRpb24sIG9uZSBtYXkgbmV2ZXIgYmUgcmVwb3J0ZWQuIFRvIGZvcmNlIHRoYXQgaXTi gJlzIG5vdCBnb29kIGVub3VnaCB0byBzYXkgYWxsIHNvdXJjZSByb3V0YWJsZSByb3V0ZXJzIG11 c3Qgc2VuZCBhIFRDLCBpbnN0ZWFkIEnigJltIGZhaXJseSBzdXJlIHlvdSB3aWxsIG5lZWQgdG8g bW9kaWZ5IE1QUiBzZWxlY3Rpb24gc28gdGhhdCBzb3VyY2Ugcm91dGFibGUgcm91dGVycyBjb3Zl ciBuZWlnaGJvdXJzIHVzaW5nIG90aGVyIHNvdXJjZSByb3V0YWJsZSBuZWlnaGJvdXJzIHRvIHRo ZSBtYXhpbXVtIGV4dGVudCBwb3NzaWJsZS4gSXMgdGhhdCBzdWZmaWNpZW50PyBOb3Qgc3VyZS4g VGhlcmUgaXMgaG93ZXZlciBubyBjb25zaWRlcmF0aW9uIG9mIHRoaXMuDQoNClRoaXMgYWxvbmUg aXMgZm9yIG1lIGEgc2hvd3N0b3BwZXIsIEkgZG8gbm90IHRoaW5rIHRoaXMgZHJhZnQgaXMgZ29v ZCBlbm91Z2ggdG8gcGFzcyBXR0xDLg0KDQo3LjIgaGFzIGNvc3RzIG9mIHBhdGhzLiBJZiB0aGlz IGlzIE9MU1J2MiBwYXRoIG1ldHJpYywgdXNlIHRoYXQgdGVybS4gSWYgbm90LCB3aHkgbm90Pw0K DQo4LjMgSW4gcm91bmQtcm9iaW4gZmFzaGlvbj8gVGhhdCBuZWVkcyBkZWZpbmluZy4gVGhlcmXi gJlzIGFsc28gYW4g4oCcb3IgZWxzZeKAnS4gQ29tcGF0aWJpbGl0eSBpc3N1ZXM/IFRoZSBhcHBy b2FjaCB3ZeKAmXZlIGFsd2F5cyB0YWtlbiBpbiB0aGUgT0xTUnYyIHNldCBvZiBwcm90b2NvbHMg aXMgKGEpIHNwZWNpZnkgdGhlIHJlcXVpcmVkIHByb3BlcnRpZXMgb2YgdGhlIHByb2Nlc3MsIChi KSBnaXZlIGNvbXBsaWFudCBleGFtcGxlIGFsZ29yaXRobShzKSwgdXN1YWxseSBpbiBhbiBhcHBl bmRpeC4gSSBkb27igJl0IGtub3cgYXQgdGhpcyBwb2ludCB3aGF0IGtleSByb3V0ZXJzIGFyZSwg b3IgaGF2ZSBhIGZvcndhcmQgcmVmZXJlbmNlLiBJ4oCZbSBub3Qgc3VyZSBpZiBhIGhvcCBsaW1p dCBpcyBjb3JyZWN0IGZvciBhIGdlbmVyYWwgbWV0cmljLg0KDQooVGhlcmUgYXJlIHNvbWUgc3R5 bGlzdGljIGRpZmZlcmVuY2VzIGluIG5hbWluZyB0aGF0IEnigJlkIHRyeSB0byBpcm9uIG91dCBp ZiBwcm9jZWVkaW5nLCBidXQgSeKAmW0gbm90IGdvaW5nIHRvIGNvbnNpZGVyIHRob3NlIGluIGRl dGFpbC4pDQoNCkRhdGFncmFtIGZvcndhcmRpbmcuIEnigJltIHVuaGFwcHkgaGVyZSBhYm91dCB0 aGF0IHdlIG5vdyBoYXZlIGEgcm91dGluZyBwcm90b2NvbCB0aGF04oCZcyBkb2luZyB0aGUgZGF0 YSBwbGFuZSBmb3J3YXJkaW5nLiBJ4oCZdmUgYmVlbiBjcml0aWNhbCBvZiBBT0RWdjIgZm9yIGFz c3VtaW5nIHRvbyBtdWNoIG9mIElQLCB0aGlzIGlzIGFjdHVhbGx5IHdvcnNlIGluIHNvbWUgcmVn YXJkcywgaXTigJlzIGRvaW5nIHRoZSBmb3J3YXJkaW5nLCBhbmQgbW9kaWZ5aW5nIHRoZSBwYWNr ZXQgKGlmIGl04oCZcyB1c2luZyBJUHNlYywgd2hhdCBoYXBwZW5zPykgYW5kIG5vdCB1c2luZyBJ UCBzb3VyY2Ugcm91dGluZy4gVGhpcyBhbHNvIGlzIGEgc2hvd3N0b3BwZXIgZm9yIFdHTEMgYXMg ZmFyIGFzIEnigJltIGNvbmNlcm5lZCwgZXZlbiBtb3JlIHNvIHRoYW4gdGhlIGxhc3Qgb25lLiBX aGF0IGFyZSB0aGUgaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEwIGRvaW5n IGhlcmU/DQoNCkkgaGF2ZSBteSBkb3VidHMgdGhhdCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBpcyBhZGVxdWF0ZSwgYnV0IHRoYXTigJlzIG5vdCBjcml0aWNhbCBhdCB0aGlz IHBvaW50Lg0KDQpJQU5BIOKAkyB5b3UgY2FuIGRyb3AgVExWIG5hbWluZyDigJMgaXTigJlzIG5v dyBhbiBSRkMsIGl04oCZcyBiZWVuIGRvbmUuIE5vIG5lZWQgZXZlbiB0byByZWZlcmVuY2UgaXQu IFRhYmxlIDEgaXTigJlzIG5vdCB1cCB0byB5b3UgdG8gc3BlY2lmeSB0aGUgbGluZXMgVEJELTIy MyBhbmQgMjI0IHRvIDI1NSAoZXNwZWNpYWxseSB0aGUgbGF0dGVyLCB3aGljaCBpcyB1bmNoYW5n ZWQpLg0KDQpBcHBlbmRpeCwgSSBoYXZlbuKAmXQgc3R1ZGllZCwgYnV0IEnigJlkIGxpa2UgdG8g c2VlIGFuIGV4YW1wbGUgbm90IHVzaW5nIGhvcCBjb3VudC4gVGhlcmXigJlzIGEgbG90IGF0IHRo ZSBlbmQgdGhhdCByYWlzZXMgbW9yZSBxdWVzdGlvbnMgdGhhbiBpdCBhbnN3ZXJzLiBEZWxheSBp c27igJl0IGp1c3QgYWJvdXQgbnVtYmVyIG9mIGhvcHMgKGFuZCA1MCBpcyBhbiBleGNlcHRpb25h bCBjYXNlKS4gSWYgZGVsYXkgbWF0dGVycywgaXQgc2hvdWxkIGJlIHBhcnQgb2YgeW91ciBtZXRy aWMgYW5kIGhhbmRsZWQgdGhhdCB3YXkuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2Vu aW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3 d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJj aCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCkZyb206IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppYXppIFlJDQpTZW50OiAx MyBPY3RvYmVyIDIwMTUgMjM6MTkNClRvOiBNQU5FVCBJRVRGDQpTdWJqZWN0OiBSZTogW21hbmV0 XSBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDYNCg0KDQoqKiogV0FSTklORyAq KioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNp ZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVu IGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVk IEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBj bGljayBoZXJlPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3Nl Y3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVl bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZj4u DQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5h dGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQpEZWFyIGFsbCwNCg0KQXMgYSBy ZW1pbmRlciwgdGhlIFdHTEMgb2YgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTA2 IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2 Mi1tdWx0aXBhdGgvKSB3aWxsIGJlIGNsb3NlZCBvbiBPY3QuIDE2Lg0KDQpZb3VyIGNvbW1lbnRz IG9uIHRoZSBkb2N1bWVudCB3aWxsIGJlIGhpZ2hseSBhcHByZWNpYXRlZCA6KQ0KDQpjaGVlcnMN Cg0KSmlhemkNCg0KT24gRnJpLCBPY3QgMiwgMjAxNSBhdCAzOjMzIFBNLCBTdGFuIFJhdGxpZmYg PHJhdGxpZmZzdGFuQGdtYWlsLmNvbTxtYWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tPj4gd3Jv dGU6DQpIZWxsbyBXRyBwYXJ0aWNpcGFudHMsDQoNClRoZSBhYm92ZSByZWZlcmVuY2VkIGRyYWZ0 IHNlZW1zIHRvIGhhdmUgYWRkcmVzc2VkIGFsbCBvZiB0aGUgb3V0c3RhbmRpbmcgV0cgY29tbWVu dHMgdG8gZGF0ZS4gVGhlcmVmb3JlLCBpdCdzIHRpbWUgZm9yIGEgV29ya2luZyBHcm91cCBMYXN0 IENhbGwgKFdHTEMpIG9uIHRoaXMgZG9jdW1lbnQuIFRoZSBXR0xDIHBlcmlvZCB3aWxsIGNsb3Nl IG9uIE9jdG9iZXIgMTYuIFBsZWFzZSByZWFkIGFuZCByZXZpZXcgdGhlIGRvY3VtZW50LCBhbmQg cHJvdmlkZSBjb21tZW50cywgcHJpb3IgdG8gdGhhdCB0aW1lIGlmIHBvc3NpYmxlLg0KDQpSZWdh cmRzLA0KU3Rhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0 cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA4CF0GLKXM0002VGREEN_ 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 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNob3J0IHZlcnNpb246IEkgZG8gbm90IHRoaW5rIHRoaXMg ZHJhZnQgaXMgcmVhZHkgZm9yIFdHTEMgYWNjZXB0YW5jZS4gVGhlcmUgYXJlIGF0IGxlYXN0IHR3 byBtYWpvciBpc3N1ZXMgZm9yIG1lLCBhbmQgdmFyaW91cyBkZXRhaWxzIEkgaGF2ZW7igJl0IGR1 ZyBpbnRvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TXkgbWFpbiByZXNlcnZhdGlvbiBhYm91dCB0aGlzIGRyYWZ0IGhh cyBhbHdheXMgYmVlbiwgYW5kIHJlbWFpbnMsIHRoYXQgT0xTUnYyLCBieSBkZXNpZ24sIG1haW50 YWlucyBhIHN1YnNldCBvZiB0aGUgbmV0d29yayB0b3BvbG9neSBzdWZmaWNpZW50IGZvciBhIGJl c3QNCiByb3V0ZSB0byBlYWNoIGRlc3RpbmF0aW9uLiBQaWNraW5nIG11bHRpcGxlIHBhdGhzIGZy b20gdGhhdCBzdWJzZXQgd2lsbCBub3QgZ3VhcmFudGVlIHRvIGZpbmQgYWxsIGFsdGVybmF0aXZl IHBhdGhzIHRoYXQgbWF5IGV4aXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgd2FzIGEgbWVjaGFuaXNtIGlu IE9MU1J2MSAoY292ZXJhZ2UgcGFyYW1ldGVyIHdoZW4gY3JlYXRpbmcgTVBScykgdGhhdCB3b3Vs ZCBoYXZlIGVuc3VyZWQgdGhhdC4gQnV0IGl0IGNvZXhpc3RlZCB2ZXJ5IHVuZWFzaWx5IHdpdGgg bGluayBtZXRyaWNzIGluIHBhcnRpY3VsYXIsDQogYW5kIGl0IGRpZG7igJl0IGVuZCB1cCBpbiBP TFNSdjIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbHNvLCBiZWZvcmUgZ2V0dGluZyB0byB0aGUgZHJhZnQgaXRzZWxm LCB0aGUgcG9pbnQgYWJvdmUgYWJvdXQgbGluayBtZXRyaWNzIGFwcGxpZXMgaGVyZS4gV2l0aCBh cmJpdHJhcnkgbGluayBtZXRyaWNzLCBhbHRlcm5hdGl2ZSBwYXRocyBoYXZpbmcgZXhhY3RseSB0 aGUNCiBzYW1lIGxpbmsgbWV0cmljIG1heSBvZnRlbiBiZSByYXJlIG9yIGFjY2lkZW50YWwuIFdo aWNoIGxlYWRzIHRvIHRoZSBxdWVzdGlvbiB3aGV0aGVyIGFsdGVybmF0aXZlIHBhdGhzIG11c3Qg aGF2ZSB0aGUgc2FtZSBtZXRyaWMgKHNvIG1heSBvZnRlbiBub3QgZXhpc3QpIG9yIG1heSBoYXZl IGEgZGlmZmVyZW50IG1ldHJpYyDigJMgYW5kIGlmIHNvIGhvdyB0byBkZWNpZGUgYSBjdXRvZmYu IChBbmQgaG93IHRvIGF2b2lkIGxvb3Bpbmcg4oCTIHVubGVzcw0KIHVzaW5nIHNvdXJjZSByb3V0 aW5nLCB3aGljaCBtYXkgYWxzbyBiZSBuZWVkZWQgdG8gZW5mb3JjZSB1c2luZyB0aGUgYWx0ZXJu YXRpdmUgcGF0aHMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gb24gdG8gdGhlIGRyYWZ0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0 aW9uIDEuMSwgZmlyc3QgbGlzdCwgcG9pbnQgMy4gSSBkb27igJl0IHNlZSB0aGlzIGFzIGEgbW90 aXZhdGlvbiBmb3IgbXVsdGlwbGUgcGF0aCByb3V0aW5nLiBJZiByb3V0ZXJzIGFyZSBub3QgdG8g YmUgdXNlZCwgdGhhdOKAmXMgYW4gaXNzdWUgZm9yIHNpbmdsZSBwYXRoDQogcm91dGluZyB0b28u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TZWN0aW9uIDEuMSwgc2Vjb25kIGxpc3QuIFNvbWUgb2YgdGhlIHdvcmRpbmcg aXNu4oCZdCByZWFsbHkgZm9jdXNzZWQgb24gd2hhdCBleHBlcmltZW50cyBhcmUgcmVxdWVzdGVk IHRvIGFkdmFuY2UgYmV5b25kIGV4cGVyaW1lbnRhbC4gVGhlIG1vc3Qgb2J2aW91cyBjYXNlDQog aXMgdGhlIHBlbnVsdGltYXRlIHBvaW50IHdoaWNoIGRpc2N1c3NlcyB3aGF0IHdvdWxkIGJlIGlu dGVyZXN0aW5nLiBTb21lIGFyZSBtb3JlIGltcG9ydGFudCB0aGFuIG90aGVycy4gSSBkb27igJl0 IGxpa2UgdGhlIGltcGxpY2F0aW9uIG9mIHRoZSB0aGlyZCBwb2ludCB0aGF0IGhvcCBjb3VudCBp cyBub3JtYWwuIE1ldHJpY3Mgb3RoZXIgdGhhbiBob3AgY291bnQgYXJlIHdoYXQgd2UgYXJlIGFs bCBhc3N1bWluZyB0aGVzZSBkYXlzIEkgdGhpbmssDQogYW5kIGlmIHRoaXMgb25seSB3b3JrcyB3 ZWxsIHdpdGggaG9wIGNvdW50IChhbmQgSSBoYXZlIG15IGNvbmNlcm5zIHRoZXJlLCBhcyBpbmRp Y2F0ZWQgYWJvdmUpIGl0IGlzIGZvciBtZSBhIG5vbi1zdGFydGVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzZWUg dGhlIGNvbW1lbnQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIE9MU1J2Mi4gVGhpcyBpcyBt YW5hZ2VkIGJ5IHJlcXVpcmluZyBhIFNPVVJDRV9ST1VURSBNUFIgaW4gYWxsIFRDIG1lc3NhZ2Vz IGZyb20gcm91dGVycyB0aGF0IHN1cHBvcnQgdGhpcy4gKEkNCiBoYXZlbuKAmXQgeWV0IGNoZWNr ZWQgZGV0YWlscy4pIE5vdGUgaG93ZXZlciB0aGF0IG5vdCBhbGwgcm91dGVycyBjcmVhdGUgVEMg bWVzc2FnZXMsIGFuZCB0aG9zZSB0aGF0IGRvbuKAmXQgYXJlIGJlY2F1c2UgdGhlcmUgaXMgYW4g YWx0ZXJuYXRpdmUgcm91dGUuIChUaGF04oCZcyB0aGUgZWZmZWN0LCB0aGUgYWN0dWFsIHJ1bGUg aXMgdG8gZG8gd2l0aCBoYXZpbmcgYWR2ZXJ0aXNlZCBuZWlnaGJvdXJzLCBhdCBsZWFzdCBNUFIg c2VsZWN0b3JzLikgQnV0DQogdGhhdCBhbHRlcm5hdGl2ZSByb3V0ZSBtYXkgYmUgbm90IHNvdXJj ZSByb3V0ZWQuIFRoZSBuZXQgZWZmZWN0IChhIHNwZWNpYWwgY2FzZSBvZiB0aGUgbGltaXRlZCB0 b3BvbG9neSBwcm9ibGVtIEkgbm90ZSBhYm92ZSkgaXMgdGhhdCBhbHRob3VnaCB0aGVyZSBtYXkg YmUgYSBzb3VyY2Ugcm91dGFibGUgcm91dGUgdG8gYSBkZXN0aW5hdGlvbiwgb25lIG1heSBuZXZl ciBiZSByZXBvcnRlZC4gVG8gZm9yY2UgdGhhdCBpdOKAmXMgbm90IGdvb2QgZW5vdWdoDQogdG8g c2F5IGFsbCBzb3VyY2Ugcm91dGFibGUgcm91dGVycyBtdXN0IHNlbmQgYSBUQywgaW5zdGVhZCBJ 4oCZbSBmYWlybHkgc3VyZSB5b3Ugd2lsbCBuZWVkIHRvIG1vZGlmeSBNUFIgc2VsZWN0aW9uIHNv IHRoYXQgc291cmNlIHJvdXRhYmxlIHJvdXRlcnMgY292ZXIgbmVpZ2hib3VycyB1c2luZyBvdGhl ciBzb3VyY2Ugcm91dGFibGUgbmVpZ2hib3VycyB0byB0aGUgbWF4aW11bSBleHRlbnQgcG9zc2li bGUuIElzIHRoYXQgc3VmZmljaWVudD8gTm90DQogc3VyZS4gVGhlcmUgaXMgaG93ZXZlciBubyBj b25zaWRlcmF0aW9uIG9mIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGFsb25lIGlzIGZvciBtZSBhIHNo b3dzdG9wcGVyLCBJIGRvIG5vdCB0aGluayB0aGlzIGRyYWZ0IGlzIGdvb2QgZW5vdWdoIHRvIHBh c3MgV0dMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjcuMiBoYXMgY29zdHMgb2YgcGF0aHMuIElmIHRoaXMgaXMgT0xT UnYyIHBhdGggbWV0cmljLCB1c2UgdGhhdCB0ZXJtLiBJZiBub3QsIHdoeSBub3Q/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij44LjMgSW4gcm91bmQtcm9iaW4gZmFzaGlvbj8gVGhhdCBuZWVkcyBkZWZpbmluZy4gVGhlcmXi gJlzIGFsc28gYW4g4oCcb3IgZWxzZeKAnS4gQ29tcGF0aWJpbGl0eSBpc3N1ZXM/IFRoZSBhcHBy b2FjaCB3ZeKAmXZlIGFsd2F5cyB0YWtlbiBpbiB0aGUgT0xTUnYyIHNldCBvZiBwcm90b2NvbHMN CiBpcyAoYSkgc3BlY2lmeSB0aGUgcmVxdWlyZWQgcHJvcGVydGllcyBvZiB0aGUgcHJvY2Vzcywg KGIpIGdpdmUgY29tcGxpYW50IGV4YW1wbGUgYWxnb3JpdGhtKHMpLCB1c3VhbGx5IGluIGFuIGFw cGVuZGl4LiBJIGRvbuKAmXQga25vdyBhdCB0aGlzIHBvaW50IHdoYXQga2V5IHJvdXRlcnMgYXJl LCBvciBoYXZlIGEgZm9yd2FyZCByZWZlcmVuY2UuIEnigJltIG5vdCBzdXJlIGlmIGEgaG9wIGxp bWl0IGlzIGNvcnJlY3QgZm9yIGEgZ2VuZXJhbCBtZXRyaWMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oVGhlcmUgYXJl IHNvbWUgc3R5bGlzdGljIGRpZmZlcmVuY2VzIGluIG5hbWluZyB0aGF0IEnigJlkIHRyeSB0byBp cm9uIG91dCBpZiBwcm9jZWVkaW5nLCBidXQgSeKAmW0gbm90IGdvaW5nIHRvIGNvbnNpZGVyIHRo b3NlIGluIGRldGFpbC4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYXRhZ3JhbSBmb3J3YXJkaW5nLiBJ4oCZbSB1bmhh cHB5IGhlcmUgYWJvdXQgdGhhdCB3ZSBub3cgaGF2ZSBhIHJvdXRpbmcgcHJvdG9jb2wgdGhhdOKA mXMgZG9pbmcgdGhlIGRhdGEgcGxhbmUgZm9yd2FyZGluZy4gSeKAmXZlIGJlZW4gY3JpdGljYWwg b2YgQU9EVnYyIGZvciBhc3N1bWluZw0KIHRvbyBtdWNoIG9mIElQLCB0aGlzIGlzIGFjdHVhbGx5 IHdvcnNlIGluIHNvbWUgcmVnYXJkcywgaXTigJlzIGRvaW5nIHRoZSBmb3J3YXJkaW5nLCBhbmQg bW9kaWZ5aW5nIHRoZSBwYWNrZXQgKGlmIGl04oCZcyB1c2luZyBJUHNlYywgd2hhdCBoYXBwZW5z PykgYW5kIG5vdCB1c2luZyBJUCBzb3VyY2Ugcm91dGluZy4gVGhpcyBhbHNvIGlzIGEgc2hvd3N0 b3BwZXIgZm9yIFdHTEMgYXMgZmFyIGFzIEnigJltIGNvbmNlcm5lZCwgZXZlbiBtb3JlIHNvIHRo YW4NCiB0aGUgbGFzdCBvbmUuIFdoYXQgYXJlIHRoZSBpbXBsZW1lbnRhdGlvbnMgZGVzY3JpYmVk IGluIHNlY3Rpb24gMTAgZG9pbmcgaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBteSBkb3VidHMgdGhh dCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyBhZGVxdWF0ZSwgYnV0IHRo YXTigJlzIG5vdCBjcml0aWNhbCBhdCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SUFOQSDigJMgeW91 IGNhbiBkcm9wIFRMViBuYW1pbmcg4oCTIGl04oCZcyBub3cgYW4gUkZDLCBpdOKAmXMgYmVlbiBk b25lLiBObyBuZWVkIGV2ZW4gdG8gcmVmZXJlbmNlIGl0LiBUYWJsZSAxIGl04oCZcyBub3QgdXAg dG8geW91IHRvIHNwZWNpZnkgdGhlIGxpbmVzIFRCRC0yMjMgYW5kDQogMjI0IHRvIDI1NSAoZXNw ZWNpYWxseSB0aGUgbGF0dGVyLCB3aGljaCBpcyB1bmNoYW5nZWQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXBwZW5k aXgsIEkgaGF2ZW7igJl0IHN0dWRpZWQsIGJ1dCBJ4oCZZCBsaWtlIHRvIHNlZSBhbiBleGFtcGxl IG5vdCB1c2luZyBob3AgY291bnQuIFRoZXJl4oCZcyBhIGxvdCBhdCB0aGUgZW5kIHRoYXQgcmFp c2VzIG1vcmUgcXVlc3Rpb25zIHRoYW4gaXQgYW5zd2Vycy4gRGVsYXkNCiBpc27igJl0IGp1c3Qg YWJvdXQgbnVtYmVyIG9mIGhvcHMgKGFuZCA1MCBpcyBhbiBleGNlcHRpb25hbCBjYXNlKS4gSWYg ZGVsYXkgbWF0dGVycywgaXQgc2hvdWxkIGJlIHBhcnQgb2YgeW91ciBtZXRyaWMgYW5kIGhhbmRs ZWQgdGhhdCB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0K PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5l ZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4NCjwvc3Bhbj48L2I+ 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 ImNvbG9yOiMzQThCOTI7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3dy5iYWVzeXN0ZW1zLmNvbS9h aTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsg V2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr LCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5ldCBb bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppYXpp IFlJPGJyPg0KPGI+U2VudDo8L2I+IDEzIE9jdG9iZXIgMjAxNSAyMzoxOTxicj4NCjxiPlRvOjwv Yj4gTUFORVQgSUVURjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBkcmFmdC1pZXRm LW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+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+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RGVhciBhbGwsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcyBhIHJlbWluZGVyLCB0aGUgV0dMQyBvZiZuYnNwO2RyYWZ0LWlldGYtbWFu ZXQtb2xzcnYyLW11bHRpcGF0aC0wNiAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLyI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLzwv YT4pIHdpbGwgYmUgY2xvc2VkIG9uIE9jdC4NCiAxNi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91ciBjb21tZW50cyBvbiB0aGUg ZG9jdW1lbnQgd2lsbCBiZSBoaWdobHkgYXBwcmVjaWF0ZWQgOik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hlZXJzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkppYXppPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDIs IDIwMTUgYXQgMzozMyBQTSwgU3RhbiBSYXRsaWZmICZsdDs8YSBocmVmPSJtYWlsdG86cmF0bGlm ZnN0YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmF0bGlmZnN0YW5AZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGVsbG8gV0cgcGFydGljaXBhbnRzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFib3ZlIHJlZmVyZW5jZWQgZHJhZnQgc2VlbXMgdG8gaGF2 ZSBhZGRyZXNzZWQgYWxsIG9mIHRoZSBvdXRzdGFuZGluZyBXRyBjb21tZW50cyB0byBkYXRlLiBU aGVyZWZvcmUsIGl0J3MgdGltZSBmb3IgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCAoV0dMQykg b24gdGhpcyBkb2N1bWVudC4gVGhlIFdHTEMgcGVyaW9kIHdpbGwgY2xvc2Ugb24gT2N0b2JlciAx Ni4gUGxlYXNlIHJlYWQgYW5kIHJldmlldw0KIHRoZSBkb2N1bWVudCwgYW5kIHByb3ZpZGUgY29t bWVudHMsIHByaW9yIHRvIHRoYXQgdGltZSBpZiBwb3NzaWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8YnI+DQpT dGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPgpUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+ CnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkPGJyPgpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVt IGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+CllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNl IGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+CmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvcD48L2JvZHk+DQo8 L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA4CF0GLKXM0002VGREEN_-- From nobody Thu Oct 15 04:33:43 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F631B2B8A for ; Thu, 15 Oct 2015 04:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBKiNHezu-g1 for ; Thu, 15 Oct 2015 04:33:28 -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 7698B1B2B9B for ; Thu, 15 Oct 2015 04:33:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,685,1437433200"; d="scan'208";a="14379402" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 15 Oct 2015 12:33:25 +0100 X-IronPort-AV: E=Sophos;i="5.17,685,1437433200"; d="scan'208";a="116462772" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 15 Oct 2015 12:33:25 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 12:33:25 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , Jiazi YI Thread-Topic: [manet] draft-ietf-manet-olsrv2-multipath-06 Thread-Index: AQHQ/RcIaOApGv8hQ0eKbF7z5TP2fZ5p/1qAgAE80gCAAUPRMA== Date: Thu, 15 Oct 2015 11:33: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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:33:36 -0000 I agree with all of Ulrich's points, which overlap mine - he's caught some = good points I haven't made such as the multiple addressing point, and that = willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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: 14 October 2015 18:13 To: Jiazi YI Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 ----------------------! 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. Jiazi, thanks for the reminder. I read the draft and have a few comments and quest= ions. Overall, I think that the draft is well written, but lacks some detai= ls that would have to be specified before I'd feel comfortable implementing= this in an interoperable fashion. - section 5.1. (router parameters). o NUMBER_OF_PATHS: Is this a constant? Can it change during router operatio= ns? If so what are the constraints, and how does the change impact existing= routes? Is this a constant per router, or could I have, say, 3 paths for a= certain destination that I need a lot, but only 1 for others? o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two parame= ters have to be negotiated between all routers or are there no interop prob= lems if routers use different values in the network? o fp/fe: This is a function (of what?). I am not sure I understand why this= is listed under a section Parameters. How can I implement this? - section 6: "To support source routing, a source routing header is added to each datagram routed by this extension." I think there is a section missing about interaction with FIB/RIB. Somewhere else it is said that "[...] the MP-OLSRv2 routing process receive= s a datagram from upper layers or interfaces connecting other routing domai= ns". How does this work? This may also need some additions to the applicabi= lity statement section. - section 7.2: How does this interact with the Routing Set in OLSRv2? Is this used instead= ? Does the MR_valid_time have to be the same as the timeout on the Routing = Set? - "PT_cost - the cost of the path to the destination" Cost in what? Hops? Does this support metrics other than hop count? - "PT_address[1...n] - the addresses of intermediate routers to be visited numbered from 1 to n." A router may have multiple addresses for each of its interfaces. Does it ma= tter which addresses are used in this list? Is loop-freedom guaranteed? - Section 8.2.: SR_OLSR_HOLD_TIME What is the relationship with other OLSRv2 information sets? Could there be= a situation where I still have an SR-OLSR Router Tuple, but the same desti= nation is not present anymore in other OLSRv2 sets (Routing Set, Topology S= et etc). Since the hold_time can be chosen independently, that seems possib= le. - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram fro= m upper layers or interfaces connecting other routing domains..." How does this work, "other routing domains"? How would a router determine t= his? - " o If the length of the path (n) is greater than MAX_SRC_HOPS, only the key routers in the path are kept. By default, the key routers are uniformly chosen in the path." What are key routers? How does this work? o The routers with higher priority (such as higher routing willingness defined in [RFC7181]) are preferred. How? - Section 8.4: This doesn't use the information bases that have been define= d before. How can I implement this using the existing information form the = protocol? (without all that abstraction) - Section 8.5. This seems to be quite intrusive into the IP stack. I though= t it would be enough to add the source route header at the first router alo= ng the path, and then just use standard source routing. Or is the path chan= ged during forwarding the packet? - Security: "Compared to OLSRv2, the use of source routing header in this specification introduces vulnerabilities related to source routing attacks, which include bypassing filtering devices, bandwidth exhaustion of certain routers, etc. Those attacks are discussed in Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the source routing header MUST be used only in the current routing domain." Is this enough to let this pass the Sec ADs? How is this enforced, "only in= the current routing domain"? Best regards Ulrich On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: > Dear all, > > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) = > will be closed on Oct. 16. > > Your comments on the document will be highly appreciated :) > > cheers > > Jiazi > > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff wrot= e: >> >> Hello WG participants, >> >> The above referenced draft seems to have addressed all of the = >> outstanding WG comments to date. Therefore, it's time for a Working = >> Group Last Call >> (WGLC) on this document. The WGLC period will close on October 16. = >> Please read and review the document, and provide comments, prior to = >> that time if possible. >> >> 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 > _______________________________________________ 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 Thu Oct 15 05:25:39 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080CA1B2EF8 for ; Thu, 15 Oct 2015 05:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuPdezZbc7fW for ; Thu, 15 Oct 2015 05:25:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1432D1B2DCF for ; Thu, 15 Oct 2015 05:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3867; q=dns/txt; s=iport; t=1444911936; x=1446121536; h=from:to:subject:date:message-id:mime-version; bh=HyewdfwCBJBNCVOH0zCFFmbNyuhycBumj3ngDeq3pm0=; b=KjpNhy8IVwfHCiwVxbbS3qV3cETmhaKUpBRerjFTOXC7B+uKOwE6ms/i GCfzgesQmf11Wl9HtBruISbzul0ouHnVZhngNH9i/WpAt/nb+s0LozDUj Di64wHDmOBGU6B23z8W/CmmxCZyQhOfnPy341lbr5zJtjMaT+wdsnIawI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQACmh9W/5NdJa1egllNgUi5FIQhAQ2BWYdUOBQBAQEBAQEBfwuELS06JAEMdCYBBBuIJp92oyMBAQEBBgEBAQEBHYZ2AY4/BZYbAY0TnBUBHwEBQoIOIIFVhVKBBgEBAQ X-IronPort-AV: E=Sophos; i="5.17,685,1437436800"; d="scan'208,217"; a="37848342" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2015 12:25:35 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9FCPZBf002886 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Oct 2015 12:25:35 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 07:25:20 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 07:25:20 -0500 From: "Ashish Dalela (adalela)" To: "manet@ietf.org" Thread-Topic: DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3A== Date: Thu, 15 Oct 2015 12:25:20 +0000 Message-ID: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> 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.65.54.79] Content-Type: multipart/alternative; boundary="_000_842811b9f2ec4385b25bfdc02f6bdb09XCHALN005ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:25:38 -0000 --_000_842811b9f2ec4385b25bfdc02f6bdb09XCHALN005ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Team, I have a comment regarding the credit windowing scheme on the DLEP draft. T= hese credits are exchanged through control plane packets, and these schemes= will work well for routers where the control and data planes are converged= . When the control and data planes are separate, translating these credit e= xchanges to packet rate flow control in hardware (e.g. ASICs) is a difficul= t practical issue. I understand that the PPPoE scheme in RFC 5578 employed a credit scheme and= a similar scheme has been carried forward for DLEP as well. However, there= is a big difference between running credits over PPPoE sessions and Ethern= et based forwarding where there is no notion of a "session". For instance, = even if we program a certain number of bytes to be forwarded on an Ethernet= port on an ASIC, after a while the packets lying in the queue will be drop= ped. The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE fra= mes, which has further been enhanced by the PFC (802.1Qbb) mechanism. In es= sence, we don't send credits before packets are forwarded. Rather we pause = the traffic when the traffic cannot be forwarded and the buffers are full. = PFC is widely used in a number of Ethernet flow-control scenarios today. I would suggest the authors to consider removing the credit windowing schem= e from DLEP and defer to Ethernet flow-control. Thanks -Ashish --_000_842811b9f2ec4385b25bfdc02f6bdb09XCHALN005ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Team,
 
I have a comment regarding the credit windowing scheme on the DLEP dra= ft. These credits are exchanged through control plane packets, and these sc= hemes will work well for routers where the control and data planes are conv= erged. When the control and data planes are separate, translating these credit exchanges to packet rate flow= control in hardware (e.g. ASICs) is a difficult practical issue.
 
I understand that the PPPoE scheme in RFC 5578 employed a credit schem= e and a similar scheme has been carried forward for DLEP as well. However, = there is a big difference between running credits over PPPoE sessions and E= thernet based forwarding where there is no notion of a “session”. For instance, even if we program a= certain number of bytes to be forwarded on an Ethernet port on an ASIC, af= ter a while the packets lying in the queue will be dropped.
 
The ideal mechanism for Ethernet flow control is the use of 802.3 PAUS= E frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. = In essence, we don’t send credits before packets are forwarded. Rathe= r we pause the traffic when the traffic cannot be forwarded and the buffers are full. PFC is widely used in a numbe= r of Ethernet flow-control scenarios today.
 
I would suggest the authors to consider removing the credit windowing = scheme from DLEP and defer to Ethernet flow-control.
 
Thanks
-Ashish
 
 --_000_842811b9f2ec4385b25bfdc02f6bdb09XCHALN005ciscocom_-- From nobody Thu Oct 15 06:06:31 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5D1B318B for ; Thu, 15 Oct 2015 06:06:30 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJsBtP25vbkF for ; Thu, 15 Oct 2015 06:06:28 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 C5DFD1A1BD7 for ; Thu, 15 Oct 2015 06:06:27 -0700 (PDT) Received: by wijq8 with SMTP id q8so128862087wij.0 for ; Thu, 15 Oct 2015 06:06: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UPZxj2KjDDLfjD6trI9O6amLNQWfrQYORxmMTYUbRhE=; b=HnPmqIBf2v6cIJpxC552Znl9ho4pJdt9wpC2cdX576TGkW6RjExtdXNksjgKRAjAPV SvOcBU6xduYs0fFHQ8jq5Fd9DSyopjPWGHU1LQBvWEeiCKVodXnySK5Q/VVtVtvcXpHA cLzGm6MdKp79Zwq0yUTQ/dZAPPhWXoRFRhP3t72W/7lUKKBtmjXSVVoNWZrPpKcJhr7R JVglsly2VTSnyWFaPKvqbTeeI3qQWGQPa6xo+hJFQNPomQr6sIBNLSvzPxdxig01ywh7 UJMmLqRDk5faSdoXHJ2lO3xyqA7wNSI5pq704e8/pH3BTr1nDpVXrNtF9AHfEHMlXNqM QHfA== X-Received: by 10.195.11.72 with SMTP id eg8mr11865667wjd.14.1444914386275; Thu, 15 Oct 2015 06:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Thu, 15 Oct 2015 06:05:56 -0700 (PDT) In-Reply-To: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> From: Henning Rogge Date: Thu, 15 Oct 2015 15:05:56 +0200 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 13:06:30 -0000 On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) wrote: > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. = In > essence, we don=E2=80=99t send credits before packets are forwarded. Rath= er we pause > the traffic when the traffic cannot be forwarded and the buffers are full= . > PFC is widely used in a number of Ethernet flow-control scenarios today. Would a 802.3 PAUSE Frame not also block the DLEP control channel? Henning Rogge From nobody Thu Oct 15 07:50:12 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB31B3340 for ; Thu, 15 Oct 2015 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ma_u18GiJEL for ; Thu, 15 Oct 2015 07:50:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A95C1B3337 for ; Thu, 15 Oct 2015 07:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3341; q=dns/txt; s=iport; t=1444920608; x=1446130208; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aXZXTVu7KQVcRy9jvSjYQE0NsEjhbHnTBR1FyCvhA2I=; b=TObbIFur2GvVDqK97FsOfZLNWYzvKnJ6A6N41JG5ax4Zuoe0hiBBGIQG sYE16wItYnqGHXbRB+uluGlSqopzFElOq5VgxgNPncrDFx4ODAblFISDz DgCo0ceTTHDOXW/5kBwEqVe/SARlkiqLyS5NO6c9djg9OIKHD7dUP9qF2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQDVvB9W/5FdJa1egllNgUK5HIQhAQ2BWYYcAoEzOBQBAQEBAQEBgQqEJgEBAQQtTBACAQgECgMDAQIBCSUPIx0IAQEEDgWILsNCAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Z2AYR9hHwRBwaEKAWGBAmQDgGNGpwOAR8BAUKEA3GFZwEBAQ X-IronPort-AV: E=Sophos; i="5.17,686,1437436800"; d="scan'208,217"; a="35999004" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 15 Oct 2015 14:50:00 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9FEo0RW014664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 14:50:00 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 09:49:45 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 09:49:45 -0500 From: "Ashish Dalela (adalela)" To: Henning Rogge Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAMVlgA///JMHQ= Date: Thu, 15 Oct 2015 14:49:45 +0000 Message-ID: <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.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 Content-Type: multipart/alternative; boundary="_000_30lejepapqucojc0oo0juiov1444920593548emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:50:11 -0000 --_000_30lejepapqucojc0oo0juiov1444920593548emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes it will and that's why I suggested the use of PFC. The control and data= planes will have different priorities. The radio never pauses the control = channel because it is never sent over the air. If desired, the data packet= s themselves could be given different priorities allowing some flows to be = selectively paused. Sent from Samsung Mobile -------- Original message -------- From: Henning Rogge Date:15/10/2015 18:36 (GMT+05:30) To: "Ashish Dalela (adalela)" Cc: manet@ietf.org Subject: Re: [manet] DLEP Credit Windowing On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) wrote: > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. = In > essence, we don=92t send credits before packets are forwarded. Rather we = pause > the traffic when the traffic cannot be forwarded and the buffers are full= . > PFC is widely used in a number of Ethernet flow-control scenarios today. Would a 802.3 PAUSE Frame not also block the DLEP control channel? Henning Rogge --_000_30lejepapqucojc0oo0juiov1444920593548emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Yes it will and that's why I suggested the use of PFC. The control and= data planes will have different priorities. The radio never pauses the con= trol channel because it is never sent over the air. If desired,  the d= ata packets themselves could be given different priorities allowing some flows to be selectively paused.


Sent from Samsung Mobile


-------- Original message --------
From: Henning Rogge
Date:15/10/2015 18:36 (GMT+05:30)
To: "Ashish Dalela (adalela)"
Cc: manet@ietf.org
Subject: Re: [manet] DLEP Credit Windowing

On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (ad= alela)
<adalela@cisco.com> wrote:
> The ideal mechanism for Ethernet flow control is the use of 802.3 PAUS= E
> frames, which has further been enhanced by the PFC (802.1Qbb) mechanis= m. In
> essence, we don=92t send credits before packets are forwarded. Rather = we pause
> the traffic when the traffic cannot be forwarded and the buffers are f= ull.
> PFC is widely used in a number of Ethernet flow-control scenarios toda= y.

Would a 802.3 PAUSE Frame not also block the DLEP control channel?

Henning Rogge
 --_000_30lejepapqucojc0oo0juiov1444920593548emailandroidcom_-- From nobody Thu Oct 15 07:53:08 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62A1B3354 for ; Thu, 15 Oct 2015 07:53:07 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYSQAARq3-wC for ; Thu, 15 Oct 2015 07:53:06 -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 B8F491B3353 for ; Thu, 15 Oct 2015 07:53:05 -0700 (PDT) Received: by lffy185 with SMTP id y185so30707698lff.2 for ; Thu, 15 Oct 2015 07:53:04 -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-type:content-transfer-encoding; bh=bEtIPLShUYXWk9uQb9I+u+933ckB0ddplOuufoqbFds=; b=XTBUfwRHH/d3XLJ+AvSjgRsWK8bOUFknAuedjcwS6QOxZJX2vHsLZFMsvAKYa2UA6O cS7M+E2RovzkrdILVCC2ILX8Z9z8Ughbn6xQCYL14jws4xh0lOf5mOCVayOvy8Ma8BlZ SoKOvHBZknuHdlM7bxoX3tYCOrYjf/dPusx9DJ7JUHSq+0pygCGGp3JMfbWV425g01E0 YmCkxqbCZR2JMX3v9eIWjxHD5o4EHx9L+owc/uY2VD2Wcs119ed4wX8d7tRQJ2VrhdSQ UHhgYdgfKiOmc7kV3eWQWCoU0Z43NGjlRhXSawKrpK4XtPaWnnY6zZhxa0+pkGzFcoqq uOqA== X-Received: by 10.180.8.197 with SMTP id t5mr19006761wia.90.1444920783876; Thu, 15 Oct 2015 07:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Thu, 15 Oct 2015 07:52:34 -0700 (PDT) In-Reply-To: <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> From: Henning Rogge Date: Thu, 15 Oct 2015 16:52:34 +0200 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 14:53:07 -0000 Hi, this sounds like a very interesting thing (we experimented with PAUSE for some time but didn't know about the extension)... do you know if its implemented in Linux? Henning Rogge On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) wrote: > Yes it will and that's why I suggested the use of PFC. The control and da= ta > planes will have different priorities. The radio never pauses the control > channel because it is never sent over the air. If desired, the data pack= ets > themselves could be given different priorities allowing some flows to be > selectively paused. > > > Sent from Samsung Mobile > > > -------- Original message -------- > From: Henning Rogge > Date:15/10/2015 18:36 (GMT+05:30) > To: "Ashish Dalela (adalela)" > Cc: manet@ietf.org > Subject: Re: [manet] DLEP Credit Windowing > > On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) > wrote: >> The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE >> frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. >> In >> essence, we don=E2=80=99t send credits before packets are forwarded. Rat= her we >> pause >> the traffic when the traffic cannot be forwarded and the buffers are ful= l. >> PFC is widely used in a number of Ethernet flow-control scenarios today. > > Would a 802.3 PAUSE Frame not also block the DLEP control channel? > > Henning Rogge From nobody Thu Oct 15 08:48:12 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97D1A1A02 for ; Thu, 15 Oct 2015 08:48:11 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV1gKdk-hxRK for ; Thu, 15 Oct 2015 08:48:08 -0700 (PDT) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (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 6F8091A01FC for ; Thu, 15 Oct 2015 08:48:07 -0700 (PDT) Received: by lffv3 with SMTP id v3so33515050lff.0 for ; Thu, 15 Oct 2015 08:48:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dcoyM5nD7kPbh4X9EAFIBGnqenTpfaCgFOHqwgfZvs4=; b=PAKBl88Z5/Egy8XsUBPxIEw/kfbKfCk3XdTTGrxn4FOUyd44d8L6YYYqfk9eXVf/zM x/mxih3JKrsHXgz4FqRCgKiSJz4P8dj8VeOyJADtPgaO3sua28H+qnrcSvovsLhL6106 EnCoCr/7x9gaXZI2hY93N3vCsmmvVTkr2zUVPeA8agB7I3CzMuRplE6dE05auyjN9PGT U7+M3wno+eDu6UQfHixCN2Up/O0WHPJxXUBsN24enAVBv/6aWz6Z7QTzi1FJjksV413R EwvRqA2JeqOHUoIrLeP+0RTRGQAMUKdm6Pi3ylIj8us5AdEj1MmjT8eZJSlqg28BCBCH 5pbQ== X-Gm-Message-State: ALoCoQnylcB4ivy0PZjZX7hkOBgLVd61FTnJXEAjsJNLcx4AT8sOB58ob1zFYJ0fWRWwteU3Oh/K X-Received: by 10.180.93.168 with SMTP id cv8mr36717846wib.54.1444924086231; Thu, 15 Oct 2015 08:48:06 -0700 (PDT) Received: from [192.168.43.109] ([188.207.122.87]) by smtp.gmail.com with ESMTPSA id e6sm24098528wiy.3.2015.10.15.08.48.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 08:48:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Teco Boot In-Reply-To: Date: Thu, 15 Oct 2015 17:48:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> To: Henning Rogge , "Ashish Dalela (adalela)" X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:48:11 -0000 PFC would be a HW or driver function. I don't think PFC solves flow control to remote nodes. This requires per = destination signaling. I agree on having a requirement for diffserv based packet dispatcher = with AQM and flow isolation. FIFO and priority queues should be = something of the past. This is to be discussed after having a = Credit-Windowing-00 draft.=20 Teco=20 =20 > Op 15 okt. 2015, om 16:52 heeft Henning Rogge het = volgende geschreven: >=20 > Hi, >=20 > this sounds like a very interesting thing (we experimented with PAUSE > for some time but didn't know about the extension)... do you know if > its implemented in Linux? >=20 > Henning Rogge >=20 > On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) > wrote: >> Yes it will and that's why I suggested the use of PFC. The control = and data >> planes will have different priorities. The radio never pauses the = control >> channel because it is never sent over the air. If desired, the data = packets >> themselves could be given different priorities allowing some flows to = be >> selectively paused. >>=20 >>=20 >> Sent from Samsung Mobile >>=20 >>=20 >> -------- Original message -------- >> From: Henning Rogge >> Date:15/10/2015 18:36 (GMT+05:30) >> To: "Ashish Dalela (adalela)" >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP Credit Windowing >>=20 >> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) >> wrote: >>> The ideal mechanism for Ethernet flow control is the use of 802.3 = PAUSE >>> frames, which has further been enhanced by the PFC (802.1Qbb) = mechanism. >>> In >>> essence, we don=E2=80=99t send credits before packets are forwarded. = Rather we >>> pause >>> the traffic when the traffic cannot be forwarded and the buffers are = full. >>> PFC is widely used in a number of Ethernet flow-control scenarios = today. >>=20 >> Would a 802.3 PAUSE Frame not also block the DLEP control channel? >>=20 >> Henning Rogge >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Oct 15 08:54:17 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032711A90BB for ; Thu, 15 Oct 2015 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx7P1WealmUN for ; Thu, 15 Oct 2015 08:54:15 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9051A8A28 for ; Thu, 15 Oct 2015 08:54:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,686,1437433200"; d="scan'208";a="12422911" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 15 Oct 2015 16:54:13 +0100 X-IronPort-AV: E=Sophos;i="5.17,686,1437433200"; d="scan'208";a="119992463" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 15 Oct 2015 16:54:12 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 16:54:12 +0100 From: "Dearlove, Christopher (UK)" To: Teco Boot , Henning Rogge , "Ashish Dalela (adalela)" Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3P///h0AgAAdAoCAAADJAIAAD4GA///t66A= Date: Thu, 15 Oct 2015 15:54:12 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:54:17 -0000 QXMgVGVjbyBpbmRpY2F0ZXMsIHRoZSBwbGFuIChJJ20gbm90IGFuIGF1dGhvciwgYnV0IEkgdGFs a2VkIHRvIG9uZSByZWNlbnRseSkgaXMgdG8gc2VwYXJhdGUgdGhlIGNyZWRpdCB3aW5kb3dpbmcg b3V0LiBTbyB0aGVzZSBkaXNjdXNzaW9ucyB3b24ndCBob2xkIHVwIHRoZSBtYWluIHBhcnQgb2Yg RExFUCwgYW5kIGl0IGJlaW5nIFdHTENlZCBhZ2Fpbi4NCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFy bG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6IMKgKzQ0ICgwKTEyNDUgMjQyMTk0IMKg fCDCoEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93 LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xh bmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFy Y2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBUZWNvIEJvb3QNClNlbnQ6IDE1IE9jdG9iZXIgMjAxNSAxNjo0OA0KVG86 IEhlbm5pbmcgUm9nZ2U7IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQpDYzogbWFuZXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVAgQ3JlZGl0IFdpbmRvd2luZw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWls cycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3Bp Y2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlM IC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9u Lg0KDQoNClBGQyB3b3VsZCBiZSBhIEhXIG9yIGRyaXZlciBmdW5jdGlvbi4NCkkgZG9uJ3QgdGhp bmsgUEZDIHNvbHZlcyBmbG93IGNvbnRyb2wgdG8gcmVtb3RlIG5vZGVzLiBUaGlzIHJlcXVpcmVz IHBlciBkZXN0aW5hdGlvbiBzaWduYWxpbmcuDQpJIGFncmVlIG9uIGhhdmluZyBhIHJlcXVpcmVt ZW50IGZvciBkaWZmc2VydiBiYXNlZCBwYWNrZXQgZGlzcGF0Y2hlciB3aXRoIEFRTSBhbmQgZmxv dyBpc29sYXRpb24uIEZJRk8gYW5kIHByaW9yaXR5IHF1ZXVlcyBzaG91bGQgYmUgc29tZXRoaW5n IG9mIHRoZSBwYXN0LiBUaGlzIGlzIHRvIGJlIGRpc2N1c3NlZCBhZnRlciBoYXZpbmcgYSBDcmVk aXQtV2luZG93aW5nLTAwIGRyYWZ0LiANCg0KVGVjbyANCg0KIA0KPiBPcCAxNSBva3QuIDIwMTUs IG9tIDE2OjUyIGhlZWZ0IEhlbm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFpbC5jb20+IGhldCB2b2xn ZW5kZSBnZXNjaHJldmVuOg0KPiANCj4gSGksDQo+IA0KPiB0aGlzIHNvdW5kcyBsaWtlIGEgdmVy eSBpbnRlcmVzdGluZyB0aGluZyAod2UgZXhwZXJpbWVudGVkIHdpdGggUEFVU0UgDQo+IGZvciBz b21lIHRpbWUgYnV0IGRpZG4ndCBrbm93IGFib3V0IHRoZSBleHRlbnNpb24pLi4uIGRvIHlvdSBr bm93IGlmIA0KPiBpdHMgaW1wbGVtZW50ZWQgaW4gTGludXg/DQo+IA0KPiBIZW5uaW5nIFJvZ2dl DQo+IA0KPiBPbiBUaHUsIE9jdCAxNSwgMjAxNSBhdCA0OjQ5IFBNLCBBc2hpc2ggRGFsZWxhIChh ZGFsZWxhKSANCj4gPGFkYWxlbGFAY2lzY28uY29tPiB3cm90ZToNCj4+IFllcyBpdCB3aWxsIGFu ZCB0aGF0J3Mgd2h5IEkgc3VnZ2VzdGVkIHRoZSB1c2Ugb2YgUEZDLiBUaGUgY29udHJvbCANCj4+ IGFuZCBkYXRhIHBsYW5lcyB3aWxsIGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMuIFRoZSByYWRp byBuZXZlciANCj4+IHBhdXNlcyB0aGUgY29udHJvbCBjaGFubmVsIGJlY2F1c2UgaXQgaXMgbmV2 ZXIgc2VudCBvdmVyIHRoZSBhaXIuIElmIA0KPj4gZGVzaXJlZCwgIHRoZSBkYXRhIHBhY2tldHMg dGhlbXNlbHZlcyBjb3VsZCBiZSBnaXZlbiBkaWZmZXJlbnQgDQo+PiBwcmlvcml0aWVzIGFsbG93 aW5nIHNvbWUgZmxvd3MgdG8gYmUgc2VsZWN0aXZlbHkgcGF1c2VkLg0KPj4gDQo+PiANCj4+IFNl bnQgZnJvbSBTYW1zdW5nIE1vYmlsZQ0KPj4gDQo+PiANCj4+IC0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS0NCj4+IEZyb206IEhlbm5pbmcgUm9nZ2UNCj4+IERhdGU6MTUvMTAvMjAx NSAxODozNiAoR01UKzA1OjMwKQ0KPj4gVG86ICJBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSINCj4+ IENjOiBtYW5ldEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQg V2luZG93aW5nDQo+PiANCj4+IE9uIFRodSwgT2N0IDE1LCAyMDE1IGF0IDI6MjUgUE0sIEFzaGlz aCBEYWxlbGEgKGFkYWxlbGEpIA0KPj4gPGFkYWxlbGFAY2lzY28uY29tPiB3cm90ZToNCj4+PiBU aGUgaWRlYWwgbWVjaGFuaXNtIGZvciBFdGhlcm5ldCBmbG93IGNvbnRyb2wgaXMgdGhlIHVzZSBv ZiA4MDIuMyANCj4+PiBQQVVTRSBmcmFtZXMsIHdoaWNoIGhhcyBmdXJ0aGVyIGJlZW4gZW5oYW5j ZWQgYnkgdGhlIFBGQyAoODAyLjFRYmIpIG1lY2hhbmlzbS4NCj4+PiBJbg0KPj4+IGVzc2VuY2Us IHdlIGRvbuKAmXQgc2VuZCBjcmVkaXRzIGJlZm9yZSBwYWNrZXRzIGFyZSBmb3J3YXJkZWQuIFJh dGhlciANCj4+PiB3ZSBwYXVzZSB0aGUgdHJhZmZpYyB3aGVuIHRoZSB0cmFmZmljIGNhbm5vdCBi ZSBmb3J3YXJkZWQgYW5kIHRoZSANCj4+PiBidWZmZXJzIGFyZSBmdWxsLg0KPj4+IFBGQyBpcyB3 aWRlbHkgdXNlZCBpbiBhIG51bWJlciBvZiBFdGhlcm5ldCBmbG93LWNvbnRyb2wgc2NlbmFyaW9z IHRvZGF5Lg0KPj4gDQo+PiBXb3VsZCBhIDgwMi4zIFBBVVNFIEZyYW1lIG5vdCBhbHNvIGJsb2Nr IHRoZSBETEVQIGNvbnRyb2wgY2hhbm5lbD8NCj4+IA0KPj4gSGVubmluZyBSb2dnZQ0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQg bWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqClRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRl ZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From nobody Thu Oct 15 08:59:39 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17A51A92AE for ; Thu, 15 Oct 2015 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlO8oxBd4ukq for ; Thu, 15 Oct 2015 08:59:37 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5031A916F for ; Thu, 15 Oct 2015 08:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3992; q=dns/txt; s=iport; t=1444924777; x=1446134377; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p79j5al7utHBBtvo4Kn1Dyz0sGmluPupsZxiUDljaWo=; b=c8ehyVd06KqEAzX22jubKdZPSSAzJwJpsgJFuig2WSFepiYqcCI/PB8a H8BWIM5odEhj35qF3sOgYqQDMlPijfAw5uwI6CVwYK2RbdbLEws3hOi8N COZLTqXmLqwZCF4cDdADPEge9NwrcNNaXJwfC5SsYtBXsvsvhMoP862HR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQAfzB9W/4UNJK1egyZUbga9NwENgVkXCoV7AhyBGTgUAQEBAQEBAYEKhCYBAQEDAQEBASAROgsFBwQCAQgRAwEBAQECAiMDAgICHwYLFAEICAEBBAENBQiIEQMKCA2wDY4cDYURAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIoVUAYR9glCCIhsHBoJjgUUFhgQJkA4BiyaBbZRNh0gBHwEBQoQDcYRhgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,686,1437436800"; d="scan'208";a="198369618" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 15 Oct 2015 15:59:36 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9FFxagZ008047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 15:59:36 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 10:59:21 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 10:59:21 -0500 From: "Ashish Dalela (adalela)" To: Teco Boot , Henning Rogge Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAMVlgA///JMHSAAFSbAIAAD4CAgABRcWA= Date: Thu, 15 Oct 2015 15:59:21 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.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.65.54.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:59:39 -0000 DQo+PiBJIGRvbid0IHRoaW5rIFBGQyBzb2x2ZXMgZmxvdyBjb250cm9sIHRvIHJlbW90ZSBub2Rl cy4gVGhpcyByZXF1aXJlcyBwZXIgZGVzdGluYXRpb24gc2lnbmFsaW5nLg0KDQpXaGF0IHJlbW90 ZSBub2RlcyBhcmUgd2UgdGFsa2luZyBhYm91dD8gSSB0aG91Z2h0IHRoZSByYWRpbyBpcyBkaXJl Y3RseSBjb25uZWN0ZWQgdG8gYSByb3V0ZXIuIEhvd2V2ZXIsIGV2ZW4gaWYgd2UgYXNzdW1lIHRo ZXJlIGlzIGEgdHJhbnNwYXJlbnQgYnJpZGdlIGluIGJldHdlZW4sIGFuZCBpZiB0aGUgYnJpZGdl IHN1cHBvcnRzIFBGQywgdGhlbiB0aGUgcmFkaW8gd2lsbCBzZWxlY3RpdmVseSBwYXVzZSB0aGUg YnJpZGdlIHdoaWNoIHdpbGwgYnVmZmVyIHBhY2tldHMgdW50aWwgaXQgcnVucyBvdXQgb2YgdGhl IGJ1ZmZlciBhbmQgdGhlbiBwYXVzZXMgdGhlIHJvdXRlci4gDQoNClBGQyB3b3JrcyBmb3IgYW55 IG51bWJlciBvZiBuZXR3b3JrIGRldmljZXMgYXMgbG9uZyBhcyBhbGwgdGhvc2UgZGV2aWNlcyBz dXBwb3J0IFBGQy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRlY28gQm9v dCBbbWFpbHRvOnRlY29AaW5mLW5ldC5ubF0gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwg MjAxNSA5OjE4IFBNDQpUbzogSGVubmluZyBSb2dnZSA8aHJvZ2dlQGdtYWlsLmNvbT47IEFzaGlz aCBEYWxlbGEgKGFkYWxlbGEpIDxhZGFsZWxhQGNpc2NvLmNvbT4NCkNjOiBtYW5ldEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQgV2luZG93aW5nDQoNClBGQyB3b3Vs ZCBiZSBhIEhXIG9yIGRyaXZlciBmdW5jdGlvbi4NCkkgZG9uJ3QgdGhpbmsgUEZDIHNvbHZlcyBm bG93IGNvbnRyb2wgdG8gcmVtb3RlIG5vZGVzLiBUaGlzIHJlcXVpcmVzIHBlciBkZXN0aW5hdGlv biBzaWduYWxpbmcuDQpJIGFncmVlIG9uIGhhdmluZyBhIHJlcXVpcmVtZW50IGZvciBkaWZmc2Vy diBiYXNlZCBwYWNrZXQgZGlzcGF0Y2hlciB3aXRoIEFRTSBhbmQgZmxvdyBpc29sYXRpb24uIEZJ Rk8gYW5kIHByaW9yaXR5IHF1ZXVlcyBzaG91bGQgYmUgc29tZXRoaW5nIG9mIHRoZSBwYXN0LiBU aGlzIGlzIHRvIGJlIGRpc2N1c3NlZCBhZnRlciBoYXZpbmcgYSBDcmVkaXQtV2luZG93aW5nLTAw IGRyYWZ0LiANCg0KVGVjbyANCg0KIA0KPiBPcCAxNSBva3QuIDIwMTUsIG9tIDE2OjUyIGhlZWZ0 IEhlbm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFpbC5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVu Og0KPiANCj4gSGksDQo+IA0KPiB0aGlzIHNvdW5kcyBsaWtlIGEgdmVyeSBpbnRlcmVzdGluZyB0 aGluZyAod2UgZXhwZXJpbWVudGVkIHdpdGggUEFVU0UgDQo+IGZvciBzb21lIHRpbWUgYnV0IGRp ZG4ndCBrbm93IGFib3V0IHRoZSBleHRlbnNpb24pLi4uIGRvIHlvdSBrbm93IGlmIA0KPiBpdHMg aW1wbGVtZW50ZWQgaW4gTGludXg/DQo+IA0KPiBIZW5uaW5nIFJvZ2dlDQo+IA0KPiBPbiBUaHUs IE9jdCAxNSwgMjAxNSBhdCA0OjQ5IFBNLCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSANCj4gPGFk YWxlbGFAY2lzY28uY29tPiB3cm90ZToNCj4+IFllcyBpdCB3aWxsIGFuZCB0aGF0J3Mgd2h5IEkg c3VnZ2VzdGVkIHRoZSB1c2Ugb2YgUEZDLiBUaGUgY29udHJvbCANCj4+IGFuZCBkYXRhIHBsYW5l cyB3aWxsIGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMuIFRoZSByYWRpbyBuZXZlciANCj4+IHBh dXNlcyB0aGUgY29udHJvbCBjaGFubmVsIGJlY2F1c2UgaXQgaXMgbmV2ZXIgc2VudCBvdmVyIHRo ZSBhaXIuIElmIA0KPj4gZGVzaXJlZCwgIHRoZSBkYXRhIHBhY2tldHMgdGhlbXNlbHZlcyBjb3Vs ZCBiZSBnaXZlbiBkaWZmZXJlbnQgDQo+PiBwcmlvcml0aWVzIGFsbG93aW5nIHNvbWUgZmxvd3Mg dG8gYmUgc2VsZWN0aXZlbHkgcGF1c2VkLg0KPj4gDQo+PiANCj4+IFNlbnQgZnJvbSBTYW1zdW5n IE1vYmlsZQ0KPj4gDQo+PiANCj4+IC0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0N Cj4+IEZyb206IEhlbm5pbmcgUm9nZ2UNCj4+IERhdGU6MTUvMTAvMjAxNSAxODozNiAoR01UKzA1 OjMwKQ0KPj4gVG86ICJBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSINCj4+IENjOiBtYW5ldEBpZXRm Lm9yZw0KPj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQgV2luZG93aW5nDQo+PiAN Cj4+IE9uIFRodSwgT2N0IDE1LCAyMDE1IGF0IDI6MjUgUE0sIEFzaGlzaCBEYWxlbGEgKGFkYWxl bGEpIA0KPj4gPGFkYWxlbGFAY2lzY28uY29tPiB3cm90ZToNCj4+PiBUaGUgaWRlYWwgbWVjaGFu aXNtIGZvciBFdGhlcm5ldCBmbG93IGNvbnRyb2wgaXMgdGhlIHVzZSBvZiA4MDIuMyANCj4+PiBQ QVVTRSBmcmFtZXMsIHdoaWNoIGhhcyBmdXJ0aGVyIGJlZW4gZW5oYW5jZWQgYnkgdGhlIFBGQyAo ODAyLjFRYmIpIG1lY2hhbmlzbS4NCj4+PiBJbg0KPj4+IGVzc2VuY2UsIHdlIGRvbuKAmXQgc2Vu ZCBjcmVkaXRzIGJlZm9yZSBwYWNrZXRzIGFyZSBmb3J3YXJkZWQuIFJhdGhlciANCj4+PiB3ZSBw YXVzZSB0aGUgdHJhZmZpYyB3aGVuIHRoZSB0cmFmZmljIGNhbm5vdCBiZSBmb3J3YXJkZWQgYW5k IHRoZSANCj4+PiBidWZmZXJzIGFyZSBmdWxsLg0KPj4+IFBGQyBpcyB3aWRlbHkgdXNlZCBpbiBh IG51bWJlciBvZiBFdGhlcm5ldCBmbG93LWNvbnRyb2wgc2NlbmFyaW9zIHRvZGF5Lg0KPj4gDQo+ PiBXb3VsZCBhIDgwMi4zIFBBVVNFIEZyYW1lIG5vdCBhbHNvIGJsb2NrIHRoZSBETEVQIGNvbnRy b2wgY2hhbm5lbD8NCj4+IA0KPj4gSGVubmluZyBSb2dnZQ0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFuZXQgbWFpbGluZyBsaXN0DQo+ IG1hbmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQNCg0K From nobody Thu Oct 15 09:02:05 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE11AC3C8 for ; Thu, 15 Oct 2015 09:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YuOBPV34f0w for ; Thu, 15 Oct 2015 09:02:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D0E1ABD8F for ; Thu, 15 Oct 2015 09:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6636; q=dns/txt; s=iport; t=1444924921; x=1446134521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d5zM+udBzkymDOxEDPudDg4XJFCrB1oqvYqcVgZ7b1g=; b=F3yJrhKQsBLY+jehxcNw67ZUmspMtom0G6PhchvF8JFSx5dBUzUdpP3v 2afLbGL4iaNTfHyyvzSU3/tNHkcEL6f1P9YmrTBMY6MEldm8Nrpi+X02i 80orr/77GQ2gsfHrkKKaqovSTB8yWBIbfNn9WM0DxSF+8LB/6l4z9B4yj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWBQCWzB9W/4YNJK1egyZUbga9RYFZFwqFewIcgRk6EgEBAQEBAQGBCoQmAQEBAwEBAQEgERUlAwgFBwQCAQgRAwEBAQECAiMDAgICHwYLFAEICAIEAQ0FCIgRAwoIDbAOjh0NhREBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKFVAGEfYJQgVoKBwEKLBsHBoJjgUUFhgQJgTCOXgGLJoFtgV+EOo40C4NPg24BKAgzhANxhB4JFyOBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,686,1437436800"; d="scan'208";a="41750613" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2015 16:02:00 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9FG20hm026272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 16:02:00 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 11:01:45 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 11:01:45 -0500 From: "Ashish Dalela (adalela)" To: "Dearlove, Christopher (UK)" , Teco Boot , Henning Rogge Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAMVlgA///JMHSAAFSbAIAAD4CAgAABuACAAFJZ4A== Date: Thu, 15 Oct 2015 16:01:45 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.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.65.54.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:02:03 -0000 DQpUaGF0IGlzIGdvb2QgdGhlbi4gTXkgcG9pbnQgaXMgdGhhdCB3ZSBzaG91bGQgcmVtb3ZlIGNy ZWRpdCB3aW5kb3dpbmcgZnJvbSB0aGlzIGRyYWZ0IGJlZm9yZSB3ZSB0YWtlIGl0IHRvIFJGQy4g V2UgY2FuIHRoZW4gc2VwYXJhdGVseSBkaXNjdXNzIGNyZWRpdHMgKG9yIGFuIGVxdWl2YWxlbnQg c2NoZW1lIHdob3NlIHB1cnBvc2Ugd291bGQgYmUgdG8gYWxsb3cgYSBjb25zaXN0ZW50IHNjaGVt ZSB0aGF0IGNhbiBiZSBwcmFjdGljYWxseSBpbXBsZW1lbnRlZCBpbiBib3RoIGNvbnZlcmdlZCBh bmQgc2VwYXJhdGVkIGNvbnRyb2wvZGF0YSBwbGFuZXMpLg0KCQ0KVGhhbmtzDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSBbbWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tXSANClNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDE1LCAyMDE1IDk6MjQgUE0NClRvOiBUZWNvIEJvb3QgPHRlY29AaW5mLW5ldC5ubD47IEhl bm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFpbC5jb20+OyBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8 YWRhbGVsYUBjaXNjby5jb20+DQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbWFu ZXRdIERMRVAgQ3JlZGl0IFdpbmRvd2luZw0KDQpBcyBUZWNvIGluZGljYXRlcywgdGhlIHBsYW4g KEknbSBub3QgYW4gYXV0aG9yLCBidXQgSSB0YWxrZWQgdG8gb25lIHJlY2VudGx5KSBpcyB0byBz ZXBhcmF0ZSB0aGUgY3JlZGl0IHdpbmRvd2luZyBvdXQuIFNvIHRoZXNlIGRpc2N1c3Npb25zIHdv bid0IGhvbGQgdXAgdGhlIG1haW4gcGFydCBvZiBETEVQLCBhbmQgaXQgYmVpbmcgV0dMQ2VkIGFn YWluLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5l ZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpUOiDCoCs0NCAoMCkxMjQ1IDI0MjE5NCDCoHwgwqBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbQ0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4N Cnd3dy5iYWVzeXN0ZW1zLmNvbS9haQ0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTEgUmVnaXN0 ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1Uy IDdZUA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFttYWls dG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlY28gQm9vdA0KU2VudDog MTUgT2N0b2JlciAyMDE1IDE2OjQ4DQpUbzogSGVubmluZyBSb2dnZTsgQXNoaXNoIERhbGVsYSAo YWRhbGVsYSkNCkNjOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBD cmVkaXQgV2luZG93aW5nDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBv dXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20g dGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGlj ayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRo ZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3Ry dWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCioqKiBX QVJOSU5HICoqKg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJv bSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uDQoNCg0KUEZDIHdvdWxkIGJlIGEgSFcgb3IgZHJp dmVyIGZ1bmN0aW9uLg0KSSBkb24ndCB0aGluayBQRkMgc29sdmVzIGZsb3cgY29udHJvbCB0byBy ZW1vdGUgbm9kZXMuIFRoaXMgcmVxdWlyZXMgcGVyIGRlc3RpbmF0aW9uIHNpZ25hbGluZy4NCkkg YWdyZWUgb24gaGF2aW5nIGEgcmVxdWlyZW1lbnQgZm9yIGRpZmZzZXJ2IGJhc2VkIHBhY2tldCBk aXNwYXRjaGVyIHdpdGggQVFNIGFuZCBmbG93IGlzb2xhdGlvbi4gRklGTyBhbmQgcHJpb3JpdHkg cXVldWVzIHNob3VsZCBiZSBzb21ldGhpbmcgb2YgdGhlIHBhc3QuIFRoaXMgaXMgdG8gYmUgZGlz Y3Vzc2VkIGFmdGVyIGhhdmluZyBhIENyZWRpdC1XaW5kb3dpbmctMDAgZHJhZnQuIA0KDQpUZWNv IA0KDQogDQo+IE9wIDE1IG9rdC4gMjAxNSwgb20gMTY6NTIgaGVlZnQgSGVubmluZyBSb2dnZSA8 aHJvZ2dlQGdtYWlsLmNvbT4gaGV0IHZvbGdlbmRlIGdlc2NocmV2ZW46DQo+IA0KPiBIaSwNCj4g DQo+IHRoaXMgc291bmRzIGxpa2UgYSB2ZXJ5IGludGVyZXN0aW5nIHRoaW5nICh3ZSBleHBlcmlt ZW50ZWQgd2l0aCBQQVVTRSANCj4gZm9yIHNvbWUgdGltZSBidXQgZGlkbid0IGtub3cgYWJvdXQg dGhlIGV4dGVuc2lvbikuLi4gZG8geW91IGtub3cgaWYgDQo+IGl0cyBpbXBsZW1lbnRlZCBpbiBM aW51eD8NCj4gDQo+IEhlbm5pbmcgUm9nZ2UNCj4gDQo+IE9uIFRodSwgT2N0IDE1LCAyMDE1IGF0 IDQ6NDkgUE0sIEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpIA0KPiA8YWRhbGVsYUBjaXNjby5jb20+ IHdyb3RlOg0KPj4gWWVzIGl0IHdpbGwgYW5kIHRoYXQncyB3aHkgSSBzdWdnZXN0ZWQgdGhlIHVz ZSBvZiBQRkMuIFRoZSBjb250cm9sIA0KPj4gYW5kIGRhdGEgcGxhbmVzIHdpbGwgaGF2ZSBkaWZm ZXJlbnQgcHJpb3JpdGllcy4gVGhlIHJhZGlvIG5ldmVyIA0KPj4gcGF1c2VzIHRoZSBjb250cm9s IGNoYW5uZWwgYmVjYXVzZSBpdCBpcyBuZXZlciBzZW50IG92ZXIgdGhlIGFpci4gSWYgDQo+PiBk ZXNpcmVkLCAgdGhlIGRhdGEgcGFja2V0cyB0aGVtc2VsdmVzIGNvdWxkIGJlIGdpdmVuIGRpZmZl cmVudCANCj4+IHByaW9yaXRpZXMgYWxsb3dpbmcgc29tZSBmbG93cyB0byBiZSBzZWxlY3RpdmVs eSBwYXVzZWQuDQo+PiANCj4+IA0KPj4gU2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlDQo+PiANCj4+ IA0KPj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPj4gRnJvbTogSGVubmlu ZyBSb2dnZQ0KPj4gRGF0ZToxNS8xMC8yMDE1IDE4OjM2IChHTVQrMDU6MzApDQo+PiBUbzogIkFz aGlzaCBEYWxlbGEgKGFkYWxlbGEpIg0KPj4gQ2M6IG1hbmV0QGlldGYub3JnDQo+PiBTdWJqZWN0 OiBSZTogW21hbmV0XSBETEVQIENyZWRpdCBXaW5kb3dpbmcNCj4+IA0KPj4gT24gVGh1LCBPY3Qg MTUsIDIwMTUgYXQgMjoyNSBQTSwgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgDQo+PiA8YWRhbGVs YUBjaXNjby5jb20+IHdyb3RlOg0KPj4+IFRoZSBpZGVhbCBtZWNoYW5pc20gZm9yIEV0aGVybmV0 IGZsb3cgY29udHJvbCBpcyB0aGUgdXNlIG9mIDgwMi4zIA0KPj4+IFBBVVNFIGZyYW1lcywgd2hp Y2ggaGFzIGZ1cnRoZXIgYmVlbiBlbmhhbmNlZCBieSB0aGUgUEZDICg4MDIuMVFiYikgbWVjaGFu aXNtLg0KPj4+IEluDQo+Pj4gZXNzZW5jZSwgd2UgZG9u4oCZdCBzZW5kIGNyZWRpdHMgYmVmb3Jl IHBhY2tldHMgYXJlIGZvcndhcmRlZC4gUmF0aGVyIA0KPj4+IHdlIHBhdXNlIHRoZSB0cmFmZmlj IHdoZW4gdGhlIHRyYWZmaWMgY2Fubm90IGJlIGZvcndhcmRlZCBhbmQgdGhlIA0KPj4+IGJ1ZmZl cnMgYXJlIGZ1bGwuDQo+Pj4gUEZDIGlzIHdpZGVseSB1c2VkIGluIGEgbnVtYmVyIG9mIEV0aGVy bmV0IGZsb3ctY29udHJvbCBzY2VuYXJpb3MgdG9kYXkuDQo+PiANCj4+IFdvdWxkIGEgODAyLjMg UEFVU0UgRnJhbWUgbm90IGFsc28gYmxvY2sgdGhlIERMRVAgY29udHJvbCBjaGFubmVsPw0KPj4g DQo+PiBIZW5uaW5nIFJvZ2dlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBs aXN0DQptYW5ldEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldA0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgcGxlYXNlIGRl bGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91 bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3Ig ZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQo= From nobody Thu Oct 15 09:06:33 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3231B2DE5 for ; Thu, 15 Oct 2015 09:06:31 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OfpdWxJjwST for ; Thu, 15 Oct 2015 09:06:30 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 6D9FD1B2DC7 for ; Thu, 15 Oct 2015 09:06:27 -0700 (PDT) Received: by qkas79 with SMTP id s79so41393945qka.0 for ; Thu, 15 Oct 2015 09:06: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZAmhKFHW5UpG49PCmq2egVbEZsjUhIlgn2vmFfC2rd0=; b=AQQ1txrGrBt47I7It+widYks2RdZUO7DUdYKlZrI/l6oPGHKyENXjkHhrOWl0k6OTP gc+vDrDcEpLEzpQoumf1WEo4WrZxDwiJ1PstGkwMdAp0d+xXqM8H0K1kFXQAz9l2DphA GzzQjVe34vHK5NuRa8n18t2y7iaNpT8qwrYyXOx2EU/yOc7KTXkUK8onbAhoScxAG9QI zg+Dg9hDVDVVFt2VTfdEEvuQUDfinWdNXBasnLeistBrLHEkNli+nSA07ayT84iItc4D wsksmGBmtHwJhd3stt4GAgme3PM4RN5tpHTBlRdP/MDkXSxdXol+nYYPGLdlTYYyARC5 jIVg== X-Received: by 10.194.191.161 with SMTP id gz1mr5135130wjc.0.1444925186614; Thu, 15 Oct 2015 09:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Thu, 15 Oct 2015 09:05:57 -0700 (PDT) In-Reply-To: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> From: Henning Rogge Date: Thu, 15 Oct 2015 18:05:57 +0200 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:06:31 -0000 On Thu, Oct 15, 2015 at 5:59 PM, Ashish Dalela (adalela) wrote: > >>> I don't think PFC solves flow control to remote nodes. This requires pe= r destination signaling. > > What remote nodes are we talking about? I thought the radio is directly c= onnected to a router. However, even if we assume there is a transparent bri= dge in between, and if the bridge supports PFC, then the radio will selecti= vely pause the bridge which will buffer packets until it runs out of the bu= ffer and then pauses the router. > > PFC works for any number of network devices as long as all those devices = support PFC. Teco is right... one router, connected to one radio... which connects it to any number of other radios. one of the outgoing queues to a neighbor might be full, another one might be empty. With the PAUSE frame (QoS aware or not) you can only block the whole connection between radio and router, but not per neighbor (as defined by the destination MAC address). Henning Rogge From nobody Thu Oct 15 09:07:38 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BBC1A6F49 for ; Thu, 15 Oct 2015 09:07:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV1t62ES-rX4 for ; Thu, 15 Oct 2015 09:07:33 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010: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 800891A92B3 for ; Thu, 15 Oct 2015 09:07:32 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so74480597lbc.3 for ; Thu, 15 Oct 2015 09:07: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:content-type:content-transfer-encoding; bh=qKvS7aGIq9SOz782B5sGzMz1tNco90mByFQf+N7gvWM=; b=FRxJzKE1JdUNEU3VH1zdtKIFhIM7FZUwv+F0vQ7zEu0vtj5kxS+DphPG1dqNr5WvIa UjzIy4//5iGCrKv0qwjKaJQcCoJkIKoCU6lz3vkbnhxanaNYEP1xNwzhJBgBdlz4aZ8c o2IUgkoiYD5RD/b3HfYDde+Yop9l1vPAU80+ZANmO9n1guSdxMSHFNT+4DqTIAcZcxCC 9K9EqF+CENpZ3twCPXbm+BZVvTm8zCGOLfVH4gu4G4wYF95wnvInzUvKOHTitxYQpaXl 2Ox6KX32r3f3u8XYBLBWxb0MY7u6kdMkticgeVZgxg6BoEyNYj0aeMeH737d55oXKE9A RVcA== X-Received: by 10.195.11.72 with SMTP id eg8mr12957892wjd.14.1444925250005; Thu, 15 Oct 2015 09:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Thu, 15 Oct 2015 09:07:00 -0700 (PDT) In-Reply-To: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> From: Henning Rogge Date: Thu, 15 Oct 2015 18:07:00 +0200 Message-ID: To: "Ashish Dalela (adalela)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:07:35 -0000 It would also enable this working group to define other "credit/flow control" schemes without taking away the possible compatibility with the PPPoE extension. Henning Rogge On Thu, Oct 15, 2015 at 6:01 PM, Ashish Dalela (adalela) wrote: > > That is good then. My point is that we should remove credit windowing fro= m this draft before we take it to RFC. We can then separately discuss credi= ts (or an equivalent scheme whose purpose would be to allow a consistent sc= heme that can be practically implemented in both converged and separated co= ntrol/data planes). > > Thanks > > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] > Sent: Thursday, October 15, 2015 9:24 PM > To: Teco Boot ; Henning Rogge ; Ashish= Dalela (adalela) > Cc: manet@ietf.org > Subject: RE: [manet] DLEP Credit Windowing > > As Teco indicates, the plan (I'm not an author, but I talked to one recen= tly) is to separate the credit windowing out. So these discussions won't ho= ld up the main part of DLEP, and it being WGLCed again. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > _________________________________________________________________________= _ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > 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 > > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot > Sent: 15 October 2015 16:48 > To: Henning Rogge; Ashish Dalela (adalela) > Cc: manet@ietf.org > Subject: Re: [manet] DLEP Credit Windowing > > ----------------------! WARNING ! ---------------------- This message ori= ginates 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 attach= ments 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. > > > PFC would be a HW or driver function. > I don't think PFC solves flow control to remote nodes. This requires per = destination signaling. > I agree on having a requirement for diffserv based packet dispatcher with= AQM and flow isolation. FIFO and priority queues should be something of th= e past. This is to be discussed after having a Credit-Windowing-00 draft. > > Teco > > >> Op 15 okt. 2015, om 16:52 heeft Henning Rogge het vol= gende geschreven: >> >> Hi, >> >> this sounds like a very interesting thing (we experimented with PAUSE >> for some time but didn't know about the extension)... do you know if >> its implemented in Linux? >> >> Henning Rogge >> >> On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) >> wrote: >>> Yes it will and that's why I suggested the use of PFC. The control >>> and data planes will have different priorities. The radio never >>> pauses the control channel because it is never sent over the air. If >>> desired, the data packets themselves could be given different >>> priorities allowing some flows to be selectively paused. >>> >>> >>> Sent from Samsung Mobile >>> >>> >>> -------- Original message -------- >>> From: Henning Rogge >>> Date:15/10/2015 18:36 (GMT+05:30) >>> To: "Ashish Dalela (adalela)" >>> Cc: manet@ietf.org >>> Subject: Re: [manet] DLEP Credit Windowing >>> >>> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) >>> wrote: >>>> The ideal mechanism for Ethernet flow control is the use of 802.3 >>>> PAUSE frames, which has further been enhanced by the PFC (802.1Qbb) me= chanism. >>>> In >>>> essence, we don=E2=80=99t send credits before packets are forwarded. R= ather >>>> we pause the traffic when the traffic cannot be forwarded and the >>>> buffers are full. >>>> PFC is widely used in a number of Ethernet flow-control scenarios toda= y. >>> >>> Would a 802.3 PAUSE Frame not also block the DLEP control channel? >>> >>> 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 > ******************************************************************** > This email and any attachments are confidential to the intended recipient= and may also be privileged. If you are not the intended recipient please d= elete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or distribu= te its contents to any other person. > ******************************************************************** From nobody Thu Oct 15 09:16:14 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3791AC44A for ; Thu, 15 Oct 2015 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzW_mVyC_zly for ; Thu, 15 Oct 2015 09:16:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95631AC43C for ; Thu, 15 Oct 2015 09:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1444925770; x=1446135370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=McWeg8WPV1+X4ntyOEPiSxRQcfZFFJOd868Bg9XuHp0=; b=aftnb54CPmJG1FAibxg3ITSoIdZ0+yQK0f0OKXX+kmssqAG/MTWHfq6d 20VmSQPpLVVF52pFwPll7C2meeJ1vQlL3YCC3yr7UNYNu8/VdagtZniSS /wxDSBxS7XOGEiPVZnrawpSym56Mtfcf+g5owr0PopeNYRqxPFwbserzI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQC+0B9W/40NJK1egyaBQga5FoQhAQ2BWYYcAhyBGTgUAQEBAQEBAYEKhCYBAQEEIxFFDAQCAQgOAwQBAQECAiMDAgICHxEUAQgIAgQOBQiIEQMSsBiOHA2FEQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIoVUAYR9glCCPQcGgmOBRQWWGwGLJoFtlE2HSAEfAQFChANxhGGBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,686,1437436800"; d="scan'208";a="197792300" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 15 Oct 2015 16:16:10 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9FGGARv025905 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 16:16:10 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 11:15:55 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 11:15:55 -0500 From: "Ashish Dalela (adalela)" To: Henning Rogge Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAMVlgA///JMHSAAFSbAIAAD4CAgABRcWD//7OPgIAAUqew Date: Thu, 15 Oct 2015 16:15:55 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.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.65.54.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:16:12 -0000 T0ssIEkgdW5kZXJzdGFuZCBub3cuIFlvdSBhcmUgc2F5aW5nIHRoYXQgc2luY2UgQ3JlZGl0cyBh cmUgY29taW5nIHdpdGggdGhlIE5laWdoYm9yIHVwZGF0ZXMsIHRoZXkgYXJlIGFib3V0IHRoZSBu ZWlnaGJvci4gVGhhdCdzIGEgZmFpciBwb2ludC4gV2l0aCBQRkMgeW91IGNvdWxkIHN1cHBvcnQg dXAgdG8gNyBuZWlnaGJvcnMgKHdpdGggb25lIHByaW9yaXR5IGxlZnQgZm9yIGNvbnRyb2wgcGxh bmUpLiBJdCBtYXkgb3Igbm90IG1heSBub3QgYmUgZW5vdWdoLCBhbmQgZm9yIGRlc2lnbiByZWFz b25zIHdlIG1pZ2h0IG5vdCBsaWtlIGl0LiBJIGNhbiB0aGluayBvZiBzb21lIGFsdGVybmF0aXZl cywgYnV0IGluc3RlYWQgb2YgbXVkZHlpbmcgdGhlIHdhdGVycyBub3csIGxldCdzIGRlZmVyIHRo aXMgaXNzdWUgdG8gYSBkaXNjdXNzaW9uIGluIGEgbGF0ZXIgZHJhZnQsIHNvIGxvbmcgYXMgd2Ug Y2FuIHJlbW92ZSB0aGUgY3JlZGl0IHdpbmRvd2luZyBmcm9tIERMRVAgZHJhZnQuDQoNClRoYW5r cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGVubmluZyBSb2dnZSBbbWFp bHRvOmhyb2dnZUBnbWFpbC5jb21dIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMTUg OTozNiBQTQ0KVG86IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpIDxhZGFsZWxhQGNpc2NvLmNvbT4N CkNjOiBUZWNvIEJvb3QgPHRlY29AaW5mLW5ldC5ubD47IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW21hbmV0XSBETEVQIENyZWRpdCBXaW5kb3dpbmcNCg0KT24gVGh1LCBPY3QgMTUsIDIw MTUgYXQgNTo1OSBQTSwgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgPGFkYWxlbGFAY2lzY28uY29t PiB3cm90ZToNCj4NCj4+PiBJIGRvbid0IHRoaW5rIFBGQyBzb2x2ZXMgZmxvdyBjb250cm9sIHRv IHJlbW90ZSBub2Rlcy4gVGhpcyByZXF1aXJlcyBwZXIgZGVzdGluYXRpb24gc2lnbmFsaW5nLg0K Pg0KPiBXaGF0IHJlbW90ZSBub2RlcyBhcmUgd2UgdGFsa2luZyBhYm91dD8gSSB0aG91Z2h0IHRo ZSByYWRpbyBpcyBkaXJlY3RseSBjb25uZWN0ZWQgdG8gYSByb3V0ZXIuIEhvd2V2ZXIsIGV2ZW4g aWYgd2UgYXNzdW1lIHRoZXJlIGlzIGEgdHJhbnNwYXJlbnQgYnJpZGdlIGluIGJldHdlZW4sIGFu ZCBpZiB0aGUgYnJpZGdlIHN1cHBvcnRzIFBGQywgdGhlbiB0aGUgcmFkaW8gd2lsbCBzZWxlY3Rp dmVseSBwYXVzZSB0aGUgYnJpZGdlIHdoaWNoIHdpbGwgYnVmZmVyIHBhY2tldHMgdW50aWwgaXQg cnVucyBvdXQgb2YgdGhlIGJ1ZmZlciBhbmQgdGhlbiBwYXVzZXMgdGhlIHJvdXRlci4NCj4NCj4g UEZDIHdvcmtzIGZvciBhbnkgbnVtYmVyIG9mIG5ldHdvcmsgZGV2aWNlcyBhcyBsb25nIGFzIGFs bCB0aG9zZSBkZXZpY2VzIHN1cHBvcnQgUEZDLg0KDQpUZWNvIGlzIHJpZ2h0Li4uDQoNCm9uZSBy b3V0ZXIsIGNvbm5lY3RlZCB0byBvbmUgcmFkaW8uLi4gd2hpY2ggY29ubmVjdHMgaXQgdG8gYW55 IG51bWJlciBvZiBvdGhlciByYWRpb3MuDQoNCm9uZSBvZiB0aGUgb3V0Z29pbmcgcXVldWVzIHRv IGEgbmVpZ2hib3IgbWlnaHQgYmUgZnVsbCwgYW5vdGhlciBvbmUgbWlnaHQgYmUgZW1wdHkuDQoN CldpdGggdGhlIFBBVVNFIGZyYW1lIChRb1MgYXdhcmUgb3Igbm90KSB5b3UgY2FuIG9ubHkgYmxv Y2sgdGhlIHdob2xlIGNvbm5lY3Rpb24gYmV0d2VlbiByYWRpbyBhbmQgcm91dGVyLCBidXQgbm90 IHBlciBuZWlnaGJvciAoYXMgZGVmaW5lZCBieSB0aGUgZGVzdGluYXRpb24gTUFDIGFkZHJlc3Mp Lg0KDQpIZW5uaW5nIFJvZ2dlDQo= From nobody Thu Oct 15 10:28:58 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A37E1ACE55 for ; Thu, 15 Oct 2015 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id indT96g0aBBI for ; Thu, 15 Oct 2015 10:28:54 -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 A71591ACE3F for ; Thu, 15 Oct 2015 10:28:53 -0700 (PDT) IronPort-PHdr: 9a23:012jRRwPy8nnq1HXCy+O+j09IxM/srCxBDY+r6Qd1+gXIJqq85mqBkHD//Il1AaPBtWHraIVwLOP6ujJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6OyZTmnLnrotX6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFmrPHs4FPqVguO/XtUfmwSnx5BS0jM4Bj+U5P482Gy4uNx0S2XOcTeRrEvUjPk5KBuHlugwgsKPiQ993/azoRbjLhauw6mvxxy2caUXaLUfrIqdaPHfMhcSWdIRMJWSSFpCIqxdJoUE+cEJqBTqIyr4xMyoBC5TSOrA/+nniNFjXje3Ks0luIsDUfA2FpkV5guvXLSrdP6fJ0VXu+4huGczS/EYPxb8Tj44YnMNBsmpKffc6h3dJ+b80AzEwLLgBHYkpDsOTeYx65F53OB5vZkVOyho28rqht8qSTpwMow3NqazrkJw0zJoH0qiL0+Ise1HQsiOYap X-IronPort-AV: E=Sophos;i="5.17,686,1437451200"; d="scan'208";a="113230" X-IPAS-Result: A2CgBAAS4R9W/8r6+gpeHAEBAYNbbga/FwcXCoV7AhyBVxEBAQEBAQEBAYEJgh+CBwEBAQEDAQEBIBEVJQMIDAQCAQgRAwEBAQECAiMDAgICHwYLFAEICAIEAQ0FCIgRAxcIsAKOIA2FEQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIoVWhHyCUIFaCgcBCiwbBwaCY4FFBYYECYEwjl4BiyaBbYFfhDqONAuDT4NvN4QvcYQeCTqBBgEBAQ From: "Ratliff, Stanley" To: "Ashish Dalela (adalela)" , "Dearlove, Christopher (UK)" , Teco Boot , "Henning Rogge" Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAKPeYAAAOgMoAAABkvAAAB8A+AAAA2/AAAAEOBgAAFmlvw Date: Thu, 15 Oct 2015 17:28:49 +0000 Message-ID: <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.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="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:28:56 -0000 SGVsbG8gYWxsLCANCg0KV2VsbCwgSSBhbSBhbiBhdXRob3IsIHNvIEkgdGhpbmsgSSBjYW4gc3Bl YWsgYXV0aG9yaXRhdGl2ZWx5Li4uIDstKSANCg0KWWVzLCB0aGUgY3JlZGl0LXdpbmRvd2luZyBp cyBzcGxpdCBvdXQuIENyZWRpdCB3aW5kb3dpbmcgd2lsbCBiZSBpbnRyb2R1Y2VkIGFzIGEgd29y a2luZyBncm91cCBkb2N1bWVudCAoc3BsaXR0aW5nIGEgV0cgZG9jIGludG8gdHdvIGRvY3MgaW1w bGllcyB0aGF0IGJvdGggYXJlIGFscmVhZHkgV0cgZG9jcykuIEZ1cnRoZXIsIHRoZSBkb2NzIChE TEVQIGFuZCBDcmVkaXQgV2luZG93aW5nKSB3aWxsIGNvbnRhaW4gbm9ybWF0aXZlIHJlZmVyZW5j ZXMgdG8gZWFjaCBvdGhlciwgc28gdGhleSB3aWxsIHByb2dyZXNzIGluIGxvY2stc3RlcC4gWW91 IGNhbiBleHBlY3QgdGhlIHN1Ym1pc3Npb25zIHdpdGhpbiB0aGUgbmV4dCBkYXkgb3IgdHdvLiAN Cg0KVGhlIGNyZWRpdCB3aW5kb3dpbmcgZHJhZnQgaXMgd3JpdHRlbiBhcyBhbiBleHRlbnNpb24g dG8gRExFUC4gSXQgaXMgbm90LCBieSBkZWZpbml0aW9uLCBhbiBleHByZXNzaW9uIG9mIHRoZSAq b25seSBmb3JtKiBvZiBwb3NzaWJsZSBmbG93IGNvbnRyb2wuIEJ5IHRoYXQsIEkgbWVhbiB0aGF0 IGEgZGlzY3Vzc2lvbiBvbiBQQVVTRSBmcmFtZXMsIG9yIHNvbWUgZXF1aXZhbGVudCBzY2hlbWUs IGRvZXMgKm5vdCogbmVjZXNzYXJpbHkgaW52YWxpZGF0ZSBjcmVkaXQgd2luZG93aW5nLiBJZiAg dGhlcmUgaXMgaW50ZXJlc3QgaW4gY3JlYXRpbmcgYW5vdGhlciBkcmFmdCB3aXRoIGFuIGFkZGl0 aW9uYWwgc2NoZW1lLCBJIHdvdWxkIGVuY291cmFnZSBzb21lb25lIGluIHRoZSBXRyB0byBzdGVw IHVwIHRvIHRoZSBwbGF0ZSBhbmQgd3JpdGUgaXQuDQoNCldpdGggdGhlIG5vcm1hdGl2ZSBjcm9z cy1yZWZlcmVuY2luZywgYSByZS1saXRpZ2F0aW9uIG9mIGNyZWRpdCB3aW5kb3dpbmcgKndpbGwq IGhvbGQgdXAgRExFUC4gDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBBc2hpc2ggRGFsZWxhDQo+IChhZGFsZWxhKQ0KPiBTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAxNSwgMjAxNSAxMjowMiBQTQ0KPiBUbzogRGVhcmxvdmUsIENocmlzdG9waGVy IChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPjsgVGVjbw0KPiBCb290IDx0ZWNv QGluZi1uZXQubmw+OyBIZW5uaW5nIFJvZ2dlIDxocm9nZ2VAZ21haWwuY29tPg0KPiBDYzogbWFu ZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQgV2luZG93aW5n DQo+IA0KPiANCj4gVGhhdCBpcyBnb29kIHRoZW4uIE15IHBvaW50IGlzIHRoYXQgd2Ugc2hvdWxk IHJlbW92ZSBjcmVkaXQgd2luZG93aW5nIGZyb20NCj4gdGhpcyBkcmFmdCBiZWZvcmUgd2UgdGFr ZSBpdCB0byBSRkMuIFdlIGNhbiB0aGVuIHNlcGFyYXRlbHkgZGlzY3VzcyBjcmVkaXRzIChvcg0K PiBhbiBlcXVpdmFsZW50IHNjaGVtZSB3aG9zZSBwdXJwb3NlIHdvdWxkIGJlIHRvIGFsbG93IGEg Y29uc2lzdGVudCBzY2hlbWUNCj4gdGhhdCBjYW4gYmUgcHJhY3RpY2FsbHkgaW1wbGVtZW50ZWQg aW4gYm90aCBjb252ZXJnZWQgYW5kIHNlcGFyYXRlZA0KPiBjb250cm9sL2RhdGEgcGxhbmVzKS4N Cj4gDQo+IFRoYW5rcw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgW21haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMTUgOToyNCBQTQ0KPiBU bzogVGVjbyBCb290IDx0ZWNvQGluZi1uZXQubmw+OyBIZW5uaW5nIFJvZ2dlIDxocm9nZ2VAZ21h aWwuY29tPjsNCj4gQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkgPGFkYWxlbGFAY2lzY28uY29tPg0K PiBDYzogbWFuZXRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFttYW5ldF0gRExFUCBDcmVkaXQg V2luZG93aW5nDQo+IA0KPiBBcyBUZWNvIGluZGljYXRlcywgdGhlIHBsYW4gKEknbSBub3QgYW4g YXV0aG9yLCBidXQgSSB0YWxrZWQgdG8gb25lIHJlY2VudGx5KSBpcw0KPiB0byBzZXBhcmF0ZSB0 aGUgY3JlZGl0IHdpbmRvd2luZyBvdXQuIFNvIHRoZXNlIGRpc2N1c3Npb25zIHdvbid0IGhvbGQg dXAgdGhlDQo+IG1haW4gcGFydCBvZiBETEVQLCBhbmQgaXQgYmVpbmcgV0dMQ2VkIGFnYWluLg0K PiANCj4gLS0NCj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4gU2VuaW9yIFByaW5jaXBhbCBFbmdp bmVlcg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX19f X19fX19fX18NCj4gDQo+IFQ6IMKgKzQ0ICgwKTEyNDUgMjQyMTk0IMKgfCDCoEU6IGNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tDQo+IA0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0DQo+IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi4NCj4gd3d3LmJhZXN5c3RlbXMuY29tL2FpDQo+IEJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYg V2FsZXMgTm86DQo+IDAxMzM3NDUxIFJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMg0KPiA3WVANCj4gDQo+IA0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVjbyBCb290DQo+IFNlbnQ6IDE1IE9jdG9iZXIgMjAx NSAxNjo0OA0KPiBUbzogSGVubmluZyBSb2dnZTsgQXNoaXNoIERhbGVsYSAoYWRhbGVsYSkNCj4g Q2M6IG1hbmV0QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVAgQ3JlZGl0IFdp bmRvd2luZw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMNCj4gZnJvbSBvdXRzaWRlIG91 ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0 aGUNCj4gaW50ZXJuZXQuDQo+IENvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQg Y2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueQ0KPiBhdHRhY2htZW50cyBvciByZXBseS4NCj4g Rm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMg Zm9yIGluc3RydWN0aW9ucyBvbg0KPiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdl cy4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+ICoqKiBXQVJOSU5HICoqKg0KPiBFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlvbi4NCj4gDQo+IA0K PiBQRkMgd291bGQgYmUgYSBIVyBvciBkcml2ZXIgZnVuY3Rpb24uDQo+IEkgZG9uJ3QgdGhpbmsg UEZDIHNvbHZlcyBmbG93IGNvbnRyb2wgdG8gcmVtb3RlIG5vZGVzLiBUaGlzIHJlcXVpcmVzIHBl cg0KPiBkZXN0aW5hdGlvbiBzaWduYWxpbmcuDQo+IEkgYWdyZWUgb24gaGF2aW5nIGEgcmVxdWly ZW1lbnQgZm9yIGRpZmZzZXJ2IGJhc2VkIHBhY2tldCBkaXNwYXRjaGVyIHdpdGgNCj4gQVFNIGFu ZCBmbG93IGlzb2xhdGlvbi4gRklGTyBhbmQgcHJpb3JpdHkgcXVldWVzIHNob3VsZCBiZSBzb21l dGhpbmcgb2YgdGhlDQo+IHBhc3QuIFRoaXMgaXMgdG8gYmUgZGlzY3Vzc2VkIGFmdGVyIGhhdmlu ZyBhIENyZWRpdC1XaW5kb3dpbmctMDAgZHJhZnQuDQo+IA0KPiBUZWNvDQo+IA0KPiANCj4gPiBP cCAxNSBva3QuIDIwMTUsIG9tIDE2OjUyIGhlZWZ0IEhlbm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFp bC5jb20+IGhldA0KPiB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPiA+DQo+ID4gSGksDQo+ID4NCj4g PiB0aGlzIHNvdW5kcyBsaWtlIGEgdmVyeSBpbnRlcmVzdGluZyB0aGluZyAod2UgZXhwZXJpbWVu dGVkIHdpdGggUEFVU0UNCj4gPiBmb3Igc29tZSB0aW1lIGJ1dCBkaWRuJ3Qga25vdyBhYm91dCB0 aGUgZXh0ZW5zaW9uKS4uLiBkbyB5b3Uga25vdyBpZg0KPiA+IGl0cyBpbXBsZW1lbnRlZCBpbiBM aW51eD8NCj4gPg0KPiA+IEhlbm5pbmcgUm9nZ2UNCj4gPg0KPiA+IE9uIFRodSwgT2N0IDE1LCAy MDE1IGF0IDQ6NDkgUE0sIEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+ID4gPGFkYWxlbGFAY2lz Y28uY29tPiB3cm90ZToNCj4gPj4gWWVzIGl0IHdpbGwgYW5kIHRoYXQncyB3aHkgSSBzdWdnZXN0 ZWQgdGhlIHVzZSBvZiBQRkMuIFRoZSBjb250cm9sDQo+ID4+IGFuZCBkYXRhIHBsYW5lcyB3aWxs IGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMuIFRoZSByYWRpbyBuZXZlcg0KPiA+PiBwYXVzZXMg dGhlIGNvbnRyb2wgY2hhbm5lbCBiZWNhdXNlIGl0IGlzIG5ldmVyIHNlbnQgb3ZlciB0aGUgYWly LiBJZg0KPiA+PiBkZXNpcmVkLCAgdGhlIGRhdGEgcGFja2V0cyB0aGVtc2VsdmVzIGNvdWxkIGJl IGdpdmVuIGRpZmZlcmVudA0KPiA+PiBwcmlvcml0aWVzIGFsbG93aW5nIHNvbWUgZmxvd3MgdG8g YmUgc2VsZWN0aXZlbHkgcGF1c2VkLg0KPiA+Pg0KPiA+Pg0KPiA+PiBTZW50IGZyb20gU2Ftc3Vu ZyBNb2JpbGUNCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0tLQ0KPiA+PiBGcm9tOiBIZW5uaW5nIFJvZ2dlDQo+ID4+IERhdGU6MTUvMTAvMjAxNSAxODoz NiAoR01UKzA1OjMwKQ0KPiA+PiBUbzogIkFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpIg0KPiA+PiBD YzogbWFuZXRAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQg V2luZG93aW5nDQo+ID4+DQo+ID4+IE9uIFRodSwgT2N0IDE1LCAyMDE1IGF0IDI6MjUgUE0sIEFz aGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+ID4+IDxhZGFsZWxhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ ID4+PiBUaGUgaWRlYWwgbWVjaGFuaXNtIGZvciBFdGhlcm5ldCBmbG93IGNvbnRyb2wgaXMgdGhl IHVzZSBvZiA4MDIuMw0KPiA+Pj4gUEFVU0UgZnJhbWVzLCB3aGljaCBoYXMgZnVydGhlciBiZWVu IGVuaGFuY2VkIGJ5IHRoZSBQRkMgKDgwMi4xUWJiKQ0KPiBtZWNoYW5pc20uDQo+ID4+PiBJbg0K PiA+Pj4gZXNzZW5jZSwgd2UgZG9u4oCZdCBzZW5kIGNyZWRpdHMgYmVmb3JlIHBhY2tldHMgYXJl IGZvcndhcmRlZC4gUmF0aGVyDQo+ID4+PiB3ZSBwYXVzZSB0aGUgdHJhZmZpYyB3aGVuIHRoZSB0 cmFmZmljIGNhbm5vdCBiZSBmb3J3YXJkZWQgYW5kIHRoZQ0KPiA+Pj4gYnVmZmVycyBhcmUgZnVs bC4NCj4gPj4+IFBGQyBpcyB3aWRlbHkgdXNlZCBpbiBhIG51bWJlciBvZiBFdGhlcm5ldCBmbG93 LWNvbnRyb2wgc2NlbmFyaW9zIHRvZGF5Lg0KPiA+Pg0KPiA+PiBXb3VsZCBhIDgwMi4zIFBBVVNF IEZyYW1lIG5vdCBhbHNvIGJsb2NrIHRoZSBETEVQIGNvbnRyb2wgY2hhbm5lbD8NCj4gPj4NCj4g Pj4gSGVubmluZyBSb2dnZQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gPiBtYW5ldEBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1h bmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gKioqKioqKioqKg0KPiBUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVj aXBpZW50DQo+IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZQ0KPiBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBh bmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+IFlvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IgZGlzdHJpYnV0ZSBpdHMNCj4gY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAqKioqKioqKioqDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlz dA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGNvbnRhaW5zCmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwgd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5CmFuZC9vciBjb25maWRlbnRpYWwuIEl0IGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbApvciBlbnRpdHkgdG8gd2hv bSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbApyZWNpcGll bnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGUgZW1haWwgdG8g dGhlCmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2aXNlZCB0aGF0IHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwKaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZv cndhcmRpbmcsIHByaW50aW5nLCBvcgpjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= From nobody Thu Oct 15 10:59:18 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C731B33EB for ; Thu, 15 Oct 2015 10:59:16 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4Vd0Ta0vCMv for ; Thu, 15 Oct 2015 10:59:14 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010: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 A44751B33DB for ; Thu, 15 Oct 2015 10:59:13 -0700 (PDT) Received: by lbwr8 with SMTP id r8so78786257lbw.2 for ; Thu, 15 Oct 2015 10:59:11 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=VyEB9onZK5/m0gOMCGEHRoPLn82fb4Ei5F6NfdAqOjI=; b=Ni6ZHfl7/1m0OgM9esn7Cr9kLKdTByR9wsr3X7SrDWhh3xaKetkBmL8sQddxERyk9Q 32zbbwidT0uwk+sqNoWo92ibsnbgOOlUdlWT7D8mYrRd0wqTMb7PcLS7w+bzWzW1agPU 6VdThW3haEULk+peRBsHxSZiXAb4UTsiJyZbBnDNx7V12KPoYG3iKQGj/BOEFR0Ry+xW pmndAbeEjtnfAytCSmaH/tbG/A0MpWwXlq4ZFu9uSkKjI03TXFNfFKWc5tDYBTxrCOHi adpPRXe2VXRYkwIUEQW62fobRUfCy3SmhqfSc8Y6Qa3GLeZOlj7RYYINMd2QwCtYmPIl kRug== X-Received: by 10.194.114.133 with SMTP id jg5mr11741560wjb.98.1444931951685; Thu, 15 Oct 2015 10:59:11 -0700 (PDT) Received: from [10.7.196.158] (dab-yat1-h-47-7.dab.02.net. [82.132.214.201]) by smtp.gmail.com with ESMTPSA id p4sm55319wia.15.2015.10.15.10.59.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 10:59:11 -0700 (PDT) References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> Mime-Version: 1.0 (1.0) In-Reply-To: <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Thu, 15 Oct 2015 18:59:07 +0100 To: "Ratliff, Stanley" Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:59:16 -0000 Why should the credit windowing draft be referenced from the main draft? It'= s an extension, and not having that reference means that the main draft, ove= r which I see a lot less controversy, wouldn't get held up by any delay (suc= h as resolving this discussion) to credit windowing. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Oct 2015, at 18:28, Ratliff, Stanley wrote: >=20 > Hello all,=20 >=20 > Well, I am an author, so I think I can speak authoritatively... ;-)=20 >=20 > Yes, the credit-windowing is split out. Credit windowing will be introduce= d as a working group document (splitting a WG doc into two docs implies that= both are already WG docs). Further, the docs (DLEP and Credit Windowing) wi= ll contain normative references to each other, so they will progress in lock= -step. You can expect the submissions within the next day or two.=20 >=20 > The credit windowing draft is written as an extension to DLEP. It is not, b= y definition, an expression of the *only form* of possible flow control. By t= hat, I mean that a discussion on PAUSE frames, or some equivalent scheme, do= es *not* necessarily invalidate credit windowing. If there is interest in c= reating another draft with an additional scheme, I would encourage someone i= n the WG to step up to the plate and write it. >=20 > With the normative cross-referencing, a re-litigation of credit windowing *= will* hold up DLEP.=20 >=20 > Regards, > Stan >=20 >=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish Dalela >> (adalela) >> Sent: Thursday, October 15, 2015 12:02 PM >> To: Dearlove, Christopher (UK) ; Teco >> Boot ; Henning Rogge >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP Credit Windowing >>=20 >>=20 >> That is good then. My point is that we should remove credit windowing fro= m >> this draft before we take it to RFC. We can then separately discuss credi= ts (or >> an equivalent scheme whose purpose would be to allow a consistent scheme >> that can be practically implemented in both converged and separated >> control/data planes). >>=20 >> Thanks >>=20 >> -----Original Message----- >> From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] >> Sent: Thursday, October 15, 2015 9:24 PM >> To: Teco Boot ; Henning Rogge ; >> Ashish Dalela (adalela) >> Cc: manet@ietf.org >> Subject: RE: [manet] DLEP Credit Windowing >>=20 >> As Teco indicates, the plan (I'm not an author, but I talked to one recen= tly) is >> to separate the credit windowing out. So these discussions won't hold up t= he >> main part of DLEP, and it being WGLCed again. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence >> __________________________________________________________ >> ________________ >>=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 >>=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot >> Sent: 15 October 2015 16:48 >> To: Henning Rogge; Ashish Dalela (adalela) >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP Credit Windowing >>=20 >> ----------------------! WARNING ! ---------------------- This message ori= ginates >> from outside our organisation, either from an external partner or from th= e >> 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 >> PFC would be a HW or driver function. >> I don't think PFC solves flow control to remote nodes. This requires per >> destination signaling. >> I agree on having a requirement for diffserv based packet dispatcher with= >> AQM and flow isolation. FIFO and priority queues should be something of t= he >> past. This is to be discussed after having a Credit-Windowing-00 draft. >>=20 >> Teco >>=20 >>=20 >>>> Op 15 okt. 2015, om 16:52 heeft Henning Rogge het >>> volgende geschreven: >>>=20 >>> Hi, >>>=20 >>> this sounds like a very interesting thing (we experimented with PAUSE >>> for some time but didn't know about the extension)... do you know if >>> its implemented in Linux? >>>=20 >>> Henning Rogge >>>=20 >>> On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) >>> wrote: >>>> Yes it will and that's why I suggested the use of PFC. The control >>>> and data planes will have different priorities. The radio never >>>> pauses the control channel because it is never sent over the air. If >>>> desired, the data packets themselves could be given different >>>> priorities allowing some flows to be selectively paused. >>>>=20 >>>>=20 >>>> Sent from Samsung Mobile >>>>=20 >>>>=20 >>>> -------- Original message -------- >>>> From: Henning Rogge >>>> Date:15/10/2015 18:36 (GMT+05:30) >>>> To: "Ashish Dalela (adalela)" >>>> Cc: manet@ietf.org >>>> Subject: Re: [manet] DLEP Credit Windowing >>>>=20 >>>> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) >>>> wrote: >>>>> The ideal mechanism for Ethernet flow control is the use of 802.3 >>>>> PAUSE frames, which has further been enhanced by the PFC (802.1Qbb) >> mechanism. >>>>> In >>>>> essence, we don=E2=80=99t send credits before packets are forwarded. R= ather >>>>> we pause the traffic when the traffic cannot be forwarded and the >>>>> buffers are full. >>>>> PFC is widely used in a number of Ethernet flow-control scenarios toda= y. >>>>=20 >>>> Would a 802.3 PAUSE Frame not also block the DLEP control channel? >>>>=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 >> ********************************************************** >> ********** >> 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 distribu= te its >> contents to any other person. >> ********************************************************** >> ********** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _____________________________________________________ > 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 Thu Oct 15 11:28:57 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E890B1AD09D for ; Thu, 15 Oct 2015 11:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv8wE_YJfkXp for ; Thu, 15 Oct 2015 11:28:53 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 13D861AD06A for ; Thu, 15 Oct 2015 11:28:52 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t9FIR64O020446; Thu, 15 Oct 2015 14:28:50 -0400 From: "Wiggins, David - 0665 - MITLL" To: Christopher Dearlove , "Ratliff, Stanley" Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAKPeYAAAOgMoAAABkvAAAB8A+AAAA2/AAAAEOBgAAFmlvw///z94D//8RYAA== Date: Thu, 15 Oct 2015 18:25:37 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> In-Reply-To: <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3527763936_46226553" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-15_16:2015-10-15,2015-10-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510150222 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 18:28:57 -0000 --B_3527763936_46226553 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I agree with Chris. I thought the main advantage of splitting the documents was so that core DLEP could proceed independent of credit windowing. David On 10/15/15, 1:59 PM, "manet on behalf of Christopher Dearlove" wrote: >Why should the credit windowing draft be referenced from the main draft? >It's an extension, and not having that reference means that the main >draft, over which I see a lot less controversy, wouldn't get held up by >any delay (such as resolving this discussion) to credit windowing. > >--=20 >Christopher Dearlove >christopher.dearlove@gmail.com (iPhone) >chris@mnemosyne.demon.co.uk (home) > >> On 15 Oct 2015, at 18:28, Ratliff, Stanley wrote: >>=20 >> Hello all,=20 >>=20 >> Well, I am an author, so I think I can speak authoritatively... ;-) >>=20 >> Yes, the credit-windowing is split out. Credit windowing will be >>introduced as a working group document (splitting a WG doc into two docs >>implies that both are already WG docs). Further, the docs (DLEP and >>Credit Windowing) will contain normative references to each other, so >>they will progress in lock-step. You can expect the submissions within >>the next day or two. >>=20 >> The credit windowing draft is written as an extension to DLEP. It is >>not, by definition, an expression of the *only form* of possible flow >>control. By that, I mean that a discussion on PAUSE frames, or some >>equivalent scheme, does *not* necessarily invalidate credit windowing. >>If there is interest in creating another draft with an additional >>scheme, I would encourage someone in the WG to step up to the plate and >>write it. >>=20 >> With the normative cross-referencing, a re-litigation of credit >>windowing *will* hold up DLEP. >>=20 >> Regards, >> Stan >>=20 >>=20 >>> -----Original Message----- >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish Dalela >>> (adalela) >>> Sent: Thursday, October 15, 2015 12:02 PM >>> To: Dearlove, Christopher (UK) ; Teco >>> Boot ; Henning Rogge >>> Cc: manet@ietf.org >>> Subject: Re: [manet] DLEP Credit Windowing >>>=20 >>>=20 >>> That is good then. My point is that we should remove credit windowing >>>from >>> this draft before we take it to RFC. We can then separately discuss >>>credits (or >>> an equivalent scheme whose purpose would be to allow a consistent >>>scheme >>> that can be practically implemented in both converged and separated >>> control/data planes). >>>=20 >>> Thanks >>>=20 >>> -----Original Message----- >>> From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] >>> Sent: Thursday, October 15, 2015 9:24 PM >>> To: Teco Boot ; Henning Rogge ; >>> Ashish Dalela (adalela) >>> Cc: manet@ietf.org >>> Subject: RE: [manet] DLEP Credit Windowing >>>=20 >>> As Teco indicates, the plan (I'm not an author, but I talked to one >>>recently) is >>> to separate the credit windowing out. So these discussions won't hold >>>up the >>> main part of DLEP, and it being WGLCed again. >>>=20 >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence >>> __________________________________________________________ >>> ________________ >>>=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 >>>=20 >>> -----Original Message----- >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot >>> Sent: 15 October 2015 16:48 >>> To: Henning Rogge; Ashish Dalela (adalela) >>> Cc: manet@ietf.org >>> Subject: Re: [manet] DLEP Credit Windowing >>>=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 >>> PFC would be a HW or driver function. >>> I don't think PFC solves flow control to remote nodes. This requires >>>per >>> destination signaling. >>> I agree on having a requirement for diffserv based packet dispatcher >>>with >>> AQM and flow isolation. FIFO and priority queues should be something >>>of the >>> past. This is to be discussed after having a Credit-Windowing-00 draft. >>>=20 >>> Teco >>>=20 >>>=20 >>>>> Op 15 okt. 2015, om 16:52 heeft Henning Rogge het >>>> volgende geschreven: >>>>=20 >>>> Hi, >>>>=20 >>>> this sounds like a very interesting thing (we experimented with PAUSE >>>> for some time but didn't know about the extension)... do you know if >>>> its implemented in Linux? >>>>=20 >>>> Henning Rogge >>>>=20 >>>> On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) >>>> wrote: >>>>> Yes it will and that's why I suggested the use of PFC. The control >>>>> and data planes will have different priorities. The radio never >>>>> pauses the control channel because it is never sent over the air. If >>>>> desired, the data packets themselves could be given different >>>>> priorities allowing some flows to be selectively paused. >>>>>=20 >>>>>=20 >>>>> Sent from Samsung Mobile >>>>>=20 >>>>>=20 >>>>> -------- Original message -------- >>>>> From: Henning Rogge >>>>> Date:15/10/2015 18:36 (GMT+05:30) >>>>> To: "Ashish Dalela (adalela)" >>>>> Cc: manet@ietf.org >>>>> Subject: Re: [manet] DLEP Credit Windowing >>>>>=20 >>>>> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) >>>>> wrote: >>>>>> The ideal mechanism for Ethernet flow control is the use of 802.3 >>>>>> PAUSE frames, which has further been enhanced by the PFC (802.1Qbb) >>> mechanism. >>>>>> In >>>>>> essence, we don=B9t send credits before packets are forwarded. Rather >>>>>> we pause the traffic when the traffic cannot be forwarded and the >>>>>> buffers are full. >>>>>> PFC is widely used in a number of Ethernet flow-control scenarios >>>>>>today. >>>>>=20 >>>>> Would a 802.3 PAUSE Frame not also block the DLEP control channel? >>>>>=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 >>> ********************************************************** >>> ********** >>> 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 >> _____________________________________________________ >> 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 > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet --B_3527763936_46226553 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFJmELM+LRP4mjOB1 FYPUPQmRijwzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTAxNTE4MjUzNlowDQYJKoZIhvcNAQEBBQAEggEAT6XW47pW9Wv42x1LYtV5WxtzpeDnyFng 8OzqBrFn8I84e3xajwWfPQy5oI2kz7ZImpLucZx6OThuolwLO3i7+pslVe9TRHzmzmZA97AG kDLsnRPaFl3ImLkEc55BtDJo35r0FQkxB7Z7X1o9TraHFCxXUeCNnY4VnHCrkTZ+TQBiLUBU GPiSV1coWoBf8A9ww27WUqmZLxIOGcG1vBLZYhh7Lla42nidMIjoSugLyKxh0h/CbtZvPNUj sIHspNYWJlMDsfbf6M1ylmMyUWFFjg/gdY7nFQYhzd82e3UV4iKbm/ENqfKMc+h7uDmkZNrT JXO/lyLm4fMQgENd9D1NrQ== --B_3527763936_46226553-- From nobody Thu Oct 15 11:35:26 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234FC1B3440 for ; Thu, 15 Oct 2015 11:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zim766F8yEsy for ; Thu, 15 Oct 2015 11:35:22 -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 1A9901AD0CD for ; Thu, 15 Oct 2015 11:35:22 -0700 (PDT) IronPort-PHdr: 9a23:ejBh0h3d2sR3XBiFsmDT+DRfVm0co7zxezQtwd8Zse4SLfad9pjvdHbS+e9qxAeQG96Lt7QU2qGP6fuocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC04LnhqvrocabSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskyJcgqA6XoaSSFevhNWAgSNqVmiAMms+m6yk8tB/A3QdZnaRK41VXKd7qhkSRnzoCMDcTs47CfahtEmyOoRixK7pgdjxJbUbZvdGPd3ZKfaY95QDT5KXtxQTDBGGoOxdc0DAuMbOeFGoqHyolIPqV21Agz6QKvN1yRUh3m+8aAz1ax1GwzM0QkpBM4Dqlzbqdz0MOEZVuXjiOGC5DHdZulRkQ3w9IHOe1hhqOuBQbt2eIubgR0mDQ7Zh1OZgYfkJDiSkO8Ktj7IwfBnULflsWc7rwB/rHzn/dsljI3El8hdnkve/Dl9wYg7Ddy0SVR2asLiFpZM4XLJf7BqS98vFjk78B0xzacL7NviJHAH X-IronPort-AV: E=Sophos;i="5.17,686,1437451200"; d="scan'208";a="114739" X-IPAS-Result: A2CfBACc8R9W/8n6+gpeDg4BAQGDW24GvUWBVQQXCoV4AwICgXMTAQEBAQEBAQGBCYIfggcBAQEBAwEBAUYlAwgMBAIBCBEDAQEBAScHIQYLFAkIAgQBDQUIiBEDFwi+Lg2FEQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGeIN2gQaCUIFaCgcBCkIFBwaEKAWGBAmBMIYLiFUBiyaBbYFfhDqONQuDT4NvIwGEBD5xAYQdCTqBBgEBAQ From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , "Christopher Dearlove" , Justin Dean , "Alvaro Retana (aretana)" Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAKPeYAAAOgMoAAABkvAAAB8A+AAAA2/AAAAEOBgAAFmlvw///z94D//8RYAP///rxw Date: Thu, 15 Oct 2015 18:34:37 +0000 Message-ID: <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.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="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 18:35:25 -0000 Sigh... There's nothing like re-litigating things that happened 3 to 4 years ago. F= olks, if we keep churning on this, we'll never accomplish anything. = The base DLEP draft normatively references Credit windowing as an example o= f *how* to do an extension. The Credit windowing draft is the extension. = Nothing says that credit windowing will be the *only* extension (in fact, I= 've heard of other extension drafts in the works). Also, *nothing* says tha= t the credit windowing extension will be the only (or the best) draft for f= low control. = Let's stop making "the good" the enemy of "the perfect", and actually accom= plish something before the WG gets shutdown for not producing anything. = Alvaro and Justin - please feel free to comment. = Stan > -----Original Message----- > From: Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] > Sent: Thursday, October 15, 2015 2:26 PM > To: Christopher Dearlove ; Ratliff, Stanl= ey > > Cc: manet@ietf.org > Subject: Re: [manet] DLEP Credit Windowing > = > I agree with Chris. I thought the main advantage of splitting the > documents was so that core DLEP could proceed independent of credit > windowing. > = > David > = > On 10/15/15, 1:59 PM, "manet on behalf of Christopher Dearlove" > > wrote: > = > >Why should the credit windowing draft be referenced from the main draft? > >It's an extension, and not having that reference means that the main > >draft, over which I see a lot less controversy, wouldn't get held up by > >any delay (such as resolving this discussion) to credit windowing. > > > >-- > >Christopher Dearlove > >christopher.dearlove@gmail.com (iPhone) > >chris@mnemosyne.demon.co.uk (home) > > > >> On 15 Oct 2015, at 18:28, Ratliff, Stanley wrot= e: > >> > >> Hello all, > >> > >> Well, I am an author, so I think I can speak authoritatively... ;-) > >> > >> Yes, the credit-windowing is split out. Credit windowing will be > >>introduced as a working group document (splitting a WG doc into two docs > >>implies that both are already WG docs). Further, the docs (DLEP and > >>Credit Windowing) will contain normative references to each other, so > >>they will progress in lock-step. You can expect the submissions within > >>the next day or two. > >> > >> The credit windowing draft is written as an extension to DLEP. It is > >>not, by definition, an expression of the *only form* of possible flow > >>control. By that, I mean that a discussion on PAUSE frames, or some > >>equivalent scheme, does *not* necessarily invalidate credit windowing. > >>If there is interest in creating another draft with an additional > >>scheme, I would encourage someone in the WG to step up to the plate > and > >>write it. > >> > >> With the normative cross-referencing, a re-litigation of credit > >>windowing *will* hold up DLEP. > >> > >> Regards, > >> Stan > >> > >> > >>> -----Original Message----- > >>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish > Dalela > >>> (adalela) > >>> Sent: Thursday, October 15, 2015 12:02 PM > >>> To: Dearlove, Christopher (UK) ; > Teco > >>> Boot ; Henning Rogge > >>> Cc: manet@ietf.org > >>> Subject: Re: [manet] DLEP Credit Windowing > >>> > >>> > >>> That is good then. My point is that we should remove credit windowing > >>>from > >>> this draft before we take it to RFC. We can then separately discuss > >>>credits (or > >>> an equivalent scheme whose purpose would be to allow a consistent > >>>scheme > >>> that can be practically implemented in both converged and separated > >>> control/data planes). > >>> > >>> Thanks > >>> > >>> -----Original Message----- > >>> From: Dearlove, Christopher (UK) > [mailto:chris.dearlove@baesystems.com] > >>> Sent: Thursday, October 15, 2015 9:24 PM > >>> To: Teco Boot ; Henning Rogge ; > >>> Ashish Dalela (adalela) > >>> Cc: manet@ietf.org > >>> Subject: RE: [manet] DLEP Credit Windowing > >>> > >>> As Teco indicates, the plan (I'm not an author, but I talked to one > >>>recently) is > >>> to separate the credit windowing out. So these discussions won't hold > >>>up the > >>> main part of DLEP, and it being WGLCed again. > >>> > >>> -- > >>> Christopher Dearlove > >>> Senior Principal Engineer > >>> BAE Systems Applied Intelligence > >>> > __________________________________________________________ > >>> ________________ > >>> > >>> 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 Teco Boot > >>> Sent: 15 October 2015 16:48 > >>> To: Henning Rogge; Ashish Dalela (adalela) > >>> Cc: manet@ietf.org > >>> Subject: Re: [manet] DLEP Credit Windowing > >>> > >>> ----------------------! 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. > >>> > >>> > >>> PFC would be a HW or driver function. > >>> I don't think PFC solves flow control to remote nodes. This requires > >>>per > >>> destination signaling. > >>> I agree on having a requirement for diffserv based packet dispatcher > >>>with > >>> AQM and flow isolation. FIFO and priority queues should be something > >>>of the > >>> past. This is to be discussed after having a Credit-Windowing-00 draf= t. > >>> > >>> Teco > >>> > >>> > >>>>> Op 15 okt. 2015, om 16:52 heeft Henning Rogge > het > >>>> volgende geschreven: > >>>> > >>>> Hi, > >>>> > >>>> this sounds like a very interesting thing (we experimented with PAUSE > >>>> for some time but didn't know about the extension)... do you know if > >>>> its implemented in Linux? > >>>> > >>>> Henning Rogge > >>>> > >>>> On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) > >>>> wrote: > >>>>> Yes it will and that's why I suggested the use of PFC. The control > >>>>> and data planes will have different priorities. The radio never > >>>>> pauses the control channel because it is never sent over the air. If > >>>>> desired, the data packets themselves could be given different > >>>>> priorities allowing some flows to be selectively paused. > >>>>> > >>>>> > >>>>> Sent from Samsung Mobile > >>>>> > >>>>> > >>>>> -------- Original message -------- > >>>>> From: Henning Rogge > >>>>> Date:15/10/2015 18:36 (GMT+05:30) > >>>>> To: "Ashish Dalela (adalela)" > >>>>> Cc: manet@ietf.org > >>>>> Subject: Re: [manet] DLEP Credit Windowing > >>>>> > >>>>> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) > >>>>> wrote: > >>>>>> The ideal mechanism for Ethernet flow control is the use of 802.3 > >>>>>> PAUSE frames, which has further been enhanced by the PFC > (802.1Qbb) > >>> mechanism. > >>>>>> In > >>>>>> essence, we don=B9t send credits before packets are forwarded. > Rather > >>>>>> we pause the traffic when the traffic cannot be forwarded and the > >>>>>> buffers are full. > >>>>>> PFC is widely used in a number of Ethernet flow-control scenarios > >>>>>>today. > >>>>> > >>>>> Would a 802.3 PAUSE Frame not also block the DLEP control channel? > >>>>> > >>>>> 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 > >>> > ********************************************************** > >>> ********** > >>> 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 > >> > >> _____________________________________________________ > >> 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 individu= al > >> 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 ema= il > >> in error, please delete it and immediately notify the sender. > >> _____________________________________________________ > >> _______________________________________________ > >> 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 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 Thu Oct 15 11:39:25 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0C51ACF57 for ; Thu, 15 Oct 2015 11:39:23 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT8jwu-r0T7s for ; Thu, 15 Oct 2015 11:39:22 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E531AC3F6 for ; Thu, 15 Oct 2015 11:39:22 -0700 (PDT) Received: by lffy185 with SMTP id y185so41649467lff.2 for ; Thu, 15 Oct 2015 11:39: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-type; bh=gTcVSyAjteTD/lcc96oKHrp9hoXrOz/ETWOTk4vR79g=; b=lUepJdl5A6Q7EaLH8IQJhOo962yf9DBzCFF0QnKna3+AQ4XechauRXQ+d6NOXuln91 DYKVF4PXrdVWdAB0Y1izvV1wp8KhWQeBv5/QZB4jlPozrYooQ3mvPQI5fxRyrv9lwgtJ /jGKVg/gCxC7RmAj1+7Pi3ebQQ6gOP7qMR/ItSkcE8+Oxo5bantF7zq5qOB3J19j7y3X muz4jrSf1tCYQiiCMHYEBxeXJ5ME809s+Kduvf4CHwNm051UBQEyZTCFNEHUj5WNDNI/ W5uyse0UziZJEY/Aeud1fkLP6nt6FOOiz2YxkIr82FvkIJK+MtiBH6qhv4g59hh1vd+a wA1g== X-Received: by 10.181.13.233 with SMTP id fb9mr320537wid.36.1444934360346; Thu, 15 Oct 2015 11:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Thu, 15 Oct 2015 11:38:50 -0700 (PDT) In-Reply-To: <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> From: Henning Rogge Date: Thu, 15 Oct 2015 20:38:50 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 18:39:23 -0000 On Thu, Oct 15, 2015 at 8:34 PM, Ratliff, Stanley wrote: > The base DLEP draft normatively references Credit windowing as an example of *how* to do an extension. The Credit windowing draft is the extension. > Nothing says that credit windowing will be the *only* extension (in fact, I've heard of other extension drafts in the works). Also, *nothing* says that the credit windowing extension will be the only (or the best) draft for flow control. I think having one extension to refer to from Core DLEP is quite a good thing. The fact that it IS an extension makes it an optional feature of DLEP. I am quite sure there is no "one size fits all" way to do Flow Control... we will need (most likely multiple of them). But the Credit Window extension will allow it to convert radios supporting the PPPoE flow-control/metric extension easily to DLEP. Henning Rogge From nobody Thu Oct 15 12:12:59 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FF61A0018 for ; Thu, 15 Oct 2015 12:12:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RWpaZgC8MuY for ; Thu, 15 Oct 2015 12:12:56 -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 D78881A000E for ; Thu, 15 Oct 2015 12:12:55 -0700 (PDT) Received: by lffv3 with SMTP id v3so43535109lff.0 for ; Thu, 15 Oct 2015 12:12:54 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1+44O+gH3xBZacCA69n5CuFwlpZPoOQS5OW1jUqMLn4=; b=IMhExOn7taxUz+NQRw3D5OQ1g1tOqCXiqmlDtTuqXDt0vMjesMIJSAVuliXAbSXBu8 pp/RgW6+trx9dyHc6LEUH4gGRCICqGcMSg4zayGKSIH4t4AxLZj6RnlVCaBWvn+bM+tj pCMe9aMq5L0K+Nv7mHPyx1QfKAxPffY159g8ni//786Dsnq+5J6Z75XyICe45PKWRfnj o9AT7sNfRk6PWhu3pKaHzBaXUepTjNoYy5QPzbGK8x0ZmGJ0CQtQHh27ZDx9rsvOKfJ9 phed/AbpaG371pI2C239a5Ham78L2g43Bv9upKvLviS13eQs1FiTbinSP5rG7q+NGPjT /LuQ== X-Received: by 10.180.207.235 with SMTP id lz11mr421576wic.1.1444936373968; Thu, 15 Oct 2015 12:12:53 -0700 (PDT) Received: from [10.7.196.158] (dab-yat1-h-47-9.dab.02.net. [82.132.215.123]) by smtp.gmail.com with ESMTPSA id lv4sm18139399wjb.43.2015.10.15.12.12.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 12:12:53 -0700 (PDT) References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> Mime-Version: 1.0 (1.0) In-Reply-To: <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <958543C0-081D-46FF-80DE-67AD64575FE7@gmail.com> X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Thu, 15 Oct 2015 20:12:49 +0100 To: "Ratliff, Stanley" Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:12:57 -0000 I would have said it was the other way round. I'm suggesting the good - grab= your most of a loaf with DLEP that's not encumbered by credit windowing, de= manding both proceed is the best that may delay the good. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 15 Oct 2015, at 19:34, Ratliff, Stanley wrote: >=20 > Sigh... >=20 > There's nothing like re-litigating things that happened 3 to 4 years ago. = Folks, if we keep churning on this, we'll never accomplish anything.=20 >=20 > The base DLEP draft normatively references Credit windowing as an example o= f *how* to do an extension. The Credit windowing draft is the extension.=20 > Nothing says that credit windowing will be the *only* extension (in fact, I= 've heard of other extension drafts in the works). Also, *nothing* says that= the credit windowing extension will be the only (or the best) draft for flo= w control.=20 >=20 > Let's stop making "the good" the enemy of "the perfect", and actually acco= mplish something before the WG gets shutdown for not producing anything.=20 >=20 > Alvaro and Justin - please feel free to comment.=20 >=20 > Stan >=20 >=20 >> -----Original Message----- >> From: Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] >> Sent: Thursday, October 15, 2015 2:26 PM >> To: Christopher Dearlove ; Ratliff, Stanl= ey >> >> Cc: manet@ietf.org >> Subject: Re: [manet] DLEP Credit Windowing >>=20 >> I agree with Chris. I thought the main advantage of splitting the >> documents was so that core DLEP could proceed independent of credit >> windowing. >>=20 >> David >>=20 >> On 10/15/15, 1:59 PM, "manet on behalf of Christopher Dearlove" >> >> wrote: >>=20 >>> Why should the credit windowing draft be referenced from the main draft?= From nobody Thu Oct 15 12:22:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381531A00B7 for ; Thu, 15 Oct 2015 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELhuhnx8lvlm for ; Thu, 15 Oct 2015 12:22:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7793B1A00B1 for ; Thu, 15 Oct 2015 12:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16520; q=dns/txt; s=iport; t=1444936949; x=1446146549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rr/DP2AvWtSPq7DLPjCACqXdW6ETonfXlhU41KKu/OY=; b=V8LlyAzHQ+oA4WNkMwwDYK0BMSeURGIBFl/uWVtU2rSjHCE9ZNRHnt9t 8MeM/yJE70Ghaf3sr4FRkTM9+MUVG5Kozr3JJJzIjjzDya6MrVcb9bCoY odimhSKIEUkGgo6M0wk+2q9NTvipMhqGsFlWnG6xJU/JLzm4CbplH0S1R 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AFAgA//B9W/51dJa1eDoMYVG4GvTcBDYFZFwqFfQIcgR44FAEBAQEBAQGBCoQmAQEBBAEBATEVJQMIDAQCAQgRAwEBAQEEIwUCAh8GCxQJCAIEAQ0FiBkDEg2SV50vBo4ZDYURAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EchVoBg3eBBoJQgVoKBwEKFBgWBQcGgl2BSwWGBAmBMIsZg0cBiyaBdIFYhDqONQuDT4NuAR8BAUKCER2BFz5xAYQdCRcjgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="scan'208";a="198442435" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 15 Oct 2015 19:22:28 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t9FJMSb4010336 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 19:22:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 14:22:13 -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.000; Thu, 15 Oct 2015 14:22:13 -0500 From: "Alvaro Retana (aretana)" To: "Ratliff, Stanley" , "Wiggins, David - 0665 - MITLL" , Christopher Dearlove , Justin Dean Thread-Topic: [manet] DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3AAMVlgA///JMHSAAFSbAIAAD4CAgAABuACAAFJZ4P//yBaAgAAIeICAAAdngIAAAoSA///KSIA= Date: Thu, 15 Oct 2015 19:22:13 +0000 Message-ID: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> In-Reply-To: <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:22:35 -0000 DQoNCk9uIDEwLzE1LzE1LCAyOjM0IFBNLCAiUmF0bGlmZiwgU3RhbmxleSIgPHNyYXRsaWZmQGlk aXJlY3QubmV0PiB3cm90ZToNCg0KPlNpZ2guLi4NCj4NCj5UaGVyZSdzIG5vdGhpbmcgbGlrZSBy ZS1saXRpZ2F0aW5nIHRoaW5ncyB0aGF0IGhhcHBlbmVkIDMgdG8gNCB5ZWFycyBhZ28uDQo+Rm9s a3MsIGlmIHdlIGtlZXAgY2h1cm5pbmcgb24gdGhpcywgd2UnbGwgbmV2ZXIgYWNjb21wbGlzaCBh bnl0aGluZy4NCj4NCj5UaGUgYmFzZSBETEVQIGRyYWZ0IG5vcm1hdGl2ZWx5IHJlZmVyZW5jZXMg Q3JlZGl0IHdpbmRvd2luZyBhcyBhbiBleGFtcGxlDQo+b2YgKmhvdyogdG8gZG8gYW4gZXh0ZW5z aW9uLiBUaGUgQ3JlZGl0IHdpbmRvd2luZyBkcmFmdCBpcyB0aGUgZXh0ZW5zaW9uLg0KPk5vdGhp bmcgc2F5cyB0aGF0IGNyZWRpdCB3aW5kb3dpbmcgd2lsbCBiZSB0aGUgKm9ubHkqIGV4dGVuc2lv biAoaW4gZmFjdCwNCj5JJ3ZlIGhlYXJkIG9mIG90aGVyIGV4dGVuc2lvbiBkcmFmdHMgaW4gdGhl IHdvcmtzKS4gQWxzbywgKm5vdGhpbmcqIHNheXMNCj50aGF0IHRoZSBjcmVkaXQgd2luZG93aW5n IGV4dGVuc2lvbiB3aWxsIGJlIHRoZSBvbmx5IChvciB0aGUgYmVzdCkgZHJhZnQNCj5mb3IgZmxv dyBjb250cm9sLiANCj4NCj5MZXQncyBzdG9wIG1ha2luZyAidGhlIGdvb2QiIHRoZSBlbmVteSBv ZiAidGhlIHBlcmZlY3QiLCBhbmQgYWN0dWFsbHkNCj5hY2NvbXBsaXNoIHNvbWV0aGluZyBiZWZv cmUgdGhlIFdHIGdldHMgc2h1dGRvd24gZm9yIG5vdCBwcm9kdWNpbmcNCj5hbnl0aGluZy4gDQo+ DQo+QWx2YXJvIGFuZCBKdXN0aW4gLSBwbGVhc2UgZmVlbCBmcmVlIHRvIGNvbW1lbnQuDQoNCklu IHRoZSAtMTYgdmVyc2lvbiBvZiBETEVQIGFsbCBJIHNlZSBpcyBhbiAqaW5mb3JtYXRpdmUqIHJl ZmVyZW5jZSB0bw0KUkZDNTU3OC4gIEZyb20gdGhlIGRpc2N1c3Npb24gb24gdGhlIHRocmVhZCwg SSdtIHN1cmUgdGhhdCBjYW4ndCBiZSB3aGF0DQp5b3UgZ3V5cyBhcmUgdGFsa2luZyBhYm91dC4g IERpZCBJIG1pc3MgdGhlIHJlZmVyZW5jZSBzb21ld2hlcmU/DQoNCkJUVywgeW91IHdyb3RlIGFi b3ZlIHRoYXQgdGhlICJiYXNlIERMRVAgZHJhZnQgbm9ybWF0aXZlbHkgcmVmZXJlbmNlcw0KQ3Jl ZGl0IHdpbmRvd2luZyBhcyBhbiBleGFtcGxlIi4gIEFuIGV4YW1wbGUgc2hvdWxkbid0IGJlIG5v cm1hdGl2ZS4gIElmDQp0aGUgYmFzZSBkcmFmdCByZWZlcmVuY2VzIHRoZSBuZXcgY3JlZGl0IHdp bmRvd2luZyBkcmFmdCBhcyBJbmZvcm1hdGlvbmFsLA0KdGhlcmUgd29uJ3QgYmUgYSBkZWxheSAt LSBvbmx5IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHdvdWxkIGhvbGQgYSBkb2N1bWVudA0KdXAuDQoN CkFsdmFyby4NCg0KPiANCj4NCj5TdGFuDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogV2lnZ2lucywgRGF2aWQgLSAwNjY1IC0gTUlUTEwgW21haWx0bzpEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHVdDQo+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAx NSAyOjI2IFBNDQo+PiBUbzogQ2hyaXN0b3BoZXIgRGVhcmxvdmUgPGNocmlzdG9waGVyLmRlYXJs b3ZlQGdtYWlsLmNvbT47IFJhdGxpZmYsDQo+PlN0YW5sZXkNCj4+IDxzcmF0bGlmZkBpZGlyZWN0 Lm5ldD4NCj4+IENjOiBtYW5ldEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExF UCBDcmVkaXQgV2luZG93aW5nDQo+PiANCj4+IEkgYWdyZWUgd2l0aCBDaHJpcy4gIEkgdGhvdWdo dCB0aGUgbWFpbiBhZHZhbnRhZ2Ugb2Ygc3BsaXR0aW5nIHRoZQ0KPj4gZG9jdW1lbnRzIHdhcyBz byB0aGF0IGNvcmUgRExFUCBjb3VsZCBwcm9jZWVkIGluZGVwZW5kZW50IG9mIGNyZWRpdA0KPj4g d2luZG93aW5nLg0KPj4gDQo+PiBEYXZpZA0KPj4gDQo+PiBPbiAxMC8xNS8xNSwgMTo1OSBQTSwg Im1hbmV0IG9uIGJlaGFsZiBvZiBDaHJpc3RvcGhlciBEZWFybG92ZSINCj4+IDxtYW5ldC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3RvcGhlci5kZWFybG92ZUBnbWFpbC5jb20+ DQo+PiB3cm90ZToNCj4+IA0KPj4gPldoeSBzaG91bGQgdGhlIGNyZWRpdCB3aW5kb3dpbmcgZHJh ZnQgYmUgcmVmZXJlbmNlZCBmcm9tIHRoZSBtYWluDQo+PmRyYWZ0Pw0KPj4gPkl0J3MgYW4gZXh0 ZW5zaW9uLCBhbmQgbm90IGhhdmluZyB0aGF0IHJlZmVyZW5jZSBtZWFucyB0aGF0IHRoZSBtYWlu DQo+PiA+ZHJhZnQsIG92ZXIgd2hpY2ggSSBzZWUgYSBsb3QgbGVzcyBjb250cm92ZXJzeSwgd291 bGRuJ3QgZ2V0IGhlbGQgdXAgYnkNCj4+ID5hbnkgZGVsYXkgKHN1Y2ggYXMgcmVzb2x2aW5nIHRo aXMgZGlzY3Vzc2lvbikgdG8gY3JlZGl0IHdpbmRvd2luZy4NCj4+ID4NCj4+ID4tLQ0KPj4gPkNo cmlzdG9waGVyIERlYXJsb3ZlDQo+PiA+Y2hyaXN0b3BoZXIuZGVhcmxvdmVAZ21haWwuY29tIChp UGhvbmUpDQo+PiA+Y2hyaXNAbW5lbW9zeW5lLmRlbW9uLmNvLnVrIChob21lKQ0KPj4gPg0KPj4g Pj4gT24gMTUgT2N0IDIwMTUsIGF0IDE4OjI4LCBSYXRsaWZmLCBTdGFubGV5IDxzcmF0bGlmZkBp ZGlyZWN0Lm5ldD4NCj4+d3JvdGU6DQo+PiA+Pg0KPj4gPj4gSGVsbG8gYWxsLA0KPj4gPj4NCj4+ ID4+IFdlbGwsIEkgYW0gYW4gYXV0aG9yLCBzbyBJIHRoaW5rIEkgY2FuIHNwZWFrIGF1dGhvcml0 YXRpdmVseS4uLiA7LSkNCj4+ID4+DQo+PiA+PiBZZXMsIHRoZSBjcmVkaXQtd2luZG93aW5nIGlz IHNwbGl0IG91dC4gQ3JlZGl0IHdpbmRvd2luZyB3aWxsIGJlDQo+PiA+PmludHJvZHVjZWQgYXMg YSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IChzcGxpdHRpbmcgYSBXRyBkb2MgaW50byB0d28NCj4+ ZG9jcw0KPj4gPj5pbXBsaWVzIHRoYXQgYm90aCBhcmUgYWxyZWFkeSBXRyBkb2NzKS4gRnVydGhl ciwgdGhlIGRvY3MgKERMRVAgYW5kDQo+PiA+PkNyZWRpdCBXaW5kb3dpbmcpIHdpbGwgY29udGFp biBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBlYWNoIG90aGVyLCBzbw0KPj4gPj50aGV5IHdpbGwg cHJvZ3Jlc3MgaW4gbG9jay1zdGVwLiBZb3UgY2FuIGV4cGVjdCB0aGUgc3VibWlzc2lvbnMgd2l0 aGluDQo+PiA+PnRoZSBuZXh0IGRheSBvciB0d28uDQo+PiA+Pg0KPj4gPj4gVGhlIGNyZWRpdCB3 aW5kb3dpbmcgZHJhZnQgaXMgd3JpdHRlbiBhcyBhbiBleHRlbnNpb24gdG8gRExFUC4gSXQgaXMN Cj4+ID4+bm90LCBieSBkZWZpbml0aW9uLCBhbiBleHByZXNzaW9uIG9mIHRoZSAqb25seSBmb3Jt KiBvZiBwb3NzaWJsZSBmbG93DQo+PiA+PmNvbnRyb2wuIEJ5IHRoYXQsIEkgbWVhbiB0aGF0IGEg ZGlzY3Vzc2lvbiBvbiBQQVVTRSBmcmFtZXMsIG9yIHNvbWUNCj4+ID4+ZXF1aXZhbGVudCBzY2hl bWUsIGRvZXMgKm5vdCogbmVjZXNzYXJpbHkgaW52YWxpZGF0ZSBjcmVkaXQgd2luZG93aW5nLg0K Pj4gPj5JZiAgdGhlcmUgaXMgaW50ZXJlc3QgaW4gY3JlYXRpbmcgYW5vdGhlciBkcmFmdCB3aXRo IGFuIGFkZGl0aW9uYWwNCj4+ID4+c2NoZW1lLCBJIHdvdWxkIGVuY291cmFnZSBzb21lb25lIGlu IHRoZSBXRyB0byBzdGVwIHVwIHRvIHRoZSBwbGF0ZQ0KPj4gYW5kDQo+PiA+PndyaXRlIGl0Lg0K Pj4gPj4NCj4+ID4+IFdpdGggdGhlIG5vcm1hdGl2ZSBjcm9zcy1yZWZlcmVuY2luZywgYSByZS1s aXRpZ2F0aW9uIG9mIGNyZWRpdA0KPj4gPj53aW5kb3dpbmcgKndpbGwqIGhvbGQgdXAgRExFUC4N Cj4+ID4+DQo+PiA+PiBSZWdhcmRzLA0KPj4gPj4gU3Rhbg0KPj4gPj4NCj4+ID4+DQo+PiA+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+PiBGcm9tOiBtYW5ldCBbbWFpbHRvOm1h bmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBc2hpc2gNCj4+IERhbGVsYQ0KPj4g Pj4+IChhZGFsZWxhKQ0KPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDE1IDEy OjAyIFBNDQo+PiA+Pj4gVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbT47DQo+PiBUZWNvDQo+PiA+Pj4gQm9vdCA8dGVjb0BpbmYtbmV0 Lm5sPjsgSGVubmluZyBSb2dnZSA8aHJvZ2dlQGdtYWlsLmNvbT4NCj4+ID4+PiBDYzogbWFuZXRA aWV0Zi5vcmcNCj4+ID4+PiBTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQIENyZWRpdCBXaW5kb3dp bmcNCj4+ID4+Pg0KPj4gPj4+DQo+PiA+Pj4gVGhhdCBpcyBnb29kIHRoZW4uIE15IHBvaW50IGlz IHRoYXQgd2Ugc2hvdWxkIHJlbW92ZSBjcmVkaXQNCj4+d2luZG93aW5nDQo+PiA+Pj5mcm9tDQo+ PiA+Pj4gdGhpcyBkcmFmdCBiZWZvcmUgd2UgdGFrZSBpdCB0byBSRkMuIFdlIGNhbiB0aGVuIHNl cGFyYXRlbHkgZGlzY3Vzcw0KPj4gPj4+Y3JlZGl0cyAob3INCj4+ID4+PiBhbiBlcXVpdmFsZW50 IHNjaGVtZSB3aG9zZSBwdXJwb3NlIHdvdWxkIGJlIHRvIGFsbG93IGEgY29uc2lzdGVudA0KPj4g Pj4+c2NoZW1lDQo+PiA+Pj4gdGhhdCBjYW4gYmUgcHJhY3RpY2FsbHkgaW1wbGVtZW50ZWQgaW4g Ym90aCBjb252ZXJnZWQgYW5kIHNlcGFyYXRlZA0KPj4gPj4+IGNvbnRyb2wvZGF0YSBwbGFuZXMp Lg0KPj4gPj4+DQo+PiA+Pj4gVGhhbmtzDQo+PiA+Pj4NCj4+ID4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPj4+IEZyb206IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQo+PiBb bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tXQ0KPj4gPj4+IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDE1LCAyMDE1IDk6MjQgUE0NCj4+ID4+PiBUbzogVGVjbyBCb290IDx0ZWNv QGluZi1uZXQubmw+OyBIZW5uaW5nIFJvZ2dlIDxocm9nZ2VAZ21haWwuY29tPjsNCj4+ID4+PiBB c2hpc2ggRGFsZWxhIChhZGFsZWxhKSA8YWRhbGVsYUBjaXNjby5jb20+DQo+PiA+Pj4gQ2M6IG1h bmV0QGlldGYub3JnDQo+PiA+Pj4gU3ViamVjdDogUkU6IFttYW5ldF0gRExFUCBDcmVkaXQgV2lu ZG93aW5nDQo+PiA+Pj4NCj4+ID4+PiBBcyBUZWNvIGluZGljYXRlcywgdGhlIHBsYW4gKEknbSBu b3QgYW4gYXV0aG9yLCBidXQgSSB0YWxrZWQgdG8gb25lDQo+PiA+Pj5yZWNlbnRseSkgaXMNCj4+ ID4+PiB0byBzZXBhcmF0ZSB0aGUgY3JlZGl0IHdpbmRvd2luZyBvdXQuIFNvIHRoZXNlIGRpc2N1 c3Npb25zIHdvbid0DQo+PmhvbGQNCj4+ID4+PnVwIHRoZQ0KPj4gPj4+IG1haW4gcGFydCBvZiBE TEVQLCBhbmQgaXQgYmVpbmcgV0dMQ2VkIGFnYWluLg0KPj4gPj4+DQo+PiA+Pj4gLS0NCj4+ID4+ PiBDaHJpc3RvcGhlciBEZWFybG92ZQ0KPj4gPj4+IFNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIN Cj4+ID4+PiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KPj4gPj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+Pj4gX19fX19fX19fX19fX19fXw0KPj4gPj4+DQo+PiA+Pj4gVDogICs0NCAoMCkxMjQ1IDI0 MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCj4+ID4+Pg0KPj4gPj4+ IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQNCj4+ID4+PiBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQo+ PiA+Pj4gd3d3LmJhZXN5c3RlbXMuY29tL2FpDQo+PiA+Pj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UgTGltaXRlZCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJg0KPj5XYWxlcw0KPj4g Pj4+Tm86DQo+PiA+Pj4gMDEzMzc0NTEgUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJj aCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwNCj4+ID4+PkdVMg0KPj4gPj4+IDdZUA0KPj4gPj4+ DQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ Pj4gRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgVGVjbyBCb290DQo+PiA+Pj4gU2VudDogMTUgT2N0b2JlciAyMDE1IDE2OjQ4DQo+PiA+Pj4g VG86IEhlbm5pbmcgUm9nZ2U7IEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+PiA+Pj4gQ2M6IG1h bmV0QGlldGYub3JnDQo+PiA+Pj4gU3ViamVjdDogUmU6IFttYW5ldF0gRExFUCBDcmVkaXQgV2lu ZG93aW5nDQo+PiA+Pj4NCj4+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzDQo+Pm1lc3NhZ2UNCj4+ID4+Pm9yaWdpbmF0ZXMN Cj4+ID4+PiBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvcg0KPj5mcm9tDQo+PiA+Pj50aGUNCj4+ID4+PiBpbnRlcm5ldC4NCj4+ ID4+PiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkNCj4+ID4+PiBhdHRhY2htZW50cyBvciByZXBseS4NCj4+ID4+PiBGb2xs b3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IN Cj4+ID4+Pmluc3RydWN0aW9ucyBvbg0KPj4gPj4+IHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWls IG1lc3NhZ2VzLg0KPj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+Pj4NCj4+ID4+PiAqKiogV0FSTklORyAqKioNCj4+ID4+ PiBFWFRFUk5BTCBFTUFJTCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyDQo+PiA+Pj5vcmdhbml6YXRpb24uDQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+IFBGQyB3b3Vs ZCBiZSBhIEhXIG9yIGRyaXZlciBmdW5jdGlvbi4NCj4+ID4+PiBJIGRvbid0IHRoaW5rIFBGQyBz b2x2ZXMgZmxvdyBjb250cm9sIHRvIHJlbW90ZSBub2Rlcy4gVGhpcyByZXF1aXJlcw0KPj4gPj4+ cGVyDQo+PiA+Pj4gZGVzdGluYXRpb24gc2lnbmFsaW5nLg0KPj4gPj4+IEkgYWdyZWUgb24gaGF2 aW5nIGEgcmVxdWlyZW1lbnQgZm9yIGRpZmZzZXJ2IGJhc2VkIHBhY2tldCBkaXNwYXRjaGVyDQo+ PiA+Pj53aXRoDQo+PiA+Pj4gQVFNIGFuZCBmbG93IGlzb2xhdGlvbi4gRklGTyBhbmQgcHJpb3Jp dHkgcXVldWVzIHNob3VsZCBiZSBzb21ldGhpbmcNCj4+ID4+Pm9mIHRoZQ0KPj4gPj4+IHBhc3Qu IFRoaXMgaXMgdG8gYmUgZGlzY3Vzc2VkIGFmdGVyIGhhdmluZyBhIENyZWRpdC1XaW5kb3dpbmct MDANCj4+ZHJhZnQuDQo+PiA+Pj4NCj4+ID4+PiBUZWNvDQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+ Pj4gT3AgMTUgb2t0LiAyMDE1LCBvbSAxNjo1MiBoZWVmdCBIZW5uaW5nIFJvZ2dlIDxocm9nZ2VA Z21haWwuY29tPg0KPj4gaGV0DQo+PiA+Pj4+IHZvbGdlbmRlIGdlc2NocmV2ZW46DQo+PiA+Pj4+ DQo+PiA+Pj4+IEhpLA0KPj4gPj4+Pg0KPj4gPj4+PiB0aGlzIHNvdW5kcyBsaWtlIGEgdmVyeSBp bnRlcmVzdGluZyB0aGluZyAod2UgZXhwZXJpbWVudGVkIHdpdGgNCj4+UEFVU0UNCj4+ID4+Pj4g Zm9yIHNvbWUgdGltZSBidXQgZGlkbid0IGtub3cgYWJvdXQgdGhlIGV4dGVuc2lvbikuLi4gZG8g eW91IGtub3cNCj4+aWYNCj4+ID4+Pj4gaXRzIGltcGxlbWVudGVkIGluIExpbnV4Pw0KPj4gPj4+ Pg0KPj4gPj4+PiBIZW5uaW5nIFJvZ2dlDQo+PiA+Pj4+DQo+PiA+Pj4+IE9uIFRodSwgT2N0IDE1 LCAyMDE1IGF0IDQ6NDkgUE0sIEFzaGlzaCBEYWxlbGEgKGFkYWxlbGEpDQo+PiA+Pj4+IDxhZGFs ZWxhQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiA+Pj4+PiBZZXMgaXQgd2lsbCBhbmQgdGhhdCdzIHdo eSBJIHN1Z2dlc3RlZCB0aGUgdXNlIG9mIFBGQy4gVGhlIGNvbnRyb2wNCj4+ID4+Pj4+IGFuZCBk YXRhIHBsYW5lcyB3aWxsIGhhdmUgZGlmZmVyZW50IHByaW9yaXRpZXMuIFRoZSByYWRpbyBuZXZl cg0KPj4gPj4+Pj4gcGF1c2VzIHRoZSBjb250cm9sIGNoYW5uZWwgYmVjYXVzZSBpdCBpcyBuZXZl ciBzZW50IG92ZXIgdGhlIGFpci4NCj4+SWYNCj4+ID4+Pj4+IGRlc2lyZWQsICB0aGUgZGF0YSBw YWNrZXRzIHRoZW1zZWx2ZXMgY291bGQgYmUgZ2l2ZW4gZGlmZmVyZW50DQo+PiA+Pj4+PiBwcmlv cml0aWVzIGFsbG93aW5nIHNvbWUgZmxvd3MgdG8gYmUgc2VsZWN0aXZlbHkgcGF1c2VkLg0KPj4g Pj4+Pj4NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBTZW50IGZyb20gU2Ftc3VuZyBNb2JpbGUNCj4+ID4+ Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LQ0KPj4gPj4+Pj4gRnJvbTogSGVubmluZyBSb2dnZQ0KPj4gPj4+Pj4gRGF0ZToxNS8xMC8yMDE1 IDE4OjM2IChHTVQrMDU6MzApDQo+PiA+Pj4+PiBUbzogIkFzaGlzaCBEYWxlbGEgKGFkYWxlbGEp Ig0KPj4gPj4+Pj4gQ2M6IG1hbmV0QGlldGYub3JnDQo+PiA+Pj4+PiBTdWJqZWN0OiBSZTogW21h bmV0XSBETEVQIENyZWRpdCBXaW5kb3dpbmcNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBPbiBUaHUsIE9j dCAxNSwgMjAxNSBhdCAyOjI1IFBNLCBBc2hpc2ggRGFsZWxhIChhZGFsZWxhKQ0KPj4gPj4+Pj4g PGFkYWxlbGFAY2lzY28uY29tPiB3cm90ZToNCj4+ID4+Pj4+PiBUaGUgaWRlYWwgbWVjaGFuaXNt IGZvciBFdGhlcm5ldCBmbG93IGNvbnRyb2wgaXMgdGhlIHVzZSBvZiA4MDIuMw0KPj4gPj4+Pj4+ IFBBVVNFIGZyYW1lcywgd2hpY2ggaGFzIGZ1cnRoZXIgYmVlbiBlbmhhbmNlZCBieSB0aGUgUEZD DQo+PiAoODAyLjFRYmIpDQo+PiA+Pj4gbWVjaGFuaXNtLg0KPj4gPj4+Pj4+IEluDQo+PiA+Pj4+ Pj4gZXNzZW5jZSwgd2UgZG9uqfZ0IHNlbmQgY3JlZGl0cyBiZWZvcmUgcGFja2V0cyBhcmUgZm9y d2FyZGVkLg0KPj4gUmF0aGVyDQo+PiA+Pj4+Pj4gd2UgcGF1c2UgdGhlIHRyYWZmaWMgd2hlbiB0 aGUgdHJhZmZpYyBjYW5ub3QgYmUgZm9yd2FyZGVkIGFuZCB0aGUNCj4+ID4+Pj4+PiBidWZmZXJz IGFyZSBmdWxsLg0KPj4gPj4+Pj4+IFBGQyBpcyB3aWRlbHkgdXNlZCBpbiBhIG51bWJlciBvZiBF dGhlcm5ldCBmbG93LWNvbnRyb2wgc2NlbmFyaW9zDQo+PiA+Pj4+Pj50b2RheS4NCj4+ID4+Pj4+ DQo+PiA+Pj4+PiBXb3VsZCBhIDgwMi4zIFBBVVNFIEZyYW1lIG5vdCBhbHNvIGJsb2NrIHRoZSBE TEVQIGNvbnRyb2wgY2hhbm5lbD8NCj4+ID4+Pj4+DQo+PiA+Pj4+PiBIZW5uaW5nIFJvZ2dlDQo+ PiA+Pj4+DQo+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+Pj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gPj4+PiBtYW5ldEBpZXRmLm9y Zw0KPj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+ PiA+Pj4NCj4+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPj4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gPj4+IG1hbmV0QGlldGYub3JnDQo+ PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPj4gPj4+ DQo+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+PiA+Pj4gKioqKioqKioqKg0KPj4gPj4+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPj4gPj4+cmVjaXBpZW50 DQo+PiA+Pj4gYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQNCj4+ID4+PnBsZWFzZQ0KPj4gPj4+IGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCj4+ID4+PiBZb3Ugc2hvdWxkIG5vdCBj b3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQo+PiA+Pj5k aXN0cmlidXRlIGl0cw0KPj4gPj4+IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQo+PiA+ Pj4NCj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+ID4+PiAqKioqKioqKioqDQo+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+PiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4+ ID4+PiBtYW5ldEBpZXRmLm9yZw0KPj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQNCj4+ID4+DQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zDQo+PiA+PiBpbmZvcm1h dGlvbiBmcm9tIGlEaXJlY3QsIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeQ0K Pj4gPj4gYW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZQ0KPj5pbmRpdmlkdWFsDQo+PiA+PiBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbA0KPj4gPj4gcmVjaXBpZW50 IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIGVtYWlsIHRvIHRo ZQ0KPj4gPj4gaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbA0KPj4gPj4gaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3Nl bWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcg0KPj4gPj4gY29weWluZyBvZiB0aGlz IGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzDQo+PmVt YWlsDQo+PiA+PiBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90 aWZ5IHRoZSBzZW5kZXIuDQo+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+ID4+IG1hbmV0IG1haWxpbmcgbGlzdA0KPj4gPj4gbWFuZXRA aWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gPm1hbmV0IG1haWxpbmcgbGlzdA0KPj4gPm1hbmV0QGlldGYub3JnDQo+PiA+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+VGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zDQo+ aW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJp ZXRhcnkNCj5hbmQvb3IgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwNCj5vciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbA0KPnJlY2lwaWVudCBvciB0aGUgcGVy c29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUNCj5pbnRlbmRl ZCByZWNpcGllbnQsIGJlIGFkdmlzZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls DQo+aW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcs IHByaW50aW5nLCBvcg0KPmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbA0KPmluIGVycm9yLCBwbGVhc2UgZGVsZXRl IGl0IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KDQo= From nobody Thu Oct 15 13:04:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719AB1A1A77 for ; Thu, 15 Oct 2015 13:04:34 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSm5CmEhVkji for ; Thu, 15 Oct 2015 13:04:32 -0700 (PDT) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (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 1E45B1A1A72 for ; Thu, 15 Oct 2015 13:04:30 -0700 (PDT) Received: by lffv3 with SMTP id v3so46080866lff.0 for ; Thu, 15 Oct 2015 13:04:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tus7wUiJm+XqeE+lw6bRVmo3eXE84v9eKFmUR5BSsrw=; b=DIQ2l3oEAGeKyjPTGzPcI+lwWbhMm86HE1moe88wV1hCZiTJdtF15HDNCfR4Jhr94/ xxBCNEQvPQoc0XyLhzz4GdwkGgFQXH6h+JJ4cFGuNTV/A/MsJXz7NlRJCWpD1+L1z02D sjhDW3E/Q2WLoROpZx6nnNyvG1fzLkWnyDqrfPnyjXsur9oV/OpNx75mFBILQ0xor+jj vINeBCaSYkgRfxd7KfU1m6VCteZ65SBTrnPCASDPTvt/rmw5Od9Y/g8wAXFTyWOBxHIt 9BVIcbp09wxv7KY/6VYVNkHC/T8edOtz1fgv9WgCSLM3tUR7IvRIPUtV5fjQo+y0oXuJ efaw== X-Gm-Message-State: ALoCoQkv/HDr0mUyh5Z9O3ZEG1ZIArC0hHETnM5crlH2udppj9paqoH1H57YwEag9irZyZtYKe71 X-Received: by 10.180.187.244 with SMTP id fv20mr596505wic.23.1444939468984; Thu, 15 Oct 2015 13:04:28 -0700 (PDT) Received: from [192.168.178.29] (524A11D6.cm-4-3a.dynamic.ziggo.nl. [82.74.17.214]) by smtp.gmail.com with ESMTPSA id qq4sm18307944wjc.14.2015.10.15.13.04.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Oct 2015 13:04:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Teco Boot In-Reply-To: <958543C0-081D-46FF-80DE-67AD64575FE7@gmail.com> Date: Thu, 15 Oct 2015 22:04:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> <1CCA0C36-4A78-4E98-BE70-C5DF1F1917B4@gmail.com> <575e96e0961b410baa9621a82637c45b@VAUSDITCHM2.idirect.net> <958543C0-081D-46FF-80DE-67AD64575FE7@gmail.com> To: Christopher Dearlove , "Ratliff, Stanley" X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 20:04:34 -0000 > Op 15 okt. 2015, om 21:12 heeft Christopher Dearlove = het volgende geschreven: >=20 > I would have said it was the other way round. I'm suggesting the good = - grab your most of a loaf with DLEP that's not encumbered by credit = windowing, demanding both proceed is the best that may delay the good. +1 Further discussions on this x-ref topic delay both of them. Teco >=20 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 >> On 15 Oct 2015, at 19:34, Ratliff, Stanley = wrote: >>=20 >> Sigh... >>=20 >> There's nothing like re-litigating things that happened 3 to 4 years = ago. Folks, if we keep churning on this, we'll never accomplish = anything.=20 >>=20 >> The base DLEP draft normatively references Credit windowing as an = example of *how* to do an extension. The Credit windowing draft is the = extension.=20 >> Nothing says that credit windowing will be the *only* extension (in = fact, I've heard of other extension drafts in the works). Also, = *nothing* says that the credit windowing extension will be the only (or = the best) draft for flow control.=20 >>=20 >> Let's stop making "the good" the enemy of "the perfect", and actually = accomplish something before the WG gets shutdown for not producing = anything.=20 >>=20 >> Alvaro and Justin - please feel free to comment.=20 >>=20 >> Stan >>=20 >>=20 >>> -----Original Message----- >>> From: Wiggins, David - 0665 - MITLL = [mailto:David.Wiggins@ll.mit.edu] >>> Sent: Thursday, October 15, 2015 2:26 PM >>> To: Christopher Dearlove ; Ratliff, = Stanley >>> >>> Cc: manet@ietf.org >>> Subject: Re: [manet] DLEP Credit Windowing >>>=20 >>> I agree with Chris. I thought the main advantage of splitting the >>> documents was so that core DLEP could proceed independent of credit >>> windowing. >>>=20 >>> David >>>=20 >>> On 10/15/15, 1:59 PM, "manet on behalf of Christopher Dearlove" >>> >>> wrote: >>>=20 >>>> Why should the credit windowing draft be referenced from the main = draft? > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Oct 15 14:03:42 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D311A1BA9 for ; Thu, 15 Oct 2015 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALKJoIg2jChp for ; Thu, 15 Oct 2015 14:03:38 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010: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 A75AA1A1B82 for ; Thu, 15 Oct 2015 14:03:37 -0700 (PDT) Received: by lbbpp2 with SMTP id pp2so56187349lbb.0 for ; Thu, 15 Oct 2015 14:03: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:content-type; bh=ic77GfPYYV4g86doUJqR2IoTVewnZNEzZNDLl+ldzPo=; b=ys7Gl2wBvOdBKrflcz2+qUAp/iarwPBGS+b8cAAwhLeILue8JBCEZc+KKlwEPiZO04 O5cVqL8P+cWV6olDmivq60+CHFzd/fhScj9R1rfakIlFFdUpxbTAqSOEAXfVuaZ+bKPr 8g/FQdQNvE2VTw3plIJjnNsMREAagOUqP3xo4ZmFuZRuQXJA8nSLvf2mxsBwEXDhnZhH 4hFXxsy7nv9cePsoQnFMis4Bp1IhBIEB6KXmzoenImEqOLUCTYz4c+C3bu7A48JXZoTB T7N0xTBLlczq7XZaIavZ4BGcSnj3/x++4cgblQZ4y5cbHRsgFXKCf47XnStGdxEFNpvf GxMA== MIME-Version: 1.0 X-Received: by 10.112.13.34 with SMTP id e2mr4677432lbc.120.1444943015742; Thu, 15 Oct 2015 14:03:35 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Thu, 15 Oct 2015 14:03:35 -0700 (PDT) In-Reply-To: <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> Date: Thu, 15 Oct 2015 17:03:35 -0400 Message-ID: From: Stan Ratliff To: "Ashish Dalela (adalela)" Content-Type: multipart/alternative; boundary=001a11c39d2c2c92df05222b03a9 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 21:03:40 -0000 --001a11c39d2c2c92df05222b03a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ashish, If you'd like to write a proposed DLEP extension using PFC, I encourage you to do so. As Henning mentioned, more than 1 flow control mechanism is likely for DLEP. Stan On Thu, Oct 15, 2015 at 10:49 AM, Ashish Dalela (adalela) wrote: > Yes it will and that's why I suggested the use of PFC. The control and > data planes will have different priorities. The radio never pauses the > control channel because it is never sent over the air. If desired, the > data packets themselves could be given different priorities allowing some > flows to be selectively paused. > > > Sent from Samsung Mobile > > > -------- Original message -------- > From: Henning Rogge > Date:15/10/2015 18:36 (GMT+05:30) > To: "Ashish Dalela (adalela)" > Cc: manet@ietf.org > Subject: Re: [manet] DLEP Credit Windowing > > On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) > wrote: > > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE > > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism= . > In > > essence, we don=E2=80=99t send credits before packets are forwarded. Ra= ther we > pause > > the traffic when the traffic cannot be forwarded and the buffers are > full. > > PFC is widely used in a number of Ethernet flow-control scenarios today= . > > Would a 802.3 PAUSE Frame not also block the DLEP control channel? > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c39d2c2c92df05222b03a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ashish,=C2=A0

If you'd like to writ= e a proposed DLEP extension using PFC, I encourage you to do so. As Henning= mentioned, more than 1 flow control mechanism is likely for DLEP.

Stan

On Thu, Oct 15, 2015 at 10:49 AM, Ashish Dalela (adalela) = <adalela@cisco.com> wrote:
Yes it will and that's why I suggested the use of PFC. The control= and data planes will have different priorities. The radio never pauses the= control channel because it is never sent over the air. If desired, =C2=A0t= he data packets themselves could be given different priorities allowing some flows to be selectively paused.


Sent from Samsung Mobile


-------- Original message --------
From: Henning Rogge
Date:15/10/2015 18:36 (GMT+05:30)
To: "Ashish Dalela (adalela)"
Cc: manet@ietf.org =
Subject: Re: [manet] DLEP Credit Windowing

On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
<adalela@cisco.co= m> wrote:
> The ideal mechanism for Ethernet flow control is the use of 802.3 PAUS= E
> frames, which has further been enhanced by the PFC (802.1Qbb) mechanis= m. In
> essence, we don=E2=80=99t send credits before packets are forwarded. R= ather we pause
> the traffic when the traffic cannot be forwarded and the buffers are f= ull.
> PFC is widely used in a number of Ethernet flow-control scenarios toda= y.

Would a 802.3 PAUSE Frame not also block the DLEP control channel?

Henning Rogge

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


--001a11c39d2c2c92df05222b03a9-- From nobody Fri Oct 16 02:28:30 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E621B3482 for ; Fri, 16 Oct 2015 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xC3Mz31IaYz for ; Fri, 16 Oct 2015 02:28:28 -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 B25671B3478 for ; Fri, 16 Oct 2015 02:28:27 -0700 (PDT) Received: by lfeh64 with SMTP id h64so73622147lfe.3 for ; Fri, 16 Oct 2015 02:28:26 -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:content-type; bh=vOoI9hFkbtO273X8kUuOEe45VyGR/x5WAlRFIYVfw2Y=; b=HiK6vS+m7Zrp3ALexpWupkFK4tm70Vu0v5qI7bG5KUV+R7imfLJ2MNY+4Gs+QdmENa K1bnwF12jVBGE+hsGxEkxlmSQw8pG42EdLhqLGNGioBKqWrXtqbcPn5gCH0hJTSx3xSJ yw/zm151kaukaySxK3fwNQun+z/3JzeCz/xqW3bLmCUcAw3/UKmOFhdi+HGhMFY3IXSG MMjjSgnO38W4uVI3dr10hjcPImyBQHd4dAf/peNpVrEDw5KKWd8z1tRZ0sLEhAxOEDxR +NMVYRvQ5bLHXgb5jrwHKehvtrodewvKpV5mMQppmfiH+QisLiTFA4T80ccDSyl8Nu57 9uTQ== MIME-Version: 1.0 X-Received: by 10.25.141.198 with SMTP id p189mr5113760lfd.9.1444987705994; Fri, 16 Oct 2015 02:28:25 -0700 (PDT) Received: by 10.25.132.18 with HTTP; Fri, 16 Oct 2015 02:28:25 -0700 (PDT) Date: Fri, 16 Oct 2015 12:58:25 +0330 Message-ID: From: Ahmad Haghighi To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11403be8ebb8a60522356a6e Archived-At: Subject: [manet] Find Sender of Route Reply X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 09:28:29 -0000 --001a11403be8ebb8a60522356a6e Content-Type: text/plain; charset=UTF-8 Hello I'm working on MANET security and Blackhole/Grayhole detection. I have a question, so please help me, or If you have little time and so can't answer me, please refer me to some people or book for finding my answer. my question is: *In MANET (with DSR or AODV) when a Route Reply (RREP) packet received by the source node, the source node can not be sure who is the sender of RREP,* (*it is a assumption in all papers*) so source node (the node which initiated Route Discovery) should do some operations for detecting exact address of Malicious node (sender of malicious RREP). But e.g. in DSR Header we have a "Source Address" field which carries address of sender. or also in IP header of ADOV RREP. I don't understand why source node is *not sure* about identity of sender of RREP? I don't know the reason of above assumption. Let me explain my question more oblivious. Source node, receive a malicious RREP, the source node use it's path for sending packets. As expected Malicious node drops all packets. Ok. Now we want to find malicious node (sender of RREP), If value of "Source Address" Was reliable, we be able to easily find malicious node (sender of RREP). But in all papers, authors employs some mechanisms for detecting malicious node (sender of RREP). so we can conclude value of "Source address" field is not reliable. My question is, why? why source node can not use this field for detecting and removing malicious node? One answer is because of IP Spoofing i.e malicious node can use another address as source address but this not the only reason, I need to find another reason for that I hardly need the answer. So please guide me Thanks --001a11403be8ebb8a60522356a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello
I'm working on MANET security and Blackhole/Grayhole= detection.
I have a question, so please help me, or =C2=A0If you have little time = and so can't answer me, please refer me to some people or book for find= ing my answer. my question is:
In MANET (with DSR or AODV) when a Rout= e Reply (RREP) packet received by the source node, the source node can not = be sure who is the sender of RREP,=C2= =A0(it is a=C2=A0assumption=C2= =A0in all papers) so source no= de (the node which initiated Route Discovery) should do some operations for= detecting exact address of Malicious node (sender of malicious RREP).
B= ut e.g. in DSR Header we have a "Source Address" field which carr= ies address of sender. or also in IP header of ADOV RREP.
I don't un= derstand why source node is *not sure* about identity of sender of RREP?
I don't know th= e reason of above=C2=A0assumption.=

Let me expla= in my question more=C2=A0oblivious.
Source node,= receive a malicious RREP, the source node use it's path for sending pa= ckets. As expected Malicious node drops all packets.
Ok.
Now we want to find malicious node (sen= der of RREP), If value of "Source Address" Was reliable, we be ab= le to easily find malicious node (sender of RREP).
But in all papers, authors employs some=C2=A0mechanisms=C2=A0for detec= ting malicious node (sender of RREP). so we can conclude value of "Sou= rce address" field=C2=A0is not=C2=A0reliable.
My question is, why? why source node can not use this field for detect= ing and removing malicious node?
One answer is b= ecause of IP Spoofing i.e malicious node can use another address as source = address
but this not the only reason, I need to = find another reason for that

I hardly need the answ= er.
So please guide me
Thanks

=

--001a11403be8ebb8a60522356a6e-- From nobody Fri Oct 16 12:39:21 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918CF1B330F for ; Fri, 16 Oct 2015 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt2tI_x2Oihk for ; Fri, 16 Oct 2015 12:39:16 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 AF6AE1B3294 for ; Fri, 16 Oct 2015 12:39:16 -0700 (PDT) Received: by obbda8 with SMTP id da8so98846470obb.1 for ; Fri, 16 Oct 2015 12:39:16 -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:content-type; bh=ZxX24LRdpu3yg/NxYbrHyHkb6zQk/Rx4l0BVwQ5Y8j0=; b=nDaMhGuSRLxJngXYG0IR+eDARKZKSqQLboagJf872H648Ak/Lji3vzk1VlC/fl49K+ iUsVp+ZUHJz0ZzumRg02pNj/GJzx1qz2XCcB0jalXg9AM+2xDxHXScyD9GvoWzyoAMwn omKkDVzY67VRrvQOCxXtd1iNQwsZ/U5rzxlSjWWUbKu5y0C0dnM9Smz16dg2Z8h/mLb7 6xigVQsO9C3CdEpUk5QT2j76YpRUsH4S1wY+jbRltOTFKtAeGBHYYRt4LsGC5gVmhKeq Ip74d+JjjYVbqcE0U6AwKXYGB3afcsA5Tmoc0MyHe5YTE3jtXSnUiGeV9Sa+Foh+4b0l JheQ== MIME-Version: 1.0 X-Received: by 10.182.28.100 with SMTP id a4mr11474085obh.38.1445024355997; Fri, 16 Oct 2015 12:39:15 -0700 (PDT) Received: by 10.202.80.193 with HTTP; Fri, 16 Oct 2015 12:39:15 -0700 (PDT) In-Reply-To: <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <30lejepapqucojc0oo0juiov.1444920593548@email.android.com> <55e6647713b44af09254f05e541433fd@VAUSDITCHM2.idirect.net> Date: Fri, 16 Oct 2015 15:39:15 -0400 Message-ID: From: Justin Dean To: "Ratliff, Stanley" Content-Type: multipart/alternative; boundary=089e014953366e60c205223df303 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 19:39:20 -0000 --089e014953366e60c205223df303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With the draft being split into two it will be more clear that the credit windowing extension is an extension and not the only one possible. I too would encourage those with other thoughts on how to do things better to write a draft and convince everyone on how it's better and we can go from there. The credit windowing draft might not be the perfect way to do it but it doesn't need to be either. Looking forward to seeing the updated drafts. Justin On Thu, Oct 15, 2015 at 1:28 PM, Ratliff, Stanley wrote: > Hello all, > > Well, I am an author, so I think I can speak authoritatively... ;-) > > Yes, the credit-windowing is split out. Credit windowing will be > introduced as a working group document (splitting a WG doc into two docs > implies that both are already WG docs). Further, the docs (DLEP and Credi= t > Windowing) will contain normative references to each other, so they will > progress in lock-step. You can expect the submissions within the next day > or two. > > The credit windowing draft is written as an extension to DLEP. It is not, > by definition, an expression of the *only form* of possible flow control. > By that, I mean that a discussion on PAUSE frames, or some equivalent > scheme, does *not* necessarily invalidate credit windowing. If there is > interest in creating another draft with an additional scheme, I would > encourage someone in the WG to step up to the plate and write it. > > With the normative cross-referencing, a re-litigation of credit windowing > *will* hold up DLEP. > > Regards, > Stan > > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish Dalela > > (adalela) > > Sent: Thursday, October 15, 2015 12:02 PM > > To: Dearlove, Christopher (UK) ; Teco > > Boot ; Henning Rogge > > Cc: manet@ietf.org > > Subject: Re: [manet] DLEP Credit Windowing > > > > > > That is good then. My point is that we should remove credit windowing > from > > this draft before we take it to RFC. We can then separately discuss > credits (or > > an equivalent scheme whose purpose would be to allow a consistent schem= e > > that can be practically implemented in both converged and separated > > control/data planes). > > > > Thanks > > > > -----Original Message----- > > From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] > > Sent: Thursday, October 15, 2015 9:24 PM > > To: Teco Boot ; Henning Rogge ; > > Ashish Dalela (adalela) > > Cc: manet@ietf.org > > Subject: RE: [manet] DLEP Credit Windowing > > > > As Teco indicates, the plan (I'm not an author, but I talked to one > recently) is > > to separate the credit windowing out. So these discussions won't hold u= p > the > > main part of DLEP, and it being WGLCed again. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer > > BAE Systems Applied Intelligence > > __________________________________________________________ > > ________________ > > > > 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, GU= 2 > > 7YP > > > > > > > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Teco Boot > > Sent: 15 October 2015 16:48 > > To: Henning Rogge; Ashish Dalela (adalela) > > Cc: manet@ietf.org > > Subject: Re: [manet] DLEP Credit Windowing > > > > ----------------------! 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= . > > > > > > PFC would be a HW or driver function. > > I don't think PFC solves flow control to remote nodes. This requires pe= r > > destination signaling. > > I agree on having a requirement for diffserv based packet dispatcher wi= th > > AQM and flow isolation. FIFO and priority queues should be something of > the > > past. This is to be discussed after having a Credit-Windowing-00 draft. > > > > Teco > > > > > > > Op 15 okt. 2015, om 16:52 heeft Henning Rogge het > > volgende geschreven: > > > > > > Hi, > > > > > > this sounds like a very interesting thing (we experimented with PAUSE > > > for some time but didn't know about the extension)... do you know if > > > its implemented in Linux? > > > > > > Henning Rogge > > > > > > On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela) > > > wrote: > > >> Yes it will and that's why I suggested the use of PFC. The control > > >> and data planes will have different priorities. The radio never > > >> pauses the control channel because it is never sent over the air. If > > >> desired, the data packets themselves could be given different > > >> priorities allowing some flows to be selectively paused. > > >> > > >> > > >> Sent from Samsung Mobile > > >> > > >> > > >> -------- Original message -------- > > >> From: Henning Rogge > > >> Date:15/10/2015 18:36 (GMT+05:30) > > >> To: "Ashish Dalela (adalela)" > > >> Cc: manet@ietf.org > > >> Subject: Re: [manet] DLEP Credit Windowing > > >> > > >> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela) > > >> wrote: > > >>> The ideal mechanism for Ethernet flow control is the use of 802.3 > > >>> PAUSE frames, which has further been enhanced by the PFC (802.1Qbb) > > mechanism. > > >>> In > > >>> essence, we don=E2=80=99t send credits before packets are forwarded= . Rather > > >>> we pause the traffic when the traffic cannot be forwarded and the > > >>> buffers are full. > > >>> PFC is widely used in a number of Ethernet flow-control scenarios > today. > > >> > > >> Would a 802.3 PAUSE Frame not also block the DLEP control channel? > > >> > > >> 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 > > ********************************************************** > > ********** > > This email and any attachments are confidential to the intended recipie= nt > > and may also be privileged. If you are not the intended recipient pleas= e > > 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 > > _____________________________________________________ > 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 > --089e014953366e60c205223df303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With the draft being split into two it will be more c= lear that the credit windowing extension is an extension and not the only o= ne possible.=C2=A0 I too would encourage those with other thoughts on how t= o do things better to write a draft and convince everyone on how it's b= etter and we can go from there.=C2=A0 The credit windowing draft might not = be the perfect way to do it but it doesn't need to be either.=C2=A0 Loo= king forward to seeing the updated drafts.

Justin

On Thu, Oct 15, = 2015 at 1:28 PM, Ratliff, Stanley <sratliff@idirect.net> = wrote:
Hello all,

Well, I am an author, so I think I can speak authoritatively... ;-)

Yes, the credit-windowing is split out. Credit windowing will be introduced= as a working group document (splitting a WG doc into two docs implies that= both are already WG docs). Further, the docs (DLEP and Credit Windowing) w= ill contain normative references to each other, so they will progress in lo= ck-step. You can expect the submissions within the next day or two.

The credit windowing draft is written as an extension to DLEP. It is not, b= y definition, an expression of the *only form* of possible flow control. By= that, I mean that a discussion on PAUSE frames, or some equivalent scheme,= does *not* necessarily invalidate credit windowing. If=C2=A0 there is inte= rest in creating another draft with an additional scheme, I would encourage= someone in the WG to step up to the plate and write it.

With the normative cross-referencing, a re-litigation of credit windowing *= will* hold up DLEP.

Regards,
Stan


> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Ashish Dalela
> (adalela)
> Sent: Thursday, October 15, 2015 12:02 PM
> To: Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>; Teco
> Boot <teco@inf-net.nl>; H= enning Rogge <hrogge@gmail.com&g= t;
> Cc: manet@ie= tf.org
> Subject: Re: [manet] DLEP Credit Windowing
>
>
> That is good then. My point is that we s= hould remove credit windowing from
> this draft before we take it to RFC. We can then separately discuss cr= edits (or
> an equivalent scheme whose purpose would be to allow a consistent sche= me
> that can be practically implemented in both converged and separated > control/data planes).
>
> Thanks
>
> -----Original Message-----
> From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com]
> Sent: Thursday, October 15, 2015 9:24 PM
> To: Teco Boot <teco@inf-net.nl>; Henning Rogge <hrogge@gmail.= com>;
> Ashish Dalela (adalela) <adale= la@cisco.com>
> Cc: manet@ietf.org
> Subject: RE: [manet] DLEP Credit Windowing
>
> As Teco indicates, the plan (I'm not an author, but I talked to on= e recently) is
> to separate the credit windowing out. So these discussions won't h= old up the
> main part of DLEP, and it being WGLCed again.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> __________________________________________________________
> ________________
>
> 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 & W= ales No:
> 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, G= U2
> 7YP
>
>
>
> -----Original Message-----
> From: manet [mailto:manet-bo= unces@ietf.org] On Behalf Of Teco Boot
> Sent: 15 October 2015 16:48
> To: Henning Rogge; Ashish Dalela (adalela)
> Cc: manet@ietf.org
> Subject: Re: [manet] DLEP Credit Windowing
>
> ----------------------! 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 i= nstructions on
> reporting suspicious email messages.
> --------------------------------------------------------
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organizatio= n.
>
>
> PFC would be a HW or driver function.
> I don't think PFC solves flow control to remote nodes. This requir= es per
> destination signaling.
> I agree on having a requirement for diffserv based packet dispatcher w= ith
> AQM and flow isolation. FIFO and priority queues should be something o= f the
> past. This is to be discussed after having a Credit-Windowing-00 draft= .
>
> Teco
>
>
> > Op 15 okt. 2015, om 16:52 heeft Henning Rogge <hrogge@gmail.com> het
> volgende geschreven:
> >
> > Hi,
> >
> > this sounds like a very interesting thing (we experimented with P= AUSE
> > for some time but didn't know about the extension)... do you = know if
> > its implemented in Linux?
> >
> > Henning Rogge
> >
> > On Thu, Oct 15, 2015 at 4:49 PM, Ashish Dalela (adalela)
> > <adalela@cisco.com>= ; wrote:
> >> Yes it will and that's why I suggested the use of PFC. Th= e control
> >> and data planes will have different priorities. The radio nev= er
> >> pauses the control channel because it is never sent over the = air. If
> >> desired,=C2=A0 the data packets themselves could be given dif= ferent
> >> priorities allowing some flows to be selectively paused.
> >>
> >>
> >> Sent from Samsung Mobile
> >>
> >>
> >> -------- Original message --------
> >> From: Henning Rogge
> >> Date:15/10/2015 18:36 (GMT+05:30)
> >> To: "Ashish Dalela (adalela)"
> >> Cc: manet@ietf.org
> >> Subject: Re: [manet] DLEP Credit Windowing
> >>
> >> On Thu, Oct 15, 2015 at 2:25 PM, Ashish Dalela (adalela)
> >> <adalela@cisco.com> wrote:
> >>> The ideal mechanism for Ethernet flow control is the use = of 802.3
> >>> PAUSE frames, which has further been enhanced by the PFC = (802.1Qbb)
> mechanism.
> >>> In
> >>> essence, we don=E2=80=99t send credits before packets are= forwarded. Rather
> >>> we pause the traffic when the traffic cannot be forwarded= and the
> >>> buffers are full.
> >>> PFC is widely used in a number of Ethernet flow-control s= cenarios today.
> >>
> >> Would a 802.3 PAUSE Frame not also block the DLEP control cha= nnel?
> >>
> >> 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
> **********************************************************
> **********
> This email and any attachments are confidential to the intended recipi= ent
> and may also be privileged. If you are not the intended recipient plea= se
> delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or distr= ibute its
> contents to any other person.
> **********************************************************
> **********
> _______________________________________________
> 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.
_____________________________________________________
___________________________________= ____________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--089e014953366e60c205223df303-- From nobody Fri Oct 16 17:04:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AF1A8764; Fri, 16 Oct 2015 17:04:33 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr49kKk7uHKU; Fri, 16 Oct 2015 17:04:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 944191A036E; Fri, 16 Oct 2015 17:04:32 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151017000432.27350.48906.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 17:04:32 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-credit-window-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 00:04:33 -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 Working Group of the IETF. Title : Credit Windowing extension for DLEP Author : Stan Ratliff Filename : draft-ietf-manet-credit-window-00.txt Pages : 9 Date : 2015-10-16 Abstract: Extends 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-00 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 Fri Oct 16 17:06:29 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703491A87BF; Fri, 16 Oct 2015 17:06:26 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzpRQ1ZsESNN; Fri, 16 Oct 2015 17:06:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5691A882A; Fri, 16 Oct 2015 17:06:21 -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.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151017000621.21337.90882.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 17:06:21 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-17.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 00:06:26 -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 Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-17.txt Pages : 64 Date : 2015-10-16 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-17 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 lanilsson@gmail.com Sat Oct 17 02:27:20 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050A91A92FF for ; Sat, 17 Oct 2015 02:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH-gjW4lH78V for ; Sat, 17 Oct 2015 02:27:19 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11721A92FE for ; Sat, 17 Oct 2015 02:27:18 -0700 (PDT) Received: by iodv82 with SMTP id v82so146456444iod.0 for ; Sat, 17 Oct 2015 02:27:18 -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 :content-type; bh=JpoN766f+p1YtugBaBMMrgh/YrgVlJhGM5+eOODsCB4=; b=yRzVyOyvPb6o9eN7MYm++j7+iXn9sdySZZq5eYvNUpR141/hbsbQxmOSaET7RtacSK tPjPQnwgpbn8oFdFTG/pf5jfhxyKrcOoAvBtBM/q9S1Y86gLCrNsuXpuJSvVPt3Wdhiq r5rXL492DDr4oEs3YmNQf1TfLCN57aV0gOrTPqXFaBD48s04lSCg0lcpllb6sTvsqY4C nQN9mHcGcOwkjaX+//WNIIl6kGTqbJBdMmgsoIRrGx5CNC5MvPZk+DL1OUKVJ87D8QIK gcGXC3yGaScCBnwyuh8tLUIhQj9iQh9RqR05mjTjxnrfbvoNsIcyW5JdVYIXg4dWsqAG 1R7w== MIME-Version: 1.0 X-Received: by 10.107.19.106 with SMTP id b103mr20377625ioj.144.1445074038249; Sat, 17 Oct 2015 02:27:18 -0700 (PDT) Received: by 10.79.33.65 with HTTP; Sat, 17 Oct 2015 02:27:18 -0700 (PDT) Received: by 10.79.33.65 with HTTP; Sat, 17 Oct 2015 02:27:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Oct 2015 11:27:18 +0200 Message-ID: From: Anders Nilsson Plymoth To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a113f63a4b962b1052249849f Archived-At: Subject: [manet] AODV implementations in Java X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 09:29:08 -0000 --001a113f63a4b962b1052249849f Content-Type: text/plain; charset=UTF-8 Hi I am looking for a reference implementation of AODV in Java, preferably AODVv2. There used to be one from UoB but that site now contain japanese porn instead. Does anyone know about a Java implementation available for AODV-RFC or draft AODVv2? Anyone here involved with AODVv2 working with Java? Thanks Anders --001a113f63a4b962b1052249849f Content-Type: text/html; charset=UTF-8

Hi

I am looking for a reference implementation of AODV in Java, preferably AODVv2. There used to be one from UoB but that site now contain japanese porn instead.
Does anyone know about a Java implementation available for AODV-RFC or draft AODVv2?
Anyone here involved with AODVv2 working with Java?

Thanks
Anders

--001a113f63a4b962b1052249849f-- From nobody Sat Oct 17 03:00:43 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1721ACCF4 for ; Sat, 17 Oct 2015 03:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d09oZyujTGzg for ; Sat, 17 Oct 2015 03:00: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 1C95F1ACCEF for ; Sat, 17 Oct 2015 03:00:38 -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; Sat, 17 Oct 2015 11:00:09 +0100 From: Rick Taylor To: "Ashish Dalela (adalela)" , "manet@ietf.org" Thread-Topic: DLEP Credit Windowing Thread-Index: AdEHQsnoEIjbPaGbSsi7klNsrLls3ABfxhcQ Date: Sat, 17 Oct 2015 10:00:01 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> In-Reply-To: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 10:00:42 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2tssserver1hom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ashish, In the forthcoming draft-17 of DLEP, the credit windowing extension has bee= n removed and placed into its own draft document, as several other people h= ave expressed opinions about the credit windowing mechanism. By doing so, t= he authors hope that it becomes more obvious that the credit windowing exte= nsion is simply that, an extension; allowing those people who liked the PPP= oE style credit windowing to continue to use it with DLEP, but allowing oth= ers to use DLEP without worrying about credit windowing. Thanks for your comment, Rick Taylor From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish Dalela (ada= lela) Sent: 15 October 2015 13:25 To: manet@ietf.org Subject: [manet] DLEP Credit Windowing Hello Team, I have a comment regarding the credit windowing scheme on the DLEP draft. T= hese credits are exchanged through control plane packets, and these schemes= will work well for routers where the control and data planes are converged= . When the control and data planes are separate, translating these credit e= xchanges to packet rate flow control in hardware (e.g. ASICs) is a difficul= t practical issue. I understand that the PPPoE scheme in RFC 5578 employed a credit scheme and= a similar scheme has been carried forward for DLEP as well. However, there= is a big difference between running credits over PPPoE sessions and Ethern= et based forwarding where there is no notion of a "session". For instance, = even if we program a certain number of bytes to be forwarded on an Ethernet= port on an ASIC, after a while the packets lying in the queue will be drop= ped. The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE fra= mes, which has further been enhanced by the PFC (802.1Qbb) mechanism. In es= sence, we don't send credits before packets are forwarded. Rather we pause = the traffic when the traffic cannot be forwarded and the buffers are full. = PFC is widely used in a number of Ethernet flow-control scenarios today. I would suggest the authors to consider removing the credit windowing schem= e from DLEP and defer to Ethernet flow-control. Thanks -Ashish --_000_38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2tssserver1hom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ashish= ,

 =

In the forthcoming draft-17 of DLEP, the cr= edit windowing extension has been removed and placed into its own draft doc= ument, as several other people have expressed opinions about the credit win= dowing mechanism. By doing so, the authors hope that it becomes more obviou= s that the credit windowing extension is simply that, an extension; allowin= g those people who liked the PPPoE style credit windowing to continue to us= e it with DLEP, but allowing others to use DLEP without worrying about cred= it windowing.

 <= /o:p>

Thanks for your comment,

Rick Taylor

 

 

From: manet [mailto:manet-bounces@ietf.org] On Beh= alf Of Ashish Dalela (adalela)
Sent: 15 October 2015 13:25To: manet@ietf.org
Subject: [manet] DLEP Credit Windowing=

 

Hello Team,

 

I have a comment r= egarding the credit windowing scheme on the DLEP draft. These credits are e= xchanged through control plane packets, and these schemes will work well fo= r routers where the control and data planes are converged. When the control= and data planes are separate, translating these credit exchanges to packet= rate flow control in hardware (e.g. ASICs) is a difficult practical issue.=

 

I understand that the PPPoE scheme in RFC 5578 em= ployed a credit scheme and a similar scheme has been carried forward for DL= EP as well. However, there is a big difference between running credits over= PPPoE sessions and Ethernet based forwarding where there is no notion of a= “session”. For instance, even if we program a certain number o= f bytes to be forwarded on an Ethernet port on an ASIC, after a while the p= ackets lying in the queue will be dropped.

 

= The ide= al mechanism for Ethernet flow control is the use of 802.3 PAUSE frames, wh= ich has further been enhanced by the PFC (802.1Qbb) mechanism. In essence, = we don’t send credits before packets are forwarded. Rather we pause t= he traffic when the traffic cannot be forwarded and the buffers are full. P= FC is widely used in a number of Ethernet flow-control scenarios today.

 

I would suggest the authors to consider removing the = credit windowing scheme from DLEP and defer to Ethernet flow-control. =

 

Thanks

-A= shish

 

= --_000_38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2tssserver1hom_-- From nobody Sat Oct 17 03:16:31 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26C81ACD82 for ; Sat, 17 Oct 2015 03:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB5eSzhKoEUp for ; Sat, 17 Oct 2015 03:16:28 -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 B12981ACD7D for ; Sat, 17 Oct 2015 03:16:27 -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; Sat, 17 Oct 2015 11:16:02 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , "manet@ietf.org" Thread-Topic: DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBwBm9nRw Date: Sat, 17 Oct 2015 10:15:59 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 10:16:30 -0000 Thanks for the quick review Chris, As far as the whole 'modem' versus 'radio' wording is concerned: I share yo= ur slight discomfort with the word 'modem', but I'm not sure 'radio' is any= better! For example, I have some scruffy code which pretends to be a DLEP= modem for DMVPN tunnels, and there's definitely no radio involved. I'm definitely willing to listen to suggestions from the WG for words to re= place 'modem' with a word to mean 'a device that forwards layer-2 packets t= o its peers, has link sensing, and is commonly some kind of radio'. Whethe= r we make the change depends entirely on whether the WG has the patience. ;= ) I believe (I haven't got draft-17 open in front of me) that we have tackled= some of your issues with the RFC 5226 terminology in 17 as well, using 'Pr= ivate Use' instead of 'Reserved' when appropriate. Cheers, Rick -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, Christop= her (UK) Sent: 15 October 2015 10:22 To: manet@ietf.org Subject: [manet] DLEP I've read DLEP draft 16, but not so far with a critical eye to specific rev= iew comments - other than that the IANA section isn't what's needed (but th= e authors already know that and I understand have already written a replace= ment) and a few editorial comments I'll make below. In particular I haven't= formed a view on the security considerations section - but I may wait for = this and most other points to see -17 which I understand is mostly written. My minor points: - I really would prefer "radio" to "modem" throughout. As someone who once = wrote some modem software, for me modem is what it says, modulation and dem= odulation (and the inseparable channel coding), i.e. converting between bit= streams and modulated signals (for a digital radio).There are many parts o= f a radio that are outside that, and everything DLEP is outside the modem. - Where there are various time and other values (timeouts, repeat periods, = number of retries) I'd use a symbolic name and collect suggested default va= lues in one place. That is after all, as we all write software. - Currently describes some code points as "Reserved for future extensions".= This is not the correct terminology. From RFC 5226: Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. (The Reserved for 0 and 65535 is however presumably correct.) As I know the IANA considerations section is done, this may already have= been caught, but I'll say it in case not. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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 7Y= P ******************************************************************** This email and any attachments are confidential to the intended recipient a= nd may also be privileged. If you are not the intended recipient please del= ete 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 Sat Oct 17 08:58:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65A21ACE9A for ; Sat, 17 Oct 2015 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 0PPJqwaV56xO for ; Sat, 17 Oct 2015 08:58:33 -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 1C9B11ACE7C for ; Sat, 17 Oct 2015 08:58:33 -0700 (PDT) Received: by vkaw128 with SMTP id w128so83913795vka.0 for ; Sat, 17 Oct 2015 08:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5+oDaakOMQI3gDGI0PjunsYQNcb17+lwR4lidwBTi48=; b=EF8KxeQ+mpCq8yeJFa1DEZ9sRhMTAPDt+gvzIqnGG7M9lMgTY5Oibf42aax7hSiTBW zNAjIdYKd36A2obgbiG+OrFhEjwfCeFfGg+cOH3m2QZ6rM+XHH7WQjRgrMp/l6mlyyJg M2zI51CbUuHl87VdNG6hKE20qeMz3M8b4vp/U= 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-type :content-transfer-encoding; bh=5+oDaakOMQI3gDGI0PjunsYQNcb17+lwR4lidwBTi48=; b=AA6FT+0Vjr/0vqXEyD4Xyr24Uns2DzC4FHlufeNqZggqK6qi0w4+4x2IgDUZKB6soS mwqYsk8OFFO/dwjb41jLU4s5eVzdMol+qcAjBi3WD0YC5xaHSyTXS3oZ2nGFvjPU7f2Z X3mpkiUz1OkICZ5sKMI/MV46S87z3nCsTdLjoKCAk/4SDvrc1ih0AqAfFjLwG8/M3RMG +sfKfRwd/dh/sirO0EqeegpwbhyrrGprPcYIbtUY0jljfwRW8UN6MmFbFNMW8dTeXWYR 78SK++m5enisC9N2jCPwVeb1SuaEmqjHcQj8471KXp5SCpF7St71Nzotrgxr/4Y85p6f gOBg== X-Gm-Message-State: ALoCoQnwKcYJF7YBF5oSJhs7xyG0oxmJDiGxdqq/99lBnwBEZgArI+iHfDSZ3lFU7yRUH0Dh2cAA MIME-Version: 1.0 X-Received: by 10.31.9.81 with SMTP id 78mr13177683vkj.10.1445097512183; Sat, 17 Oct 2015 08:58:32 -0700 (PDT) Received: by 10.31.96.85 with HTTP; Sat, 17 Oct 2015 08:58:32 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> Date: Sat, 17 Oct 2015 08:58:32 -0700 Message-ID: From: Ulrich Herberg To: Rick Taylor , "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 15:58:35 -0000 Hi Rick, I thought the purpose of splitting off the credit window draft is to accelerate DLEP? But now there is a normative reference to it from DLEP, so there is really no gain at all. Also, it contradicts what Alvaro wrote in a previous email: > "BTW, you wrote above that the "base DLEP draft normatively references Credit windowing as an example". An example shouldn't be normative." Also, the new draft was immediately posted as WG draft without asking the WG for consensus to adopt it first. I am not opposed to adopting it, but I think the process is a bit strange here. Regard Ulrich On Sat, Oct 17, 2015 at 3:00 AM, Rick Taylor wrote: > Hi Ashish, > > > > In the forthcoming draft-17 of DLEP, the credit windowing extension has b= een > removed and placed into its own draft document, as several other people h= ave > expressed opinions about the credit windowing mechanism. By doing so, the > authors hope that it becomes more obvious that the credit windowing > extension is simply that, an extension; allowing those people who liked t= he > PPPoE style credit windowing to continue to use it with DLEP, but allowin= g > others to use DLEP without worrying about credit windowing. > > > > Thanks for your comment, > > Rick Taylor > > > > > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ashish Dalela > (adalela) > Sent: 15 October 2015 13:25 > To: manet@ietf.org > Subject: [manet] DLEP Credit Windowing > > > > Hello Team, > > > > I have a comment regarding the credit windowing scheme on the DLEP draft. > These credits are exchanged through control plane packets, and these sche= mes > will work well for routers where the control and data planes are converge= d. > When the control and data planes are separate, translating these credit > exchanges to packet rate flow control in hardware (e.g. ASICs) is a > difficult practical issue. > > > > I understand that the PPPoE scheme in RFC 5578 employed a credit scheme a= nd > a similar scheme has been carried forward for DLEP as well. However, ther= e > is a big difference between running credits over PPPoE sessions and Ether= net > based forwarding where there is no notion of a =E2=80=9Csession=E2=80=9D.= For instance, even > if we program a certain number of bytes to be forwarded on an Ethernet po= rt > on an ASIC, after a while the packets lying in the queue will be dropped. > > > > The ideal mechanism for Ethernet flow control is the use of 802.3 PAUSE > frames, which has further been enhanced by the PFC (802.1Qbb) mechanism. = In > essence, we don=E2=80=99t send credits before packets are forwarded. Rath= er we pause > the traffic when the traffic cannot be forwarded and the buffers are full= . > PFC is widely used in a number of Ethernet flow-control scenarios today. > > > > I would suggest the authors to consider removing the credit windowing sch= eme > from DLEP and defer to Ethernet flow-control. > > > > Thanks > > -Ashish > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Sat Oct 17 09:50:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACAC1A1B84 for ; Sat, 17 Oct 2015 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1YMFTp8mdIY for ; Sat, 17 Oct 2015 09:50:43 -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 E03121A1B27 for ; Sat, 17 Oct 2015 09:50:42 -0700 (PDT) Received: by lfaz124 with SMTP id z124so91165856lfa.1 for ; Sat, 17 Oct 2015 09: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:content-type; bh=NnDQDWSGdV3G+XFwSLV00gdLqliPjzGkbIpQOHkk1bE=; b=CF6f2sOIBOF16sikaqQEIRWi2Te3LvjXGYHwAhzyzKe+SxwZkdHWSebWoIttu0WRZO qpAdGhjIFdRTBZUaFCTb2OBtPFG9Z4HeGy+G0tK0huAuiJkxruwt3pK8UTzTDLqolRKK iCOHBUv2qGhRI+jLUU4jpx4S86o0G0c397feVTPHLnbPlJp6mIn/8DAjShvXjdfonFA+ REMtE6rqOBJfCSXDnX94+4WQu6gHOpwDruA9gvGHGmYD22AX87Cs1904GRC5KidXhuHC /yVKN6+rvLKzCbhym0AY0KrPacp6q8nWWKAU/y6Yh3Z7YuFo7X5XqSEGGyGKJfve4sRq c67g== MIME-Version: 1.0 X-Received: by 10.25.154.203 with SMTP id c194mr317066lfe.32.1445100641028; Sat, 17 Oct 2015 09:50:41 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Sat, 17 Oct 2015 09:50:40 -0700 (PDT) In-Reply-To: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> Date: Sat, 17 Oct 2015 12:50:40 -0400 Message-ID: From: Stan Ratliff To: Ulrich Herberg Content-Type: multipart/alternative; boundary=001a114016045f952f05224fb6fa Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2015 16:50:45 -0000 --001a114016045f952f05224fb6fa Content-Type: text/plain; charset=UTF-8 Ulrich, The credit windowing draft was submitted as a WG document since this was a split of one WG doc (DLEP-16) into two. According to the guidance I had at the time, from Lou Berger, that's acceptable since credit windowing was already "accepted" by the WG (it was accepted as part of the original DLEP). Stan On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg wrote: > Hi Rick, > > I thought the purpose of splitting off the credit window draft is to > accelerate DLEP? But now there is a normative reference to it from > DLEP, so there is really no gain at all. Also, it contradicts what > Alvaro wrote in a previous email: > > > "BTW, you wrote above that the "base DLEP draft normatively references > Credit windowing as an example". An example shouldn't be normative." > > Also, the new draft was immediately posted as WG draft without asking > the WG for consensus to adopt it first. I am not opposed to adopting > it, but I think the process is a bit strange here. > > Regard > Ulrich > > --001a114016045f952f05224fb6fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ulrich,=C2=A0

The credit windowing draf= t was submitted as a WG document since this was a split of one WG doc (DLEP= -16) into two. According to the guidance I had at the time, from Lou Berger= , that's acceptable since credit windowing was already "accepted&q= uot; by the WG (it was accepted as part of the original DLEP).=C2=A0
<= div>
Stan


On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg <u= lrich@herberg.name> wrote:
= Hi Rick,

I thought the purpose of splitting off the credit window draft is to
accelerate DLEP? But now there is a normative reference to it from
DLEP, so there is really no gain at all. Also, it contradicts what
Alvaro wrote in a previous email:

> "BTW, you wrote above that the "base DLEP draft normatively = references
Credit windowing as an example".=C2=A0 An example shouldn't be nor= mative."

Also, the new draft was immediately posted as WG draft without asking
the WG for consensus to adopt it first. I am not opposed to adopting
it, but I think the process is a bit strange here.

Regard
Ulrich

--001a114016045f952f05224fb6fa-- From nobody Sun Oct 18 03:13:50 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB71B2EB7 for ; Sun, 18 Oct 2015 03:13:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VGCu1g7K8iC for ; Sun, 18 Oct 2015 03:13:47 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 84F591B2EBA for ; Sun, 18 Oct 2015 03:13:47 -0700 (PDT) Received: by wikq8 with SMTP id q8so14650839wik.1 for ; Sun, 18 Oct 2015 03:13: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:from:date:message-id:subject:to :cc:content-type; bh=wiLlSdEVeYwPIrTVtx44Idk8EkxS1+KnUu6Zt4iahA4=; b=fDRdPGyCdzEwi0YIA3hGZPHSmjn5HDQSGEAUnABjNbzW/zNUeuC86WC7m4UkWZXc/f baZL0YYrsl3ajUVU/DYUEqgfTWOU/5OkJs+N6IGOMc5Vkfv3XFXJQccU4g59brf1y5wJ /TVoS9SEc5IHSrBUKAJfL8JGQhUa9uL2W/Pl/7JXQ36Sqlmvs2gN28yobgQB/yduv93u irnqu141Pt7K/CC9b/tppm3LvaBgQpQWp4CnbGZmSBu5nImyDTgi2e05Xx4BuvjF5bg9 WjfaEzeijTYI+4F/wOmLS1hAhyaezwQd82j6/tNvJHz74kEgnwe4AceCCAhylQihPAlN u9xw== X-Received: by 10.180.9.74 with SMTP id x10mr13994540wia.61.1445163226024; Sun, 18 Oct 2015 03:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Sun, 18 Oct 2015 03:13:16 -0700 (PDT) In-Reply-To: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Sun, 18 Oct 2015 12:13:16 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 10:13:49 -0000 On Sat, Oct 17, 2015 at 6:50 PM, Stan Ratliff wrote: > Ulrich, > > The credit windowing draft was submitted as a WG document since this was a > split of one WG doc (DLEP-16) into two. According to the guidance I had at > the time, from Lou Berger, that's acceptable since credit windowing was > already "accepted" by the WG (it was accepted as part of the original DLEP). I think it was also mentioned at the last IETF meeting that the plan was to progress both drafts in parallel. Henning Rogge From nobody Sun Oct 18 06:07:12 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832F81A6F4C for ; Sun, 18 Oct 2015 06:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 TXzwIuGHKHmT for ; Sun, 18 Oct 2015 06:07:08 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 3956A1A6F45 for ; Sun, 18 Oct 2015 06:07:08 -0700 (PDT) Received: (qmail 10276 invoked by uid 0); 18 Oct 2015 13:07:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 18 Oct 2015 13:07:00 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Wd6w1r0052SSUrH01d6zAi; Sun, 18 Oct 2015 07:07:00 -0600 X-Authority-Analysis: v=2.1 cv=IekUBwaa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=uatV8ciq1sMA:10 a=5lJygRwiOn0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=Qvd3nZa3dIX5VdFwhxcA:9 a=IU1kuscoXZJQ1vWr:21 a=PFjAXrXW5IDiwynS:21 a=CjuIK1q_8ugA:10 a=f8r6Ixb0u_ctLlwII-QA:9 a=by-6UIBwAWztZ32k:21 a=J98DNZ4Yjrq-Y936:21 a=-yYaCFgRGfP1EdyW:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=8mLy+CIDhhkbEhOlDFX70S6s95zfSe+EabkPl4znA9k=; b=uAXDWEtPLl6dXoDxMray6qq+bTXw3OerKMlYgqTPQxiu29XJMfRK7hWmEnfku6DZma8+si7gW6WfxfwySgHoI+ERpLBu5v6BsEsgKiyA2idB0dbeHYYfitdYDNZN38ts; Received: from [208.54.45.231] (port=39423 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Znnfr-0002Fj-Rj; Sun, 18 Oct 2015 07:06:56 -0600 From: Lou Berger To: Stan Ratliff , Ulrich Herberg Date: Sun, 18 Oct 2015 09:06:49 -0400 Message-ID: <1507b0f3e40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.14 (build: 22000040) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1507b0f42735516281842cf84e0" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 208.54.45.231 authed with lberger@labn.net} Archived-At: Cc: manet@ietf.org Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 13:07:10 -0000 This is a multi-part message in MIME format. ------------1507b0f42735516281842cf84e0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit On October 17, 2015 12:51:32 PM Stan Ratliff wrote: > Ulrich, > > The credit windowing draft was submitted as a WG document since this was a > split of one WG doc (DLEP-16) into two. According to the guidance I had at > the time, from Lou Berger, that's acceptable since credit windowing was > already "accepted" by the WG (it was accepted as part of the original > DLEP). > I believe my statement was along the lines of it being perfectly reasonable to start a new document as a WG document when it is split from an existing wg draft, and have seen this done before. Either way it's the chairs call... Lou > Stan > > > On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg > wrote: > >> Hi Rick, >> >> I thought the purpose of splitting off the credit window draft is to >> accelerate DLEP? But now there is a normative reference to it from >> DLEP, so there is really no gain at all. Also, it contradicts what >> Alvaro wrote in a previous email: >> >> > "BTW, you wrote above that the "base DLEP draft normatively references >> Credit windowing as an example". An example shouldn't be normative." >> >> Also, the new draft was immediately posted as WG draft without asking >> the WG for consensus to adopt it first. I am not opposed to adopting >> it, but I think the process is a bit strange here. >> >> Regard >> Ulrich >> >> > > > > ---------- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > ------------1507b0f42735516281842cf84e0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

On October 17, 2015 12:51:32 PM Stan Ratliff <ratliffstan@gmail.com> wrote:

> Ulrich,
>
> The credit windowing draft was submitted as a WG document since this was a
> split of one WG doc (DLEP-16) into two. According to the guidance I had at
> the time, from Lou Berger, that's acceptable since credit windowing was
> already "accepted" by the WG (it was accepted as part of the original
> DLEP).
>

I believe my statement was along the lines of it being perfectly reasonable to start a new document as a WG document when  it is split from an existing wg draft, and have seen this done before. 

Either way it's the chairs call...

Lou

> Stan
>
>
> On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg <ulrich@herberg.name>
> wrote:
>
>> Hi Rick,
>>
>> I thought the purpose of splitting off the credit window draft is to
>> accelerate DLEP? But now there is a normative reference to it from
>> DLEP, so there is really no gain at all. Also, it contradicts what
>> Alvaro wrote in a previous email:
>>
>> > "BTW, you wrote above that the "base DLEP draft normatively references
>> Credit windowing as an example".  An example shouldn't be normative."
>>
>> Also, the new draft was immediately posted as WG draft without asking
>> the WG for consensus to adopt it first. I am not opposed to adopting
>> it, but I think the process is a bit strange here.
>>
>> Regard
>> Ulrich
>>
>>
>
>
>
> ----------
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

------------1507b0f42735516281842cf84e0-- From nobody Sun Oct 18 09:57:35 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18291A90E5 for ; Sun, 18 Oct 2015 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 6LysRQquL7RO for ; Sun, 18 Oct 2015 09:57:31 -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 2DFC61A90E1 for ; Sun, 18 Oct 2015 09:57:30 -0700 (PDT) Received: by vkex70 with SMTP id x70so85615496vke.3 for ; Sun, 18 Oct 2015 09:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rGuNOBJQZGuuqS1PFW/ULrW0K5IFQ1BmxjnZ3h2yZ2E=; b=pZMRILZgO6nPCODrzDRqLZfHeBQDBEU8zxuII83UjiScLSmnC+8ECHWlHsQ/vxnR7R LJ35+8lYOFAUPdhnMbaLo9BDGvnTQZzp+7xFfsZAAY2vpVFLOnJW/Ii3HHeMRPZYLrg9 BsPe92JBGgoL883gINf2FpJ/nm1sja4HnlN1o= 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-type; bh=rGuNOBJQZGuuqS1PFW/ULrW0K5IFQ1BmxjnZ3h2yZ2E=; b=J3kwocj+lEF3GNo9QPnWyYiN4mRlQKVTjiI5QCX93JnquVHDlBag4UWJw4fC9ozMWS rmaaFIOSbpXRd97OUPzfcSgeCEqZvvHW0PBubAKdSAewlgzDTuuOEa83salGyJfddDbF la0sZ6rZmKiYDDb837uZZBiraW5R5urVlTSgGQf6OER+pKAI9xRDDAtTJOJkPxbeM6dq bhC0GuA6+5VIQFXchux8FbkmcYuPoo2odS/ZI3zAxEU9M9rqk15KWIinCsvT/h9ZeKBK IjO3aLgz3AN00ful2h8Afw8GSLMe54BYbheBfzBMQoU1Fc+2yMtuFnjxKCSpLs5NSM/A /KBg== X-Gm-Message-State: ALoCoQlwjIVDljMeMe/ffMfhKiQ6mJ9itZIw0qWJtijiq7r7niYQKFa143xdhroIVL2c72OEqDqZ MIME-Version: 1.0 X-Received: by 10.31.180.79 with SMTP id d76mr10722002vkf.111.1445187449937; Sun, 18 Oct 2015 09:57:29 -0700 (PDT) Received: by 10.31.96.85 with HTTP; Sun, 18 Oct 2015 09:57:29 -0700 (PDT) In-Reply-To: <1507b0f3e40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> <1507b0f3e40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Sun, 18 Oct 2015 09:57:29 -0700 Message-ID: From: Ulrich Herberg To: Lou Berger Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet@ietf.org Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 16:57:33 -0000 Understood. Thanks Ulrich On Sun, Oct 18, 2015 at 6:06 AM, Lou Berger wrote: > On October 17, 2015 12:51:32 PM Stan Ratliff wrote: > >> Ulrich, >> >> The credit windowing draft was submitted as a WG document since this was a >> split of one WG doc (DLEP-16) into two. According to the guidance I had at >> the time, from Lou Berger, that's acceptable since credit windowing was >> already "accepted" by the WG (it was accepted as part of the original >> DLEP). >> > > I believe my statement was along the lines of it being perfectly reasonable > to start a new document as a WG document when it is split from an existing > wg draft, and have seen this done before. > > Either way it's the chairs call... > > Lou > >> Stan >> >> >> On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg >> wrote: >> >>> Hi Rick, >>> >>> I thought the purpose of splitting off the credit window draft is to >>> accelerate DLEP? But now there is a normative reference to it from >>> DLEP, so there is really no gain at all. Also, it contradicts what >>> Alvaro wrote in a previous email: >>> >>> > "BTW, you wrote above that the "base DLEP draft normatively references >>> Credit windowing as an example". An example shouldn't be normative." >>> >>> Also, the new draft was immediately posted as WG draft without asking >>> the WG for consensus to adopt it first. I am not opposed to adopting >>> it, but I think the process is a bit strange here. >>> >>> Regard >>> Ulrich >>> >>> >> >> >> >> ---------- >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> From nobody Sun Oct 18 13:38:47 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B548B1AD09A for ; Sun, 18 Oct 2015 13:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWqO24-kMp_N for ; Sun, 18 Oct 2015 13:38:44 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 BCBDA1AD094 for ; Sun, 18 Oct 2015 13:38:44 -0700 (PDT) Received: by oiao187 with SMTP id o187so31291489oia.3 for ; Sun, 18 Oct 2015 13:38:44 -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:content-type; bh=NE+MlzxJAukT+dfE2SI5TNE2VH6yk3P4MGOV0cEX7aY=; b=QFr+Ie4CPDJx+OQoAp5H/PckWu5jcvwkiWVRYwuOwUbsqnVOYzej5SsocUX3SzKBBs DAvbXeeDyxZl863PtNQkgfx/6nC7H77z4/tadfWtQNI0Dd0bku+k5PvZ4+FSvSObp/iJ uRSZ2oovgtIQd/VJ8SqED9GyqkVV/+KJ2osVCOwE+2FIgk+Vuol5GSdpUxqJfSWezDJZ X3suU4z/GzhXqQMoIUIWrgc/3lz92vJjj0grEbpfx4frcAL8GvHDunRWk3Y170dv1iKI GYmDuRR3FV/dtgVDjazU4aflMBfZONqOlOmFFnEyA5lhe3+u9XzvL2pwbNPhMsg9YaFu pRHA== X-Received: by 10.202.73.73 with SMTP id w70mr7035652oia.94.1445200724164; Sun, 18 Oct 2015 13:38:44 -0700 (PDT) MIME-Version: 1.0 References: <842811b9f2ec4385b25bfdc02f6bdb09@XCH-ALN-005.cisco.com> <38A5475DE83986499AEACD2CFAFC3F98019ABF9CB2@tss-server1.home.tropicalstormsoftware.com> <1507b0f3e40.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: From: Justin Dean Date: Sun, 18 Oct 2015 20:38:34 +0000 Message-ID: To: Ulrich Herberg , Lou Berger Content-Type: multipart/alternative; boundary=001a113dec46cb070c0522670320 Archived-At: Cc: manet@ietf.org Subject: Re: [manet] DLEP Credit Windowing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 20:38:46 -0000 --001a113dec46cb070c0522670320 Content-Type: text/plain; charset=UTF-8 As it was a split and something that was discussed agreed upon at prague I have no issue with it starting as a WG draft. On Sun, Oct 18, 2015, 9:57 AM Ulrich Herberg wrote: > Understood. > > Thanks > Ulrich > > On Sun, Oct 18, 2015 at 6:06 AM, Lou Berger wrote: > > On October 17, 2015 12:51:32 PM Stan Ratliff > wrote: > > > >> Ulrich, > >> > >> The credit windowing draft was submitted as a WG document since this > was a > >> split of one WG doc (DLEP-16) into two. According to the guidance I had > at > >> the time, from Lou Berger, that's acceptable since credit windowing was > >> already "accepted" by the WG (it was accepted as part of the original > >> DLEP). > >> > > > > I believe my statement was along the lines of it being perfectly > reasonable > > to start a new document as a WG document when it is split from an > existing > > wg draft, and have seen this done before. > > > > Either way it's the chairs call... > > > > Lou > > > >> Stan > >> > >> > >> On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg > >> wrote: > >> > >>> Hi Rick, > >>> > >>> I thought the purpose of splitting off the credit window draft is to > >>> accelerate DLEP? But now there is a normative reference to it from > >>> DLEP, so there is really no gain at all. Also, it contradicts what > >>> Alvaro wrote in a previous email: > >>> > >>> > "BTW, you wrote above that the "base DLEP draft normatively > references > >>> Credit windowing as an example". An example shouldn't be normative." > >>> > >>> Also, the new draft was immediately posted as WG draft without asking > >>> the WG for consensus to adopt it first. I am not opposed to adopting > >>> it, but I think the process is a bit strange here. > >>> > >>> Regard > >>> Ulrich > >>> > >>> > >> > >> > >> > >> ---------- > >> _______________________________________________ > >> 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 > --001a113dec46cb070c0522670320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

As it was a split and something that was discussed agreed up= on at prague I have no issue with it starting as a WG draft.


On Sun, Oct 18, 2015, 9:57 = AM=C2=A0Ulrich Herberg <ulrich@he= rberg.name> wrote:
Understo= od.

Thanks
Ulrich

On Sun, Oct 18, 2015 at 6:06 AM, Lou Berger <lberger@labn.net> wrote:
> On October 17, 2015 12:51:32 PM Stan Ratliff <ratliffstan@gmail.com> wrote:<= br> >
>> Ulrich,
>>
>> The credit windowing draft was submitted as a WG document since th= is was a
>> split of one WG doc (DLEP-16) into two. According to the guidance = I had at
>> the time, from Lou Berger, that's acceptable since credit wind= owing was
>> already "accepted" by the WG (it was accepted as part of= the original
>> DLEP).
>>
>
> I believe my statement was along the lines of it being perfectly reaso= nable
> to start a new document as a WG document when=C2=A0 it is split from a= n existing
> wg draft, and have seen this done before.
>
> Either way it's the chairs call...
>
> Lou
>
>> Stan
>>
>>
>> On Sat, Oct 17, 2015 at 11:58 AM, Ulrich Herberg <ulrich@herberg.name>
>> wrote:
>>
>>> Hi Rick,
>>>
>>> I thought the purpose of splitting off the credit window draft= is to
>>> accelerate DLEP? But now there is a normative reference to it = from
>>> DLEP, so there is really no gain at all. Also, it contradicts = what
>>> Alvaro wrote in a previous email:
>>>
>>> > "BTW, you wrote above that the "base DLEP draft= normatively references
>>> Credit windowing as an example".=C2=A0 An example shouldn= 't be normative."
>>>
>>> Also, the new draft was immediately posted as WG draft without= asking
>>> the WG for consensus to adopt it first. I am not opposed to ad= opting
>>> it, but I think the process is a bit strange here.
>>>
>>> Regard
>>> Ulrich
>>>
>>>
>>
>>
>>
>> ----------
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org=
>> https://www.ietf.org/mailman/listinfo/manet<= br> >>

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
--001a113dec46cb070c0522670320-- From nobody Mon Oct 19 01:31:23 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AA51A854B for ; Mon, 19 Oct 2015 01:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8T9E5EFYQGc for ; Mon, 19 Oct 2015 01:31:19 -0700 (PDT) Received: from ukmta4.baesystems.com (ukmta4.baesystems.com [20.133.40.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA831A86FC for ; Mon, 19 Oct 2015 01:31:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.17,701,1437433200"; d="scan'208";a="12722202" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta4.baesystems.com with ESMTP; 19 Oct 2015 09:31:15 +0100 X-IronPort-AV: E=Sophos;i="5.17,701,1437433200"; d="scan'208";a="120246797" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 19 Oct 2015 09:31:15 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 09:31:15 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , "manet@ietf.org" Thread-Topic: DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBwBm9nRwAGEtIrA= Date: Mon, 19 Oct 2015 08:31:14 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:31:21 -0000 I take the point about radio being imperfect, but I think it's significantl= y less imperfect than modem. I can't think of anything better myself. --=20 Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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: Rick Taylor [mailto:rick@tropicalstormsoftware.com]=20 Sent: 17 October 2015 11:16 To: Dearlove, Christopher (UK); manet@ietf.org Subject: RE: DLEP ----------------------! 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. -------------------------------------------------------- Thanks for the quick review Chris, As far as the whole 'modem' versus 'radio' wording is concerned: I share yo= ur slight discomfort with the word 'modem', but I'm not sure 'radio' is any= better! For example, I have some scruffy code which pretends to be a DLEP= modem for DMVPN tunnels, and there's definitely no radio involved. I'm definitely willing to listen to suggestions from the WG for words to re= place 'modem' with a word to mean 'a device that forwards layer-2 packets t= o its peers, has link sensing, and is commonly some kind of radio'. Whethe= r we make the change depends entirely on whether the WG has the patience. ;= ) I believe (I haven't got draft-17 open in front of me) that we have tackled= some of your issues with the RFC 5226 terminology in 17 as well, using 'Pr= ivate Use' instead of 'Reserved' when appropriate. Cheers, Rick -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, Christop= her (UK) Sent: 15 October 2015 10:22 To: manet@ietf.org Subject: [manet] DLEP I've read DLEP draft 16, but not so far with a critical eye to specific rev= iew comments - other than that the IANA section isn't what's needed (but th= e authors already know that and I understand have already written a replace= ment) and a few editorial comments I'll make below. In particular I haven't= formed a view on the security considerations section - but I may wait for = this and most other points to see -17 which I understand is mostly written. My minor points: - I really would prefer "radio" to "modem" throughout. As someone who once = wrote some modem software, for me modem is what it says, modulation and dem= odulation (and the inseparable channel coding), i.e. converting between bit= streams and modulated signals (for a digital radio).There are many parts o= f a radio that are outside that, and everything DLEP is outside the modem. - Where there are various time and other values (timeouts, repeat periods, = number of retries) I'd use a symbolic name and collect suggested default va= lues in one place. That is after all, as we all write software. - Currently describes some code points as "Reserved for future extensions".= This is not the correct terminology. From RFC 5226: Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment. (The Reserved for 0 and 65535 is however presumably correct.) As I know the IANA considerations section is done, this may already have= been caught, but I'll say it in case not. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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 7Y= P ******************************************************************** This email and any attachments are confidential to the intended recipient a= nd may also be privileged. If you are not the intended recipient please del= ete 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 Mon Oct 19 01:33:54 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219451A70FE for ; Mon, 19 Oct 2015 01:33:53 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZasQ1xRShwf for ; Mon, 19 Oct 2015 01:33:52 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 E517E1A7028 for ; Mon, 19 Oct 2015 01:33:51 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so39163878wic.1 for ; Mon, 19 Oct 2015 01:33: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-type; bh=YUOMlm6uLPD8KKvGsZE8Vfxazr4FTlf0BElbakIdnZo=; b=nkwlrzjz1JnClR5zFy0474/IHfOefMg+vcri/Lyx3byv4vsW/Yr6EbTN+bQJPAqtS8 RzsMlA/0mVixiJXXonpjpYVNrOhTh+No9LofaUL5jncjWC7jFiojuKXHmaheO808zNxt P5XzJsV8qTfxpq7CH43xP4S0W3Z9lsJraeZF95yhuUe3CCak1w+2czPXnLwHsCJD20Hh YHTBZRKN9qhw107zNLOjQayPn963XvhW2rg5w62t83q8SSpBEiggwzLiMMEvspmkwD74 JKAqSXNcoXwqNDs05drVwyyoYdi9sFc6RFR6Il1lmbO6iqMh9V2jZyw43BXqFnmgYt03 wj8w== X-Received: by 10.180.9.74 with SMTP id x10mr18319515wia.61.1445243630531; Mon, 19 Oct 2015 01:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.178.95 with HTTP; Mon, 19 Oct 2015 01:33:21 -0700 (PDT) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 19 Oct 2015 10:33:21 +0200 Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 08:33:53 -0000 On Mon, Oct 19, 2015 at 10:31 AM, Dearlove, Christopher (UK) wrote: > I take the point about radio being imperfect, but I think it's significantly less imperfect than modem. > > I can't think of anything better myself. I would also prefer radio, but whatever we use it might be a good idea to mention in the draft that the other name could also be used. Henning Rogge From nobody Mon Oct 19 02:10:59 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4848B1A8750 for ; Mon, 19 Oct 2015 02:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDkB8vrW7buZ for ; Mon, 19 Oct 2015 02:10:56 -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 CFE6C1A8737 for ; Mon, 19 Oct 2015 02:10:55 -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; Mon, 19 Oct 2015 10:10:29 +0100 From: Rick Taylor To: Henning Rogge , "Dearlove, Christopher (UK)" Thread-Topic: [manet] DLEP Thread-Index: AQHRCkjhRsjN0g+lNUyjpRi43/6osA== Date: Mon, 19 Oct 2015 09:10:27 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98019ABFA006@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 09:10:57 -0000 On 19/10/15 09:33, Henning Rogge wrote:=0A= > On Mon, Oct 19, 2015 at 10:31 AM, Dearlove, Christopher (UK)=0A= > wrote:=0A= >> I take the point about radio being imperfect, but I think it's significa= ntly less imperfect than modem.=0A= >>=0A= >> I can't think of anything better myself.=0A= >=0A= > I would also prefer radio, but whatever we use it might be a good idea=0A= > to mention in the draft that the other name could also be used.=0A= =0A= This might be something for the assumptions section. Something along =0A= the lines of "We use the word 'modem', but it can actually be something =0A= much more general..."=0A= =0A= Rick=0A= =0A= From nobody Mon Oct 19 06:28:56 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57621A1AE1 for ; Mon, 19 Oct 2015 06:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo6T2zOuLRgp for ; Mon, 19 Oct 2015 06:28:52 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 808621A1AD3 for ; Mon, 19 Oct 2015 06:28:51 -0700 (PDT) Received: by lbbes7 with SMTP id es7so54263003lbb.2 for ; Mon, 19 Oct 2015 06:28: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:content-type; bh=LkxGx0Nt40ejO3NrVXNlaCAksHWLA0TPiE4cWihxVBI=; b=PA5+ibZTCrS/6maPgSn7KgKCzq5mSIT1rAmzWOqhgyvUwHoF/EzhuA1kS/Iatyzqlx vvb/4mDFit8ng8j4h0K5k8XUKHAj26JgPhWgyq7pYOnnCvkMyGqB1e/oifF2LZqZgolH 6cHhARx0XUfvRKKqgjMm4gbaoFZySCGMfJ/EV9ZVC0F8vcX91qQGgz0DzKGWUTgjuaGb RbSggUW7N7bIumGPJNQsSYK6EETFGxib3fcyK1C9A4hf3S7tfan3BrSiLofVfo4gSqGm UjIg1Tf5WG3m+1XeuC0whm2Lm80aoRVxzmW5ZuARMejr70SL6XQO944jGj68S8gQ9E0j O4PA== MIME-Version: 1.0 X-Received: by 10.112.132.7 with SMTP id oq7mr15019520lbb.32.1445261329585; Mon, 19 Oct 2015 06:28:49 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Mon, 19 Oct 2015 06:28:49 -0700 (PDT) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> Date: Mon, 19 Oct 2015 09:28:49 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b3a81a2285b59052275203a Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:28:54 -0000 --047d7b3a81a2285b59052275203a Content-Type: text/plain; charset=UTF-8 All, I think Rick hit the nail on the head. We initially used the term "radio", but changed it when we realized that DLEP *could* (but doesn't have to) be used in devices like cable modems. "Router" is also a far from perfect term - I'm currently working on an implementation where the "router" code actually lives in an iDirect-specific application having nothing to do with routing. Regards, Stan On Mon, Oct 19, 2015 at 4:31 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I take the point about radio being imperfect, but I think it's > significantly less imperfect than modem. > > I can't think of anything better myself. > > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > __________________________________________________________________________ > > 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: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: 17 October 2015 11:16 > To: Dearlove, Christopher (UK); manet@ietf.org > Subject: RE: DLEP > > ----------------------! 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. > -------------------------------------------------------- > > Thanks for the quick review Chris, > > As far as the whole 'modem' versus 'radio' wording is concerned: I share > your slight discomfort with the word 'modem', but I'm not sure 'radio' is > any better! For example, I have some scruffy code which pretends to be a > DLEP modem for DMVPN tunnels, and there's definitely no radio involved. > > I'm definitely willing to listen to suggestions from the WG for words to > replace 'modem' with a word to mean 'a device that forwards layer-2 packets > to its peers, has link sensing, and is commonly some kind of radio'. > Whether we make the change depends entirely on whether the WG has the > patience. ;) > > I believe (I haven't got draft-17 open in front of me) that we have > tackled some of your issues with the RFC 5226 terminology in 17 as well, > using 'Private Use' instead of 'Reserved' when appropriate. > > Cheers, > Rick > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, > Christopher (UK) > Sent: 15 October 2015 10:22 > To: manet@ietf.org > Subject: [manet] DLEP > > I've read DLEP draft 16, but not so far with a critical eye to specific > review comments - other than that the IANA section isn't what's needed (but > the authors already know that and I understand have already written a > replacement) and a few editorial comments I'll make below. In particular I > haven't formed a view on the security considerations section - but I may > wait for this and most other points to see -17 which I understand is mostly > written. > > My minor points: > > - I really would prefer "radio" to "modem" throughout. As someone who once > wrote some modem software, for me modem is what it says, modulation and > demodulation (and the inseparable channel coding), i.e. converting between > bit streams and modulated signals (for a digital radio).There are many > parts of a radio that are outside that, and everything DLEP is outside the > modem. > > - Where there are various time and other values (timeouts, repeat periods, > number of retries) I'd use a symbolic name and collect suggested default > values in one place. That is after all, as we all write software. > > - Currently describes some code points as "Reserved for future > extensions". This is not the correct terminology. From RFC 5226: > > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it become > exhausted. Reserved values are not available for general > assignment. > > (The Reserved for 0 and 65535 is however presumably correct.) > > As I know the IANA considerations section is done, this may already > have been caught, but I'll say it in case not. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > __________________________________________________________________________ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited Registered in England & Wales No: > 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > ******************************************************************** > This email and any attachments are confidential to the intended recipient > and may also be privileged. If you are not the intended recipient please > delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7b3a81a2285b59052275203a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

I think Rick hit the nail on= the head. We initially used the term "radio", but changed it whe= n we realized that DLEP *could* (but doesn't have to) be used in device= s like cable modems. "Router" is also a far from perfect term - I= 'm currently working on an implementation where the "router" = code actually lives in an iDirect-specific application having nothing to do= with routing.=C2=A0

Regards,
Stan

On = Mon, Oct 19, 2015 at 4:31 AM, Dearlove, Christopher (UK) = <chri= s.dearlove@baesystems.com> wrote:
I take the point about radio being imperfect, but I think it's s= ignificantly less imperfect than modem.

I can't think of anything better myself.


--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= 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: Rick Taylor [mailto:rick@tropicalstormsoftware.com]
Sent: 17 October 2015 11:16
To: Dearlove, Christopher (UK); manet@iet= f.org
Subject: RE: DLEP

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

Thanks for the quick review Chris,

As far as the whole 'modem' versus 'radio' wording is conce= rned: I share your slight discomfort with the word 'modem', but I&#= 39;m not sure 'radio' is any better!=C2=A0 For example, I have some= scruffy code which pretends to be a DLEP modem for DMVPN tunnels, and ther= e's definitely no radio involved.

I'm definitely willing to listen to suggestions from the WG for words t= o replace 'modem' with a word to mean 'a device that forwards l= ayer-2 packets to its peers, has link sensing, and is commonly some kind of= radio'.=C2=A0 Whether we make the change depends entirely on whether t= he WG has the patience. ;)

I believe (I haven't got draft-17 open in front of me) that we have tac= kled some of your issues with the RFC 5226 terminology in 17 as well, using= 'Private Use' instead of 'Reserved' when appropriate.

Cheers,
Rick

-----Original Message-----
From: manet [mailto:manet-bounces= @ietf.org] On Behalf Of Dearlove, Christopher (UK)
Sent: 15 October 2015 10:22
To: manet@ietf.org
Subject: [manet] DLEP

I've read DLEP draft 16, but not so far with a critical eye to specific= review comments - other than that the IANA section isn't what's ne= eded (but the authors already know that and I understand have already writt= en a replacement) and a few editorial comments I'll make below. In part= icular I haven't formed a view on the security considerations section -= but I may wait for this and most other points to see -17 which I understan= d is mostly written.

My minor points:

- I really would prefer "radio" to "modem" throughout. = As someone who once wrote some modem software, for me modem is what it says= , modulation and demodulation (and the inseparable channel coding), i.e. co= nverting between bit streams and modulated signals (for a digital radio).Th= ere are many parts of a radio that are outside that, and everything DLEP is= outside the modem.

- Where there are various time and other values (timeouts, repeat periods, = number of retries) I'd use a symbolic name and collect suggested defaul= t values in one place. That is after all, as we all write software.

- Currently describes some code points as "Reserved for future extensi= ons". This is not the correct terminology. From RFC 5226:

=C2=A0 =C2=A0 =C2=A0 Reserved:=C2=A0 Not to be assigned.=C2=A0 Reserved val= ues are held for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 special uses, such as to extend t= he namespace when it become
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 exhausted.=C2=A0 Reserved values = are not available for general
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 assignment.

=C2=A0 =C2=A0 (The Reserved for 0 and 65535 is however presumably correct.)=

=C2=A0 =C2=A0As I know the IANA considerations section is done, this may al= ready have been caught, but I'll say it in case not.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= 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, GU= 2 7YP



********************************************************************
This email and any attachments are confidential to the intended recipient a= nd may also be privileged. If you are not the intended recipient please del= ete 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

--047d7b3a81a2285b59052275203a-- From nobody Mon Oct 19 06:54:30 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B511A6ED9 for ; Mon, 19 Oct 2015 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1YQdu1KfchT for ; Mon, 19 Oct 2015 06:54:25 -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 8782A1A1A3D for ; Mon, 19 Oct 2015 06:54:24 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,702,1437433200"; d="scan'208,217"; a="14851822" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 19 Oct 2015 14:54:22 +0100 X-IronPort-AV: E=Sophos;i="5.17,702,1437433200"; d="scan'208,217";a="116853880" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 19 Oct 2015 14:54:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 14:54:22 +0100 From: "Dearlove, Christopher (UK)" To: Stan Ratliff Thread-Topic: [manet] DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBwBm9nRwAGEtIrAACGKTgAAC9zKA Date: Mon, 19 Oct 2015 13:54:21 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:54:28 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgc3VnZ2VzdCBhIHN0cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZvciByYWRpbyBvdmVyIG1v ZGVtLCB0aG91Z2ggb3BlbiB0byBhIGJldHRlciBzdWdnZXN0aW9uLg0KDQotLQ0KQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQy MTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBF c3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVt cy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNl OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpG cm9tOiBTdGFuIFJhdGxpZmYgW21haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21dDQpTZW50OiAx OSBPY3RvYmVyIDIwMTUgMTQ6MjkNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6 IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gRExFUA0K DQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl IGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFp bHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu cGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93 IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmPi4NCkFsbCwNCg0KSSB0aGluayBSaWNrIGhpdCB0aGUgbmFpbCBvbiB0 aGUgaGVhZC4gV2UgaW5pdGlhbGx5IHVzZWQgdGhlIHRlcm0gInJhZGlvIiwgYnV0IGNoYW5nZWQg aXQgd2hlbiB3ZSByZWFsaXplZCB0aGF0IERMRVAgKmNvdWxkKiAoYnV0IGRvZXNuJ3QgaGF2ZSB0 bykgYmUgdXNlZCBpbiBkZXZpY2VzIGxpa2UgY2FibGUgbW9kZW1zLiAiUm91dGVyIiBpcyBhbHNv IGEgZmFyIGZyb20gcGVyZmVjdCB0ZXJtIC0gSSdtIGN1cnJlbnRseSB3b3JraW5nIG9uIGFuIGlt cGxlbWVudGF0aW9uIHdoZXJlIHRoZSAicm91dGVyIiBjb2RlIGFjdHVhbGx5IGxpdmVzIGluIGFu IGlEaXJlY3Qtc3BlY2lmaWMgYXBwbGljYXRpb24gaGF2aW5nIG5vdGhpbmcgdG8gZG8gd2l0aCBy b3V0aW5nLg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCk9uIE1vbiwgT2N0IDE5LCAyMDE1IGF0IDQ6 MzEgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkkg dGFrZSB0aGUgcG9pbnQgYWJvdXQgcmFkaW8gYmVpbmcgaW1wZXJmZWN0LCBidXQgSSB0aGluayBp dCdzIHNpZ25pZmljYW50bHkgbGVzcyBpbXBlcmZlY3QgdGhhbiBtb2RlbS4NCg0KSSBjYW4ndCB0 aGluayBvZiBhbnl0aGluZyBiZXR0ZXIgbXlzZWxmLg0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFy bG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVs OiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMu Y29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzog MDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm b3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUmljayBUYXlsb3IgW21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb208bWFp bHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbT5dDQpTZW50OiAxNyBPY3RvYmVyIDIw MTUgMTE6MTYNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KU3ViamVjdDogUkU6IERMRVANCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdl IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFu IGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxp bmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3Vz IGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmV2aWV3IENocmlzLA0K DQpBcyBmYXIgYXMgdGhlIHdob2xlICdtb2RlbScgdmVyc3VzICdyYWRpbycgd29yZGluZyBpcyBj b25jZXJuZWQ6IEkgc2hhcmUgeW91ciBzbGlnaHQgZGlzY29tZm9ydCB3aXRoIHRoZSB3b3JkICdt b2RlbScsIGJ1dCBJJ20gbm90IHN1cmUgJ3JhZGlvJyBpcyBhbnkgYmV0dGVyISAgRm9yIGV4YW1w bGUsIEkgaGF2ZSBzb21lIHNjcnVmZnkgY29kZSB3aGljaCBwcmV0ZW5kcyB0byBiZSBhIERMRVAg bW9kZW0gZm9yIERNVlBOIHR1bm5lbHMsIGFuZCB0aGVyZSdzIGRlZmluaXRlbHkgbm8gcmFkaW8g aW52b2x2ZWQuDQoNCkknbSBkZWZpbml0ZWx5IHdpbGxpbmcgdG8gbGlzdGVuIHRvIHN1Z2dlc3Rp b25zIGZyb20gdGhlIFdHIGZvciB3b3JkcyB0byByZXBsYWNlICdtb2RlbScgd2l0aCBhIHdvcmQg dG8gbWVhbiAnYSBkZXZpY2UgdGhhdCBmb3J3YXJkcyBsYXllci0yIHBhY2tldHMgdG8gaXRzIHBl ZXJzLCBoYXMgbGluayBzZW5zaW5nLCBhbmQgaXMgY29tbW9ubHkgc29tZSBraW5kIG9mIHJhZGlv Jy4gIFdoZXRoZXIgd2UgbWFrZSB0aGUgY2hhbmdlIGRlcGVuZHMgZW50aXJlbHkgb24gd2hldGhl ciB0aGUgV0cgaGFzIHRoZSBwYXRpZW5jZS4gOykNCg0KSSBiZWxpZXZlIChJIGhhdmVuJ3QgZ290 IGRyYWZ0LTE3IG9wZW4gaW4gZnJvbnQgb2YgbWUpIHRoYXQgd2UgaGF2ZSB0YWNrbGVkIHNvbWUg b2YgeW91ciBpc3N1ZXMgd2l0aCB0aGUgUkZDIDUyMjYgdGVybWlub2xvZ3kgaW4gMTcgYXMgd2Vs bCwgdXNpbmcgJ1ByaXZhdGUgVXNlJyBpbnN0ZWFkIG9mICdSZXNlcnZlZCcgd2hlbiBhcHByb3By aWF0ZS4NCg0KQ2hlZXJzLA0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpT ZW50OiAxNSBPY3RvYmVyIDIwMTUgMTA6MjINClRvOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFu ZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFuZXRdIERMRVANCg0KSSd2ZSByZWFkIERMRVAgZHJh ZnQgMTYsIGJ1dCBub3Qgc28gZmFyIHdpdGggYSBjcml0aWNhbCBleWUgdG8gc3BlY2lmaWMgcmV2 aWV3IGNvbW1lbnRzIC0gb3RoZXIgdGhhbiB0aGF0IHRoZSBJQU5BIHNlY3Rpb24gaXNuJ3Qgd2hh dCdzIG5lZWRlZCAoYnV0IHRoZSBhdXRob3JzIGFscmVhZHkga25vdyB0aGF0IGFuZCBJIHVuZGVy c3RhbmQgaGF2ZSBhbHJlYWR5IHdyaXR0ZW4gYSByZXBsYWNlbWVudCkgYW5kIGEgZmV3IGVkaXRv cmlhbCBjb21tZW50cyBJJ2xsIG1ha2UgYmVsb3cuIEluIHBhcnRpY3VsYXIgSSBoYXZlbid0IGZv cm1lZCBhIHZpZXcgb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gLSBidXQg SSBtYXkgd2FpdCBmb3IgdGhpcyBhbmQgbW9zdCBvdGhlciBwb2ludHMgdG8gc2VlIC0xNyB3aGlj aCBJIHVuZGVyc3RhbmQgaXMgbW9zdGx5IHdyaXR0ZW4uDQoNCk15IG1pbm9yIHBvaW50czoNCg0K LSBJIHJlYWxseSB3b3VsZCBwcmVmZXIgInJhZGlvIiB0byAibW9kZW0iIHRocm91Z2hvdXQuIEFz IHNvbWVvbmUgd2hvIG9uY2Ugd3JvdGUgc29tZSBtb2RlbSBzb2Z0d2FyZSwgZm9yIG1lIG1vZGVt IGlzIHdoYXQgaXQgc2F5cywgbW9kdWxhdGlvbiBhbmQgZGVtb2R1bGF0aW9uIChhbmQgdGhlIGlu c2VwYXJhYmxlIGNoYW5uZWwgY29kaW5nKSwgaS5lLiBjb252ZXJ0aW5nIGJldHdlZW4gYml0IHN0 cmVhbXMgYW5kIG1vZHVsYXRlZCBzaWduYWxzIChmb3IgYSBkaWdpdGFsIHJhZGlvKS5UaGVyZSBh cmUgbWFueSBwYXJ0cyBvZiBhIHJhZGlvIHRoYXQgYXJlIG91dHNpZGUgdGhhdCwgYW5kIGV2ZXJ5 dGhpbmcgRExFUCBpcyBvdXRzaWRlIHRoZSBtb2RlbS4NCg0KLSBXaGVyZSB0aGVyZSBhcmUgdmFy aW91cyB0aW1lIGFuZCBvdGhlciB2YWx1ZXMgKHRpbWVvdXRzLCByZXBlYXQgcGVyaW9kcywgbnVt YmVyIG9mIHJldHJpZXMpIEknZCB1c2UgYSBzeW1ib2xpYyBuYW1lIGFuZCBjb2xsZWN0IHN1Z2dl c3RlZCBkZWZhdWx0IHZhbHVlcyBpbiBvbmUgcGxhY2UuIFRoYXQgaXMgYWZ0ZXIgYWxsLCBhcyB3 ZSBhbGwgd3JpdGUgc29mdHdhcmUuDQoNCi0gQ3VycmVudGx5IGRlc2NyaWJlcyBzb21lIGNvZGUg cG9pbnRzIGFzICJSZXNlcnZlZCBmb3IgZnV0dXJlIGV4dGVuc2lvbnMiLiBUaGlzIGlzIG5vdCB0 aGUgY29ycmVjdCB0ZXJtaW5vbG9neS4gRnJvbSBSRkMgNTIyNjoNCg0KICAgICAgUmVzZXJ2ZWQ6 ICBOb3QgdG8gYmUgYXNzaWduZWQuICBSZXNlcnZlZCB2YWx1ZXMgYXJlIGhlbGQgZm9yDQogICAg ICAgICAgICBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMgdG8gZXh0ZW5kIHRoZSBuYW1lc3BhY2Ugd2hl biBpdCBiZWNvbWUNCiAgICAgICAgICAgIGV4aGF1c3RlZC4gIFJlc2VydmVkIHZhbHVlcyBhcmUg bm90IGF2YWlsYWJsZSBmb3IgZ2VuZXJhbA0KICAgICAgICAgICAgYXNzaWdubWVudC4NCg0KICAg IChUaGUgUmVzZXJ2ZWQgZm9yIDAgYW5kIDY1NTM1IGlzIGhvd2V2ZXIgcHJlc3VtYWJseSBjb3Jy ZWN0LikNCg0KICAgQXMgSSBrbm93IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMg ZG9uZSwgdGhpcyBtYXkgYWxyZWFkeSBoYXZlIGJlZW4gY2F1Z2h0LCBidXQgSSdsbCBzYXkgaXQg aW4gY2FzZSBub3QuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUl MjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFl c3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MSBSZWdpc3RlcmVkIE9m ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoN Cg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBwbGVhc2UgZGVsZXRl IGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBu b3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvciBkaXN0 cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5l dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595GLKXM0002VGREEN_ 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 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+SeKAmWQgc3VnZ2VzdCBhIHN0cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZv ciByYWRpbyBvdmVyIG1vZGVtLCB0aG91Z2ggb3BlbiB0byBhIGJldHRlciBzdWdnZXN0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0 b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2U8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQg KDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9iPjxhIGhyZWY9Im1haWx0bzpj aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdF Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFy aywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4Qjky O3RleHQtZGVjb3JhdGlvbjpub25lIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5j ZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMz NzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThC OTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBT dXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3RhbiBSYXRsaWZmIFttYWlsdG86 cmF0bGlmZnN0YW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE5IE9jdG9iZXIgMjAx NSAxNDoyOTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8 Yj5DYzo8L2I+IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW21hbmV0XSBETEVQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxh Y2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUiPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhp cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Db25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVt PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFu PjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQg RmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPiB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVj ZWl2ZSwNCiBjbGljayA8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29t L2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYi Pg0KaGVyZTwvYT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBz dXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50cmFuZXQuZW50LmJh ZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFs aW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4u PC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBSaWNrIGhpdCB0aGUgbmFpbCBvbiB0aGUgaGVhZC4g V2UgaW5pdGlhbGx5IHVzZWQgdGhlIHRlcm0gJnF1b3Q7cmFkaW8mcXVvdDssIGJ1dCBjaGFuZ2Vk IGl0IHdoZW4gd2UgcmVhbGl6ZWQgdGhhdCBETEVQICpjb3VsZCogKGJ1dCBkb2Vzbid0IGhhdmUg dG8pIGJlIHVzZWQgaW4gZGV2aWNlcyBsaWtlIGNhYmxlIG1vZGVtcy4gJnF1b3Q7Um91dGVyJnF1 b3Q7IGlzIGFsc28gYSBmYXIgZnJvbSBwZXJmZWN0IHRlcm0gLSBJJ20gY3VycmVudGx5DQogd29y a2luZyBvbiBhbiBpbXBsZW1lbnRhdGlvbiB3aGVyZSB0aGUgJnF1b3Q7cm91dGVyJnF1b3Q7IGNv ZGUgYWN0dWFsbHkgbGl2ZXMgaW4gYW4gaURpcmVjdC1zcGVjaWZpYyBhcHBsaWNhdGlvbiBoYXZp bmcgbm90aGluZyB0byBkbyB3aXRoIHJvdXRpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPGJyPg0KU3RhbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgT2N0IDE5LCAyMDE1IGF0IDQ6MzEgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspICZs dDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0i X2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0YWtlIHRoZSBwb2ludCBhYm91dCBy YWRpbyBiZWluZyBpbXBlcmZlY3QsIGJ1dCBJIHRoaW5rIGl0J3Mgc2lnbmlmaWNhbnRseSBsZXNz IGltcGVyZmVjdCB0aGFuIG1vZGVtLjxicj4NCjxicj4NCkkgY2FuJ3QgdGhpbmsgb2YgYW55dGhp bmcgYmV0dGVyIG15c2VsZi48YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCkNocmlzdG9waGVyIERl YXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpUOiAm bmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5NCI+JiM0Mzs0NCAo MCkxMjQ1IDI0MjE5NDwvYT4gJm5ic3A7fCAmbmJzcDtFOiA8YSBocmVmPSJtYWlsdG86Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPg0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208 L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJf YmxhbmsiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvYT48YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdh bGVzIE5vOiAwMTMzNzQ1MTxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFJpY2sgVGF5bG9yIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbSI+cmlja0B0cm9waWNhbHN0 b3Jtc29mdHdhcmUuY29tPC9hPl08YnI+DQpTZW50OiAxNyBPY3RvYmVyIDIwMTUgMTE6MTY8YnI+ DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IDxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUkU6IERMRVA8YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC48 YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBs aW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9sbG93IHRoZSAnUmVw b3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9u cyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4N ClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJldmlldyBDaHJpcyw8YnI+DQo8YnI+DQpBcyBmYXIgYXMg dGhlIHdob2xlICdtb2RlbScgdmVyc3VzICdyYWRpbycgd29yZGluZyBpcyBjb25jZXJuZWQ6IEkg c2hhcmUgeW91ciBzbGlnaHQgZGlzY29tZm9ydCB3aXRoIHRoZSB3b3JkICdtb2RlbScsIGJ1dCBJ J20gbm90IHN1cmUgJ3JhZGlvJyBpcyBhbnkgYmV0dGVyISZuYnNwOyBGb3IgZXhhbXBsZSwgSSBo YXZlIHNvbWUgc2NydWZmeSBjb2RlIHdoaWNoIHByZXRlbmRzIHRvIGJlIGEgRExFUCBtb2RlbSBm b3IgRE1WUE4gdHVubmVscywgYW5kIHRoZXJlJ3MNCiBkZWZpbml0ZWx5IG5vIHJhZGlvIGludm9s dmVkLjxicj4NCjxicj4NCkknbSBkZWZpbml0ZWx5IHdpbGxpbmcgdG8gbGlzdGVuIHRvIHN1Z2dl c3Rpb25zIGZyb20gdGhlIFdHIGZvciB3b3JkcyB0byByZXBsYWNlICdtb2RlbScgd2l0aCBhIHdv cmQgdG8gbWVhbiAnYSBkZXZpY2UgdGhhdCBmb3J3YXJkcyBsYXllci0yIHBhY2tldHMgdG8gaXRz IHBlZXJzLCBoYXMgbGluayBzZW5zaW5nLCBhbmQgaXMgY29tbW9ubHkgc29tZSBraW5kIG9mIHJh ZGlvJy4mbmJzcDsgV2hldGhlciB3ZSBtYWtlIHRoZSBjaGFuZ2UgZGVwZW5kcyBlbnRpcmVseQ0K IG9uIHdoZXRoZXIgdGhlIFdHIGhhcyB0aGUgcGF0aWVuY2UuIDspPGJyPg0KPGJyPg0KSSBiZWxp ZXZlIChJIGhhdmVuJ3QgZ290IGRyYWZ0LTE3IG9wZW4gaW4gZnJvbnQgb2YgbWUpIHRoYXQgd2Ug aGF2ZSB0YWNrbGVkIHNvbWUgb2YgeW91ciBpc3N1ZXMgd2l0aCB0aGUgUkZDIDUyMjYgdGVybWlu b2xvZ3kgaW4gMTcgYXMgd2VsbCwgdXNpbmcgJ1ByaXZhdGUgVXNlJyBpbnN0ZWFkIG9mICdSZXNl cnZlZCcgd2hlbiBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KUmljazxicj4N Cjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbWFuZXQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyI+bWFuZXQtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4N ClNlbnQ6IDE1IE9jdG9iZXIgMjAxNSAxMDoyMjxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86bWFu ZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFttYW5ldF0gRExF UDxicj4NCjxicj4NCkkndmUgcmVhZCBETEVQIGRyYWZ0IDE2LCBidXQgbm90IHNvIGZhciB3aXRo IGEgY3JpdGljYWwgZXllIHRvIHNwZWNpZmljIHJldmlldyBjb21tZW50cyAtIG90aGVyIHRoYW4g dGhhdCB0aGUgSUFOQSBzZWN0aW9uIGlzbid0IHdoYXQncyBuZWVkZWQgKGJ1dCB0aGUgYXV0aG9y cyBhbHJlYWR5IGtub3cgdGhhdCBhbmQgSSB1bmRlcnN0YW5kIGhhdmUgYWxyZWFkeSB3cml0dGVu IGEgcmVwbGFjZW1lbnQpIGFuZCBhIGZldyBlZGl0b3JpYWwgY29tbWVudHMNCiBJJ2xsIG1ha2Ug YmVsb3cuIEluIHBhcnRpY3VsYXIgSSBoYXZlbid0IGZvcm1lZCBhIHZpZXcgb24gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gLSBidXQgSSBtYXkgd2FpdCBmb3IgdGhpcyBhbmQg bW9zdCBvdGhlciBwb2ludHMgdG8gc2VlIC0xNyB3aGljaCBJIHVuZGVyc3RhbmQgaXMgbW9zdGx5 IHdyaXR0ZW4uPGJyPg0KPGJyPg0KTXkgbWlub3IgcG9pbnRzOjxicj4NCjxicj4NCi0gSSByZWFs bHkgd291bGQgcHJlZmVyICZxdW90O3JhZGlvJnF1b3Q7IHRvICZxdW90O21vZGVtJnF1b3Q7IHRo cm91Z2hvdXQuIEFzIHNvbWVvbmUgd2hvIG9uY2Ugd3JvdGUgc29tZSBtb2RlbSBzb2Z0d2FyZSwg Zm9yIG1lIG1vZGVtIGlzIHdoYXQgaXQgc2F5cywgbW9kdWxhdGlvbiBhbmQgZGVtb2R1bGF0aW9u IChhbmQgdGhlIGluc2VwYXJhYmxlIGNoYW5uZWwgY29kaW5nKSwgaS5lLiBjb252ZXJ0aW5nIGJl dHdlZW4gYml0IHN0cmVhbXMgYW5kIG1vZHVsYXRlZCBzaWduYWxzIChmb3INCiBhIGRpZ2l0YWwg cmFkaW8pLlRoZXJlIGFyZSBtYW55IHBhcnRzIG9mIGEgcmFkaW8gdGhhdCBhcmUgb3V0c2lkZSB0 aGF0LCBhbmQgZXZlcnl0aGluZyBETEVQIGlzIG91dHNpZGUgdGhlIG1vZGVtLjxicj4NCjxicj4N Ci0gV2hlcmUgdGhlcmUgYXJlIHZhcmlvdXMgdGltZSBhbmQgb3RoZXIgdmFsdWVzICh0aW1lb3V0 cywgcmVwZWF0IHBlcmlvZHMsIG51bWJlciBvZiByZXRyaWVzKSBJJ2QgdXNlIGEgc3ltYm9saWMg bmFtZSBhbmQgY29sbGVjdCBzdWdnZXN0ZWQgZGVmYXVsdCB2YWx1ZXMgaW4gb25lIHBsYWNlLiBU aGF0IGlzIGFmdGVyIGFsbCwgYXMgd2UgYWxsIHdyaXRlIHNvZnR3YXJlLjxicj4NCjxicj4NCi0g Q3VycmVudGx5IGRlc2NyaWJlcyBzb21lIGNvZGUgcG9pbnRzIGFzICZxdW90O1Jlc2VydmVkIGZv ciBmdXR1cmUgZXh0ZW5zaW9ucyZxdW90Oy4gVGhpcyBpcyBub3QgdGhlIGNvcnJlY3QgdGVybWlu b2xvZ3kuIEZyb20gUkZDIDUyMjY6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgUmVz ZXJ2ZWQ6Jm5ic3A7IE5vdCB0byBiZSBhc3NpZ25lZC4mbmJzcDsgUmVzZXJ2ZWQgdmFsdWVzIGFy ZSBoZWxkIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHNwZWNpYWwgdXNlcywgc3VjaCBhcyB0byBleHRlbmQgdGhlIG5hbWVzcGFjZSB3aGVuIGl0IGJl Y29tZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGV4aGF1 c3RlZC4mbmJzcDsgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBub3QgYXZhaWxhYmxlIGZvciBnZW5lcmFs PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXNzaWdubWVu dC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IChUaGUgUmVzZXJ2ZWQgZm9yIDAgYW5kIDY1NTM1 IGlzIGhvd2V2ZXIgcHJlc3VtYWJseSBjb3JyZWN0Lik8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 QXMgSSBrbm93IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgZG9uZSwgdGhpcyBt YXkgYWxyZWFkeSBoYXZlIGJlZW4gY2F1Z2h0LCBidXQgSSdsbCBzYXkgaXQgaW4gY2FzZSBub3Qu PGJyPg0KPGJyPg0KLS08YnI+DQpDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmlu Y2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0 JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNw O3wgJm5ic3A7RTogPGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t Ij4NCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4NCkJBRSBTeXN0 ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3Jl YXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFlc3lzdGVtcy5j b20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZCBS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxIFJlZ2lzdGVyZWQg T2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl IHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8 L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595GLKXM0002VGREEN_-- From nobody Mon Oct 19 06:59:15 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0161A6F63 for ; Mon, 19 Oct 2015 06:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCSF9xZa6fdJ for ; Mon, 19 Oct 2015 06:59:08 -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 244701A6F92 for ; Mon, 19 Oct 2015 06:59:08 -0700 (PDT) IronPort-PHdr: 9a23:t51syBA5r/5rGRZTZ1afUyQJP3N1i/DPJgcQr6AfoPdwSP//osbcNUDSrc9gkEXOFd2CrakU16yH7eu/AyQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTrkbHssMKJKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ6jiR6WByeC72EYVXsb1lJjAxLE9w39Rpf8qGO6i8k8kmHONs3sTKtyVTmr9aNsVhLAgi4KLC8i7GzSkYp7i6cN5FqauxV5i7TdfIWUOvQ2KrnUYdcbS2RaQs9XfyNEC4K4KYAICrxSE/xfqty3nVISqRqwC03kP//mzDtFlzW+ibYg2vglEA/I9A0sHsgDu2iSqtjpYvRBGdupxbXFmG2QJ8hd3i3wvc2RKkgs X-IronPort-AV: E=Sophos;i="5.17,702,1437451200"; d="scan'208,217";a="86769" X-IPAS-Result: A2CrBACM9iRW/8r6+gpeGQEBAQEOAQEBgjuBIW8Gv2IOFwENgj+CcEoCHIFXEQEBAQEBAQEBgQmCJoIHAQEBAQECAQEBIAocJQMIDAQCAQYCEQQBASEHAwICAh8GCxQJCAEBBAENBQiIEwMXCJMcnTeBS4wFDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ5g3aBBoJQgVoKBwEKDx0WAQQGAQaCY4FFBYc+hVSJEQGFGIYPgW6BX0iDdIMkixYLg1CDbxEmhC9yAQGEHAIHOoEGAQEB From: "Ratliff, Stanley" To: "Dearlove, Christopher (UK)" , Stan Ratliff Thread-Topic: [manet] DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBwBm9nRwAGEtIrAAEtzJgAAA5EmAAAg8uAA= Date: Mon, 19 Oct 2015 13:59:03 +0000 Message-ID: <388d2e5efea1412b8d9c887e53d0b944@VAUSDITCHM3.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.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: multipart/alternative; boundary="_000_388d2e5efea1412b8d9c887e53d0b944VAUSDITCHM3idirectnet_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 13:59:13 -0000 --_000_388d2e5efea1412b8d9c887e53d0b944VAUSDITCHM3idirectnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGhlcmXigJlzIGEgZG93bnNpZGUgdG8g4oCYcmFkaW/igJkg4oCTIGl0IGdpdmVzIHRoZSBpbXBy ZXNzaW9uIHRoYXQgRExFUCBpcyBsaW1pdGVkIHRvICpvbmx5KiByYWRpby1iYXNlZCBpbXBsZW1l bnRhdGlvbnMuIEl04oCZcyBub3QuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KRnJvbTogbWFuZXQg W21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENo cmlzdG9waGVyIChVSykNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAxNSA5OjU0IEFNDQpU bzogU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb20+DQpDYzogbWFuZXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVANCg0KSeKAmWQgc3VnZ2VzdCBhIHN0cmF3IHBv bGwuIFB1dCBtZSBkb3duIGZvciByYWRpbyBvdmVyIG1vZGVtLCB0aG91Z2ggb3BlbiB0byBhIGJl dHRlciBzdWdnZXN0aW9uLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmlu Y2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoN CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5 c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxl cyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywg R3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpGcm9tOiBTdGFuIFJhdGxpZmYgW21haWx0 bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21dDQpTZW50OiAxOSBPY3RvYmVyIDIwMTUgMTQ6MjkNClRv OiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQDQoN Cg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUg aW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRp b24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWls cyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMu Y29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5w ZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cg dGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91 cyUyMEVtYWlscy5wZGY+Lg0KQWxsLA0KDQpJIHRoaW5rIFJpY2sgaGl0IHRoZSBuYWlsIG9uIHRo ZSBoZWFkLiBXZSBpbml0aWFsbHkgdXNlZCB0aGUgdGVybSAicmFkaW8iLCBidXQgY2hhbmdlZCBp dCB3aGVuIHdlIHJlYWxpemVkIHRoYXQgRExFUCAqY291bGQqIChidXQgZG9lc24ndCBoYXZlIHRv KSBiZSB1c2VkIGluIGRldmljZXMgbGlrZSBjYWJsZSBtb2RlbXMuICJSb3V0ZXIiIGlzIGFsc28g YSBmYXIgZnJvbSBwZXJmZWN0IHRlcm0gLSBJJ20gY3VycmVudGx5IHdvcmtpbmcgb24gYW4gaW1w bGVtZW50YXRpb24gd2hlcmUgdGhlICJyb3V0ZXIiIGNvZGUgYWN0dWFsbHkgbGl2ZXMgaW4gYW4g aURpcmVjdC1zcGVjaWZpYyBhcHBsaWNhdGlvbiBoYXZpbmcgbm90aGluZyB0byBkbyB3aXRoIHJv dXRpbmcuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KT24gTW9uLCBPY3QgMTksIDIwMTUgYXQgNDoz MSBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3RlOg0KSSB0 YWtlIHRoZSBwb2ludCBhYm91dCByYWRpbyBiZWluZyBpbXBlcmZlY3QsIGJ1dCBJIHRoaW5rIGl0 J3Mgc2lnbmlmaWNhbnRseSBsZXNzIGltcGVyZmVjdCB0aGFuIG1vZGVtLg0KDQpJIGNhbid0IHRo aW5rIG9mIGFueXRoaW5nIGJldHRlciBteXNlbGYuDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJs b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6 JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5 c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBH cmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5j b20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAw MTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZv cmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbTxtYWls dG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPl0NClNlbnQ6IDE3IE9jdG9iZXIgMjAx NSAxMToxNg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldEBpZXRmLm9yZzxt YWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogRExFUA0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxs eSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2ht ZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGlu ayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMg ZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXZpZXcgQ2hyaXMsDQoN CkFzIGZhciBhcyB0aGUgd2hvbGUgJ21vZGVtJyB2ZXJzdXMgJ3JhZGlvJyB3b3JkaW5nIGlzIGNv bmNlcm5lZDogSSBzaGFyZSB5b3VyIHNsaWdodCBkaXNjb21mb3J0IHdpdGggdGhlIHdvcmQgJ21v ZGVtJywgYnV0IEknbSBub3Qgc3VyZSAncmFkaW8nIGlzIGFueSBiZXR0ZXIhICBGb3IgZXhhbXBs ZSwgSSBoYXZlIHNvbWUgc2NydWZmeSBjb2RlIHdoaWNoIHByZXRlbmRzIHRvIGJlIGEgRExFUCBt b2RlbSBmb3IgRE1WUE4gdHVubmVscywgYW5kIHRoZXJlJ3MgZGVmaW5pdGVseSBubyByYWRpbyBp bnZvbHZlZC4NCg0KSSdtIGRlZmluaXRlbHkgd2lsbGluZyB0byBsaXN0ZW4gdG8gc3VnZ2VzdGlv bnMgZnJvbSB0aGUgV0cgZm9yIHdvcmRzIHRvIHJlcGxhY2UgJ21vZGVtJyB3aXRoIGEgd29yZCB0 byBtZWFuICdhIGRldmljZSB0aGF0IGZvcndhcmRzIGxheWVyLTIgcGFja2V0cyB0byBpdHMgcGVl cnMsIGhhcyBsaW5rIHNlbnNpbmcsIGFuZCBpcyBjb21tb25seSBzb21lIGtpbmQgb2YgcmFkaW8n LiAgV2hldGhlciB3ZSBtYWtlIHRoZSBjaGFuZ2UgZGVwZW5kcyBlbnRpcmVseSBvbiB3aGV0aGVy IHRoZSBXRyBoYXMgdGhlIHBhdGllbmNlLiA7KQ0KDQpJIGJlbGlldmUgKEkgaGF2ZW4ndCBnb3Qg ZHJhZnQtMTcgb3BlbiBpbiBmcm9udCBvZiBtZSkgdGhhdCB3ZSBoYXZlIHRhY2tsZWQgc29tZSBv ZiB5b3VyIGlzc3VlcyB3aXRoIHRoZSBSRkMgNTIyNiB0ZXJtaW5vbG9neSBpbiAxNyBhcyB3ZWxs LCB1c2luZyAnUHJpdmF0ZSBVc2UnIGluc3RlYWQgb2YgJ1Jlc2VydmVkJyB3aGVuIGFwcHJvcHJp YXRlLg0KDQpDaGVlcnMsDQpSaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0LWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNClNl bnQ6IDE1IE9jdG9iZXIgMjAxNSAxMDoyMg0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5l dEBpZXRmLm9yZz4NClN1YmplY3Q6IFttYW5ldF0gRExFUA0KDQpJJ3ZlIHJlYWQgRExFUCBkcmFm dCAxNiwgYnV0IG5vdCBzbyBmYXIgd2l0aCBhIGNyaXRpY2FsIGV5ZSB0byBzcGVjaWZpYyByZXZp ZXcgY29tbWVudHMgLSBvdGhlciB0aGFuIHRoYXQgdGhlIElBTkEgc2VjdGlvbiBpc24ndCB3aGF0 J3MgbmVlZGVkIChidXQgdGhlIGF1dGhvcnMgYWxyZWFkeSBrbm93IHRoYXQgYW5kIEkgdW5kZXJz dGFuZCBoYXZlIGFscmVhZHkgd3JpdHRlbiBhIHJlcGxhY2VtZW50KSBhbmQgYSBmZXcgZWRpdG9y aWFsIGNvbW1lbnRzIEknbGwgbWFrZSBiZWxvdy4gSW4gcGFydGljdWxhciBJIGhhdmVuJ3QgZm9y bWVkIGEgdmlldyBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAtIGJ1dCBJ IG1heSB3YWl0IGZvciB0aGlzIGFuZCBtb3N0IG90aGVyIHBvaW50cyB0byBzZWUgLTE3IHdoaWNo IEkgdW5kZXJzdGFuZCBpcyBtb3N0bHkgd3JpdHRlbi4NCg0KTXkgbWlub3IgcG9pbnRzOg0KDQot IEkgcmVhbGx5IHdvdWxkIHByZWZlciAicmFkaW8iIHRvICJtb2RlbSIgdGhyb3VnaG91dC4gQXMg c29tZW9uZSB3aG8gb25jZSB3cm90ZSBzb21lIG1vZGVtIHNvZnR3YXJlLCBmb3IgbWUgbW9kZW0g aXMgd2hhdCBpdCBzYXlzLCBtb2R1bGF0aW9uIGFuZCBkZW1vZHVsYXRpb24gKGFuZCB0aGUgaW5z ZXBhcmFibGUgY2hhbm5lbCBjb2RpbmcpLCBpLmUuIGNvbnZlcnRpbmcgYmV0d2VlbiBiaXQgc3Ry ZWFtcyBhbmQgbW9kdWxhdGVkIHNpZ25hbHMgKGZvciBhIGRpZ2l0YWwgcmFkaW8pLlRoZXJlIGFy ZSBtYW55IHBhcnRzIG9mIGEgcmFkaW8gdGhhdCBhcmUgb3V0c2lkZSB0aGF0LCBhbmQgZXZlcnl0 aGluZyBETEVQIGlzIG91dHNpZGUgdGhlIG1vZGVtLg0KDQotIFdoZXJlIHRoZXJlIGFyZSB2YXJp b3VzIHRpbWUgYW5kIG90aGVyIHZhbHVlcyAodGltZW91dHMsIHJlcGVhdCBwZXJpb2RzLCBudW1i ZXIgb2YgcmV0cmllcykgSSdkIHVzZSBhIHN5bWJvbGljIG5hbWUgYW5kIGNvbGxlY3Qgc3VnZ2Vz dGVkIGRlZmF1bHQgdmFsdWVzIGluIG9uZSBwbGFjZS4gVGhhdCBpcyBhZnRlciBhbGwsIGFzIHdl IGFsbCB3cml0ZSBzb2Z0d2FyZS4NCg0KLSBDdXJyZW50bHkgZGVzY3JpYmVzIHNvbWUgY29kZSBw b2ludHMgYXMgIlJlc2VydmVkIGZvciBmdXR1cmUgZXh0ZW5zaW9ucyIuIFRoaXMgaXMgbm90IHRo ZSBjb3JyZWN0IHRlcm1pbm9sb2d5LiBGcm9tIFJGQyA1MjI2Og0KDQogICAgICBSZXNlcnZlZDog IE5vdCB0byBiZSBhc3NpZ25lZC4gIFJlc2VydmVkIHZhbHVlcyBhcmUgaGVsZCBmb3INCiAgICAg ICAgICAgIHNwZWNpYWwgdXNlcywgc3VjaCBhcyB0byBleHRlbmQgdGhlIG5hbWVzcGFjZSB3aGVu IGl0IGJlY29tZQ0KICAgICAgICAgICAgZXhoYXVzdGVkLiAgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBu b3QgYXZhaWxhYmxlIGZvciBnZW5lcmFsDQogICAgICAgICAgICBhc3NpZ25tZW50Lg0KDQogICAg KFRoZSBSZXNlcnZlZCBmb3IgMCBhbmQgNjU1MzUgaXMgaG93ZXZlciBwcmVzdW1hYmx5IGNvcnJl Y3QuKQ0KDQogICBBcyBJIGtub3cgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyBk b25lLCB0aGlzIG1heSBhbHJlYWR5IGhhdmUgYmVlbiBjYXVnaHQsIGJ1dCBJJ2xsIHNheSBpdCBp biBjYXNlIG5vdC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUy MDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxp Z2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2Zv cmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVz eXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQg UmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxIFJlZ2lzdGVyZWQgT2Zm aWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0K DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUg aXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5v dCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIGRpc3Ry aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFp bGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0 QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBjb250YWlucwppbmZvcm1hdGlvbiBmcm9tIGlEaXJlY3Qs IHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeQphbmQvb3IgY29uZmlkZW50aWFs LiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwKb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgb3Jp Z2luYWwKcmVjaXBpZW50IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcg dGhlIGVtYWlsIHRvIHRoZQppbnRlbmRlZCByZWNpcGllbnQsIGJlIGFkdmlzZWQgdGhhdCB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVycm9yLCBhbmQgdGhhdCBhbnkgdXNlLCBkaXNz ZW1pbmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3IKY29weWluZyBvZiB0aGlzIGVtYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGVtYWlsCmluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci4K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K --_000_388d2e5efea1412b8d9c887e53d0b944VAUSDITCHM3idirectnet_ 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 IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhlcmXigJlzIGEgZG93bnNpZGUgdG8g4oCYcmFkaW/igJkg4oCTIGl0IGdpdmVzIHRoZSBp bXByZXNzaW9uIHRoYXQgRExFUCBpcyBsaW1pdGVkIHRvICo8Yj5vbmx5PC9iPiogcmFkaW8tYmFz ZWQgaW1wbGVtZW50YXRpb25zLiBJdOKAmXMgbm90Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TdGFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGVhcmxvdmUsIENocmlzdG9waGVyIChV Syk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDk6NTQgQU08YnI+ DQo8Yj5Ubzo8L2I+IFN0YW4gUmF0bGlmZiAmbHQ7cmF0bGlmZnN0YW5AZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtt YW5ldF0gRExFUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmWQgc3VnZ2Vz dCBhIHN0cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZvciByYWRpbyBvdmVyIG1vZGVtLCB0aG91Z2gg b3BlbiB0byBhIGJldHRlciBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2U8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiNC RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNw O3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBD aGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lz dGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyO3RleHQtZGVjb3JhdGlvbjpu b25lIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJl Z2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBP ZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBTdGFuIFJhdGxpZmYgWzxhIGhyZWY9Im1haWx0 bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iPm1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE5IE9jdG9iZXIgMjAxNSAxNDoyOTxicj4NCjxiPlRvOjwv Yj4gRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IFJpY2sgVGF5bG9y OyA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBETEVQPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5n OjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7 YmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMz Mzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Db25zaWRlciBjYXJlZnVsbHkg d2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVu dHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5n IDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91 dA0KIGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRy YW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9j dW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHlvdSBmZWVsIHRo ZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMg cHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5BbGwsJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSB0aGluayBSaWNr IGhpdCB0aGUgbmFpbCBvbiB0aGUgaGVhZC4gV2UgaW5pdGlhbGx5IHVzZWQgdGhlIHRlcm0gJnF1 b3Q7cmFkaW8mcXVvdDssIGJ1dCBjaGFuZ2VkIGl0IHdoZW4gd2UgcmVhbGl6ZWQgdGhhdCBETEVQ ICpjb3VsZCogKGJ1dCBkb2Vzbid0IGhhdmUgdG8pIGJlIHVzZWQgaW4gZGV2aWNlcyBsaWtlIGNh YmxlIG1vZGVtcy4gJnF1b3Q7Um91dGVyJnF1b3Q7IGlzIGFsc28gYSBmYXIgZnJvbSBwZXJmZWN0 DQogdGVybSAtIEknbSBjdXJyZW50bHkgd29ya2luZyBvbiBhbiBpbXBsZW1lbnRhdGlvbiB3aGVy ZSB0aGUgJnF1b3Q7cm91dGVyJnF1b3Q7IGNvZGUgYWN0dWFsbHkgbGl2ZXMgaW4gYW4gaURpcmVj dC1zcGVjaWZpYyBhcHBsaWNhdGlvbiBoYXZpbmcgbm90aGluZyB0byBkbyB3aXRoIHJvdXRpbmcu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5S ZWdhcmRzLDxicj4NClN0YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBNb24sIE9jdCAxOSwgMjAx NSBhdCA0OjMxIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SSB0YWtlIHRoZSBw b2ludCBhYm91dCByYWRpbyBiZWluZyBpbXBlcmZlY3QsIGJ1dCBJIHRoaW5rIGl0J3Mgc2lnbmlm aWNhbnRseSBsZXNzIGltcGVyZmVjdCB0aGFuIG1vZGVtLjxicj4NCjxicj4NCkkgY2FuJ3QgdGhp bmsgb2YgYW55dGhpbmcgYmV0dGVyIG15c2VsZi48YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCkNo cmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQo8YnI+DQpUOiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5 NCI+JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NDwvYT4gJm5ic3A7fCAmbmJzcDtFOiA8YSBocmVmPSJt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPg0KY2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208L2E+PGJyPg0KPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQs IEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9h aSIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvYT48YnI+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmds YW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxicj4NClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJy ZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8YnI+DQo8YnI+DQo8 YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFJpY2sgVGF5bG9yIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbSI+cmlj a0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPC9hPl08YnI+DQpTZW50OiAxNyBPY3RvYmVyIDIw MTUgMTE6MTY8YnI+DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IDxhIGhyZWY9Im1h aWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUkU6 IERMRVA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3Vy IG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRo ZSBpbnRlcm5ldC48YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNs aWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuPGJyPg0KRm9s bG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9y IGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy48YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJldmlldyBDaHJpcyw8YnI+DQo8YnI+ DQpBcyBmYXIgYXMgdGhlIHdob2xlICdtb2RlbScgdmVyc3VzICdyYWRpbycgd29yZGluZyBpcyBj b25jZXJuZWQ6IEkgc2hhcmUgeW91ciBzbGlnaHQgZGlzY29tZm9ydCB3aXRoIHRoZSB3b3JkICdt b2RlbScsIGJ1dCBJJ20gbm90IHN1cmUgJ3JhZGlvJyBpcyBhbnkgYmV0dGVyISZuYnNwOyBGb3Ig ZXhhbXBsZSwgSSBoYXZlIHNvbWUgc2NydWZmeSBjb2RlIHdoaWNoIHByZXRlbmRzIHRvIGJlIGEg RExFUCBtb2RlbSBmb3IgRE1WUE4gdHVubmVscywgYW5kIHRoZXJlJ3MNCiBkZWZpbml0ZWx5IG5v IHJhZGlvIGludm9sdmVkLjxicj4NCjxicj4NCkknbSBkZWZpbml0ZWx5IHdpbGxpbmcgdG8gbGlz dGVuIHRvIHN1Z2dlc3Rpb25zIGZyb20gdGhlIFdHIGZvciB3b3JkcyB0byByZXBsYWNlICdtb2Rl bScgd2l0aCBhIHdvcmQgdG8gbWVhbiAnYSBkZXZpY2UgdGhhdCBmb3J3YXJkcyBsYXllci0yIHBh Y2tldHMgdG8gaXRzIHBlZXJzLCBoYXMgbGluayBzZW5zaW5nLCBhbmQgaXMgY29tbW9ubHkgc29t ZSBraW5kIG9mIHJhZGlvJy4mbmJzcDsgV2hldGhlciB3ZSBtYWtlIHRoZSBjaGFuZ2UgZGVwZW5k cyBlbnRpcmVseQ0KIG9uIHdoZXRoZXIgdGhlIFdHIGhhcyB0aGUgcGF0aWVuY2UuIDspPGJyPg0K PGJyPg0KSSBiZWxpZXZlIChJIGhhdmVuJ3QgZ290IGRyYWZ0LTE3IG9wZW4gaW4gZnJvbnQgb2Yg bWUpIHRoYXQgd2UgaGF2ZSB0YWNrbGVkIHNvbWUgb2YgeW91ciBpc3N1ZXMgd2l0aCB0aGUgUkZD IDUyMjYgdGVybWlub2xvZ3kgaW4gMTcgYXMgd2VsbCwgdXNpbmcgJ1ByaXZhdGUgVXNlJyBpbnN0 ZWFkIG9mICdSZXNlcnZlZCcgd2hlbiBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpDaGVlcnMsPGJy Pg0KUmljazxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog bWFuZXQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyI+bWFu ZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEZWFybG92ZSwgQ2hyaXN0b3Bo ZXIgKFVLKTxicj4NClNlbnQ6IDE1IE9jdG9iZXIgMjAxNSAxMDoyMjxicj4NClRvOiA8YSBocmVm PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6 IFttYW5ldF0gRExFUDxicj4NCjxicj4NCkkndmUgcmVhZCBETEVQIGRyYWZ0IDE2LCBidXQgbm90 IHNvIGZhciB3aXRoIGEgY3JpdGljYWwgZXllIHRvIHNwZWNpZmljIHJldmlldyBjb21tZW50cyAt IG90aGVyIHRoYW4gdGhhdCB0aGUgSUFOQSBzZWN0aW9uIGlzbid0IHdoYXQncyBuZWVkZWQgKGJ1 dCB0aGUgYXV0aG9ycyBhbHJlYWR5IGtub3cgdGhhdCBhbmQgSSB1bmRlcnN0YW5kIGhhdmUgYWxy ZWFkeSB3cml0dGVuIGEgcmVwbGFjZW1lbnQpIGFuZCBhIGZldyBlZGl0b3JpYWwgY29tbWVudHMN CiBJJ2xsIG1ha2UgYmVsb3cuIEluIHBhcnRpY3VsYXIgSSBoYXZlbid0IGZvcm1lZCBhIHZpZXcg b24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gLSBidXQgSSBtYXkgd2FpdCBm b3IgdGhpcyBhbmQgbW9zdCBvdGhlciBwb2ludHMgdG8gc2VlIC0xNyB3aGljaCBJIHVuZGVyc3Rh bmQgaXMgbW9zdGx5IHdyaXR0ZW4uPGJyPg0KPGJyPg0KTXkgbWlub3IgcG9pbnRzOjxicj4NCjxi cj4NCi0gSSByZWFsbHkgd291bGQgcHJlZmVyICZxdW90O3JhZGlvJnF1b3Q7IHRvICZxdW90O21v ZGVtJnF1b3Q7IHRocm91Z2hvdXQuIEFzIHNvbWVvbmUgd2hvIG9uY2Ugd3JvdGUgc29tZSBtb2Rl bSBzb2Z0d2FyZSwgZm9yIG1lIG1vZGVtIGlzIHdoYXQgaXQgc2F5cywgbW9kdWxhdGlvbiBhbmQg ZGVtb2R1bGF0aW9uIChhbmQgdGhlIGluc2VwYXJhYmxlIGNoYW5uZWwgY29kaW5nKSwgaS5lLiBj b252ZXJ0aW5nIGJldHdlZW4gYml0IHN0cmVhbXMgYW5kIG1vZHVsYXRlZCBzaWduYWxzIChmb3IN CiBhIGRpZ2l0YWwgcmFkaW8pLlRoZXJlIGFyZSBtYW55IHBhcnRzIG9mIGEgcmFkaW8gdGhhdCBh cmUgb3V0c2lkZSB0aGF0LCBhbmQgZXZlcnl0aGluZyBETEVQIGlzIG91dHNpZGUgdGhlIG1vZGVt Ljxicj4NCjxicj4NCi0gV2hlcmUgdGhlcmUgYXJlIHZhcmlvdXMgdGltZSBhbmQgb3RoZXIgdmFs dWVzICh0aW1lb3V0cywgcmVwZWF0IHBlcmlvZHMsIG51bWJlciBvZiByZXRyaWVzKSBJJ2QgdXNl IGEgc3ltYm9saWMgbmFtZSBhbmQgY29sbGVjdCBzdWdnZXN0ZWQgZGVmYXVsdCB2YWx1ZXMgaW4g b25lIHBsYWNlLiBUaGF0IGlzIGFmdGVyIGFsbCwgYXMgd2UgYWxsIHdyaXRlIHNvZnR3YXJlLjxi cj4NCjxicj4NCi0gQ3VycmVudGx5IGRlc2NyaWJlcyBzb21lIGNvZGUgcG9pbnRzIGFzICZxdW90 O1Jlc2VydmVkIGZvciBmdXR1cmUgZXh0ZW5zaW9ucyZxdW90Oy4gVGhpcyBpcyBub3QgdGhlIGNv cnJlY3QgdGVybWlub2xvZ3kuIEZyb20gUkZDIDUyMjY6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgUmVzZXJ2ZWQ6Jm5ic3A7IE5vdCB0byBiZSBhc3NpZ25lZC4mbmJzcDsgUmVzZXJ2 ZWQgdmFsdWVzIGFyZSBoZWxkIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHNwZWNpYWwgdXNlcywgc3VjaCBhcyB0byBleHRlbmQgdGhlIG5hbWVzcGFj ZSB3aGVuIGl0IGJlY29tZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGV4aGF1c3RlZC4mbmJzcDsgUmVzZXJ2ZWQgdmFsdWVzIGFyZSBub3QgYXZhaWxhYmxl IGZvciBnZW5lcmFsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYXNzaWdubWVudC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IChUaGUgUmVzZXJ2ZWQgZm9y IDAgYW5kIDY1NTM1IGlzIGhvd2V2ZXIgcHJlc3VtYWJseSBjb3JyZWN0Lik8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7QXMgSSBrbm93IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMg ZG9uZSwgdGhpcyBtYXkgYWxyZWFkeSBoYXZlIGJlZW4gY2F1Z2h0LCBidXQgSSdsbCBzYXkgaXQg aW4gY2FzZSBub3QuPGJyPg0KPGJyPg0KLS08YnI+DQpDaHJpc3RvcGhlciBEZWFybG92ZTxicj4N ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KVDogJm5ic3A7PGEgaHJl Zj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiPiYjNDM7NDQgKDApMTI0NSAyNDIx OTQ8L2E+ICZuYnNwO3wgJm5ic3A7RTogPGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tIj4NCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxi cj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xv Z3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxh IGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cu YmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGltaXRlZCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUx IFJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJy ZXksIEdVMiA3WVA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFu ZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBp dCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQ8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxicj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgY29sb3I6ICMwMDMzNjY7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5UaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnM8YnI+aW5mb3JtYXRpb24gZnJv bSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnk8YnI+YW5kL29y IGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsPGJyPm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIG9yaWdpbmFsPGJyPnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNp YmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGU8YnI+aW50ZW5kZWQgcmVjaXBpZW50 LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbDxicj5pbiBlcnJv ciwgYW5kIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcs IG9yPGJyPmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5 b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbDxicj5pbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg aW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_388d2e5efea1412b8d9c887e53d0b944VAUSDITCHM3idirectnet_-- From nobody Mon Oct 19 07:01:34 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC011A6FA3 for ; Mon, 19 Oct 2015 07:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.102 X-Spam-Level: X-Spam-Status: No, score=-4.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMupAVluGM9R for ; Mon, 19 Oct 2015 07:01:28 -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 62D191A6F9F for ; Mon, 19 Oct 2015 07:01:24 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.17,702,1437433200"; d="scan'208,217"; a="14853697" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 19 Oct 2015 15:01:22 +0100 X-IronPort-AV: E=Sophos;i="5.17,702,1437433200"; d="scan'208,217";a="116855746" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 19 Oct 2015 15:01:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.69]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 15:01:22 +0100 From: "Dearlove, Christopher (UK)" To: "Ratliff, Stanley" , Stan Ratliff Thread-Topic: [manet] DLEP Thread-Index: AdEHJ5wNC0ZL+4DURwqe8PO/tbuCBwBm9nRwAGEtIrAACGKTgAAC9zKA///wuID//+6rgA== Date: Mon, 19 Oct 2015 14:01:22 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> <388d2e5efea1412b8d9c887e53d0b944@VAUSDITCHM3.idirect.net> In-Reply-To: <388d2e5efea1412b8d9c887e53d0b944@VAUSDITCHM3.idirect.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_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA75BEGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:01:32 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA75BEGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5kZWVkLCBubyB0ZXJtIGlzIHBlcmZlY3QuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0K U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u DQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCkZyb206IFJhdGxpZmYs IFN0YW5sZXkgW21haWx0bzpzcmF0bGlmZkBpZGlyZWN0Lm5ldF0NClNlbnQ6IDE5IE9jdG9iZXIg MjAxNSAxNDo1OQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBTdGFuIFJhdGxpZmYN CkNjOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFttYW5ldF0gRExFUA0KDQoNCioqKiBX QVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0 Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlu a3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2Fy ZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJl Y2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3 ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklm IHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJv Y2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0 eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFp bHMucGRmPi4NClRoZXJl4oCZcyBhIGRvd25zaWRlIHRvIOKAmHJhZGlv4oCZIOKAkyBpdCBnaXZl cyB0aGUgaW1wcmVzc2lvbiB0aGF0IERMRVAgaXMgbGltaXRlZCB0byAqb25seSogcmFkaW8tYmFz ZWQgaW1wbGVtZW50YXRpb25zLiBJdOKAmXMgbm90Lg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCkZy b206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMTUg OTo1NCBBTQ0KVG86IFN0YW4gUmF0bGlmZiA8cmF0bGlmZnN0YW5AZ21haWwuY29tPG1haWx0bzpy YXRsaWZmc3RhbkBnbWFpbC5jb20+Pg0KQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVANCg0KSeKAmWQgc3VnZ2VzdCBhIHN0 cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZvciByYWRpbyBvdmVyIG1vZGVtLCB0aG91Z2ggb3BlbiB0 byBhIGJldHRlciBzdWdnZXN0aW9uLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3 LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpGcm9tOiBTdGFuIFJhdGxpZmYg W21haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21dDQpTZW50OiAxOSBPY3RvYmVyIDIwMTUgMTQ6 MjkNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IFJpY2sgVGF5bG9yOyBtYW5l dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBE TEVQDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv ciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNs aWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5m b3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGlu IGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5 c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBG bGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBm b2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3Vz cGljaW91cyUyMEVtYWlscy5wZGY+Lg0KQWxsLA0KDQpJIHRoaW5rIFJpY2sgaGl0IHRoZSBuYWls IG9uIHRoZSBoZWFkLiBXZSBpbml0aWFsbHkgdXNlZCB0aGUgdGVybSAicmFkaW8iLCBidXQgY2hh bmdlZCBpdCB3aGVuIHdlIHJlYWxpemVkIHRoYXQgRExFUCAqY291bGQqIChidXQgZG9lc24ndCBo YXZlIHRvKSBiZSB1c2VkIGluIGRldmljZXMgbGlrZSBjYWJsZSBtb2RlbXMuICJSb3V0ZXIiIGlz IGFsc28gYSBmYXIgZnJvbSBwZXJmZWN0IHRlcm0gLSBJJ20gY3VycmVudGx5IHdvcmtpbmcgb24g YW4gaW1wbGVtZW50YXRpb24gd2hlcmUgdGhlICJyb3V0ZXIiIGNvZGUgYWN0dWFsbHkgbGl2ZXMg aW4gYW4gaURpcmVjdC1zcGVjaWZpYyBhcHBsaWNhdGlvbiBoYXZpbmcgbm90aGluZyB0byBkbyB3 aXRoIHJvdXRpbmcuDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KT24gTW9uLCBPY3QgMTksIDIwMTUg YXQgNDozMSBBTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+IHdyb3Rl Og0KSSB0YWtlIHRoZSBwb2ludCBhYm91dCByYWRpbyBiZWluZyBpbXBlcmZlY3QsIGJ1dCBJIHRo aW5rIGl0J3Mgc2lnbmlmaWNhbnRseSBsZXNzIGltcGVyZmVjdCB0aGFuIG1vZGVtLg0KDQpJIGNh bid0IHRoaW5rIG9mIGFueXRoaW5nIGJldHRlciBteXNlbGYuDQoNCg0KLS0NCkNocmlzdG9waGVy IERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5 NDx0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0K QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQ YXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lz dGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVz IE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBH dWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNv bTxtYWlsdG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tPl0NClNlbnQ6IDE3IE9jdG9i ZXIgMjAxNSAxMToxNg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldEBpZXRm Lm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogRExFUA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWls cycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3Bp Y2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXZpZXcgQ2hy aXMsDQoNCkFzIGZhciBhcyB0aGUgd2hvbGUgJ21vZGVtJyB2ZXJzdXMgJ3JhZGlvJyB3b3JkaW5n IGlzIGNvbmNlcm5lZDogSSBzaGFyZSB5b3VyIHNsaWdodCBkaXNjb21mb3J0IHdpdGggdGhlIHdv cmQgJ21vZGVtJywgYnV0IEknbSBub3Qgc3VyZSAncmFkaW8nIGlzIGFueSBiZXR0ZXIhICBGb3Ig ZXhhbXBsZSwgSSBoYXZlIHNvbWUgc2NydWZmeSBjb2RlIHdoaWNoIHByZXRlbmRzIHRvIGJlIGEg RExFUCBtb2RlbSBmb3IgRE1WUE4gdHVubmVscywgYW5kIHRoZXJlJ3MgZGVmaW5pdGVseSBubyBy YWRpbyBpbnZvbHZlZC4NCg0KSSdtIGRlZmluaXRlbHkgd2lsbGluZyB0byBsaXN0ZW4gdG8gc3Vn Z2VzdGlvbnMgZnJvbSB0aGUgV0cgZm9yIHdvcmRzIHRvIHJlcGxhY2UgJ21vZGVtJyB3aXRoIGEg d29yZCB0byBtZWFuICdhIGRldmljZSB0aGF0IGZvcndhcmRzIGxheWVyLTIgcGFja2V0cyB0byBp dHMgcGVlcnMsIGhhcyBsaW5rIHNlbnNpbmcsIGFuZCBpcyBjb21tb25seSBzb21lIGtpbmQgb2Yg cmFkaW8nLiAgV2hldGhlciB3ZSBtYWtlIHRoZSBjaGFuZ2UgZGVwZW5kcyBlbnRpcmVseSBvbiB3 aGV0aGVyIHRoZSBXRyBoYXMgdGhlIHBhdGllbmNlLiA7KQ0KDQpJIGJlbGlldmUgKEkgaGF2ZW4n dCBnb3QgZHJhZnQtMTcgb3BlbiBpbiBmcm9udCBvZiBtZSkgdGhhdCB3ZSBoYXZlIHRhY2tsZWQg c29tZSBvZiB5b3VyIGlzc3VlcyB3aXRoIHRoZSBSRkMgNTIyNiB0ZXJtaW5vbG9neSBpbiAxNyBh cyB3ZWxsLCB1c2luZyAnUHJpdmF0ZSBVc2UnIGluc3RlYWQgb2YgJ1Jlc2VydmVkJyB3aGVuIGFw cHJvcHJpYXRlLg0KDQpDaGVlcnMsDQpSaWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlzdG9waGVyIChV SykNClNlbnQ6IDE1IE9jdG9iZXIgMjAxNSAxMDoyMg0KVG86IG1hbmV0QGlldGYub3JnPG1haWx0 bzptYW5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFttYW5ldF0gRExFUA0KDQpJJ3ZlIHJlYWQgRExF UCBkcmFmdCAxNiwgYnV0IG5vdCBzbyBmYXIgd2l0aCBhIGNyaXRpY2FsIGV5ZSB0byBzcGVjaWZp YyByZXZpZXcgY29tbWVudHMgLSBvdGhlciB0aGFuIHRoYXQgdGhlIElBTkEgc2VjdGlvbiBpc24n dCB3aGF0J3MgbmVlZGVkIChidXQgdGhlIGF1dGhvcnMgYWxyZWFkeSBrbm93IHRoYXQgYW5kIEkg dW5kZXJzdGFuZCBoYXZlIGFscmVhZHkgd3JpdHRlbiBhIHJlcGxhY2VtZW50KSBhbmQgYSBmZXcg ZWRpdG9yaWFsIGNvbW1lbnRzIEknbGwgbWFrZSBiZWxvdy4gSW4gcGFydGljdWxhciBJIGhhdmVu J3QgZm9ybWVkIGEgdmlldyBvbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAt IGJ1dCBJIG1heSB3YWl0IGZvciB0aGlzIGFuZCBtb3N0IG90aGVyIHBvaW50cyB0byBzZWUgLTE3 IHdoaWNoIEkgdW5kZXJzdGFuZCBpcyBtb3N0bHkgd3JpdHRlbi4NCg0KTXkgbWlub3IgcG9pbnRz Og0KDQotIEkgcmVhbGx5IHdvdWxkIHByZWZlciAicmFkaW8iIHRvICJtb2RlbSIgdGhyb3VnaG91 dC4gQXMgc29tZW9uZSB3aG8gb25jZSB3cm90ZSBzb21lIG1vZGVtIHNvZnR3YXJlLCBmb3IgbWUg bW9kZW0gaXMgd2hhdCBpdCBzYXlzLCBtb2R1bGF0aW9uIGFuZCBkZW1vZHVsYXRpb24gKGFuZCB0 aGUgaW5zZXBhcmFibGUgY2hhbm5lbCBjb2RpbmcpLCBpLmUuIGNvbnZlcnRpbmcgYmV0d2VlbiBi aXQgc3RyZWFtcyBhbmQgbW9kdWxhdGVkIHNpZ25hbHMgKGZvciBhIGRpZ2l0YWwgcmFkaW8pLlRo ZXJlIGFyZSBtYW55IHBhcnRzIG9mIGEgcmFkaW8gdGhhdCBhcmUgb3V0c2lkZSB0aGF0LCBhbmQg ZXZlcnl0aGluZyBETEVQIGlzIG91dHNpZGUgdGhlIG1vZGVtLg0KDQotIFdoZXJlIHRoZXJlIGFy ZSB2YXJpb3VzIHRpbWUgYW5kIG90aGVyIHZhbHVlcyAodGltZW91dHMsIHJlcGVhdCBwZXJpb2Rz LCBudW1iZXIgb2YgcmV0cmllcykgSSdkIHVzZSBhIHN5bWJvbGljIG5hbWUgYW5kIGNvbGxlY3Qg c3VnZ2VzdGVkIGRlZmF1bHQgdmFsdWVzIGluIG9uZSBwbGFjZS4gVGhhdCBpcyBhZnRlciBhbGws IGFzIHdlIGFsbCB3cml0ZSBzb2Z0d2FyZS4NCg0KLSBDdXJyZW50bHkgZGVzY3JpYmVzIHNvbWUg Y29kZSBwb2ludHMgYXMgIlJlc2VydmVkIGZvciBmdXR1cmUgZXh0ZW5zaW9ucyIuIFRoaXMgaXMg bm90IHRoZSBjb3JyZWN0IHRlcm1pbm9sb2d5LiBGcm9tIFJGQyA1MjI2Og0KDQogICAgICBSZXNl cnZlZDogIE5vdCB0byBiZSBhc3NpZ25lZC4gIFJlc2VydmVkIHZhbHVlcyBhcmUgaGVsZCBmb3IN CiAgICAgICAgICAgIHNwZWNpYWwgdXNlcywgc3VjaCBhcyB0byBleHRlbmQgdGhlIG5hbWVzcGFj ZSB3aGVuIGl0IGJlY29tZQ0KICAgICAgICAgICAgZXhoYXVzdGVkLiAgUmVzZXJ2ZWQgdmFsdWVz IGFyZSBub3QgYXZhaWxhYmxlIGZvciBnZW5lcmFsDQogICAgICAgICAgICBhc3NpZ25tZW50Lg0K DQogICAgKFRoZSBSZXNlcnZlZCBmb3IgMCBhbmQgNjU1MzUgaXMgaG93ZXZlciBwcmVzdW1hYmx5 IGNvcnJlY3QuKQ0KDQogICBBcyBJIGtub3cgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBpcyBkb25lLCB0aGlzIG1heSBhbHJlYWR5IGhhdmUgYmVlbiBjYXVnaHQsIGJ1dCBJJ2xsIHNh eSBpdCBpbiBjYXNlIG5vdC4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJp bmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAlMjgwJTI5 MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0 bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3 dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxIFJlZ2lzdGVy ZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3 WVANCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hv dWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9y IGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFu ZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QN Cm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zDQppbmZvcm1hdGlvbiBmcm9t IGlEaXJlY3QsIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeQ0KYW5kL29yIGNv bmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRp dmlkdWFsDQpvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBvcmlnaW5hbA0KcmVjaXBpZW50IG9yIHRoZSBwZXJzb24gcmVzcG9uc2libGUgZm9y IGRlbGl2ZXJpbmcgdGhlIGVtYWlsIHRvIHRoZQ0KaW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZp c2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbA0KaW4gZXJyb3IsIGFuZCB0aGF0 IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcg0KY29weWlu ZyBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0 aGlzIGVtYWlsDQppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90 aWZ5IHRoZSBzZW5kZXIuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA75BEGLKXM0002VGREEN_ 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 c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JbmRlZWQsIG5vIHRlcm0gaXMgcGVyZmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4N ClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZTxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJz cDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENo ZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0 ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTI7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz QThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+UmVnaXN0ZXJlZCBPZmZp Y2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBSYXRsaWZmLCBTdGFubGV5IFttYWlsdG86c3JhdGxpZmZAaWRpcmVjdC5uZXRdDQo8YnI+DQo8 Yj5TZW50OjwvYj4gMTkgT2N0b2JlciAyMDE1IDE0OjU5PGJyPg0KPGI+VG86PC9iPiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgU3RhbiBSYXRsaWZmPGJyPg0KPGI+Q2M6PC9iPiBtYW5ldEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW21hbmV0XSBETEVQPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRp bmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0 LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVy O2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRo ZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVm dWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRh Y2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZv cm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8 L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sNCiBvdXQgZm9yIGluIGVtYWls cyB5b3UgcmVjZWl2ZSwgY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0 ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxh Z3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91 IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0 dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3Rs aWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYi Pg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJl4oCZcyBhIGRv d25zaWRlIHRvIOKAmHJhZGlv4oCZIOKAkyBpdCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IERM RVAgaXMgbGltaXRlZCB0byAqPGI+b25seTwvYj4qIHJhZGlvLWJhc2VkIGltcGxlbWVudGF0aW9u cy4gSXTigJlzIG5vdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3RhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQgWzxhIGhyZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgT2N0b2JlciAxOSwgMjAxNSA5OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBTdGFuIFJhdGxpZmYg Jmx0OzxhIGhyZWY9Im1haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb20iPnJhdGxpZmZzdGFuQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0 Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0 XSBETEVQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SeKAmWQgc3VnZ2VzdCBhIHN0cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZvciByYWRp byBvdmVyIG1vZGVtLCB0aG91Z2ggb3BlbiB0byBhIGJldHRlciBzdWdnZXN0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIg RGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2U8YnI+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 Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyO3RleHQt ZGVjb3JhdGlvbjpub25lIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1p dGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJl Z2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXks IEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3RhbiBSYXRsaWZmIFs8YSBocmVmPSJtYWls dG86cmF0bGlmZnN0YW5AZ21haWwuY29tIj5tYWlsdG86cmF0bGlmZnN0YW5AZ21haWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOSBPY3RvYmVyIDIwMTUgMTQ6Mjk8YnI+DQo8Yj5Ubzo8 L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBSaWNrIFRheWxv cjsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gRExFUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3Jn YW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5l dC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi Pjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bh bj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3Nw YW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBp biBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVu dC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMv UmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVl bCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0cDov L2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0 cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+DQp0 aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgUmljayBoaXQgdGhlIG5h aWwgb24gdGhlIGhlYWQuIFdlIGluaXRpYWxseSB1c2VkIHRoZSB0ZXJtICZxdW90O3JhZGlvJnF1 b3Q7LCBidXQgY2hhbmdlZCBpdCB3aGVuIHdlIHJlYWxpemVkIHRoYXQgRExFUCAqY291bGQqIChi dXQgZG9lc24ndCBoYXZlIHRvKSBiZSB1c2VkIGluIGRldmljZXMgbGlrZSBjYWJsZSBtb2RlbXMu ICZxdW90O1JvdXRlciZxdW90OyBpcyBhbHNvIGEgZmFyIGZyb20gcGVyZmVjdCB0ZXJtIC0gSSdt IGN1cnJlbnRseQ0KIHdvcmtpbmcgb24gYW4gaW1wbGVtZW50YXRpb24gd2hlcmUgdGhlICZxdW90 O3JvdXRlciZxdW90OyBjb2RlIGFjdHVhbGx5IGxpdmVzIGluIGFuIGlEaXJlY3Qtc3BlY2lmaWMg YXBwbGljYXRpb24gaGF2aW5nIG5vdGhpbmcgdG8gZG8gd2l0aCByb3V0aW5nLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz LDxicj4NClN0YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIE9jdCAxOSwgMjAxNSBhdCA0OjMxIEFNLCBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGFrZSB0 aGUgcG9pbnQgYWJvdXQgcmFkaW8gYmVpbmcgaW1wZXJmZWN0LCBidXQgSSB0aGluayBpdCdzIHNp Z25pZmljYW50bHkgbGVzcyBpbXBlcmZlY3QgdGhhbiBtb2RlbS48YnI+DQo8YnI+DQpJIGNhbid0 IHRoaW5rIG9mIGFueXRoaW5nIGJldHRlciBteXNlbGYuPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+ DQpDaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+ DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KPGJyPg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAy NDIxOTQiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNwO3wgJm5ic3A7RTogPGEgaHJl Zj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj4NCmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5j b20vYWkiIHRhcmdldD0iX2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJy Pg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBSaWNrIFRheWxv ciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb20i PnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbTwvYT5dPGJyPg0KU2VudDogMTcgT2N0b2Jl ciAyMDE1IDExOjE2PGJyPg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyA8YSBocmVm PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6 IFJFOiBETEVQPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJv bSB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3Vs ZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4N CkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJz IGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMu PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBxdWljayByZXZpZXcgQ2hyaXMsPGJyPg0K PGJyPg0KQXMgZmFyIGFzIHRoZSB3aG9sZSAnbW9kZW0nIHZlcnN1cyAncmFkaW8nIHdvcmRpbmcg aXMgY29uY2VybmVkOiBJIHNoYXJlIHlvdXIgc2xpZ2h0IGRpc2NvbWZvcnQgd2l0aCB0aGUgd29y ZCAnbW9kZW0nLCBidXQgSSdtIG5vdCBzdXJlICdyYWRpbycgaXMgYW55IGJldHRlciEmbmJzcDsg Rm9yIGV4YW1wbGUsIEkgaGF2ZSBzb21lIHNjcnVmZnkgY29kZSB3aGljaCBwcmV0ZW5kcyB0byBi ZSBhIERMRVAgbW9kZW0gZm9yIERNVlBOIHR1bm5lbHMsIGFuZCB0aGVyZSdzDQogZGVmaW5pdGVs eSBubyByYWRpbyBpbnZvbHZlZC48YnI+DQo8YnI+DQpJJ20gZGVmaW5pdGVseSB3aWxsaW5nIHRv IGxpc3RlbiB0byBzdWdnZXN0aW9ucyBmcm9tIHRoZSBXRyBmb3Igd29yZHMgdG8gcmVwbGFjZSAn bW9kZW0nIHdpdGggYSB3b3JkIHRvIG1lYW4gJ2EgZGV2aWNlIHRoYXQgZm9yd2FyZHMgbGF5ZXIt MiBwYWNrZXRzIHRvIGl0cyBwZWVycywgaGFzIGxpbmsgc2Vuc2luZywgYW5kIGlzIGNvbW1vbmx5 IHNvbWUga2luZCBvZiByYWRpbycuJm5ic3A7IFdoZXRoZXIgd2UgbWFrZSB0aGUgY2hhbmdlIGRl cGVuZHMgZW50aXJlbHkNCiBvbiB3aGV0aGVyIHRoZSBXRyBoYXMgdGhlIHBhdGllbmNlLiA7KTxi cj4NCjxicj4NCkkgYmVsaWV2ZSAoSSBoYXZlbid0IGdvdCBkcmFmdC0xNyBvcGVuIGluIGZyb250 IG9mIG1lKSB0aGF0IHdlIGhhdmUgdGFja2xlZCBzb21lIG9mIHlvdXIgaXNzdWVzIHdpdGggdGhl IFJGQyA1MjI2IHRlcm1pbm9sb2d5IGluIDE3IGFzIHdlbGwsIHVzaW5nICdQcml2YXRlIFVzZScg aW5zdGVhZCBvZiAnUmVzZXJ2ZWQnIHdoZW4gYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KQ2hlZXJz LDxicj4NClJpY2s8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IG1hbmV0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmci Pm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlz dG9waGVyIChVSyk8YnI+DQpTZW50OiAxNSBPY3RvYmVyIDIwMTUgMTA6MjI8YnI+DQpUbzogPGEg aHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0OiBbbWFuZXRdIERMRVA8YnI+DQo8YnI+DQpJJ3ZlIHJlYWQgRExFUCBkcmFmdCAxNiwgYnV0 IG5vdCBzbyBmYXIgd2l0aCBhIGNyaXRpY2FsIGV5ZSB0byBzcGVjaWZpYyByZXZpZXcgY29tbWVu dHMgLSBvdGhlciB0aGFuIHRoYXQgdGhlIElBTkEgc2VjdGlvbiBpc24ndCB3aGF0J3MgbmVlZGVk IChidXQgdGhlIGF1dGhvcnMgYWxyZWFkeSBrbm93IHRoYXQgYW5kIEkgdW5kZXJzdGFuZCBoYXZl IGFscmVhZHkgd3JpdHRlbiBhIHJlcGxhY2VtZW50KSBhbmQgYSBmZXcgZWRpdG9yaWFsIGNvbW1l bnRzDQogSSdsbCBtYWtlIGJlbG93LiBJbiBwYXJ0aWN1bGFyIEkgaGF2ZW4ndCBmb3JtZWQgYSB2 aWV3IG9uIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIC0gYnV0IEkgbWF5IHdh aXQgZm9yIHRoaXMgYW5kIG1vc3Qgb3RoZXIgcG9pbnRzIHRvIHNlZSAtMTcgd2hpY2ggSSB1bmRl cnN0YW5kIGlzIG1vc3RseSB3cml0dGVuLjxicj4NCjxicj4NCk15IG1pbm9yIHBvaW50czo8YnI+ DQo8YnI+DQotIEkgcmVhbGx5IHdvdWxkIHByZWZlciAmcXVvdDtyYWRpbyZxdW90OyB0byAmcXVv dDttb2RlbSZxdW90OyB0aHJvdWdob3V0LiBBcyBzb21lb25lIHdobyBvbmNlIHdyb3RlIHNvbWUg bW9kZW0gc29mdHdhcmUsIGZvciBtZSBtb2RlbSBpcyB3aGF0IGl0IHNheXMsIG1vZHVsYXRpb24g YW5kIGRlbW9kdWxhdGlvbiAoYW5kIHRoZSBpbnNlcGFyYWJsZSBjaGFubmVsIGNvZGluZyksIGku ZS4gY29udmVydGluZyBiZXR3ZWVuIGJpdCBzdHJlYW1zIGFuZCBtb2R1bGF0ZWQgc2lnbmFscyAo Zm9yDQogYSBkaWdpdGFsIHJhZGlvKS5UaGVyZSBhcmUgbWFueSBwYXJ0cyBvZiBhIHJhZGlvIHRo YXQgYXJlIG91dHNpZGUgdGhhdCwgYW5kIGV2ZXJ5dGhpbmcgRExFUCBpcyBvdXRzaWRlIHRoZSBt b2RlbS48YnI+DQo8YnI+DQotIFdoZXJlIHRoZXJlIGFyZSB2YXJpb3VzIHRpbWUgYW5kIG90aGVy IHZhbHVlcyAodGltZW91dHMsIHJlcGVhdCBwZXJpb2RzLCBudW1iZXIgb2YgcmV0cmllcykgSSdk IHVzZSBhIHN5bWJvbGljIG5hbWUgYW5kIGNvbGxlY3Qgc3VnZ2VzdGVkIGRlZmF1bHQgdmFsdWVz IGluIG9uZSBwbGFjZS4gVGhhdCBpcyBhZnRlciBhbGwsIGFzIHdlIGFsbCB3cml0ZSBzb2Z0d2Fy ZS48YnI+DQo8YnI+DQotIEN1cnJlbnRseSBkZXNjcmliZXMgc29tZSBjb2RlIHBvaW50cyBhcyAm cXVvdDtSZXNlcnZlZCBmb3IgZnV0dXJlIGV4dGVuc2lvbnMmcXVvdDsuIFRoaXMgaXMgbm90IHRo ZSBjb3JyZWN0IHRlcm1pbm9sb2d5LiBGcm9tIFJGQyA1MjI2Ojxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IFJlc2VydmVkOiZuYnNwOyBOb3QgdG8gYmUgYXNzaWduZWQuJm5ic3A7IFJl c2VydmVkIHZhbHVlcyBhcmUgaGVsZCBmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMgdG8gZXh0ZW5kIHRoZSBuYW1l c3BhY2Ugd2hlbiBpdCBiZWNvbWU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBleGhhdXN0ZWQuJm5ic3A7IFJlc2VydmVkIHZhbHVlcyBhcmUgbm90IGF2YWls YWJsZSBmb3IgZ2VuZXJhbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGFzc2lnbm1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAoVGhlIFJlc2VydmVk IGZvciAwIGFuZCA2NTUzNSBpcyBob3dldmVyIHByZXN1bWFibHkgY29ycmVjdC4pPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwO0FzIEkga25vdyB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u IGlzIGRvbmUsIHRoaXMgbWF5IGFscmVhZHkgaGF2ZSBiZWVuIGNhdWdodCwgYnV0IEknbGwgc2F5 IGl0IGluIGNhc2Ugbm90Ljxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3BoZXIgRGVhcmxvdmU8 YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2U8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NClQ6ICZuYnNwOzxh IGhyZWY9InRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0Ij4mIzQzOzQ0ICgwKTEyNDUg MjQyMTk0PC9hPiAmbmJzcDt8ICZuYnNwO0U6IDxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbSI+DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+ DQo8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNo bm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+ DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+ d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9hPjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlIExpbWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMz NzQ1MSBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwg U3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpU aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3Rl bSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvciBkaXN0cmlidXRlIGl0cyBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDMzNjYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zPGJyPg0KaW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0 LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnk8YnI+DQphbmQvb3IgY29uZmlk ZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWw8YnI+DQpvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBvcmlnaW5hbDxicj4NCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxl IGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGU8YnI+DQppbnRlbmRlZCByZWNpcGllbnQs IGJlIGFkdmlzZWQgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsPGJyPg0KaW4gZXJy b3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5n LCBvcjxicj4NCmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ ZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbDxicj4NCmluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0 IGFuZCBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA75BEGLKXM0002VGREEN_-- From nobody Mon Oct 19 07:15:16 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034031A7020 for ; Mon, 19 Oct 2015 07:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7vxfeS033J6 for ; Mon, 19 Oct 2015 07:15:05 -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 581141A6FAC for ; Mon, 19 Oct 2015 07:15:05 -0700 (PDT) Received: from rosout.astrium.eads.net ([10.222.0.6]) by isabel.astrium.eads.net (8.14.4/8.14.4) with ESMTP id t9JEF0AQ015564; Mon, 19 Oct 2015 15:15:00 +0100 Received: from rosout.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3AF62208133; Mon, 19 Oct 2015 15:15:00 +0100 (BST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 23E60208293; Mon, 19 Oct 2015 15:15:00 +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 F07CF208133; Mon, 19 Oct 2015 15:14:50 +0100 (BST) Received: from AUK52715.UKN.UKNROOT.ASTRIUM.CORP ([fe80::70c5:d8f8:7a03:bd48]) by AUK52840.UKN.UKNROOT.ASTRIUM.CORP ([fe80::7584:4b98:38c0:4ce7%15]) with mapi id 14.03.0123.003; Mon, 19 Oct 2015 15:14:51 +0100 From: "MATTY, Steven" To: "'Dearlove, Christopher (UK)'" , "Stan Ratliff" Thread-Topic: [manet] DLEP Thread-Index: AdEHJ5wNz9Z2rnFy2UuzC21ioDuhoQBm9nRwAGEtIrAACGKTgAAC9zKAAACGDKA= Date: Mon, 19 Oct 2015 14:14:49 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> <6396_1445262874_5624F619_6396_2843_4_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595@GLKXM0002V.GREENLNK.net> In-Reply-To: <6396_1445262874_5624F619_6396_2843_4_B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAA7595@GLKXM0002V.GREENLNK.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.1383-8.0.0.1202-21890.000 X-TM-AS-Result: No--40.512-5.0-31-10 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_D9712B947A4CCA43AB42F01B90AF1DEC010FD34B53AUK52715UKNUK_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-imss-scan-details: No--40.512-5.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1383-8.0.1202-21890.000 X-TMASE-Result: 10--40.511800-5.000000 X-TMASE-MatchedRID: Z/tjqhsgM6cs3eJUt5qL1QNcJqf1+q/l0MPAZcVGQYu5L/GPeV4Yf/vA DvTnCf5vpjnmJgKhwtGgOwyC+HWFxRVp5VqT3KoY2eLvbayjHBDXDN74BR4+fFd9anLxZbwbUyl SIDEm+MdtuhCTvk2wOC1bKLdhloRJUlLRvzP/1ME1g2myLVBpERQatTXEjbeoTLWmVXrWsAvC+o 4YGuB7e3KcSFbBuz03xJ6ERKC4/9kIBKAnrWweqpm4LRSW7HomdamgeAZIZ5YyDIdIGryMaLxyg pRxo469k4FdoXhNFg3K99fyOVK2z4I7s5f4WtvNkl659xZzPxKAeW8GqBpFrkL2oRfsBIKxaK+M sTwM+1mVq+okl1rYDy2g4quVMWelLyQlyBhWI1PFM89JC+U/uVWNuEl0eLMsDsB+KQ9eA7DcWo5 Vvs8MQstcv4yLqGWeAVscD1Oo0tALCBQ+Nxxn8GZutr4ZuQnxmSyn9Pn5/GwYGe03I+tEG7420L FuMF+GQV6BZJ9WeFbSYAzZ6KmqWpg6TMV9/2vqRl0I57OsmtQ/mODo4d3yUYdM1kFwmWfIbD4iY fbCo2NQCOsAlaxN75gWnaLDiGghMyviVP1W1mQbRC9Cl9SDU5cWIhbuuvyj4s8Dsu/oDtiJQ9k+ Ypk5CfZpw431D6uekzE2kM4b6HqziXnYnnGhTVPKCkpgbBHVyRHuydhXzgwR8hZMqdJm+Qz4VsC c1YW+viRliDV2nyw3DLgNZ/WB37uvq/IDqF/O9Xd525Ajg0E1DOIF+HNIOFwiNkCSQ5LISDkh6b W+bcchwKIIdklOV7ll2qmkY+3i/ZLQhRYz+G3i8zVgXoAltuoKEDqVJEm+0u+wqOGzSV0TKUvkO TsTXnsq4KNO+lkkIrKPqPr62uMgBwKKRHe+r8CpZgCbbOVTISZ4XfeWZaVbP00GsG6eVUkJUbCu ZIXxhi9k5KJdOJs= X-TMASE-SNAP-Result: 1.801202.0001-0-1-22:0,12:0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:15:15 -0000 --_000_D9712B947A4CCA43AB42F01B90AF1DEC010FD34B53AUK52715UKNUK_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V04oCmDQoNClJhZGlvIC8gTW9kZW0gPSBEYXRhIENvbW11bmljYXRpb25zIEVxdWlw bWVudCAoRENFKQ0KUm91dGVyIC8gVGhpbmcgV2l0aCBBbiBJbnRlcmVzdCBJbiBNZXRyaWNzID0g RGF0YSBUZXJtaW5hdGluZyBFcXVpcG1lbnQgKERURSkNCg0KRnJvbTogbWFuZXQgW21haWx0bzpt YW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlzdG9waGVy IChVSykNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAxNSAyOjU0IFBNDQpUbzogU3RhbiBS YXRsaWZmDQpDYzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVANCg0K SeKAmWQgc3VnZ2VzdCBhIHN0cmF3IHBvbGwuIFB1dCBtZSBkb3duIGZvciByYWRpbyBvdmVyIG1v ZGVtLCB0aG91Z2ggb3BlbiB0byBhIGJldHRlciBzdWdnZXN0aW9uLg0KDQotLQ0KQ2hyaXN0b3Bo ZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQy MTk0ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl LCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBF c3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVt cy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdp c3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNl OiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpG cm9tOiBTdGFuIFJhdGxpZmYgW21haWx0bzpyYXRsaWZmc3RhbkBnbWFpbC5jb21dDQpTZW50OiAx OSBPY3RvYmVyIDIwMTUgMTQ6MjkNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6 IFJpY2sgVGF5bG9yOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gRExFUA0K DQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhl IGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFp bHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1z LmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3Mu cGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93 IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29y ay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lv dXMlMjBFbWFpbHMucGRmPi4NCkFsbCwNCg0KSSB0aGluayBSaWNrIGhpdCB0aGUgbmFpbCBvbiB0 aGUgaGVhZC4gV2UgaW5pdGlhbGx5IHVzZWQgdGhlIHRlcm0gInJhZGlvIiwgYnV0IGNoYW5nZWQg aXQgd2hlbiB3ZSByZWFsaXplZCB0aGF0IERMRVAgKmNvdWxkKiAoYnV0IGRvZXNuJ3QgaGF2ZSB0 bykgYmUgdXNlZCBpbiBkZXZpY2VzIGxpa2UgY2FibGUgbW9kZW1zLiAiUm91dGVyIiBpcyBhbHNv IGEgZmFyIGZyb20gcGVyZmVjdCB0ZXJtIC0gSSdtIGN1cnJlbnRseSB3b3JraW5nIG9uIGFuIGlt cGxlbWVudGF0aW9uIHdoZXJlIHRoZSAicm91dGVyIiBjb2RlIGFjdHVhbGx5IGxpdmVzIGluIGFu IGlEaXJlY3Qtc3BlY2lmaWMgYXBwbGljYXRpb24gaGF2aW5nIG5vdGhpbmcgdG8gZG8gd2l0aCBy b3V0aW5nLg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQoNCk9uIE1vbiwgT2N0IDE5LCAyMDE1IGF0IDQ6 MzEgQU0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToNCkkg dGFrZSB0aGUgcG9pbnQgYWJvdXQgcmFkaW8gYmVpbmcgaW1wZXJmZWN0LCBidXQgSSB0aGluayBp dCdzIHNpZ25pZmljYW50bHkgbGVzcyBpbXBlcmZlY3QgdGhhbiBtb2RlbS4NCg0KSSBjYW4ndCB0 aGluayBvZiBhbnl0aGluZyBiZXR0ZXIgbXlzZWxmLg0KDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFy bG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVs OiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBT eXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywg R3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMu Y29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzog MDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRm b3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUmljayBUYXlsb3IgW21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb208bWFp bHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbT5dDQpTZW50OiAxNyBPY3RvYmVyIDIw MTUgMTE6MTYNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KU3ViamVjdDogUkU6IERMRVANCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdl IG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFu IGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxp bmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3Vz IGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmV2aWV3IENocmlzLA0K DQpBcyBmYXIgYXMgdGhlIHdob2xlICdtb2RlbScgdmVyc3VzICdyYWRpbycgd29yZGluZyBpcyBj b25jZXJuZWQ6IEkgc2hhcmUgeW91ciBzbGlnaHQgZGlzY29tZm9ydCB3aXRoIHRoZSB3b3JkICdt b2RlbScsIGJ1dCBJJ20gbm90IHN1cmUgJ3JhZGlvJyBpcyBhbnkgYmV0dGVyISAgRm9yIGV4YW1w bGUsIEkgaGF2ZSBzb21lIHNjcnVmZnkgY29kZSB3aGljaCBwcmV0ZW5kcyB0byBiZSBhIERMRVAg bW9kZW0gZm9yIERNVlBOIHR1bm5lbHMsIGFuZCB0aGVyZSdzIGRlZmluaXRlbHkgbm8gcmFkaW8g aW52b2x2ZWQuDQoNCkknbSBkZWZpbml0ZWx5IHdpbGxpbmcgdG8gbGlzdGVuIHRvIHN1Z2dlc3Rp b25zIGZyb20gdGhlIFdHIGZvciB3b3JkcyB0byByZXBsYWNlICdtb2RlbScgd2l0aCBhIHdvcmQg dG8gbWVhbiAnYSBkZXZpY2UgdGhhdCBmb3J3YXJkcyBsYXllci0yIHBhY2tldHMgdG8gaXRzIHBl ZXJzLCBoYXMgbGluayBzZW5zaW5nLCBhbmQgaXMgY29tbW9ubHkgc29tZSBraW5kIG9mIHJhZGlv Jy4gIFdoZXRoZXIgd2UgbWFrZSB0aGUgY2hhbmdlIGRlcGVuZHMgZW50aXJlbHkgb24gd2hldGhl ciB0aGUgV0cgaGFzIHRoZSBwYXRpZW5jZS4gOykNCg0KSSBiZWxpZXZlIChJIGhhdmVuJ3QgZ290 IGRyYWZ0LTE3IG9wZW4gaW4gZnJvbnQgb2YgbWUpIHRoYXQgd2UgaGF2ZSB0YWNrbGVkIHNvbWUg b2YgeW91ciBpc3N1ZXMgd2l0aCB0aGUgUkZDIDUyMjYgdGVybWlub2xvZ3kgaW4gMTcgYXMgd2Vs bCwgdXNpbmcgJ1ByaXZhdGUgVXNlJyBpbnN0ZWFkIG9mICdSZXNlcnZlZCcgd2hlbiBhcHByb3By aWF0ZS4NCg0KQ2hlZXJzLA0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpT ZW50OiAxNSBPY3RvYmVyIDIwMTUgMTA6MjINClRvOiBtYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFu ZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbWFuZXRdIERMRVANCg0KSSd2ZSByZWFkIERMRVAgZHJh ZnQgMTYsIGJ1dCBub3Qgc28gZmFyIHdpdGggYSBjcml0aWNhbCBleWUgdG8gc3BlY2lmaWMgcmV2 aWV3IGNvbW1lbnRzIC0gb3RoZXIgdGhhbiB0aGF0IHRoZSBJQU5BIHNlY3Rpb24gaXNuJ3Qgd2hh dCdzIG5lZWRlZCAoYnV0IHRoZSBhdXRob3JzIGFscmVhZHkga25vdyB0aGF0IGFuZCBJIHVuZGVy c3RhbmQgaGF2ZSBhbHJlYWR5IHdyaXR0ZW4gYSByZXBsYWNlbWVudCkgYW5kIGEgZmV3IGVkaXRv cmlhbCBjb21tZW50cyBJJ2xsIG1ha2UgYmVsb3cuIEluIHBhcnRpY3VsYXIgSSBoYXZlbid0IGZv cm1lZCBhIHZpZXcgb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gLSBidXQg SSBtYXkgd2FpdCBmb3IgdGhpcyBhbmQgbW9zdCBvdGhlciBwb2ludHMgdG8gc2VlIC0xNyB3aGlj aCBJIHVuZGVyc3RhbmQgaXMgbW9zdGx5IHdyaXR0ZW4uDQoNCk15IG1pbm9yIHBvaW50czoNCg0K LSBJIHJlYWxseSB3b3VsZCBwcmVmZXIgInJhZGlvIiB0byAibW9kZW0iIHRocm91Z2hvdXQuIEFz IHNvbWVvbmUgd2hvIG9uY2Ugd3JvdGUgc29tZSBtb2RlbSBzb2Z0d2FyZSwgZm9yIG1lIG1vZGVt IGlzIHdoYXQgaXQgc2F5cywgbW9kdWxhdGlvbiBhbmQgZGVtb2R1bGF0aW9uIChhbmQgdGhlIGlu c2VwYXJhYmxlIGNoYW5uZWwgY29kaW5nKSwgaS5lLiBjb252ZXJ0aW5nIGJldHdlZW4gYml0IHN0 cmVhbXMgYW5kIG1vZHVsYXRlZCBzaWduYWxzIChmb3IgYSBkaWdpdGFsIHJhZGlvKS5UaGVyZSBh cmUgbWFueSBwYXJ0cyBvZiBhIHJhZGlvIHRoYXQgYXJlIG91dHNpZGUgdGhhdCwgYW5kIGV2ZXJ5 dGhpbmcgRExFUCBpcyBvdXRzaWRlIHRoZSBtb2RlbS4NCg0KLSBXaGVyZSB0aGVyZSBhcmUgdmFy aW91cyB0aW1lIGFuZCBvdGhlciB2YWx1ZXMgKHRpbWVvdXRzLCByZXBlYXQgcGVyaW9kcywgbnVt YmVyIG9mIHJldHJpZXMpIEknZCB1c2UgYSBzeW1ib2xpYyBuYW1lIGFuZCBjb2xsZWN0IHN1Z2dl c3RlZCBkZWZhdWx0IHZhbHVlcyBpbiBvbmUgcGxhY2UuIFRoYXQgaXMgYWZ0ZXIgYWxsLCBhcyB3 ZSBhbGwgd3JpdGUgc29mdHdhcmUuDQoNCi0gQ3VycmVudGx5IGRlc2NyaWJlcyBzb21lIGNvZGUg cG9pbnRzIGFzICJSZXNlcnZlZCBmb3IgZnV0dXJlIGV4dGVuc2lvbnMiLiBUaGlzIGlzIG5vdCB0 aGUgY29ycmVjdCB0ZXJtaW5vbG9neS4gRnJvbSBSRkMgNTIyNjoNCg0KICAgICAgUmVzZXJ2ZWQ6 ICBOb3QgdG8gYmUgYXNzaWduZWQuICBSZXNlcnZlZCB2YWx1ZXMgYXJlIGhlbGQgZm9yDQogICAg ICAgICAgICBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMgdG8gZXh0ZW5kIHRoZSBuYW1lc3BhY2Ugd2hl biBpdCBiZWNvbWUNCiAgICAgICAgICAgIGV4aGF1c3RlZC4gIFJlc2VydmVkIHZhbHVlcyBhcmUg bm90IGF2YWlsYWJsZSBmb3IgZ2VuZXJhbA0KICAgICAgICAgICAgYXNzaWdubWVudC4NCg0KICAg IChUaGUgUmVzZXJ2ZWQgZm9yIDAgYW5kIDY1NTM1IGlzIGhvd2V2ZXIgcHJlc3VtYWJseSBjb3Jy ZWN0LikNCg0KICAgQXMgSSBrbm93IHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMg ZG9uZSwgdGhpcyBtYXkgYWxyZWFkeSBoYXZlIGJlZW4gY2F1Z2h0LCBidXQgSSdsbCBzYXkgaXQg aW4gY2FzZSBub3QuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUl MjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxs aWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNm b3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFl c3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVk IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MSBSZWdpc3RlcmVkIE9m ZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoN Cg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBwbGVhc2UgZGVsZXRl IGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBu b3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvciBkaXN0 cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1h aWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5l dEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg0KVGhpcyBlbWFpbCAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIG9yIGluZm9ybWF0aW9uIG90aGVyd2lzZSBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJl LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRvIG5vdCBjb3B5IHRoaXMgbWVzc2FnZSBvciBhbnkgYXR0 YWNobWVudHMgYW5kIGRvIG5vdCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG9yIGRpc2Nsb3NlIGl0 cyBjb250ZW50IHRvIGFueSBwZXJzb24sIGJ1dCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkg YXR0YWNobWVudHMgZnJvbSB5b3VyIHN5c3RlbS4gQWlyYnVzIERlZmVuY2UgYW5kIFNwYWNlIExp bWl0ZWQgZGlzY2xhaW1zIGFueSBhbmQgYWxsIGxpYWJpbGl0eSBpZiB0aGlzIGVtYWlsIHRyYW5z bWlzc2lvbiB3YXMgdmlydXMgY29ycnVwdGVkLCBhbHRlcmVkIG9yIGZhbHNpZmllZC4NCi1vLQ0K RW1haWxzIHRvIEFpcmJ1cyBEZWZlbmNlIGFuZCBTcGFjZSBMaW1pdGVkIG1heSBiZSBwcm9jZXNz ZWQsIHJlY29yZGVkIGFuZCBtb25pdG9yZWQgb3V0c2lkZSB0aGUgVUsuDQotby0NCkFpcmJ1cyBE ZWZlbmNlIGFuZCBTcGFjZSBMaW1pdGVkLCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVz IE5vLiAyNDQ5MjU5DQpSZWdpc3RlcmVkIE9mZmljZTogR3VubmVscyBXb29kIFJvYWQsIFN0ZXZl bmFnZSwgSGVydGZvcmRzaGlyZSwgU0cxIDJBUywgRW5nbGFuZA== --_000_D9712B947A4CCA43AB42F01B90AF1DEC010FD34B53AUK52715UKNUK_ 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 c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhvdyBhYm91dOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFkaW8gLyBNb2RlbSA9IERhdGEg Q29tbXVuaWNhdGlvbnMgRXF1aXBtZW50IChEQ0UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJvdXRlciAvIFRoaW5nIFdpdGggQW4gSW50ZXJlc3QgSW4gTWV0cmljcyA9IERhdGEgVGVy bWluYXRpbmcgRXF1aXBtZW50IChEVEUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbWFuZXQgW21haWx0bzptYW5l dC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EZWFybG92ZSwgQ2hyaXN0 b3BoZXIgKFVLKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMTksIDIwMTUgMjo1 NCBQTTxicj4NCjxiPlRvOjwvYj4gU3RhbiBSYXRsaWZmPGJyPg0KPGI+Q2M6PC9iPiBtYW5ldEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBETEVQPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlkIHN1Z2dlc3QgYSBzdHJhdyBwb2xsLiBQdXQgbWUg ZG93biBmb3IgcmFkaW8gb3ZlciBtb2RlbSwgdGhvdWdoIG9wZW4gdG8gYSBiZXR0ZXIgc3VnZ2Vz dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui PkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlPGJyPg0KPC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsm IzQzOzQ0ICgwKTEyNDUgMjQyMTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJt YWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4 QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9s b2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8 YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6 IzNBOEI5Mjt0ZXh0LWRlY29yYXRpb246bm9uZSI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBO bzogMDEzMzc0NTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxk Zm9yZCwgU3VycmV5LCBHVTIgN1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN0YW4gUmF0bGlmZiBb bWFpbHRvOnJhdGxpZmZzdGFuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxOSBPY3Rv YmVyIDIwMTUgMTQ6Mjk8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp PGJyPg0KPGI+Q2M6PC9iPiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFttYW5ldF0gRExFUDxvOnA+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 dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgUmljayBoaXQgdGhlIG5haWwgb24gdGhl IGhlYWQuIFdlIGluaXRpYWxseSB1c2VkIHRoZSB0ZXJtICZxdW90O3JhZGlvJnF1b3Q7LCBidXQg Y2hhbmdlZCBpdCB3aGVuIHdlIHJlYWxpemVkIHRoYXQgRExFUCAqY291bGQqIChidXQgZG9lc24n dCBoYXZlIHRvKSBiZSB1c2VkIGluIGRldmljZXMgbGlrZSBjYWJsZSBtb2RlbXMuICZxdW90O1Jv dXRlciZxdW90OyBpcyBhbHNvIGEgZmFyIGZyb20gcGVyZmVjdCB0ZXJtIC0gSSdtIGN1cnJlbnRs eQ0KIHdvcmtpbmcgb24gYW4gaW1wbGVtZW50YXRpb24gd2hlcmUgdGhlICZxdW90O3JvdXRlciZx dW90OyBjb2RlIGFjdHVhbGx5IGxpdmVzIGluIGFuIGlEaXJlY3Qtc3BlY2lmaWMgYXBwbGljYXRp b24gaGF2aW5nIG5vdGhpbmcgdG8gZG8gd2l0aCByb3V0aW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxicj4NClN0 YW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIE9jdCAxOSwgMjAxNSBhdCA0OjMxIEFNLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIg KFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGFrZSB0aGUgcG9pbnQg YWJvdXQgcmFkaW8gYmVpbmcgaW1wZXJmZWN0LCBidXQgSSB0aGluayBpdCdzIHNpZ25pZmljYW50 bHkgbGVzcyBpbXBlcmZlY3QgdGhhbiBtb2RlbS48YnI+DQo8YnI+DQpJIGNhbid0IHRoaW5rIG9m IGFueXRoaW5nIGJldHRlciBteXNlbGYuPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpDaHJpc3Rv cGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJy Pg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiPiYj NDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+ICZuYnNwO3wgJm5ic3A7RTogPGEgaHJlZj0ibWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj4NCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3Rl bXMuY29tPC9hPjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBD aGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl eCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRh cmdldD0iX2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAm YW1wOyBXYWxlcyBObzogMDEzMzc0NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJl c2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KPGJyPg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBSaWNrIFRheWxvciBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb20iPnJpY2tAdHJv cGljYWxzdG9ybXNvZnR3YXJlLmNvbTwvYT5dPGJyPg0KU2VudDogMTcgT2N0b2JlciAyMDE1IDEx OjE2PGJyPg0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyA8YSBocmVmPSJtYWlsdG86 bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJFOiBETEVQ PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdh bmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50 ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBv biBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljxicj4NCkZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0 cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuPGJyPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBxdWljayByZXZpZXcgQ2hyaXMsPGJyPg0KPGJyPg0KQXMg ZmFyIGFzIHRoZSB3aG9sZSAnbW9kZW0nIHZlcnN1cyAncmFkaW8nIHdvcmRpbmcgaXMgY29uY2Vy bmVkOiBJIHNoYXJlIHlvdXIgc2xpZ2h0IGRpc2NvbWZvcnQgd2l0aCB0aGUgd29yZCAnbW9kZW0n LCBidXQgSSdtIG5vdCBzdXJlICdyYWRpbycgaXMgYW55IGJldHRlciEmbmJzcDsgRm9yIGV4YW1w bGUsIEkgaGF2ZSBzb21lIHNjcnVmZnkgY29kZSB3aGljaCBwcmV0ZW5kcyB0byBiZSBhIERMRVAg bW9kZW0gZm9yIERNVlBOIHR1bm5lbHMsIGFuZCB0aGVyZSdzDQogZGVmaW5pdGVseSBubyByYWRp byBpbnZvbHZlZC48YnI+DQo8YnI+DQpJJ20gZGVmaW5pdGVseSB3aWxsaW5nIHRvIGxpc3RlbiB0 byBzdWdnZXN0aW9ucyBmcm9tIHRoZSBXRyBmb3Igd29yZHMgdG8gcmVwbGFjZSAnbW9kZW0nIHdp dGggYSB3b3JkIHRvIG1lYW4gJ2EgZGV2aWNlIHRoYXQgZm9yd2FyZHMgbGF5ZXItMiBwYWNrZXRz IHRvIGl0cyBwZWVycywgaGFzIGxpbmsgc2Vuc2luZywgYW5kIGlzIGNvbW1vbmx5IHNvbWUga2lu ZCBvZiByYWRpbycuJm5ic3A7IFdoZXRoZXIgd2UgbWFrZSB0aGUgY2hhbmdlIGRlcGVuZHMgZW50 aXJlbHkNCiBvbiB3aGV0aGVyIHRoZSBXRyBoYXMgdGhlIHBhdGllbmNlLiA7KTxicj4NCjxicj4N CkkgYmVsaWV2ZSAoSSBoYXZlbid0IGdvdCBkcmFmdC0xNyBvcGVuIGluIGZyb250IG9mIG1lKSB0 aGF0IHdlIGhhdmUgdGFja2xlZCBzb21lIG9mIHlvdXIgaXNzdWVzIHdpdGggdGhlIFJGQyA1MjI2 IHRlcm1pbm9sb2d5IGluIDE3IGFzIHdlbGwsIHVzaW5nICdQcml2YXRlIFVzZScgaW5zdGVhZCBv ZiAnUmVzZXJ2ZWQnIHdoZW4gYXBwcm9wcmlhdGUuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NClJp Y2s8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IG1hbmV0 IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmciPm1hbmV0LWJv dW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRGVhcmxvdmUsIENocmlzdG9waGVyIChV Syk8YnI+DQpTZW50OiAxNSBPY3RvYmVyIDIwMTUgMTA6MjI8YnI+DQpUbzogPGEgaHJlZj0ibWFp bHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbbWFu ZXRdIERMRVA8YnI+DQo8YnI+DQpJJ3ZlIHJlYWQgRExFUCBkcmFmdCAxNiwgYnV0IG5vdCBzbyBm YXIgd2l0aCBhIGNyaXRpY2FsIGV5ZSB0byBzcGVjaWZpYyByZXZpZXcgY29tbWVudHMgLSBvdGhl ciB0aGFuIHRoYXQgdGhlIElBTkEgc2VjdGlvbiBpc24ndCB3aGF0J3MgbmVlZGVkIChidXQgdGhl IGF1dGhvcnMgYWxyZWFkeSBrbm93IHRoYXQgYW5kIEkgdW5kZXJzdGFuZCBoYXZlIGFscmVhZHkg d3JpdHRlbiBhIHJlcGxhY2VtZW50KSBhbmQgYSBmZXcgZWRpdG9yaWFsIGNvbW1lbnRzDQogSSds bCBtYWtlIGJlbG93LiBJbiBwYXJ0aWN1bGFyIEkgaGF2ZW4ndCBmb3JtZWQgYSB2aWV3IG9uIHRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIC0gYnV0IEkgbWF5IHdhaXQgZm9yIHRo aXMgYW5kIG1vc3Qgb3RoZXIgcG9pbnRzIHRvIHNlZSAtMTcgd2hpY2ggSSB1bmRlcnN0YW5kIGlz IG1vc3RseSB3cml0dGVuLjxicj4NCjxicj4NCk15IG1pbm9yIHBvaW50czo8YnI+DQo8YnI+DQot IEkgcmVhbGx5IHdvdWxkIHByZWZlciAmcXVvdDtyYWRpbyZxdW90OyB0byAmcXVvdDttb2RlbSZx dW90OyB0aHJvdWdob3V0LiBBcyBzb21lb25lIHdobyBvbmNlIHdyb3RlIHNvbWUgbW9kZW0gc29m dHdhcmUsIGZvciBtZSBtb2RlbSBpcyB3aGF0IGl0IHNheXMsIG1vZHVsYXRpb24gYW5kIGRlbW9k dWxhdGlvbiAoYW5kIHRoZSBpbnNlcGFyYWJsZSBjaGFubmVsIGNvZGluZyksIGkuZS4gY29udmVy dGluZyBiZXR3ZWVuIGJpdCBzdHJlYW1zIGFuZCBtb2R1bGF0ZWQgc2lnbmFscyAoZm9yDQogYSBk aWdpdGFsIHJhZGlvKS5UaGVyZSBhcmUgbWFueSBwYXJ0cyBvZiBhIHJhZGlvIHRoYXQgYXJlIG91 dHNpZGUgdGhhdCwgYW5kIGV2ZXJ5dGhpbmcgRExFUCBpcyBvdXRzaWRlIHRoZSBtb2RlbS48YnI+ DQo8YnI+DQotIFdoZXJlIHRoZXJlIGFyZSB2YXJpb3VzIHRpbWUgYW5kIG90aGVyIHZhbHVlcyAo dGltZW91dHMsIHJlcGVhdCBwZXJpb2RzLCBudW1iZXIgb2YgcmV0cmllcykgSSdkIHVzZSBhIHN5 bWJvbGljIG5hbWUgYW5kIGNvbGxlY3Qgc3VnZ2VzdGVkIGRlZmF1bHQgdmFsdWVzIGluIG9uZSBw bGFjZS4gVGhhdCBpcyBhZnRlciBhbGwsIGFzIHdlIGFsbCB3cml0ZSBzb2Z0d2FyZS48YnI+DQo8 YnI+DQotIEN1cnJlbnRseSBkZXNjcmliZXMgc29tZSBjb2RlIHBvaW50cyBhcyAmcXVvdDtSZXNl cnZlZCBmb3IgZnV0dXJlIGV4dGVuc2lvbnMmcXVvdDsuIFRoaXMgaXMgbm90IHRoZSBjb3JyZWN0 IHRlcm1pbm9sb2d5LiBGcm9tIFJGQyA1MjI2Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IFJlc2VydmVkOiZuYnNwOyBOb3QgdG8gYmUgYXNzaWduZWQuJm5ic3A7IFJlc2VydmVkIHZh bHVlcyBhcmUgaGVsZCBmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBzcGVjaWFsIHVzZXMsIHN1Y2ggYXMgdG8gZXh0ZW5kIHRoZSBuYW1lc3BhY2Ugd2hl biBpdCBiZWNvbWU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBleGhhdXN0ZWQuJm5ic3A7IFJlc2VydmVkIHZhbHVlcyBhcmUgbm90IGF2YWlsYWJsZSBmb3Ig Z2VuZXJhbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFz c2lnbm1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAoVGhlIFJlc2VydmVkIGZvciAwIGFu ZCA2NTUzNSBpcyBob3dldmVyIHByZXN1bWFibHkgY29ycmVjdC4pPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwO0FzIEkga25vdyB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIGRvbmUs IHRoaXMgbWF5IGFscmVhZHkgaGF2ZSBiZWVuIGNhdWdodCwgYnV0IEknbGwgc2F5IGl0IGluIGNh c2Ugbm90Ljxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5p b3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2U8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NClQ6ICZuYnNwOzxhIGhyZWY9InRl bDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0Ij4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9h PiAmbmJzcDt8ICZuYnNwO0U6IDxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbSI+DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8YnI+DQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBh cmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVm PSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmJhZXN5 c3RlbXMuY29tL2FpPC9hPjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAwMTMzNzQ1MSBSZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90 aWZ5IHRoZSBzZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9y IGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvciBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoNCjx0YWJsZT48dHI+PHRk IGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+VGhpcyBlbWFpbCAoaW5j bHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIG9yIGluZm9ybWF0aW9uIG90aGVyd2lzZSBwcm90ZWN0ZWQg ZnJvbSBkaXNjbG9zdXJlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRvIG5vdCBjb3B5IHRoaXMgbWVz c2FnZSBvciBhbnkgYXR0YWNobWVudHMgYW5kIGRvIG5vdCB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl IG9yIGRpc2Nsb3NlIGl0cyBjb250ZW50IHRvIGFueSBwZXJzb24sIGJ1dCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgZnJvbSB5b3VyIHN5c3RlbS4gQWlyYnVzIERlZmVu Y2UgYW5kIFNwYWNlIExpbWl0ZWQgZGlzY2xhaW1zIGFueSBhbmQgYWxsIGxpYWJpbGl0eSBpZiB0 aGlzIGVtYWlsIHRyYW5zbWlzc2lvbiB3YXMgdmlydXMgY29ycnVwdGVkLCBhbHRlcmVkIG9yIGZh bHNpZmllZC4NCi1vLQ0KRW1haWxzIHRvIEFpcmJ1cyBEZWZlbmNlIGFuZCBTcGFjZSBMaW1pdGVk IG1heSBiZSBwcm9jZXNzZWQsIHJlY29yZGVkIGFuZCBtb25pdG9yZWQgb3V0c2lkZSB0aGUgVUsu DQotby0NCkFpcmJ1cyBEZWZlbmNlIGFuZCBTcGFjZSBMaW1pdGVkLCBSZWdpc3RlcmVkIGluIEVu Z2xhbmQgYW5kIFdhbGVzIE5vLiAyNDQ5MjU5DQpSZWdpc3RlcmVkIE9mZmljZTogR3VubmVscyBX b29kIFJvYWQsIFN0ZXZlbmFnZSwgSGVydGZvcmRzaGlyZSwgU0cxIDJBUywgRW5nbGFuZDwvcHJl PjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --_000_D9712B947A4CCA43AB42F01B90AF1DEC010FD34B53AUK52715UKNUK_-- From nobody Mon Oct 19 07:40:06 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22441A914A for ; Mon, 19 Oct 2015 07:40:05 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7a9sXUf_4Wq for ; Mon, 19 Oct 2015 07:40:02 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 6E8B21A6F7F for ; Mon, 19 Oct 2015 07:40:01 -0700 (PDT) Received: by wijp11 with SMTP id p11so9492474wij.0 for ; Mon, 19 Oct 2015 07:40:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=a+jMnSfrDnP88RgL8EyQRpQ8Ta2y+zpM8zxlJ2gec90=; b=h+sOqCUqlhvhzAx/umK9ddEEjDYT1TeVQnZOa2VJ4RzsfQdMrWaHSLorbeSovSZKK0 zDKY2palBHd0qFGo1I6qMW1gMqjbm0t/OZtV58M03DadDMHxRkAPa2wDTq8ErECBUYLm zFlz2zupL362zbOrME14IfwtcPEqtzsRt5vt6twMGH38gY6vkS9WPe5IcI2ftL1vvAUg a0/lLI94Zle0tcoqUbLZ0UwNYRtmz31StKAY5dkVActxpYL0cXgR3N16Ge0uWIQW8kKs C6OjYhGkpTFrLG7/3T2vvInezbXPr7xs2btfhk6PB066ceV5TZ1s/YQJa0Plvk0P9Buf oBaA== X-Gm-Message-State: ALoCoQkCPdY36Ja1kTgusnt54CwS1nw+8qil4Jmnc4xre0un01mD/PhYeE4UtFedemBJU2QvKG32 X-Received: by 10.194.192.6 with SMTP id hc6mr32755108wjc.33.1445265600532; Mon, 19 Oct 2015 07:40:00 -0700 (PDT) Received: from [192.168.43.109] ([188.207.121.230]) by smtp.gmail.com with ESMTPSA id bd4sm34658955wjb.15.2015.10.19.07.39.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Oct 2015 07:39:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Teco Boot In-Reply-To: Date: Mon, 19 Oct 2015 16:39:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38A5475DE83986499AEACD2CFAFC3F98019ABF9CE3@tss-server1.home.tropicalstormsoftware.com> To: "Dearlove, Christopher (UK)" , Stan Ratliff X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:40:05 -0000 Wasn't radio the term for a device radiating RF signals, where a radio = receiver catches this signal and for example plays out sounds? :-) Perhaps add a diagram showing expected behavior. Based on something like = https://upload.wikimedia.org/wikipedia/commons/e/e8/Network_Bridging.png Something such as: |-------Local Node------| |------Remote Node------| | | | | +--------+ | | +--------+ | | | | | | | Router | /-----\| |/-----\ | Router | | | / bridge\ /bridge \ | | +--------+ +---+---+ +---+---+ +--------+ | MAC | |MAC|MAC| |MAC|MAC| | MAC | +--------+ +---+---+ +---+---+ +--------+ |ethernet|=3D=3D=3D=3D=3D=3D|eth|WAN|{~~~~~~~~}|WAN|eth|=3D=3D=3D=3D=3D=3D= |ethernet| +--------+ +---+---+ +---+---+ +--------+ | | | | | | |-DLEP-| | WAN link | |-DLEP-| |-data-| | protocol | |-data-| I typed bridge. Some time ago I knew these kind of devices were called = half-bridges. I suggest replacing delp-17 figure 1 with above diagram, with "bridge", = "radio", "modem" or whatever. Teco > Op 19 okt. 2015, om 15:54 heeft Dearlove, Christopher (UK) = het volgende geschreven: >=20 > I=E2=80=99d suggest a straw poll. Put me down for radio over modem, = though open to a better suggestion. > =20 > -- >=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > = __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai >=20 > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 > =20 >=20 > =20 > From: Stan Ratliff [mailto:ratliffstan@gmail.com]=20 > Sent: 19 October 2015 14:29 > To: Dearlove, Christopher (UK) > Cc: Rick Taylor; manet@ietf.org > Subject: Re: [manet] DLEP > =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 > All,=20 > =20 > I think Rick hit the nail on the head. We initially used the term = "radio", but changed it when we realized that DLEP *could* (but doesn't = have to) be used in devices like cable modems. "Router" is also a far = from perfect term - I'm currently working on an implementation where the = "router" code actually lives in an iDirect-specific application having = nothing to do with routing.=20 > =20 > Regards, > Stan > =20 > =20 > On Mon, Oct 19, 2015 at 4:31 AM, Dearlove, Christopher (UK) = wrote: > I take the point about radio being imperfect, but I think it's = significantly less imperfect than modem. >=20 > I can't think of anything better myself. >=20 >=20 > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > = __________________________________________________________________________= >=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: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: 17 October 2015 11:16 > To: Dearlove, Christopher (UK); manet@ietf.org > Subject: RE: DLEP >=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 > Thanks for the quick review Chris, >=20 > As far as the whole 'modem' versus 'radio' wording is concerned: I = share your slight discomfort with the word 'modem', but I'm not sure = 'radio' is any better! For example, I have some scruffy code which = pretends to be a DLEP modem for DMVPN tunnels, and there's definitely no = radio involved. >=20 > I'm definitely willing to listen to suggestions from the WG for words = to replace 'modem' with a word to mean 'a device that forwards layer-2 = packets to its peers, has link sensing, and is commonly some kind of = radio'. Whether we make the change depends entirely on whether the WG = has the patience. ;) >=20 > I believe (I haven't got draft-17 open in front of me) that we have = tackled some of your issues with the RFC 5226 terminology in 17 as well, = using 'Private Use' instead of 'Reserved' when appropriate. >=20 > Cheers, > Rick >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Dearlove, = Christopher (UK) > Sent: 15 October 2015 10:22 > To: manet@ietf.org > Subject: [manet] DLEP >=20 > I've read DLEP draft 16, but not so far with a critical eye to = specific review comments - other than that the IANA section isn't what's = needed (but the authors already know that and I understand have already = written a replacement) and a few editorial comments I'll make below. In = particular I haven't formed a view on the security considerations = section - but I may wait for this and most other points to see -17 which = I understand is mostly written. >=20 > My minor points: >=20 > - I really would prefer "radio" to "modem" throughout. As someone who = once wrote some modem software, for me modem is what it says, modulation = and demodulation (and the inseparable channel coding), i.e. converting = between bit streams and modulated signals (for a digital radio).There = are many parts of a radio that are outside that, and everything DLEP is = outside the modem. >=20 > - Where there are various time and other values (timeouts, repeat = periods, number of retries) I'd use a symbolic name and collect = suggested default values in one place. That is after all, as we all = write software. >=20 > - Currently describes some code points as "Reserved for future = extensions". This is not the correct terminology. =46rom RFC 5226: >=20 > Reserved: Not to be assigned. Reserved values are held for > special uses, such as to extend the namespace when it = become > exhausted. Reserved values are not available for general > assignment. >=20 > (The Reserved for 0 and 65535 is however presumably correct.) >=20 > As I know the IANA considerations section is done, this may already = have been caught, but I'll say it in case not. >=20 > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > = __________________________________________________________________________= >=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 >=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 From nobody Mon Oct 19 12:11:55 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7627E1B2BFD for ; Mon, 19 Oct 2015 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB9BVCZNUNth for ; Mon, 19 Oct 2015 12:11:49 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 535C71B2C00 for ; Mon, 19 Oct 2015 12:11:48 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t9JJBlS0024053; Mon, 19 Oct 2015 15:11:47 -0400 From: "Wiggins, David - 0665 - MITLL" To: "manet@ietf.org" , "Ratliff, Stanley" Thread-Topic: DLEP credit windowing comments Thread-Index: AQHRCqH/l51eF4+cmkyMGtJNe8W0gg== Date: Mon, 19 Oct 2015 19:11:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3528112305_67133586" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-19_15:2015-10-15,2015-10-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510190324 Archived-At: Subject: [manet] DLEP credit windowing comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:11:53 -0000 --B_3528112305_67133586 Content-type: multipart/alternative; boundary="B_3528112305_67166670" --B_3528112305_67166670 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Glad to see credit windowing split out and progressing. A few comments: When a router receives an update containing only a Credit Window Status, exactly what should it do with the MRW? Should it just overwrite whatever it has for that destination's MRW with the new MRW? If so, this would seem to provide a second mechanism to grant credits. The modem could simply include the additional credits in its MRW, instead of in a Credit Grant. Is that allowed? What happens when the router receives an update containing both a Credit Grant and a Credit Window Status? How are the router's MRW (for that destination), the MRW from the window status, and the granted credits combined to get the new router's new MRW value? An answer on the list would be great, but I suggest that the above points be clarified in the draft too. A couple of nits: In the overview: "Credits represent the number of data octets, or an increment in the number of plane octets, that can be sent on a given window at OSI Layer 2 to the receiver." I'm guessing these octets both wanted to be "data plane octets"? In 7.1 Credit Grant: "Reserved: A 64-bit unsigned integer representing the additional credits to be assigned to the credit window." Reserved -> Credit Increment David --B_3528112305_67166670 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Glad to see credit window= ing split out and progressing.   A few comments:

When a router receives an updat= e containing only a Credit Window
Status, exactly what should it do with the MRW? &= nbsp;Should it just
overwrite whatever it has for that destination's MRW with the n= ew MRW?
If so, this would seem to provide a second mechanism to grant credits.
The modem c= ould simply include the additional credits in its MRW,
instead of in a Credit Grant= .  Is that allowed?

What happens when the router receives an update containing b= oth a
C= redit Grant and a Credit Window Status?  How are the router's MRW
=
(for that de= stination), the MRW from the window status, and the
granted credits combined to get= the new router's new MRW value?

An answer on the list would be great, but I suggest = that the above points be clarified in the draft too.

A couple of nits:

In the overview: "Credi= ts represent the number of data octets, or an
increment in the number of plane octe= ts, that can be sent on a given
window at OSI Layer 2 to the receiver."  I'm g= uessing these octets
both wanted to be "data plane octets"?

In 7.1 Credit Grant:
"Reserved:  A= 64-bit unsigned integer representing the additional
 credits to be assigned t= o the credit window."
Reserved -> Credit Increment

David

--B_3528112305_67166670-- --B_3528112305_67133586 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFErDC0b3onsTp041 FdMA1MB8/MusMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTAxOTE5MTE0NVowDQYJKoZIhvcNAQEBBQAEggEA0BWtUVnwYdJwpaYswdebI+VQFvJUr2WV zfACZbG5cgqZyeTiaVMkSUXvAAV0GFQI+ftZ7xzfSuw+0Y2di9RmKy9evQcA9yfHUj/ShBaw Ibl99W8D/GNQhk9RQxyHnr+T9T+Ss2F8I5VoomdKpni4x0bbsCPRPWLfWShkomj/lIczjqUX 7TvKNtU1DEkqp4IdfnQXldbpPaG6ESkSuzOn8FKOV/fIOY9Of789Fe3PERRjoUDeiSJWx7Pl 5spwFaYfM6yMm2H15yNKjdoliuEfZSt+gzT/YCRq9lQNX6XIXhEgvhNaL/VvjNB2MOYF9CKj M7l2GtBtawhLvHqYXynjAg== --B_3528112305_67133586-- From nobody Mon Oct 19 13:50:33 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF2C1ACD45 for ; Mon, 19 Oct 2015 13:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 jgr67BQVxIOO for ; Mon, 19 Oct 2015 13:50:05 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450: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 159101ACDC8 for ; Mon, 19 Oct 2015 13:50:01 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so55478wic.0 for ; Mon, 19 Oct 2015 13:49:59 -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:content-type; bh=GfX29IOw1DZjX6zVwCrIWbzMKQBmMUgwm/Lcsauc4Bc=; b=O/jBT20U7hau8K/FVnpscwZXQ/HLDnACpZ8dVsP0QMyMQw540rCRqkbsU29D2S3tVe OhLXd26O7wxG/QlNrMglSjbzqmCoiEGmMVG6XZYKOp7LaX0un7UtsEkZ4bdHOs40DhZ3 EEj/IlE24GUKNfgCRxXb/YIHO8MrNAGhuvXS4mPvu8PNiCOBO638aguYe949HMdSwRID 3qH7TyG0m8FkpfLHFg4E580p5sEi7+sbga12dhoB6mlZ448OBtwa1ZfnmNbOv+QjUXCM MXJ8lkRZNhEh0SrGrQPGsfSpjpmqG2PNflb9w4tCGvvE3q7AdqjAp571Qj3Mh4gebRzB rrRQ== MIME-Version: 1.0 X-Received: by 10.180.37.113 with SMTP id x17mr22162923wij.33.1445287799584; Mon, 19 Oct 2015 13:49:59 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.43.7 with HTTP; Mon, 19 Oct 2015 13:49:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 22:49:59 +0200 X-Google-Sender-Auth: OeEMUNgQ10AhhG7P1QLMRtORnXc Message-ID: From: Jiazi YI To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=e89a8f502ef8e47e3005227b492b Archived-At: Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:50:10 -0000 --e89a8f502ef8e47e3005227b492b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Ulrich, Chris, all: Thanks very much for your valuable comments. We appreciate your detailed review of the draft. At this point, please allow me to reply to some of your major concerns first. For the rest, I'll respond in another mail later, or integrate directly into the draft. *- Source routing intrusion to the IP stack * This is one of the major concerns brought out by Chris, Ulrich and Geoff Ladwig on the list or privately. In fact, this draft uses the standard source routing. The steps defined in https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-8.= 5 is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6). Therefore, if the system support the IPv4 source routing defined in RFC791, or the IPv6 source routing defined in RFC6554, this part is already there. I'll make it more explicit in the next revision. *- Finding alternative paths in OLSRv2* >From Chris: > My main reservation about this draft has always been, and remains, that > OLSRv2, by design, maintains a subset of the network topology sufficient > for a best route to each destination. Picking multiple paths from that > subset will not guarantee to find all alternative paths that may exist. Finding all alternative paths - no. It's not the design goal either. Finding useful multiple paths - yes. As each router selects MPR independently, and it's hard to get an optimal set of MPR (most of the time, the greedy algorithm is used), we always have redundancies in the topology graph. Multiple paths can thus be found. Simulation study and testbed experiments (not only from the authors, but also from different parties) have shown that the extension obtain the multiple disjoint paths desired. In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY parameter to obtain the whole topology graph. But it didn't give us any gain, but much more significant control overhead, as expected. *- Link metrics* >From Chris: > With arbitrary link metrics, alternative paths having exactly the same > link metric may often be rare or accidental. Which leads to the question > whether alternative paths must have the same metric (so may often not > exist) or may have a different metric =E2=80=93 and if so how to decide a= cutoff. > (And how to avoid looping =E2=80=93 unless using source routing, which ma= y also be > needed to enforce using the alternative paths.) This multipath extension does not require the paths have the same metric. It can use any metrics that are suitable for OLSRv2. As Chris said, it uses source routing to avoid looping. *- Interoperability with OLSRv2* >From Chris: > I see the comment about interoperability with OLSRv2. This is managed by > requiring a SOURCE_ROUTE MPR in all TC messages from routers that support > this. (I haven=E2=80=99t yet checked details.) Note however that not all = routers > create TC messages, and those that don=E2=80=99t are because there is an > alternative route. (That=E2=80=99s the effect, the actual rule is to do w= ith having > advertised neighbours, at least MPR selectors.) But that alternative rout= e > may be not source routed. The net effect (a special case of the limited > topology problem I note above) is that although there may be a source > routable route to a destination, one may never be reported. To force that > it=E2=80=99s not good enough to say all source routable routers must send= a TC, > instead I=E2=80=99m fairly sure you will need to modify MPR selection so = that > source routable routers cover neighbours using other source routable > neighbours to the maximum extent possible. Is that sufficient? In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO messages. It's very good point that it's preferred to choose multipath-extension enabled router as MPR, to make them visible. We are thinking about having it as a SHOULD/RECOMMENDATION in the next revision. Is that sufficient? From interoperability point of view, I think yes. For my understanding, when we have extension-foo to bring certain performance gain, being interoperable means that using extension-foo won't interrupt the existed operations. We don't expect in a mixed environment can have the same performance gain as all routers with extension-foo. Here, the worst case is that the SOURCE_ROUTE enabled routers are not advised -- it won't break the network. But of course, the performance gain is less than all SOURCE_ROUTE enabled network. We have observed that by simulation study. I also have a question to Chris: You said not all routers create TC messages, but in RFC7181, we read: A router with one or more OLSRv2 interfaces, and with any Neighbor > Tuples with N_advertised =3D true, or with a non-empty Local Attached > Network Set MUST generate TC messages. A router that does not have > such information to advertise MUST also generate "empty" TC messages > for a period A_HOLD_TIME after it last generated a non-empty TC > message. If I understand well, generating TC message is a MUST for OLSRv2, even an "empty" one? Above is just a reply to some of the major issues that I would like to discuss and clarify in the first place. I'll reply to other comments in another mail later. Thanks again for your time reviewing the document and bringing out all those issues -- I believe that, if we can't make the document clear to you, it must be we doing something wrong :) regards Jiazi On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I agree with all of Ulrich's points, which overlap mine - he's caught som= e > good points I haven't made such as the multiple addressing point, and tha= t > willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2= . > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > _________________________________________________________________________= _ > > 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: 14 October 2015 18:13 > To: Jiazi YI > Cc: MANET IETF > Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 > > ----------------------! 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. > > > Jiazi, > > thanks for the reminder. I read the draft and have a few comments and > questions. Overall, I think that the draft is well written, but lacks som= e > details that would have to be specified before I'd feel comfortable > implementing this in an interoperable fashion. > > > - section 5.1. (router parameters). > o NUMBER_OF_PATHS: Is this a constant? Can it change during router > operations? If so what are the constraints, and how does the change impac= t > existing routes? Is this a constant per router, or could I have, say, 3 > paths for a certain destination that I need a lot, but only 1 for others? > o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two > parameters have to be negotiated between all routers or are there no > interop problems if routers use different values in the network? > o fp/fe: This is a function (of what?). I am not sure I understand why > this is listed under a section Parameters. How can I implement this? > > - section 6: > "To support source > routing, a source routing header is added to each datagram routed by > this extension." > > I think there is a section missing about interaction with FIB/RIB. > Somewhere else it is said that "[...] the MP-OLSRv2 routing process > receives a datagram from upper layers or interfaces connecting other > routing domains". How does this work? This may also need some additions t= o > the applicability statement section. > > - section 7.2: > How does this interact with the Routing Set in OLSRv2? Is this used > instead? Does the MR_valid_time have to be the same as the timeout on the > Routing Set? > > - "PT_cost - the cost of the path to the destination" > Cost in what? Hops? Does this support metrics other than hop count? > > - "PT_address[1...n] - the addresses of intermediate routers to be > visited numbered from 1 to n." > > A router may have multiple addresses for each of its interfaces. Does it > matter which addresses are used in this list? Is loop-freedom guaranteed? > > - Section 8.2.: SR_OLSR_HOLD_TIME > What is the relationship with other OLSRv2 information sets? Could there > be a situation where I still have an SR-OLSR Router Tuple, but the same > destination is not present anymore in other OLSRv2 sets (Routing Set, > Topology Set etc). Since the hold_time can be chosen independently, that > seems possible. > > - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram > from upper > layers or interfaces connecting other routing domains..." > How does this work, "other routing domains"? How would a router determine > this? > > - " o If the length of the path (n) is greater than MAX_SRC_HOPS, only > the key routers in the path are kept. By default, the key routers > are uniformly chosen in the path." > > What are key routers? How does this work? > > o The routers with higher priority (such as higher routing > willingness defined in [RFC7181]) are preferred. > > How? > > - Section 8.4: This doesn't use the information bases that have been > defined before. How can I implement this using the existing information > form the protocol? (without all that abstraction) > > - Section 8.5. This seems to be quite intrusive into the IP stack. I > thought it would be enough to add the source route header at the first > router along the path, and then just use standard source routing. Or is t= he > path changed during forwarding the packet? > > - Security: > > "Compared to OLSRv2, the use of source routing header in this > specification introduces vulnerabilities related to source routing > attacks, which include bypassing filtering devices, bandwidth > exhaustion of certain routers, etc. Those attacks are discussed in > Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the > influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the > source routing header MUST be used only in the current routing > domain." > > Is this enough to let this pass the Sec ADs? How is this enforced, "only > in the current routing domain"? > > Best regards > Ulrich > > On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: > > Dear all, > > > > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 > > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) > > will be closed on Oct. 16. > > > > Your comments on the document will be highly appreciated :) > > > > cheers > > > > Jiazi > > > > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff > wrote: > >> > >> Hello WG participants, > >> > >> The above referenced draft seems to have addressed all of the > >> outstanding WG comments to date. Therefore, it's time for a Working > >> Group Last Call > >> (WGLC) on this document. The WGLC period will close on October 16. > >> Please read and review the document, and provide comments, prior to > >> that time if possible. > >> > >> 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 > > > > _______________________________________________ > 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. > ******************************************************************** > > --e89a8f502ef8e47e3005227b492b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ulrich, Chris, all:

Tha= nks very much for your valuable comments. We appreciate your detailed revie= w of the draft.=C2=A0

At this point, please allow = me to reply to some of your major concerns first. For the rest, I'll re= spond in another mail later, or integrate directly into the draft. =C2=A0

- Source routing intrusion to the IP stack =C2= =A0

This is one of the major concerns brought = out by Chris, Ulrich and Geoff Ladwig on the list or privately.=C2=A0
=
In fact, this draft uses the standard source routing. The steps define= d in =C2=A0https://tools.ietf.org/html/draft-ietf-manet-olsrv= 2-multipath-06#section-8.5 is simply a synthesis of RFC 791 (for IPv4) = and RFC 6554 (for IPv6).=C2=A0
Therefore, if the system support t= he IPv4 source routing defined in RFC791, or the IPv6 source routing define= d in RFC6554, this part is already there.=C2=A0
I'll make it = more explicit in the next revision.=C2=A0

- =C2= =A0Finding alternative paths in OLSRv2

From Ch= ris:
My main reservation about this draft has always = been, and remains, that OLSRv2, by design, maintains a subset of the networ= k topology sufficient for a best route to each destination. Picking multipl= e paths from that subset will not guarantee to find all alternative paths t= hat may exist.

Finding all alternative path= s - no. It's not the design goal either. Finding useful multiple paths = - yes.=C2=A0
As each router selects MPR independently, and it'= ;s hard to get an optimal set of MPR (most of the time, the greedy algorith= m is used), we always have redundancies in the topology graph. Multiple pat= hs can thus be found.=C2=A0
Simulation study and testbed experime= nts (not only from the authors, but also from different parties) have shown= that the extension obtain the multiple disjoint paths desired. =C2=A0
In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDAN= CY parameter to obtain the whole topology graph. But it didn't give us = any gain, but much more significant control overhead, as expected. =C2=A0 = =C2=A0


- Link metrics
<= div>
From Chris:
With arbitrary link me= trics, alternative paths having exactly the same link metric may often be r= are or accidental. Which leads to the question whether alternative paths mu= st have the same metric (so may often not exist) or may have a different me= tric =E2=80=93 and if so how to decide a cutoff. (And how to avoid looping = =E2=80=93 unless using source routing, which may also be needed to enforce = using the alternative paths.)

This multipat= h extension does not require the paths have the same metric. It can use any= metrics that are suitable for OLSRv2. As Chris said, it uses source routin= g to avoid looping.=C2=A0

- Interoperability wi= th OLSRv2

From Chris:
= I see the comment about interoperability with OLSRv2. This is managed by re= quiring a SOURCE_ROUTE MPR in all TC messages from routers that support thi= s. (I haven=E2=80=99t yet checked details.) Note however that not all route= rs create TC messages, and those that don=E2=80=99t are because there is an= alternative route. (That=E2=80=99s the effect, the actual rule is to do wi= th having advertised neighbours, at least MPR selectors.) But that alternat= ive route may be not source routed. The net effect (a special case of the l= imited topology problem I note above) is that although there may be a sourc= e routable route to a destination, one may never be reported. To force that= it=E2=80=99s not good enough to say all source routable routers must send = a TC, instead I=E2=80=99m fairly sure you will need to modify MPR selection= so that source routable routers cover neighbours using other source routab= le neighbours to the maximum extent possible. Is that sufficient?=C2=A0

In fact, the SOURCE_ROUTE TLV is not only in T= C messages, but also HELLO messages.=C2=A0
It's very good poi= nt that it's preferred to choose multipath-extension enabled router as = MPR, to make them visible. We are thinking about having it as a SHOULD/RECO= MMENDATION in the next revision.=C2=A0

Is that suf= ficient? From interoperability point of view, I think yes. For my understan= ding, when we have extension-foo to bring certain performance gain, being i= nteroperable means that using extension-foo won't interrupt the existed= operations. We don't expect in a mixed environment can have the same p= erformance gain as all routers with extension-foo.=C2=A0
Here, th= e worst case is that the SOURCE_ROUTE enabled routers are not advised -- it= won't break the network. But of course, the performance gain is less t= han all SOURCE_ROUTE enabled network. We have observed that by simulation s= tudy.=C2=A0

I also have a question to Chris:
=
You said not all routers create TC messages, but in RFC7181, we read:<= /div>

=C2=A0 A router with one or more = OLSRv2 interfaces, and with any Neighbor
=C2=A0 =C2=A0Tuples with N_adve= rtised =3D true, or with a non-empty Local Attached
=C2=A0 =C2=A0Network= Set MUST generate TC messages.=C2=A0 A router that does not have
=C2=A0= =C2=A0such information to advertise MUST also generate "empty" T= C messages
=C2=A0 =C2=A0for a period A_HOLD_TIME after it last generated= a non-empty TC
=C2=A0 =C2=A0message.

<= div>If I understand well, generating TC message is a MUST for OLSRv2, even = an "empty" one?=C2=A0

Above is just a re= ply to some of the major issues that I would like to discuss and clarify in= the first place. I'll reply to other comments in another mail later.= =C2=A0

Thanks again for your time reviewing the do= cument and bringing out all those issues -- I believe that, if we can't= make the document clear to you, it must be we doing something wrong :)

regards

Jiazi

=



On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christo= pher (UK) <chris.dearlove@baesystems.com> wrote:=
I agree with all of Ulrich's points,= which overlap mine - he's caught some good points I haven't made s= uch as the multiple addressing point, and that willingness is local (only i= n HELLO messages and Neighbour Set) in OLSRv2.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= 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: 14 October 2015 18:13
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06

----------------------! WARNING ! ---------------------- This messag= e 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.

Jiazi,

thanks for the reminder. I read the draft and have a few comments and quest= ions. Overall, I think that the draft is well written, but lacks some detai= ls that would have to be specified before I'd feel comfortable implemen= ting this in an interoperable fashion.


- section 5.1. (router parameters).
o NUMBER_OF_PATHS: Is this a constant? Can it change during router operatio= ns? If so what are the constraints, and how does the change impact existing= routes? Is this a constant per router, or could I have, say, 3 paths for a= certain destination that I need a lot, but only 1 for others?
o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two parame= ters have to be negotiated between all routers or are there no interop prob= lems if routers use different values in the network?
o fp/fe: This is a function (of what?). I am not sure I understand why this= is listed under a section Parameters. How can I implement this?

- section 6:
"To support source
=C2=A0 =C2=A0routing, a source routing header is added to each datagram rou= ted by
=C2=A0 =C2=A0this extension."

I think there is a section missing about interaction with FIB/RIB.
Somewhere else it is said that "[...] the MP-OLSRv2 routing process re= ceives a datagram from upper layers or interfaces connecting other routing = domains". How does this work? This may also need some additions to the= applicability statement section.

- section 7.2:
How does this interact with the Routing Set in OLSRv2? Is this used instead= ? Does the MR_valid_time have to be the same as the timeout on the Routing = Set?

- "PT_cost -=C2=A0 =C2=A0the cost of the path to the destination"=
Cost in what? Hops? Does this support metrics other than hop count?

- "PT_address[1...n] -=C2=A0 =C2=A0the addresses of intermediate route= rs to be
=C2=A0 =C2=A0 =C2=A0 visited numbered from 1 to n."

A router may have multiple addresses for each of its interfaces. Does it ma= tter which addresses are used in this list? Is loop-freedom guaranteed?

- Section 8.2.: SR_OLSR_HOLD_TIME
What is the relationship with other OLSRv2 information sets? Could there be= a situation where I still have an SR-OLSR Router Tuple, but the same desti= nation is not present anymore in other OLSRv2 sets (Routing Set, Topology S= et etc). Since the hold_time can be chosen independently, that seems possib= le.

- Section 8.3: " When the MP-OLSRv2 routing process receives a datagra= m from upper
=C2=A0 =C2=A0layers or interfaces connecting other routing domains..."=
How does this work, "other routing domains"? How would a router d= etermine this?

- "=C2=A0 =C2=A0o=C2=A0 If the length of the path (n) is greater than = MAX_SRC_HOPS, only
=C2=A0 =C2=A0 =C2=A0 the key routers in the path are kept.=C2=A0 By default= , the key routers
=C2=A0 =C2=A0 =C2=A0 are uniformly chosen in the path."

What are key routers? How does this work?

=C2=A0 =C2=A0o=C2=A0 The routers with higher priority (such as higher routi= ng
=C2=A0 =C2=A0 =C2=A0 willingness defined in [RFC7181]) are preferred.

How?

- Section 8.4: This doesn't use the information bases that have been de= fined before. How can I implement this using the existing information form = the protocol? (without all that abstraction)

- Section 8.5. This seems to be quite intrusive into the IP stack. I though= t it would be enough to add the source route header at the first router alo= ng the path, and then just use standard source routing. Or is the path chan= ged during forwarding the packet?

- Security:

"Compared to OLSRv2, the use of source routing header in this
=C2=A0 =C2=A0specification introduces vulnerabilities related to source rou= ting
=C2=A0 =C2=A0attacks, which include bypassing filtering devices, bandwidth<= br> =C2=A0 =C2=A0exhaustion of certain routers, etc.=C2=A0 Those attacks are di= scussed in
=C2=A0 =C2=A0Section 5.1 of [RFC6554] and [RFC5095].=C2=A0 To make sure tha= t the
=C2=A0 =C2=A0influence is limited to the OLSRv2/MP-OLSRv2 routing domain, t= he
=C2=A0 =C2=A0source routing header MUST be used only in the current routing=
=C2=A0 =C2=A0domain."

Is this enough to let this pass the Sec ADs? How is this enforced, "on= ly in the current routing domain"?

Best regards
Ulrich

On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06
> (https://datatracker.ietf.or= g/doc/draft-ietf-manet-olsrv2-multipath/)
> will be closed on Oct. 16.
>
> Your comments on the document will be highly appreciated :)
>
> cheers
>
> Jiazi
>
> On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
>>
>> Hello WG participants,
>>
>> The above referenced draft seems to have addressed all of the
>> outstanding WG comments to date. Therefore, it's time for a Wo= rking
>> Group Last Call
>> (WGLC) on this document. The WGLC period will close on October 16.=
>> Please read and review the document, and provide comments, prior t= o
>> that time if possible.
>>
>> Regards,
>> Stan
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet<= br> >>
>
>
> _______________________________________________
> 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.
********************************************************************


--e89a8f502ef8e47e3005227b492b-- From nobody Mon Oct 19 15:41:13 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82BA1B2E07 for ; Mon, 19 Oct 2015 15:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7EMw6vdKCj0 for ; Mon, 19 Oct 2015 15:40:53 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450: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 A4A9F1B2E05 for ; Mon, 19 Oct 2015 15:40:52 -0700 (PDT) Received: by wijp11 with SMTP id p11so20964086wij.0 for ; Mon, 19 Oct 2015 15:40:51 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=D/k8EWIv1SsGUWihblrbdOiiVPreU7+dHhryI64yJL8=; b=EHul0mDL482o1yIwEsAPUcvRophVbQRqvFKnMsacNvHuq5hvlSY9+lvBwTi8i+UErI WxK7hJXqoUq6V/XyRsbqP4v3ATiBFVYkz6f8qqS9HvvfaKbIu7drpNvkmhfFg097ooV1 UT/FRpf5VcbyQ2peADbXdfZBker0NIfu7+j0PSNsxKIeTFPcMFo5cyakrMhrQ+v2Yxrk 4/VXDxNfk1VZQTBXcToIBthuTHcHEcs9LvryxrQfv2lGh8GfaBl3i9LyWxFHu/7+gDXv VGqsISC/wdwQRLPLHuEamJr5Klpgz8G7fPuNz2R+7hvgZQ6hUQbn5FswuzTM6A2CSzRN Y9Xg== X-Received: by 10.194.103.38 with SMTP id ft6mr40464048wjb.15.1445294451214; Mon, 19 Oct 2015 15:40:51 -0700 (PDT) Received: from [10.1.127.43] (dab-hlw1-h-54-1.dab.02.net. [82.132.232.186]) by smtp.gmail.com with ESMTPSA id nd9sm16710103wic.0.2015.10.19.15.40.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 15:40:50 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7341474A-5026-4931-881F-5ACA53499123 Content-Transfer-Encoding: 7bit Message-Id: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Mon, 19 Oct 2015 23:40:42 +0100 To: Jiazi YI Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:41:00 -0000 --Apple-Mail-7341474A-5026-4931-881F-5ACA53499123 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As I may not find time to reply in detail immediately, I'll just make a few p= oints. Sorting out MPRs and interworking can't be fixed with just a SHOULD. There i= sn't even a proof on the table that making it a MUST works. This is not good= enough to proceed. No, creating a TC is anything but mandatory. It's mandatory under certain co= nditions, which may not apply. Again, this misunderstanding is fundamental t= o whether the protocol will interwork with basic OLSRv2. I haven't had time to consider the source routing. But if it's being done by= IP, just say so and don't confuse matters here. If not, there's a problem. This draft is, I'm afraid, not in a suitable state for a WGLC. It needs to g= o back, have some major changes made, and re-enter pre-WGLC discussion. (A point I've not previously made is that we have multitopology now out of t= he IESG and heading to be an RFC soon. I'd not be happy with this draft if i= ncompatible with that, also a discussion worth having.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 19 Oct 2015, at 21:49, Jiazi YI wrote: >=20 > Dear Ulrich, Chris, all: >=20 > Thanks very much for your valuable comments. We appreciate your detailed r= eview of the draft.=20 >=20 > At this point, please allow me to reply to some of your major concerns fir= st. For the rest, I'll respond in another mail later, or integrate directly i= nto the draft. =20 >=20 > - Source routing intrusion to the IP stack =20 >=20 > This is one of the major concerns brought out by Chris, Ulrich and Geoff L= adwig on the list or privately.=20 > In fact, this draft uses the standard source routing. The steps defined in= https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-8= .5 is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6).=20 > Therefore, if the system support the IPv4 source routing defined in RFC791= , or the IPv6 source routing defined in RFC6554, this part is already there.= =20 > I'll make it more explicit in the next revision.=20 >=20 > - Finding alternative paths in OLSRv2 >=20 > =46rom Chris: >> My main reservation about this draft has always been, and remains, that O= LSRv2, by design, maintains a subset of the network topology sufficient for a= best route to each destination. Picking multiple paths from that subset wil= l not guarantee to find all alternative paths that may exist. >=20 > Finding all alternative paths - no. It's not the design goal either. Findi= ng useful multiple paths - yes.=20 > As each router selects MPR independently, and it's hard to get an optimal s= et of MPR (most of the time, the greedy algorithm is used), we always have r= edundancies in the topology graph. Multiple paths can thus be found.=20 > Simulation study and testbed experiments (not only from the authors, but a= lso from different parties) have shown that the extension obtain the multipl= e disjoint paths desired. =20 > In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY pa= rameter to obtain the whole topology graph. But it didn't give us any gain, b= ut much more significant control overhead, as expected. =20 >=20 >=20 > - Link metrics >=20 > =46rom Chris: >> With arbitrary link metrics, alternative paths having exactly the same li= nk metric may often be rare or accidental. Which leads to the question wheth= er alternative paths must have the same metric (so may often not exist) or m= ay have a different metric =E2=80=93 and if so how to decide a cutoff. (And h= ow to avoid looping =E2=80=93 unless using source routing, which may also be= needed to enforce using the alternative paths.) >=20 > This multipath extension does not require the paths have the same metric. I= t can use any metrics that are suitable for OLSRv2. As Chris said, it uses s= ource routing to avoid looping.=20 >=20 > - Interoperability with OLSRv2 >=20 > =46rom Chris: >> I see the comment about interoperability with OLSRv2. This is managed by r= equiring a SOURCE_ROUTE MPR in all TC messages from routers that support thi= s. (I haven=E2=80=99t yet checked details.) Note however that not all router= s create TC messages, and those that don=E2=80=99t are because there is an a= lternative route. (That=E2=80=99s the effect, the actual rule is to do with h= aving advertised neighbours, at least MPR selectors.) But that alternative r= oute may be not source routed. The net effect (a special case of the limited= topology problem I note above) is that although there may be a source routa= ble route to a destination, one may never be reported. To force that it=E2=80= =99s not good enough to say all source routable routers must send a TC, inst= ead I=E2=80=99m fairly sure you will need to modify MPR selection so that so= urce routable routers cover neighbours using other source routable neighbour= s to the maximum extent possible. Is that sufficient?=20 >=20 > In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO m= essages.=20 > It's very good point that it's preferred to choose multipath-extension ena= bled router as MPR, to make them visible. We are thinking about having it as= a SHOULD/RECOMMENDATION in the next revision.=20 >=20 > Is that sufficient? =46rom interoperability point of view, I think yes. Fo= r my understanding, when we have extension-foo to bring certain performance g= ain, being interoperable means that using extension-foo won't interrupt the e= xisted operations. We don't expect in a mixed environment can have the same p= erformance gain as all routers with extension-foo.=20 > Here, the worst case is that the SOURCE_ROUTE enabled routers are not advi= sed -- it won't break the network. But of course, the performance gain is le= ss than all SOURCE_ROUTE enabled network. We have observed that by simulatio= n study.=20 >=20 > I also have a question to Chris: > You said not all routers create TC messages, but in RFC7181, we read: >=20 >> A router with one or more OLSRv2 interfaces, and with any Neighbor >> Tuples with N_advertised =3D true, or with a non-empty Local Attached >> Network Set MUST generate TC messages. A router that does not have >> such information to advertise MUST also generate "empty" TC messages >> for a period A_HOLD_TIME after it last generated a non-empty TC >> message. >=20 >=20 > If I understand well, generating TC message is a MUST for OLSRv2, even an "= empty" one?=20 >=20 > Above is just a reply to some of the major issues that I would like to dis= cuss and clarify in the first place. I'll reply to other comments in another= mail later.=20 >=20 > Thanks again for your time reviewing the document and bringing out all tho= se issues -- I believe that, if we can't make the document clear to you, it m= ust be we doing something wrong :) >=20 > regards >=20 > Jiazi >=20 >=20 >=20 >=20 >> On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) wrote: >> I agree with all of Ulrich's points, which overlap mine - he's caught som= e good points I haven't made such as the multiple addressing point, and that= willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence >> _________________________________________________________________________= _ >>=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 >>=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg >> Sent: 14 October 2015 18:13 >> To: Jiazi YI >> Cc: MANET IETF >> Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 >>=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 >> Jiazi, >>=20 >> thanks for the reminder. I read the draft and have a few comments and que= stions. Overall, I think that the draft is well written, but lacks some deta= ils that would have to be specified before I'd feel comfortable implementing= this in an interoperable fashion. >>=20 >>=20 >> - section 5.1. (router parameters). >> o NUMBER_OF_PATHS: Is this a constant? Can it change during router operat= ions? If so what are the constraints, and how does the change impact existin= g routes? Is this a constant per router, or could I have, say, 3 paths for a= certain destination that I need a lot, but only 1 for others? >> o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two para= meters have to be negotiated between all routers or are there no interop pro= blems if routers use different values in the network? >> o fp/fe: This is a function (of what?). I am not sure I understand why th= is is listed under a section Parameters. How can I implement this? >>=20 >> - section 6: >> "To support source >> routing, a source routing header is added to each datagram routed by >> this extension." >>=20 >> I think there is a section missing about interaction with FIB/RIB. >> Somewhere else it is said that "[...] the MP-OLSRv2 routing process recei= ves a datagram from upper layers or interfaces connecting other routing doma= ins". How does this work? This may also need some additions to the applicabi= lity statement section. >>=20 >> - section 7.2: >> How does this interact with the Routing Set in OLSRv2? Is this used inste= ad? Does the MR_valid_time have to be the same as the timeout on the Routing= Set? >>=20 >> - "PT_cost - the cost of the path to the destination" >> Cost in what? Hops? Does this support metrics other than hop count? >>=20 >> - "PT_address[1...n] - the addresses of intermediate routers to be >> visited numbered from 1 to n." >>=20 >> A router may have multiple addresses for each of its interfaces. Does it m= atter which addresses are used in this list? Is loop-freedom guaranteed? >>=20 >> - Section 8.2.: SR_OLSR_HOLD_TIME >> What is the relationship with other OLSRv2 information sets? Could there b= e a situation where I still have an SR-OLSR Router Tuple, but the same desti= nation is not present anymore in other OLSRv2 sets (Routing Set, Topology Se= t etc). Since the hold_time can be chosen independently, that seems possible= . >>=20 >> - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram f= rom upper >> layers or interfaces connecting other routing domains..." >> How does this work, "other routing domains"? How would a router determine= this? >>=20 >> - " o If the length of the path (n) is greater than MAX_SRC_HOPS, only= >> the key routers in the path are kept. By default, the key routers >> are uniformly chosen in the path." >>=20 >> What are key routers? How does this work? >>=20 >> o The routers with higher priority (such as higher routing >> willingness defined in [RFC7181]) are preferred. >>=20 >> How? >>=20 >> - Section 8.4: This doesn't use the information bases that have been defi= ned before. How can I implement this using the existing information form the= protocol? (without all that abstraction) >>=20 >> - Section 8.5. This seems to be quite intrusive into the IP stack. I thou= ght it would be enough to add the source route header at the first router al= ong the path, and then just use standard source routing. Or is the path chan= ged during forwarding the packet? >>=20 >> - Security: >>=20 >> "Compared to OLSRv2, the use of source routing header in this >> specification introduces vulnerabilities related to source routing >> attacks, which include bypassing filtering devices, bandwidth >> exhaustion of certain routers, etc. Those attacks are discussed in >> Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the >> influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the >> source routing header MUST be used only in the current routing >> domain." >>=20 >> Is this enough to let this pass the Sec ADs? How is this enforced, "only i= n the current routing domain"? >>=20 >> Best regards >> Ulrich >>=20 >> On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: >> > Dear all, >> > >> > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 >> > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) >> > will be closed on Oct. 16. >> > >> > Your comments on the document will be highly appreciated :) >> > >> > cheers >> > >> > Jiazi >> > >> > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff wr= ote: >> >> >> >> Hello WG participants, >> >> >> >> The above referenced draft seems to have addressed all of the >> >> outstanding WG comments to date. Therefore, it's time for a Working >> >> Group Last Call >> >> (WGLC) on this document. The WGLC period will close on October 16. >> >> Please read and review the document, and provide comments, prior to >> >> that time if possible. >> >> >> >> 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 >> > >>=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 --Apple-Mail-7341474A-5026-4931-881F-5ACA53499123 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As I may not find time to reply in det= ail immediately, I'll just make a few points.

Sorti= ng out MPRs and interworking can't be fixed with just a SHOULD. There isn't e= ven a proof on the table that making it a MUST works. This is not good enoug= h to proceed.

No, creating a TC is anything but man= datory. It's mandatory under certain conditions, which may not apply. Again,= this misunderstanding is fundamental to whether the protocol will interwork= with basic OLSRv2.

I haven't had time to consider t= he source routing. But if it's being done by IP, just say so and don't confu= se matters here. If not, there's a problem.

This dr= aft is, I'm afraid, not in a suitable state for a WGLC. It needs to go back,= have some major changes made, and re-enter pre-WGLC discussion.
<= br>
(A point I've not previously made is that we have multitopolog= y now out of the IESG and heading to be an RFC soon. I'd not be happy with t= his draft if incompatible with that, also a discussion worth having.)
--  
Christopher Dearlove
chris@mnemosyne.demon.co.uk= (home)

On 19 Oct 2015, at 21:49, Jiazi YI <ietf@jiaziyi.com> wrote:

Dear Ulrich, Chris, all:
<= div>
Thanks very much for your valuable comments. We appreciat= e your detailed review of the draft. 

At this p= oint, please allow me to reply to some of your major concerns first. For the= rest, I'll respond in another mail later, or integrate directly into the dr= aft.  

- Source routing intrusion to the IP= stack  

This is one of the major concerns= brought out by Chris, Ulrich and Geoff Ladwig on the list or privately.&nbs= p;
In fact, this draft uses the standard source routing. The steps= defined in  https://tools.ietf.org/html/draft-ietf-manet-= olsrv2-multipath-06#section-8.5 is simply a synthesis of RFC 791 (for IP= v4) and RFC 6554 (for IPv6). 
Therefore, if the system suppor= t the IPv4 source routing defined in RFC791, or the IPv6 source routing defi= ned in RFC6554, this part is already there. 
I'll make it mor= e explicit in the next revision. 

-  Fi= nding alternative paths in OLSRv2

=46rom Chris:=
My main reservation about this draft has always been, a= nd remains, that OLSRv2, by design, maintains a subset of the network topolo= gy sufficient for a best route to each destination. Picking multiple paths f= rom that subset will not guarantee to find all alternative paths that may ex= ist.

Finding all alternative paths - no. It'= s not the design goal either. Finding useful multiple paths - yes. 
As each router selects MPR independently, and it's hard to get an opt= imal set of MPR (most of the time, the greedy algorithm is used), we always h= ave redundancies in the topology graph. Multiple paths can thus be found.&nb= sp;
Simulation study and testbed experiments (not only from the au= thors, but also from different parties) have shown that the extension obtain= the multiple disjoint paths desired.  
In fact, in the OLSRv= 1 epoch, we actually played with the TC_REDUNDANCY parameter to obtain the w= hole topology graph. But it didn't give us any gain, but much more significa= nt control overhead, as expected.    

- Link metrics

=46rom Chris:
With arbitrary link metrics, alternative paths having exact= ly the same link metric may often be rare or accidental. Which leads to the q= uestion whether alternative paths must have the same metric (so may often no= t exist) or may have a different metric =E2=80=93 and if so how to decide a c= utoff. (And how to avoid looping =E2=80=93 unless using source routing, whic= h may also be needed to enforce using the alternative paths.)

This multipath extension does not require the paths have t= he same metric. It can use any metrics that are suitable for OLSRv2. As Chri= s said, it uses source routing to avoid looping. 

<= div>- Interoperability with OLSRv2

=46rom Ch= ris:
I see the comment about interoperability with OLSRv= 2. This is managed by requiring a SOURCE_ROUTE MPR in all TC messages from r= outers that support this. (I haven=E2=80=99t yet checked details.) Note howe= ver that not all routers create TC messages, and those that don=E2=80=99t ar= e because there is an alternative route. (That=E2=80=99s the effect, the act= ual rule is to do with having advertised neighbours, at least MPR selectors.= ) But that alternative route may be not source routed. The net effect (a spe= cial case of the limited topology problem I note above) is that although the= re may be a source routable route to a destination, one may never be reporte= d. To force that it=E2=80=99s not good enough to say all source routable rou= ters must send a TC, instead I=E2=80=99m fairly sure you will need to modify= MPR selection so that source routable routers cover neighbours using other s= ource routable neighbours to the maximum extent possible. Is that sufficient= ? 

In fact, the SOURCE_ROUTE TLV is not= only in TC messages, but also HELLO messages. 
It's very goo= d point that it's preferred to choose multipath-extension enabled router as M= PR, to make them visible. We are thinking about having it as a SHOULD/RECOMM= ENDATION in the next revision. 

Is that suffic= ient? =46rom interoperability point of view, I think yes. For my understandi= ng, when we have extension-foo to bring certain performance gain, being inte= roperable means that using extension-foo won't interrupt the existed operati= ons. We don't expect in a mixed environment can have the same performance ga= in as all routers with extension-foo. 
Here, the worst case i= s that the SOURCE_ROUTE enabled routers are not advised -- it won't break th= e network. But of course, the performance gain is less than all SOURCE_ROUTE= enabled network. We have observed that by simulation study. 

I also have a question to Chris:
You said not all r= outers create TC messages, but in RFC7181, we read:

  A router with one or more OLSRv2 interfaces, and with= any Neighbor
   Tuples with N_advertised =3D true, or with a n= on-empty Local Attached
   Network Set MUST generate TC message= s.  A router that does not have
   such information to adv= ertise MUST also generate "empty" TC messages
   for a period A= _HOLD_TIME after it last generated a non-empty TC
   message.

If I understand well, generating TC mes= sage is a MUST for OLSRv2, even an "empty" one? 

Above is just a reply to some of the major issues that I would like to di= scuss and clarify in the first place. I'll reply to other comments in anothe= r mail later. 

Thanks again for your time revi= ewing the document and bringing out all those issues -- I believe that, if w= e can't make the document clear to you, it must be we doing something wrong := )

regards

Jiazi
=


On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Chris= topher (UK) <chris.dearlove@baesystems.com> wrote:=
I agree with all of Ulrich's points, which= overlap mine - he's caught some good points I haven't made such as the mult= iple addressing point, and that willingness is local (only in HELLO messages= and Neighbour Set) in OLSRv2.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________
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: 14 October 2015 18:13
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06

----------------------! 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, o= pen any attachments 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 organization.
=

Jiazi,

thanks for the reminder. I read the draft and have a few comments and questi= ons. Overall, I think that the draft is well written, but lacks some details= that would have to be specified before I'd feel comfortable implementing th= is in an interoperable fashion.


- section 5.1. (router parameters).
o NUMBER_OF_PATHS: Is this a constant? Can it change during router operation= s? If so what are the constraints, and how does the change impact existing r= outes? Is this a constant per router, or could I have, say, 3 paths for a ce= rtain destination that I need a lot, but only 1 for others?
o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two paramet= ers have to be negotiated between all routers or are there no interop proble= ms if routers use different values in the network?
o fp/fe: This is a function (of what?). I am not sure I understand why this i= s listed under a section Parameters. How can I implement this?

- section 6:
"To support source
   routing, a source routing header is added to each datagram rout= ed by
   this extension."

I think there is a section missing about interaction with FIB/RIB.
Somewhere else it is said that "[...] the MP-OLSRv2 routing process receives= a datagram from upper layers or interfaces connecting other routing domains= ". How does this work? This may also need some additions to the applicabilit= y statement section.

- section 7.2:
How does this interact with the Routing Set in OLSRv2? Is this used instead?= Does the MR_valid_time have to be the same as the timeout on the Routing Se= t?

- "PT_cost -   the cost of the path to the destination"
Cost in what? Hops? Does this support metrics other than hop count?

- "PT_address[1...n] -   the addresses of intermediate routers to b= e
      visited numbered from 1 to n."

A router may have multiple addresses for each of its interfaces. Does it mat= ter which addresses are used in this list? Is loop-freedom guaranteed?

- Section 8.2.: SR_OLSR_HOLD_TIME
What is the relationship with other OLSRv2 information sets? Could there be a= situation where I still have an SR-OLSR Router Tuple, but the same destinat= ion is not present anymore in other OLSRv2 sets (Routing Set, Topology Set e= tc). Since the hold_time can be chosen independently, that seems possible.
- Section 8.3: " When the MP-OLSRv2 routing process receives a datagram from= upper
   layers or interfaces connecting other routing domains..."
How does this work, "other routing domains"? How would a router determine th= is?

- "   o  If the length of the path (n) is greater than MAX_SR= C_HOPS, only
      the key routers in the path are kept.  By default,= the key routers
      are uniformly chosen in the path."

What are key routers? How does this work?

   o  The routers with higher priority (such as higher routin= g
      willingness defined in [RFC7181]) are preferred.

How?

- Section 8.4: This doesn't use the information bases that have been defined= before. How can I implement this using the existing information form the pr= otocol? (without all that abstraction)

- Section 8.5. This seems to be quite intrusive into the IP stack. I thought= it would be enough to add the source route header at the first router along= the path, and then just use standard source routing. Or is the path changed= during forwarding the packet?

- Security:

"Compared to OLSRv2, the use of source routing header in this
   specification introduces vulnerabilities related to source rout= ing
   attacks, which include bypassing filtering devices, bandwidth    exhaustion of certain routers, etc.  Those attacks are dis= cussed in
   Section 5.1 of [RFC6554] and [RFC5095].  To make sure that= the
   influence is limited to the OLSRv2/MP-OLSRv2 routing domain, th= e
   source routing header MUST be used only in the current routing<= br>    domain."

Is this enough to let this pass the Sec ADs? How is this enforced, "only in t= he current routing domain"?

Best regards
Ulrich

On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06
> (https://datatracker.ietf.org/= doc/draft-ietf-manet-olsrv2-multipath/)
> will be closed on Oct. 16.
>
> Your comments on the document will be highly appreciated :)
>
> cheers
>
> Jiazi
>
> On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:
>>
>> Hello WG participants,
>>
>> The above referenced draft seems to have addressed all of the
>> outstanding WG comments to date. Therefore, it's time for a Working=
>> Group Last Call
>> (WGLC) on this document. The WGLC period will close on October 16.<= br> >> Please read and review the document, and provide comments, prior to=
>> that time if possible.
>>
>> 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
>

_______________________________________________
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/mai= lman/listinfo/manet
= --Apple-Mail-7341474A-5026-4931-881F-5ACA53499123-- From nobody Mon Oct 19 17:02:47 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7261B2E8A for ; Mon, 19 Oct 2015 17:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 qYBv8IyxzPf9 for ; Mon, 19 Oct 2015 17:02:39 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450: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 DF8651B2BB4 for ; Mon, 19 Oct 2015 17:02:38 -0700 (PDT) Received: by wikq8 with SMTP id q8so21940859wik.1 for ; Mon, 19 Oct 2015 17:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OPz5FVnaaRlfhxGbCKYbPKOec2bw78ex11HDwDbF8+c=; b=WkEl60APYqShH2tfJchMZZaoS3KYg0iOueF028s/yU9y78W5XHEpJJIlDsQb/lvfgE Xq5FiKjm/G4NO7vAf4F+Mx2TxziCNN7iW2anjAui+TpDzBqvf5EfTqJfP9kcD3s3niwY Qk4/GyTrAizAPTcyWULOmwPQ2glxD+9TcdV1QcQ0Nf8tf/bm8LGQf47MOnYTByW31Qpa FKMU/8rRCcySJHm9Xc/GE5saCb18rFye4VNqM5fxg1/7JtbdBOLq1KImRRIMquWvMMF2 yFpCzROMxi3xjGzp+7zINf7B2zu5SsvOCl0KWABUOvVaWeckGenEchDQEkoW1Twx+gDi n3Dg== MIME-Version: 1.0 X-Received: by 10.194.184.166 with SMTP id ev6mr153145wjc.125.1445299357374; Mon, 19 Oct 2015 17:02:37 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.43.7 with HTTP; Mon, 19 Oct 2015 17:02:37 -0700 (PDT) In-Reply-To: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> Date: Tue, 20 Oct 2015 02:02:37 +0200 X-Google-Sender-Auth: TjwMyq4U8jx40MSC6BmlBZpZJiQ Message-ID: From: Jiazi YI To: Christopher Dearlove Content-Type: multipart/alternative; boundary=047d7bae4932ca608805227dfad9 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 00:02:44 -0000 --047d7bae4932ca608805227dfad9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > > Sorting out MPRs and interworking can't be fixed with just a SHOULD. Ther= e > isn't even a proof on the table that making it a MUST works. This is not > good enough to proceed. > > No, creating a TC is anything but mandatory. It's mandatory under certain > conditions, which may not apply. Again, this misunderstanding is > fundamental to whether the protocol will interwork with basic OLSRv2. > The point I want to make is: - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages. - I'm skeptical to making it a MUST, because even we don't consider it at all, it won't bring any negative impact to the network. Although a router with this extension will find less SOURCE_ROUTE enabled routers in that case, it can still work perfectly with other OLSRv2-only routers like a normal OLSRv2 router. > > I haven't had time to consider the source routing. But if it's being done > by IP, just say so and don't confuse matters here. > Agree. > This draft is, I'm afraid, not in a suitable state for a WGLC. It needs t= o > go back, have some major changes made, and re-enter pre-WGLC discussion. > The authors are, of course, willing to discuss related issues with the WG and have them appropriately resolved. > > (A point I've not previously made is that we have multitopology now out o= f > the IESG and heading to be an RFC soon. I'd not be happy with this draft = if > incompatible with that, also a discussion worth having.) > I don't see the how the multipath draft would be incompatible with the multi-topology draft. In fact, those two drafts are two different approaches to solve different problems. This olsrv2-multipath draft tries to make use of multiple parallel paths to send packets. It can even make use of the multiple topology to build multiple paths -- this is, of course, not tested yet. But we wrote it as a possible experiment to do in the "Motivation and Experiments to Be Conducted" section. best Jiazi > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 19 Oct 2015, at 21:49, Jiazi YI wrote: > > Dear Ulrich, Chris, all: > > Thanks very much for your valuable comments. We appreciate your detailed > review of the draft. > > At this point, please allow me to reply to some of your major concerns > first. For the rest, I'll respond in another mail later, or integrate > directly into the draft. > > *- Source routing intrusion to the IP stack * > > This is one of the major concerns brought out by Chris, Ulrich and Geoff > Ladwig on the list or privately. > In fact, this draft uses the standard source routing. The steps defined i= n > > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-= 8.5 > is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6). > Therefore, if the system support the IPv4 source routing defined in > RFC791, or the IPv6 source routing defined in RFC6554, this part is alrea= dy > there. > I'll make it more explicit in the next revision. > > *- Finding alternative paths in OLSRv2* > > From Chris: > >> My main reservation about this draft has always been, and remains, that >> OLSRv2, by design, maintains a subset of the network topology sufficient >> for a best route to each destination. Picking multiple paths from that >> subset will not guarantee to find all alternative paths that may exist. > > > Finding all alternative paths - no. It's not the design goal either. > Finding useful multiple paths - yes. > As each router selects MPR independently, and it's hard to get an optimal > set of MPR (most of the time, the greedy algorithm is used), we always ha= ve > redundancies in the topology graph. Multiple paths can thus be found. > Simulation study and testbed experiments (not only from the authors, but > also from different parties) have shown that the extension obtain the > multiple disjoint paths desired. > In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY > parameter to obtain the whole topology graph. But it didn't give us any > gain, but much more significant control overhead, as expected. > > > *- Link metrics* > > From Chris: > >> With arbitrary link metrics, alternative paths having exactly the same >> link metric may often be rare or accidental. Which leads to the question >> whether alternative paths must have the same metric (so may often not >> exist) or may have a different metric =E2=80=93 and if so how to decide = a cutoff. >> (And how to avoid looping =E2=80=93 unless using source routing, which m= ay also be >> needed to enforce using the alternative paths.) > > > This multipath extension does not require the paths have the same metric. > It can use any metrics that are suitable for OLSRv2. As Chris said, it us= es > source routing to avoid looping. > > *- Interoperability with OLSRv2* > > From Chris: > >> I see the comment about interoperability with OLSRv2. This is managed by >> requiring a SOURCE_ROUTE MPR in all TC messages from routers that suppor= t >> this. (I haven=E2=80=99t yet checked details.) Note however that not all= routers >> create TC messages, and those that don=E2=80=99t are because there is an >> alternative route. (That=E2=80=99s the effect, the actual rule is to do = with having >> advertised neighbours, at least MPR selectors.) But that alternative rou= te >> may be not source routed. The net effect (a special case of the limited >> topology problem I note above) is that although there may be a source >> routable route to a destination, one may never be reported. To force tha= t >> it=E2=80=99s not good enough to say all source routable routers must sen= d a TC, >> instead I=E2=80=99m fairly sure you will need to modify MPR selection so= that >> source routable routers cover neighbours using other source routable >> neighbours to the maximum extent possible. Is that sufficient? > > > In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO > messages. > It's very good point that it's preferred to choose multipath-extension > enabled router as MPR, to make them visible. We are thinking about having > it as a SHOULD/RECOMMENDATION in the next revision. > > Is that sufficient? From interoperability point of view, I think yes. For > my understanding, when we have extension-foo to bring certain performance > gain, being interoperable means that using extension-foo won't interrupt > the existed operations. We don't expect in a mixed environment can have t= he > same performance gain as all routers with extension-foo. > Here, the worst case is that the SOURCE_ROUTE enabled routers are not > advised -- it won't break the network. But of course, the performance gai= n > is less than all SOURCE_ROUTE enabled network. We have observed that by > simulation study. > > I also have a question to Chris: > You said not all routers create TC messages, but in RFC7181, we read: > > A router with one or more OLSRv2 interfaces, and with any Neighbor >> Tuples with N_advertised =3D true, or with a non-empty Local Attached >> Network Set MUST generate TC messages. A router that does not have >> such information to advertise MUST also generate "empty" TC messages >> for a period A_HOLD_TIME after it last generated a non-empty TC >> message. > > > If I understand well, generating TC message is a MUST for OLSRv2, even an > "empty" one? > > Above is just a reply to some of the major issues that I would like to > discuss and clarify in the first place. I'll reply to other comments in > another mail later. > > Thanks again for your time reviewing the document and bringing out all > those issues -- I believe that, if we can't make the document clear to yo= u, > it must be we doing something wrong :) > > regards > > Jiazi > > > > > On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> I agree with all of Ulrich's points, which overlap mine - he's caught >> some good points I haven't made such as the multiple addressing point, a= nd >> that willingness is local (only in HELLO messages and Neighbour Set) in >> OLSRv2. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence >> ________________________________________________________________________= __ >> >> 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: 14 October 2015 18:13 >> To: Jiazi YI >> Cc: MANET IETF >> Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 >> >> ----------------------! 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. >> >> >> Jiazi, >> >> thanks for the reminder. I read the draft and have a few comments and >> questions. Overall, I think that the draft is well written, but lacks so= me >> details that would have to be specified before I'd feel comfortable >> implementing this in an interoperable fashion. >> >> >> - section 5.1. (router parameters). >> o NUMBER_OF_PATHS: Is this a constant? Can it change during router >> operations? If so what are the constraints, and how does the change impa= ct >> existing routes? Is this a constant per router, or could I have, say, 3 >> paths for a certain destination that I need a lot, but only 1 for others= ? >> o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two >> parameters have to be negotiated between all routers or are there no >> interop problems if routers use different values in the network? >> o fp/fe: This is a function (of what?). I am not sure I understand why >> this is listed under a section Parameters. How can I implement this? >> >> - section 6: >> "To support source >> routing, a source routing header is added to each datagram routed by >> this extension." >> >> I think there is a section missing about interaction with FIB/RIB. >> Somewhere else it is said that "[...] the MP-OLSRv2 routing process >> receives a datagram from upper layers or interfaces connecting other >> routing domains". How does this work? This may also need some additions = to >> the applicability statement section. >> >> - section 7.2: >> How does this interact with the Routing Set in OLSRv2? Is this used >> instead? Does the MR_valid_time have to be the same as the timeout on th= e >> Routing Set? >> >> - "PT_cost - the cost of the path to the destination" >> Cost in what? Hops? Does this support metrics other than hop count? >> >> - "PT_address[1...n] - the addresses of intermediate routers to be >> visited numbered from 1 to n." >> >> A router may have multiple addresses for each of its interfaces. Does it >> matter which addresses are used in this list? Is loop-freedom guaranteed= ? >> >> - Section 8.2.: SR_OLSR_HOLD_TIME >> What is the relationship with other OLSRv2 information sets? Could there >> be a situation where I still have an SR-OLSR Router Tuple, but the same >> destination is not present anymore in other OLSRv2 sets (Routing Set, >> Topology Set etc). Since the hold_time can be chosen independently, that >> seems possible. >> >> - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram >> from upper >> layers or interfaces connecting other routing domains..." >> How does this work, "other routing domains"? How would a router determin= e >> this? >> >> - " o If the length of the path (n) is greater than MAX_SRC_HOPS, onl= y >> the key routers in the path are kept. By default, the key routers >> are uniformly chosen in the path." >> >> What are key routers? How does this work? >> >> o The routers with higher priority (such as higher routing >> willingness defined in [RFC7181]) are preferred. >> >> How? >> >> - Section 8.4: This doesn't use the information bases that have been >> defined before. How can I implement this using the existing information >> form the protocol? (without all that abstraction) >> >> - Section 8.5. This seems to be quite intrusive into the IP stack. I >> thought it would be enough to add the source route header at the first >> router along the path, and then just use standard source routing. Or is = the >> path changed during forwarding the packet? >> >> - Security: >> >> "Compared to OLSRv2, the use of source routing header in this >> specification introduces vulnerabilities related to source routing >> attacks, which include bypassing filtering devices, bandwidth >> exhaustion of certain routers, etc. Those attacks are discussed in >> Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the >> influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the >> source routing header MUST be used only in the current routing >> domain." >> >> Is this enough to let this pass the Sec ADs? How is this enforced, "only >> in the current routing domain"? >> >> Best regards >> Ulrich >> >> On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: >> > Dear all, >> > >> > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 >> > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/) >> > will be closed on Oct. 16. >> > >> > Your comments on the document will be highly appreciated :) >> > >> > cheers >> > >> > Jiazi >> > >> > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff >> wrote: >> >> >> >> Hello WG participants, >> >> >> >> The above referenced draft seems to have addressed all of the >> >> outstanding WG comments to date. Therefore, it's time for a Working >> >> Group Last Call >> >> (WGLC) on this document. The WGLC period will close on October 16. >> >> Please read and review the document, and provide comments, prior to >> >> that time if possible. >> >> >> >> 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 >> > >> >> _______________________________________________ >> 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 > > --047d7bae4932ca608805227dfad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
=C2=A0

Sorting out MPRs and interworking can't be fixed with = just a SHOULD. There isn't even a proof on the table that making it a M= UST works. This is not good enough to proceed.

No,= creating a TC is anything but mandatory. It's mandatory under certain = conditions, which may not apply. Again, this misunderstanding is fundamenta= l to whether the protocol will interwork with basic OLSRv2.

The point I want to make is:
=C2=A0 = =C2=A0- The=C2=A0SOURCE_ROUTE TLV are sent= over both HELLO and TC messages.=C2=A0
=C2=A0 =C2=A0- I'm skeptical to making it a MUST, becaus= e even we don't consider it at all, it won't bring any negative imp= act to the network. Although a router with this extension will find less SO= URCE_ROUTE enabled routers in that case, it can still work perfectly with o= ther OLSRv2-only routers like a normal OLSRv2 router.=C2=A0
=C2=A0

I have= n't had time to consider the source routing. But if it's being done= by IP, just say so and don't confuse matters here.

Agree.=C2=A0
=C2=A0
This draft is, I'm afraid, not in a suitable s= tate for a WGLC. It needs to go back, have some major changes made, and re-= enter pre-WGLC discussion.

The = authors are, of course, willing to discuss related issues with the WG and h= ave them appropriately resolved.=C2=A0
=C2=A0

(A point I've not previously m= ade is that we have multitopology now out of the IESG and heading to be an = RFC soon. I'd not be happy with this draft if incompatible with that, a= lso a discussion worth having.)

=
I don't see the how the multipath draft would be incompatible with= the multi-topology draft.=C2=A0
In fact, those two drafts are tw= o different approaches to solve different problems. This olsrv2-multipath d= raft tries to make use of multiple parallel paths to send packets. It can e= ven make use of the multiple topology to build multiple paths -- this is, o= f course, not tested yet. But we wrote it as a possible experiment to do in= the "Motivation and Experiments to Be Conducted" section.=C2=A0<= /div>

best

Jiazi
=C2= =A0

-- =C2=A0
Christopher Dearlove
<= /font>

On 19 Oct 2015, at 21:49= , Jiazi YI <ietf@j= iaziyi.com> wrote:

Dear Ulrich, Chris, all:

Thanks v= ery much for your valuable comments. We appreciate your detailed review of = the draft.=C2=A0

At this point, please allow me to= reply to some of your major concerns first. For the rest, I'll respond= in another mail later, or integrate directly into the draft. =C2=A0
<= div>
- Source routing intrusion to the IP stack =C2=A0=

This is one of the major concerns brought out by = Chris, Ulrich and Geoff Ladwig on the list or privately.=C2=A0
In= fact, this draft uses the standard source routing. The steps defined in = =C2=A0https://tools.ietf.org/html/draft-iet= f-manet-olsrv2-multipath-06#section-8.5 is simply a synthesis of RFC 79= 1 (for IPv4) and RFC 6554 (for IPv6).=C2=A0
Therefore, if the sys= tem support the IPv4 source routing defined in RFC791, or the IPv6 source r= outing defined in RFC6554, this part is already there.=C2=A0
I= 9;ll make it more explicit in the next revision.=C2=A0

=
- =C2=A0Finding alternative paths in OLSRv2

From Chris:
My main reservation about this draf= t has always been, and remains, that OLSRv2, by design, maintains a subset = of the network topology sufficient for a best route to each destination. Pi= cking multiple paths from that subset will not guarantee to find all altern= ative paths that may exist.

Finding all alt= ernative paths - no. It's not the design goal either. Finding useful mu= ltiple paths - yes.=C2=A0
As each router selects MPR independentl= y, and it's hard to get an optimal set of MPR (most of the time, the gr= eedy algorithm is used), we always have redundancies in the topology graph.= Multiple paths can thus be found.=C2=A0
Simulation study and tes= tbed experiments (not only from the authors, but also from different partie= s) have shown that the extension obtain the multiple disjoint paths desired= . =C2=A0
In fact, in the OLSRv1 epoch, we actually played with th= e TC_REDUNDANCY parameter to obtain the whole topology graph. But it didn&#= 39;t give us any gain, but much more significant control overhead, as expec= ted. =C2=A0 =C2=A0


- Link metric= s

From Chris:
With arbit= rary link metrics, alternative paths having exactly the same link metric ma= y often be rare or accidental. Which leads to the question whether alternat= ive paths must have the same metric (so may often not exist) or may have a = different metric =E2=80=93 and if so how to decide a cutoff. (And how to av= oid looping =E2=80=93 unless using source routing, which may also be needed= to enforce using the alternative paths.)

T= his multipath extension does not require the paths have the same metric. It= can use any metrics that are suitable for OLSRv2. As Chris said, it uses s= ource routing to avoid looping.=C2=A0

- Interop= erability with OLSRv2

From Chris:
I see the comment about interoperability with OLSRv2. This is man= aged by requiring a SOURCE_ROUTE MPR in all TC messages from routers that s= upport this. (I haven=E2=80=99t yet checked details.) Note however that not= all routers create TC messages, and those that don=E2=80=99t are because t= here is an alternative route. (That=E2=80=99s the effect, the actual rule i= s to do with having advertised neighbours, at least MPR selectors.) But tha= t alternative route may be not source routed. The net effect (a special cas= e of the limited topology problem I note above) is that although there may = be a source routable route to a destination, one may never be reported. To = force that it=E2=80=99s not good enough to say all source routable routers = must send a TC, instead I=E2=80=99m fairly sure you will need to modify MPR= selection so that source routable routers cover neighbours using other sou= rce routable neighbours to the maximum extent possible. Is that sufficient?= =C2=A0

In fact, the SOURCE_ROUTE TLV is not= only in TC messages, but also HELLO messages.=C2=A0
It's ver= y good point that it's preferred to choose multipath-extension enabled = router as MPR, to make them visible. We are thinking about having it as a S= HOULD/RECOMMENDATION in the next revision.=C2=A0

I= s that sufficient? From interoperability point of view, I think yes. For my= understanding, when we have extension-foo to bring certain performance gai= n, being interoperable means that using extension-foo won't interrupt t= he existed operations. We don't expect in a mixed environment can have = the same performance gain as all routers with extension-foo.=C2=A0
Here, the worst case is that the SOURCE_ROUTE enabled routers are not adv= ised -- it won't break the network. But of course, the performance gain= is less than all SOURCE_ROUTE enabled network. We have observed that by si= mulation study.=C2=A0

I also have a question to Ch= ris:
You said not all routers create TC messages, but in RFC7181,= we read:

=C2=A0 A router with o= ne or more OLSRv2 interfaces, and with any Neighbor
=C2=A0 =C2=A0Tuples = with N_advertised =3D true, or with a non-empty Local Attached
=C2=A0 = =C2=A0Network Set MUST generate TC messages.=C2=A0 A router that does not h= ave
=C2=A0 =C2=A0such information to advertise MUST also generate "= empty" TC messages
=C2=A0 =C2=A0for a period A_HOLD_TIME after it l= ast generated a non-empty TC
=C2=A0 =C2=A0message.

If I understand well, generating TC message is a MUST for = OLSRv2, even an "empty" one?=C2=A0

Above= is just a reply to some of the major issues that I would like to discuss a= nd clarify in the first place. I'll reply to other comments in another = mail later.=C2=A0

Thanks again for your time revie= wing the document and bringing out all those issues -- I believe that, if w= e can't make the document clear to you, it must be we doing something w= rong :)

regards

Jiazi




On Thu, Oct 15, 2015 at 1:33 PM, Dearlo= ve, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
I agree with all of Ulrich's points, wh= ich overlap mine - he's caught some good points I haven't made such= as the multiple addressing point, and that willingness is local (only in H= ELLO messages and Neighbour Set) in OLSRv2.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= 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: 14 October 2015 18:13
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06

----------------------! WARNING ! ---------------------- This messag= e 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 at= tachments 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.

Jiazi,

thanks for the reminder. I read the draft and have a few comments and quest= ions. Overall, I think that the draft is well written, but lacks some detai= ls that would have to be specified before I'd feel comfortable implemen= ting this in an interoperable fashion.


- section 5.1. (router parameters).
o NUMBER_OF_PATHS: Is this a constant? Can it change during router operatio= ns? If so what are the constraints, and how does the change impact existing= routes? Is this a constant per router, or could I have, say, 3 paths for a= certain destination that I need a lot, but only 1 for others?
o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two parame= ters have to be negotiated between all routers or are there no interop prob= lems if routers use different values in the network?
o fp/fe: This is a function (of what?). I am not sure I understand why this= is listed under a section Parameters. How can I implement this?

- section 6:
"To support source
=C2=A0 =C2=A0routing, a source routing header is added to each datagram rou= ted by
=C2=A0 =C2=A0this extension."

I think there is a section missing about interaction with FIB/RIB.
Somewhere else it is said that "[...] the MP-OLSRv2 routing process re= ceives a datagram from upper layers or interfaces connecting other routing = domains". How does this work? This may also need some additions to the= applicability statement section.

- section 7.2:
How does this interact with the Routing Set in OLSRv2? Is this used instead= ? Does the MR_valid_time have to be the same as the timeout on the Routing = Set?

- "PT_cost -=C2=A0 =C2=A0the cost of the path to the destination"=
Cost in what? Hops? Does this support metrics other than hop count?

- "PT_address[1...n] -=C2=A0 =C2=A0the addresses of intermediate route= rs to be
=C2=A0 =C2=A0 =C2=A0 visited numbered from 1 to n."

A router may have multiple addresses for each of its interfaces. Does it ma= tter which addresses are used in this list? Is loop-freedom guaranteed?

- Section 8.2.: SR_OLSR_HOLD_TIME
What is the relationship with other OLSRv2 information sets? Could there be= a situation where I still have an SR-OLSR Router Tuple, but the same desti= nation is not present anymore in other OLSRv2 sets (Routing Set, Topology S= et etc). Since the hold_time can be chosen independently, that seems possib= le.

- Section 8.3: " When the MP-OLSRv2 routing process receives a datagra= m from upper
=C2=A0 =C2=A0layers or interfaces connecting other routing domains..."=
How does this work, "other routing domains"? How would a router d= etermine this?

- "=C2=A0 =C2=A0o=C2=A0 If the length of the path (n) is greater than = MAX_SRC_HOPS, only
=C2=A0 =C2=A0 =C2=A0 the key routers in the path are kept.=C2=A0 By default= , the key routers
=C2=A0 =C2=A0 =C2=A0 are uniformly chosen in the path."

What are key routers? How does this work?

=C2=A0 =C2=A0o=C2=A0 The routers with higher priority (such as higher routi= ng
=C2=A0 =C2=A0 =C2=A0 willingness defined in [RFC7181]) are preferred.

How?

- Section 8.4: This doesn't use the information bases that have been de= fined before. How can I implement this using the existing information form = the protocol? (without all that abstraction)

- Section 8.5. This seems to be quite intrusive into the IP stack. I though= t it would be enough to add the source route header at the first router alo= ng the path, and then just use standard source routing. Or is the path chan= ged during forwarding the packet?

- Security:

"Compared to OLSRv2, the use of source routing header in this
=C2=A0 =C2=A0specification introduces vulnerabilities related to source rou= ting
=C2=A0 =C2=A0attacks, which include bypassing filtering devices, bandwidth<= br> =C2=A0 =C2=A0exhaustion of certain routers, etc.=C2=A0 Those attacks are di= scussed in
=C2=A0 =C2=A0Section 5.1 of [RFC6554] and [RFC5095].=C2=A0 To make sure tha= t the
=C2=A0 =C2=A0influence is limited to the OLSRv2/MP-OLSRv2 routing domain, t= he
=C2=A0 =C2=A0source routing header MUST be used only in the current routing=
=C2=A0 =C2=A0domain."

Is this enough to let this pass the Sec ADs? How is this enforced, "on= ly in the current routing domain"?

Best regards
Ulrich

On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06
> (https://datatracker.ietf.or= g/doc/draft-ietf-manet-olsrv2-multipath/)
> will be closed on Oct. 16.
>
> Your comments on the document will be highly appreciated :)
>
> cheers
>
> Jiazi
>
> On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote:<= br> >>
>> Hello WG participants,
>>
>> The above referenced draft seems to have addressed all of the
>> outstanding WG comments to date. Therefore, it's time for a Wo= rking
>> Group Last Call
>> (WGLC) on this document. The WGLC period will close on October 16.=
>> Please read and review the document, and provide comments, prior t= o
>> that time if possible.
>>
>> Regards,
>> Stan
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org=
>> https://www.ietf.org/mailman/listinfo/manet<= br> >>
>
>
> _______________________________________________
> 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
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet
<= /div>

--047d7bae4932ca608805227dfad9-- From nobody Mon Oct 19 23:13:44 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8BB1A1A94 for ; Mon, 19 Oct 2015 23:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3iqHcnBsdSP for ; Mon, 19 Oct 2015 23:13:37 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450: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 36B7A1A1A8D for ; Mon, 19 Oct 2015 23:13:37 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so29276638wic.1 for ; Mon, 19 Oct 2015 23:13:35 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Rt3WdKc0lNxJPk/Kjx6l3b1QvI9AHJ3q4MTHJRpg3Mc=; b=cQMddeBzRQuj21+wsGWWUvnPFLvC1ItIBv/ow0Gu0kG3qZnsLrI+IVLTV1+YL2rcN5 1bEhnJAaDzI7tYqDLM2boE+mScDGCiYTCFMyKUQQ8l3Z0yaDeYjS62uTy52su/yCQjRQ GFshzZFppOvWip1729bvq2V8KFBqr8FD3RoJQibe/RQh0Yp+tMKSC1hNGrXwo5UdlJze tV4dehWG9nM5ekNDXDNOYkANfNpzovA+GffAsHFvGvy1psn2+ckxBCaYcD0NZ2ZojAkY aTVqHIqXQDMfshTOUttNZkkp+6Cf+y8lGt67lbYW+TWprnQiQss9OJ7BaWz3vcvCNTme ULYw== X-Received: by 10.194.120.131 with SMTP id lc3mr1584243wjb.99.1445321615665; Mon, 19 Oct 2015 23:13:35 -0700 (PDT) Received: from [10.1.127.43] (dab-hlw1-h-54-3.dab.02.net. [82.132.233.108]) by smtp.gmail.com with ESMTPSA id ry1sm1629300wjb.24.2015.10.19.23.13.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 23:13:35 -0700 (PDT) References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-76E80D07-A952-41A8-B0FA-62A6AC4FEA2F Content-Transfer-Encoding: 7bit Message-Id: <51D23502-6DDB-4710-B217-A4640508FB7F@gmail.com> X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Tue, 20 Oct 2015 07:13:31 +0100 To: Jiazi YI Archived-At: Cc: "Dearlove, Christopher \(UK\)" , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 06:13:43 -0000 --Apple-Mail-76E80D07-A952-41A8-B0FA-62A6AC4FEA2F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Unless you manage the MPRs there may (in a mixed network) be destinations yo= u cannot source route to, although (with complete knowledge) that would be p= ossible. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 20 Oct 2015, at 01:02, Jiazi YI wrote: >=20 > Hi,=20 > =20 >>=20 >> Sorting out MPRs and interworking can't be fixed with just a SHOULD. Ther= e isn't even a proof on the table that making it a MUST works. This is not g= ood enough to proceed. >>=20 >> No, creating a TC is anything but mandatory. It's mandatory under certain= conditions, which may not apply. Again, this misunderstanding is fundamenta= l to whether the protocol will interwork with basic OLSRv2. >=20 > The point I want to make is: > - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages.=20 > - I'm skeptical to making it a MUST, because even we don't consider it a= t all, it won't bring any negative impact to the network. Although a router w= ith this extension will find less SOURCE_ROUTE enabled routers in that case,= it can still work perfectly with other OLSRv2-only routers like a normal OL= SRv2 router.=20 > =20 >>=20 >> I haven't had time to consider the source routing. But if it's being done= by IP, just say so and don't confuse matters here. >=20 > Agree.=20 > =20 >> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs t= o go back, have some major changes made, and re-enter pre-WGLC discussion. >=20 > The authors are, of course, willing to discuss related issues with the WG a= nd have them appropriately resolved.=20 > =20 >>=20 >> (A point I've not previously made is that we have multitopology now out o= f the IESG and heading to be an RFC soon. I'd not be happy with this draft i= f incompatible with that, also a discussion worth having.) >=20 > I don't see the how the multipath draft would be incompatible with the mul= ti-topology draft.=20 > In fact, those two drafts are two different approaches to solve different p= roblems. This olsrv2-multipath draft tries to make use of multiple parallel p= aths to send packets. It can even make use of the multiple topology to build= multiple paths -- this is, of course, not tested yet. But we wrote it as a p= ossible experiment to do in the "Motivation and Experiments to Be Conducted"= section.=20 >=20 > best >=20 > Jiazi > =20 >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >>> On 19 Oct 2015, at 21:49, Jiazi YI wrote: >>>=20 >>> Dear Ulrich, Chris, all: >>>=20 >>> Thanks very much for your valuable comments. We appreciate your detailed= review of the draft.=20 >>>=20 >>> At this point, please allow me to reply to some of your major concerns f= irst. For the rest, I'll respond in another mail later, or integrate directl= y into the draft. =20 >>>=20 >>> - Source routing intrusion to the IP stack =20 >>>=20 >>> This is one of the major concerns brought out by Chris, Ulrich and Geoff= Ladwig on the list or privately.=20 >>> In fact, this draft uses the standard source routing. The steps defined i= n https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-= 8.5 is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6).=20 >>> Therefore, if the system support the IPv4 source routing defined in RFC7= 91, or the IPv6 source routing defined in RFC6554, this part is already ther= e.=20 >>> I'll make it more explicit in the next revision.=20 >>>=20 >>> - Finding alternative paths in OLSRv2 >>>=20 >>> =46rom Chris: >>>> My main reservation about this draft has always been, and remains, that= OLSRv2, by design, maintains a subset of the network topology sufficient fo= r a best route to each destination. Picking multiple paths from that subset w= ill not guarantee to find all alternative paths that may exist. >>>=20 >>> Finding all alternative paths - no. It's not the design goal either. Fin= ding useful multiple paths - yes.=20 >>> As each router selects MPR independently, and it's hard to get an optima= l set of MPR (most of the time, the greedy algorithm is used), we always hav= e redundancies in the topology graph. Multiple paths can thus be found.=20 >>> Simulation study and testbed experiments (not only from the authors, but= also from different parties) have shown that the extension obtain the multi= ple disjoint paths desired. =20 >>> In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY p= arameter to obtain the whole topology graph. But it didn't give us any gain,= but much more significant control overhead, as expected. =20 >>>=20 >>>=20 >>> - Link metrics >>>=20 >>> =46rom Chris: >>>> With arbitrary link metrics, alternative paths having exactly the same l= ink metric may often be rare or accidental. Which leads to the question whet= her alternative paths must have the same metric (so may often not exist) or m= ay have a different metric =E2=80=93 and if so how to decide a cutoff. (And h= ow to avoid looping =E2=80=93 unless using source routing, which may also be= needed to enforce using the alternative paths.) >>>=20 >>> This multipath extension does not require the paths have the same metric= . It can use any metrics that are suitable for OLSRv2. As Chris said, it use= s source routing to avoid looping.=20 >>>=20 >>> - Interoperability with OLSRv2 >>>=20 >>> =46rom Chris: >>>> I see the comment about interoperability with OLSRv2. This is managed b= y requiring a SOURCE_ROUTE MPR in all TC messages from routers that support t= his. (I haven=E2=80=99t yet checked details.) Note however that not all rout= ers create TC messages, and those that don=E2=80=99t are because there is an= alternative route. (That=E2=80=99s the effect, the actual rule is to do wit= h having advertised neighbours, at least MPR selectors.) But that alternativ= e route may be not source routed. The net effect (a special case of the limi= ted topology problem I note above) is that although there may be a source ro= utable route to a destination, one may never be reported. To force that it=E2= =80=99s not good enough to say all source routable routers must send a TC, i= nstead I=E2=80=99m fairly sure you will need to modify MPR selection so that= source routable routers cover neighbours using other source routable neighb= ours to the maximum extent possible. Is that sufficient?=20 >>>=20 >>> In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO= messages.=20 >>> It's very good point that it's preferred to choose multipath-extension e= nabled router as MPR, to make them visible. We are thinking about having it a= s a SHOULD/RECOMMENDATION in the next revision.=20 >>>=20 >>> Is that sufficient? =46rom interoperability point of view, I think yes. = For my understanding, when we have extension-foo to bring certain performanc= e gain, being interoperable means that using extension-foo won't interrupt t= he existed operations. We don't expect in a mixed environment can have the s= ame performance gain as all routers with extension-foo.=20 >>> Here, the worst case is that the SOURCE_ROUTE enabled routers are not ad= vised -- it won't break the network. But of course, the performance gain is l= ess than all SOURCE_ROUTE enabled network. We have observed that by simulati= on study.=20 >>>=20 >>> I also have a question to Chris: >>> You said not all routers create TC messages, but in RFC7181, we read: >>>=20 >>>> A router with one or more OLSRv2 interfaces, and with any Neighbor >>>> Tuples with N_advertised =3D true, or with a non-empty Local Attache= d >>>> Network Set MUST generate TC messages. A router that does not have >>>> such information to advertise MUST also generate "empty" TC messages= >>>> for a period A_HOLD_TIME after it last generated a non-empty TC >>>> message. >>>=20 >>>=20 >>> If I understand well, generating TC message is a MUST for OLSRv2, even a= n "empty" one?=20 >>>=20 >>> Above is just a reply to some of the major issues that I would like to d= iscuss and clarify in the first place. I'll reply to other comments in anoth= er mail later.=20 >>>=20 >>> Thanks again for your time reviewing the document and bringing out all t= hose issues -- I believe that, if we can't make the document clear to you, i= t must be we doing something wrong :) >>>=20 >>> regards >>>=20 >>> Jiazi >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) wrote: >>>> I agree with all of Ulrich's points, which overlap mine - he's caught s= ome good points I haven't made such as the multiple addressing point, and th= at willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2= . >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer >>>> BAE Systems Applied Intelligence >>>> _______________________________________________________________________= ___ >>>>=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 >>>> BAE Systems Applied Intelligence Limited >>>> Registered in England & Wales No: 01337451 >>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg= >>>> Sent: 14 October 2015 18:13 >>>> To: Jiazi YI >>>> Cc: MANET IETF >>>> Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 >>>>=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 atta= chments or reply. >>>> Follow the 'Report Suspicious Emails' link on IT matters for instructio= ns on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> *** WARNING *** >>>> EXTERNAL EMAIL -- This message originates from outside our organization= . >>>>=20 >>>>=20 >>>> Jiazi, >>>>=20 >>>> thanks for the reminder. I read the draft and have a few comments and q= uestions. Overall, I think that the draft is well written, but lacks some de= tails that would have to be specified before I'd feel comfortable implementi= ng this in an interoperable fashion. >>>>=20 >>>>=20 >>>> - section 5.1. (router parameters). >>>> o NUMBER_OF_PATHS: Is this a constant? Can it change during router oper= ations? If so what are the constraints, and how does the change impact exist= ing routes? Is this a constant per router, or could I have, say, 3 paths for= a certain destination that I need a lot, but only 1 for others? >>>> o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two pa= rameters have to be negotiated between all routers or are there no interop p= roblems if routers use different values in the network? >>>> o fp/fe: This is a function (of what?). I am not sure I understand why t= his is listed under a section Parameters. How can I implement this? >>>>=20 >>>> - section 6: >>>> "To support source >>>> routing, a source routing header is added to each datagram routed by= >>>> this extension." >>>>=20 >>>> I think there is a section missing about interaction with FIB/RIB. >>>> Somewhere else it is said that "[...] the MP-OLSRv2 routing process rec= eives a datagram from upper layers or interfaces connecting other routing do= mains". How does this work? This may also need some additions to the applica= bility statement section. >>>>=20 >>>> - section 7.2: >>>> How does this interact with the Routing Set in OLSRv2? Is this used ins= tead? Does the MR_valid_time have to be the same as the timeout on the Routi= ng Set? >>>>=20 >>>> - "PT_cost - the cost of the path to the destination" >>>> Cost in what? Hops? Does this support metrics other than hop count? >>>>=20 >>>> - "PT_address[1...n] - the addresses of intermediate routers to be >>>> visited numbered from 1 to n." >>>>=20 >>>> A router may have multiple addresses for each of its interfaces. Does i= t matter which addresses are used in this list? Is loop-freedom guaranteed? >>>>=20 >>>> - Section 8.2.: SR_OLSR_HOLD_TIME >>>> What is the relationship with other OLSRv2 information sets? Could ther= e be a situation where I still have an SR-OLSR Router Tuple, but the same de= stination is not present anymore in other OLSRv2 sets (Routing Set, Topology= Set etc). Since the hold_time can be chosen independently, that seems possi= ble. >>>>=20 >>>> - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram= from upper >>>> layers or interfaces connecting other routing domains..." >>>> How does this work, "other routing domains"? How would a router determi= ne this? >>>>=20 >>>> - " o If the length of the path (n) is greater than MAX_SRC_HOPS, on= ly >>>> the key routers in the path are kept. By default, the key router= s >>>> are uniformly chosen in the path." >>>>=20 >>>> What are key routers? How does this work? >>>>=20 >>>> o The routers with higher priority (such as higher routing >>>> willingness defined in [RFC7181]) are preferred. >>>>=20 >>>> How? >>>>=20 >>>> - Section 8.4: This doesn't use the information bases that have been de= fined before. How can I implement this using the existing information form t= he protocol? (without all that abstraction) >>>>=20 >>>> - Section 8.5. This seems to be quite intrusive into the IP stack. I th= ought it would be enough to add the source route header at the first router a= long the path, and then just use standard source routing. Or is the path cha= nged during forwarding the packet? >>>>=20 >>>> - Security: >>>>=20 >>>> "Compared to OLSRv2, the use of source routing header in this >>>> specification introduces vulnerabilities related to source routing >>>> attacks, which include bypassing filtering devices, bandwidth >>>> exhaustion of certain routers, etc. Those attacks are discussed in >>>> Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the >>>> influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the >>>> source routing header MUST be used only in the current routing >>>> domain." >>>>=20 >>>> Is this enough to let this pass the Sec ADs? How is this enforced, "onl= y in the current routing domain"? >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>>> On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: >>>> > Dear all, >>>> > >>>> > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 >>>> > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/)= >>>> > will be closed on Oct. 16. >>>> > >>>> > Your comments on the document will be highly appreciated :) >>>> > >>>> > cheers >>>> > >>>> > Jiazi >>>> > >>>> > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff w= rote: >>>> >> >>>> >> Hello WG participants, >>>> >> >>>> >> The above referenced draft seems to have addressed all of the >>>> >> outstanding WG comments to date. Therefore, it's time for a Working >>>> >> Group Last Call >>>> >> (WGLC) on this document. The WGLC period will close on October 16. >>>> >> Please read and review the document, and provide comments, prior to >>>> >> that time if possible. >>>> >> >>>> >> 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 >>>> > >>>>=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 --Apple-Mail-76E80D07-A952-41A8-B0FA-62A6AC4FEA2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Unless you manage the MPRs there may (= in a mixed network) be destinations you cannot source route to, although (wi= th complete knowledge) that would be possible.

--  
Christop= her Dearlove

On 20 Oct 2015, at 01:02, Jiazi YI <ietf@jiaziyi.com> wrote:

<= div>
<= div>Hi, 
 

Sorting out MPRs and interworking can't be fixed with just a= SHOULD. There isn't even a proof on the table that making it a MUST works. T= his is not good enough to proceed.

No, creating a T= C is anything but mandatory. It's mandatory under certain conditions, which m= ay not apply. Again, this misunderstanding is fundamental to whether the pro= tocol will interwork with basic OLSRv2.

The point I want to make is:
   - The SOURCE_ROUTE TLV are sent over both HELLO and TC= messages. 
  &n= bsp;- I'm skeptical to making it a MUST, because even we don't consider it a= t all, it won't bring any negative impact to the network. Although a router w= ith this extension will find less SOURCE_ROUTE enabled routers in that case,= it can still work perfectly with other OLSRv2-only routers like a normal OL= SRv2 router. 
 

I haven't had time to consider the source routing. B= ut if it's being done by IP, just say so and don't confuse matters here.

Agree. 
 
=
This draft is, I'm afraid, not in a su= itable state for a WGLC. It needs to go back, have some major changes made, a= nd re-enter pre-WGLC discussion.

The authors are, of course, willing to discuss related issues with the WG a= nd have them appropriately resolved. 
 

(A point I've not previously made i= s that we have multitopology now out of the IESG and heading to be an RFC so= on. I'd not be happy with this draft if incompatible with that, also a discu= ssion worth having.)

I don't= see the how the multipath draft would be incompatible with the multi-topolo= gy draft. 
In fact, those two drafts are two different approa= ches to solve different problems. This olsrv2-multipath draft tries to make u= se of multiple parallel paths to send packets. It can even make use of the m= ultiple topology to build multiple paths -- this is, of course, not tested y= et. But we wrote it as a possible experiment to do in the "Motivation and Ex= periments to Be Conducted" section. 

best

Jiazi
 

--  
Christ= opher Dearlove
=
On 19 Oct 2015, at 21:49, Jiazi YI <ietf@jiaziyi.com> wrote:

Dear Ulrich, Chris, all:

Thanks very much for your valuable comments. We appreciate y= our detailed review of the draft. 

At this poi= nt, please allow me to reply to some of your major concerns first. For the r= est, I'll respond in another mail later, or integrate directly into the draf= t.  

- Source routing intrusion to the IP s= tack  

This is one of the major concerns b= rought out by Chris, Ulrich and Geoff Ladwig on the list or privately. =
In fact, this draft uses the standard source routing. The steps d= efined in  https://tools.ietf.org/html/d= raft-ietf-manet-olsrv2-multipath-06#section-8.5 is simply a synthesis of= RFC 791 (for IPv4) and RFC 6554 (for IPv6). 
Therefore, if t= he system support the IPv4 source routing defined in RFC791, or the IPv6 sou= rce routing defined in RFC6554, this part is already there. 
= I'll make it more explicit in the next revision. 

<= div>-  Finding alternative paths in OLSRv2

<= div>=46rom Chris:
My main reservation about this draft h= as always been, and remains, that OLSRv2, by design, maintains a subset of t= he network topology sufficient for a best route to each destination. Picking= multiple paths from that subset will not guarantee to find all alternative p= aths that may exist.

Finding all alternative= paths - no. It's not the design goal either. Finding useful multiple paths -= yes. 
As each router selects MPR independently, and it's har= d to get an optimal set of MPR (most of the time, the greedy algorithm is us= ed), we always have redundancies in the topology graph. Multiple paths can t= hus be found. 
Simulation study and testbed experiments (not o= nly from the authors, but also from different parties) have shown that the e= xtension obtain the multiple disjoint paths desired.  
In fac= t, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY parameter t= o obtain the whole topology graph. But it didn't give us any gain, but much m= ore significant control overhead, as expected.    

<= /div>

- Link metrics

=46rom= Chris:
With arbitrary link metrics, alternative paths h= aving exactly the same link metric may often be rare or accidental. Which le= ads to the question whether alternative paths must have the same metric (so m= ay often not exist) or may have a different metric =E2=80=93 and if so how t= o decide a cutoff. (And how to avoid looping =E2=80=93 unless using source r= outing, which may also be needed to enforce using the alternative paths.)

This multipath extension does not require the p= aths have the same metric. It can use any metrics that are suitable for OLSR= v2. As Chris said, it uses source routing to avoid looping. 
=
- Interoperability with OLSRv2

=46rom Chris:
I see the comment about interoperability= with OLSRv2. This is managed by requiring a SOURCE_ROUTE MPR in all TC mess= ages from routers that support this. (I haven=E2=80=99t yet checked details.= ) Note however that not all routers create TC messages, and those that don=E2= =80=99t are because there is an alternative route. (That=E2=80=99s the effec= t, the actual rule is to do with having advertised neighbours, at least MPR s= electors.) But that alternative route may be not source routed. The net effe= ct (a special case of the limited topology problem I note above) is that alt= hough there may be a source routable route to a destination, one may never b= e reported. To force that it=E2=80=99s not good enough to say all source rou= table routers must send a TC, instead I=E2=80=99m fairly sure you will need t= o modify MPR selection so that source routable routers cover neighbours usin= g other source routable neighbours to the maximum extent possible. Is that s= ufficient? 

In fact, the SOURCE_ROUTE T= LV is not only in TC messages, but also HELLO messages. 
It's= very good point that it's preferred to choose multipath-extension enabled r= outer as MPR, to make them visible. We are thinking about having it as a SHO= ULD/RECOMMENDATION in the next revision. 

Is t= hat sufficient? =46rom interoperability point of view, I think yes. For my u= nderstanding, when we have extension-foo to bring certain performance gain, b= eing interoperable means that using extension-foo won't interrupt the existe= d operations. We don't expect in a mixed environment can have the same perfo= rmance gain as all routers with extension-foo. 
Here, the wor= st case is that the SOURCE_ROUTE enabled routers are not advised -- it won't= break the network. But of course, the performance gain is less than all SOU= RCE_ROUTE enabled network. We have observed that by simulation study. <= /div>

I also have a question to Chris:
You said= not all routers create TC messages, but in RFC7181, we read:

=
  A router with one or more OLSRv2 interfaces= , and with any Neighbor
   Tuples with N_advertised =3D true, o= r with a non-empty Local Attached
   Network Set MUST generate T= C messages.  A router that does not have
   such informati= on to advertise MUST also generate "empty" TC messages
   for a= period A_HOLD_TIME after it last generated a non-empty TC
   m= essage.

If I understand well, generati= ng TC message is a MUST for OLSRv2, even an "empty" one? 
Above is just a reply to some of the major issues that I would l= ike to discuss and clarify in the first place. I'll reply to other comments i= n another mail later. 

Thanks again for your t= ime reviewing the document and bringing out all those issues -- I believe th= at, if we can't make the document clear to you, it must be we doing somethin= g wrong :)

regards

Jiazi




On Thu, Oct 15, 2015 at 1:33 PM, Dearlo= ve, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
I agree with all of Ulrich's points, which overl= ap mine - he's caught some good points I haven't made such as the multiple a= ddressing point, and that willingness is local (only in HELLO messages and N= eighbour Set) in OLSRv2.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________
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: 14 October 2015 18:13
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06

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

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

Jiazi,

thanks for the reminder. I read the draft and have a few comments and questi= ons. Overall, I think that the draft is well written, but lacks some details= that would have to be specified before I'd feel comfortable implementing th= is in an interoperable fashion.


- section 5.1. (router parameters).
o NUMBER_OF_PATHS: Is this a constant? Can it change during router operation= s? If so what are the constraints, and how does the change impact existing r= outes? Is this a constant per router, or could I have, say, 3 paths for a ce= rtain destination that I need a lot, but only 1 for others?
o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two paramet= ers have to be negotiated between all routers or are there no interop proble= ms if routers use different values in the network?
o fp/fe: This is a function (of what?). I am not sure I understand why this i= s listed under a section Parameters. How can I implement this?

- section 6:
"To support source
   routing, a source routing header is added to each datagram rout= ed by
   this extension."

I think there is a section missing about interaction with FIB/RIB.
Somewhere else it is said that "[...] the MP-OLSRv2 routing process receives= a datagram from upper layers or interfaces connecting other routing domains= ". How does this work? This may also need some additions to the applicabilit= y statement section.

- section 7.2:
How does this interact with the Routing Set in OLSRv2? Is this used instead?= Does the MR_valid_time have to be the same as the timeout on the Routing Se= t?

- "PT_cost -   the cost of the path to the destination"
Cost in what? Hops? Does this support metrics other than hop count?

- "PT_address[1...n] -   the addresses of intermediate routers to b= e
      visited numbered from 1 to n."

A router may have multiple addresses for each of its interfaces. Does it mat= ter which addresses are used in this list? Is loop-freedom guaranteed?

- Section 8.2.: SR_OLSR_HOLD_TIME
What is the relationship with other OLSRv2 information sets? Could there be a= situation where I still have an SR-OLSR Router Tuple, but the same destinat= ion is not present anymore in other OLSRv2 sets (Routing Set, Topology Set e= tc). Since the hold_time can be chosen independently, that seems possible.
- Section 8.3: " When the MP-OLSRv2 routing process receives a datagram from= upper
   layers or interfaces connecting other routing domains..."
How does this work, "other routing domains"? How would a router determine th= is?

- "   o  If the length of the path (n) is greater than MAX_SR= C_HOPS, only
      the key routers in the path are kept.  By default,= the key routers
      are uniformly chosen in the path."

What are key routers? How does this work?

   o  The routers with higher priority (such as higher routin= g
      willingness defined in [RFC7181]) are preferred.

How?

- Section 8.4: This doesn't use the information bases that have been defined= before. How can I implement this using the existing information form the pr= otocol? (without all that abstraction)

- Section 8.5. This seems to be quite intrusive into the IP stack. I thought= it would be enough to add the source route header at the first router along= the path, and then just use standard source routing. Or is the path changed= during forwarding the packet?

- Security:

"Compared to OLSRv2, the use of source routing header in this
   specification introduces vulnerabilities related to source rout= ing
   attacks, which include bypassing filtering devices, bandwidth    exhaustion of certain routers, etc.  Those attacks are dis= cussed in
   Section 5.1 of [RFC6554] and [RFC5095].  To make sure that= the
   influence is limited to the OLSRv2/MP-OLSRv2 routing domain, th= e
   source routing header MUST be used only in the current routing<= br>    domain."

Is this enough to let this pass the Sec ADs? How is this enforced, "only in t= he current routing domain"?

Best regards
Ulrich

On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06
> (https://datatracker.ietf.org/= doc/draft-ietf-manet-olsrv2-multipath/)
> will be closed on Oct. 16.
>
> Your comments on the document will be highly appreciated :)
>
> cheers
>
> Jiazi
>
> On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote: >>
>> Hello WG participants,
>>
>> The above referenced draft seems to have addressed all of the
>> outstanding WG comments to date. Therefore, it's time for a Working=
>> Group Last Call
>> (WGLC) on this document. The WGLC period will close on October 16.<= br> >> Please read and review the document, and provide comments, prior to=
>> that time if possible.
>>
>> Regards,
>> Stan
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/manet >>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org<= br> > 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
=

= --Apple-Mail-76E80D07-A952-41A8-B0FA-62A6AC4FEA2F-- From nobody Tue Oct 20 07:25:50 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD761A6F4C for ; Tue, 20 Oct 2015 07:25:48 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGa_F5gQYI_C for ; Tue, 20 Oct 2015 07:25:38 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A70C1A6F17 for ; Tue, 20 Oct 2015 07:25:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 482C0254964; Tue, 20 Oct 2015 07:25:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.100.20.72] (unknown [37.162.115.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2F09D2585A3; Tue, 20 Oct 2015 07:25:26 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-097E4E59-4401-4C49-A90E-A4C4D5774F37 Mime-Version: 1.0 (1.0) From: Thomas Clausen X-Mailer: iPad Mail (13A452) In-Reply-To: Date: Tue, 20 Oct 2015 16:25:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> To: Jiazi YI Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 14:25:48 -0000 --Apple-Mail-097E4E59-4401-4C49-A90E-A4C4D5774F37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just two quick points... > On 20 Oct 2015, at 02:02, Jiazi YI wrote: >=20 > Hi,=20 > =20 >>=20 >> Sorting out MPRs and interworking can't be fixed with just a SHOULD. Ther= e isn't even a proof on the table that making it a MUST works. This is not g= ood enough to proceed. >>=20 >> No, creating a TC is anything but mandatory. It's mandatory under certain= conditions, which may not apply. Specifically, a TC is mandatory only if having a non-empty MPR-selector set,= or a non-empty Attached Network set -- or, having recently had non-empty su= ch sets (in which case empty TCs are mandated for a bit to "purge stale info= rmation"). A case where an OLSRv2-router will not send TCs would, for example, be with M= PR_WILLING =3D=3D WILL_NEVER. And a case where it likely would not would be a= router with WILL_NEVER+1, in a dense network. >> Again, this misunderstanding is fundamental to whether the protocol will i= nterwork with basic OLSRv2. >=20 > The point I want to make is: > - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages.=20 > - I'm skeptical to making it a MUST, because even we don't consider it a= t all, it won't bring any negative impact to the network. Although a router w= ith this extension will find less SOURCE_ROUTE enabled routers in that case,= it can still work perfectly with other OLSRv2-only routers like a normal OL= SRv2 router.=20 Gotta consider this, at least, these ways: "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the -MP= network"?=20 "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the OLS= Rv2 network"? "Will an OLSRv2-MP router be able to function in an OLSRv2 network"? "Will an OLSRv2 router be able to function in an OLSRv2-MP network"? And then, of course, what happens if it's not "a single" but "a bunch of" ..= .. Thomas >> I haven't had time to consider the source routing. But if it's being done= by IP, just say so and don't confuse matters here. >=20 > Agree.=20 > =20 >> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs t= o go back, have some major changes made, and re-enter pre-WGLC discussion. >=20 > The authors are, of course, willing to discuss related issues with the WG a= nd have them appropriately resolved.=20 > =20 >>=20 >> (A point I've not previously made is that we have multitopology now out o= f the IESG and heading to be an RFC soon. I'd not be happy with this draft i= f incompatible with that, also a discussion worth having.) >=20 > I don't see the how the multipath draft would be incompatible with the mul= ti-topology draft.=20 > In fact, those two drafts are two different approaches to solve different p= roblems. This olsrv2-multipath draft tries to make use of multiple parallel p= aths to send packets. It can even make use of the multiple topology to build= multiple paths -- this is, of course, not tested yet. But we wrote it as a p= ossible experiment to do in the "Motivation and Experiments to Be Conducted"= section.=20 >=20 > best >=20 > Jiazi > =20 >>=20 >> -- =20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >>> On 19 Oct 2015, at 21:49, Jiazi YI wrote: >>>=20 >>> Dear Ulrich, Chris, all: >>>=20 >>> Thanks very much for your valuable comments. We appreciate your detailed= review of the draft.=20 >>>=20 >>> At this point, please allow me to reply to some of your major concerns f= irst. For the rest, I'll respond in another mail later, or integrate directl= y into the draft. =20 >>>=20 >>> - Source routing intrusion to the IP stack =20 >>>=20 >>> This is one of the major concerns brought out by Chris, Ulrich and Geoff= Ladwig on the list or privately.=20 >>> In fact, this draft uses the standard source routing. The steps defined i= n https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-= 8.5 is simply a synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6).=20 >>> Therefore, if the system support the IPv4 source routing defined in RFC7= 91, or the IPv6 source routing defined in RFC6554, this part is already ther= e.=20 >>> I'll make it more explicit in the next revision.=20 >>>=20 >>> - Finding alternative paths in OLSRv2 >>>=20 >>> =46rom Chris: >>>> My main reservation about this draft has always been, and remains, that= OLSRv2, by design, maintains a subset of the network topology sufficient fo= r a best route to each destination. Picking multiple paths from that subset w= ill not guarantee to find all alternative paths that may exist. >>>=20 >>> Finding all alternative paths - no. It's not the design goal either. Fin= ding useful multiple paths - yes.=20 >>> As each router selects MPR independently, and it's hard to get an optima= l set of MPR (most of the time, the greedy algorithm is used), we always hav= e redundancies in the topology graph. Multiple paths can thus be found.=20 >>> Simulation study and testbed experiments (not only from the authors, but= also from different parties) have shown that the extension obtain the multi= ple disjoint paths desired. =20 >>> In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY p= arameter to obtain the whole topology graph. But it didn't give us any gain,= but much more significant control overhead, as expected. =20 >>>=20 >>>=20 >>> - Link metrics >>>=20 >>> =46rom Chris: >>>> With arbitrary link metrics, alternative paths having exactly the same l= ink metric may often be rare or accidental. Which leads to the question whet= her alternative paths must have the same metric (so may often not exist) or m= ay have a different metric =E2=80=93 and if so how to decide a cutoff. (And h= ow to avoid looping =E2=80=93 unless using source routing, which may also be= needed to enforce using the alternative paths.) >>>=20 >>> This multipath extension does not require the paths have the same metric= . It can use any metrics that are suitable for OLSRv2. As Chris said, it use= s source routing to avoid looping.=20 >>>=20 >>> - Interoperability with OLSRv2 >>>=20 >>> =46rom Chris: >>>> I see the comment about interoperability with OLSRv2. This is managed b= y requiring a SOURCE_ROUTE MPR in all TC messages from routers that support t= his. (I haven=E2=80=99t yet checked details.) Note however that not all rout= ers create TC messages, and those that don=E2=80=99t are because there is an= alternative route. (That=E2=80=99s the effect, the actual rule is to do wit= h having advertised neighbours, at least MPR selectors.) But that alternativ= e route may be not source routed. The net effect (a special case of the limi= ted topology problem I note above) is that although there may be a source ro= utable route to a destination, one may never be reported. To force that it=E2= =80=99s not good enough to say all source routable routers must send a TC, i= nstead I=E2=80=99m fairly sure you will need to modify MPR selection so that= source routable routers cover neighbours using other source routable neighb= ours to the maximum extent possible. Is that sufficient?=20 >>>=20 >>> In fact, the SOURCE_ROUTE TLV is not only in TC messages, but also HELLO= messages.=20 >>> It's very good point that it's preferred to choose multipath-extension e= nabled router as MPR, to make them visible. We are thinking about having it a= s a SHOULD/RECOMMENDATION in the next revision.=20 >>>=20 >>> Is that sufficient? =46rom interoperability point of view, I think yes. = For my understanding, when we have extension-foo to bring certain performanc= e gain, being interoperable means that using extension-foo won't interrupt t= he existed operations. We don't expect in a mixed environment can have the s= ame performance gain as all routers with extension-foo.=20 >>> Here, the worst case is that the SOURCE_ROUTE enabled routers are not ad= vised -- it won't break the network. But of course, the performance gain is l= ess than all SOURCE_ROUTE enabled network. We have observed that by simulati= on study.=20 >>>=20 >>> I also have a question to Chris: >>> You said not all routers create TC messages, but in RFC7181, we read: >>>=20 >>>> A router with one or more OLSRv2 interfaces, and with any Neighbor >>>> Tuples with N_advertised =3D true, or with a non-empty Local Attache= d >>>> Network Set MUST generate TC messages. A router that does not have >>>> such information to advertise MUST also generate "empty" TC messages= >>>> for a period A_HOLD_TIME after it last generated a non-empty TC >>>> message. >>>=20 >>>=20 >>> If I understand well, generating TC message is a MUST for OLSRv2, even a= n "empty" one?=20 >>>=20 >>> Above is just a reply to some of the major issues that I would like to d= iscuss and clarify in the first place. I'll reply to other comments in anoth= er mail later.=20 >>>=20 >>> Thanks again for your time reviewing the document and bringing out all t= hose issues -- I believe that, if we can't make the document clear to you, i= t must be we doing something wrong :) >>>=20 >>> regards >>>=20 >>> Jiazi >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Thu, Oct 15, 2015 at 1:33 PM, Dearlove, Christopher (UK) wrote: >>>> I agree with all of Ulrich's points, which overlap mine - he's caught s= ome good points I haven't made such as the multiple addressing point, and th= at willingness is local (only in HELLO messages and Neighbour Set) in OLSRv2= . >>>>=20 >>>> -- >>>> Christopher Dearlove >>>> Senior Principal Engineer >>>> BAE Systems Applied Intelligence >>>> _______________________________________________________________________= ___ >>>>=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 >>>> BAE Systems Applied Intelligence Limited >>>> Registered in England & Wales No: 01337451 >>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ulrich Herberg= >>>> Sent: 14 October 2015 18:13 >>>> To: Jiazi YI >>>> Cc: MANET IETF >>>> Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 >>>>=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 atta= chments or reply. >>>> Follow the 'Report Suspicious Emails' link on IT matters for instructio= ns on reporting suspicious email messages. >>>> -------------------------------------------------------- >>>>=20 >>>> *** WARNING *** >>>> EXTERNAL EMAIL -- This message originates from outside our organization= . >>>>=20 >>>>=20 >>>> Jiazi, >>>>=20 >>>> thanks for the reminder. I read the draft and have a few comments and q= uestions. Overall, I think that the draft is well written, but lacks some de= tails that would have to be specified before I'd feel comfortable implementi= ng this in an interoperable fashion. >>>>=20 >>>>=20 >>>> - section 5.1. (router parameters). >>>> o NUMBER_OF_PATHS: Is this a constant? Can it change during router oper= ations? If so what are the constraints, and how does the change impact exist= ing routes? Is this a constant per router, or could I have, say, 3 paths for= a certain destination that I need a lot, but only 1 for others? >>>> o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two pa= rameters have to be negotiated between all routers or are there no interop p= roblems if routers use different values in the network? >>>> o fp/fe: This is a function (of what?). I am not sure I understand why t= his is listed under a section Parameters. How can I implement this? >>>>=20 >>>> - section 6: >>>> "To support source >>>> routing, a source routing header is added to each datagram routed by= >>>> this extension." >>>>=20 >>>> I think there is a section missing about interaction with FIB/RIB. >>>> Somewhere else it is said that "[...] the MP-OLSRv2 routing process rec= eives a datagram from upper layers or interfaces connecting other routing do= mains". How does this work? This may also need some additions to the applica= bility statement section. >>>>=20 >>>> - section 7.2: >>>> How does this interact with the Routing Set in OLSRv2? Is this used ins= tead? Does the MR_valid_time have to be the same as the timeout on the Routi= ng Set? >>>>=20 >>>> - "PT_cost - the cost of the path to the destination" >>>> Cost in what? Hops? Does this support metrics other than hop count? >>>>=20 >>>> - "PT_address[1...n] - the addresses of intermediate routers to be >>>> visited numbered from 1 to n." >>>>=20 >>>> A router may have multiple addresses for each of its interfaces. Does i= t matter which addresses are used in this list? Is loop-freedom guaranteed? >>>>=20 >>>> - Section 8.2.: SR_OLSR_HOLD_TIME >>>> What is the relationship with other OLSRv2 information sets? Could ther= e be a situation where I still have an SR-OLSR Router Tuple, but the same de= stination is not present anymore in other OLSRv2 sets (Routing Set, Topology= Set etc). Since the hold_time can be chosen independently, that seems possi= ble. >>>>=20 >>>> - Section 8.3: " When the MP-OLSRv2 routing process receives a datagram= from upper >>>> layers or interfaces connecting other routing domains..." >>>> How does this work, "other routing domains"? How would a router determi= ne this? >>>>=20 >>>> - " o If the length of the path (n) is greater than MAX_SRC_HOPS, on= ly >>>> the key routers in the path are kept. By default, the key router= s >>>> are uniformly chosen in the path." >>>>=20 >>>> What are key routers? How does this work? >>>>=20 >>>> o The routers with higher priority (such as higher routing >>>> willingness defined in [RFC7181]) are preferred. >>>>=20 >>>> How? >>>>=20 >>>> - Section 8.4: This doesn't use the information bases that have been de= fined before. How can I implement this using the existing information form t= he protocol? (without all that abstraction) >>>>=20 >>>> - Section 8.5. This seems to be quite intrusive into the IP stack. I th= ought it would be enough to add the source route header at the first router a= long the path, and then just use standard source routing. Or is the path cha= nged during forwarding the packet? >>>>=20 >>>> - Security: >>>>=20 >>>> "Compared to OLSRv2, the use of source routing header in this >>>> specification introduces vulnerabilities related to source routing >>>> attacks, which include bypassing filtering devices, bandwidth >>>> exhaustion of certain routers, etc. Those attacks are discussed in >>>> Section 5.1 of [RFC6554] and [RFC5095]. To make sure that the >>>> influence is limited to the OLSRv2/MP-OLSRv2 routing domain, the >>>> source routing header MUST be used only in the current routing >>>> domain." >>>>=20 >>>> Is this enough to let this pass the Sec ADs? How is this enforced, "onl= y in the current routing domain"? >>>>=20 >>>> Best regards >>>> Ulrich >>>>=20 >>>> On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI wrote: >>>> > Dear all, >>>> > >>>> > As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06 >>>> > (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/)= >>>> > will be closed on Oct. 16. >>>> > >>>> > Your comments on the document will be highly appreciated :) >>>> > >>>> > cheers >>>> > >>>> > Jiazi >>>> > >>>> > On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff w= rote: >>>> >> >>>> >> Hello WG participants, >>>> >> >>>> >> The above referenced draft seems to have addressed all of the >>>> >> outstanding WG comments to date. Therefore, it's time for a Working >>>> >> Group Last Call >>>> >> (WGLC) on this document. The WGLC period will close on October 16. >>>> >> Please read and review the document, and provide comments, prior to >>>> >> that time if possible. >>>> >> >>>> >> 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 >>>> > >>>>=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-097E4E59-4401-4C49-A90E-A4C4D5774F37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Just two quick points...

=
On 20 Oct 2015, at 02:02, Jiazi YI <ietf@jiaziyi.com> wrote:

<= div>
<= div>Hi, 
 

Sorting out MPRs and interworking can't be fixed with just a= SHOULD. There isn't even a proof on the table that making it a MUST works. T= his is not good enough to proceed.

No, creating a T= C is anything but mandatory. It's mandatory under certain conditions, which m= ay not apply.
=

Specifically, a TC is mandatory only if having a non-empty MP= R-selector set, or a non-empty Attached Network set -- or, having recently h= ad non-empty such sets (in which case empty TCs are mandated for a bit to "p= urge stale information").

A case where an OLSRv2-router w= ill not send TCs would, for example, be with MPR_WILLING =3D=3D WILL_NEVER. A= nd a case where it likely would not would be a router with WILL_NEVER+1, in a= dense network.

=
Again, this misunderstanding is fundamental to whether the p= rotocol will interwork with basic OLSRv2.

<= /div>
The point I want to make is:
   - The SOURCE_ROUTE TLV are sent over both HELLO and T= C messages. 
  &= nbsp;- I'm skeptical to making it a MUST, because even we don't consider it a= t all, it won't bring any negative impact to the network. Although a router w= ith this extension will find less SOURCE_ROUTE enabled routers in that case,= it can still work perfectly with other OLSRv2-only routers like a normal OL= SRv2 router. 
Gotta consider this, at least, these ways:

"= Will the presence of an OLSRv2 router in an OLSRv2-MP network break the -MP n= etwork"? 

"Will the presence of an OLSRv2-MP router in an OLSRv2 network br= eak the OLSRv2 network"?

"Will an OLSRv2-MP r= outer be able to function in an OLSRv2 network"?

"Will an OLSRv2 rout= er be able to function in an OLSRv2-MP network"?

And th= en, of course, what happens if it's not "a single" but "a bunch of" ....

Thomas

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex">
I haven't had time to consider the sour= ce routing. But if it's being done by IP, just say so and don't confuse matt= ers here.

Agree. 
 
This draft is, I'm afraid= , not in a suitable state for a WGLC. It needs to go back, have some major c= hanges made, and re-enter pre-WGLC discussion.
=
The authors are, of course, willing to discuss related issues= with the WG and have them appropriately resolved. 
 

(A point I've not pr= eviously made is that we have multitopology now out of the IESG and heading t= o be an RFC soon. I'd not be happy with this draft if incompatible with that= , also a discussion worth having.)

I don't see the how the multipath draft would be incompatible with th= e multi-topology draft. 
In fact, those two drafts are two di= fferent approaches to solve different problems. This olsrv2-multipath draft t= ries to make use of multiple parallel paths to send packets. It can even mak= e use of the multiple topology to build multiple paths -- this is, of course= , not tested yet. But we wrote it as a possible experiment to do in the "Mot= ivation and Experiments to Be Conducted" section. 

=
best

Jiazi
 

--  
Christopher Dearlove

On 19 Oct 2015, at 21:49, Jiazi YI <ietf@jiaziyi.com> wrote:

Dear Ulrich, Chris,= all:

Thanks very much for your valuable comments. W= e appreciate your detailed review of the draft. 

At this point, please allow me to reply to some of your major concerns fi= rst. For the rest, I'll respond in another mail later, or integrate directly= into the draft.  

- Source routing intrusi= on to the IP stack  

This is one of the ma= jor concerns brought out by Chris, Ulrich and Geoff Ladwig on the list or pr= ivately. 
In fact, this draft uses the standard source routin= g. The steps defined in  https://tools.i= etf.org/html/draft-ietf-manet-olsrv2-multipath-06#section-8.5 is simply a= synthesis of RFC 791 (for IPv4) and RFC 6554 (for IPv6). 
Th= erefore, if the system support the IPv4 source routing defined in RFC791, or= the IPv6 source routing defined in RFC6554, this part is already there.&nbs= p;
I'll make it more explicit in the next revision. 

-  Finding alternative paths in OLSRv2

=46rom Chris:
My main reservation about t= his draft has always been, and remains, that OLSRv2, by design, maintains a s= ubset of the network topology sufficient for a best route to each destinatio= n. Picking multiple paths from that subset will not guarantee to find all al= ternative paths that may exist.

Finding all a= lternative paths - no. It's not the design goal either. Finding useful multi= ple paths - yes. 
As each router selects MPR independently, a= nd it's hard to get an optimal set of MPR (most of the time, the greedy algo= rithm is used), we always have redundancies in the topology graph. Multiple p= aths can thus be found. 
Simulation study and testbed experim= ents (not only from the authors, but also from different parties) have shown= that the extension obtain the multiple disjoint paths desired.  
=
In fact, in the OLSRv1 epoch, we actually played with the TC_REDUNDANCY= parameter to obtain the whole topology graph. But it didn't give us any gai= n, but much more significant control overhead, as expected.    


- Link metrics

=46rom Chris:
With arbitrary link metrics, alte= rnative paths having exactly the same link metric may often be rare or accid= ental. Which leads to the question whether alternative paths must have the s= ame metric (so may often not exist) or may have a different metric =E2=80=93= and if so how to decide a cutoff. (And how to avoid looping =E2=80=93 unles= s using source routing, which may also be needed to enforce using the altern= ative paths.)

This multipath extension does n= ot require the paths have the same metric. It can use any metrics that are s= uitable for OLSRv2. As Chris said, it uses source routing to avoid looping.&= nbsp;

- Interoperability with OLSRv2

=46rom Chris:
I see the comment about i= nteroperability with OLSRv2. This is managed by requiring a SOURCE_ROUTE MPR= in all TC messages from routers that support this. (I haven=E2=80=99t yet c= hecked details.) Note however that not all routers create TC messages, and t= hose that don=E2=80=99t are because there is an alternative route. (That=E2=80= =99s the effect, the actual rule is to do with having advertised neighbours,= at least MPR selectors.) But that alternative route may be not source route= d. The net effect (a special case of the limited topology problem I note abo= ve) is that although there may be a source routable route to a destination, o= ne may never be reported. To force that it=E2=80=99s not good enough to say a= ll source routable routers must send a TC, instead I=E2=80=99m fairly sure y= ou will need to modify MPR selection so that source routable routers cover n= eighbours using other source routable neighbours to the maximum extent possi= ble. Is that sufficient? 

In fact, the S= OURCE_ROUTE TLV is not only in TC messages, but also HELLO messages. 
It's very good point that it's preferred to choose multipath-extens= ion enabled router as MPR, to make them visible. We are thinking about havin= g it as a SHOULD/RECOMMENDATION in the next revision. 

Is that sufficient? =46rom interoperability point of view, I think y= es. For my understanding, when we have extension-foo to bring certain perfor= mance gain, being interoperable means that using extension-foo won't interru= pt the existed operations. We don't expect in a mixed environment can have t= he same performance gain as all routers with extension-foo. 
= Here, the worst case is that the SOURCE_ROUTE enabled routers are not advise= d -- it won't break the network. But of course, the performance gain is less= than all SOURCE_ROUTE enabled network. We have observed that by simulation s= tudy. 

I also have a question to Chris:
<= div>You said not all routers create TC messages, but in RFC7181, we read:

  A router with one or more OLSRv= 2 interfaces, and with any Neighbor
   Tuples with N_advertised= =3D true, or with a non-empty Local Attached
   Network Set MU= ST generate TC messages.  A router that does not have
   s= uch information to advertise MUST also generate "empty" TC messages
 = ;  for a period A_HOLD_TIME after it last generated a non-empty TC
&= nbsp;  message.

If I understand w= ell, generating TC message is a MUST for OLSRv2, even an "empty" one? <= /div>

Above is just a reply to some of the major issues t= hat I would like to discuss and clarify in the first place. I'll reply to ot= her comments in another mail later. 

Thanks ag= ain for your time reviewing the document and bringing out all those issues -= - I believe that, if we can't make the document clear to you, it must be we d= oing something wrong :)

regards

Jiazi




On Thu, Oct 15, 2015 at 1:= 33 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com= > wrote:
I agree with all of Ulrich's points= , which overlap mine - he's caught some good points I haven't made such as t= he multiple addressing point, and that willingness is local (only in HELLO m= essages and Neighbour Set) in OLSRv2.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________
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: 14 October 2015 18:13
To: Jiazi YI
Cc: MANET IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06

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

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

Jiazi,

thanks for the reminder. I read the draft and have a few comments and questi= ons. Overall, I think that the draft is well written, but lacks some details= that would have to be specified before I'd feel comfortable implementing th= is in an interoperable fashion.


- section 5.1. (router parameters).
o NUMBER_OF_PATHS: Is this a constant? Can it change during router operation= s? If so what are the constraints, and how does the change impact existing r= outes? Is this a constant per router, or could I have, say, 3 paths for a ce= rtain destination that I need a lot, but only 1 for others?
o MAX_SRC_HOPS: same as above. (constant? constraints?) Do these two paramet= ers have to be negotiated between all routers or are there no interop proble= ms if routers use different values in the network?
o fp/fe: This is a function (of what?). I am not sure I understand why this i= s listed under a section Parameters. How can I implement this?

- section 6:
"To support source
   routing, a source routing header is added to each datagram rout= ed by
   this extension."

I think there is a section missing about interaction with FIB/RIB.
Somewhere else it is said that "[...] the MP-OLSRv2 routing process receives= a datagram from upper layers or interfaces connecting other routing domains= ". How does this work? This may also need some additions to the applicabilit= y statement section.

- section 7.2:
How does this interact with the Routing Set in OLSRv2? Is this used instead?= Does the MR_valid_time have to be the same as the timeout on the Routing Se= t?

- "PT_cost -   the cost of the path to the destination"
Cost in what? Hops? Does this support metrics other than hop count?

- "PT_address[1...n] -   the addresses of intermediate routers to b= e
      visited numbered from 1 to n."

A router may have multiple addresses for each of its interfaces. Does it mat= ter which addresses are used in this list? Is loop-freedom guaranteed?

- Section 8.2.: SR_OLSR_HOLD_TIME
What is the relationship with other OLSRv2 information sets? Could there be a= situation where I still have an SR-OLSR Router Tuple, but the same destinat= ion is not present anymore in other OLSRv2 sets (Routing Set, Topology Set e= tc). Since the hold_time can be chosen independently, that seems possible.
- Section 8.3: " When the MP-OLSRv2 routing process receives a datagram from= upper
   layers or interfaces connecting other routing domains..."
How does this work, "other routing domains"? How would a router determine th= is?

- "   o  If the length of the path (n) is greater than MAX_SR= C_HOPS, only
      the key routers in the path are kept.  By default,= the key routers
      are uniformly chosen in the path."

What are key routers? How does this work?

   o  The routers with higher priority (such as higher routin= g
      willingness defined in [RFC7181]) are preferred.

How?

- Section 8.4: This doesn't use the information bases that have been defined= before. How can I implement this using the existing information form the pr= otocol? (without all that abstraction)

- Section 8.5. This seems to be quite intrusive into the IP stack. I thought= it would be enough to add the source route header at the first router along= the path, and then just use standard source routing. Or is the path changed= during forwarding the packet?

- Security:

"Compared to OLSRv2, the use of source routing header in this
   specification introduces vulnerabilities related to source rout= ing
   attacks, which include bypassing filtering devices, bandwidth    exhaustion of certain routers, etc.  Those attacks are dis= cussed in
   Section 5.1 of [RFC6554] and [RFC5095].  To make sure that= the
   influence is limited to the OLSRv2/MP-OLSRv2 routing domain, th= e
   source routing header MUST be used only in the current routing<= br>    domain."

Is this enough to let this pass the Sec ADs? How is this enforced, "only in t= he current routing domain"?

Best regards
Ulrich

On Tue, Oct 13, 2015 at 3:18 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As a reminder, the WGLC of draft-ietf-manet-olsrv2-multipath-06
> (https://datatracker.ietf.org/= doc/draft-ietf-manet-olsrv2-multipath/)
> will be closed on Oct. 16.
>
> Your comments on the document will be highly appreciated :)
>
> cheers
>
> Jiazi
>
> On Fri, Oct 2, 2015 at 3:33 PM, Stan Ratliff <ratliffstan@gmail.com> wrote: >>
>> Hello WG participants,
>>
>> The above referenced draft seems to have addressed all of the
>> outstanding WG comments to date. Therefore, it's time for a Working=
>> Group Last Call
>> (WGLC) on this document. The WGLC period will close on October 16.<= br> >> Please read and review the document, and provide comments, prior to=
>> that time if possible.
>>
>> Regards,
>> Stan
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org<= /a>
>> https://www.ietf.org/mailman/listinfo/manet >>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org<= br> > 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/li= stinfo/manet
= --Apple-Mail-097E4E59-4401-4C49-A90E-A4C4D5774F37-- From nobody Tue Oct 20 08:03:34 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7731B34FC for ; Tue, 20 Oct 2015 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldpk3P8Nkuob for ; Tue, 20 Oct 2015 08:03:31 -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 9A1791B347B for ; Tue, 20 Oct 2015 07:56:55 -0700 (PDT) Received: by lffz202 with SMTP id z202so7164967lff.3 for ; Tue, 20 Oct 2015 07:56: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:content-type; bh=5dFVS9NgOi97yxroyEnem/P7ngmI5CI9loVAfUAy8oM=; b=T0L6bJUaS0ixxgy4k4usDa51gElGC3c3TSM2QkvI7Kh5R3bvwk1k/1C/wh3YOlmQpO i7Mi9uqUYJj49BZJbH37tyzmZkBFZOBy0L08rtAtAsuoUH4sEZ9Zh9ZRJK9x+htcB4es z2PHG6SYzG+FL8WPNaUjSDPdn3YOqfmpZVXQZkHkgFztpqJZM4WZd17fW0Yd8PZnTTev 8U7yrX+C6mbDXmhDwkIF9K8uIpsDEKhyQu6etEqljaha1qRGnSXCsZFHNaMbyiGHhxJO ylyLks5UkAow6JHtT9i1YIw8x5yGm4TZstw5eJgHghAd2t5m5IGQmJ2045wmYztblSK4 NXig== MIME-Version: 1.0 X-Received: by 10.25.170.11 with SMTP id t11mr1435308lfe.20.1445353013788; Tue, 20 Oct 2015 07:56:53 -0700 (PDT) Received: by 10.25.214.131 with HTTP; Tue, 20 Oct 2015 07:56:53 -0700 (PDT) In-Reply-To: References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> Date: Tue, 20 Oct 2015 10:56:53 -0400 Message-ID: From: Stan Ratliff To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a113db35cf6495a05228a7847 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 15:03:33 -0000 --001a113db35cf6495a05228a7847 Content-Type: text/plain; charset=UTF-8 All, Based on this discussion, and an email or two between myself and Justin and Ulrich, here's the plan going forward: I've just moved the document back to "WG Document" state. I think there is general agreement that there are issues to be addressed, and that the doc isn't yet ready for publication. We have a good discussion going here on the list; hopefully that discussion will lead to a resolution on all issues. At that point, we can reissue WGLC when the WG consensus indicates that the doc is ready. Other opinions? Questions? Flames? Regards, Stan On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen wrote: > Just two quick points... > > On 20 Oct 2015, at 02:02, Jiazi YI wrote: > > Hi, > > >> >> Sorting out MPRs and interworking can't be fixed with just a SHOULD. >> There isn't even a proof on the table that making it a MUST works. This is >> not good enough to proceed. >> >> No, creating a TC is anything but mandatory. It's mandatory under certain >> conditions, which may not apply. >> > > Specifically, a TC is mandatory only if having a non-empty MPR-selector > set, or a non-empty Attached Network set -- or, having recently had > non-empty such sets (in which case empty TCs are mandated for a bit to > "purge stale information"). > > A case where an OLSRv2-router will not send TCs would, for example, be > with MPR_WILLING == WILL_NEVER. And a case where it likely would not would > be a router with WILL_NEVER+1, in a dense network. > > Again, this misunderstanding is fundamental to whether the protocol will >> interwork with basic OLSRv2. >> > > The point I want to make is: > - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages. > - I'm skeptical to making it a MUST, because even we don't consider it > at all, it won't bring any negative impact to the network. Although a > router with this extension will find less SOURCE_ROUTE enabled routers in > that case, it can still work perfectly with other OLSRv2-only routers like > a normal OLSRv2 router. > > > Gotta consider this, at least, these ways: > > "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the > -MP network"? > > "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the > OLSRv2 network"? > > "Will an OLSRv2-MP router be able to function in an OLSRv2 network"? > > "Will an OLSRv2 router be able to function in an OLSRv2-MP network"? > > And then, of course, what happens if it's not "a single" but "a bunch of" > .... > > Thomas > > I haven't had time to consider the source routing. But if it's being done >> by IP, just say so and don't confuse matters here. >> > > Agree. > > >> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs >> to go back, have some major changes made, and re-enter pre-WGLC discussion. >> > > The authors are, of course, willing to discuss related issues with the WG > and have them appropriately resolved. > > >> >> (A point I've not previously made is that we have multitopology now out >> of the IESG and heading to be an RFC soon. I'd not be happy with this draft >> if incompatible with that, also a discussion worth having.) >> > > I don't see the how the multipath draft would be incompatible with the > multi-topology draft. > In fact, those two drafts are two different approaches to solve different > problems. This olsrv2-multipath draft tries to make use of multiple > parallel paths to send packets. It can even make use of the multiple > topology to build multiple paths -- this is, of course, not tested yet. But > we wrote it as a possible experiment to do in the "Motivation and > Experiments to Be Conducted" section. > > best > > Jiazi > > > [snip] --001a113db35cf6495a05228a7847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

Based on this discussion, an= d an email or two between myself and Justin and Ulrich, here's the plan= going forward:=C2=A0

I've just moved the docu= ment back to "WG Document" state. I think there is general agreem= ent that there are issues to be addressed, and that the doc isn't yet r= eady for publication. We have a good discussion going here on the list; hop= efully that discussion will lead to a resolution on all issues. At that poi= nt, we can reissue WGLC when the WG consensus indicates that the doc is rea= dy.=C2=A0

Other opinions? Questions?=C2=A0 Flames?= =C2=A0

Regards,
Stan


On Tue, Oct= 20, 2015 at 10:25 AM, Thomas Clausen <ietf@thomasclausen.org>= wrote:
Just two quick po= ints...

On 20 Oct 2015, at 02:02, Jiazi YI <ietf@jiaziyi.com> wrote:=

Hi,=C2=A0
=C2=A0

Sorting out M= PRs and interworking can't be fixed with just a SHOULD. There isn't= even a proof on the table that making it a MUST works. This is not good en= ough to proceed.

No, creating a TC is anything but= mandatory. It's mandatory under certain conditions, which may not appl= y.

<= /div>Specifically, a TC is mandatory only if having a non-empty MPR-selecto= r set, or a non-empty Attached Network set -- or, having recently had non-e= mpty such sets (in which case empty TCs are mandated for a bit to "pur= ge stale information").

A case where an OLSRv2-rout= er will not send TCs would, for example, be with MPR_WILLING =3D=3D WILL_NE= VER. And a case where it likely would not would be a router with WILL_NEVER= +1, in a dense network.

Again, this misunderstanding is fundamental to = whether the protocol will interwork with basic OLSRv2.

The point I want to make is:
=C2=A0 =C2= =A0- The=C2=A0SOURCE_ROUTE TLV are sent ov= er both HELLO and TC messages.=C2=A0
=C2=A0 =C2=A0- I'm skeptical to making it a MUST, because e= ven we don't consider it at all, it won't bring any negative impact= to the network. Although a router with this extension will find less SOURC= E_ROUTE enabled routers in that case, it can still work perfectly with othe= r OLSRv2-only routers like a normal OLSRv2 router.=C2=A0
=

Gotta consider this, at least= , these ways:

"Will the presence of an OLSRv2= router in an OLSRv2-MP network break the -MP network"?=C2=A0

"Will the prese= nce of an OLSRv2-MP router in an OLSRv2 network break the OLSRv2 network&qu= ot;?

"Will an OLSRv2-MP router be able= to function in an OLSRv2 network"?

"Will an OLSRv2 router be = able to function in an OLSRv2-MP network"?

And then, = of course, what happens if it's not "a single" but "a bu= nch of" ....

Thomas

=
I haven't= had time to consider the source routing. But if it's being done by IP,= just say so and don't confuse matters here.

Agree.=C2=A0
=C2=A0
This draft is, I'm afraid, not in a suitable state fo= r a WGLC. It needs to go back, have some major changes made, and re-enter p= re-WGLC discussion.

The authors= are, of course, willing to discuss related issues with the WG and have the= m appropriately resolved.=C2=A0
=C2=A0

(A point I've not previously made is = that we have multitopology now out of the IESG and heading to be an RFC soo= n. I'd not be happy with this draft if incompatible with that, also a d= iscussion worth having.)

I = don't see the how the multipath draft would be incompatible with the mu= lti-topology draft.=C2=A0
In fact, those two drafts are two diffe= rent approaches to solve different problems. This olsrv2-multipath draft tr= ies to make use of multiple parallel paths to send packets. It can even mak= e use of the multiple topology to build multiple paths -- this is, of cours= e, not tested yet. But we wrote it as a possible experiment to do in the &q= uot;Motivation and Experiments to Be Conducted" section.=C2=A0

best

Jiazi
=C2=A0
[snip]
=
--001a113db35cf6495a05228a7847-- From nobody Tue Oct 20 08:28:40 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289DA1B3416 for ; Tue, 20 Oct 2015 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 RkA8kU97SBTk for ; Tue, 20 Oct 2015 08:28:37 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450: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 22AC81B3461 for ; Tue, 20 Oct 2015 08:24:10 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so34247157wic.0 for ; Tue, 20 Oct 2015 08:24:08 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=m3raHf7zxmLHU6yfhkI+viPETZUe2EJIGShcL3HB9Wk=; b=freLLR2D8LcwHWK31HHC69npDUvVabQFAJtbBYTGQUSa6/VFcATu/BYC6xn/d0TIWe kzgchdv58NLg8yXBsPSKpebuKiPu/325dm9R26SBVSHQqkPIwPqvbBe3fokTldjzML/X bL0uCLR0Ml3DZnps4hRknRHSBEGmUrXVOx1okkBr7FoEPim94oVij7DGkVSFbZVHL7lw zPYH9/ZrWL8yCDN2LOrujo2ekwGd+F7MbZc4MNMrAz8lBQTzZ8tTk1di6eBXeQvGvJ7r dep5sudcu+1PnygrboXcoNzY+dl5BipYo9HAjAHR3IvWkeuk2Z2FpEuVT6Oazp1UJ3jD l8Pg== X-Received: by 10.180.93.2 with SMTP id cq2mr5042941wib.33.1445354648570; Tue, 20 Oct 2015 08:24:08 -0700 (PDT) Received: from [10.1.127.43] (dab-hlw1-h-1-8.dab.02.net. [82.132.234.244]) by smtp.gmail.com with ESMTPSA id ht5sm3369585wib.10.2015.10.20.08.24.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 08:24:07 -0700 (PDT) References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-997029F8-FC8E-469B-B017-4ED8CDB0D6E8 Content-Transfer-Encoding: 7bit Message-Id: <2C2CE24E-464D-4128-ACDD-4A54B4DD41E2@gmail.com> X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Tue, 20 Oct 2015 16:24:03 +0100 To: Stan Ratliff Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 15:28:39 -0000 --Apple-Mail-997029F8-FC8E-469B-B017-4ED8CDB0D6E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That sounds like the right plan to me. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 20 Oct 2015, at 15:56, Stan Ratliff wrote: >=20 > All,=20 >=20 > Based on this discussion, and an email or two between myself and Justin an= d Ulrich, here's the plan going forward:=20 >=20 > I've just moved the document back to "WG Document" state. I think there is= general agreement that there are issues to be addressed, and that the doc i= sn't yet ready for publication. We have a good discussion going here on the l= ist; hopefully that discussion will lead to a resolution on all issues. At t= hat point, we can reissue WGLC when the WG consensus indicates that the doc i= s ready.=20 >=20 > Other opinions? Questions? Flames?=20 >=20 > Regards, > Stan >=20 >=20 >> On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen = wrote: >> Just two quick points... >>=20 >>> On 20 Oct 2015, at 02:02, Jiazi YI wrote: >>>=20 >>> Hi,=20 >>> =20 >>>>=20 >>>> Sorting out MPRs and interworking can't be fixed with just a SHOULD. Th= ere isn't even a proof on the table that making it a MUST works. This is not= good enough to proceed. >>>>=20 >>>> No, creating a TC is anything but mandatory. It's mandatory under certa= in conditions, which may not apply. >>=20 >> Specifically, a TC is mandatory only if having a non-empty MPR-selector s= et, or a non-empty Attached Network set -- or, having recently had non-empty= such sets (in which case empty TCs are mandated for a bit to "purge stale i= nformation"). >>=20 >> A case where an OLSRv2-router will not send TCs would, for example, be wi= th MPR_WILLING =3D=3D WILL_NEVER. And a case where it likely would not would= be a router with WILL_NEVER+1, in a dense network. >>=20 >>>> Again, this misunderstanding is fundamental to whether the protocol wil= l interwork with basic OLSRv2. >>>=20 >>> The point I want to make is: >>> - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages.=20 >>> - I'm skeptical to making it a MUST, because even we don't consider i= t at all, it won't bring any negative impact to the network. Although a rout= er with this extension will find less SOURCE_ROUTE enabled routers in that c= ase, it can still work perfectly with other OLSRv2-only routers like a norma= l OLSRv2 router.=20 >>=20 >> Gotta consider this, at least, these ways: >>=20 >> "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the -= MP network"?=20 >>=20 >> "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the O= LSRv2 network"? >>=20 >> "Will an OLSRv2-MP router be able to function in an OLSRv2 network"? >>=20 >> "Will an OLSRv2 router be able to function in an OLSRv2-MP network"? >>=20 >> And then, of course, what happens if it's not "a single" but "a bunch of"= .... >>=20 >> Thomas >>=20 >>>> I haven't had time to consider the source routing. But if it's being do= ne by IP, just say so and don't confuse matters here. >>>=20 >>> Agree.=20 >>> =20 >>>> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs= to go back, have some major changes made, and re-enter pre-WGLC discussion.= >>>=20 >>> The authors are, of course, willing to discuss related issues with the W= G and have them appropriately resolved.=20 >>> =20 >>>>=20 >>>> (A point I've not previously made is that we have multitopology now out= of the IESG and heading to be an RFC soon. I'd not be happy with this draft= if incompatible with that, also a discussion worth having.) >>>=20 >>> I don't see the how the multipath draft would be incompatible with the m= ulti-topology draft.=20 >>> In fact, those two drafts are two different approaches to solve differen= t problems. This olsrv2-multipath draft tries to make use of multiple parall= el paths to send packets. It can even make use of the multiple topology to b= uild multiple paths -- this is, of course, not tested yet. But we wrote it a= s a possible experiment to do in the "Motivation and Experiments to Be Condu= cted" section.=20 >>>=20 >>> best >>>=20 >>> Jiazi >> [snip] >=20 --Apple-Mail-997029F8-FC8E-469B-B017-4ED8CDB0D6E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That sounds like the right plan to me.=

--  
Christopher Dearlove
=

On 20 Oct 2015, at 15:56, Stan Ratliff &l= t;ratliffstan@gmail.com> wro= te:

All, 
Based on this discussion, and an email or two between myself= and Justin and Ulrich, here's the plan going forward: 

<= /div>
I've just moved the document back to "WG Document" state. I think t= here is general agreement that there are issues to be addressed, and that th= e doc isn't yet ready for publication. We have a good discussion going here o= n the list; hopefully that discussion will lead to a resolution on all issue= s. At that point, we can reissue WGLC when the WG consensus indicates that t= he doc is ready. 

Other opinions? Questions?&n= bsp; Flames? 

Regards,
Stan


O= n Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen <ietf@thomasclausen.org= > wrote:
Just two qui= ck points...

On 20 Oct 2015, at 02:02, Jiazi YI <ietf@jiaziyi.com> wro= te:

Hi, 
 
=

Sorting out MPRs a= nd interworking can't be fixed with just a SHOULD. There isn't even a proof o= n the table that making it a MUST works. This is not good enough to proceed.=

No, creating a TC is anything but mandatory. It's m= andatory under certain conditions, which may not apply.

Specifically, a TC i= s mandatory only if having a non-empty MPR-selector set, or a non-empty Atta= ched Network set -- or, having recently had non-empty such sets (in which ca= se empty TCs are mandated for a bit to "purge stale information").

<= /div>
A case where an OLSRv2-router will not send TCs would, for example= , be with MPR_WILLING =3D=3D WILL_NEVER. And a case where it likely would no= t would be a router with WILL_NEVER+1, in a dense network.

Again, this misun= derstanding is fundamental to whether the protocol will interwork with basic= OLSRv2.

The point I want to mak= e is:
   - The SOU= RCE_ROUTE TLV are sent over both HELLO and TC messages. 
   - I'm skeptical to making i= t a MUST, because even we don't consider it at all, it won't bring any negat= ive impact to the network. Although a router with this extension will find l= ess SOURCE_ROUTE enabled routers in that case, it can still work perfectly w= ith other OLSRv2-only routers like a normal OLSRv2 router. 

Gotta consider this, at= least, these ways:

"Will the presence of an OLSRv2= router in an OLSRv2-MP network break the -MP network"? 

"Will the presence of an OLS= Rv2-MP router in an OLSRv2 network break the OLSRv2 network"?

"Will an OLSRv2-MP router be able to function in an OLSRv2= network"?

"Will an OLSRv2 router be able to function in an OLSRv2-MP netw= ork"?
=
And then, of course, what happens if it's not "a singl= e" but "a bunch of" ....

Thomas

=
I haven't h= ad time to consider the source routing. But if it's being done by IP, just s= ay so and don't confuse matters here.

Agree. 
 
This draft is, I'm afraid, not in a suitable state for a WGLC. It needs t= o go back, have some major changes made, and re-enter pre-WGLC discussion.

The authors are, of course, willi= ng to discuss related issues with the WG and have them appropriately resolve= d. 
 

(A point I've not previously made is that we have multitopology now o= ut of the IESG and heading to be an RFC soon. I'd not be happy with this dra= ft if incompatible with that, also a discussion worth having.)

I don't see the how the multipath draft w= ould be incompatible with the multi-topology draft. 
In fact,= those two drafts are two different approaches to solve different problems. T= his olsrv2-multipath draft tries to make use of multiple parallel paths to s= end packets. It can even make use of the multiple topology to build multiple= paths -- this is, of course, not tested yet. But we wrote it as a possible e= xperiment to do in the "Motivation and Experiments to Be Conducted" section.=  

best

Jiazi
 
[snip]

= --Apple-Mail-997029F8-FC8E-469B-B017-4ED8CDB0D6E8-- From nobody Tue Oct 20 11:44:48 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36821A92E1 for ; Tue, 20 Oct 2015 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 2-RiVntnj0U2 for ; Tue, 20 Oct 2015 11:44:46 -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 CCEB11A92BB for ; Tue, 20 Oct 2015 11:44:45 -0700 (PDT) Received: by lffv3 with SMTP id v3so10367929lff.0 for ; Tue, 20 Oct 2015 11:44: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:content-type; bh=QfdKMG/QaimwC22Uo8tP22cjHNhHYXY7xXiTnP7pT5w=; b=uprABLN7VRYcgmZta4VscPT8YqyUnk1i9eLspjipLQim+2P3r45kYTr4enCRvKqctO bPM/pqz+4tVk2gZsAPuNKZAO8vuEyLmgkn+4m3g6H8+k6LHwT3Gbhwk9U50t6rwo1OJH /j6BXyDlRC7q7+no8BvlJ4ynC8I0cL2eX1NtyHid90qqv8MSMcdCT0Aq1HYl5ZAyF07T A7iPF3jv7dV6uY9OAwl/C43krYMfnZmoJJSgVg+nTPGGlnwA6dKVRFLZhk+PhHCLDZr9 S2tubjSz69kitxJ/CM1HW4D92Kc30DMESigdY8AX14kEmJ5KyzgXs8h+ZlUgekG9KOG9 Bc5A== MIME-Version: 1.0 X-Received: by 10.25.148.204 with SMTP id w195mr1858875lfd.77.1445366683891; Tue, 20 Oct 2015 11:44:43 -0700 (PDT) Received: by 10.25.80.194 with HTTP; Tue, 20 Oct 2015 11:44:43 -0700 (PDT) In-Reply-To: <72796CAF-F7CD-4DCE-9F83-859E596050D0@thomasclausen.org> References: <72796CAF-F7CD-4DCE-9F83-859E596050D0@thomasclausen.org> Date: Tue, 20 Oct 2015 20:44:43 +0200 Message-ID: From: John Dowdell To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11401d74c37f4f05228da74b Archived-At: Cc: "manet-ads@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] No MANET Meeting Scheduled for Yokohama X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 18:44:47 -0000 --001a11401d74c37f4f05228da74b Content-Type: text/plain; charset=UTF-8 Given also that both AODVv2 and DLEP are likely to be asking for last call, how do the chairs propose to move forwards in decision making? Since there is no meeting, we are unable to ask for last call in the meeting, nor do we have a forum to present the not inconsiderable progress that both drafts have made. What now? John On Saturday, 10 October 2015, Thomas Clausen wrote: > Given the significant volume of outstanding unresolved, and > raised-but-un-addressed, issues with current WG deliverables, and given > that rechartering has been announced but never discussed on the list, it > would have been more than reasonable to agree with the WG (by way of the > mailing list) in well in advance -- rather than for the chair to > unilaterally decide to cancel any further discussions at the WG meeting > *after* the deadline for "final agenda" has lapsed. > > As far as I understand, in the IETF WG decisions are made by way of > consensus among a populace larger than the WG chairs. > > > Thomas > > > On 10 Oct 2015, at 21:23, Stan Ratliff > wrote: > > > > Hello WG participants, > > > > Just an FYI - there's no MANET meeting scheduled for the upcoming IETF > in Yokohama. The consensus amongst the chairs was that we need to progress > the AODVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, > the thought was that a face-to-face isn't necessary; the work can and > should progress on the list. > > > > Both of the pending drafts (AODVv2 and DLEP) have new revisions coming - > most likely this next week. Please stay tuned for updates, and your review > & comments will be welcome and appreciated. > > > > 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 > --001a11401d74c37f4f05228da74b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given also that both AODVv2 and DLEP=C2=A0are likely to be asking for last = call, how do the chairs propose to move forwards in decision making? Since = there is no meeting, we are unable to ask for last call in the meeting, nor= do we have a forum=C2=A0to present the not inconsiderable progress that bo= th drafts have made.

What now?

= John

On Saturday, 10 October 2015, Thomas Clausen <ietf@thomasclausen.org> wrote:
Given the significant volume of outstanding unreso= lved, and raised-but-un-addressed, issues with current WG deliverables, and= given that rechartering has been announced but never discussed on the list= , it would have been more than reasonable to agree with the WG (by way of t= he mailing list) in well in advance -- rather than for the chair to unilate= rally decide to cancel any further discussions at the WG meeting *after* th= e deadline for "final agenda" has lapsed.

As far as I understand, in the IETF WG decisions are made by way of consens= us among a populace larger than the WG chairs.


Thomas

> On 10 Oct 2015, at 21:23, Stan Ratliff <ratlif= fstan@gmail.com> wrote:
>
> Hello WG participants,
>
> Just an FYI - there's no MANET meeting scheduled for the upcoming = IETF in Yokohama. The consensus amongst the chairs was that we need to prog= ress the AODVv2 and DLEP drafts, *then* proceed with a re-charter. Given th= at, the thought was that a face-to-face isn't necessary; the work can a= nd should progress on the list.
>
> Both of the pending drafts (AODVv2 and DLEP) have new revisions coming= - most likely this next week. Please stay tuned for updates, and your revi= ew & comments will be welcome and appreciated.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--001a11401d74c37f4f05228da74b-- From nobody Tue Oct 20 12:31:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5571B1AD0EA for ; Tue, 20 Oct 2015 12:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uacFGT2JHN8k for ; Tue, 20 Oct 2015 12:31:42 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 683E61AD350 for ; Tue, 20 Oct 2015 12:27:22 -0700 (PDT) Received: by wikq8 with SMTP id q8so61682143wik.1 for ; Tue, 20 Oct 2015 12:27:21 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=FHPCb1Gs2OaJ3VsIg4BFOAIU2ywyshhIBahkJNCiZtQ=; b=Czlm+nYCZYEnW6h62z2wYPWOqkrazexpptNYmPiJOGdRs/9yiP93QUEjNGs3Bca39V HLEFOEjRZwhVgbvB7Dw8+ZjE5YsWASUtq6B2VE9GFtDODPpjRvP4FUOUIH1CAgEnvLVo yV2m/i8m10r8YblVJOsq9Q/qsHzoRiL4QSGlOfwYT+qcjXpgzg2QJrnlp12Wdd5n1CfR ETMDVh90fZBqsScKXSiSuh75MaIdtSE2YlrAQcSvjmwkTSbwnDve0jbIA+bfOLGgKibD aINOILnKNG7Z9HdOwb3fCHNXDLVQi5OcsEiRXMivz38ojK/9nv9rvqXQxRqeMunVlYGF ddEA== X-Received: by 10.194.235.39 with SMTP id uj7mr6651749wjc.115.1445369241008; Tue, 20 Oct 2015 12:27:21 -0700 (PDT) Received: from [192.168.81.184] (88-98-8-213.dsl.zen.co.uk. [88.98.8.213]) by smtp.gmail.com with ESMTPSA id bk4sm5676259wjc.1.2015.10.20.12.27.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 12:27:20 -0700 (PDT) References: <72796CAF-F7CD-4DCE-9F83-859E596050D0@thomasclausen.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-0D73F776-FBBA-46C1-A18D-2964724B90F2 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12H321) From: Christopher Dearlove Date: Tue, 20 Oct 2015 20:27:19 +0100 To: John Dowdell Archived-At: Cc: "manet@ietf.org" , "manet-ads@tools.ietf.org" Subject: Re: [manet] No MANET Meeting Scheduled for Yokohama X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 19:31:44 -0000 --Apple-Mail-0D73F776-FBBA-46C1-A18D-2964724B90F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Even when there's a meeting, the formal last call happens on the mailing lis= t, and that's where consensus is judged. So it's quite possible to proceed. T= here's a loss in not having a meeting, but it's not catastrophic. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 20 Oct 2015, at 19:44, John Dowdell wrote= : >=20 > Given also that both AODVv2 and DLEP are likely to be asking for last call= , how do the chairs propose to move forwards in decision making? Since there= is no meeting, we are unable to ask for last call in the meeting, nor do we= have a forum to present the not inconsiderable progress that both drafts ha= ve made. >=20 > What now? >=20 > John >=20 >> On Saturday, 10 October 2015, Thomas Clausen wro= te: >> Given the significant volume of outstanding unresolved, and raised-but-un= -addressed, issues with current WG deliverables, and given that rechartering= has been announced but never discussed on the list, it would have been more= than reasonable to agree with the WG (by way of the mailing list) in well i= n advance -- rather than for the chair to unilaterally decide to cancel any f= urther discussions at the WG meeting *after* the deadline for "final agenda"= has lapsed. >>=20 >> As far as I understand, in the IETF WG decisions are made by way of conse= nsus among a populace larger than the WG chairs. >>=20 >>=20 >> Thomas >>=20 >> > On 10 Oct 2015, at 21:23, Stan Ratliff wrote: >> > >> > Hello WG participants, >> > >> > Just an FYI - there's no MANET meeting scheduled for the upcoming IETF i= n Yokohama. The consensus amongst the chairs was that we need to progress th= e AODVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, the t= hought was that a face-to-face isn't necessary; the work can and should prog= ress on the list. >> > >> > Both of the pending drafts (AODVv2 and DLEP) have new revisions coming -= most likely this next week. Please stay tuned for updates, and your review &= comments will be welcome and appreciated. >> > >> > Regards, >> > Stan >> > _______________________________________________ >> > 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-0D73F776-FBBA-46C1-A18D-2964724B90F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Even when there's a meeting, the forma= l last call happens on the mailing list, and that's where consensus is judge= d. So it's quite possible to proceed. There's a loss in not having a meeting= , but it's not catastrophic.

--  
Christopher Dearlove
=

On 20 Oct 201= 5, at 19:44, John Dowdell <john.dowdell.ietf@gmail.com> wrote:

Given also that both AODVv2 and DLEP are likely to be asking for= last call, how do the chairs propose to move forwards in decision making? S= ince there is no meeting, we are unable to ask for last call in the meeting,= nor do we have a forum to present the not inconsiderable progress that= both drafts have made.

What now?

John

On Saturday, 10 October 2015, Thomas Clausen <ietf@thomasclausen.org> wrote:
Given the significant volume of outstanding unresolve= d, and raised-but-un-addressed, issues with current WG deliverables, and giv= en that rechartering has been announced but never discussed on the list, it w= ould have been more than reasonable to agree with the WG (by way of the mail= ing list) in well in advance -- rather than for the chair to unilaterally de= cide to cancel any further discussions at the WG meeting *after* the deadlin= e for "final agenda" has lapsed.

As far as I understand, in the IETF WG decisions are made by way of consensu= s among a populace larger than the WG chairs.


Thomas

> On 10 Oct 2015, at 21:23, Stan Ratliff <ratliffstan@gmail.com> wrote:
>
> Hello WG participants,
>
> Just an FYI - there's no MANET meeting scheduled for the upcoming IETF i= n Yokohama. The consensus amongst the chairs was that we need to progress th= e AODVv2 and DLEP drafts, *then* proceed with a re-charter. Given that, the t= hought was that a face-to-face isn't necessary; the work can and should prog= ress on the list.
>
> Both of the pending drafts (AODVv2 and DLEP) have new revisions coming -= most likely this next week. Please stay tuned for updates, and your review &= amp; comments will be welcome and appreciated.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
man= et@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-0D73F776-FBBA-46C1-A18D-2964724B90F2-- From nobody Tue Oct 20 12:33:42 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C01B1ACE7D for ; Tue, 20 Oct 2015 12:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: 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_Pv2I4croAi for ; Tue, 20 Oct 2015 12:33:39 -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 B45E81B2A87 for ; Tue, 20 Oct 2015 12:32:06 -0700 (PDT) IronPort-PHdr: 9a23:TSVYuxeKGO6jShmf+NPQlJ5alGMj4u6mDksu8pMizoh2WeGdxc+7ZB7h7PlgxGXEQZ/co6odzbGG7ua4ASdZuM7JmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbviptuLO04R3WL1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu2pN5g/GJ5fDDJuH2cq6MDvsVGXTwyP4D0QVXoanx5MRQnI8B/SUZL4sy+8ve14jm3SAc3xSLkvER+m5rpwRRmg3CYKKzAR7GHQj8Vrh6ZSvQmsoVp42YGCM6+PM/8rNJnUYdcbS2QFFv1NXipFD5L2J98UFeMdOedWoaH8q1oUoBCiQw+hGLW8mXdzmnbq0PhigKwaGgbc0Vl4Eg== X-IronPort-AV: E=Sophos;i="5.17,708,1437451200"; d="scan'208,217";a="102063" X-IPAS-Result: A2CoBABDliZW/8r6+gpdGQEBAQEOAQEBgjuBIW8Gvi2BUwcXAQmFfQIcgV0TAQEBAQEBAQGBCYImggcBAQEBAgEBAQEgCkELBQsCAQYCEQQBAQEnAwICAh8GCxQJCAIEAQ0FCIgTAwoNCJMfnTeOGA2EfgEBAQEBAQEBAQEBAQEBAQEBAQEBARQBAwaGc4R8glCCOQQGAYJpgUUFliQBiyiBb4FfhD+OPoNdg28iAYRDcoRhgQYBAQE From: "Ratliff, Stanley" To: John Dowdell , Thomas Clausen Thread-Topic: [manet] No MANET Meeting Scheduled for Yokohama Thread-Index: AQHRC2dovl3DZ6YCsESOhEEkgtiLfZ50xHoQ Date: Tue, 20 Oct 2015 19:31:16 +0000 Message-ID: References: <72796CAF-F7CD-4DCE-9F83-859E596050D0@thomasclausen.org> 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_ed99aa88783e4d8cb1b4d87a494ec4c6VAUSDITCHM3idirectnet_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" , "manet-ads@tools.ietf.org" Subject: Re: [manet] No MANET Meeting Scheduled for Yokohama X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 19:33:41 -0000 --_000_ed99aa88783e4d8cb1b4d87a494ec4c6VAUSDITCHM3idirectnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Sm9obiwNCg0KV0dMQyBtYXkgYmUgcmVxdWVzdGVkL2NvbnNlbnN1cyBkZXRlcm1pbmVkIG9uIHRo ZSBtYWlsaW5nIGxpc3QuDQoNCkFzIGl0IHJlZ2FyZHMgYSBmb3J1bSB0byDigKbigJ1wcmVzZW50 IHRoZSBub3QgaW5jb25zaWRlcmFibGUgcHJvZ3Jlc3MgdGhhdCBib3RoIGRyYWZ0cyBoYXZlIG1h ZGXigJ0sIEkgdGhpbmsgeW91IGp1c3QgcHJlc2VudGVkIHRoYXQgbm90aW9u4oCmIDstKQ0KDQpS ZWdhcmRzLA0KU3Rhbg0KDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gRG93ZGVsbA0KU2VudDogVHVlc2RheSwgT2N0b2JlciAy MCwgMjAxNSAyOjQ1IFBNDQpUbzogVGhvbWFzIENsYXVzZW4gPGlldGZAdGhvbWFzY2xhdXNlbi5v cmc+DQpDYzogbWFuZXQtYWRzQHRvb2xzLmlldGYub3JnOyBtYW5ldEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFttYW5ldF0gTm8gTUFORVQgTWVldGluZyBTY2hlZHVsZWQgZm9yIFlva29oYW1hDQoN CkdpdmVuIGFsc28gdGhhdCBib3RoIEFPRFZ2MiBhbmQgRExFUCBhcmUgbGlrZWx5IHRvIGJlIGFz a2luZyBmb3IgbGFzdCBjYWxsLCBob3cgZG8gdGhlIGNoYWlycyBwcm9wb3NlIHRvIG1vdmUgZm9y d2FyZHMgaW4gZGVjaXNpb24gbWFraW5nPyBTaW5jZSB0aGVyZSBpcyBubyBtZWV0aW5nLCB3ZSBh cmUgdW5hYmxlIHRvIGFzayBmb3IgbGFzdCBjYWxsIGluIHRoZSBtZWV0aW5nLCBub3IgZG8gd2Ug aGF2ZSBhIGZvcnVtIHRvIHByZXNlbnQgdGhlIG5vdCBpbmNvbnNpZGVyYWJsZSBwcm9ncmVzcyB0 aGF0IGJvdGggZHJhZnRzIGhhdmUgbWFkZS4NCg0KV2hhdCBub3c/DQoNCkpvaG4NCg0KT24gU2F0 dXJkYXksIDEwIE9jdG9iZXIgMjAxNSwgVGhvbWFzIENsYXVzZW4gPGlldGZAdGhvbWFzY2xhdXNl bi5vcmc8bWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmc+PiB3cm90ZToNCkdpdmVuIHRoZSBz aWduaWZpY2FudCB2b2x1bWUgb2Ygb3V0c3RhbmRpbmcgdW5yZXNvbHZlZCwgYW5kIHJhaXNlZC1i dXQtdW4tYWRkcmVzc2VkLCBpc3N1ZXMgd2l0aCBjdXJyZW50IFdHIGRlbGl2ZXJhYmxlcywgYW5k IGdpdmVuIHRoYXQgcmVjaGFydGVyaW5nIGhhcyBiZWVuIGFubm91bmNlZCBidXQgbmV2ZXIgZGlz Y3Vzc2VkIG9uIHRoZSBsaXN0LCBpdCB3b3VsZCBoYXZlIGJlZW4gbW9yZSB0aGFuIHJlYXNvbmFi bGUgdG8gYWdyZWUgd2l0aCB0aGUgV0cgKGJ5IHdheSBvZiB0aGUgbWFpbGluZyBsaXN0KSBpbiB3 ZWxsIGluIGFkdmFuY2UgLS0gcmF0aGVyIHRoYW4gZm9yIHRoZSBjaGFpciB0byB1bmlsYXRlcmFs bHkgZGVjaWRlIHRvIGNhbmNlbCBhbnkgZnVydGhlciBkaXNjdXNzaW9ucyBhdCB0aGUgV0cgbWVl dGluZyAqYWZ0ZXIqIHRoZSBkZWFkbGluZSBmb3IgImZpbmFsIGFnZW5kYSIgaGFzIGxhcHNlZC4N Cg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgaW4gdGhlIElFVEYgV0cgZGVjaXNpb25zIGFyZSBt YWRlIGJ5IHdheSBvZiBjb25zZW5zdXMgYW1vbmcgYSBwb3B1bGFjZSBsYXJnZXIgdGhhbiB0aGUg V0cgY2hhaXJzLg0KDQoNClRob21hcw0KDQo+IE9uIDEwIE9jdCAyMDE1LCBhdCAyMToyMywgU3Rh biBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5jb208amF2YXNjcmlwdDo7Pj4gd3JvdGU6DQo+ DQo+IEhlbGxvIFdHIHBhcnRpY2lwYW50cywNCj4NCj4gSnVzdCBhbiBGWUkgLSB0aGVyZSdzIG5v IE1BTkVUIG1lZXRpbmcgc2NoZWR1bGVkIGZvciB0aGUgdXBjb21pbmcgSUVURiBpbiBZb2tvaGFt YS4gVGhlIGNvbnNlbnN1cyBhbW9uZ3N0IHRoZSBjaGFpcnMgd2FzIHRoYXQgd2UgbmVlZCB0byBw cm9ncmVzcyB0aGUgQU9EVnYyIGFuZCBETEVQIGRyYWZ0cywgKnRoZW4qIHByb2NlZWQgd2l0aCBh IHJlLWNoYXJ0ZXIuIEdpdmVuIHRoYXQsIHRoZSB0aG91Z2h0IHdhcyB0aGF0IGEgZmFjZS10by1m YWNlIGlzbid0IG5lY2Vzc2FyeTsgdGhlIHdvcmsgY2FuIGFuZCBzaG91bGQgcHJvZ3Jlc3Mgb24g dGhlIGxpc3QuDQo+DQo+IEJvdGggb2YgdGhlIHBlbmRpbmcgZHJhZnRzIChBT0RWdjIgYW5kIERM RVApIGhhdmUgbmV3IHJldmlzaW9ucyBjb21pbmcgLSBtb3N0IGxpa2VseSB0aGlzIG5leHQgd2Vl ay4gUGxlYXNlIHN0YXkgdHVuZWQgZm9yIHVwZGF0ZXMsIGFuZCB5b3VyIHJldmlldyAmIGNvbW1l bnRzIHdpbGwgYmUgd2VsY29tZSBhbmQgYXBwcmVjaWF0ZWQuDQo+DQo+IFJlZ2FyZHMsDQo+IFN0 YW4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bWFuZXQgbWFpbGluZyBsaXN0DQo+IG1hbmV0QGlldGYub3JnPGphdmFzY3JpcHQ6Oz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQpt YW5ldEBpZXRmLm9yZzxqYXZhc2NyaXB0Ojs+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGNvbnRhaW5zCmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwgd2hpY2gg bWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5CmFuZC9vciBjb25maWRlbnRpYWwuIEl0IGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbApvciBlbnRpdHkg dG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBvcmlnaW5hbApy ZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGUgZW1h aWwgdG8gdGhlCmludGVuZGVkIHJlY2lwaWVudCwgYmUgYWR2aXNlZCB0aGF0IHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIGFuZCB0aGF0IGFueSB1c2UsIGRpc3NlbWluYXRp b24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvcgpjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgZW1haWwKaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyLgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_ed99aa88783e4d8cb1b4d87a494ec4c6VAUSDITCHM3idirectnet_ 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 b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpvaG4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldHTEMgbWF5IGJlIHJlcXVlc3RlZC9jb25zZW5zdXMg ZGV0ZXJtaW5lZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBpdCByZWdhcmRzIGEgZm9ydW0gdG8g4oCm4oCdcHJlc2Vu dCB0aGUgbm90IGluY29uc2lkZXJhYmxlIHByb2dyZXNzIHRoYXQgYm90aCBkcmFmdHMgaGF2ZSBt YWRl4oCdLCBJIHRoaW5rIHlvdSBqdXN0IHByZXNlbnRlZCB0aGF0IG5vdGlvbuKApiA7LSk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPGJyPg0KU3Rh bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtYW5ldCBbbWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gRG93ZGVsbDxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDIwLCAyMDE1IDI6NDUgUE08YnI+DQo8Yj5U bzo8L2I+IFRob21hcyBDbGF1c2VuICZsdDtpZXRmQHRob21hc2NsYXVzZW4ub3JnJmd0Ozxicj4N CjxiPkNjOjwvYj4gbWFuZXQtYWRzQHRvb2xzLmlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBObyBNQU5FVCBNZWV0aW5nIFNjaGVkdWxlZCBm b3IgWW9rb2hhbWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5HaXZlbiBhbHNvIHRoYXQgYm90aCBBT0RWdjIgYW5kIERMRVAmbmJzcDthcmUgbGlrZWx5IHRv IGJlIGFza2luZyBmb3IgbGFzdCBjYWxsLCBob3cgZG8gdGhlIGNoYWlycyBwcm9wb3NlIHRvIG1v dmUgZm9yd2FyZHMgaW4gZGVjaXNpb24gbWFraW5nPyBTaW5jZSB0aGVyZSBpcyBubyBtZWV0aW5n LCB3ZSBhcmUgdW5hYmxlIHRvIGFzayBmb3IgbGFzdCBjYWxsIGluIHRoZSBtZWV0aW5nLCBub3Ig ZG8gd2UgaGF2ZSBhIGZvcnVtJm5ic3A7dG8NCiBwcmVzZW50IHRoZSBub3QgaW5jb25zaWRlcmFi bGUgcHJvZ3Jlc3MgdGhhdCBib3RoIGRyYWZ0cyBoYXZlIG1hZGUuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IG5vdz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9objxicj4NCjxicj4NCk9uIFNh dHVyZGF5LCAxMCBPY3RvYmVyIDIwMTUsIFRob21hcyBDbGF1c2VuICZsdDs8YSBocmVmPSJtYWls dG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyI+aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkdpdmVuIHRoZSBzaWduaWZpY2FudCB2b2x1bWUgb2Ygb3V0c3RhbmRpbmcgdW5yZXNvbHZlZCwg YW5kIHJhaXNlZC1idXQtdW4tYWRkcmVzc2VkLCBpc3N1ZXMgd2l0aCBjdXJyZW50IFdHIGRlbGl2 ZXJhYmxlcywgYW5kIGdpdmVuIHRoYXQgcmVjaGFydGVyaW5nIGhhcyBiZWVuIGFubm91bmNlZCBi dXQgbmV2ZXIgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LCBpdCB3b3VsZCBoYXZlIGJlZW4gbW9yZSB0 aGFuIHJlYXNvbmFibGUNCiB0byBhZ3JlZSB3aXRoIHRoZSBXRyAoYnkgd2F5IG9mIHRoZSBtYWls aW5nIGxpc3QpIGluIHdlbGwgaW4gYWR2YW5jZSAtLSByYXRoZXIgdGhhbiBmb3IgdGhlIGNoYWly IHRvIHVuaWxhdGVyYWxseSBkZWNpZGUgdG8gY2FuY2VsIGFueSBmdXJ0aGVyIGRpc2N1c3Npb25z IGF0IHRoZSBXRyBtZWV0aW5nICphZnRlciogdGhlIGRlYWRsaW5lIGZvciAmcXVvdDtmaW5hbCBh Z2VuZGEmcXVvdDsgaGFzIGxhcHNlZC48YnI+DQo8YnI+DQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5k LCBpbiB0aGUgSUVURiBXRyBkZWNpc2lvbnMgYXJlIG1hZGUgYnkgd2F5IG9mIGNvbnNlbnN1cyBh bW9uZyBhIHBvcHVsYWNlIGxhcmdlciB0aGFuIHRoZSBXRyBjaGFpcnMuPGJyPg0KPGJyPg0KPGJy Pg0KVGhvbWFzPGJyPg0KPGJyPg0KJmd0OyBPbiAxMCBPY3QgMjAxNSwgYXQgMjE6MjMsIFN0YW4g UmF0bGlmZiAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDo7Ij5yYXRsaWZmc3RhbkBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZWxsbyBXRyBwYXJ0aWNpcGFudHMs PGJyPg0KJmd0Ozxicj4NCiZndDsgSnVzdCBhbiBGWUkgLSB0aGVyZSdzIG5vIE1BTkVUIG1lZXRp bmcgc2NoZWR1bGVkIGZvciB0aGUgdXBjb21pbmcgSUVURiBpbiBZb2tvaGFtYS4gVGhlIGNvbnNl bnN1cyBhbW9uZ3N0IHRoZSBjaGFpcnMgd2FzIHRoYXQgd2UgbmVlZCB0byBwcm9ncmVzcyB0aGUg QU9EVnYyIGFuZCBETEVQIGRyYWZ0cywgKnRoZW4qIHByb2NlZWQgd2l0aCBhIHJlLWNoYXJ0ZXIu IEdpdmVuIHRoYXQsIHRoZSB0aG91Z2h0IHdhcyB0aGF0IGEgZmFjZS10by1mYWNlDQogaXNuJ3Qg bmVjZXNzYXJ5OyB0aGUgd29yayBjYW4gYW5kIHNob3VsZCBwcm9ncmVzcyBvbiB0aGUgbGlzdC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBCb3RoIG9mIHRoZSBwZW5kaW5nIGRyYWZ0cyAoQU9EVnYyIGFu ZCBETEVQKSBoYXZlIG5ldyByZXZpc2lvbnMgY29taW5nIC0gbW9zdCBsaWtlbHkgdGhpcyBuZXh0 IHdlZWsuIFBsZWFzZSBzdGF5IHR1bmVkIGZvciB1cGRhdGVzLCBhbmQgeW91ciByZXZpZXcgJmFt cDsgY29tbWVudHMgd2lsbCBiZSB3ZWxjb21lIGFuZCBhcHByZWNpYXRlZC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgU3Rhbjxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1hbmV0IG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0iamF2YXNjcmlwdDo7Ij5tYW5ldEBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0iamF2 YXNjcmlwdDo7Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6ICMwMDMz NjY7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5UaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdp dGggaXQgY29udGFpbnM8YnI+aW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUg cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnk8YnI+YW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsPGJyPm9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIG9yaWdpbmFsPGJy PnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBl bWFpbCB0byB0aGU8YnI+aW50ZW5kZWQgcmVjaXBpZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbDxicj5pbiBlcnJvciwgYW5kIHRoYXQgYW55IHVzZSwgZGlz c2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yPGJyPmNvcHlpbmcgb2YgdGhpcyBl bWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlbWFpbDxi cj5pbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBz ZW5kZXIuPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ed99aa88783e4d8cb1b4d87a494ec4c6VAUSDITCHM3idirectnet_-- From nobody Tue Oct 20 13:00:14 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D06C1AD0EA for ; Tue, 20 Oct 2015 13:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 wAj3yEUeCWAR for ; Tue, 20 Oct 2015 13:00:10 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450: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 B2A631ACE76 for ; Tue, 20 Oct 2015 13:00:09 -0700 (PDT) Received: by wicll6 with SMTP id ll6so44944640wic.1 for ; Tue, 20 Oct 2015 13:00:08 -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:content-type; bh=U/tdAyATvI71/9ySh9pPrmM+J4cj5HwbHMCpEpkpFDU=; b=n2jqL48TwVNTzvo7bxb0da2yJdV8H3qzT7qFxObGQBIraVp4oqhlVwDkAfk1jI/9XX Lz1VWbX360rNtub8e2pJ0Yge31ftLjGM4rYm//10vHeSAJiHrqS6O516xcS+V8E7fRAH 3qP5316k8T+MRM7S5s2PAL9P5jF5qLbjOeuriz0raFoikGJoiYUU5jsZDEMi3I5A0Cbs 5xSl9/OLTNoYfJXsAJXUPvsgx8lzt4JxW6/O2PMz63PWhH3hhWgnF6ccYNnDKEG0qGdU nTuKKBIMCz2ciO50LWG8FaWCU8Cu9FjJSufNzbO84HMmFuWlRrvRtzXUE9Zys67oP1F/ paxw== MIME-Version: 1.0 X-Received: by 10.194.184.166 with SMTP id ev6mr6597587wjc.125.1445371208211; Tue, 20 Oct 2015 13:00:08 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.43.7 with HTTP; Tue, 20 Oct 2015 13:00:08 -0700 (PDT) In-Reply-To: References: <3EBFC7E9-BFE7-43D1-9DD2-12248D78F0B9@gmail.com> Date: Tue, 20 Oct 2015 22:00:08 +0200 X-Google-Sender-Auth: fwh2aF2BepMsEAaXdSwB5EFJtl8 Message-ID: From: Jiazi YI To: Stan Ratliff Content-Type: multipart/alternative; boundary=047d7bae49326f263905228eb59b Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 20:00:12 -0000 --047d7bae49326f263905228eb59b Content-Type: text/plain; charset=UTF-8 Thanks very much, Stan. I agree with the decision, and am happy to work with the WG to have the issues resolved. cheers Jiazi On Tue, Oct 20, 2015 at 4:56 PM, Stan Ratliff wrote: > All, > > Based on this discussion, and an email or two between myself and Justin > and Ulrich, here's the plan going forward: > > I've just moved the document back to "WG Document" state. I think there is > general agreement that there are issues to be addressed, and that the doc > isn't yet ready for publication. We have a good discussion going here on > the list; hopefully that discussion will lead to a resolution on all > issues. At that point, we can reissue WGLC when the WG consensus indicates > that the doc is ready. > > Other opinions? Questions? Flames? > > Regards, > Stan > > > On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen > wrote: > >> Just two quick points... >> >> On 20 Oct 2015, at 02:02, Jiazi YI wrote: >> >> Hi, >> >> >>> >>> Sorting out MPRs and interworking can't be fixed with just a SHOULD. >>> There isn't even a proof on the table that making it a MUST works. This is >>> not good enough to proceed. >>> >>> No, creating a TC is anything but mandatory. It's mandatory under >>> certain conditions, which may not apply. >>> >> >> Specifically, a TC is mandatory only if having a non-empty MPR-selector >> set, or a non-empty Attached Network set -- or, having recently had >> non-empty such sets (in which case empty TCs are mandated for a bit to >> "purge stale information"). >> >> A case where an OLSRv2-router will not send TCs would, for example, be >> with MPR_WILLING == WILL_NEVER. And a case where it likely would not would >> be a router with WILL_NEVER+1, in a dense network. >> >> Again, this misunderstanding is fundamental to whether the protocol will >>> interwork with basic OLSRv2. >>> >> >> The point I want to make is: >> - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages. >> - I'm skeptical to making it a MUST, because even we don't consider it >> at all, it won't bring any negative impact to the network. Although a >> router with this extension will find less SOURCE_ROUTE enabled routers in >> that case, it can still work perfectly with other OLSRv2-only routers like >> a normal OLSRv2 router. >> >> >> Gotta consider this, at least, these ways: >> >> "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the >> -MP network"? >> >> "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the >> OLSRv2 network"? >> >> "Will an OLSRv2-MP router be able to function in an OLSRv2 network"? >> >> "Will an OLSRv2 router be able to function in an OLSRv2-MP network"? >> >> And then, of course, what happens if it's not "a single" but "a bunch of" >> .... >> >> Thomas >> >> I haven't had time to consider the source routing. But if it's being done >>> by IP, just say so and don't confuse matters here. >>> >> >> Agree. >> >> >>> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs >>> to go back, have some major changes made, and re-enter pre-WGLC discussion. >>> >> >> The authors are, of course, willing to discuss related issues with the WG >> and have them appropriately resolved. >> >> >>> >>> (A point I've not previously made is that we have multitopology now out >>> of the IESG and heading to be an RFC soon. I'd not be happy with this draft >>> if incompatible with that, also a discussion worth having.) >>> >> >> I don't see the how the multipath draft would be incompatible with the >> multi-topology draft. >> In fact, those two drafts are two different approaches to solve different >> problems. This olsrv2-multipath draft tries to make use of multiple >> parallel paths to send packets. It can even make use of the multiple >> topology to build multiple paths -- this is, of course, not tested yet. But >> we wrote it as a possible experiment to do in the "Motivation and >> Experiments to Be Conducted" section. >> >> best >> >> Jiazi >> >> >> [snip] > > > --047d7bae49326f263905228eb59b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks very much, Stan.=C2=A0

I agree with the decision, and am happy to work with the WG to have the i= ssues resolved.=C2=A0

cheers

<= div>Jiazi

On Tue, Oct 20, 2015 at 4:56 PM, Stan Ratliff <ratliffstan@gmail.co= m> wrote:
= All,=C2=A0

Based on this discussion, and an email or two= between myself and Justin and Ulrich, here's the plan going forward:= =C2=A0

I've just moved the document back to &q= uot;WG Document" state. I think there is general agreement that there = are issues to be addressed, and that the doc isn't yet ready for public= ation. We have a good discussion going here on the list; hopefully that dis= cussion will lead to a resolution on all issues. At that point, we can reis= sue WGLC when the WG consensus indicates that the doc is ready.=C2=A0
=

Other opinions? Questions?=C2=A0 Flames?=C2=A0

Regards,
Stan


On = Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen <ietf@thomasclausen.org= > wrote:
Just two quick points...

On 20 = Oct 2015, at 02:02, Jiazi YI <ietf@jiaziyi.com> wrote:

Hi,=C2=A0
=C2=A0

Sorting out MPRs and interworking can't= be fixed with just a SHOULD. There isn't even a proof on the table tha= t making it a MUST works. This is not good enough to proceed.
No, creating a TC is anything but mandatory. It's mandatory= under certain conditions, which may not apply.

Specifically, a TC is man= datory only if having a non-empty MPR-selector set, or a non-empty Attached= Network set -- or, having recently had non-empty such sets (in which case = empty TCs are mandated for a bit to "purge stale information").
A case where an OLSRv2-router will not send TCs would, fo= r example, be with MPR_WILLING =3D=3D WILL_NEVER. And a case where it likel= y would not would be a router with WILL_NEVER+1, in a dense network.

Ag= ain, this misunderstanding is fundamental to whether the protocol will inte= rwork with basic OLSRv2.

The po= int I want to make is:
=C2=A0 =C2=A0- The=C2=A0SOURCE_ROUTE TLV are sent over both HELLO and TC messages.= =C2=A0
=C2=A0 =C2=A0- I&#= 39;m skeptical to making it a MUST, because even we don't consider it a= t all, it won't bring any negative impact to the network. Although a ro= uter with this extension will find less SOURCE_ROUTE enabled routers in tha= t case, it can still work perfectly with other OLSRv2-only routers like a n= ormal OLSRv2 router.=C2=A0

Gotta consider this, at least, these ways:

"Will the presence of an OLSRv2 router in an OLSRv2-MP networ= k break the -MP network"?=C2=A0

"Will the presence of an OLSRv2-MP router in = an OLSRv2 network break the OLSRv2 network"?

"Will an OLSRv2-MP router be able to function in an OLSRv2 netw= ork"?

"Will an OLSRv2 router be able to function in an OLSRv2-= MP network"?

And then, of course, what happens if it&= #39;s not "a single" but "a bunch of" ....
Thomas

I haven't had time to consider the sour= ce routing. But if it's being done by IP, just say so and don't con= fuse matters here.

Agree.=C2=A0=
=C2=A0
This draft i= s, I'm afraid, not in a suitable state for a WGLC. It needs to go back,= have some major changes made, and re-enter pre-WGLC discussion.

The authors are, of course, willing to di= scuss related issues with the WG and have them appropriately resolved.=C2= =A0
=C2=A0

(A point I've not previously made is that we have multitopology n= ow out of the IESG and heading to be an RFC soon. I'd not be happy with= this draft if incompatible with that, also a discussion worth having.)
=

I don't see the how the mu= ltipath draft would be incompatible with the multi-topology draft.=C2=A0
In fact, those two drafts are two different approaches to solve dif= ferent problems. This olsrv2-multipath draft tries to make use of multiple = parallel paths to send packets. It can even make use of the multiple topolo= gy to build multiple paths -- this is, of course, not tested yet. But we wr= ote it as a possible experiment to do in the "Motivation and Experimen= ts to Be Conducted" section.=C2=A0

best
=

Jiazi
=C2=A0
[snip]

=
--047d7bae49326f263905228eb59b-- From nobody Thu Oct 29 22:33:29 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0185F1A0371 for ; Thu, 29 Oct 2015 22:33:28 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsnW6HIdIgXa for ; Thu, 29 Oct 2015 22:33:26 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 63A4F1B3679 for ; Thu, 29 Oct 2015 22:33:26 -0700 (PDT) Received: by padhy1 with SMTP id hy1so57159829pad.0 for ; Thu, 29 Oct 2015 22:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=p+wII6MYp+Q+NRm/MV9Vh6NfpgW1FZjDK2crtuX7DFA=; b=YIxh1OgzyNmksYUT0D1cWFnO5U8cjPFm/R++1jTyGDUSjEJfn+zyyWWdRYpU1Tn9xl s4rrnw1A0ihJGjfwHGs1Pm3JgzekGtygg/sWQI9CcQfDG+C3sfkUbIQ73FbOqR/CTFX/ hdLUrtwAf/PLV9WJObF0QHmj/QUDyMl6tHaCzgzRznX3L8YrdfWWmv82bv4oCmyZRqO7 NeunL1nHJTEzunnf16ZvdKmjmksFcwWhqfCWcJRlPg3mG3Alajnay1DMWuixahCkKPYF caPIE5bC5+SA1zLQSCkNVhIJdl0OzqTWLjVWNvKeRmLOrHZ9wQ0a50vdqY9O8rDacQxn j32w== X-Received: by 10.68.98.195 with SMTP id ek3mr6421628pbb.36.1446183206093; Thu, 29 Oct 2015 22:33:26 -0700 (PDT) Received: from [192.168.0.13] ([182.18.238.19]) by smtp.gmail.com with ESMTPSA id yp9sm5634657pab.1.2015.10.29.22.33.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2015 22:33:25 -0700 (PDT) To: manet@ietf.org From: Hazel Ann Message-ID: <56330127.6060404@gmail.com> Date: Fri, 30 Oct 2015 13:33:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [manet] 2016 Call for Papers: ICETC Lebanon - Education Technologies and Computers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 05:33:28 -0000 The submission is open until March 21, 2016. Please consider submitting your papers to ICETC2016. ****All registered papers will be published in publisher's Digital Library.**** BEST registered papers will be published in one of the following special issues provided that the author do major improvements and extension within the time frame set by the conference and his/her paper is approved by the chief editor. ================================================================================================= The Third International Conference on Education Technologies and Computers (ICETC2016) April 21-23, 2016 » Beirut, Lebanon Faculty of Engineering - Lebanese University Website: http://sdiwc.net/conferences/icetc2016/ ================ IMPORTANT DATES ================ Submission Dates Open from now until March 21, 2016 Notification of Acceptance March 31, 2016 or 4 weeks from the submission date Camera Ready Submission Open until April 11, 2016 Registration Open until April 11, 2016 Conference Dates April 21-23, 2016 You are invited to participate in The Third International Conference on Education Technologies and Computers (ICETC2016) that will be held at Faculty of Engineering – Lebanese University, Campus of Hadath, Beirut, Lebanon on April 21-23, 2016. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. ICETC2016 welcomes papers on the following (but not limited to) Education Technologies and Computers and related research topics. SUBMISSION LINK: http://sdiwc.net/conferences/icetc2016/openconf/openconf.php EMAIL: icetc16@sdiwc.net