From nobody Tue Sep 2 15:30:55 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FE91A0AD7; Tue, 2 Sep 2014 15:30:53 -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 GMNnGZiacr_V; Tue, 2 Sep 2014 15:30:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EFD1A88FC; Tue, 2 Sep 2014 15:30:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140902223048.4663.25251.idtracker@ietfa.amsl.com> Date: Tue, 02 Sep 2014 15:30:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/1rdsck_udgy350_P-iNC6nqq2ow Cc: netext@ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Stephen Farrell's No Objection on draft-ietf-netext-pmip-cp-up-separation-07: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:30:53 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-pmip-cp-up-separation-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 http://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: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. From nobody Wed Sep 3 06:09:59 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388091A0282; Wed, 3 Sep 2014 06:09:56 -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 iVQUN0FCIazN; Wed, 3 Sep 2014 06:09:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C48C91A8A51; Wed, 3 Sep 2014 06:09:50 -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: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903130950.31175.63915.idtracker@ietfa.amsl.com> Date: Wed, 03 Sep 2014 06:09:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/CVVF-7GWWe_QlIecxGek7aC9RJY Cc: netext mailing list , netext chair , RFC Editor Subject: [netext] Protocol Action: 'Separation of Control and User Plane for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-pmip-cp-up-separation-07.txt) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 13:09:56 -0000 The IESG has approved the following document: - 'Separation of Control and User Plane for Proxy Mobile IPv6' (draft-ietf-netext-pmip-cp-up-separation-07.txt) as Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ Technical Summary: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a Mobile Access Gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the Local Mobility Anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has sailed through the WG process because the problem that it aims to solve is clear and has strong consensus among the WG members. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No known implementations of the protocol exist at this time. No vendors have expressly stated a plan to implement this specification either. The I-D acknowledges the reviewers who have helped improve the I-D. Personnel: Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman From nobody Wed Sep 3 23:09:48 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321C1A06F2; Wed, 3 Sep 2014 23:09:45 -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 sChoLWtxeLjt; Wed, 3 Sep 2014 23:09:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 878651A06C0; Wed, 3 Sep 2014 23:09:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904060943.7623.46411.idtracker@ietfa.amsl.com> Date: Wed, 03 Sep 2014 23:09:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/k_XiCjkFu32uNIP6MFTys-XhiJM Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 06:09:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Logical Interface Support for multi-mode IP Hosts Authors : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-10.txt Pages : 19 Date : 2014-09-03 Abstract: A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-logical-interface-support-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 8 06:52:23 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6BF1A8831; Mon, 8 Sep 2014 06:52:21 -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 A9lPMuJNB4zt; Mon, 8 Sep 2014 06:52:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B031A8830; Mon, 8 Sep 2014 06:52:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908135220.25596.77206.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 06:52:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/MSoIRB3z2Ezy4j8BQEewSBvf4-o Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-03.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:52:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Extensions to the PMIPv6 Access Network Identifier Option Authors : Rajesh S. Pazhyannur Sebastian Speicher Sri Gundavelli Jouni Korhonen John Kaippallimalil Filename : draft-ietf-netext-ani-location-03.txt Pages : 11 Date : 2014-09-08 Abstract: Access Network Identifier (ANI) Mobility option was introduced in [RFC6757] enabling a MAG to convey identifiers like network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub- options to carry civic location and MAG group Identifier. This specification also defines a ANI Update timer sub-option that determines when and how often the ANI will be updated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-ani-location-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 9 13:00:00 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354951A016F for ; Tue, 9 Sep 2014 12:59: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 AM4DV68_wTBt for ; Tue, 9 Sep 2014 12:59:55 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8251F1A0100 for ; Tue, 9 Sep 2014 12:59:55 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so5103668wib.9 for ; Tue, 09 Sep 2014 12:59: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=X+S3bYnFJGSsZEtYD4K61ayGMUetrh7UscBAnT6rFkk=; b=rmTRKIm1PApx2On+/5a2RuUeLqiZoS2JYT0rQLbLqn2aSJ3or5DrVYy9jlgsB0HMQy ei1D4EkGG6/2uehP8viQrLc9LSYTrk4+dx1CnTFYeREVPN8YUniVbwJQO1ryhciV0K8O vne90xFZX1c+ForVgU6wcwcVOw/aaw9zyZCjSSo7Wxd6/2Oog9Lcf5IauXMeNNz+fv5/ F418lWBfIJnOMEEoZiuBOS8tvJL5RufS3rBlkO3b7NZvppVqyRAkWWMZA7CNv4HIxGDl I1DyeF7Mu37Lo7GQ/VYtH3YQOx2EVYXY70bpmUwZNmaPtw3GDppWLO9f8C5O8EO5g6ee DMEQ== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr32089151wiv.65.1410292794128; Tue, 09 Sep 2014 12:59:54 -0700 (PDT) Received: by 10.194.94.166 with HTTP; Tue, 9 Sep 2014 12:59:54 -0700 (PDT) Date: Tue, 9 Sep 2014 12:59:54 -0700 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f0405fe130502a7610a Archived-At: http://mailarchive.ietf.org/arch/msg/netext/5fTSyjff5dW-CJb4tsgcgGMPtqo Subject: [netext] Addition of text for IANA section of WiFi-EAP Attributes draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:59:57 -0000 --f46d043c7f0405fe130502a7610a Content-Type: text/plain; charset=UTF-8 Hello folks, background: draft-ietf-netext-wifi-epc-eap-attributes specifies a new IANA registry for EAP attributes, with a Specification Required clause. Jouni and Pierrick have agreed to be the Designated Experts for future IANA requests for assignments. proposal: the following text is proposed for the IANA Designated Expert's review of future requests for EAP attribute assignments from the above-mentioned registry. This text is a guidance for IANA, and I am including here for WG information. "The Designated Expert should review the requirements for new assignments based on factors including, but not limited to, the source of request (e.g., standards bodies), deployment needs (e.g., industry consortium, operator community) and experimental needs (e.g., academia, industrial labs). A document outlining the purpose of new assignments should accompany the request. Such a document could be a standards document, or a research project description. The Designated Expert should consider that there is sufficient evidence of potential usage both on the end-points (e.g., Mobile Devices etc.) and the infrastructure (e.g., AAA servers, gateways etc.)" Please let me know if you have any comments. Thanks. -Rajeev --f46d043c7f0405fe130502a7610a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello folks,

background:= draft-ietf-netext-wifi-epc-eap-attributes specifies a new IANA registry fo= r EAP attributes, with a Specification Required clause. Jouni and Pierrick = have agreed to be the Designated Experts for future IANA requests for assig= nments.=C2=A0

proposal: the following text is prop= osed for the IANA Designated Expert's review of future requests for EAP= attribute assignments from the above-mentioned registry.=C2=A0This text is a guidance fo= r IANA, and I am including here for WG information.=C2=A0
=
= "The Designated Expert should review the requirements for new assignme= nts based on factors including, but not limited to, the source of request (= e.g., standards bodies), deployment needs (e.g., industry consortium, opera= tor community) and experimental needs (e.g., academia, industrial labs). A = document outlining the purpose of new assignments should accompany the requ= est. Such a document could be a standards document, or a research project d= escription. The Designated Expert should consider that there is sufficient = evidence of potential usage both on the end-points (e.g., Mobile Devices et= c.) and the infrastructure (e.g., AAA servers, gateways etc.)"<= br>
<= br>
Please let me know if you have any comments.

<= div>Thanks.
<= br>
-Rajeev

--f46d043c7f0405fe130502a7610a-- From nobody Sun Sep 14 13:16:41 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809431A0270 for ; Sun, 14 Sep 2014 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 RpyvETotO_hM for ; Sun, 14 Sep 2014 13:16:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F881A0264 for ; Sun, 14 Sep 2014 13:16:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8EKGXb4026745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Sep 2014 20:16:33 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8EKGUc9007899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 14 Sep 2014 22:16:33 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 14 Sep 2014 22:16:30 +0200 Received: from DEMUMBX008.nsn-intra.net ([169.254.8.152]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Sun, 14 Sep 2014 22:16:30 +0200 From: "Riegel, Maximilian (NSN - DE/Munich)" To: "netext@ietf.org" Thread-Topic: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 Thread-Index: AQHPwgMFQZOAaa43Z0uG8e+pa8mTfpwBC/oA Date: Sun, 14 Sep 2014 20:16:29 +0000 Message-ID: <003101cfd058$c48a4850$4d9ed8f0$@nsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_003101cfd058c48a48504d9ed8f0nsncom_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 49344 X-purgate-ID: 151667::1410725794-00001FC1-43145392/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/nnshymeEtsmaTtvO8LjaEMxWO9k Cc: "draft-ietf-netext-logical-interface-support-09@tools.ietf.org" Subject: Re: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 20:16:39 -0000 --_000_003101cfd058c48a48504d9ed8f0nsncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd291bGQgbGlrZSB0byBwcm92aWRlIGEgZmV3IHJldmlldyBjb21tZW50cyBvbiB0 aGUgZHJhZnQ6DQoNCldoaWxlIHN0cm9uZ2x5IHN1cHBvcnRpbmcgdGhhdCB0aGUgSS1EIGlzIG1v dmluZyBmb3J3YXJkIGFuZCBmaW5hbGx5IGdldHRpbmcgcHVibGlzaGVkIGFzIEluZm9ybWF0aW9u YWwgUkZDIEkgZm91bmQgYSBudW1iZXIgb2Ygc2hvcnRjb21pbmdzIHdoaWNoIHNob3VsZCBiZSBh ZGRyZXNzZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQoNCi0gICAgVGhlIG92ZXJhbGwgc3RydWN0 dXJlIGlzIGxlYWRpbmcgdG8gcmVwbGljYXRpb24gb2YgaW5mb3JtYXRpb24gYW5kIGRvZXMgbm90 IHByb3ZpZGUgYSBjbGVhciBzdG9yeSBsaW5lLiBJIHdvdWxkIHJlY29tbWVuZCBhIHN0cnVjdHVy ZSBsaWtlDQoNCm8gICAgSW50cm9kdWN0aW9uDQoNCm8gICAgVGVybWlub2xvZ3kNCg0KbyAgICBQ cm9ibGVtIHN0YXRlbWVudA0KDQpvICAgIExpbmsgTGF5ZXIgaW50ZXJmYWNlIGJlaGF2aW9yDQoN Cm8gICAgTG9naWNhbCBJbnRlcmZhY2UgRnVuY3Rpb25hbCBEZXNjcmlwdGlvbg0KDQpvICAgIExv Z2ljYWwgSW50ZXJmYWNlIERlcGxveW1lbnQgRXhhbXBsZXMNCg0KLSAgICAoMS4gSW50cm9kdWN0 aW9uKQ0KDQotICAgICgyLiBUZXJtaW5vbG9neSkNCg0KbyAgICBJTUhPLCBhIFBJRiBpcyB0aGUg aW50ZXJmYWNlIGNvbWluZyBvdXQgb2YgdGhlIGhvc3QgdG8gdGhlIHBoeXNpY2FsIHdvcmxkLiBJ IHdvdWxkIHJlY29tbWVuZCB0byBjbGVhbiB1cCB0ZXJtaW5vbG9neSB0byBjbGVhcmx5IGlkZW50 aWZ5IHRoZSByZWxldmFudCBpbnRlcmZhY2VzIGluIHRoZSBjb21tdW5pY2F0aW9uIHN0YWNrLCBl LmcuIGJ5IGludHJvZHVjdGlvbiBvZiBhICdMaW5rIEludGVyZmFjZScgb3IgZXZlbiBhICdMaW5r IFNBUCcuIFRha2luZyBhIGxvb2sgaW50byBJRUVFIDgwMiBzcGVjaWZpY2F0aW9ucyBtYXkgaGVs cCB0byBmaW5kIGFwcHJvcHJpYXRlIHdvcmRpbmcuDQoNCi0gICAgKDMuIEhpZGluZyBMaW5rLWxh eWVyIFRlY2hub2xvZ2llcyAtIEFwcHJvYWNoZXMgYW5kIEFwcGxpY2FiaWxpdHkNCg0KbyAgICBU aXRsZSBpcyBzb21ld2hhdCBtaXNsZWFkaW5nOyB0aGUgdG9waWMgaXMgdG8gZW5hYmxlIGFuIElQ IGludGVyZmFjZSB0byBjb25uZWN0IHNlcXVlbnRpYWxseSBvciBzaW11bHRhbmVvdXMgdG8gbXVs dGlwbGUgZGlmZmVyZW50ICdMaW5rIFNBUHMnLg0KDQotICAgICgzLjIuMSBMaW5rIExheWVyIEFi c3RyYWN0aW9uIC0gQXBwcm9hY2hlcykNCg0KbyAgICBBYnN0cmFjdGlvbiBpcyBub3QgcmVhbGx5 IHRoZSBpc3N1ZTsgc3dpdGNoaW5nIGFuZCBtdWx0aXBsZXhpbmcgbXVsdGlwbGUgbGlua3MgaW50 byBvbmUgaXMgdGhlIHRvcGljLg0KDQpvICAgIFRleHQgb24gSUVFRSA4MDIgTGluayBMYXllciBz dXBwb3J0IHNob3VsZCBmb2N1cyBub3Qgb24gUEhZIHRlY2hub2xvZ2llcyBidXQgb24gdGhlIGRp ZmZlcmVuY2VzIGluIHRoZSAnTGluayBTQVBzJy4gSUVFRSA4MDIuMUFDIG1heSBiZSBvZiBncmVh dCBoZWxwIHRvIHVuZGVyc3RhbmQgdGhlIGNvbW1vbmFsaXRpZXMgYW5kIGRpZmZlcmVuY2VzIG9m IHRoZSBTQVBzIGFtb25nIHRoZSBkaWZmZXJlbnQgODAyIHRlY2hub2xvZ2llcy4NCg0KbyAgICAz R1BQIHJlcXVpcmVzIGEgbXVjaCBtb3JlIGNvbXByZWhlbnNpdmUgZGVzY3JpcHRpb24gaGVyZS4g VFMyMy40MDEgcHJvdmlkZXMgYSBnZW5lcmljIG5ldHdvcmsgYXJjaGl0ZWN0dXJlLCBidXQgdGhl IGRldGFpbHMgb2YgdGhlIGxpbmsgaW50ZXJmYWNlcyBhcmUgc3BlY2lmaWVkIHdpdGhpbiBvdGhl ciBkb2N1bWVudHMuDQoNCm8gICAgQSBsb2dpY2FsIGludGVyZmFjZSBoYXMgbm90IG5lY2Vzc2Fy aWx5IG11bHRpcGxlIHBoeXNpY2FsIGludGVyZmFjZXMgYmVuZWF0aC4gTmVpdGhlciBpcyBhIGxv Z2ljYWwgaW50ZXJmYWNlIGJvdW5kIHRvIHRoZSBhcHBsaWNhdGlvbnMgbWVudGlvbmVkIGluIHRo ZSBJLUQuDQoNCi0gICAgKDMuMiBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCkNCg0KbyAgICBJIHdv bmRlciBhYm91dCB0aGUgJ2Fib3ZlIHNvbHV0aW9ucycuIFdoaWNoIHNvbHV0aW9ucz8gSSBzZWUg b25seSBsaXN0aW5nIG9mIGNvbW1vbiBQSFlzIGFuZCB0ZWNobm9sb2d5IHRlcm1zICgnY29ubmVj dGlvbiBtYW5hZ2VyJywgQU5EU0YpLiBIb3cgZG8gdGhlc2UgcmVsYXRlIHRvIHRoZSBzb2x1dGlv bnM/DQoNCm8gICAgQm90aCAnbXVsdGkgdGVjaG5vbG9neSBzdXBwb3J0JyBhbmQgJ3NlcXVlbnRp YWwgdnMuIHNpbXVsdGFuZW91cyBhY2Nlc3MnIHNob3VsZCBiZSBleHBsYWluZWQgYnkgYSBmZXcg c2VudGVuY2VzLiBBdCB0aGlzIGxvY2F0aW9uIHRoZSB0ZXJtcyBhcmUgbm90IHNlbGYtZXhwbGFu YXRvcnkgeWV0Lg0KDQpvICAgIEkgYW0gbm90IGNsZWFyLCB3aGF0IHlvdSB3b3VsZCBsaWtlIHRv IGV4cGxhaW4gaW4gdGhpcyBzZWN0aW9uLiBTb21laG93IGl0IGxvb2tzIGxpa2UgYW4gZXh0ZW5z aW9uIHRvIHRoZSAnbGluayBsYXllciBzdXBwb3J0JyBhbmQgJ2xvZ2ljYWwgaW50ZXJmYWNlJyBw YXJhZ3JhcGhzIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLg0KDQotICAgICg0LiBUZWNobm9sb2d5 IFVzZSBDYXNlcykNCg0KbyAgICBMb29rcyBsaWtlIGFuIHJlcGV0aXRpb24gb2YgaW5mb3JtYXRp b24gb2YgdGhlIHByZXZpb3VzIHNlY3Rpb25zLg0KDQpvICAgIFBQUCB2cy4gTkJNQSB2cy4gQk1B IHJlcXVpcmVzIGNvbXByZWhlbnNpdmUgY29uc2lkZXJhdGlvbnMuDQoNCi0gICAgKDUuIExvZ2lj YWwgSW50ZXJmYWNlIEZ1bmN0aW9uYWwgRGV0YWlscykNCg0KbyAgICBMb2dpY2FsIEludGVyZmFj ZSBzaG91bGQgYmUgZGVmaW5lZCBpbmRlcGVuZGVudCBmcm9tIHBoeXNpY2FsIHdpcmVzLCBhcyBh IGxvZ2ljYWwgaW50ZXJmYWNlIG1heSBhbHNvIGJlIHVzZWQgd2l0aCAndHVubmVscycuDQoNCm8g ICAgSSBtaXNzIGNvbnNpZGVyYXRpb25zIGFib3V0IGludGVyZmFjZSBmdW5jdGlvbnMgbGlrZSBO RC9BUlAvREhDUC4gUHJvYmFibHkgdGhlIEktRCBzaG91bGQgbWFrZSBhIHJlZmVyZW5jZSB0byBJ UHY2IG5vZGUgcmVxdWlyZW1lbnRzIChSRkMgNjQzNCkgYW5kIHByb3ZpZGUgY29tbWVudHMgdG8g YWxsIHN0YXRlbWVudHMgd2hpY2ggcmVxdWlyZSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgdGhlIExJ RiwgZS5nLg0KDQrCpyAgV2hhdCBhcmUgdGhlIGlzc3VlcyBjb21pbmcgdXAgd2hlbiBjb21iaW5p bmcgYSBQUFAgbGluayB3aXRoIGFuIEV0aGVybmV0IGxpbmsgZm9yIG9uZSBsb2dpY2FsIGludGVy ZmFjZS4NCg0KbyAgICBJcyBGTE9XIG1hbmFnZW1lbnQgbWFuZGF0b3J5IGZvciBhbGwga2luZCBv ZiBMSUZzPyBJIHdvdWxkIGd1ZXNzLCB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIHRleHQgYmVsb25n cyB0byB0aGUgJ3NpbXVsdGFuZW91cyBhY2Nlc3MnIHNjZW5hcmlvLCBub3QgdG8gYWxsIHNjZW5h cmlvcy4NCg0KDQoNCi0gICAgT3ZlcmFsbCwgSSB3b3VsZCBhcHByZWNpYXRlIG1vcmUgdGhvcm91 Z2ggY29uc2lkZXJhdGlvbnMgYWJvdXQgdGhlIGlzc3VlcyBjb21pbmcgdXAgd2hlbiBjb21iaW5p bmcgbXVsdGlwbGUgZGlmZmVyZW50IGxpbmsgdHlwZXMsIGUuZy4gc3dpdGNoaW5nIGJldHdlZW4g YW4gRXRoZXJuZXQgYW5kIGEgUFBQIGxpbmsuIFdoYXQgYWJvdXQgcmVhY2hhYmlsaXR5IG9mIG90 aGVyIGhvc3RzIG9uIHRoZSBFdGhlcm5ldCB3aGVuIHNlbGVjdGluZyB0aGUgUFBQIGxpbms/IFdo YXQgYWJvdXQgbXVsdGljYXN0IHNlcnZpY2VzLCB3aGF0IGFib3V0IGEgbWl4IG9mIHN0YXRlZnVs IGFuZCBzdGF0ZWxlc3MgYXV0byBjb25maWd1cmF0aW9uPw0KDQpCeWUNCk1heA0KDQoNCkZyb206 IG5ldGV4dCBbbWFpbHRvOm5ldGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0 IEJhc2F2YXJhaiBQYXRpbA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgMTY6MjcN ClRvOiBuZXRleHRAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLW5ldGV4dC1sb2dpY2FsLWludGVy ZmFjZS1zdXBwb3J0LTA5QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBbbmV0ZXh0XSBXR0xDOiBJ LUQgZHJhZnQtaWV0Zi1uZXRleHQtbG9naWNhbC1pbnRlcmZhY2Utc3VwcG9ydC0wOQ0KDQoNCkhl bGxvLA0KDQpUaGUgV0cgSS1EOiBMb2dpY2FsIEludGVyZmFjZSBTdXBwb3J0IGZvciBtdWx0aS1t b2RlIElQIEhvc3RzDQogICAgICAgICAgICA8ZHJhZnQtaWV0Zi1uZXRleHQtbG9naWNhbC1pbnRl cmZhY2Utc3VwcG9ydC0wOT4NCmlzIHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4N Cg0KVGhpcyBJLUQgaXMgaW50ZW5kZWQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIEluZm9ybWF0aW9u YWwgUkZDLg0KDQpQbGVhc2UgdHJlYXQgdGhpcyBlbWFpbCBhcyB0aGUgc3RhcnQgb2YgdGhlIFdH TEMgZm9yIHRoaXMgSS1ELg0KVGhlIFdHTEMgd2lsbCBlbmQgb24gU2VwdCAxNXRoLCAyMDE0LiBQ bGVhc2Ugc2VuZCB5b3VyIHJldmlldyBjb21tZW50cyB0byB0aGUgV0cgbWFpbGluZyBsaXN0IG9y IHRoZSBhdXRob3JzIGRpcmVjdGx5Lg0KDQotQ2hhaXJzDQoNCi0tDQpCYXNhdmFyYWogUGF0aWwN Cg== --_000_003101cfd058c48a48504d9ed8f0nsncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3FF5801FA1708748928C8D790AF392FD@internal.nsn.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdp bi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjojMkY1NDk2Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsN Cgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo0MzI2NzE1NTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE4OTQwMjAyNTAgLTcyNzgyNjkyMCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzJGNTQ5NiI+SGksPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPkkgd291bGQgbGlrZSB0byBw cm92aWRlIGEgZmV3IHJldmlldyBjb21tZW50cyBvbiB0aGUgZHJhZnQ6PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9y PSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMyRjU0OTYiPldoaWxlIHN0cm9uZ2x5IHN1cHBvcnRpbmcgdGhhdCB0aGUgSS1EIGlzIG1v dmluZyBmb3J3YXJkIGFuZCBmaW5hbGx5IGdldHRpbmcgcHVibGlzaGVkIGFzIEluZm9ybWF0aW9u YWwgUkZDIEkgZm91bmQNCiBhIG51bWJlciBvZiBzaG9ydGNvbWluZ3Mgd2hpY2ggc2hvdWxkIGJl IGFkZHJlc3NlZCBiZWZvcmUgcHVibGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxm b250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjEiIGNv bG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij5U aGUgb3ZlcmFsbCBzdHJ1Y3R1cmUgaXMgbGVhZGluZyB0byByZXBsaWNhdGlvbiBvZiBpbmZvcm1h dGlvbiBhbmQgZG9lcyBub3QgcHJvdmlkZSBhIGNsZWFyDQogc3RvcnkgbGluZS4gSSB3b3VsZCBy ZWNvbW1lbmQgYSBzdHJ1Y3R1cmUgbGlrZSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxm b250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjEiIGNv bG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij5J bnRyb2R1Y3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBz aXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxmb250IHNpemU9IjEiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFu Pjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij5UZXJtaW5vbG9neTxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIj MmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48 IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPlByb2JsZW0gc3RhdGVtZW50PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48 Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzJGNTQ5NiI+TGluayBMYXllciBpbnRlcmZhY2UgYmVoYXZpb3I8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+bzxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZd Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMkY1NDk2Ij5Mb2dpY2FsIEludGVyZmFjZSBGdW5jdGlvbmFsIERlc2NyaXB0aW9u PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29s b3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9m b250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+TG9naWNhbCBJbnRlcmZhY2UgRGVwbG95bWVu dCBFeGFtcGxlczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2 IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRp Zl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMyRjU0OTYiPigxLiBJbnRyb2R1Y3Rpb24pPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZv bnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIx IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwv c3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5 NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+KDIuIFRlcm1pbm9s b2d5KTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjEi IGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2 Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFu PjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPklNSE8sIGEgUElGIGlzIHRoZSBpbnRl cmZhY2UgY29taW5nIG91dCBvZiB0aGUgaG9zdCB0byB0aGUgcGh5c2ljYWwgd29ybGQuIEkgd291 bGQgcmVjb21tZW5kDQogdG8gY2xlYW4gdXAgdGVybWlub2xvZ3kgdG8gY2xlYXJseSBpZGVudGlm eSB0aGUgcmVsZXZhbnQgaW50ZXJmYWNlcyBpbiB0aGUgY29tbXVuaWNhdGlvbiBzdGFjaywgZS5n LiBieSBpbnRyb2R1Y3Rpb24gb2YgYSAnTGluayBJbnRlcmZhY2UnIG9yIGV2ZW4gYSAnTGluayBT QVAnLiBUYWtpbmcgYSBsb29rIGludG8gSUVFRSA4MDIgc3BlY2lmaWNhdGlvbnMgbWF5IGhlbHAg dG8gZmluZCBhcHByb3ByaWF0ZSB3b3JkaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9 IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1 NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9z cGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPigzLiBIaWRpbmcgTGluay1sYXll ciBUZWNobm9sb2dpZXMgLSBBcHByb2FjaGVzIGFuZCBBcHBsaWNhYmlsaXR5PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlm XT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzJGNTQ5NiI+VGl0bGUgaXMgc29tZXdoYXQgbWlzbGVhZGluZzsgdGhlIHRvcGlj IGlzIHRvIGVuYWJsZSBhbiBJUCBpbnRlcmZhY2UgdG8gY29ubmVjdCBzZXF1ZW50aWFsbHkNCiBv ciBzaW11bHRhbmVvdXMgdG8gbXVsdGlwbGUgZGlmZmVyZW50ICdMaW5rIFNBUHMnLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4t PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYi PigzLjIuMSBMaW5rIExheWVyIEFic3RyYWN0aW9uIC0gQXBwcm9hY2hlcyk8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+bzxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZd Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMkY1NDk2Ij5BYnN0cmFjdGlvbiBpcyBub3QgcmVhbGx5IHRoZSBpc3N1ZTsgc3dp dGNoaW5nIGFuZCBtdWx0aXBsZXhpbmcgbXVsdGlwbGUgbGlua3MgaW50byBvbmUgaXMgdGhlDQog dG9waWMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0i MSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0 OTYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3Nw YW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+VGV4dCBvbiBJRUVFIDgwMiBMaW5r IExheWVyIHN1cHBvcnQgc2hvdWxkIGZvY3VzIG5vdCBvbiBQSFkgdGVjaG5vbG9naWVzIGJ1dCBv biB0aGUgZGlmZmVyZW5jZXMNCiBpbiB0aGUgJ0xpbmsgU0FQcycuIElFRUUgODAyLjFBQyBtYXkg YmUgb2YgZ3JlYXQgaGVscCB0byB1bmRlcnN0YW5kIHRoZSBjb21tb25hbGl0aWVzIGFuZCBkaWZm ZXJlbmNlcyBvZiB0aGUgU0FQcyBhbW9uZyB0aGUgZGlmZmVyZW50IDgwMiB0ZWNobm9sb2dpZXMu PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29s b3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9m b250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+M0dQUCByZXF1aXJlcyBhIG11Y2ggbW9yZSBj b21wcmVoZW5zaXZlIGRlc2NyaXB0aW9uIGhlcmUuIFRTMjMuNDAxIHByb3ZpZGVzIGEgZ2VuZXJp YyBuZXR3b3JrDQogYXJjaGl0ZWN0dXJlLCBidXQgdGhlIGRldGFpbHMgb2YgdGhlIGxpbmsgaW50 ZXJmYWNlcyBhcmUgc3BlY2lmaWVkIHdpdGhpbiBvdGhlciBkb2N1bWVudHMuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlm XT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzJGNTQ5NiI+QSBsb2dpY2FsIGludGVyZmFjZSBoYXMgbm90IG5lY2Vzc2FyaWx5 IG11bHRpcGxlIHBoeXNpY2FsIGludGVyZmFjZXMgYmVuZWF0aC4gTmVpdGhlciBpcyBhIGxvZ2lj YWwNCiBpbnRlcmZhY2UgYm91bmQgdG8gdGhlIGFwcGxpY2F0aW9ucyBtZW50aW9uZWQgaW4gdGhl IEktRC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxm b250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMkY1NDk2Ij4oMy4yIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50KTxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+ PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMyRjU0OTYiPkkgd29uZGVyIGFib3V0IHRoZSAnYWJvdmUgc29sdXRpb25zJy4gV2hp Y2ggc29sdXRpb25zPyBJIHNlZSBvbmx5IGxpc3Rpbmcgb2YgY29tbW9uIFBIWXMgYW5kDQogdGVj aG5vbG9neSB0ZXJtcyAoJ2Nvbm5lY3Rpb24gbWFuYWdlcicsIEFORFNGKS4gSG93IGRvIHRoZXNl IHJlbGF0ZSB0byB0aGUgc29sdXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZv bnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29s b3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPkJv dGggJ211bHRpIHRlY2hub2xvZ3kgc3VwcG9ydCcgYW5kICdzZXF1ZW50aWFsIHZzLiBzaW11bHRh bmVvdXMgYWNjZXNzJyBzaG91bGQgYmUgZXhwbGFpbmVkDQogYnkgYSBmZXcgc2VudGVuY2VzLiBB dCB0aGlzIGxvY2F0aW9uIHRoZSB0ZXJtcyBhcmUgbm90IHNlbGYtZXhwbGFuYXRvcnkgeWV0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9y PSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9u dD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPkkgYW0gbm90IGNsZWFyLCB3aGF0IHlvdSB3b3Vs ZCBsaWtlIHRvIGV4cGxhaW4gaW4gdGhpcyBzZWN0aW9uLiBTb21laG93IGl0IGxvb2tzIGxpa2Ug YW4gZXh0ZW5zaW9uDQogdG8gdGhlICdsaW5rIGxheWVyIHN1cHBvcnQnIGFuZCAnbG9naWNhbCBp bnRlcmZhY2UnIHBhcmFncmFwaHMgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24uPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9u dCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xv cj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+KDQu IFRlY2hub2xvZ3kgVXNlIENhc2VzKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQg c2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv Zm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9 IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPkxvb2tz IGxpa2UgYW4gcmVwZXRpdGlvbiBvZiBpbmZvcm1hdGlvbiBvZiB0aGUgcHJldmlvdXMgc2VjdGlv bnMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+ PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+UFBQIHZzLiBOQk1BIHZzLiBCTUEgcmVx dWlyZXMgY29tcHJlaGVuc2l2ZSBjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9u dCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2 IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij4oNS4gTG9naWNhbCBJ bnRlcmZhY2UgRnVuY3Rpb25hbCBEZXRhaWxzKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5v PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIg Y29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYi PkxvZ2ljYWwgSW50ZXJmYWNlIHNob3VsZCBiZSBkZWZpbmVkIGluZGVwZW5kZW50IGZyb20gcGh5 c2ljYWwgd2lyZXMsIGFzIGEgbG9naWNhbCBpbnRlcmZhY2UNCiBtYXkgYWxzbyBiZSB1c2VkIHdp dGggJ3R1bm5lbHMnLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250 IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPGZvbnQgc2l6ZT0iMSIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3Nw YW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPkkgbWlzcyBjb25zaWRl cmF0aW9ucyBhYm91dCBpbnRlcmZhY2UgZnVuY3Rpb25zIGxpa2UgTkQvQVJQL0RIQ1AuIFByb2Jh Ymx5IHRoZSBJLUQgc2hvdWxkIG1ha2UNCiBhIHJlZmVyZW5jZSB0byBJUHY2IG5vZGUgcmVxdWly ZW1lbnRzIChSRkMgNjQzNCkgYW5kIHByb3ZpZGUgY29tbWVudHMgdG8gYWxsIHN0YXRlbWVudHMg d2hpY2ggcmVxdWlyZSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgdGhlIExJRiwgZS5nLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJm NTQ5NiIgZmFjZT0iV2luZ2RpbmdzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMkY1NDk2Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7Cpzxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxmb250IHNpemU9IjEiIGNvbG9y PSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij5XaGF0 IGFyZSB0aGUgaXNzdWVzIGNvbWluZyB1cCB3aGVuIGNvbWJpbmluZyBhIFBQUCBsaW5rIHdpdGgg YW4gRXRoZXJuZXQgbGluayBmb3Igb25lIGxvZ2ljYWwNCiBpbnRlcmZhY2UuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPm88Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlm XT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzJGNTQ5NiI+SXMgRkxPVyBtYW5hZ2VtZW50IG1hbmRhdG9yeSBmb3IgYWxsIGtp bmQgb2YgTElGcz8gSSB3b3VsZCBndWVzcywgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiB0ZXh0DQog YmVsb25ncyB0byB0aGUgJ3NpbXVsdGFuZW91cyBhY2Nlc3MnIHNjZW5hcmlvLCBub3QgdG8gYWxs IHNjZW5hcmlvcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxmb250IHNpemU9IjEiIGNv bG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMkY1NDk2Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJmNTQ5NiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxmb250IHNpemU9IjEiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PCFbZW5kaWZdPjxm b250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMkY1NDk2Ij5PdmVyYWxsLCBJIHdvdWxkIGFwcHJlY2lhdGUgbW9yZSB0aG9yb3VnaCBj b25zaWRlcmF0aW9ucyBhYm91dCB0aGUgaXNzdWVzIGNvbWluZyB1cCB3aGVuIGNvbWJpbmluZw0K IG11bHRpcGxlIGRpZmZlcmVudCBsaW5rIHR5cGVzLCBlLmcuIHN3aXRjaGluZyBiZXR3ZWVuIGFu IEV0aGVybmV0IGFuZCBhIFBQUCBsaW5rLiBXaGF0IGFib3V0IHJlYWNoYWJpbGl0eSBvZiBvdGhl ciBob3N0cyBvbiB0aGUgRXRoZXJuZXQgd2hlbiBzZWxlY3RpbmcgdGhlIFBQUCBsaW5rPyBXaGF0 IGFib3V0IG11bHRpY2FzdCBzZXJ2aWNlcywgd2hhdCBhYm91dCBhIG1peCBvZiBzdGF0ZWZ1bCBh bmQgc3RhdGVsZXNzIGF1dG8gY29uZmlndXJhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIx IiBjb2xvcj0iIzJmNTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5 NiI+QnllPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjEiIGNvbG9yPSIjMmY1NDk2IiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMkY1NDk2Ij5NYXg8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMyZjU0OTYiIGZhY2U9IkNvdXJp ZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzJm NTQ5NiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzJGNTQ5NiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztmb250 LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogbmV0ZXh0IFttYWlsdG86 bmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5PbiBCZWhhbGYgT2YNCjwvc3Bhbj48L2I+ZXh0IEJhc2F2YXJhaiBQYXRpbDxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IFdlZG5lc2RheSwg QXVndXN0IDI3LCAyMDE0IDE2OjI3PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOjwvc3Bhbj48L2I+IG5ldGV4dEBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBkcmFmdC1pZXRmLW5ldGV4dC1sb2dpY2Fs LWludGVyZmFjZS1zdXBwb3J0LTA5QHRvb2xzLmlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW25ldGV4dF0gV0dMQzogSS1E IGRyYWZ0LWlldGYtbmV0ZXh0LWxvZ2ljYWwtaW50ZXJmYWNlLXN1cHBvcnQtMDk8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhlbGxv LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIFdH IEktRDogTG9naWNhbCBJbnRlcmZhY2UgU3VwcG9ydCBmb3IgbXVsdGktbW9kZSBJUCBIb3N0czxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7ZHJhZnQtaWV0Zi1uZXRleHQtbG9naWNhbC1pbnRlcmZhY2Utc3VwcG9ydC0wOSZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+aXMgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhp cyBJLUQgaXMgaW50ZW5kZWQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZD LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UGxlYXNl IHRyZWF0IHRoaXMgZW1haWwgYXMgdGhlIHN0YXJ0IG9mIHRoZSBXR0xDIGZvciB0aGlzIEktRC4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhlIFdHTEMgd2lsbCBlbmQgb24gU2VwdCAxNXRo LCAyMDE0LiBQbGVhc2Ugc2VuZCB5b3VyIHJldmlldyBjb21tZW50cyB0byB0aGUgV0cgbWFpbGlu ZyBsaXN0IG9yIHRoZSBhdXRob3JzIGRpcmVjdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+LUNoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4tLQ0KPGJyPg0KQmFzYXZhcmFqIFBhdGlsIDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_003101cfd058c48a48504d9ed8f0nsncom_-- From nobody Sun Sep 14 18:26:13 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFCD1A0476 for ; Sun, 14 Sep 2014 18:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 nUsNiuCxG53j for ; Sun, 14 Sep 2014 18:26:09 -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 9C7C61A0475 for ; Sun, 14 Sep 2014 18:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41619; q=dns/txt; s=iport; t=1410744368; x=1411953968; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=j0wDTtR1IxFhpuHgiF3yiobKtZS1iu7J/KYEyTbBTl4=; b=cfZLdB9RuT7LQ+6Ar7zcWcM7IODmWXp3+TUnSEn5JthxhQ9YtKO+RKSz hdwIKxY4uAGp+kMmgGhRF3Oh7/1HH142h59mXm+IdaFfzrtd5idn9Grxt gi6xxzOfMM9Emn9yyMOyOQaQ+7R17QvlN7LkZOYMFI3LtKbdd14wIclMs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAIE/FlStJV2R/2dsb2JhbABVCoJHRlNXBNE5AYEMFniEAwEBAQQtQQsSAQgRAQIBAQEhAQY5FAMGCAIEAQ0FG4gjuTUBF4oAhGsGCwEsExEGAQKESQWRTYs7lT+DXmyBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,524,1406592000"; d="scan'208,217";a="355177255" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 15 Sep 2014 01:26:06 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8F1Q6MV032267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 01:26:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Sun, 14 Sep 2014 20:26:06 -0500 From: "Sri Gundavelli (sgundave)" To: "Riegel, Maximilian (NSN - DE/Munich)" , "netext@ietf.org" Thread-Topic: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 Thread-Index: AQHP0IQF5s2xzftcEkGqxv4tdw8U8g== Date: Mon, 15 Sep 2014 01:26:05 +0000 Message-ID: In-Reply-To: <003101cfd058$c48a4850$4d9ed8f0$@nsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D03B8DF4164251sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/M67GtKaENIpTmxQKoENT6ZzllPE Cc: "draft-ietf-netext-logical-interface-support-09@tools.ietf.org" Subject: Re: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 01:26:11 -0000 --_000_D03B8DF4164251sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Max, Thanks. We still have to address your comments from prev review. Will take = care of this comments in =9610 version. Regards Sri From: , "Maximilian (NSN - DE/Munich)" > Date: Sunday, September 14, 2014 1:16 PM To: "netext@ietf.org" > Cc: "draft-ietf-netext-logical-interface-support-09@tools.ietf.org" > Subject: Re: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support= -09 Hi, I would like to provide a few review comments on the draft: While strongly supporting that the I-D is moving forward and finally gettin= g published as Informational RFC I found a number of shortcomings which sho= uld be addressed before publication. - The overall structure is leading to replication of information and doe= s not provide a clear story line. I would recommend a structure like o Introduction o Terminology o Problem statement o Link Layer interface behavior o Logical Interface Functional Description o Logical Interface Deployment Examples - (1. Introduction) - (2. Terminology) o IMHO, a PIF is the interface coming out of the host to the physical wo= rld. I would recommend to clean up terminology to clearly identify the rele= vant interfaces in the communication stack, e.g. by introduction of a 'Link= Interface' or even a 'Link SAP'. Taking a look into IEEE 802 specification= s may help to find appropriate wording. - (3. Hiding Link-layer Technologies - Approaches and Applicability o Title is somewhat misleading; the topic is to enable an IP interface t= o connect sequentially or simultaneous to multiple different 'Link SAPs'. - (3.2.1 Link Layer Abstraction - Approaches) o Abstraction is not really the issue; switching and multiplexing multip= le links into one is the topic. o Text on IEEE 802 Link Layer support should focus not on PHY technologi= es but on the differences in the 'Link SAPs'. IEEE 802.1AC may be of great = help to understand the commonalities and differences of the SAPs among the = different 802 technologies. o 3GPP requires a much more comprehensive description here. TS23.401 pro= vides a generic network architecture, but the details of the link interface= s are specified within other documents. o A logical interface has not necessarily multiple physical interfaces b= eneath. Neither is a logical interface bound to the applications mentioned = in the I-D. - (3.2 Applicability Statement) o I wonder about the 'above solutions'. Which solutions? I see only list= ing of common PHYs and technology terms ('connection manager', ANDSF). How = do these relate to the solutions? o Both 'multi technology support' and 'sequential vs. simultaneous acces= s' should be explained by a few sentences. At this location the terms are n= ot self-explanatory yet. o I am not clear, what you would like to explain in this section. Someho= w it looks like an extension to the 'link layer support' and 'logical inter= face' paragraphs in the previous section. - (4. Technology Use Cases) o Looks like an repetition of information of the previous sections. o PPP vs. NBMA vs. BMA requires comprehensive considerations. - (5. Logical Interface Functional Details) o Logical Interface should be defined independent from physical wires, a= s a logical interface may also be used with 'tunnels'. o I miss considerations about interface functions like ND/ARP/DHCP. Prob= ably the I-D should make a reference to IPv6 node requirements (RFC 6434) a= nd provide comments to all statements which require special treatment for t= he LIF, e.g. =A7 What are the issues coming up when combining a PPP link with an Ethern= et link for one logical interface. o Is FLOW management mandatory for all kind of LIFs? I would guess, that= the specification text belongs to the 'simultaneous access' scenario, not = to all scenarios. - Overall, I would appreciate more thorough considerations about the iss= ues coming up when combining multiple different link types, e.g. switching = between an Ethernet and a PPP link. What about reachability of other hosts = on the Ethernet when selecting the PPP link? What about multicast services,= what about a mix of stateful and stateless auto configuration? Bye Max From: netext [mailto:netext-bounces@ietf.org] On Behalf Of ext Basavaraj Pa= til Sent: Wednesday, August 27, 2014 16:27 To: netext@ietf.org Cc: draft-ietf-netext-logical-interface-support-09@tools.ietf.org Subject: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 Hello, The WG I-D: Logical Interface Support for multi-mode IP Hosts is ready for working group last call. This I-D is intended to be published as an Informational RFC. Please treat this email as the start of the WGLC for this I-D. The WGLC will end on Sept 15th, 2014. Please send your review comments to t= he WG mailing list or the authors directly. -Chairs -- Basavaraj Patil --_000_D03B8DF4164251sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Max,

Thanks. We still have to address your comments from prev review. Will = take care of this comments in =9610 version.


Regards
Sri


From: <Riegel>, "Maximil= ian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
Date: Sunday, September 14, 2014 1:= 16 PM
To: "netext@ietf.org" <= netext@ietf.org>
Cc: "draft-ietf-netext-l= ogical-interface-support-09@tools.ietf.org" <draft-ietf-n= etext-logical-interface-support-09@tools.ietf.org>
Subject: Re: [netext] WGLC: I-D dra= ft-ietf-netext-logical-interface-support-09

Hi,

 

I would like to provide a few review comments on the draft:<= o:p>

 

While strongly supporting that the I-D is moving forward and= finally getting published as Informational RFC I found a number of shortcomings which should be addressed before publ= ication.

 

-    The overall structure is leading t= o replication of information and does not provide a clear story line. I would recommend a structure like =

o &= nbsp;  Introduction

o &= nbsp;  Terminology

o &= nbsp;  Problem statement

o &= nbsp;  Link Layer interface behavior=

o &= nbsp;  Logical Interface Functional Descr= iption

o &= nbsp;  Logical Interface Deployment Examp= les

-    (1. Introduction)

-    (2. Terminology)=

o &= nbsp;  IMHO, a PIF is the interface comin= g out of the host to the physical world. I would recommend to clean up terminology to clearly identify the relevant= interfaces in the communication stack, e.g. by introduction of a 'Link Int= erface' or even a 'Link SAP'. Taking a look into IEEE 802 specifications ma= y help to find appropriate wording.

-    (3. Hiding Link-layer Technologies= - Approaches and Applicability

o &= nbsp;  Title is somewhat misleading; the = topic is to enable an IP interface to connect sequentially or simultaneous to multiple different 'Link SAPs'.=

-   (3.2.1 Link Layer Abstraction - Approaches)

o &= nbsp;  Abstraction is not really the issu= e; switching and multiplexing multiple links into one is the topic.

o &= nbsp;  Text on IEEE 802 Link Layer suppor= t should focus not on PHY technologies but on the differences in the 'Link SAPs'. IEEE 802.1AC may be of great help t= o understand the commonalities and differences of the SAPs among the differ= ent 802 technologies.

o &= nbsp;  3GPP requires a much more comprehe= nsive description here. TS23.401 provides a generic network architecture, but the details of the link interfaces are= specified within other documents.

o &= nbsp;  A logical interface has not necess= arily multiple physical interfaces beneath. Neither is a logical interface bound to the applications mentioned in the = I-D.

-    (3.2 Applicability Statement)=

o &= nbsp;  I wonder about the 'above solution= s'. Which solutions? I see only listing of common PHYs and technology terms ('connection manager', ANDSF). How do = these relate to the solutions?

o &= nbsp;  Both 'multi technology support' an= d 'sequential vs. simultaneous access' should be explained by a few sentences. At this location the terms are not self-e= xplanatory yet.

o &= nbsp;  I am not clear, what you would lik= e to explain in this section. Somehow it looks like an extension to the 'link layer support' and 'logical interface= ' paragraphs in the previous section.

-    (4. Technology Use Cases)

o &= nbsp;  Looks like an repetition of inform= ation of the previous sections.

o &= nbsp;  PPP vs. NBMA vs. BMA requires comp= rehensive considerations.

-    (5. Logical Interface Functional D= etails)

o &= nbsp;  Logical Interface should be define= d independent from physical wires, as a logical interface may also be used with 'tunnels'.

o &= nbsp;  I miss considerations about interf= ace functions like ND/ARP/DHCP. Probably the I-D should make a reference to IPv6 node requirements (RFC 6434) and p= rovide comments to all statements which require special treatment for the L= IF, e.g.

=A7<= span style=3D"font:7.0pt "Times New Roman"">  What are the issues coming up when= combining a PPP link with an Ethernet link for one logical interface.

o &= nbsp;  Is FLOW management mandatory for a= ll kind of LIFs? I would guess, that the specification text belongs to the 'simultaneous access' scenario, not to a= ll scenarios.

 =

-    Overall, I would appreciate more t= horough considerations about the issues coming up when combining multiple different link types, e.g. switching bet= ween an Ethernet and a PPP link. What about reachability of other hosts on = the Ethernet when selecting the PPP link? What about multicast services, wh= at about a mix of stateful and stateless auto configuration?

 

Bye

Max

 

 

Fro= m: netext [mailto:netext-bounces@i= etf.org] On Behalf Of ext Basavaraj P= atil
Sent: Wednesday, August 27, = 2014 16:27
To: netext@ietf.org
Cc: draft-ietf-netext-logical-interface-support-09@tools.ietf.org
Subject: [netext] WGLC: I-D = draft-ietf-netext-logical-interface-support-09

 

 

Hello,

 

The WG I-D: Logical Interface Support for multi-mode= IP Hosts

            <draft-= ietf-netext-logical-interface-support-09>

is ready for working group last call.

 

This I-D is intended to be published as an Informati= onal RFC.

 

Please treat this email as the start of the WGLC for= this I-D. 

The WGLC will end on Sept 15th, 2014. Please send yo= ur review comments to the WG mailing list or the authors directly.

 

-Chairs

 

--
Basavaraj Patil

--_000_D03B8DF4164251sgundaveciscocom_-- From nobody Mon Sep 15 09:23:07 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2A51A8955; Mon, 15 Sep 2014 09:23:04 -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 7VHrQMAQ7fwx; Mon, 15 Sep 2014 09:23:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 137AE1A87A9; Mon, 15 Sep 2014 09:01:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140915160139.2404.60597.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 09:01:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/igt2buyi4Yesr1DCiB_IFEat7Rw Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-12.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 16:23:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-12.txt Pages : 17 Date : 2014-09-15 Abstract: With Wi-Fi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted Wi-Fi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-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 nobody Mon Sep 15 22:46:56 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489F51A02E2 for ; Mon, 15 Sep 2014 22:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 bTJyEI2P55CS for ; Mon, 15 Sep 2014 22:46:53 -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 99E9C1A02C1 for ; Mon, 15 Sep 2014 22:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9287; q=dns/txt; s=iport; t=1410846413; x=1412056013; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=iWt0fqiAaZ1EA8dH3nXEWbMVMotEoChWx6zg1hQZXf8=; b=SN0i2eeQj/OYQff5NNg7kJaC4Flot7QdUWkcNpzkU5QZ2O0d8XD4bb4D M80lzGClGYPo1ssEghL3QjNgp5NVVn1WNKH+bh/bIFpuBry02v7QMgLrz 2Ee2uwjnNpNCxD34ciT+wn/c55xor4YKBCzY73EkIgddFLqDE4pDiY7Fn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAIfOF1StJV2T/2dsb2JhbABggkdGgS7SPQGBERZ4hAUEAWsTDQEaZhcOAgSISQiWK6U9ARePVIRLBY83ghaLO5U/g16CNIECAQEB X-IronPort-AV: E=Sophos;i="5.04,533,1406592000"; d="scan'208,217";a="355528901" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 16 Sep 2014 05:46:52 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8G5kqbB018525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Sep 2014 05:46:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 00:46:52 -0500 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 Thread-Index: AQHP0XGdq6lR2CqF9kq32SrRu7DxUQ== Date: Tue, 16 Sep 2014 05:46:52 +0000 Message-ID: In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D9BF77E@dfweml703-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D03D11DE1645D3sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/bsSRHCFMLqeMFWmULCvdx4t5lyc Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 05:46:55 -0000 --_000_D03D11DE1645D3sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors: I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. I= ts in a good shape. Few comments below. Major Comment: > Section 3: "However, there are no standards defined way for the AP to ini= tiate a QoS service request to the MN." I'm bit disappointed to see the removal of the support for network initiate= d QoS set-up. John, Rajesh and myself had several offline discussions on t= his few months back; Here is my comment from earlier discussions. I'm not a= sking the Authors to add the support for network-initiated dynamic QoS, but= I thought it will be good to get some feedback from others. "I do not understand the 802.11 guys thinking on this entire StreamId busin= ess. When I first looked at it this, I thought this is just a identifier us= ed in Application signaling. But, when this is tied to .1Q, even the basic = semantics on the StreamId length or how its used in the network is not clea= r to me. Their view that the tag is global and can be enforced in the entir= e network seems bit broken. But, that spec is not my area of expertise and = so may be I missing the real intent here. However, when I look at this from PMIP QoS point of view and with the goal = of realizing end to end QoS, the QoS enforcement in this context is on the= MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP is= sue. If that is the baseline requirement, my point is what stops the UE or = the MAG implementation to ignore the StreamId completely ? MAG and UE repre= sent the two end points of the air interface and they both have the TFT. S= o, this entire streamId business is total non-sense, specially the key prot= ocols such as SIP have no mapping. So, even if there is public OUI allocati= on, I fail to understand how it fits in the overall scheme of things. So, m= y initial suggestion was to workaround the StreamId and make the spec work. " Additional Comments: > Introduction: "STA" Please add a reference or explanation on "STA" term - Station; In general, = please add references/explanations to all Wi-Fi terminology. > "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]= " Some explanation can help. > However, this document does not exclude various deployments including those where AP and WLC are separate nodes, or the MAG control and data planes are separate." Should there any guidance on how the QoS parameters are negotiated/exchange= d between AP and WLC in the split mode ? > Section 1.2: TSPEC Add a reference to TSPEC > GBR, AMBR Terminology You may want to add a reference to RFC 7222 Terminology section. There is e= xplanation for GBR, AMBR and other parameters > PMIPV6 Should be PMIPv6 > Handovers ? I did not see much text on what happens to the QoS states after a MN's inte= r-MAG handovers. > Section 4.1 Please use "Traffic Class" in the table, instead of "DSCP" > Error Code Mapping RFC7222 defines couple of error codes. Its not clear how those error codes = map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is tha= t all ? > Scope: Per-MN, Per-Session, No discussion on the scope. Its unclear how the Per-Session, Per-MN attribu= tes map to different Wi-Fi QoS elements > Security Considerations You may want to add some text on how WLAN security architecture can protect= the integrity of the QoS signaling messages on the air interface. The curr= ent text may not be sufficient. > References Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used= in call flows Add a reference to UPN/UPA spec (RFC7077) as its used in call flows --_000_D03D11DE1645D3sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Authors:

I've reviewed the -01 version of Wi-Fi QoS document. Its is well writt= en. Its in a good shape. Few comments below.



Major Comment:

> Section 3: "However, there are no standards defined way = ;for the AP to initiate a QoS service request to the MN."

I'm bit disappointed to see the removal of the support for network ini= tiated QoS set-up.  John, Rajesh and myself had several offline discus= sions on this few months back; Here is my comment from earlier discussions.= I'm not asking the Authors to add the support for network-initiated dynamic QoS, but I thought it will be good t= o get some feedback from others.

"I do not understand the 802.11 guys thinking on this entire Stre= amId business. When I first looked at it this, I thought this is just a ide= ntifier used in Application signaling. But, when this is tied to .1Q, even = the basic semantics on the StreamId length or how its used in the network is not clear to me. Their view that the tag= is global and can be enforced in the entire network seems bit broken. But,= that spec is not my area of expertise and so may be I missing the real int= ent here. 

However, when I look at this from PMIP QoS point of view and with the = goal of realizing end to end QoS, the QoS enforcement  in this context= is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) = is PMIP issue. If that is the baseline requirement, my point is what stops the UE or the MAG implementation to ig= nore the StreamId completely ? MAG and UE represent the two end points of t= he air interface and they both have the TFT.  So, this entire str= eamId business is total non-sense, specially the key protocols such as SIP have no mapping. So, even if there is public= OUI allocation, I fail to understand how it fits in the overall scheme of = things. So, my initial suggestion was to workaround the StreamId and make t= he spec work.
" 



Additional Comments:

> Introduction: "STA"
Please add a reference or explanation on "STA" term - Statio= n; In general, please add references/explanations to all Wi-Fi terminology.=

> "The Mean Data Rate does not include the MAC and PHY ov= erheads [WMM1.2.0]"
 Some explanation can help.

> However, this document does not exclude
   various deployments including those where AP and WLC are = separate
   nodes, or the MAG control and data planes are separate.&q= uot;

Should there any guidance on how the QoS parameters are negotiated/exc= hanged between AP and WLC in the split mode ?

> Section 1.2: TSPEC
Add a reference to TSPEC

> GBR, AMBR Terminology
You may want to add a reference to RFC 7222 Terminology section. There= is explanation for GBR, AMBR and other parameters

> PMIPV6 
Should be PMIPv6 

> Handovers ?
I did not see much text on what happens to the QoS states after a MN's= inter-MAG handovers.

> Section 4.1
Please use "Traffic Class" in the table, instead of "DS= CP" 

> Error Code Mapping
RFC7222 defines couple of error codes. Its not clear how those error c= odes map to the Cause Codes in ADDTS Response. I saw just one Cause Code. I= s that all ?

> Scope: Per-MN, Per-Session, 
No discussion on the scope. Its unclear how the Per-Session, Per-MN at= tributes map to different Wi-Fi QoS elements

> Security Considerations
You may want to add some text on how WLAN security architecture can pr= otect the integrity of the QoS signaling messages on the air interface. The= current text may not be sufficient.


> References
Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are= used in call flows
Add a reference to UPN/UPA spec (RFC7077) as its used in call flows





--_000_D03D11DE1645D3sgundaveciscocom_-- From nobody Tue Sep 16 11:34:47 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012401A6FE9 for ; Tue, 16 Sep 2014 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 HXQ59RRBgr13 for ; Tue, 16 Sep 2014 11:34:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F811A03EE for ; Tue, 16 Sep 2014 11:34:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJN25536; Tue, 16 Sep 2014 18:34:37 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Sep 2014 19:34:36 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 16 Sep 2014 11:34:32 -0700 From: John Kaippallimalil To: "Sri Gundavelli (sgundave)" , "netext@ietf.org" , "Rajesh Pazhyannur (rpazhyan)" , Parviz Yegani Thread-Topic: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 Thread-Index: AQHP0XGdq6lR2CqF9kq32SrRu7DxUZwECnQw Date: Tue, 16 Sep 2014 18:34:32 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA1F366@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BF77E@dfweml703-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.126] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DA1F366dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/w1HY4igjwH8BATfimNartY84QzY Subject: Re: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:34:45 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DA1F366dfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, Thank you for a very thorough review and comments. With regard to the major comment: - for QoS setup from AP to STA, we canno= t convey the relevant flow/stream in 802.11aa (it would need further stand= ardization in IEEE). Rajesh and I can discuss with you some simple text to address this comment. The other comments are relatively straightforward (see some notes inline be= low). In the next revision, we will address all these comments. Best Regards, John From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (= sgundave) Sent: Tuesday, September 16, 2014 12:47 AM To: netext@ietf.org Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-0= 1 Hi Authors: I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. I= ts in a good shape. Few comments below. Major Comment: > Section 3: "However, there are no standards defined way for the AP to ini= tiate a QoS service request to the MN." I'm bit disappointed to see the removal of the support for network initiate= d QoS set-up. John, Rajesh and myself had several offline discussions on t= his few months back; Here is my comment from earlier discussions. I'm not a= sking the Authors to add the support for network-initiated dynamic QoS, but= I thought it will be good to get some feedback from others. "I do not understand the 802.11 guys thinking on this entire StreamId busin= ess. When I first looked at it this, I thought this is just a identifier us= ed in Application signaling. But, when this is tied to .1Q, even the basic = semantics on the StreamId length or how its used in the network is not clea= r to me. Their view that the tag is global and can be enforced in the entir= e network seems bit broken. But, that spec is not my area of expertise and = so may be I missing the real intent here. However, when I look at this from PMIP QoS point of view and with the goal = of realizing end to end QoS, the QoS enforcement in this context is on the= MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP is= sue. If that is the baseline requirement, my point is what stops the UE or = the MAG implementation to ignore the StreamId completely ? MAG and UE repre= sent the two end points of the air interface and they both have the TFT. S= o, this entire streamId business is total non-sense, specially the key prot= ocols such as SIP have no mapping. So, even if there is public OUI allocati= on, I fail to understand how it fits in the overall scheme of things. So, m= y initial suggestion was to workaround the StreamId and make the spec work. " Additional Comments: > Introduction: "STA" Please add a reference or explanation on "STA" term - Station; In general, = please add references/explanations to all Wi-Fi terminology. OK, will revise > "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]= " Some explanation can help. Will add explanation > However, this document does not exclude various deployments including those where AP and WLC are separate nodes, or the MAG control and data planes are separate." Should there any guidance on how the QoS parameters are negotiated/exchange= d between AP and WLC in the split mode ? Did not want to add specifics since this is implementation specific. > Section 1.2: TSPEC Add a reference to TSPEC OK, will revise > GBR, AMBR Terminology You may want to add a reference to RFC 7222 Terminology section. There is e= xplanation for GBR, AMBR and other parameters OK, will revise. > PMIPV6 Should be PMIPv6 OK. > Handovers ? I did not see much text on what happens to the QoS states after a MN's inte= r-MAG handovers. We refer to RFC 7222 for the overall session handling. In > Section 4.1 Please use "Traffic Class" in the table, instead of "DSCP" OK. > Error Code Mapping RFC7222 defines couple of error codes. Its not clear how those error codes = map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is tha= t all ? Will revise to add other error codes. > Scope: Per-MN, Per-Session, No discussion on the scope. Its unclear how the Per-Session, Per-MN attribu= tes map to different Wi-Fi QoS elements The connection parameters - 4.1 shows the mapping per session and MN attrib= utes. Can revise text in introduction that refers to per MN and per session to gi= ve the context. > Security Considerations You may want to add some text on how WLAN security architecture can protect= the integrity of the QoS signaling messages on the air interface. The curr= ent text may not be sufficient. Will review. > References Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used= in call flows Add a reference to UPN/UPA spec (RFC7077) as its used in call flows OK. --_000_6561EABF52675C45BCDACA1B4D7AA1171DA1F366dfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sri,=

Thank you for a very thor= ough review and comments.

 <= /p>

With regard to the major = comment: - for QoS setup from AP to STA,  we cannot convey  the r= elevant flow/stream in 802.11aa (it would need further standardization in IEEE).

Rajesh and I can discuss = with you some simple text to address this comment.

 <= /p>

The other comments are re= latively straightforward (see some notes inline below).

 <= /p>

In the next revision, we = will address all these comments.

 <= /p>

Best Regards,<= /span>

John

 <= /p>

 <= /p>

 <= /p>

From: netext [= mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, September 16, 2014 12:47 AM
To: netext@ietf.org
Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos= -wifi-01

 

Hi Authors:

 

I've reviewed the -01 versi= on of Wi-Fi QoS document. Its is well written. Its in a good shape. Few com= ments below.

 

 

 

Major Comment:

 

> Section 3: "Howev= er, there are no standards defined way for the AP to initiate a QoS se= rvice request to the MN."

 

I'm bit disappointed to see= the removal of the support for network initiated QoS set-up.  John, R= ajesh and myself had several offline discussions on this few months back; Here is my comment from earlier discussions. I'm not asking t= he Authors to add the support for network-initiated dynamic QoS, but I thou= ght it will be good to get some feedback from others.

 

"I do not understand t= he 802.11 guys thinking on this entire StreamId business. When I first look= ed at it this, I thought this is just a identifier used in Application signaling. But, when this is tied to .1Q, even the basic semantics on the = StreamId length or how its used in the network is not clear to me. Their vi= ew that the tag is global and can be enforced in the entire network seems b= it broken. But, that spec is not my area of expertise and so may be I missing the real intent here. 

 

However, when I look at thi= s from PMIP QoS point of view and with the goal of realizing end to end QoS= , the QoS enforcement  in this context is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP issue. If = that is the baseline requirement, my point is what stops the UE or the MAG = implementation to ignore the StreamId completely ? MAG and UE represent the= two end points of the air interface and they both have the TFT.  So, this entire streamId business i= s total non-sense, specially the key protocols such as SIP have no mapping.= So, even if there is public OUI allocation, I fail to understand how it fi= ts in the overall scheme of things. So, my initial suggestion was to workaround the StreamId and make the spec work.<= o:p>

" 

 

 

 

Additional Comments:

 

> Introduction: "ST= A"

Please add a reference or e= xplanation on "STA" term - Station; In general, please add refere= nces/explanations to all Wi-Fi terminology.

OK, will revise

 

> "The Mean Data&nb= sp;Rate does not include the MAC and PHY overheads [WMM1.2.0]"

 Some explanation can = help.

Will add explanation=

 

> However, this doc= ument does not exclude

   various deploy= ments including those where AP and WLC are separate

   nodes, or the = MAG control and data planes are separate."

 

Should there any guidance o= n how the QoS parameters are negotiated/exchanged between AP and WLC in the= split mode ?

Did not want to add speci= fics since this is implementation specific.

 

> Section 1.2: TSPEC

Add a reference to TSPEC

OK, will revise

 

> GBR, AMBR Terminology<= o:p>

You may want to add a refer= ence to RFC 7222 Terminology section. There is explanation for GBR, AMBR an= d other parameters

OK, will revise.

 

> PMIPV6 

Should be PMIPv6 =

OK.

 

> Handovers ?=

I did not see much text on = what happens to the QoS states after a MN's inter-MAG handovers.=

We refer to RFC 7222 for = the overall session handling.

In

 

> Section 4.1=

Please use "Traffic Cl= ass" in the table, instead of "DSCP" =

OK.

 

> Error Code Mapping

RFC7222 defines couple of e= rror codes. Its not clear how those error codes map to the Cause Codes in A= DDTS Response. I saw just one Cause Code. Is that all ?

Will revise to add other = error codes.

 

> Scope: Per-MN, Per-Ses= sion, 

No discussion on the scope.= Its unclear how the Per-Session, Per-MN attributes map to different Wi-Fi = QoS elements

The connection parameters= – 4.1 shows the mapping per session and MN attributes.

Can revise text in introd= uction that refers to per MN and per session to give the context.

 

> Security Consideration= s

You may want to add some te= xt on how WLAN security architecture can protect the integrity of the QoS s= ignaling messages on the air interface. The current text may not be sufficient.

Will review.

 

 

> References<= /span>

Informative Reference to RF= C 5213 and 5844 as the PBU/PBA messages are used in call flows

Add a reference to UPN/UPA = spec (RFC7077) as its used in call flows

OK.

 

 

 

 

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DA1F366dfweml703chm_-- From nobody Tue Sep 16 11:56:43 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14171A6F28 for ; Tue, 16 Sep 2014 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 Vfz7IVfVCZ1A for ; Tue, 16 Sep 2014 11:56:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9820B1A6F80 for ; Tue, 16 Sep 2014 11:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29639; q=dns/txt; s=iport; t=1410893799; x=1412103399; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=NzN16qSNGVzcRYKsZ6CnpCPl1U7xmhck6CRx7LXovjo=; b=ez/Ng5N8csu5NQ+ee6WweKljgNMtEtoh9NOXC7sbVMEf/tMBEin2+TKp FXiSdzACAeEk0AI4dXO7kRPOGcsXByx1yuUzLuVbnVyp4vC648DMEkyCL LLNUsx1L2uokRzwk/gg+KL8wxfkcoR2b0zRTbPL2wkrJ9A8nYnc6Y+uE+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAECHGFStJV2S/2dsb2JhbABggkdGU1cE0BsBgRQWAXmEAwEBAQMBLT4TDQEIEQECAQEBIQEGORQDBggCBAESiDYIvC0BF48nExcBhEsFjzeCFos9lUWDXmyBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,535,1406592000"; d="scan'208,217";a="355742771" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 16 Sep 2014 18:56:38 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8GIucYx007328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Sep 2014 18:56:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 13:56:38 -0500 From: "Sri Gundavelli (sgundave)" To: John Kaippallimalil , "netext@ietf.org" , "Rajesh Pazhyannur (rpazhyan)" , Parviz Yegani Thread-Topic: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 Thread-Index: AQHP0d/xq6lR2CqF9kq32SrRu7DxUQ== Date: Tue, 16 Sep 2014 18:56:37 +0000 Message-ID: In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DA1F366@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.217] Content-Type: multipart/alternative; boundary="_000_D03DD28A164779sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/myXXhD30qAAsMVTr_FqIHb2wGkw Subject: Re: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:56:42 -0000 --_000_D03DD28A164779sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi John, > With regard to the major comment: - for QoS setup from AP to STA, we can= not convey the relevant flow/stream in 802.11aa (it would need further sta= ndardization in IEEE). May be a recommendation on the needed changes will help. Regards Sri From: John Kaippallimalil > Date: Tuesday, September 16, 2014 11:34 AM To: Sri Gundavelli >, "netext= @ietf.org" = >, "Rajesh Pazhyannur (rpazhyan)" >, Parviz Yegani > Subject: RE: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 Hi Sri, Thank you for a very thorough review and comments. With regard to the major comment: - for QoS setup from AP to STA, we canno= t convey the relevant flow/stream in 802.11aa (it would need further stand= ardization in IEEE). Rajesh and I can discuss with you some simple text to address this comment. The other comments are relatively straightforward (see some notes inline be= low). In the next revision, we will address all these comments. Best Regards, John From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (= sgundave) Sent: Tuesday, September 16, 2014 12:47 AM To: netext@ietf.org Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-0= 1 Hi Authors: I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. I= ts in a good shape. Few comments below. Major Comment: > Section 3: "However, there are no standards defined way for the AP to ini= tiate a QoS service request to the MN." I'm bit disappointed to see the removal of the support for network initiate= d QoS set-up. John, Rajesh and myself had several offline discussions on t= his few months back; Here is my comment from earlier discussions. I'm not a= sking the Authors to add the support for network-initiated dynamic QoS, but= I thought it will be good to get some feedback from others. "I do not understand the 802.11 guys thinking on this entire StreamId busin= ess. When I first looked at it this, I thought this is just a identifier us= ed in Application signaling. But, when this is tied to .1Q, even the basic = semantics on the StreamId length or how its used in the network is not clea= r to me. Their view that the tag is global and can be enforced in the entir= e network seems bit broken. But, that spec is not my area of expertise and = so may be I missing the real intent here. However, when I look at this from PMIP QoS point of view and with the goal = of realizing end to end QoS, the QoS enforcement in this context is on the= MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP is= sue. If that is the baseline requirement, my point is what stops the UE or = the MAG implementation to ignore the StreamId completely ? MAG and UE repre= sent the two end points of the air interface and they both have the TFT. S= o, this entire streamId business is total non-sense, specially the key prot= ocols such as SIP have no mapping. So, even if there is public OUI allocati= on, I fail to understand how it fits in the overall scheme of things. So, m= y initial suggestion was to workaround the StreamId and make the spec work. " Additional Comments: > Introduction: "STA" Please add a reference or explanation on "STA" term - Station; In general, = please add references/explanations to all Wi-Fi terminology. OK, will revise > "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]= " Some explanation can help. Will add explanation > However, this document does not exclude various deployments including those where AP and WLC are separate nodes, or the MAG control and data planes are separate." Should there any guidance on how the QoS parameters are negotiated/exchange= d between AP and WLC in the split mode ? Did not want to add specifics since this is implementation specific. > Section 1.2: TSPEC Add a reference to TSPEC OK, will revise > GBR, AMBR Terminology You may want to add a reference to RFC 7222 Terminology section. There is e= xplanation for GBR, AMBR and other parameters OK, will revise. > PMIPV6 Should be PMIPv6 OK. > Handovers ? I did not see much text on what happens to the QoS states after a MN's inte= r-MAG handovers. We refer to RFC 7222 for the overall session handling. In > Section 4.1 Please use "Traffic Class" in the table, instead of "DSCP" OK. > Error Code Mapping RFC7222 defines couple of error codes. Its not clear how those error codes = map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is tha= t all ? Will revise to add other error codes. > Scope: Per-MN, Per-Session, No discussion on the scope. Its unclear how the Per-Session, Per-MN attribu= tes map to different Wi-Fi QoS elements The connection parameters =96 4.1 shows the mapping per session and MN attr= ibutes. Can revise text in introduction that refers to per MN and per session to gi= ve the context. > Security Considerations You may want to add some text on how WLAN security architecture can protect= the integrity of the QoS signaling messages on the air interface. The curr= ent text may not be sufficient. Will review. > References Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used= in call flows Add a reference to UPN/UPA spec (RFC7077) as its used in call flows OK. --_000_D03DD28A164779sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi John,

> With regard to the major comment: - for QoS setup= from AP to STA,  we cannot convey  the relevant flow/stream in 8= 02.11aa (it would need further standardization in IEEE).

May be a recommendation on the needed changes will help.


Regards
Sri

From: John Kaippallimalil <John.Kaippallimalil@huawei.com= >
Date: Tuesday, September 16, 2014 1= 1:34 AM
To: Sri Gundavelli <sgundave@cisco.com>, "netext@ietf.org" <netext@ietf.org>, "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>, Parv= iz Yegani <pyegani@juniper.net>
Subject: RE: Review Comments on I-D= : draft-ietf-netext-pmip-qos-wifi-01

Hi Sri,

Thank you for a very thorough revi= ew and comments.

 

With regard to the major comment: = - for QoS setup from AP to STA,  we cannot convey  the relevant f= low/stream in 802.11aa (it would need further standardization in IEEE).

Rajesh and I can discuss with you = some simple text to address this comment.

 

The other comments are relatively = straightforward (see some notes inline below).

 

In the next revision, we will addr= ess all these comments.

 

Best Regards,

John

 

 

 

From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, September 16, 2014 12:47 AM
To: netext@ietf.org
Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos= -wifi-01

 

Hi Authors:

 

I've reviewed the -01 version of Wi-Fi QoS = document. Its is well written. Its in a good shape. Few comments below.

 

 

 

Major Comment:

 

> Section 3: "However, there are no= standards defined way for the AP to initiate a QoS service request to= the MN."

 

I'm bit disappointed to see the removal of = the support for network initiated QoS set-up.  John, Rajesh and myself= had several offline discussions on this few months back; Here is my comment from earlier discussions. I'm not aski= ng the Authors to add the support for network-initiated dynamic QoS, but I = thought it will be good to get some feedback from others.=

 

"I do not understand the 802.11 guys t= hinking on this entire StreamId business. When I first looked at it this, I= thought this is just a identifier used in Application signaling. But, when this is tied to .1Q, even the basic seman= tics on the StreamId length or how its used in the network is not clear to = me. Their view that the tag is global and can be enforced in the entire net= work seems bit broken. But, that spec is not my area of expertise and so may be I missing the real intent h= ere. 

 

However, when I look at this from PMIP QoS = point of view and with the goal of realizing end to end QoS, the QoS enforc= ement  in this context is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP issue. If = that is the baseline requirement, my point is what stops the UE or the MAG = implementation to ignore the StreamId completely ? MAG and UE represent the= two end points of the air interface and they both have the TFT.  So, this entire streamId business i= s total non-sense, specially the key protocols such as SIP have no mapping.= So, even if there is public OUI allocation, I fail to understand how it fi= ts in the overall scheme of things. So, my initial suggestion was to workaround the StreamId and make the spec work.<= o:p>

" 

 

 

 

Additional Comments:

 

> Introduction: "STA"

Please add a reference or explanation on &q= uot;STA" term - Station; In general, please add references/explanation= s to all Wi-Fi terminology.

OK, will revise<= /p>

 

> "The Mean Data Rate does not= include the MAC and PHY overheads [WMM1.2.0]"

 Some explanation can help.=

Will add explanation

 

> However, this document does not e= xclude

   various deployments including = those where AP and WLC are separate

   nodes, or the MAG control and = data planes are separate."

 

Should there any guidance on how the QoS pa= rameters are negotiated/exchanged between AP and WLC in the split mode ?

Did not want to add specifics sinc= e this is implementation specific.

 

> Section 1.2: TSPEC

Add a reference to TSPEC<= /p>

OK, will revise<= /p>

 

> GBR, AMBR Terminology

You may want to add a reference to RFC 7222= Terminology section. There is explanation for GBR, AMBR and other paramete= rs

OK, will revise.=

 

> PMIPV6 

Should be PMIPv6 

OK.

 

> Handovers ?

I did not see much text on what happens to = the QoS states after a MN's inter-MAG handovers.

We refer to RFC 7222 for the overa= ll session handling.

In

 

> Section 4.1

Please use "Traffic Class" in the= table, instead of "DSCP" 

OK.

 

> Error Code Mapping

RFC7222 defines couple of error codes. Its = not clear how those error codes map to the Cause Codes in ADDTS Response. I= saw just one Cause Code. Is that all ?

Will revise to add other error cod= es.

 

> Scope: Per-MN, Per-Session, =

No discussion on the scope. Its unclear how= the Per-Session, Per-MN attributes map to different Wi-Fi QoS elements

The connection parameters =96 4.1 = shows the mapping per session and MN attributes.

Can revise text in introduction th= at refers to per MN and per session to give the context.<= /p>

 

> Security Considerations

You may want to add some text on how WLAN s= ecurity architecture can protect the integrity of the QoS signaling message= s on the air interface. The current text may not be sufficient.

Will review.

 

 

> References

Informative Reference to RFC 5213 and 5844 = as the PBU/PBA messages are used in call flows

Add a reference to UPN/UPA spec (RFC7077) a= s its used in call flows

OK.

 

 

 

 

 

 --_000_D03DD28A164779sgundaveciscocom_--