From owner-ietf-ppp@merit.edu Mon Mar 4 07:08:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20901 for ; Mon, 4 Mar 2002 07:08:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9E659120F; Mon, 4 Mar 2002 07:08:45 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79D4D9121D; Mon, 4 Mar 2002 07:08:45 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F5449120F for ; Mon, 4 Mar 2002 07:08:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 452605DDD7; Mon, 4 Mar 2002 07:08:44 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C79C15DDCC for ; Mon, 4 Mar 2002 07:08:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20846; Mon, 4 Mar 2002 07:08:40 -0500 (EST) Message-Id: <200203041208.HAA20846@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-02.txt Date: Mon, 04 Mar 2002 07:08:40 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-02.txt Pages : 25 Date : 01-Mar-02 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-rfc2284bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020301135515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020301135515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Mon Mar 4 15:38:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20921 for ; Mon, 4 Mar 2002 15:38:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDB4691225; Mon, 4 Mar 2002 15:38:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5A3991226; Mon, 4 Mar 2002 15:38:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98FE691225 for ; Mon, 4 Mar 2002 15:38:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7766A5DDDD; Mon, 4 Mar 2002 15:38:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from dc-mx08.cluster1.charter.net (unknown [209.225.8.18]) by segue.merit.edu (Postfix) with ESMTP id 4B0AF5DDCC for ; Mon, 4 Mar 2002 15:38:08 -0500 (EST) Received: from [66.189.14.218] (HELO westboro-1.world.std.com) by dc-mx08.cluster1.charter.net (CommuniGate Pro SMTP 3.5.3) with ESMTP id 17134859; Mon, 04 Mar 2002 15:38:03 -0500 Message-Id: <5.1.0.14.0.20020304191529.04bdf330@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Mar 2002 19:29:54 -0500 To: ietf-ppp@merit.edu From: David Jablon Subject: Re: EAP method discussion at EAP BOF In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu A recent Internet-Draft that is relevant to this EAP BOF discussion is: http://search.ietf.org/internet-drafts/draft-jablon-speke-00.txt Title : The SPEKE Password-Based Key Agreement Methods Author(s) : D. Jablon Filename : draft-jablon-speke-00.txt Pages : 25 Date : 13-Feb-02 This document describes SPEKE, B-SPEKE, and SRP-4, three methods for password-based key agreement and authentication. In the same class of techniques as SRP-3 [RFC 2945], these methods provide a zero-knowledge proof of a password and authenticate session keys over an unprotected channel, with minimal dependency on infrastructure and proper user behavior. These methods are compatible with IEEE 1363 and ANSI X9 standards, and are closely aligned with RFC 2945 from an application perspective. They are also based on different fundamental techniques than earlier patented alternatives, providing an expanded set of choices for convenient and secure personal authentication over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jablon-speke-00.txt At 10:39 AM 2/23/02 -0800, Bernard Aboba wrote: >An EAP BoF session has been scheduled at IETF 53. As part of this session, >some time has been set aside for discussion of proposed EAP >methods. We hereby solicit EAP method authors who wish to make a >short (1 slide) presentation on their proposed EAP method. In the >presentation, it can be assumed that BoF participants have read the >draft. > >The slide should cover the following: > >a. Name of the method >b. Justification (why is it unique) >c. Usage scenario (kinds of devices, media, etc.) >d. EAP Type # assigned >e. Authentication (mutual/one-way) >f. Support for "fast reconnect" (yes/no) >g. Dictionary attack vulnerability (yes/no) >h. Key derivation? (yes/no, kinds of keys derived) >i. Algorithms (e.g. does it use existing standard > algorithms or does it create new ones) >j. Standards group dependencies (3GPP, IEEE 802.11i, etc.) Yes, brevity is desirable. But cramming all of the above into a single slide may create an unnecessary burden for both presenter and audience. A few simpler slides should be an acceptable alternate format. >EAP BOF description: > >http://www.ietf.org/ietf/02mar/eap.txt From owner-ietf-ppp@merit.edu Tue Mar 5 06:32:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24360 for ; Tue, 5 Mar 2002 06:32:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 17DFD91243; Tue, 5 Mar 2002 06:32:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3B9191244; Tue, 5 Mar 2002 06:32:02 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8EB4B91243 for ; Tue, 5 Mar 2002 06:32:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B9495DE48; Tue, 5 Mar 2002 06:32:01 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id F12905DDF8 for ; Tue, 5 Mar 2002 06:32:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24261; Tue, 5 Mar 2002 06:31:59 -0500 (EST) Message-Id: <200203051131.GAA24261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-03.txt Date: Tue, 05 Mar 2002 06:31:58 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over ATM Adaptation Layer 2 Author(s) : B. Thompson, T. Koren, B. Buffam Filename : draft-ietf-pppext-ppp-over-aal2-03.txt Pages : Date : 04-Mar-02 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ppp-over-aal2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Tue Mar 5 12:11:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09841 for ; Tue, 5 Mar 2002 12:11:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55C0A9124B; Tue, 5 Mar 2002 12:11:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 258739124C; Tue, 5 Mar 2002 12:11:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0F4169124B for ; Tue, 5 Mar 2002 12:11:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id E935F5DDCC; Tue, 5 Mar 2002 12:11:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by segue.merit.edu (Postfix) with ESMTP id C2ABB5DDB1 for ; Tue, 5 Mar 2002 12:11:22 -0500 (EST) Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id ACO62463; Tue, 5 Mar 2002 11:11:11 -0600 (CST) Received: from tellabs.com (dhcp-172-23-151-63.lisle.tellabs.com [172.23.151.63]) by mail.hq.tellabs.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA16525; Tue, 5 Mar 2002 11:11:00 -0600 (CST) Message-ID: <3C84FC1E.4EEDBFE5@tellabs.com> Date: Tue, 05 Mar 2002 11:10:54 -0600 From: John Sauer X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: PPP over Ethernet Phy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Group, Earl McCoy and I have written an I-D on PPP over a slimmed down Ethernet. The thrust is to remove some functional duplication between IP and underlying Ethernet. We think it is applicable to the pppext group and would like to get your opinion on the draft. See the I-D info below. Thanks, John PS - I already know I got the wrong year on the expiration date on some pages. :-) #### A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPP over Full Duplex Point-to-Point Ethernet Physical Layers Author(s) : E. McCoy, J. Sauer Filename : draft-mccoy-pppext-pppoephy-00.txt Pages : 12 Date : 21-Feb-02 This document provides a definition for encapsulating the PPP protocol directly on the various full duplex point-to-point Ethernet physical layers. The later includes transmission bit rates of 10Mbps, 100Mbps, 1Gbps, and 10Gbps. Note this is a distinct protocol from PPPoE, as the Ethernet frame is not existent here. All PPP packet semantics and syntax are retained. The proposed methods in this document may be especially useful for low cost, high bandwidth physical channel implementations. In particular it specifies and redefines all necessary Ethernet Medium Independent Interface functional 'clauses.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mccoy-pppext-pppoephy-00.txt -- ---------------------------------------------- John Sauer John.Sauer@tellabs.com Tellabs Operations ph: 630.798.5581 1415 West Diehl Road fx: 630.798.5744 Naperville, IL 60563 ---------------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Wed Mar 6 06:48:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02612 for ; Wed, 6 Mar 2002 06:48:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F3FB9125F; Wed, 6 Mar 2002 06:48:30 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1903B91260; Wed, 6 Mar 2002 06:48:30 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04B189125F for ; Wed, 6 Mar 2002 06:48:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB1C15DE17; Wed, 6 Mar 2002 06:48:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 601065DDA5 for ; Wed, 6 Mar 2002 06:48:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02586; Wed, 6 Mar 2002 06:48:25 -0500 (EST) Message-Id: <200203061148.GAA02586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-ppp-over-aal2-03.txt Date: Wed, 06 Mar 2002 06:48:25 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over ATM Adaptation Layer 2 Author(s) : B. Thompson, T. Koren, B. Buffam Filename : draft-ietf-pppext-ppp-over-aal2-03.txt Pages : Date : 04-Mar-02 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ppp-over-aal2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ppp-over-aal2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ppp-over-aal2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Mar 7 19:08:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03678 for ; Thu, 7 Mar 2002 19:08:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D8C8912AF; Thu, 7 Mar 2002 19:07:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F423912B0; Thu, 7 Mar 2002 19:07:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42BC7912AF for ; Thu, 7 Mar 2002 19:07:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F1715DDE9; Thu, 7 Mar 2002 19:07:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from RRMAIL01.RADIOROUTER_NT (unknown [63.103.94.23]) by segue.merit.edu (Postfix) with ESMTP id E24EA5DDBC for ; Thu, 7 Mar 2002 19:07:30 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 19:07:29 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE4647D1CB@ftmail> From: David Reeder To: "'eap@frascone.com'" Cc: "'ietf-ppp@merit.edu'" Subject: Notes on rfc2284bis-02 Date: Thu, 7 Mar 2002 19:07:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I am relatively new to this discussion, apologies if any of the following issues have already been treated or solved. My sense is EAP is a work in progress and that some of the following obseravtions may be useful. Most are well-contained notes about the details in the draft. ISSUE #1 -- Request/Response Type namespace: Advisable to introduce some growing room in the Type namespace given at the top of Section 5 ("Initial EAP Request/Respose Types"). Types 1-3 are EAP control messages, wherease Type 4 is the beginning of the list of authentication types. Clearly EAP is yet incomplete and is likely to grow (possibly in state, operational details and header fields). Why not set the first authentication type at some higher number (25? 50?). This leaves room for new control types. Eg, new Types may be needed for key management. ISSUE #2 -- NAK lists ordered alternatives: Would it be conveient for the NAK (Section 5.3) to return an ordered list of authentication types, instead of just one? Thus both the Peer and Authenticator have more choice as the list of authentication types grows. The list might provide an indicator of security/access policy -- eg, specify a list such as: #1 IKE, #2 OTP, #3 MD5-Challenge. The Authenticator could immediately downgrade to #3 if it is too busy and SLA with the Peer allows it. ISSUE #3 -- Multi-message authentication exchanges: It is not clear how EAP will handle Request/Response Types which, themselves, consist of multi-message exchanges. Eg, IKE requires 3-6 messages. Is Code "Request" always used for messages initiated by the Authenticator, and Code "Response" for all messages from the Peer? How does the identifier change (or not) during the exchange? Assume that it does not change and instead rely on sequence numbers within the given authentication protocol? ISSUE #4 -- Peer plays active as well as passive role: Seems like there should be a clear means for Peer to initate an exchange with Authenticator, rather than having to wait for a Request. This is most important if (eg) a mobile device wishes to have mutual authentication with an access router even though they share no other acceptable authentication method besides MD5-Challenge. More sophisticated authentication methods (IKE, TLS) support mutual authentication no matter who begins the exchange, so this may not be a problem in those cases. Though if it is arbitrary who begins the exchange for these methods, it could be convenient for the Peer to begin the exchange once it detects (eg) an access router advertisement. ISSUE #5 -- Division of labor with PANA WG: There appears to be important overlap between the charters of the PANA and proposed EAP WGs. (Not to mention other WGs such as IPSRA.) This overlap may be removed by collapsing one group into the other, or by clearly distinguishing the role of each. Seems like WG roles might be distinguished very simply: . PANA is concerned with the transport layer(s) of EAP; . EAP is concerned with everything else, and is transport agnostic. Following this guideline, PANA should defer any questions about security (key management, replay protection, &c), protocol state machines, retry mechanisms and robustness of the authentication exchange to EAP. EAP should, in turn, defer any interactions between itself and the layer at which it is transported to PANA. Acting on such guidelines would significantly shrink the PANA charter, and in turn, possibly indicate that Section 3 ("Media-specific issues") be separated out of the BIS draft into a separate document for further specification and maintenance by PANA. david .......................................................................... David Reeder 908/947-7075 804a 2990 2490 47c3 8ef1 23be 39ce d1f5 56c0 a5c5 From owner-ietf-ppp@merit.edu Thu Mar 7 20:29:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06301 for ; Thu, 7 Mar 2002 20:29:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EF77912B0; Thu, 7 Mar 2002 20:29:06 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEBB5912B1; Thu, 7 Mar 2002 20:29:05 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF540912B0 for ; Thu, 7 Mar 2002 20:29:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D34285DE11; Thu, 7 Mar 2002 20:29:04 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 13C8E5DDA4 for ; Thu, 7 Mar 2002 20:29:04 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g280mBC32149; Thu, 7 Mar 2002 16:48:11 -0800 Date: Thu, 7 Mar 2002 16:48:10 -0800 (PST) From: Bernard Aboba To: David Reeder Cc: "'eap@frascone.com'" , "'ietf-ppp@merit.edu'" Subject: Re: Notes on RFC 2284bis In-Reply-To: <8C92E23A3E87FB479988285F9E22BE4647D1CB@ftmail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > EAP is a work in progress and that some of the following obseravtions > may be useful. Actually, RFC 2284 is an IETF Proposed Standard, and thus is not a "work in progress". As a result, RFC 2284bis is about clarifying the specification while remaining backwards-compatible with RFC 2284. So this is not a "greenfield" effort. > Why not set the > first authentication type at some higher number (25? 50?). Because changing existing authentication types would be incompatible with RFC 2284, and existing Method Types allocated by IANA. > Would it be conveient for the NAK (Section 5.3) to return an > ordered list of authentication types, instead of just one? This might be possible while retaining backward compatibility, as long as existing implementations won't discard the NAK packet as a result. This would imply that a peer sending a list of authentication types in the NAK, instead of just one, might get back a type it didn't put in the list, because the other implementation only read the first NAK type and didn't go farther. > It is not clear how EAP will handle Request/Response Types which, > themselves have multiple roundtrips. Existing EAP methods handle this today. See RFC 2716 for an example. > Is Code "Request" always used for messages initiated > by the Authenticator, and Code "Response" for all messages from the > Peer? Yes. > How does the identifier change (or not) during the exchange? We could use more detail on this, I think. Most implementations I have seen increment the Identifier. > Assume that it does not change and instead rely on sequence numbers > within the given authentication protocol? Some protocols do use "Parts" but I have so far not seen sequence numbers. > Seems like there should be a clear means for Peer to initate an > exchange with Authenticator, rather than having to wait for a > Request. EAP is a peer-to-peer protocol. So it's quite feasible for one party to initiate to the other or vice versa. In other words, there's no reason that a NAS couldn't be a peer, and a host couldn't be the authenticator. > This is most important if (eg) a mobile device wishes to > have mutual authentication with an access router even though they > share no other acceptable authentication method besides MD5-Challenge. Since EAP is peer to peer, it's quite feasible for each side to do an MD5-Challenge authentication to the other (although you have to be wary of reflection attacks). > EAP is concerned with everything else, and is transport agnostic. One of the goals of RFC 2284bis is to lay out the requirements that EAP has on the lower layers, and make the protocol more media independent. Assuming this can be achieved, then other WGs and standards bodies can successfully adapt EAP for use with other media and transports. An example of some of the problems we have in this regard are the RFC 2284 references to "alternate indications" of success/failure. These are problematic because not all lower layers provide these indications; also the implementation surveys indicate that few if any implementations actually take these indications into account. However, the lack of an ACK for Success/Failure packets was built on the assumption that "alternate indications" would be available. Thus the discussion about creating new ACK'd EAP Types for Success and Failure. > Following this guideline, PANA should defer any questions about > security (key management, replay protection, &c), protocol state > machines, retry mechanisms and robustness of the authentication > exchange to EAP. I think that makes sense. We already have enough trouble rationalizing a potential EAP state machine with the 802.1X state machine. Thankfully, Bill Arbaugh's group at University of Maryland has signed up to tackle this. Creating yet another potentially incompatible state machine would make their job that much harder. > EAP should, in turn, defer any interactions > between itself and the layer at which it is transported to PANA. I suspect that PANA is not concerned about EAP transport over *all* lower layers, just IP, correct? > Acting on such guidelines would significantly shrink the PANA > charter, and in turn, possibly indicate that Section 3 > ("Media-specific issues") be separated out of the BIS draft into a > separate document for further specification and maintenance by PANA. I'm not clear why PANA would be concerned with how EAP is transported over PPP and IEEE 802. Can you explain? From owner-ietf-ppp@merit.edu Sat Mar 9 22:14:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24488 for ; Sat, 9 Mar 2002 22:14:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B8DB9121D; Sat, 9 Mar 2002 22:14:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD99891225; Sat, 9 Mar 2002 22:14:14 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94A519121D for ; Sat, 9 Mar 2002 22:14:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69AF75DDE8; Sat, 9 Mar 2002 22:14:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E17855DD8F for ; Sat, 9 Mar 2002 22:14:02 -0500 (EST) Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g2A3DmT03895; Sat, 9 Mar 2002 19:13:48 -0800 (PST) (envelope-from dennis@juniper.net) Message-Id: <200203100313.g2A3DmT03895@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: john.sauer@tellabs.com (John Sauer) Cc: ietf-ppp@merit.edu Subject: Re: PPP over Ethernet Phy In-reply-to: Your message of "05 Mar 1902 17:10:54 GMT." <3C84FC1E.4EEDBFE5@tellabs.com> Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 09 Mar 2002 19:13:48 -0800 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu John, > Earl McCoy and I have written an I-D on PPP over a slimmed down > Ethernet. The thrust is to remove some functional duplication between > IP and underlying Ethernet. We think it is applicable to the pppext > group and would like to get your opinion on the draft. See the I-D info > below. I read this with some interest, but discovered I didn't understand the punch line. For the benefit of the uneducated could you perhaps at least include a hint in the document about what a PPP frame is supposed to look like when encapsulated directly on an Ethernet Physical Layer without the Ethernet MAC Layer? For example, is the protocol packet preceded solely by the two-byte PPP protocol identifier, or are there other bytes at the front of the packet too? Does the frame include an FCS, and if so is it a 16-bit or a 32-bit CRC, or what? Are the bits in bytes put on the wire with the most significant or least significant bit first? Do frames still need to be padded out to a minimum of 64 bytes? It is kind of hard to guess this stuff, but it would be easy to draw a few pictures. If you are into describing things in terms of layers, then I think part of the confusion here is that PPP itself is only about half of a "layer 2" and always borrows the other half (framing procedures, error detection and stuff like that) from something that works appropriately over the physical layer in question. For example, "PPP over SONET/SDH" isn't really "PPP over SONET/SDH", it is "PPP in Octet-Synchronous HDLC U/I Frames over SONET/SDH", with the document incorporating what HDLC octet-synchronous HDLC U/I frames look like to make it easy for implementors. Similarly, PPPoE is really "PPP in Ethernet MAC layer frames over Ethernet Physical Layers", and you can't just chuck out the MAC layer framing without fully specifying the framing procedures you are replacing it with, because there are no generic PPP framing procedures to replace it with. You have to make them up. The question I'm really fascinated with, however, is why you want to do this at all? I understand from this This places the data service industry in a dilemma, namely wishing the less costly physical interface of Ethernet layer 1, but not actually needing or wanting Ethernet`s redundant layer 2 packet switching capability, scaling problems, etc. [...] Alternatively, and proposed here, is to retain Ethernet`s full duplex point-to-point physical interface alternatives, but define PPP encapsulation directly - leaving out the redundant MAC frame and hence all Ethernet Layer 2 functionality. The authors believe this is the best of both worlds, and consistent with the Internet`s proven architectural principles. that what you want to accomplish is to remove Ethernet switches from the links between routers, or routers and hosts, but I can't for the life of me figure out why the goal of removing Ethernet switches is not fully accomplished by simply removing the Ethernet switches, wiring the routers and hosts directly together instead? Once the Ethernet switches are physically removed you no longer have a redundant layer 2 packet switching capability, so replacing the Ethernet MAC-level framing in addition to that is unnecessary for this purpose. What additional advantage are you trying to get by doing the latter? Enquiring minds want to know. Dennis Ferguson From owner-ietf-ppp@merit.edu Mon Mar 11 16:02:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24384 for ; Mon, 11 Mar 2002 16:02:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48DBC91257; Mon, 11 Mar 2002 16:02:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14BEE91258; Mon, 11 Mar 2002 16:02:31 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61C4291257 for ; Mon, 11 Mar 2002 16:02:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C8AB5DDD4; Mon, 11 Mar 2002 16:02:30 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by segue.merit.edu (Postfix) with ESMTP id F11935DDCC for ; Mon, 11 Mar 2002 16:02:29 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id ACQ28302; Mon, 11 Mar 2002 15:02:04 -0600 (CST) Received: from tellabs.com (dhcp-172-23-60-7.lisle.tellabs.com [172.23.60.7]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id PAA00383; Mon, 11 Mar 2002 15:02:05 -0600 (CST) Message-ID: <3C8D1B5F.BDA8DA88@tellabs.com> Date: Mon, 11 Mar 2002 15:02:23 -0600 From: Earl McCoy Organization: Tellabs North American Solutions Center X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: dennis@juniper.net Cc: ietf-ppp@merit.edu, John@mailw02.hq.tellabs.com, Sauer@mailw02.hq.tellabs.com Subject: Re: PPP over Ethernet Phy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Dennis: Thanks for your interest and comments. Please see our responses below: Dennis Ferguson wrote: > I read this with some interest, but discovered I didn't understand > the punch line. For the benefit of the uneducated could you perhaps > at least include a hint in the document about what a PPP frame is supposed > to look like when encapsulated directly on an Ethernet Physical Layer > without the Ethernet MAC Layer? For example, is the protocol packet > preceded solely by the two-byte PPP protocol identifier, or are there > other bytes at the front of the packet too? Does the frame include an > FCS, and if so is it a 16-bit or a 32-bit CRC, or what? Are the bits > in bytes put on the wire with the most significant or least significant > bit first? Do frames still need to be padded out to a minimum of 64 > bytes? It is kind of hard to guess this stuff, but it would be easy to > draw a few pictures. We did not explicitly diagram a PPP frame when encapsulated in Ethernet physical layer as we didn't (and don't) feel that necessary. The PPP frame is exactly the usual PPP frame; with or without a FCS, of whatever length, with or without PPP header compression, MLPPP or just PPP. Nothing concerning the PPP frame proper (before encapsulation) is changed. The bit order is Ethernets bit order, as all physical layer encapsulation aspects of Ethernet are unchanged, by definition. Literally we propose a "fork lift upgrade" of PPP frame for Ethernet frame. All PPP details and particulars are beside the point. All aspects of the MAC frame are gone, but the "medium dependent sublayer" of Ethernet remains as the PPP encapsulation method. We did not mention "padding out" to Ethernet's 64-byte minimum frame length, as we understand this is done "above" the Ethernet Medium Dependent Sublayer (hence is done before physical layer encapsulation), and so is not an explicit part of Ethernet encapsulation, and hence need not be mentioned by us. RFC1661 states this concerning padding: "Padding On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information." Our thinking is that there is no need to mention PPP's padding requirement either; it is "above" our encapsulation layer concern. > If you are into describing things in terms of layers, then I think > part of the confusion here is that PPP itself is only about half of > a "layer 2" and always borrows the other half (framing procedures, error > detection and stuff like that) from something that works appropriately > over the physical layer in question. For example, "PPP over SONET/SDH" > isn't really "PPP over SONET/SDH", it is "PPP in Octet-Synchronous HDLC > U/I Frames over SONET/SDH", with the document incorporating what HDLC > octet-synchronous HDLC U/I frames look like to make it easy for > implementors. Similarly, PPPoE is really "PPP in Ethernet MAC layer > frames over Ethernet Physical Layers", and you can't just chuck out > the MAC layer framing without fully specifying the framing procedures > you are replacing it with, because there are no generic PPP framing > procedures to replace it with. You have to make them up. We feel we did specify the framing method, namely both Ethernet encapsulation methods. Your comment concerning "PPP over SONET/SDH" is correct, that HDLC "framing" for idleness encoding and "octet stuffing" for certain ASCII control character "escaping" is the essense of that encapsulation. Likewise, our point is that PPP be encapsulated just as Ethernet is in its two full duplex manifestations, otherwise unchanged. If we are not sufficiently clear on this point we must revise our proposal. > The question I'm really fascinated with, however, is why you want to > do this at all? I understand from this > > This places the data service industry in a dilemma, namely wishing > the less costly physical interface of Ethernet layer 1, but not > actually needing or wanting Ethernet`s redundant layer 2 packet > switching capability, scaling problems, etc. > [...] > Alternatively, and proposed here, is to retain Ethernet`s full > duplex point-to-point physical interface alternatives, but define > PPP encapsulation directly - leaving out the redundant MAC frame and > hence all Ethernet Layer 2 functionality. The authors believe this > is the best of both worlds, and consistent with the Internet`s > proven architectural principles. > > that what you want to accomplish is to remove Ethernet switches from the > links between routers, or routers and hosts, but I can't for the life of > me figure out why the goal of removing Ethernet switches is not fully > accomplished by simply removing the Ethernet switches, wiring the routers > and hosts directly together instead? Once the Ethernet switches are > physically removed you no longer have a redundant layer 2 packet switching > capability, so replacing the Ethernet MAC-level framing in addition to > that is unnecessary for this purpose. What additional advantage are > you trying to get by doing the latter? > > Enquiring minds want to know. > > Dennis Ferguson The issue is not just the removal of Ethernet switches. Rather the issue is - as you state - the "wiring the routers and hosts directly together" - with what and why? PPP over T1/T3/SONET via HDLC-like encapsulation is the historic "non-Ethernet" way, but these interfaces are so expensive that the Ethernet pipe is much preferred. Our point is that this expense is unwarranted and unnecessary IF an Ethernet physical layer encapsulation for PPP is defined - our purpose exactly. PPPoE doesn't really help, as it doesn't remove the protocol redundancy and adds complexity and overhead. However our proposed "PPP over Ethernet Layer 1" both removes the Ethernet switches while also removing the cost of historic T1/T3/SONET interfaces, and reduces protocol redundancy, complexity, and overhead in the bargin. Let us know if this response does not address your comments. Regards, Earl McCoy and John Sauer -- Earl E. McCoy, PhD Application Specialist North American Solutions Center Tellabs, Inc 630-798-3673 desk 630-452-8262 cellular Earl.McCoy@tellabs.com ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Wed Mar 13 00:26:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20109 for ; Wed, 13 Mar 2002 00:26:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A952C91211; Wed, 13 Mar 2002 00:25:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D5889129A; Wed, 13 Mar 2002 00:25:53 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C56B91211 for ; Wed, 13 Mar 2002 00:25:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE24B5DDA9; Wed, 13 Mar 2002 00:25:50 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by segue.merit.edu (Postfix) with SMTP id 752FA5DD90 for ; Wed, 13 Mar 2002 00:25:50 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Mar 12 21:25:37 2002 To: "PPPList" Date: Tue, 12 Mar 2002 21:25:37 -0800 From: "Affan Ahmed" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: affanahmed@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: PPP state machine interactions X-Sender-Ip: 203.215.160.34 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit hello everyone, sometime back i sent out a plea for help. Nobody has come up with a reply as yet. May be it missed your attention. I will try to briefly rephrase my problem again. I just want to know *exactly* how in a working env each of the tlf, tls, tld tlu, events to with respect to each other( LCP,IPCP & CHAP/PAP(assuming these also have the open,close,up,down events!) ). Thats all. ThankYou --- Best Regards Affan Ahmed 2,000,000,000 Web Pages--you only need 1. Save time with My Lycos. http://my.lycos.com From owner-ietf-ppp@merit.edu Wed Mar 13 13:38:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14541 for ; Wed, 13 Mar 2002 13:38:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6CE491222; Wed, 13 Mar 2002 13:38:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90DB691233; Wed, 13 Mar 2002 13:38:03 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 608A091222 for ; Wed, 13 Mar 2002 13:38:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 450915DE48; Wed, 13 Mar 2002 13:38:01 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id BB7805DE46 for ; Wed, 13 Mar 2002 13:38:00 -0500 (EST) Received: from tawei-u5.cisco.com (tawei-u5.cisco.com [171.69.58.65]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DIbud25585 for ; Wed, 13 Mar 2002 10:37:56 -0800 (PST) Date: Wed, 13 Mar 2002 10:37:42 -0800 (PST) From: Tawei Liao To: Subject: adding BPDU bit to RFC2878 frame format Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu We're proposing a new bit definition in the RFC2878 Bridge Control Protocol frame format. I ran this by Fred Baker first. He's in agreement with me but wants some discussion on this topic first. The problem has to do with the treatment of Bridged PDUs in RFC2878. In the IEEE world, all BPDUs have MAC addresses starting with 01-80-C2-00-00-00-xx. The problem is that there are other frame types that are also BPDUs. For instance, 09-00-2B-01-00-01 DEC STP AB-00-00-01-00-00 DEC MOP 01-00-0c-cc-cc-cd Cisco SSTP There are many many more. These control protocol frames should into a separate "high priority" control queue. That way they won't get mixed up with the data frames. Since the RFC2878 frame format doesn't tell us whether a frame is BPDU, we have to resort to parsing the DA MAC. And here lies the problem. Parsing the DA MAC is not a clean and extensible solution because there will always be new control protocols. Rather than relying on the ingress router/switch to "know" about the different layer 2 control protocols, we're proposing adding a new BPDU bit in the FLAGS field in the frame format. The egress box always knows what type of traffic it's sending. If it's sending BPDU control packets, the BPDU bit should be set. The ingress box can then look at that one bit and immediately know that it's a BPDU without parsing the DA MAC. The flags field is currently defined as the following. We have two bits available. We're proposing making "bit 0" currently reserved and set to 0 to become the BPDU bit. +-+-+-+-+-+-+-+-+ |F|0|Z|0| Pads | +-+-+-+-+-+-+-+-+ ^ proposed BPDU bit Flags bit F: Set if the LAN FCS Field is present bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size bit 0: reserved, must be zero Pads Any PPP frame may have padding inserted in the "Optional Data Link Layer Padding" field. This number tells the receiving system how many pad octets to strip off. -tawei -- Tawei Liao || || Cisco Systems || || (408) 853-8905 |||| |||| tawei@cisco.com ..:||||||:..:||||||:.. From owner-ietf-ppp@merit.edu Thu Mar 14 06:43:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15097 for ; Thu, 14 Mar 2002 06:43:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02373912BE; Thu, 14 Mar 2002 06:42:51 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDDCE912BF; Thu, 14 Mar 2002 06:42:50 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC09E912BE for ; Thu, 14 Mar 2002 06:42:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 96F8B5DDC1; Thu, 14 Mar 2002 06:42:49 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id DE3305DD9B for ; Thu, 14 Mar 2002 06:42:48 -0500 (EST) Received: from gatekeeper.noc.anritsu.co.jp (gatekeeper.noc.anritsu.co.jp [172.16.16.20]) by ns.anritsu.co.jp (Postfix) with ESMTP id C833220F01 for ; Thu, 14 Mar 2002 20:42:46 +0900 (JST) Received: from ATS-VIRUS-001 (ats-virus-001.noc.anritsu.co.jp [172.16.16.26]) by gatekeeper.noc.anritsu.co.jp (Postfix) with SMTP id B8FEC20F03 for ; Thu, 14 Mar 2002 20:42:46 +0900 (JST) Received: FROM mail0.cr.anritsu.co.jp BY ATS-VIRUS-001 ; Thu Mar 14 20:39:41 2002 +0900 Received: from ibm0er ([172.16.203.105]) by mail0.cr.anritsu.co.jp (Netscape Messaging Server 3.54) with SMTP id AAAD71; Thu, 14 Mar 2002 20:51:22 +0900 Message-ID: <001901c1cb4d$518d9c80$69cb10ac@ibm0er> From: "Mitsuru Higashiyama" To: "Tawei Liao" , References: Subject: Re: adding BPDU bit to RFC2878 frame format Date: Thu, 14 Mar 2002 20:42:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Tawei, I understand your motivation to do this. But I would like to point out two problems. 1) Backward compatibility. The devices which are implemented RFC2878 or RFC1638 can not handle new flag bit in BCP header. Probably, the BPDU indicator flag should be optional and need negotiation between peer to peer. 2) Two implementations models. I can show two different implementations models. A: Back-end operation for BPDU +------------+ +----------+ +-------------+ +----------+ ====| Line framer |---| PPP and |--| MAC operation |--|BPDU Filter | | | | BCP entity | | | | and Switching +------------+ +----------+ +-------------+ +----------+ | | PPP STP B: Front-end operation for BPDU +------------+ +----------+ +--------- -+ +--------------+ ====| Line framer |---| PPP and |--| BPDU Filter |--| MAC operation | | | | BCP entity | | | | and Switching | +------------+ +----------+ +----- -----+ +--------------+ | | PPP STP In the Front-end operation model, it is easy to mark on BPDU packets. In the other hand, in Back-end operation model, the PPP and BCP entity have to snoop and check all packets and mark on found BPDU packets. I don't have good idea to solve this problem. Best regards, Mitsuru Higashiyama ----- Original Message ----- From: "Tawei Liao" To: Sent: Thursday, March 14, 2002 3:37 AM Subject: adding BPDU bit to RFC2878 frame format > We're proposing a new bit definition in the RFC2878 Bridge Control > Protocol frame format. I ran this by Fred Baker first. He's in > agreement with me but wants some discussion on this topic first. > > The problem has to do with the treatment of Bridged PDUs in RFC2878. > In the IEEE world, all BPDUs have MAC addresses starting with > 01-80-C2-00-00-00-xx. The problem is that there are other frame > types that are also BPDUs. For instance, > > 09-00-2B-01-00-01 DEC STP > AB-00-00-01-00-00 DEC MOP > 01-00-0c-cc-cc-cd Cisco SSTP > > There are many many more. These control protocol frames should into > a separate "high priority" control queue. That way they won't get > mixed up with the data frames. > > Since the RFC2878 frame format doesn't tell us whether a frame is > BPDU, we have to resort to parsing the DA MAC. And here lies the > problem. Parsing the DA MAC is not a clean and extensible solution > because there will always be new control protocols. > > Rather than relying on the ingress router/switch to "know" about the > different layer 2 control protocols, we're proposing adding a new > BPDU bit in the FLAGS field in the frame format. The egress box > always knows what type of traffic it's sending. If it's sending > BPDU control packets, the BPDU bit should be set. The ingress box > can then look at that one bit and immediately know that it's a BPDU > without parsing the DA MAC. > > The flags field is currently defined as the following. We have two > bits available. We're proposing making "bit 0" currently reserved > and set to 0 to become the BPDU bit. > > +-+-+-+-+-+-+-+-+ > |F|0|Z|0| Pads | > +-+-+-+-+-+-+-+-+ > ^ > proposed BPDU bit > > > Flags > > bit F: Set if the LAN FCS Field is present > bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size > bit 0: reserved, must be zero > > > Pads > > Any PPP frame may have padding inserted in the "Optional Data Link > Layer Padding" field. This number tells the receiving system how > many pad octets to strip off. > > > -tawei > > -- > Tawei Liao || || > Cisco Systems || || > (408) 853-8905 |||| |||| > tawei@cisco.com ..:||||||:..:||||||:.. > From owner-ietf-ppp@merit.edu Thu Mar 14 13:34:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24997 for ; Thu, 14 Mar 2002 13:34:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5215C912D2; Thu, 14 Mar 2002 13:34:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F745912D4; Thu, 14 Mar 2002 13:34:20 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E95F7912D2 for ; Thu, 14 Mar 2002 13:34:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id C23EC5DE19; Thu, 14 Mar 2002 13:34:18 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 740DD5DDCC for ; Thu, 14 Mar 2002 13:34:18 -0500 (EST) Received: from tawei-u5.cisco.com (tawei-u5.cisco.com [171.69.58.65]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EIYFd22844; Thu, 14 Mar 2002 10:34:16 -0800 (PST) Date: Thu, 14 Mar 2002 10:34:00 -0800 (PST) From: Tawei Liao To: Mitsuru Higashiyama Cc: Subject: Re: adding BPDU bit to RFC2878 frame format In-Reply-To: <001901c1cb4d$518d9c80$69cb10ac@ibm0er> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Thu, 14 Mar 2002, Mitsuru Higashiyama wrote: > Tawei, > > I understand your motivation to do this. > But I would like to point out two problems. > 1) Backward compatibility. > The devices which are implemented RFC2878 or RFC1638 can not handle > new flag bit in BCP header. Probably, the BPDU indicator flag should be > optional > and need negotiation between peer to peer. Mitsuru, thanks for the quick reply. I'm aware of the compatibility issue. RFC2878 currently requires the reserved bit to be set to 0. We could make this BPDU bit optional like you described. > 2) Two implementations models. > I can show two different implementations models. > > A: Back-end operation for BPDU I'm not certain I understand the two models that you're describing below. I'll draw what I believe to be the two common cases of operation (no tabs in text drawings please :-). This is the case where we have a single box that can switch between LAN links like ethernet or fdddi and ppp-encapsulated ethernet/fddi. STP runs on this box of course. The box knows when it's sending BPDUs and can mark the egress BCP packets accordingly. I believe that this is the most common scenario. This kind of operation that integrates LAN and WAN is what defines the typical edge router. +-----------+ --- PPP/BCP --- | Switching |-----ethernet/fddi | PPP | | STP |-----ethernet/fddi +-----------+ This second scenario is the case where we have one box that just does L2 switching and another WAN box that does PPP. I believe that this is a less common scenario because any box that can take input from a LAN interface typically can also perform the LAN operations like L2 switching and STP. +--------+ +------------+ --- PPP/BCP ---| WAN |--- ethernet/fddi ---| LAN switch |-- ether/fddi | router | | STP |-- ether/fddi +--------+ +------------+ The WAN router makes no L2 switching decision. It takes ether/fddi as input and sends it out of the PPP/BCP link. It has to look at every single frame and do the proper encap/decap. The marking of the BPDU bit happens here. In order for the WAN router to properly queue the frames, it has to be able to distinguish between data frames and BPDU frames. The parsing of DA MAC has to happen on the ingress ether/fddi link. On the egress PPP link, the BPDU bit would be set. At the other end of the PPP/BCP link, the WAN router doesn't need to parse the DA MAC yet again, it can look at the BPDU bit and immediately decide to put the BPDU frames into a control queue and put the non-BPDU frames into one or more data queues. The burden of marking the BPDU bit is always on the egress box. With a BPDU bit, this operation doesn't need to happen yet again on the ingress box. -tawei > > +------------+ +----------+ +-------------+ +----------+ > ====| Line framer |---| PPP and |--| MAC operation |--|BPDU Filter | > | | | BCP entity | | | > | and Switching > +------------+ +----------+ +-------------+ +----------+ > | > | > PPP > STP > > B: Front-end operation for BPDU > > +------------+ +----------+ +--------- -+ +--------------+ > ====| Line framer |---| PPP and |--| BPDU Filter |--| MAC operation | > | | | BCP entity | | | | > and Switching | > +------------+ +----------+ +----- -----+ +--------------+ > | | > PPP STP > > In the Front-end operation model, it is easy to mark on BPDU packets. > In the other hand, in Back-end operation model, the PPP and BCP entity > have to snoop and check all packets and mark on found BPDU packets. > > I don't have good idea to solve this problem. > > Best regards, > Mitsuru Higashiyama > > > > ----- Original Message ----- > From: "Tawei Liao" > To: > Sent: Thursday, March 14, 2002 3:37 AM > Subject: adding BPDU bit to RFC2878 frame format > > > > We're proposing a new bit definition in the RFC2878 Bridge Control > > Protocol frame format. I ran this by Fred Baker first. He's in > > agreement with me but wants some discussion on this topic first. > > > > The problem has to do with the treatment of Bridged PDUs in RFC2878. > > In the IEEE world, all BPDUs have MAC addresses starting with > > 01-80-C2-00-00-00-xx. The problem is that there are other frame > > types that are also BPDUs. For instance, > > > > 09-00-2B-01-00-01 DEC STP > > AB-00-00-01-00-00 DEC MOP > > 01-00-0c-cc-cc-cd Cisco SSTP > > > > There are many many more. These control protocol frames should into > > a separate "high priority" control queue. That way they won't get > > mixed up with the data frames. > > > > Since the RFC2878 frame format doesn't tell us whether a frame is > > BPDU, we have to resort to parsing the DA MAC. And here lies the > > problem. Parsing the DA MAC is not a clean and extensible solution > > because there will always be new control protocols. > > > > Rather than relying on the ingress router/switch to "know" about the > > different layer 2 control protocols, we're proposing adding a new > > BPDU bit in the FLAGS field in the frame format. The egress box > > always knows what type of traffic it's sending. If it's sending > > BPDU control packets, the BPDU bit should be set. The ingress box > > can then look at that one bit and immediately know that it's a BPDU > > without parsing the DA MAC. > > > > The flags field is currently defined as the following. We have two > > bits available. We're proposing making "bit 0" currently reserved > > and set to 0 to become the BPDU bit. > > > > +-+-+-+-+-+-+-+-+ > > |F|0|Z|0| Pads | > > +-+-+-+-+-+-+-+-+ > > ^ > > proposed BPDU bit > > > > > > Flags > > > > bit F: Set if the LAN FCS Field is present > > bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum > size > > bit 0: reserved, must be zero > > > > > > Pads > > > > Any PPP frame may have padding inserted in the "Optional Data > Link > > Layer Padding" field. This number tells the receiving system > how > > many pad octets to strip off. > > > > > > -tawei > > > > -- > > Tawei Liao || || > > Cisco Systems || || > > (408) 853-8905 |||| |||| > > tawei@cisco.com ..:||||||:..:||||||:.. > > > > From owner-ietf-ppp@merit.edu Fri Mar 15 02:33:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22729 for ; Fri, 15 Mar 2002 02:33:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D16191227; Fri, 15 Mar 2002 02:33:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36F5991229; Fri, 15 Mar 2002 02:33:20 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CAE391227 for ; Fri, 15 Mar 2002 02:33:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AC3E5DDE2; Fri, 15 Mar 2002 02:33:19 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id 644D85DDA9 for ; Fri, 15 Mar 2002 02:33:18 -0500 (EST) Received: from gatekeeper.noc.anritsu.co.jp (gatekeeper.noc.anritsu.co.jp [172.16.16.20]) by ns.anritsu.co.jp (Postfix) with ESMTP id 7500920F01 for ; Fri, 15 Mar 2002 16:33:17 +0900 (JST) Received: from ATS-VIRUS-001 (ats-virus-001.noc.anritsu.co.jp [172.16.16.26]) by gatekeeper.noc.anritsu.co.jp (Postfix) with SMTP id D982D20F06 for ; Fri, 15 Mar 2002 16:33:13 +0900 (JST) Received: FROM mail0.cr.anritsu.co.jp BY ATS-VIRUS-001 ; Fri Mar 15 16:30:07 2002 +0900 Received: from ibm0er ([172.16.203.105]) by mail0.cr.anritsu.co.jp (Netscape Messaging Server 3.54) with SMTP id AAA74EE; Fri, 15 Mar 2002 16:41:48 +0900 Message-ID: <003601c1cbf3$9c7884c0$69cb10ac@ibm0er> From: "Mitsuru Higashiyama" To: "Tawei Liao" Cc: References: Subject: Re: adding BPDU bit to RFC2878 frame format Date: Fri, 15 Mar 2002 16:32:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Tawei, > On Thu, 14 Mar 2002, Mitsuru Higashiyama wrote: (CUT) > > 2) Two implementations models. > > I can show two different implementations models. > > > > A: Back-end operation for BPDU > > I'm not certain I understand the two models that you're describing > below. I'll draw what I believe to be the two common cases of > operation (no tabs in text drawings please :-). Sorry for my shortage of explanation. The models I draw are device internal architectures. The lines in the drawing are internal BUS instead of networks. In the backend model, network cable/fiber is connected to line framer like as Modem LSI or SONET Framer. The processor (CPU or FPGA) receive PPP format packet and process PPP. LCP and BCP control packets are terminated at there. All Ethernet/FDDI frame include BPDU are forwarded to MAC entity. MAC entity process FCS / Learning and filtering / Link Aggregation load-balance / Tag-Untag operation and multicast copy. In the MAC entity or back of MAC entiry may parse DA MAC and distinguish between data frames and BPDU frames. --- Mitsuru > This is the case where we have a single box that can switch between > LAN links like ethernet or fdddi and ppp-encapsulated ethernet/fddi. > STP runs on this box of course. The box knows when it's sending BPDUs > and can mark the egress BCP packets accordingly. I believe that this is > the most common scenario. This kind of operation that integrates > LAN and WAN is what defines the typical edge router. > > +-----------+ > --- PPP/BCP --- | Switching |-----ethernet/fddi > | PPP | > | STP |-----ethernet/fddi > +-----------+ > > This second scenario is the case where we have one box that just > does L2 switching and another WAN box that does PPP. I believe that > this is a less common scenario because any box that can take input > from a LAN interface typically can also perform the LAN operations > like L2 switching and STP. > > +--------+ +------------+ > --- PPP/BCP ---| WAN |--- ethernet/fddi ---| LAN switch |-- ether/fddi > | router | | STP |-- ether/fddi > +--------+ +------------+ > > The WAN router makes no L2 switching decision. It takes ether/fddi as > input and sends it out of the PPP/BCP link. It has to look at every > single frame and do the proper encap/decap. The marking of the BPDU > bit happens here. > > In order for the WAN router to properly queue the frames, it has to be > able to distinguish between data frames and BPDU frames. The parsing > of DA MAC has to happen on the ingress ether/fddi link. On the egress > PPP link, the BPDU bit would be set. > > At the other end of the PPP/BCP link, the WAN router doesn't need to > parse the DA MAC yet again, it can look at the BPDU bit and > immediately decide to put the BPDU frames into a control queue and > put the non-BPDU frames into one or more data queues. > > The burden of marking the BPDU bit is always on the egress box. > With a BPDU bit, this operation doesn't need to happen yet again on > the ingress box. > > -tawei > > > > > +------------+ +----------+ +-------------+ +----------+ > > ====| Line framer |---| PPP and |--| MAC operation |--|BPDU Filter | > > | | | BCP entity | | | > > | and Switching > > +------------+ +----------+ +-------------+ +----------+ > > | > > | > > PPP > > STP > > > > B: Front-end operation for BPDU > > > > +------------+ +----------+ +--------- -+ +--------------+ > > ====| Line framer |---| PPP and |--| BPDU Filter |--| MAC operation | > > | | | BCP entity | | | | > > and Switching | > > +------------+ +----------+ +----- -----+ +--------------+ > > | | > > PPP STP > > > > In the Front-end operation model, it is easy to mark on BPDU packets. > > In the other hand, in Back-end operation model, the PPP and BCP entity > > have to snoop and check all packets and mark on found BPDU packets. > > > > I don't have good idea to solve this problem. > > > > Best regards, > > Mitsuru Higashiyama > > > > > > > > ----- Original Message ----- > > From: "Tawei Liao" > > To: > > Sent: Thursday, March 14, 2002 3:37 AM > > Subject: adding BPDU bit to RFC2878 frame format > > > > > > > We're proposing a new bit definition in the RFC2878 Bridge Control > > > Protocol frame format. I ran this by Fred Baker first. He's in > > > agreement with me but wants some discussion on this topic first. > > > > > > The problem has to do with the treatment of Bridged PDUs in RFC2878. > > > In the IEEE world, all BPDUs have MAC addresses starting with > > > 01-80-C2-00-00-00-xx. The problem is that there are other frame > > > types that are also BPDUs. For instance, > > > > > > 09-00-2B-01-00-01 DEC STP > > > AB-00-00-01-00-00 DEC MOP > > > 01-00-0c-cc-cc-cd Cisco SSTP > > > > > > There are many many more. These control protocol frames should into > > > a separate "high priority" control queue. That way they won't get > > > mixed up with the data frames. > > > > > > Since the RFC2878 frame format doesn't tell us whether a frame is > > > BPDU, we have to resort to parsing the DA MAC. And here lies the > > > problem. Parsing the DA MAC is not a clean and extensible solution > > > because there will always be new control protocols. > > > > > > Rather than relying on the ingress router/switch to "know" about the > > > different layer 2 control protocols, we're proposing adding a new > > > BPDU bit in the FLAGS field in the frame format. The egress box > > > always knows what type of traffic it's sending. If it's sending > > > BPDU control packets, the BPDU bit should be set. The ingress box > > > can then look at that one bit and immediately know that it's a BPDU > > > without parsing the DA MAC. > > > > > > The flags field is currently defined as the following. We have two > > > bits available. We're proposing making "bit 0" currently reserved > > > and set to 0 to become the BPDU bit. > > > > > > +-+-+-+-+-+-+-+-+ > > > |F|0|Z|0| Pads | > > > +-+-+-+-+-+-+-+-+ > > > ^ > > > proposed BPDU bit > > > > > > > > > Flags > > > > > > bit F: Set if the LAN FCS Field is present > > > bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum > > size > > > bit 0: reserved, must be zero > > > > > > > > > Pads > > > > > > Any PPP frame may have padding inserted in the "Optional Data > > Link > > > Layer Padding" field. This number tells the receiving system > > how > > > many pad octets to strip off. > > > > > > > > > -tawei > > > > > > -- > > > Tawei Liao || || > > > Cisco Systems || || > > > (408) 853-8905 |||| |||| > > > tawei@cisco.com ..:||||||:..:||||||:.. > > > > > > > > From owner-ietf-ppp@merit.edu Fri Mar 15 17:18:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12111 for ; Fri, 15 Mar 2002 17:18:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50DA3912E4; Fri, 15 Mar 2002 17:18:22 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15AB8912FA; Fri, 15 Mar 2002 17:18:21 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9901C912E4 for ; Fri, 15 Mar 2002 17:18:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 774CA5DE02; Fri, 15 Mar 2002 17:18:20 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 2EDCD5DDB1 for ; Fri, 15 Mar 2002 17:18:20 -0500 (EST) Received: from tawei-u5.cisco.com (tawei-u5.cisco.com [171.69.58.65]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2FMIId24763; Fri, 15 Mar 2002 14:18:18 -0800 (PST) Date: Fri, 15 Mar 2002 14:18:03 -0800 (PST) From: Tawei Liao To: Mitsuru Higashiyama Cc: Subject: Re: adding BPDU bit to RFC2878 frame format In-Reply-To: <003601c1cbf3$9c7884c0$69cb10ac@ibm0er> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Mitsuru and I will take this discussion offline so as to not spam everybody with the gory details. If you'd like to participate reply to me only. thanks, -tawei On Fri, 15 Mar 2002, Mitsuru Higashiyama wrote: > Hello Tawei, > > > On Thu, 14 Mar 2002, Mitsuru Higashiyama wrote: > (CUT) > > > > 2) Two implementations models. > > > I can show two different implementations models. > > > > > > A: Back-end operation for BPDU > > > > I'm not certain I understand the two models that you're describing > > below. I'll draw what I believe to be the two common cases of > > operation (no tabs in text drawings please :-). > > Sorry for my shortage of explanation. > The models I draw are device internal architectures. > > The lines in the drawing are internal BUS instead of networks. > > > > In the backend model, network cable/fiber is connected to line > > framer like as Modem LSI or SONET Framer. The processor (CPU > > or FPGA) receive PPP format packet and process PPP. > > LCP and BCP control packets are terminated at there. > > All Ethernet/FDDI frame include BPDU are forwarded to MAC > > entity. MAC entity process FCS / Learning and filtering / > > Link Aggregation load-balance / Tag-Untag operation > > and multicast copy. In the MAC entity or back of MAC entiry > > may parse DA MAC and distinguish between data frames and > > BPDU frames. > > > > --- > Mitsuru > > > This is the case where we have a single box that can switch between > > LAN links like ethernet or fdddi and ppp-encapsulated ethernet/fddi. > > STP runs on this box of course. The box knows when it's sending BPDUs > > and can mark the egress BCP packets accordingly. I believe that this is > > the most common scenario. This kind of operation that integrates > > LAN and WAN is what defines the typical edge router. > > > > +-----------+ > > --- PPP/BCP --- | Switching |-----ethernet/fddi > > | PPP | > > | STP |-----ethernet/fddi > > +-----------+ > > > > This second scenario is the case where we have one box that just > > does L2 switching and another WAN box that does PPP. I believe that > > this is a less common scenario because any box that can take input > > from a LAN interface typically can also perform the LAN operations > > like L2 switching and STP. > > > > +--------+ +------------+ > > --- PPP/BCP ---| WAN |--- ethernet/fddi ---| LAN switch |-- ether/fddi > > | router | | STP |-- ether/fddi > > +--------+ +------------+ > > > > The WAN router makes no L2 switching decision. It takes ether/fddi as > > input and sends it out of the PPP/BCP link. It has to look at every > > single frame and do the proper encap/decap. The marking of the BPDU > > bit happens here. > > > > In order for the WAN router to properly queue the frames, it has to be > > able to distinguish between data frames and BPDU frames. The parsing > > of DA MAC has to happen on the ingress ether/fddi link. On the egress > > PPP link, the BPDU bit would be set. > > > > At the other end of the PPP/BCP link, the WAN router doesn't need to > > parse the DA MAC yet again, it can look at the BPDU bit and > > immediately decide to put the BPDU frames into a control queue and > > put the non-BPDU frames into one or more data queues. > > > > The burden of marking the BPDU bit is always on the egress box. > > With a BPDU bit, this operation doesn't need to happen yet again on > > the ingress box. > > > > -tawei > > > > > > > > +------------+ +----------+ +-------------+ +----------+ > > > ====| Line framer |---| PPP and |--| MAC operation |--|BPDU Filter > | > > > | | | BCP entity | | > | > > > | and Switching > > > +------------+ +----------+ +-------------+ +----------+ > > > | > > > | > > > PPP > > > STP > > > > > > B: Front-end operation for BPDU > > > > > > +------------+ +----------+ +--------- -+ +--------------+ > > > ====| Line framer |---| PPP and |--| BPDU Filter |--| MAC > operation | > > > | | | BCP entity | | | > | > > > and Switching | > > > +------------+ +----------+ +----- -----+ +--------------+ > > > | | > > > PPP STP > > > > > > In the Front-end operation model, it is easy to mark on BPDU packets. > > > In the other hand, in Back-end operation model, the PPP and BCP entity > > > have to snoop and check all packets and mark on found BPDU packets. > > > > > > I don't have good idea to solve this problem. > > > > > > Best regards, > > > Mitsuru Higashiyama > > > > > > > > > > > > ----- Original Message ----- > > > From: "Tawei Liao" > > > To: > > > Sent: Thursday, March 14, 2002 3:37 AM > > > Subject: adding BPDU bit to RFC2878 frame format > > > > > > > > > > We're proposing a new bit definition in the RFC2878 Bridge Control > > > > Protocol frame format. I ran this by Fred Baker first. He's in > > > > agreement with me but wants some discussion on this topic first. > > > > > > > > The problem has to do with the treatment of Bridged PDUs in RFC2878. > > > > In the IEEE world, all BPDUs have MAC addresses starting with > > > > 01-80-C2-00-00-00-xx. The problem is that there are other frame > > > > types that are also BPDUs. For instance, > > > > > > > > 09-00-2B-01-00-01 DEC STP > > > > AB-00-00-01-00-00 DEC MOP > > > > 01-00-0c-cc-cc-cd Cisco SSTP > > > > > > > > There are many many more. These control protocol frames should into > > > > a separate "high priority" control queue. That way they won't get > > > > mixed up with the data frames. > > > > > > > > Since the RFC2878 frame format doesn't tell us whether a frame is > > > > BPDU, we have to resort to parsing the DA MAC. And here lies the > > > > problem. Parsing the DA MAC is not a clean and extensible solution > > > > because there will always be new control protocols. > > > > > > > > Rather than relying on the ingress router/switch to "know" about the > > > > different layer 2 control protocols, we're proposing adding a new > > > > BPDU bit in the FLAGS field in the frame format. The egress box > > > > always knows what type of traffic it's sending. If it's sending > > > > BPDU control packets, the BPDU bit should be set. The ingress box > > > > can then look at that one bit and immediately know that it's a BPDU > > > > without parsing the DA MAC. > > > > > > > > The flags field is currently defined as the following. We have two > > > > bits available. We're proposing making "bit 0" currently reserved > > > > and set to 0 to become the BPDU bit. > > > > > > > > +-+-+-+-+-+-+-+-+ > > > > |F|0|Z|0| Pads | > > > > +-+-+-+-+-+-+-+-+ > > > > ^ > > > > proposed BPDU bit > > > > > > > > > > > > Flags > > > > > > > > bit F: Set if the LAN FCS Field is present > > > > bit Z: Set if IEEE 802.3 Pad must be zero filled to > minimum > > > size > > > > bit 0: reserved, must be zero > > > > > > > > > > > > Pads > > > > > > > > Any PPP frame may have padding inserted in the "Optional > Data > > > Link > > > > Layer Padding" field. This number tells the receiving > system > > > how > > > > many pad octets to strip off. > > > > > > > > > > > > -tawei > > > > > > > > -- > > > > Tawei Liao || || > > > > Cisco Systems || || > > > > (408) 853-8905 |||| |||| > > > > tawei@cisco.com ..:||||||:..:||||||:.. > > > > > > > > > > > > > > From owner-ietf-ppp@merit.edu Fri Mar 15 21:32:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15910 for ; Fri, 15 Mar 2002 21:32:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F1319122F; Fri, 15 Mar 2002 21:32:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FDD29125B; Fri, 15 Mar 2002 21:32:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 918CF9122F for ; Fri, 15 Mar 2002 21:32:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 602F15DE38; Fri, 15 Mar 2002 21:32:06 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EDD8D5DDB4 for ; Fri, 15 Mar 2002 21:32:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2G1oPk28222; Fri, 15 Mar 2002 17:50:25 -0800 Date: Fri, 15 Mar 2002 17:50:25 -0800 (PST) From: Bernard Aboba To: eap@frascone.com Cc: ietf-ppp@merit.edu Subject: Presentations for EAP BOF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu John and I are in the process of revising the EAP BOF agenda. If you've indicated that you would be presenting, we'd like to get the following: a. Confirmation. This includes the names of people presenting. b. References to documents if the doc isn't on the IETF archive and you haven't already sent it to the list. c. Slides. d. Estimated time required. Thanks! From owner-ietf-ppp@merit.edu Sat Mar 16 12:20:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06396 for ; Sat, 16 Mar 2002 12:20:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC9BA9120D; Sat, 16 Mar 2002 12:20:04 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 947B791214; Sat, 16 Mar 2002 12:20:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67BCB9120D for ; Sat, 16 Mar 2002 12:20:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 121805DE00; Sat, 16 Mar 2002 12:20:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id BBA695DD97 for ; Sat, 16 Mar 2002 12:20:02 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Sat Mar 16 12:19:53 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g2GHJqk02915; Sat, 16 Mar 2002 12:19:53 -0500 (EST) Received: from localhost (guard.research.bell-labs.com [135.104.2.9]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA06564; Sat, 16 Mar 2002 12:19:52 -0500 (EST) Subject: Re: [eap] Presentations for EAP BOF From: Luca Salgarelli To: Bernard Aboba Cc: eap@frascone.com, ietf-ppp@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Mar 2002 12:19:51 -0500 Message-Id: <1016299192.6152.8.camel@gandalf> Mime-Version: 1.0 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bernard, I will be presenting 1 slide on EAP-SKE, explaining the points according to your message below: > a. Name of the method > b. Justification (why is it unique) > c. Usage scenario (kinds of devices, media, etc.) > d. EAP Type # assigned > e. Authentication (mutual/one-way) > f. Support for "fast reconnect" (yes/no) > g. Dictionary attack vulnerability (yes/no) > h. Key derivation? (yes/no, kinds of keys derived) > i. Algorithms (e.g. does it use existing standard > algorithms or does it create new ones) > j. Standards group dependencies (3GPP, IEEE 802.11i, etc.) The document can be found at: http://search.ietf.org/internet-drafts/draft-salgarelli-pppext-eap-ske-00.txt I will need 5 minutes. Thanks Luca On Fri, 2002-03-15 at 20:50, Bernard Aboba wrote: > John and I are in the process of revising the EAP BOF agenda. If you've > indicated that you would be presenting, we'd like to get the following: > > a. Confirmation. This includes the names of people presenting. > b. References to documents if the doc isn't on the IETF archive and you > haven't already sent it to the list. > c. Slides. > d. Estimated time required. > > Thanks! > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From owner-ietf-ppp@merit.edu Sun Mar 17 11:43:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05194 for ; Sun, 17 Mar 2002 11:43:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2903B91217; Sun, 17 Mar 2002 11:42:59 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F32E491218; Sun, 17 Mar 2002 11:42:58 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1951691217 for ; Sun, 17 Mar 2002 11:42:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id E78375DDAC; Sun, 17 Mar 2002 11:42:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 68FD35DDA1 for ; Sun, 17 Mar 2002 11:42:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2HG1KJ29012; Sun, 17 Mar 2002 08:01:20 -0800 Date: Sun, 17 Mar 2002 08:01:20 -0800 (PST) From: Bernard Aboba To: David Jablon Cc: eap@frascone.com, ietf-ppp@merit.edu Subject: Re: Presentations for EAP BOF In-Reply-To: <5.1.0.14.0.20020317153944.00a48310@pop.theworld.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At this point, the agenda is very full. If you would like to present an EAP method, we can allocate 5 minutes. On Sun, 17 Mar 2002, David Jablon wrote: > Bernard, > > I'll have a few slides on EAP methods and password authenticated > key exchange protocols, and their relation to some issues in your earlier > message, plus some others. It should take about 10-15 minutes. > > Some relevant documents are > http://www.ietf.org/rfc/rfc2945.txt, > http://www.ietf.org/internet-drafts/draft-jablon-speke-00.txt > and several of the eap drafts, including > http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-srp-03.txt > http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt > > Thanks. > > -- David > > At 05:50 PM 3/15/02 -0800, Bernard Aboba wrote: > >John and I are in the process of revising the EAP BOF agenda. If you've > >indicated that you would be presenting, we'd like to get the following: > > > >a. Confirmation. This includes the names of people presenting. > >b. References to documents if the doc isn't on the IETF archive and you > >haven't already sent it to the list. > >c. Slides. > >d. Estimated time required. > > From owner-ietf-ppp@merit.edu Tue Mar 19 07:06:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20040 for ; Tue, 19 Mar 2002 07:06:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A16FB91249; Tue, 19 Mar 2002 07:06:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 692F79124A; Tue, 19 Mar 2002 07:06:19 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B2FF91249 for ; Tue, 19 Mar 2002 07:06:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49E065DE7C; Tue, 19 Mar 2002 07:06:18 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3F5C05DD8C for ; Tue, 19 Mar 2002 07:06:14 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2JC3ZZ19677 for ; Tue, 19 Mar 2002 14:03:36 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 14:03:23 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 14:03:22 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 14:03:21 +0200 content-class: urn:content-classes:message Subject: RE: Presentations for EAP BOF MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1CF3E.104DB84C" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 19 Mar 2002 14:03:21 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Presentations for EAP BOF Thread-Index: AcHMktzq8/vdhmdtR6aNnoeoqo2V6QCqlJGw From: To: , , , Cc: X-OriginalArrivalTime: 19 Mar 2002 12:03:21.0649 (UTC) FILETIME=[10995210:01C1CF3E] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CF3E.104DB84C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bernard, We'd like to briefly present EAP/AKA (draft-arkko-pppext-eap-aka) and EAP/SIM (draft-haverinen-pppext-eap-sim). Both drafts are available at IETF archives. TJ Kniveton and Jari Arkko will present the drafts. We only have two slides, one slide per method. Please find the slides=20 attached. Estimated time is 4-5 minutes. Best regards, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 16 March, 2002 03:50 > To: eap@frascone.com > Cc: ietf-ppp@merit.edu > Subject: Presentations for EAP BOF >=20 >=20 > John and I are in the process of revising the EAP BOF agenda.=20 > If you've > indicated that you would be presenting, we'd like to get the=20 > following: >=20 > a. Confirmation. This includes the names of people presenting.=20 > b. References to documents if the doc isn't on the IETF=20 > archive and you > haven't already sent it to the list. =20 > c. Slides.=20 > d. Estimated time required.=20 >=20 > Thanks! >=20 >=20 ------_=_NextPart_001_01C1CF3E.104DB84C Content-Type: application/vnd.ms-powerpoint; name="EAP_type_one_pagers.ppt" Content-Description: EAP_type_one_pagers.ppt Content-Disposition: attachment; filename="EAP_type_one_pagers.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAHgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////MwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA ADQAAAD+////IAAAAP7///8iAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAAP7////+////NQAAADYAAAA3AAAAOAAAADkAAAA6 AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgA AAD+//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAMBClYISxMEB HwAAAIACAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAA8GAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEAAACgIgAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwCAAAAAAAADwDo A2UTAAABAOkDKAAAAGAYAADgEAAAjxAAAOgXAAAFAAAACgAAAAIAAAADAAAAAQACAAAAAAEPAPID HgIAAC8AyA/qAAAAMADSDwQAAAACAAAAAAC6DygAAAAYIBwgCP8UMDv/W/8IMAowDDAOMBAw5f8E /yQAKABbAFwAewBi/+H/EAC6D6YAAAABMAIwDP8O//swGv8b/x//Af+bMJww/TD+MJ0wnjAFMPww GSAdIAn/FTA9/13/CTALMA0wDzARMLAAMCAyIDMgAyHg/wX/QTBDMEUwRzBJMGMwgzCFMIcwjjCh MKMwpTCnMKkwwzDjMOUw5zDuMPUw9jAhACUAKQAsAC4AOgA7AD8AXQB9AGH/Y/9k/2X/Z/9o/2n/ av9r/2z/bf9u/2//cP+e/5//DwDVB0wAAAAAALcPRAAAAFIAbwB0AGkAcwAgAFMAYQBuAHMAIABT AGUAcgBpAGYAIABmAG8AcgAgAE4AbwBrAGkAYQAAAAAAYNYSACAmDDAAAAYiAACkDwwAAACAAGIA AAD/////FAAAAKUPDgAAAAAAABguAAAAWgACAAAAAACrDx4AAAD/HwAABQDgAQAAAAAAAGgBaAHQ AtACOAQ4BKAFoAUAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAA ZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUA AEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBFgCAAAPAADwUAIAAAAABvCgAQAA AswAADMAAAAWAAAABQAAAAEAAABSAAAABAAAAAQAAAADAAAAAgAAAAAAAAAEAAAAAAAAAAcAAAAA AAAACQAAAAAAAAAIAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAhAAAAAAAAABsAAAAAAAAABwAAAAAA AAAMAAAAAAAAABIAAAAAAAAACAAAAAAAAAAlAAAAAAAAABgAAAAAAAAAdwAAAAAAAAAEAAAABQAA AD4AAAAAAAAABgAAAAAAAAALAAAAAAAAAAsAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAA CQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAG AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAIAAAAAAAAAAQA AAAAAAAAAgAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAMAAAAAAAAAAYAAAAAAAAABgAA AAAAAAAEAAAAAgAAAAQAAAADAQvwYAAAAIABAAAAAIEBAAAACIMBAAAACL8BEAAQAMABAQAACMEB AAABAMQBAAAAAMsBnDEAAM0BAAAAAM4BAAAAANABAAAAANEBAAAAANcBAgAAAP8BCAAIAAECAgAA CD8CAAACAIAAGvEgAAAAzOz/AGdnZwCpqakA/P65AAY96ACiwf4A+v0AAMD++QBAAB7xEAAAAKLB /gD/////AgAACPcAABAfAPAPHAAAAAAA8wMUAAAABAAAAAQAAAAAAAAAAAAAgAAAAAAPANAHvQEA AB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3J AMqaOwACAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABZAAAAZAAAAFkAAABkAAAAZKcMMAgA AAAAAAAAVNYSAAAAAAAAAAAAfvz//7j///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAA ADAMAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGc/DDAQ2hIAAAAAANBCHwQAAAAA AAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAZz8MMBDaEgAA AAAA0EIfBAAAAAAAAAAAAAAAAAAAAAAAARIAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQA AABnPwwwENoSAAAAAADQQh8EAAAAAAAAAAAAAAAAAAAAAAAAEgAPAIgTOgAAAA8AihMyAAAAAAC6 Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAALwDIDwwAAAAwANIPBAAAAIAAAAA/ANkPDAAAAAAA 2g8EAAAAAAAlAA8A8A9KDAAAAADzAxQAAAAWAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8bAAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvQUtBAACqDxwAAAATAAAAAAAAAAgAAAAG AAAACwQAAAEAAAAAAAAAEACfDwQAAAABAAAAAACgD4wFAABGAGkAbABlAG4AYQBtAGUAOgAgAGQA cgBhAGYAdAAtAGEAcgBrAGsAbwAtAHAAcABwAGUAeAB0AC0AZQBhAHAALQBhAGsAYQANAEoAdQBz AHQAaQBmAGkAYwBhAHQAaQBvAG4AOgAgAFUATQBUAFMAIABhAG4AZAAgAFAAbABhAGkAbgAgAEcA UwBNACAAQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAYQBuAGQAIABLAGUAeQAgAEEAZwBy AGUAZQBtAGUAbgB0AC4AIABQAG8AcwBzAGkAYgBpAGwAaQB0AHkAIAB0AG8AIAB1AHMAZQAgAFUA TQBUAFMALwBHAFMATQAgAHIAbwBhAG0AaQBuAGcAIABhAG4AZAAgAFUAUwBJAE0ALwBTAEkATQAg AGMAYQByAGQAcwAuACAADQBVAHMAYQBnAGUAIABzAGMAZQBuAGEAcgBpAG8AOgAgAFcATABBAE4A IABhAGMAYwBlAHMAcwAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAuACAAQQBuAHkAIAB0 AHkAcABlACAAbwBmACAAZABlAHYAaQBjAGUAcwAgACgAbQBvAGIAaQBsAGUAIABwAGgAbwBuAGUA LAAgAFAARABBACwAIABQAEMAIABjAGEAcgBkACkAIAANAEUAQQBQACAAVAB5AHAAZQAgACMAIABh AHMAcwBpAGcAbgBlAGQAOgAgADIAMwANAE0AdQB0AHUAYQBsACAAYQB1AHQAaABlAG4AdABpAGMA YQB0AGkAbwBuACAAaQBuACAAVQBNAFQAUwAgAG0AbwBkAGUALAAgAG8AbgBlAC0AdwBhAHkAIABh AHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABpAG4AIABHAFMATQAgAG0AbwBkAGUADQBTAHUA cABwAG8AcgB0ACAAZgBvAHIAIAAiAGYAYQBzAHQAIAByAGUAYwBvAG4AbgBlAGMAdAAcIDoAIABu AG8AdAAgAGkAbgAgAHQAaABlACAAYwB1AHIAcgBlAG4AdAAgAGQAcgBhAGYAdAAgAHYAZQByAHMA aQBvAG4ADQBEAGkAYwB0AGkAbwBuAGEAcgB5ACAAYQB0AHQAYQBjAGsAIAB2AHUAbABuAGUAcgBh AGIAaQBsAGkAdAB5ADoAIABuAG8ADQBLAGUAeQAgAGQAZQByAGkAdgBhAHQAaQBvAG4AOgAgAGEA IAAxADIAOAAtAGIAaQB0ACAAYwBpAHAAaABlAHIAIABrAGUAeQAgAGEAbgBkACAAYQAgADEAMgA4 AC0AYgBpAHQAIABpAG4AdABlAGcAcgBpAHQAeQAgAGsAZQB5ACAAaQBuACAAVQBNAFQAUwAgAG0A bwBkAGUALgAgAEEAIAA1ADYALQBiAGkAdAAgAGUAbgBjAHIAeQBwAHQAaQBvAG4AIABrAGUAeQAg AGkAbgAgAEcAUwBNACAAbQBvAGQAZQAuAA0AQQBsAGcAbwByAGkAdABoAG0AcwA6ACAAVQBNAFQA UwAgAGEAbABnAG8AcgBpAHQAaABtAHMALAAgAEcAUwBNACAAYQBsAGcAbwByAGkAdABoAG0AcwAu ACAASQBkAGUAbgB0AGkAdAB5ACAAcAByAGkAdgBhAGMAeQAgAHcAaQB0AGgAIABwAHMAZQB1AGQA bwBuAHkAbQBzAC4ADQBTAHQAYQBuAGQAYQByAGQAcwAgAGcAcgBvAHUAcAAgAGQAZQBwAGUAbgBk AGUAbgBjAGkAZQBzADoAIAAgAHAAbwB0AGUAbgB0AGkAYQBsACAAMwBHAFAAUAAsACAASQBFAEUA RQAgADgAMAAyAC4AMQAxAGkAIAB1AHMAYQBnAGUAAAChDyoAAADHAgAAAAAAAAAANAAAAAAAAgAU ADMAAAABAAIAAQAUAGACAAAAAAIAFAAAAKoPLAAAABAAAAAAAAAABQAAAAEAAAADAAEAAAAAAAAA BgAAAAEAAAADAKsCAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8bAAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvU0lNEACfDwQAAAABAAAAAACgD/4EAABG AGkAbABlAG4AYQBtAGUAOgAgAGQAcgBhAGYAdAAtAGgAYQB2AGUAcgBpAG4AZQBuAC0AcABwAHAA ZQB4AHQALQBlAGEAcAAtAHMAaQBtAA0ASgB1AHMAdABpAGYAaQBjAGEAdABpAG8AbgA6ACAARQBu AGgAYQBuAGMAZQBkACAARwBTAE0AIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4ALgAgAFAA bwBzAHMAaQBiAGkAbABpAHQAeQAgAHQAbwAgAHUAcwBlACAAZQB4AGkAcwB0AGkAbgBnACAARwBT AE0AIABTAEkATQAgAGMAYQByAGQAcwAgAGEAbgBkACAARwBTAE0AIAByAG8AYQBtAGkAbgBnACAA aQBuAGYAcgBhAHMAdAByAHUAYwB0AHUAcgBlAC4AIAANAFUAcwBhAGcAZQAgAHMAYwBlAG4AYQBy AGkAbwA6ACAAVwBMAEEATgAgAGEAYwBjAGUAcwBzACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkA bwBuAC4AIABBAG4AeQAgAHQAeQBwAGUAIABvAGYAIABkAGUAdgBpAGMAZQBzACAAKABtAG8AYgBp AGwAZQAgAHAAaABvAG4AZQAsACAAUABEAEEALAAgAFAAQwAgAGMAYQByAGQAKQANAEUAQQBQACAA VAB5AHAAZQAgACMAIABhAHMAcwBpAGcAbgBlAGQAOgAgADEAOAANAE0AdQB0AHUAYQBsACAAYQB1 AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuAA0AUwB1AHAAcABvAHIAdAAgAGYAbwByACAAIgBmAGEA cwB0ACAAcgBlAGMAbwBuAG4AZQBjAHQAHCA6ACAAbgBvAHQAIABpAG4AIAB0AGgAZQAgAGMAdQBy AHIAZQBuAHQAIABkAHIAYQBmAHQAIAB2AGUAcgBzAGkAbwBuAA0ARABpAGMAdABpAG8AbgBhAHIA eQAgAGEAdAB0AGEAYwBrACAAdgB1AGwAbgBlAHIAYQBiAGkAbABpAHQAeQA6ACAAbgBvAA0ASwBl AHkAIABkAGUAcgBpAHYAYQB0AGkAbwBuADoAIAB5AGUAcwAsACAAYQBuAHkAIABrAGkAbgBkACAA bwBmACAAawBlAHkAcwANAEEAbABnAG8AcgBpAHQAaABtAHMAOgAgAEcAUwBNACAAYQBsAGcAbwBy AGkAdABoAG0AcwAgAHcAaQB0AGgAIABuAGUAdwAgAGUAbgBoAGEAbgBjAGUAbQBlAG4AdABzACAA ZgBvAHIAIABtAHUAdAB1AGEAbAAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAgAGEAbgBk ACAAcwB0AHIAbwBuAGcAZQByACAAawBlAHkAIABkAGUAcgBpAHYAYQB0AGkAbwBuAC4AIABJAGQA ZQBuAHQAaQB0AHkAIABwAHIAaQB2AGEAYwB5ACAAdwBpAHQAaAAgAHAAcwBlAHUAZABvAG4AeQBt AHMALgANAFMAdABhAG4AZABhAHIAZABzACAAZwByAG8AdQBwACAAZABlAHAAZQBuAGQAZQBuAGMA aQBlAHMAOgAgAFAAbwB0AGUAbgB0AGkAYQBsACAAMwBHAFAAUAAsACAASQBFAEUARQAgADgAMAAy AC4AMQAxAGkAIAB1AHMAYQBnAGUADQAAAKEPKgAAAIACAAAAAAAAAAA4AAAAAAACABQAGwAAAAEA AgABABQALQIAAAAAAgAUAAAAqg8+AAAAEAAAAAAAAAAJAAAAAQAAAAEAAQAAAAAAAAAGAAAAAQAA AAEABQAAAAAAAAADAAAAAQAAAAEAWAIAAAAAAAABAAEEUAAAAAAAAAH///9/AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABIAAADqAwAAAAAPAPgD4hwAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAA AAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAGAA8AcgAAAAAAD/AP///wAAAAAA//8A AP+ZAAAA//8A/wAAAJaWlgBgAPAHIAAAAP//zAAAAAAAZmYzAICAAAAzmTMAgAAAAAAzzAD/zGYA YADwByAAAAD///8AAAAAADMzMwAAAAAA3d3dAICAgABNTU0A6urqAGAA8AcgAAAA////AAAAAACA gIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/AP8A AAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD/ /T8AAAAiIAAAZAAAAAAAAQBaAAAAAAAAAAAA4AEAAAAAAgAAAP//7wABAAAA////////JAAAAAAB AAAQAKMPiAAAAAUA//0/AAUAIiAAAGQAAAAABAAAWgAoAAAAsQAAAOABAAAAAAIAAAD//+8AAAAA AP///////xgAAAAAAQAASCUAAA0ASwAAAKQBKQEAAAAAAAUAANMCWAIAAAIAEgDsNQAAAQATIGQA AAAAAGQAFABxBMIDAAACABQAgAUAALsAoAXvBAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAA AAAAWgAoAAAAAAAAAOABAAAAAAIAAAD//+8AAAAAAP///////woAAAAAAQAAAAUAACABIAEAAAAA AAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD04AAAAFAAAAAQkAAAQAAQAA AAAAAAABAAAJAAABACABAAAAAAIAAAkAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAA AQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow9CAAAABQAAAAAAAAAAAAIAFAABAAABAAAp AQAAAgAUAAIAAAEAAFgCAAACABAAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjD0IAAAAFAAAA AAAAAAAAAgASAAEAAAEAACkBAAACABIAAgAAAQAAWAIAAAIADgADAAAAAAAAAAIAEAAEAAAAAAAA AAIAEAAPAAwEBBkAAA8AAvD8GAAAEAAI8AgAAAAMAAAAUQQAADAAGPEMAAAAAQAAAAIAAAADAAAA DwAD8IYYAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAP AATwKgEAABIACvAIAAAAAgQAAAAKAAADAQvwYAAAAH8AAQABAIAAgC0fBIEAeGEBAIIAoq0AAIMA eGEBAIQAoq0AAIcAAQAAAL8AEAAfAIEBAAAACIMBAAAACL8BAQARAMABAQAACMsBnDEAAP8BAQAJ AAECAgAACD8CAAACABMAIvEGAAAAvwMAAAAEAAAQ8AgAAACQACABLBdAAg8AEfAQAAAAAADDCwgA AAAAAAAAAQAfBA8ADfB0AAAAAACfDwQAAAAAAAAAAACoDywAAABUaXRsZTogMzYgcHQgUm90aXMg U2FucyBTZXJpZiBmb3IgTm9raWEgQm9sZAAAog8GAAAALQAAAAAAAACnDwwAAAAAAAAALQAAAAEA AAAAAKoPCgAAAC0AAAABAAAAAAAPAATwTgAAABIACvAIAAAADgQAAAAKAABDAAvwGAAAAIEBAHD/ AL8BAAAQAP8BAAAIAIgDAQAAABMAIvEGAAAAvwMAAAAEAAAQ8AgAAAASDyATXhc/EA8ABPAsAQAA EgAK8AgAAAAdBAAAAAoAAOMAC/BUAAAAgACMOR8EgQB4YQEAggCirQAAgwB4YQEAhACirQAAvwAS AB8AgQEAAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA/wEAAAgAAQICAAAIPwIAAAIAEwAi8QYA AAC/AwAAAAQAABDwCAAAADMQkADADLgQDwAN8JoAAAAAAJ8PBAAAAAQAAAAAAKAPKAAAACoAIAAg ACAAIAAgACAAIACpACAATgBPAEsASQBBACAAMgAwADAAMgAAAKEPLAAAABUAAAAAAAAQAABaAAkA AAAAAAIACQABAAAAAgACAAIACQALAAAAAAACAAkAAADYDwQAAAAAAAAAAACmDxYAAADxHgAA/gBo AWgB0ALQAjgEOASgBaAFDwAE8PgBAAASAArwCAAAACEEAAAACgAA8wAL8FoAAAB/AAEAAQCAAJQw HwSBAHhhAQCCAKKtAACDAHhhAQCEAKKtAAC/ABAAHwCBAQAAAAiDAQAAAAi/AQEAEQDAAQEAAAjL AZwxAAD/AQEACQABAgIAAAg/AgAAAgATACLxBgAAAL8DAAAABAAAEPAIAAAA0AIgAUAXkA8PABHw EAAAAAAAwwsIAAAAAQAAAAIAHwQPAA3wSAEAAAAAnw8EAAAAAQAAAAAAqA/8AAAATm9raWEgUG93 ZXJQb2ludCA5OVRlbXBsYXRlIC0gSnVseSAxOTk5CyhSb3RpcyBTYW5zIFNlcmlmIGZvciBOb2tp YSAyNCBwdCkNMXN0IExldmVsIEJ1bGxldA0ybmQgTGV2ZWwgQnVsbGV0DTNyZCBMZXZlbCBCdWxs ZXQNDQ0NDUNIQU5HRSBUSEUgQ09ERSA9IEZpbGUgbmFtZQsoUm90aXMgU2FucyBTZXJpZiBmb3Ig Tm9raWEgOSBwdCkgCzcgY2hhcmFjdGVycyArIGEgKGFuaW1hdGVkKSBzIChzdGlsbCkuUFBUC0RB VEU6IGRkLm1tLnl5eXkLAACiDx4AAABcAAAAAAARAAAAAQASAAAAAgABAAAAAQB9AAAAAAAAAKoP CgAAAP0AAAABAAAAAAAPAAPwkhMAAA8ABPBOAAAAAQAJ8BAAAACWFAAAABAAAKAXAAB/EAAAAgAK 8AgAAABCBAAAAQIAAAMAC/AAAAAAEwAi8QYAAAC/AwAAAAQAABDwCAAAAAAQlhSgF38QDwAE8PAD AAACAArwCAAAACQEAAACCgAAwwgL8MADAACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACH AAAAAACIAAAAAACJAAAAAAC/AAAADwAIAQAAAQAJAQAAAAAMAfQAABANAQAAACAOAQAAACA/AQAA BgBCAWABAABDAfgAAABEAQQAAABFwTQAAABGwT4AAAB/AQEAAQCAAQAAAACBAQBSugCCAQAAAQCD Af///wCEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAA AACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACW AQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ARwAHgDAAQAAAADBAQAA AQDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADM AQAACADNAQAAAADOAQAAAADPwQAAAADSAQEAAADTAQEAAADUAQEAAADVAQEAAADXAQIAAAD/ARYA HgAAAgAAAAABAoCAgAACAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJ AgAAAQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAA AwCAAgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/ AgEADwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAA AADJAgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADS AiBOAADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYA HwAEAwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACG A3y+AQCHAwAAAAANAA0A8P9KAPgAAAD4AAAAAACAAAAAFgG6ABcBvQAXAQAAYAEAAGAB+ADiAPgA SgA+AEoAOwBKAPgAHAAgAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAJYUAAABEAAARhUAAH4QAAAPAATwZgAAABIACvAIAAAA JQQAAAIKAACTAAvwNgAAAL8AAAAPAD8BAAAGAIEBAFK6AL8BHAAeAP8BBgAOAD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAAAAD/AQAAAAChYAAAEQAAAwFgAAfhAAAA8ABPDAAwAAAgAK8AgAAAAmBAAA AgoAAMMIC/CQAwAAgQAwZQEAggCYsgAAgwAwZQEAhACYsgAAhQAAAAAAhwAAAAAAiAAAAAAAiQAA AAAAvwAAAA8ACAEAAAEACQEAAAAADAH0AAAQDQEAAAAgDgEAAAAgPwEAAAYAQgEAAQAAQwH4AAAA RAEEAAAARcEcAAAARsEmAAAAfwEBAAEAgAEAAAAAgQEAUroAggEAAAEAgwH///8AhAEAAAEAhQEA AAAghkEAAAAAh8EAAAAAiAEAAAAAiQEAAAAAigEAAAAAiwEAAAAAjAEAAAAAjQEAAAAAjgEAAAAA jwEAAAAAkAEAAAAAkQEAAAAAkgEAAAAAkwEAAAAAlAEAAAAAlQEAAAAAlgEAAAAAl8EAAAAAmAEA AAAAmQEAAAAAmgEAAAAAmwEAAAAAnAEDAABAvwEcAB4AwAEAAAAAwQEAAAEAwwEAAAAgxAEAAAAA xUEAAAAAxsEAAAAAxwEAAAAAyAEAAAAAyQEAAAAAygEAAAAAywE1JQAAzAEAAAgAzQEAAAAAzgEA AAAAz8EAAAAA0gEBAAAA0wEBAAAA1AEBAAAA1QEBAAAA1wECAAAA/wEWAB4AAAIAAAAAAQKAgIAA AgLLy8sAAwIAAAAgBAIAAAEABQI4YwAABgI4YwAABwIAAAAACAIAAAAACQIAAAEACgIAAAAACwIA AAAADAIAAAEADQIAAAAADgIAAAAADwIAAQAAEAIAAAAAEQIAAAAAPwIAAAMAgAIAAAAAgQIAAAEA ggIFAAAAgwKcMQAAhAIAAAAAhQLw+QYAhgIAAAAAhwL3AAAQiAIAAAAgvwIBAA8AwAIAAAAAwQIA AAAAwgJkAAAAwwIAAAAAxAIAAAAAxQIAAAAAxgIAAAAAxwIAAAAAyAIAAAAAyQIAAAAAygIwdQAA ywLQEhMAzAIw7ez/zQJAVIkAzgIAgAAAzwIAgP//0AIAAHn/0QIyAAAA0gIgTgAA0wJQwwAA1AIA AAAA1QIQJwAA1gJwlAAA1wKwPP//2AIAAAAA2QIQJwAA2gJwlAAA/wIWAB8ABAMBAAAAQQOoKQEA QgMAAAAAQwMDAAAARAN8vgEARQMAAAAAfwMAAA8AhAN8vgEAhQMAAAAAhgN8vgEAhwMAAAAABwAH APD/hgAAAO4AAABfAHoAAAH4AI8A+AAAAHoAhgAAABAAFAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAAwFgAAARAAALAWAAB+EAAADwAE8GYAAAASAArwCAAAACcEAAAC CgAAkwAL8DYAAAC/AAAADwA/AQAABgCBAQBSugC/ARwAHgD/AQYADgA/AgAAAwC/AgEADwD/AhYA HwB/AwAADwAAAA/wEAAAALcWAAABEAAA3hYAAH4QAAAPAATw+AMAAAIACvAIAAAAKAQAAAIKAADT CAvwyAMAAH8ACAAIAIEAMGUBAIIAmLIAAIMAMGUBAIQAmLIAAIUAAAAAAIcAAAAAAIgAAAAAAIkA AAAAAL8AAAAPAAgBAAABAAkBAAAAAAwB9AAAEA0BAAAAIA4BAAAAID8BAAAGAEIBdQEAAEMB+AAA AEQBBAAAAEXBNAAAAEbBQAAAAH8BAQABAIABAAAAAIEBAFK6AIIBAAABAIMB////AIQBAAABAIUB AAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAAAIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAA AI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMBAAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgB AAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAAQL8BHAAeAMABAAAAAMEBAAABAMMBAAAAIMQBAAAA AMVBAAAAAMbBAAAAAMcBAAAAAMgBAAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4B AAAAAM/BAAAAANIBAQAAANMBAQAAANQBAQAAANUBAQAAANcBAgAAAP8BFgAeAAACAAAAAAECgICA AAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkCAAABAAoCAAAAAAsC AAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAADAIACAAAAAIECAAAB AIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8CAQAPAMACAAAAAMEC AAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAAAMkCAAAAAMoCMHUA AMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANICIE4AANMCUMMAANQC AAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAfAAQDAQAAAEEDqCkB AEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYDfL4BAIcDAAAAAA0A DQDw/24AzQBWAPgAAAD4AIkAAADsAAAAdQH4AB8B+AAHAc0AbgDNAIoAlwDrAJcAuwA+AIoAlwAd ACAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYABAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAADlFgAAARAAAKAXAAB+EAAADwAE8JgGAAACAArwCAAAACkEAAACCgAA0wgL 8GgGAAB/AAgACACBADBlAQCCAJiyAACDADBlAQCEAJiyAACFAAAAAACHAAAAAACIAAAAAACJAAAA AAC/AAAADwAIAQAAAQAJAQAAAAAMAfQAABANAQAAACAOAQAAACA/AQAABgBCAUkBAABDAf4AAABE AQQAAABFwYQBAABGwZABAAB/AQEAAQCAAQAAAACBAQBSugCCAQAAAQCDAf///wCEAQAAAQCFAQAA ACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACKAQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACP AQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAAAACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAA AACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ARwAHgDAAQAAAADBAQAAAQDDAQAAACDEAQAAAADF QQAAAADGwQAAAADHAQAAAADIAQAAAADJAQAAAADKAQAAAADLATUlAADMAQAACADNAQAAAADOAQAA AADPwQAAAADSAQEAAADTAQEAAADUAQEAAADVAQEAAADXAQIAAAD/ARYAHgAAAgAAAAABAoCAgAAC AsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAAAQAKAgAAAAALAgAA AAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCAAgAAAACBAgAAAQCC AgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEADwDAAgAAAADBAgAA AADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJAgAAAADKAjB1AADL AtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBOAADTAlDDAADUAgAA AADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAEAwEAAABBA6gpAQBC AwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+AQCHAwAAAABhAGEA 8P8AAEEAAAA1AAIAMAADACoABQAlAAkAHwAMABsAEQAWABoADwAeAAwAIwAJAC4ABgA9AAMATwAB AGcAAAClAAAA4gAAAPoAAQAMAQMAGwEGACUBCQAwAQ8AOQEWAD0BGwBAAR8AQwElAEQBKgBHATAA RwE1AEkBQQBJAWYASQG7AEcByQBHAc4ARAHUAEMB2QBAAd8APQHjADkB6AAwAe8AJQH0ABkB+AAK AfsA+QD9AOIA/gCkAP4AZQD+AE8A/QA9APsALgD4ACMA9AAaAO8AEQDoAAwA4wAJAN8ABQDZAAMA 1AACAM4AAADJAAAAuwAAAEEARgCxAEYAtQBIALgASQC7AEwAvQBPAL4AUgC+AF4AwADrAMAA8QDA APcAvgD6AL0A/QC7AAABugACAbcAAwG1AAMBsQADAZUAAwFNAAMBSQACAUYAAAFDAP8AQAD8AEAA 9wA+AO0APQBeAD0AWAA+AFIAPgBPAEAATABBAEkARABIAEcARgBJAEYATQBGALEAxQDIAAIAAEAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA VhUAAAAQAAD6FQAAfxAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAAwAAHMAC/AqAAAAgQEAAAAIkwEe QJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJGRkQAAAAAA YY/9AACuAAD8ASgAzs7OACAAug8kAAAAQgBsAGEAbgBrACAAUAByAGUAcwBlAG4AdABhAHQAaQBv AG4ADwDwA4MCAAABAPEDCAAAAAAAAIAAAAwwDwAMBEMCAAAPAALwOwIAAEAACPAIAAAAAwAAAAMI AAAPAAPw2QEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAA AA8ABPApAQAAEgAK8AgAAAACCAAAAAoAAPMAC/BaAAAAfwABAAEAgACYff8AgQBmXQEAggCiqwAA gwBmXQEAhACiqwAAvwAQAB8AgQEAAAAIgwEAAAAIvwEBABEAwAEBAAAIywGcMQAA/wEBAAkAAQIC AAAIPwIAAAIAAAAQ8AgAAABlCzUCWg40Fg8AEfAQAAAAAADDCwgAAAADAAAABgL/AA8ADfCHAAAA AACfDwQAAAACAAAAAACoDzsAAABCb2R5IFRleHQNU2Vjb25kIExldmVsDVRoaXJkIExldmVsDUZv dXJ0aCBMZXZlbA1GaWZ0aCBMZXZlbAAAog8eAAAACgAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA AAQAAACqDwoAAAA8AAAAAQAAAAAADwAE8HAAAAASAArwCAAAAAMIAAAACgAAgwAL8DAAAAB/AAQA BACHAAEAAAB/AQAAAQC/AQEAEQDAAQEAAAjLAZwxAAD/AQgACQA/AgEAAwAAABDwCAAAABQCPAJT DnQKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAP8ADwAE8EIAAAASAArwCAAAAAEIAAAADAAAcwAL8CoA AACBAQAAAAiTAZPHZgCUAfpXlAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAkZGRAAAAAABhj/0AAK4AAPwBKADOzs4ADwDJD8oAAAAPAAwEmgAAAA8AAvCSAAAAMAAI8AgA AAABAAAAAQwAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAWAACAArwCAAA AAAMAAAFAAAADwAE8EIAAAASAArwCAAAAAEMAAAADAAAcwAL8CoAAACBAQAAAAiTAZPHZgCUAfpX lAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAAAABhj/0AAK4A APwBKADOzs4ADwDuA+QBAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASUAQAA DwAC8IwBAAAgAAjwCAAAAAMAAAADyAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAMgAAAUAAAAPAATwcgAAABIACvAIAAAAAsgAACACAABTAAvwHgAAAH8A AAAEAIAAeCQfBL8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAkAAgASwXQAIPABHwEAAAAAAAwwsI AAAAAAAAAA0AHwQPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADyAAAIAIAAFMA C/AeAAAAfwAAAAQAgADIJB8EvwEAAAEA/wEAAAEAAQMhBAAAAAAQ8AgAAADQAiABQBeQDw8AEfAQ AAAAAADDCwgAAAABAAAADgAfBA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHI AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAAAABhj/0AAK4AAPwBKADOzs4ADwDuA94BAAACAO8D GAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASOAQAADwAC8IYBAABQAAjwCAAAAAMAAAA9 UAAADwAD8B4BAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAFAAAAUA AAAPAATwcgAAABIACvAIAAAAHlAAACACAABTAAvwHgAAAAQAAAAAAIAAmCUfBL8BAAABAP8BAAAB AAEDAgQAAAAAEPAIAAAAkAAgASwXQAIPABHwEAAAAAAAwwsIAAAAAAAAAA0AHwQPAA3wDAAAAAAA ng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAAkUAAAIAIAAEMAC/AYAAAAgACUHx8EvwEAAAEA/wEA AAEAAQMhBAAAAAAQ8AgAAADQAiABQBeQDw8AEfAQAAAAAADDCwgAAAABAAAADgAfBA8ADfAMAAAA AACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAFQAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiT AR5AlwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAA AABhj/0AAK4AAPwBKADOzs4AAAByFyAAAAABAFAAAAAAAFcwAADiMgAAbRMAAKA1AAAWABAAtDMA AAAA9Q8cAAAAAQEAAK8RAAMAAAAAhjcAAAEAAAAWAAAAAQAAAA8A6ANZEwAAAQDpAygAAABgGAAA 4BAAAI8QAADoFwAABQAAAAoAAAACAAAAAwABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AP7////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3V nC4bEJOXCAArLPmuMAAAAAwCAAARAAAAAQAAAJAAAAADAAAAmAAAAA4AAAC4AAAADwAAAMQAAAAE AAAA1AAAAAYAAADcAAAABwAAAOQAAAAIAAAA7AAAAAkAAAD0AAAACgAAAPwAAAAXAAAABAEAAAsA AAAMAQAAEAAAABQBAAATAAAAHAEAABYAAAAkAQAADQAAACwBAAAMAAAAqgEAAAIAAADkBAAAHgAA ABYAAABBNCBQYXBlciAoMjEweDI5NyBtbSkAaAAeAAAAAQAAAAA0IFAeAAAABgAAAE5va2lhAGVy AwAAAPBgAAADAAAAFgAAAAMAAAACAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAADIRCQAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAEAAAAGwAAAFJvdGlzIFNhbnMgU2Vy aWYgZm9yIE5va2lhABMAAABCbGFuayBQcmVzZW50YXRpb24AHAAAAE5hbWUgb2YgdGhlIG1ldGhv ZDogRUFQL0FLQQAcAAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvU0lNAAwQAAAGAAAAHgAAAAsA AABGb250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAA DQAAAFNsaWRlIFRpdGxlcwADAAAAAgAAAAAAQAAAAAAA9g8gAAAAFAAAAF/AkePMYAAACAD0AwMA HwRoZWhhdmVyaQgAAABoAGUAaABhAHYAZQByAGkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP aBCrkQgAKyez2TAAAABwIgAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAvAAAAAQAAADIAAAABQAA ANwAAAAGAAAA6AAAAAcAAABsAQAACAAAALABAAAJAAAAxAEAABIAAADQAQAACgAAAPQBAAALAAAA AAIAAAwAAAAMAgAADQAAABgCAAAOAAAAJAIAAA8AAAAsAgAAEQAAADQCAAACAAAA5AQAAB4AAAAc AAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvU0lNAB4AAAABAAAAAGFtZR4AAAAJAAAAaGVoYXZl cmkAaGUgHgAAAAEAAAAAZWhhHgAAAHwAAABOb2tpYSBTdGFuZGFyZCBQcmVzZW50YXRpb24gVGVt cGxhdGUgLSBBNA0Kdi4gNCAyMDAwLzAxLzA1IEVyaWMgQmVhc2xleQ0KRml4ZWQgUkdCIHZhbHVl cyBmb3IgTm9raWEgbG9nbw0KTk8gU2VjdXJpdHkgTGFiZWwAHgAAADoAAABDOlxVU0VSU1xVU0VS SU5GXE1TT0ZGSUNFXFRFTVBMQVRFXEJsYW5rIFByZXNlbnRhdGlvbi5wb3QAIEUeAAAACQAAAGhl aGF2ZXJpAFVTRR4AAAADAAAAMzcAYR4AAAAZAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQgNC4wAFxU RUAAAADgaDufBAAAAEAAAABAce1tepC+AUAAAADAQ2Ff2L3BAUAAAAAwzIKCEsTBAQMAAAAPAAAA AwAAANEAAABHAAAANCAAAP////8DAAAACAA7DS4JAAABAAkAAAMSEAAABgDMAAAAAAARAAAAJgYP ABgA/////wAAEAAAAAAAAAAAAAADAAAVAgAACQAAACYGDwAIAP////8CAAAAFwAAACYGDwAjAP// //8EABsAVE5QUBQAFAH/ADIAAAD//08AFAAAAE0AaQAAAAoAAAAmBg8ACgBUTlBQAAACAPQDCQAA ACYGDwAIAP////8DAAAADwAAACYGDwAUAFROUFAEAAwAAQAAAAEAAAAAAAAABQAAAAsCAAAAAAUA AAAMAhUCAAMFAAAABAENAAAABwAAAPwCAAD///8AAAAEAAAALQEAAAgAAAD6AgUAAQAAAAAAAAAE AAAALQEBAAQAAAAtAQAACQAAAB0GIQDwABUCAAMAAAAABAAAAC0BAAAHAAAA/AIAAP///wAAAAQA AAAtAQIABAAAAPABAAAIAAAA+gIAAAAAAAAAAAAABAAAAC0BAAAHAAAA/AIBAAAAAAAAAAQAAAAt AQMABAAAAC0BAQAHAAAAGwQCAuEC3AFbAgQAAAAtAQIABAAAAC0BAAAEAAAALQEDAAQAAAAtAQEA BwAAABsEEQKTAQACEgAEAAAALQECAAQAAAAtAQAAHAAAAPsCAAAAAAAAAAAAAAAAAAAAAAAAAMkS AC9n9XdAAAAADgQKWY9J9XeYSfV3AQAAAAAAMAAEAAAALQEEAAUAAAAJAgAAAAIFAAAAFAIAAAAA HAAAAPsC9/8AAAAAAACQAQAAAAAAQAAiUm90aXMgU2FucyBTZXJpZiBmb3IgTm9raWEAAAAAMAAE AAAALQEFAAQAAADwAQQABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkA AAAyCgsCGAABAAAAMQAFAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCgsCLAABAAAAqQAFAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABYAAAAyCgsCMwAKAAAATk9L SUEgMjAwMgYABQAFAAIABQACAAUABAAFAAUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAA EAAAACYGDwAWAP////8AAIkCAAD5AQAA6QIAAAoCAAAQAAAAJgYPABYA/////wAAiQIAAPkBAACf AgAACgIAAAQAAAAtAQEABwAAAPwCAAAAUroAAAAEAAAALQEEAB4AAAAkAw0AjQIJAokCCQKJAvkB kAL5AZoCBQKaAgUCmgL5AZ4C+QGeAgkClwIJAo0C/QGNAv0BjQIJAgQAAAAtAQAABAAAAC0BAgAE AAAA8AEEAAgAAAAmBg8ABgD/////AQAHAAAA/AIAAABSugAAAAQAAAAtAQQABAAAAC0BAQAEAAAA LQEEAAkAAAAdBiEA8AAQAAUA+QG2AgQAAAAtAQQABAAAAC0BAgAEAAAA8AEEAAQAAAAtAQAAEAAA ACYGDwAWAP////8AALsCAAD5AQAAzAIAAAoCAAAEAAAALQEBAAcAAAD8AgAAAFK6AAAABAAAAC0B BAASAAAAJAMHAMMC+QHKAvkBwQIBAssCCQLEAgkCuwIBAsMC+QEEAAAALQEAAAQAAAAtAQIABAAA APABBAAIAAAAJgYPAAYA/////wEABwAAAPwCAAAAUroAAAAEAAAALQEEAAQAAAAtAQEABAAAAC0B BAAJAAAAHQYhAPAAEAAEAPkBzAIEAAAALQEEAAQAAAAtAQIABAAAAPABBAAEAAAALQEAABAAAAAm Bg8AFgD/////AADRAgAA+QEAAOkCAAAKAgAABAAAAC0BAQAHAAAA/AIAAABSugAAAAQAAAAtAQQA JAAAADgFAgAKAAUA2AIGAtcCCQLRAgkC2gL5AeAC+QHoAgkC4wIJAuICBgLYAgYC2AIGAtoCAwLg AgMC3QL9AdoCAwLaAgMCBAAAAC0BAAAEAAAALQECAAQAAADwAQQACAAAACYGDwAGAP////8BABAA AAAmBg8AFgD/////AACgAgAA+QEAALUCAAAKAgAABAAAAC0BAQAHAAAA/AIAAABSugAAAAQAAAAt AQQAzAAAADgFAgA+ACUAoAL9AaAC/QGgAvwBoAL8AaEC/AGhAvsBoQL7AaEC+wGiAvoBogL6AaIC +gGjAvoBpAL6AaUC+QGnAvkBqgL5Aa4C+QGwAvkBsQL6AbIC+gGyAvoBswL6AbMC+wG0AvsBtAL7 AbQC/AG0AvwBtAL8AbQC/QG0Av0BtAIAArQCBQK0AgYCtAIGArQCBgK0AgcCtAIHArQCBwKzAggC swIIArICCAKxAgkCsQIJArACCQKuAgkCqgIJAqYCCQKlAgkCpAIJAqMCCQKiAggCogIIAqECCAKh AgcCoQIHAqECBwKgAgYCoAIGAqACBgKgAgUCoAL9AaAC/QGlAgQCpQIFAqUCBQKlAgUCpQIFAqUC BQKlAgUCpgIFAq8CBQKvAgUCrwIFArACBQKwAgUCsAIFArACBQKwAgUCsAIEArACAwKwAv4BsAL+ AbAC/gGwAv0BsAL9AbAC/QGvAv0BrwL9AaYC/QGmAv0BpQL9AaUC/QGlAv0BpQL+AaUC/gGlAv4B pQL+AaUCBAKlAgQCBAAAAC0BAAAEAAAALQECAAQAAADwAQQACAAAACYGDwAGAP////8BAAgAAAAm Bg8ABgD/////AQAEAAAALQEDAAQAAAAtAQEABwAAABsESADbAhIAIwAEAAAALQECAAQAAAAtAQAA BQAAAAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLd/wAAAAAAALwCAAAAAABAACJSb3RpcyBTYW5zIFNl cmlmIGZvciBOb2tpYQAAAAAwAAQAAAAtAQQABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAAJAAAADIKOACZABMAAABOYW1lIG9mIHRoZSBtZXRob2Q6AhcAEQAb ABEACgASAA0ACgAOABIAEQAKABsAEAANABIAEgASAAsABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEgAAADIKOADeAQcAAABFQVAvQUtB ARMAFQASAAwAFQAVABUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAwAEAAAA LQEBAAcAAAAbBO0B3gJZACMABAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAA APsC7P8AAAAAAACQAQAAAAAAQAAiUm90aXMgU2FucyBTZXJpZiBmb3IgTm9raWEAAAAAMAAEAAAA LQEFAAQAAADwAQQABQAAAAkCYY/9AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAy Cm4AKQABAAAAlQAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA LgEYAAAABQAAAAIBAQAAAB4AAAAyCm4APwAPAAAARmlsZW5hbWU6IGRyYWZ0AgkABQAFAAkACgAI AA8ACQAFAAUACgAGAAkABgAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCm4AtQABAAAALQAIAAUAAAAuAQEAAAAFAAAAAgEC AAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAyCm4AvQAFAAAA YXJra28ACQAFAAkACAAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCm4A5gABAAAALQAIAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABAAAAAyCm4A7gAGAAAAcHBw ZXh0CQAKAAoACAAJAAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAACQAAADIKbgAjAQEAAAAtAAgABQAAAC4BAQAAAAUAAAACAQIAAAAF AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADAAAADIKbgArAQMAAABlYXBr CQAIAAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAF AAAAAgEBAAAACQAAADIKbgBGAQEAAAAtAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADAAAADIKbgBOAQMAAABha2FrCQAJAAkABQAA AC4BAQAAAAUAAAACAQIAAAAFAAAACQJhj/0CBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA CQAAADIKiwApAAEAAACVAAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAA AAUAAAAuARgAAAAFAAAAAgEBAAAAHgAAADIKiwA/AA8AAABKdXN0aWZpY2F0aW9uOiACBwAKAAcA BwAFAAYABQAJAAgABwAFAAoACgAFAAUABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLs/wAAAAAA ALwCAAAAAABAACJSb3RpcyBTYW5zIFNlcmlmIGZvciBOb2tpYQAAAAAwAAQAAAAtAQQABAAAAPAB BQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAASwAAADIKiwCpAC0AAABV TVRTIGFuZCBHU00gQXV0aGVudGljYXRpb24gYW5kIEtleSBBZ3JlZW1lbnRlCwARAAkACgAGAAoA CgAKAAYADAAKABEABgAMAAoABwAKAAkACgAHAAUACQAKAAcABQAKAAoABgAKAAoACgAGAAsACQAJ AAYADAAKAAcACQAJAA8ACQAKAAcABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLs/wAAAAAAAJAB AAAAAABAACJSb3RpcyBTYW5zIFNlcmlmIGZvciBOb2tpYQAAAAAwAAQAAAAtAQUABAAAAPABBAAF AAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAIQAAADIKiwBNAhEAAAAuIFBv c3NpYmlsaXR5IHRvIAAEAAUACgAKAAcABwAFAAoABAAFAAUABgAJAAUABgAKAAQABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAARQAAADIK ogA/ACkAAAB1c2UgVU1UUy9HU00gcm9hbWluZyBhbmQgVVNJTS9TSU0gY2FyZHMuIAAKAAcACQAF AAwAEAAIAAoABQAMAAkAEAAFAAYACgAJAA8ABQAJAAoABQAJAAoACgAEAAwACgAFAA8ABgAKAAUA EAAEAAkACQAGAAoABwAEAAUABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJhj/0CBQAAABQCAAAA AAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKwQApAAEAAACVAAoABQAAAC4BAQAAAAUAAAACAQIA AAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAZwAAADIKwQA/AEAAAABV c2FnZSBzY2VuYXJpbzogV0xBTiBhY2Nlc3MgYXV0aGVudGljYXRpb24uIEFueSB0eXBlIG9mIGRl dmljZXMgDAAHAAkACgAJAAUABwAJAAkACgAJAAYABAAKAAUABQARAAgACgANAAUACQAIAAkACQAH AAcABQAJAAoABwAKAAgACgAHAAQACQAJAAcABAAKAAoABAAFAAsACQAJAAUABgAJAAoACQAEAAoA BgAFAAoACAAJAAQACQAJAAcABQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAAAeAAAAMgrBAD0CDwAAAChtb2JpbGUgcGhvbmUsIAIFAA8A CQAKAAUABQAJAAQACgAKAAkACgAJAAQABAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgrWAD8ADgAAAFBEQSwgUEMgY2FyZCkg CgALAAsABAAFAAoACwAEAAkACQAGAAoABgAFAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCYY/9 AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCvUAKQABAAAAlQAKAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACoAAAAy CvUAPwAXAAAARUFQIFR5cGUgIyBhc3NpZ25lZDogMjM4CQALAAoABQAIAAkACQAJAAUACwAFAAkA BwAHAAUACgAKAAkACgAFAAUACgAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCYY/9AgUAAAAU AgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyChQBKQABAAAAlQAKAAUAAAAuAQEAAAAFAAAA AgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAEIAAAAyChQBPwAn AAAATXV0dWFsIGF1dGhlbnRpY2F0aW9uIGluIFVNVFMgbW9kZSwgb25lABAACgAHAAoACQAFAAUA CQAJAAcACgAJAAkABwAFAAkACAAHAAUACQAKAAUABQAKAAUADAAQAAcACgAFAA4ACgAKAAkABAAE AAoACgAJAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAA BQAAAAIBAQAAAAkAAAAyChQBiQEBAAAALQAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAA AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADQAAAAyChQBkAEeAAAAd2F5IGF1dGhlbnRp Y2F0aW9uIGluIEdTTSBtb2RlDgAJAAkABQAJAAkABwAKAAkACQAHAAUACQAIAAcABQAJAAoABQAF AAoABQALAAoAEAAFAA4ACgAJAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJhj/0CBQAAABQC AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKMwEpAAEAAACVAAoABQAAAC4BAQAAAAUAAAAC AQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAZAAAADIKMwE/AD4A AABTdXBwb3J0IGZvciAiZmFzdCByZWNvbm5lY3STOiBub3QgaW4gdGhlIGN1cnJlbnQgZHJhZnQg dmVyc2lvbgoACgAJAAoACgAGAAcABQAFAAoABgAFAAcABgAJAAcABwAFAAYACQAIAAoACgAKAAgA CQAHAAcABQAFAAkACgAHAAQABQAKAAUABwAJAAkABQAJAAoABgAGAAkACQAHAAUACgAGAAkABgAH AAQACQAJAAYABwAFAAoACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAmGP/QIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpRASkAAQAAAJUACgAFAAAALgEBAAAABQAAAAIBAgAA AAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAA8AAAAMgpRAT8AIwAAAERp Y3Rpb25hcnkgYXR0YWNrIHZ1bG5lcmFiaWxpdHk6IG5vAAsABQAJAAcABAAKAAoACQAGAAkABQAJ AAYABwAJAAgACQAEAAkACgAFAAoACQAGAAkACQAFAAUABAAHAAkABQAFAAkACgAFAAAALgEBAAAA BQAAAAIBAgAAAAUAAAAJAmGP/QIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpw ASkAAQAAAJUACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAnAAAAMgpwAT8AFQAAAEtleSBkZXJpdmF0aW9uOiBhIDEyOAAKAAkACQAF AAoACQAGAAQACQAJAAYABQAKAAoABQAFAAkABQAKAAoACgAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgpwAeQAAQAAAC0ABwAF AAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAArAAAAMgpwAesAGAAAAGJpdCBjaXBoZXIga2V5IGFuZCBhIDEyOAoABQAHAAQACQAEAAoACgAJ AAYABAAJAAkACQAFAAkACQAKAAUACQAFAAoACgAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCnABpgEBAAAALQAHAAUAAAAu AQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAD0A AAAyCnABrQEkAAAAYml0IGludGVncml0eSBrZXkgaW4gVU1UUyBtb2RlLiBBIDU2CgAFAAcABQAF AAkABwAIAAoABgAFAAYACQAFAAgACQAJAAUABAAKAAUADAAQAAcACgAFAA8ACQAKAAkABAAFAAsA BQAKAAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAF AAAAAgEBAAAACQAAADIKcAHKAgEAAAAtAAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAANgAAADIKhgE/AB8AAABiaXQgZW5jcnlwdGlv biBrZXkgaW4gR1NNIG1vZGUuAAoABQAHAAUACAAKAAkABQAJAAkABwAFAAoACgAEAAkACAAJAAUA BQAKAAUACwAKABAABQAOAAoACQAJAAQABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQJhj/0CBQAA ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKpAEpAAEAAACVAAoABQAAAC4BAQAAAAUA AAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAZwAAADIKpAE/ AEAAAABBbGdvcml0aG1zOiBVTVRTIGFsZ29yaXRobXMsIEdTTSBhbGdvcml0aG1zLiBJZGVudGl0 eSBwcml2YWN5IHdpCwAFAAoACgAGAAQABwAKAA8ABwAFAAUADAAQAAcACgAFAAkABQAJAAoABgAF AAYACgAPAAcABAAFAAwACQAQAAUACQAFAAkACgAGAAUABwAJAA8ABwAEAAUABQAKAAkACQAHAAUA BgAJAAUACgAGAAQACQAIAAkACQAEAA4ABQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgqkAT8CDgAAAHRoIHBzZXVkb255bXMu BwAKAAQACgAHAAkACgAJAAoACQAJAA8ABwAEAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCYY/9 AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCsMBKQABAAAAlQAKAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAGcAAAAy CsMBPwBAAAAAU3RhbmRhcmRzIGdyb3VwIGRlcGVuZGVuY2llczogIHBvdGVudGlhbCAzR1BQLCBJ RUVFIDgwMi4xMWkgdXNhZwoABwAJAAkACgAJAAYACgAHAAUACgAGAAoACQAKAAUACQAJAAoACAAK AAoACQAJAAkABQAJAAcABQAFAAQACgAJAAcACQAKAAYABQAJAAUABQAKAAsACgAKAAQABQAFAAkA CQAJAAUACgAKAAoABAAKAAoABQAFAAoABwAJAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKwwE+AgEAAABlAAkABQAAAC4B AQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEDABwAAAD7AhQACQAAAAAAvAIA AAAAAQICIlN5c3RlbQAAAAAKAAAABAAAAAAABAAAAAEAAAAAADAABAAAAC0BBAAEAAAA8AEFAA8A AAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAAAAgA//// /wEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAkAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQACAAAAAAEPAPIDHgIAAC8AyA/qAAAAMADSDwQAAAACAAAAAAC6DygAAAAYIBwgCP8U MDv/W/8IMAowDDAOMBAw5f8E/yQAKABbAFwAewBi/+H/EAC6D6YAAAABMAIwDP8O//swGv8b/x// Af+bMJww/TD+MJ0wnjAFMPwwGSAdIAn/FTA9/13/CTALMA0wDzARMLAAMCAyIDMgAyHg/wX/QTBD MEUwRzBJMGMwgzCFMIcwjjChMKMwpTCnMKkwwzDjMOUw5zDuMPUw9jAhACUAKQAsAC4AOgA7AD8A XQB9AGH/Y/9k/2X/Z/9o/2n/av9r/2z/bf9u/2//cP+e/5//DwDVB0wAAAAAALcPRAAAAFIAbwB0 AGkAcwAgAFMAYQBuAHMAIABTAGUAcgBpAGYAIABmAG8AcgAgAE4AbwBrAGkAYQAAAAAAYNYSACAm DDAAAAYiAACkDwwAAACAAGIAAAD/////FAAAAKUPDgAAAAAAABguAAAAWgACAAAAAACrDx4AAAD/ HwAABQDgAQAAAAAAAGgBaAHQAtACOAQ4BKAFoAUAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA //0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgAAAAA AQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBFgC AAAPAADwUAIAAAAABvCgAQAAAswAADMAAAAWAAAABQAAAAEAAABSAAAABAAAAAQAAAADAAAAAgAA AAAAAAAEAAAAAAAAAAcAAAAAAAAACQAAAAAAAAAIAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAhAAAA AAAAABsAAAAAAAAABwAAAAAAAAAMAAAAAAAAABIAAAAAAAAACAAAAAAAAAAlAAAAAAAAABgAAAAA AAAAdwAAAAAAAAAEAAAABQAAAD4AAAAAAAAABgAAAAAAAAALAAAAAAAAAAsAAAAAAAAACQAAAAAA AAAJAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAA AAIAAAAAAAAAAgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAgAAAAAAAAA BgAAAAAAAAAIAAAAAAAAAAQAAAAAAAAAAgAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAM AAAAAAAAAAYAAAAAAAAABgAAAAAAAAAEAAAAAgAAAAQAAAADAQvwYAAAAIABAAAAAIEBAAAACIMB AAAACL8BEAAQAMABAQAACMEBAAABAMQBAAAAAMsBnDEAAM0BAAAAAM4BAAAAANABAAAAANEBAAAA ANcBAgAAAP8BCAAIAAECAgAACD8CAAACAIAAGvEgAAAAzOz/AGdnZwCpqakA/P65AAY96ACiwf4A +v0AAMD++QBAAB7xEAAAAKLB/gD/////AgAACPcAABAfAPAPHAAAAAAA8wMUAAAABAAAAAQAAAAA AAAAAAAAgAAAAAAPANAHvQEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABQEHAAAAAAA FQQUAAAAuh117ADKmjsyTs3JAMqaOwACAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABZAAAA ZAAAAFkAAABkAAAAZKcMMAgAAAAAAAAAVNYSAAAAAAAAAAAAfvz//7j///8BAAAAcAD7AwgAAAAA AAAAcAgAAHAA+wMIAAAAAQAAADAMAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGc/ DDAQ2hIAAAAAANBCHwQAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAA AGQAAABkAAAAZz8MMBDaEgAAAAAA0EIfBAAAAAAAAAAAAAAAAAAAAAAAARIAHwAIBDwAAAAAAP0D NAAAAEIAAABkAAAAQgAAAGQAAABnPwwwENoSAAAAAADQQh8EAAAAAAAAAAAAAAAAAAAAAAAAEgAP AIgTOgAAAA8AihMyAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMUAAAALwDIDwwAAAAwANIP BAAAAIAAAAA/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A8+DAAAAADzAxQAAAAWAAAAAAAAAAIAAAAB AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8bAAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvQUtBAACq DxwAAAATAAAAAAAAAAgAAAAGAAAACwQAAAEAAAAAAAAAEACfDwQAAAABAAAAAACgD4AFAABGAGkA bABlAG4AYQBtAGUAOgAgAGQAcgBhAGYAdAAtAGEAcgBrAGsAbwAtAHAAcABwAGUAeAB0AC0AZQBh AHAALQBhAGsAYQANAEoAdQBzAHQAaQBmAGkAYwBhAHQAaQBvAG4AOgAgAFUATQBUAFMAIABhAG4A ZAAgAEcAUwBNACAAQQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAYQBuAGQAIABLAGUAeQAg AEEAZwByAGUAZQBtAGUAbgB0AC4AIABQAG8AcwBzAGkAYgBpAGwAaQB0AHkAIAB0AG8AIAB1AHMA ZQAgAFUATQBUAFMALwBHAFMATQAgAHIAbwBhAG0AaQBuAGcAIABhAG4AZAAgAFUAUwBJAE0ALwBT AEkATQAgAGMAYQByAGQAcwAuACAADQBVAHMAYQBnAGUAIABzAGMAZQBuAGEAcgBpAG8AOgAgAFcA TABBAE4AIABhAGMAYwBlAHMAcwAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAuACAAQQBu AHkAIAB0AHkAcABlACAAbwBmACAAZABlAHYAaQBjAGUAcwAgACgAbQBvAGIAaQBsAGUAIABwAGgA bwBuAGUALAAgAFAARABBACwAIABQAEMAIABjAGEAcgBkACkAIAANAEUAQQBQACAAVAB5AHAAZQAg ACMAIABhAHMAcwBpAGcAbgBlAGQAOgAgADIAMwANAE0AdQB0AHUAYQBsACAAYQB1AHQAaABlAG4A dABpAGMAYQB0AGkAbwBuACAAaQBuACAAVQBNAFQAUwAgAG0AbwBkAGUALAAgAG8AbgBlAC0AdwBh AHkAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABpAG4AIABHAFMATQAgAG0AbwBkAGUA DQBTAHUAcABwAG8AcgB0ACAAZgBvAHIAIAAiAGYAYQBzAHQAIAByAGUAYwBvAG4AbgBlAGMAdAAc IDoAIABuAG8AdAAgAGkAbgAgAHQAaABlACAAYwB1AHIAcgBlAG4AdAAgAGQAcgBhAGYAdAAgAHYA ZQByAHMAaQBvAG4ADQBEAGkAYwB0AGkAbwBuAGEAcgB5ACAAYQB0AHQAYQBjAGsAIAB2AHUAbABu AGUAcgBhAGIAaQBsAGkAdAB5ADoAIABuAG8ADQBLAGUAeQAgAGQAZQByAGkAdgBhAHQAaQBvAG4A OgAgAGEAIAAxADIAOAAtAGIAaQB0ACAAYwBpAHAAaABlAHIAIABrAGUAeQAgAGEAbgBkACAAYQAg ADEAMgA4AC0AYgBpAHQAIABpAG4AdABlAGcAcgBpAHQAeQAgAGsAZQB5ACAAaQBuACAAVQBNAFQA UwAgAG0AbwBkAGUALgAgAEEAIAA1ADYALQBiAGkAdAAgAGUAbgBjAHIAeQBwAHQAaQBvAG4AIABr AGUAeQAgAGkAbgAgAEcAUwBNACAAbQBvAGQAZQAuAA0AQQBsAGcAbwByAGkAdABoAG0AcwA6ACAA VQBNAFQAUwAgAGEAbABnAG8AcgBpAHQAaABtAHMALAAgAEcAUwBNACAAYQBsAGcAbwByAGkAdABo AG0AcwAuACAASQBkAGUAbgB0AGkAdAB5ACAAcAByAGkAdgBhAGMAeQAgAHcAaQB0AGgAIABwAHMA ZQB1AGQAbwBuAHkAbQBzAC4ADQBTAHQAYQBuAGQAYQByAGQAcwAgAGcAcgBvAHUAcAAgAGQAZQBw AGUAbgBkAGUAbgBjAGkAZQBzADoAIAAgAHAAbwB0AGUAbgB0AGkAYQBsACAAMwBHAFAAUAAsACAA SQBFAEUARQAgADgAMAAyAC4AMQAxAGkAIAB1AHMAYQBnAGUAAAChDyoAAADBAgAAAAAAAAAANAAA AAAAAgAUAC0AAAABAAIAAQAUAGACAAAAAAIAFAAAAKoPLAAAABAAAAAAAAAABQAAAAEAAAADAAEA AAAAAAAABgAAAAEAAAADAKUCAAAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAAAAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8bAAAATmFtZSBvZiB0aGUgbWV0aG9kOiBFQVAvU0lNEACfDwQAAAABAAAAAACg D/4EAABGAGkAbABlAG4AYQBtAGUAOgAgAGQAcgBhAGYAdAAtAGgAYQB2AGUAcgBpAG4AZQBuAC0A cABwAHAAZQB4AHQALQBlAGEAcAAtAHMAaQBtAA0ASgB1AHMAdABpAGYAaQBjAGEAdABpAG8AbgA6 ACAARQBuAGgAYQBuAGMAZQBkACAARwBTAE0AIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4A LgAgAFAAbwBzAHMAaQBiAGkAbABpAHQAeQAgAHQAbwAgAHUAcwBlACAAZQB4AGkAcwB0AGkAbgBn ACAARwBTAE0AIABTAEkATQAgAGMAYQByAGQAcwAgAGEAbgBkACAARwBTAE0AIAByAG8AYQBtAGkA bgBnACAAaQBuAGYAcgBhAHMAdAByAHUAYwB0AHUAcgBlAC4AIAANAFUAcwBhAGcAZQAgAHMAYwBl AG4AYQByAGkAbwA6ACAAVwBMAEEATgAgAGEAYwBjAGUAcwBzACAAYQB1AHQAaABlAG4AdABpAGMA YQB0AGkAbwBuAC4AIABBAG4AeQAgAHQAeQBwAGUAIABvAGYAIABkAGUAdgBpAGMAZQBzACAAKABt AG8AYgBpAGwAZQAgAHAAaABvAG4AZQAsACAAUABEAEEALAAgAFAAQwAgAGMAYQByAGQAKQANAEUA QQBQACAAVAB5AHAAZQAgACMAIABhAHMAcwBpAGcAbgBlAGQAOgAgADEAOAANAE0AdQB0AHUAYQBs ACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuAA0AUwB1AHAAcABvAHIAdAAgAGYAbwByACAA IgBmAGEAcwB0ACAAcgBlAGMAbwBuAG4AZQBjAHQAHCA6ACAAbgBvAHQAIABpAG4AIAB0AGgAZQAg AGMAdQByAHIAZQBuAHQAIABkAHIAYQBmAHQAIAB2AGUAcgBzAGkAbwBuAA0ARABpAGMAdABpAG8A bgBhAHIAeQAgAGEAdAB0AGEAYwBrACAAdgB1AGwAbgBlAHIAYQBiAGkAbABpAHQAeQA6ACAAbgBv AA0ASwBlAHkAIABkAGUAcgBpAHYAYQB0AGkAbwBuADoAIAB5AGUAcwAsACAAYQBuAHkAIABrAGkA bgBkACAAbwBmACAAawBlAHkAcwANAEEAbABnAG8AcgBpAHQAaABtAHMAOgAgAEcAUwBNACAAYQBs AGcAbwByAGkAdABoAG0AcwAgAHcAaQB0AGgAIABuAGUAdwAgAGUAbgBoAGEAbgBjAGUAbQBlAG4A dABzACAAZgBvAHIAIABtAHUAdAB1AGEAbAAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAg AGEAbgBkACAAcwB0AHIAbwBuAGcAZQByACAAawBlAHkAIABkAGUAcgBpAHYAYQB0AGkAbwBuAC4A IABJAGQAZQBuAHQAaQB0AHkAIABwAHIAaQB2AGEAYwB5ACAAdwBpAHQAaAAgAHAAcwBlAHUAZABv AG4AeQBtAHMALgANAFMAdABhAG4AZABhAHIAZABzACAAZwByAG8AdQBwACAAZABlAHAAZQBuAGQA ZQBuAGMAaQBlAHMAOgAgAFAAbwB0AGUAbgB0AGkAYQBsACAAMwBHAFAAUAAsACAASQBFAEUARQAg ADgAMAAyAC4AMQAxAGkAIAB1AHMAYQBnAGUADQAAAKEPKgAAAIACAAAAAAAAAAA4AAAAAAACABQA GwAAAAEAAgABABQALQIAAAAAAgAUAAAAqg8+AAAAEAAAAAAAAAAJAAAAAQAAAAMAAQAAAAAAAAAG AAAAAQAAAAMABQAAAAAAAAADAAAAAQAAAAMAWAIAAAAAAAABAAEEUAAAAAAAAAH///9/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABIAAADqAwAAAAAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAA DwAMBJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAPIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAyAAABQAAAA8ABPByAAAAEgAK8AgAAAACyAAAIAIAAFMA C/AeAAAAfwAAAAQAgAB4JB8EvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACQACABLBdAAg8AEfAQ AAAAAADDCwgAAAAAAAAADQAfBA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAPI AAAgAgAAUwAL8B4AAAB/AAAABACAAMgkHwS/AQAAAQD/AQAAAQABAyEEAAAAABDwCAAAANACIAFA F5APDwAR8BAAAAAAAMMLCAAAAAEAAAAOAB8EDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIA CvAIAAAAAcgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBHkCXAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACRkZEAAAAAAGGP/QAArgAA/AEoAM7OzgAAAHIX EAAAAAEAEADSNwAAFgAQADNLAAAAAPUPHAAAAAABAACvEQADrjcAAB9NAAABAAAAFgAAAAEAAAAP AOgDWRMAAAEA6QMoAAAAYBgAAOAQAACPEAAA6BcAAAUAAAAKAAAAAgAAAAMAAAABAAIAAAAAAQ8A 8gMeAgAALwDID+oAAAAwANIPBAAAAAIAAAAAALoPKAAAABggHCAI/xQwO/9b/wgwCjAMMA4wEDDl /wT/JAAoAFsAXAB7AGL/4f8QALoPpgAAAAEwAjAM/w7/+zAa/xv/H/8B/5swnDD9MP4wnTCeMAUw /DAZIB0gCf8VMD3/Xf8JMAswDTAPMBEwsAAwIDIgMyADIeD/Bf9BMEMwRTBHMEkwYzCDMIUwhzCO MKEwozClMKcwqTDDMOMw5TDnMO4w9TD2MCEAJQApACwALgA6ADsAPwBdAH0AYf9j/2T/Zf9n/2j/ af9q/2v/bP9t/27/b/9w/57/n/8PANUHTAAAAAAAtw9EAAAAUgBvAHQAaQBzACAAUwBhAG4AcwAg AFMAZQByAGkAZgAgAGYAbwByACAATgBvAGsAaQBhAAAAAABg1hIAICYMMAAABiIAAKQPDAAAAIAA YgAAAP////8UAAAApQ8OAAAAAAAAGC4AAABaAAIAAAAAAKsPHgAAAP8fAAAFAOABAAAAAAAAaAFo AdAC0AI4BDgEoAWgBQAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEWAIAAA8AAPBQAgAAAAAG8KAB AAACzAAAMwAAABYAAAAFAAAAAQAAAFIAAAAEAAAABAAAAAMAAAACAAAAAAAAAAQAAAAAAAAABwAA AAAAAAAJAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAEAAAAAAAAACEAAAAAAAAAGwAAAAAAAAAHAAAA AAAAAAwAAAAAAAAAEgAAAAAAAAAIAAAAAAAAACUAAAAAAAAAGAAAAAAAAAB3AAAAAAAAAAQAAAAF AAAAPgAAAAAAAAAGAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAJAAAAAAAAAAkAAAAAAAAACQAAAAAA AAAJAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAAAgAAAAAAAAACAAAAAAAA AAYAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAYAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAgAAAAAAAAA BAAAAAAAAAACAAAAAAAAAAQAAAAAAAAACAAAAAAAAAAGAAAAAAAAAAwAAAAAAAAABgAAAAAAAAAG AAAAAAAAAAQAAAACAAAABAAAAAMBC/BgAAAAgAEAAAAAgQEAAAAIgwEAAAAIvwEQABAAwAEBAAAI wQEAAAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA0AEAAAAA0QEAAAAA1wECAAAA/wEIAAgAAQIC AAAIPwIAAAIAgAAa8SAAAADM7P8AZ2dnAKmpqQD8/rkABj3oAKLB/gD6/QAAwP75AEAAHvEQAAAA osH+AP////8CAAAI9wAAEB8A8A8cAAAAAADzAxQAAAAEAAAABAAAAAAAAAAAAACAAAAAAA8A0Ae9 AQAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJO zckAypo7AAIAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAFkAAABkAAAAWQAAAGQAAABkpwww CAAAAAAAAABU1hIAAAAAAAAAAAB+/P//uP///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAAB AAAAMAwAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAZz8MMBDaEgAAAAAA0EIfBAAA AAAAAAAAAAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABnPwwwENoS AAAAAADQQh8EAAAAAAAAAAAAAAAAAAAAAAABEgAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAA ZAAAAGc/DDAQ2hIAAAAAANBCHwQAAAAAAAAAAAAAAAAAAAAAAAASAA8AiBM6AAAADwCKEzIAAAAA ALoPDgAAAF8AXwBfAFAAUABUADkAAACLExQAAAAvAMgPDAAAADAA0g8EAAAAgAAAAD8A2Q8MAAAA AADaDwQAAAAAACUADwDwDz4MAAAAAPMDFAAAABYAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAA AAAAAACoDxsAAABOYW1lIG9mIHRoZSBtZXRob2Q6IEVBUC9BS0EAAKoPHAAAABMAAAAAAAAACAAA AAYAAAALBAAAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKAPgAUAAEYAaQBsAGUAbgBhAG0AZQA6ACAA ZAByAGEAZgB0AC0AYQByAGsAawBvAC0AcABwAHAAZQB4AHQALQBlAGEAcAAtAGEAawBhAA0ASgB1 AHMAdABpAGYAaQBjAGEAdABpAG8AbgA6ACAAVQBNAFQAUwAgAGEAbgBkACAARwBTAE0AIABBAHUA dABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABhAG4AZAAgAEsAZQB5ACAAQQBnAHIAZQBlAG0AZQBu AHQALgAgAFAAbwBzAHMAaQBiAGkAbABpAHQAeQAgAHQAbwAgAHUAcwBlACAAVQBNAFQAUwAvAEcA UwBNACAAcgBvAGEAbQBpAG4AZwAgAGEAbgBkACAAVQBTAEkATQAvAFMASQBNACAAYwBhAHIAZABz AC4AIAANAFUAcwBhAGcAZQAgAHMAYwBlAG4AYQByAGkAbwA6ACAAVwBMAEEATgAgAGEAYwBjAGUA cwBzACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuAC4AIABBAG4AeQAgAHQAeQBwAGUAIABv AGYAIABkAGUAdgBpAGMAZQBzACAAKABtAG8AYgBpAGwAZQAgAHAAaABvAG4AZQAsACAAUABEAEEA LAAgAFAAQwAgAGMAYQByAGQAKQAgAA0ARQBBAFAAIABUAHkAcABlACAAIwAgAGEAcwBzAGkAZwBu AGUAZAA6ACAAMgAzAA0ATQB1AHQAdQBhAGwAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4A IABpAG4AIABVAE0AVABTACAAbQBvAGQAZQAsACAAbwBuAGUALQB3AGEAeQAgAGEAdQB0AGgAZQBu AHQAaQBjAGEAdABpAG8AbgAgAGkAbgAgAEcAUwBNACAAbQBvAGQAZQANAFMAdQBwAHAAbwByAHQA IABmAG8AcgAgACIAZgBhAHMAdAAgAHIAZQBjAG8AbgBuAGUAYwB0ABwgOgAgAG4AbwB0ACAAaQBu ACAAdABoAGUAIABjAHUAcgByAGUAbgB0ACAAZAByAGEAZgB0ACAAdgBlAHIAcwBpAG8AbgANAEQA aQBjAHQAaQBvAG4AYQByAHkAIABhAHQAdABhAGMAawAgAHYAdQBsAG4AZQByAGEAYgBpAGwAaQB0 AHkAOgAgAG4AbwANAEsAZQB5ACAAZABlAHIAaQB2AGEAdABpAG8AbgA6ACAAYQAgADEAMgA4AC0A YgBpAHQAIABjAGkAcABoAGUAcgAgAGsAZQB5ACAAYQBuAGQAIABhACAAMQAyADgALQBiAGkAdAAg AGkAbgB0AGUAZwByAGkAdAB5ACAAawBlAHkAIABpAG4AIABVAE0AVABTACAAbQBvAGQAZQAuACAA QQAgADUANgAtAGIAaQB0ACAAZQBuAGMAcgB5AHAAdABpAG8AbgAgAGsAZQB5ACAAaQBuACAARwBT AE0AIABtAG8AZABlAC4ADQBBAGwAZwBvAHIAaQB0AGgAbQBzADoAIABVAE0AVABTACAAYQBsAGcA bwByAGkAdABoAG0AcwAsACAARwBTAE0AIABhAGwAZwBvAHIAaQB0AGgAbQBzAC4AIABJAGQAZQBu AHQAaQB0AHkAIABwAHIAaQB2AGEAYwB5ACAAdwBpAHQAaAAgAHAAcwBlAHUAZABvAG4AeQBtAHMA LgANAFMAdABhAG4AZABhAHIAZABzACAAZwByAG8AdQBwACAAZABlAHAAZQBuAGQAZQBuAGMAaQBl AHMAOgAgACAAcABvAHQAZQBuAHQAaQBhAGwAIAAzAEcAUABQACwAIABJAEUARQBFACAAOAAwADIA LgAxADEAaQAgAHUAcwBhAGcAZQAAAKEPKgAAAMECAAAAAAAAAAA0AAAAAAACABQALQAAAAEAAgAB ABQAYAIAAAAAAgAUAAAAqg8sAAAAEAAAAAAAAAAFAAAAAQAAAAMAAQAAAAAAAAAGAAAAAQAAAAMA pQIAAAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAAAAAAAACoDxsAAABO YW1lIG9mIHRoZSBtZXRob2Q6IEVBUC9TSU0QAJ8PBAAAAAEAAAAAAKAP/gQAAEYAaQBsAGUAbgBh AG0AZQA6ACAAZAByAGEAZgB0AC0AaABhAHYAZQByAGkAbgBlAG4ALQBwAHAAcABlAHgAdAAtAGUA YQBwAC0AcwBpAG0ADQBKAHUAcwB0AGkAZgBpAGMAYQB0AGkAbwBuADoAIABFAG4AaABhAG4AYwBl AGQAIABHAFMATQAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAuACAAUABvAHMAcwBpAGIA aQBsAGkAdAB5ACAAdABvACAAdQBzAGUAIABlAHgAaQBzAHQAaQBuAGcAIABHAFMATQAgAFMASQBN ACAAYwBhAHIAZABzACAAYQBuAGQAIABHAFMATQAgAHIAbwBhAG0AaQBuAGcAIABpAG4AZgByAGEA cwB0AHIAdQBjAHQAdQByAGUALgAgAA0AVQBzAGEAZwBlACAAcwBjAGUAbgBhAHIAaQBvADoAIABX AEwAQQBOACAAYQBjAGMAZQBzAHMAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4ALgAgAEEA bgB5ACAAdAB5AHAAZQAgAG8AZgAgAGQAZQB2AGkAYwBlAHMAIAAoAG0AbwBiAGkAbABlACAAcABo AG8AbgBlACwAIABQAEQAQQAsACAAUABDACAAYwBhAHIAZAApAA0ARQBBAFAAIABUAHkAcABlACAA IwAgAGEAcwBzAGkAZwBuAGUAZAA6ACAAMQA4AA0ATQB1AHQAdQBhAGwAIABhAHUAdABoAGUAbgB0 AGkAYwBhAHQAaQBvAG4ADQBTAHUAcABwAG8AcgB0ACAAZgBvAHIAIAAiAGYAYQBzAHQAIAByAGUA YwBvAG4AbgBlAGMAdAAcIDoAIABuAG8AdAAgAGkAbgAgAHQAaABlACAAYwB1AHIAcgBlAG4AdAAg AGQAcgBhAGYAdAAgAHYAZQByAHMAaQBvAG4ADQBEAGkAYwB0AGkAbwBuAGEAcgB5ACAAYQB0AHQA YQBjAGsAIAB2AHUAbABuAGUAcgBhAGIAaQBsAGkAdAB5ADoAIABuAG8ADQBLAGUAeQAgAGQAZQBy AGkAdgBhAHQAaQBvAG4AOgAgAHkAZQBzACwAIABhAG4AeQAgAGsAaQBuAGQAIABvAGYAIABrAGUA eQBzAA0AQQBsAGcAbwByAGkAdABoAG0AcwA6ACAARwBTAE0AIABhAGwAZwBvAHIAaQB0AGgAbQBz ACAAdwBpAHQAaAAgAG4AZQB3ACAAZQBuAGgAYQBuAGMAZQBtAGUAbgB0AHMAIABmAG8AcgAgAG0A dQB0AHUAYQBsACAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAYQBuAGQAIABzAHQAcgBv AG4AZwBlAHIAIABrAGUAeQAgAGQAZQByAGkAdgBhAHQAaQBvAG4ALgAgAEkAZABlAG4AdABpAHQA eQAgAHAAcgBpAHYAYQBjAHkAIAB3AGkAdABoACAAcABzAGUAdQBkAG8AbgB5AG0AcwAuAA0AUwB0 AGEAbgBkAGEAcgBkAHMAIABnAHIAbwB1AHAAIABkAGUAcABlAG4AZABlAG4AYwBpAGUAcwA6ACAA UABvAHQAZQBuAHQAaQBhAGwAIAAzAEcAUABQACwAIABJAEUARQBFACAAOAAwADIALgAxADEAaQAg AHUAcwBhAGcAZQANAAAAoQ8qAAAAgAIAAAAAAAAAADgAAAAAAAIAFAAbAAAAAQACAAEAFAAtAgAA AAACABQAAACqDz4AAAAQAAAAAAAAAAkAAAABAAAAAwABAAAAAAAAAAYAAAABAAAAAwAFAAAAAAAA AAMAAAABAAAAAwBYAgAAAAAAAAEAAQRQAAAAAAAAAf///38AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAAAOoDAAAA AAAAchcIAAAAAQAQAFtNAAAAAPUPHAAAAAEBAACvEQADN00AALxgAAABAAAAFgAAAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_001_01C1CF3E.104DB84C-- From owner-ietf-ppp@merit.edu Tue Mar 19 07:31:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20434 for ; Tue, 19 Mar 2002 07:31:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 920419124A; Tue, 19 Mar 2002 07:30:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FD299124B; Tue, 19 Mar 2002 07:30:56 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 332BF9124A for ; Tue, 19 Mar 2002 07:30:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 124D65DE82; Tue, 19 Mar 2002 07:30:55 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by segue.merit.edu (Postfix) with SMTP id 8BB0D5DD8C for ; Tue, 19 Mar 2002 07:30:54 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Mar 19 04:30:49 2002 To: ietf-ppp@merit.edu Date: Tue, 19 Mar 2002 04:30:49 -0800 From: "Affan Ahmed" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: affanahmed@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Echo reply X-Sender-Ip: 203.215.160.34 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit hello, I just want to ask a very basic question regarding the lcp echo req packet. If u recv it in LCP opened state while generating the echo reply do u copy the magic number in the req or pass on your own magic number. Similarly do we differentiate b/w discard req packets rcvd in states other than opened, or do we discard all packets no matter when they come? Hoping for a reply. --- Best Regards Affan Ahmed 2,000,000,000 Web Pages--you only need 1. Save time with My Lycos. http://my.lycos.com From owner-ietf-ppp@merit.edu Tue Mar 19 13:16:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29527 for ; Tue, 19 Mar 2002 13:16:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 548F291253; Tue, 19 Mar 2002 13:16:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03E1F91254; Tue, 19 Mar 2002 13:16:02 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C13A091253 for ; Tue, 19 Mar 2002 13:16:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94D2B5DD92; Tue, 19 Mar 2002 13:16:01 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by segue.merit.edu (Postfix) with ESMTP id 118655DDF9 for ; Tue, 19 Mar 2002 13:16:01 -0500 (EST) Received: from packetdesign.com (bubba.packetdesign.com [192.168.0.223]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id g2JIG0p95977; Tue, 19 Mar 2002 10:16:00 -0800 (PST) (envelope-from archie@packetdesign.com) Message-ID: <3C978060.C42AC9B4@packetdesign.com> Date: Tue, 19 Mar 2002 10:16:00 -0800 From: Archie Cobbs Organization: Packet Design X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: affanahmed@lycos.com Cc: ietf-ppp@merit.edu Subject: Re: Echo reply References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Affan Ahmed wrote: > I just want to ask a very basic question regarding the lcp echo req packet. If u recv it in LCP opened state while generating the echo reply do u copy the magic number in the req or pass on your own magic number. I believe the rules are: - Only send an echo reply when in the OPENED state - Always use your magic number when transmitting - Only verify magic numbers when in the OPENED state > Similarly do we differentiate b/w discard req packets rcvd in states other than opened, or do we discard all packets no matter when they come? Discard requests are always discarded. However, the magic number should still be checked (if in the OPENED state). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com From owner-ietf-ppp@merit.edu Tue Mar 19 13:28:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29761 for ; Tue, 19 Mar 2002 13:28:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A734D91254; Tue, 19 Mar 2002 13:28:30 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B12491255; Tue, 19 Mar 2002 13:28:30 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66CEE91254 for ; Tue, 19 Mar 2002 13:28:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4AF1F5DDF9; Tue, 19 Mar 2002 13:28:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id AA4555DD92 for ; Tue, 19 Mar 2002 13:28:28 -0500 (EST) Received: from tawei-u5.cisco.com (tawei-u5.cisco.com [171.69.58.65]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JISPd19258; Tue, 19 Mar 2002 10:28:26 -0800 (PST) Date: Tue, 19 Mar 2002 10:28:10 -0800 (PST) From: Tawei Liao To: Mitsuru Higashiyama Cc: Subject: Re: adding BPDU bit to RFC2878 frame format In-Reply-To: <003601c1cbf3$9c7884c0$69cb10ac@ibm0er> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu To give everybody an update on what's happening with this proposal... Mitsuru called me from the meeting in Minneapolis and we went over this. We're in agreement that this is a good idea, but we should make this change backward compatible with RFC2878. Meaning that the marking of BPDUs will be optional. It's just another option to be negotiated at init time. One person asked whether QoS is really necessary for L2. My answer is absolutely yes. STP is a control protocol just like BGP or OSPF. IP routing packets has an IP precendence of 6 or 7 and gets high priority queuing (as per RFC2474) based on those markings. BPDUs should get preferential treatment in the same manner in the L2 world. We will draft something up and send it out for review soon. thanks, -tawei -- Tawei Liao || || Cisco Systems || || (408) 853-8905 |||| |||| tawei@cisco.com ..:||||||:..:||||||:.. From owner-ietf-ppp@merit.edu Tue Mar 19 18:38:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07973 for ; Tue, 19 Mar 2002 18:38:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7472491203; Tue, 19 Mar 2002 18:38:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 467039121A; Tue, 19 Mar 2002 18:38:15 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60A8991203 for ; Tue, 19 Mar 2002 18:38:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42E885DDA3; Tue, 19 Mar 2002 18:38:14 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B43785DD96 for ; Tue, 19 Mar 2002 18:38:13 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2JMuNN16911 for ; Tue, 19 Mar 2002 14:56:23 -0800 Date: Tue, 19 Mar 2002 14:56:23 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Subject: UPDATE: EAP BOF Method Template Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu An update on the recommended EAP BOF Method Template slide. If you are presentating an EAP Method at the EAP BOF (e.g. you have requested time on the agenda to present a Method), please fill in the Template below and include this slide in your talk. A version of the template is available at: http://www.drizzle.com/~aboba/AAA/BOFTemplate.ppt Note that a few fields have been added to the template. EAP BOF Method Template Slide Name of the Method: EAP/BLAH Filename: draft-author-eap-blah-00.txt Authors: john doe Justification: Why anyone should care about your method Usage scenario: When and where will it be used? EAP Type # assigned: XX Privacy Support: yes or no Mutual authentication: yes or no Support for "fast reconnect: yes or no Support for tunneling of other EAP methods: yes or no Dictionary attack vulnerability: yes, or no Key derivation: yes or no; if yes, what kind of keys Like media: what media will it likely be used with (802, PPP, VPN, etc.) AAA dependency: does it only work with a subset of AAA protocols Key hierarchy defined: yes or no Algorithms: what algorithms does it use Standards group dependencies: has another standards organization made a formal request to the IETF relating to it From owner-ietf-ppp@merit.edu Tue Mar 19 21:49:26 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11862 for ; Tue, 19 Mar 2002 21:49:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D5099125E; Tue, 19 Mar 2002 21:48:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F348A9125F; Tue, 19 Mar 2002 21:48:52 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23B4A9125E for ; Tue, 19 Mar 2002 21:48:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06B6D5DDEE; Tue, 19 Mar 2002 21:48:52 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 90FEB5DDA2 for ; Tue, 19 Mar 2002 21:48:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2K26p127470; Tue, 19 Mar 2002 18:06:51 -0800 Date: Tue, 19 Mar 2002 18:06:51 -0800 (PST) From: Bernard Aboba To: eap@frascone.com Cc: ietf-ppp@merit.edu Subject: Slides for EAP BOF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Due to time constraints, we will be assembling a single slide deck for the EAP BOF, so as to avoid having to change laptops. This means that everyone needs to send their slides to the EAP mailing list ASAP, by no later than 1200 tommorrow, March 20, 2002. From owner-ietf-ppp@merit.edu Mon Mar 25 13:10:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23374 for ; Mon, 25 Mar 2002 13:10:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 071DE91236; Mon, 25 Mar 2002 13:10:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C932391239; Mon, 25 Mar 2002 13:10:11 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E57C691236 for ; Mon, 25 Mar 2002 13:10:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC3B05DDCC; Mon, 25 Mar 2002 13:10:10 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4A4C15DDC1 for ; Mon, 25 Mar 2002 13:10:10 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2PHQoM14086; Mon, 25 Mar 2002 09:26:51 -0800 Date: Mon, 25 Mar 2002 09:26:50 -0800 (PST) From: Bernard Aboba To: eap@frascone.com Cc: ietf-ppp@merit.edu Subject: EAP issue tracking process Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu In order to better track issues with EAP-related documents, we are going to be instituting an issue tracking process similar to what is being used now within AAA WG. The EAP issues list, once we have got it going, will be availble for inspection at: http://www.drizzle.com/~aboba/EAP/eapissues.html As part of this effort, we will be tracking requested changes to the following documents: draft-ietf-pppext-rfc2284bis-0x.txt draft-aboba-pppext-key-problem-0x.txt Changes to RFC 2869 will be handled in the AAA WG, which has several issues relating to EAP in the NASREQ issues list, which can be viewed at: http://www.drizzle.com/~aboba/AAA/issues.html If you would like to propose a change to any of the above documents, please post a message to the EAP mailing list with [issue] in the subject, along with the title of the change. In the body of the message, please include the following information: Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [base, nasreq, mobileip, cms] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal Since the goal is to complete RFC 2284bis by June, I would like to encourage everyone to submit their issues ASAP so that we can address them and make rapid progress. From owner-ietf-ppp@merit.edu Mon Mar 25 16:50:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04981 for ; Mon, 25 Mar 2002 16:50:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 834E991242; Mon, 25 Mar 2002 16:50:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5315E91245; Mon, 25 Mar 2002 16:50:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F91191242 for ; Mon, 25 Mar 2002 16:50:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5504A5DDC4; Mon, 25 Mar 2002 16:50:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A92BD5DDC0 for ; Mon, 25 Mar 2002 16:50:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2PL89V25616; Mon, 25 Mar 2002 13:08:09 -0800 Date: Mon, 25 Mar 2002 13:08:09 -0800 (PST) From: Bernard Aboba To: eap@frascone.com Cc: ietf-ppp@merit.edu Subject: EAP issues list now available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu A list of open issues on various EAP-related drafts is now online at: http://www.drizzle.com/~aboba/EAP/eapissues.html To file your own issue, please send mail to eap@frascone.com, with [issue] and the title of the issue in the subject, and the following text in the body of the message: Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [RFC2284bis, RFC 2869bis, Keying Framework] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal From owner-ietf-ppp@merit.edu Wed Mar 27 16:06:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23053 for ; Wed, 27 Mar 2002 16:06:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA4B991293; Wed, 27 Mar 2002 16:06:07 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5F3C91298; Wed, 27 Mar 2002 16:06:07 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40E9D91293 for ; Wed, 27 Mar 2002 16:06:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A9005DE18; Wed, 27 Mar 2002 16:06:06 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 92FBC5DE16 for ; Wed, 27 Mar 2002 16:06:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2RKNXb11827; Wed, 27 Mar 2002 12:23:33 -0800 Date: Wed, 27 Mar 2002 12:23:33 -0800 (PST) From: Bernard Aboba To: eap@frascone.com Cc: ietf-ppp@merit.edu Subject: RFC2284bis-03 strawman available for inspection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I've put a strawman RFC 2284bis-03 version up for inspection at: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-03.txt The open and resolved issues on the specification are described in: http://www.drizzle.com/~aboba/EAP/eapissues.html Specifically, the following issues are resolved in the -03 strawman: Issue #1 EAP NAK allows only one alternative method Issue #2 "Alternative Indications" not useful Issue #4 EAP multiplexing model not described Issue #5 Editorial changes to section 4.2 Issue #13 Identifier usage not specified Issue #14 EAP transport behavior not specified The following issues remain open: Issue #3 EAP needs a formal state machine Issue #10 No support for acknowledged Success or Failure Issue #11 No threat model Issue #12 No support for localization Issue #17 EAP Negotiation Method Here is where we are on the open issues: Issue #3: We have a submitted state machine paper from Bryan Payne, which was presented at IETF 53. I would like to solicit discussion of that paper. Issue #10: We have a proposed resolution, which involves addition of an "Acknowledged Outcome" Method. This would appear to address the issue raised by Bryan Payne about the client and server getting out of sync. However, since this is a major change, I'd like see more discussion of the issue before making changes to the spec. Issue #12: The issue describes two potential avenues for resolution. Would like to get a sense of where the WG wants to go on this before proceeding. Issue #17: Not sure where to go with this one. Do we need a generic negotiation method? If so, what should it do? From owner-ietf-ppp@merit.edu Thu Mar 28 07:09:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22577 for ; Thu, 28 Mar 2002 07:09:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A808D912B2; Thu, 28 Mar 2002 07:09:08 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DDE5912B3; Thu, 28 Mar 2002 07:09:08 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57664912B2 for ; Thu, 28 Mar 2002 07:09:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DD625DDD6; Thu, 28 Mar 2002 07:09:07 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C3CEE5DDD5 for ; Thu, 28 Mar 2002 07:09:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22544; Thu, 28 Mar 2002 07:09:04 -0500 (EST) Message-Id: <200203281209.HAA22544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-ttls-01.txt Date: Thu, 28 Mar 2002 07:09:03 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : EAP Tunneled TLS Authentication Protocol (EAP-TTLS) Author(s) : P. Funk, S. Blake-Wilson Filename : draft-ietf-pppext-eap-ttls-01.txt Pages : 40 Date : 27-Mar-02 EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-ttls-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-ttls-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020327152431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-ttls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-ttls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152431.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Sat Mar 30 17:43:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06386 for ; Sat, 30 Mar 2002 17:43:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC72B9121E; Sat, 30 Mar 2002 17:42:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A86999121F; Sat, 30 Mar 2002 17:42:50 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 716CC9121E for ; Sat, 30 Mar 2002 17:42:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F34F5DDAF; Sat, 30 Mar 2002 17:42:24 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8EFD05DD8D for ; Sat, 30 Mar 2002 17:42:09 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g2ULx7F14685; Sat, 30 Mar 2002 13:59:12 -0800 Date: Sat, 30 Mar 2002 13:59:07 -0800 (PST) From: Bernard Aboba To: ietf-ppp@merit.edu Cc: eap@frascone.com Subject: RFC 2284bis status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu We are now tracking issues in the EAP specification revision, RFC 2284bis, on the following web page: http://www.drizzle.com/~aboba/EAP/eapissues.html A version of the -03 strawman is available at: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-03.txt If you would like to raise an issue with the specification, please send mail to eap@frascone.com with [issue] and the title of the issue in the subject, and following fields in the body: Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [RFC2284bis, RFC 2869bis, Keying Framework] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal