From skitrip2008-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 01 08:32:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GU0V6-0002pc-DO for capwap-archive@lists.ietf.org; Sun, 01 Oct 2006 08:32:56 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GU0V3-0003eQ-4U for capwap-archive@lists.ietf.org; Sun, 01 Oct 2006 08:32:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 14700398041 for ; Sun, 1 Oct 2006 05:32:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: frascone.com mailing list memberships reminder From: skitrip2008-owner@frascone.com To: capwap-archive@lists.ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Oct 2006 05:30:46 -0700 Precedence: bulk X-BeenThere: skitrip2008@frascone.com X-Mailman-Version: 2.1.9 List-Id: Our Next Skitrip! X-List-Administrivia: yes Errors-To: skitrip2008-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 This is a monthly reminder about your frascone.com mailing list memberships. It shows the lists you are subscribed to, your passwords, and a Web page URL you can use to manage your subscriptions. Visit the Web page URL shown below to unsubscribe, change your e-mail address, temporarily disable your subscription for a vacation, set digest-style delivery, and so on. You can also use e-mail to make changes. For more info, send a message to the '-request' address of the list (for example, skitrip2008-request@frascone.com) containing just the word 'help' in the message body. An e-mail message will be sent to you with instructions. Here is the subscription information for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com ugimni http://lists.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From callistau@brownwoodmusic.com Sun Oct 01 23:43:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUEiY-0006QE-GZ for capwap-archive@ietf.org; Sun, 01 Oct 2006 23:43:46 -0400 Received: from [201.255.22.203] (helo=brownwoodmusic.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUEiW-00047q-Tv for capwap-archive@ietf.org; Sun, 01 Oct 2006 23:43:46 -0400 Message-ID: <01c6e5ab$06f118f0$cb16ffc9@lt4k82xc7nymod> Date: Mon, 2 Oct 2006 00:43:34 +0100 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Linda Shrader" From: "Linda Shrader" To: Subject: PHxyvARMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0765_01C6E5BB.CA7C59F0" X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0765_01C6E5BB.CA7C59F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good day, AMBttIEN CIAttLIS VIAttGRA VALttIUM Save 50 % with http://www.sedunjinkadesinkloons.com =20 _____ =20 treated, but the whole ugly business. Well, I feel that it is getting temporooter. Well take it off your hands now. him at work, just the results. ------=_NextPart_000_0765_01C6E5BB.CA7C59F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good day,

AMBttIEN

CIAttLIS

VIAttGRA

VALttIUM

 

treated, but the whole ugly business. Well, I feel that it = is getting
temporooter. Well take it off your hands now.
him at work, just the results.

------=_NextPart_000_0765_01C6E5BB.CA7C59F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 02 01:47:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUGeV-0005t1-Bj for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 01:47:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUGeQ-00060H-OY for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 01:47:43 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DB3681448023 for ; Sun, 1 Oct 2006 22:47:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8098B4300EA for ; Sun, 1 Oct 2006 22:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2D6A4144800D for ; Sun, 1 Oct 2006 22:37:50 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 9F15D1448008 for ; Sun, 1 Oct 2006 22:37:41 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k925bKtX028518; Mon, 2 Oct 2006 14:37:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k925bMN09008; Mon, 2 Oct 2006 14:37:22 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id k925bFl27810; Mon, 2 Oct 2006 14:37:15 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Oct 2006 13:36:07 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F228D@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgAAILorcACAwhAA From: "Cheng Hong" To: "Bob O'Hara (boohara)" , "Dorothy Stanley" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap@frascone.com, Saravanan Govindan Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530292894==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: cbc3a0773f997484b7ccb6b9a6247de5 This is a multi-part message in MIME format. --===============1530292894== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E5E4.AA897A5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E5E4.AA897A5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bob, =20 Let's get this straight again, hopefully, it is the last time. We have been deviated from the real technical issue by your non-technical comments too many times. And, by the way, they are not funny at all :) =20 No one is asking for assistance of protocol design from you or Cisco as a commercial entity. The question was raised since you claim that your proposal is workable, and should be adopted by the CAPWAP WG into the protocol design. Shouldn't any member of this WG demand a bit more information to justify your assertion? I think as a veteran of standardization, you should know this better than anyone else ?! =20 If you plainly refuse to provide any information on that, please stop talking again like "xxx products works fine like this, and there is no problem", since it is simply not verifiable.=20 =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Saturday, September 30, 2006 12:10 AM To: Cheng Hong; Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations I am afraid that requesting design assistance from a competitor is very close to violation of U.S anti-trust laws. I will not describe how Cisco has designed any of its products and I cannot help you design yours. =20 Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity. A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions. And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary. =20 As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC. This must be done for EVERY frame received, whether it is a replayed frame or not. This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA. So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame. -Bob =20 =20 _____ =20 From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: Thursday, September 28, 2006 5:34 PM To: Bob O'Hara (boohara); Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Bob, =20 As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.=20 =20 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function. =20 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.=20 =20 Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack? =20 cheers =20 Cheng Hong =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap =20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap =20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > _________________________________________________________________=20 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap =20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6E5E4.AA897A5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Bob,
 
Let's=20 get this straight again, hopefully, it is the last time. We have been = deviated=20 from the real technical issue by your non-technical comments too many = times.=20 And, by the way, they are not funny at all :)
 
No one=20 is asking for assistance of protocol design from you or Cisco as a = commercial=20 entity. The question was raised since you claim that your proposal is = workable,=20 and should be adopted by the CAPWAP WG into the protocol design. = Shouldn't any=20 member of this WG demand a bit more information to justify your = assertion? I=20 think as a veteran of standardization, you should know this better than = anyone=20 else ?!
 
If you=20 plainly refuse to provide any information on that, please stop talking = again=20 like "xxx products works fine like this, and there is no problem", since = it is=20 simply not verifiable.
 
cheers
 
Cheng=20 Hong
 
 
 

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
Sent: Saturday, September 30, = 2006 12:10=20 AM
To: Cheng Hong; Dorothy Stanley
Cc: Pat Calhoun = (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); = capwap@frascone.com;=20 Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - = Explanation for=20 802.11i Considerations

I am afraid that requesting design assistance = from a=20 competitor is very close to violation of U.S anti-trust laws.  I = will not=20 describe how Cisco has designed any of its products and I cannot help = you=20 design yours.
 
Again, your proposal does not eliminate any = attack=20 mechanism and does not add any functionality to the protocol, only = cost and=20 complexity.  A replayed frame will be discarded by the MAC, using = the=20 normal duplicate frame detection mechanisms.  See section=20 8.3.3.3.2 of 802.11i (where the frame sequence number is part = of the=20 additional authenticated data) and section 9.2.9 of = 802.11-1999 for the=20 description of these functions.  And PLEASE read 802.11 and = 802.11i=20 before again asserting that this proposal is = necessary.
 
As I said several emails ago, the ONLY effect = of using=20 zero as the value for the KeyRSC is that the 802.11 chipset in the STA = (client) will have to receive the frame, attempt to decrypt it, and = validate=20 the MIC.  This must be done for EVERY frame received, whether it = is a=20 replayed frame or not.  This set of functions is performed in the = 802.11=20 STA chipset and does not consume any additional resources of the = STA. =20 So, the attack, if it can even be characterized as an attack, is no = more=20 effective at DOSing the STA than sending it any other=20 frame.

 -Bob
 

 

From: Cheng Hong=20 [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Thursday, = September 28,=20 2006 5:34 PM
To: Bob O'Hara (boohara); Dorothy = Stanley
Cc:=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com; Saravanan Govindan
Subject: RE: = [Capwap] Issue=20 43 - Explanation for 802.11i Considerations

Hi=20 Bob,
 
As=20 Dorothy correctly pointed out below, setting the KeyRSC to a value = closer to=20 the current RSC would be better than setting it to a pre-defined value = zero.=20
 
It=20 is true that 802.11i and 802.1X do not specify what is the KeyRSC = value to be=20 used, since they are trying to provide us a tool to correctly = synchronize the=20 RSC using the Msg 3. By mandating the KeyRSC to zero, we are just = disabling=20 the tool. It is not wrong, but just deprives the system a designed=20 function.
 
As=20 for the effectiveness of KeyRSC, setting it to a predefined value of 0 = would=20 pose a greater threat. In a simple example, if the RSC is currently = 1000, and=20 we are mandating the KeyRSC to be always zero, the attacker = basically can=20 safely replay the last 1000 packets to the STA without being = detected. If=20 the KeyRSC can be set to a closer value of the current RSC, say, 900, = the=20 number of possible replayed packets can be reduced to 10 percent, = 100=20 packets.
 
Therefore, I would say, setting the KeyRSC value to zero does = place a=20 bigger threat. Is that how the cisco products implemented? Maybe you = could=20 share with us some other implementation/testing data to prove = otherwise. Or,=20 you have some other considerations that could defend the replay=20 attack?
 
cheers
 
Cheng Hong
 

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
Sent: Friday, September 29, = 2006 5:21=20 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat = Calhoun=20 (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - = Explanation=20 for 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it = is no more=20 effective than sending a value of zero for the KeyRSC.  It = doesn't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and = complexity to=20 the protocol. 

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28,=20 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng = Hong;=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); = capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation=20 for 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 = Clause 8.5.2,=20 describing the Key RSC field.:

"g)=20 Key RSC. This field is 8 octets in length. It contains the receive = sequence=20 counter (RSC) for the
GTK being installed in IEEE 802.11. It = is used in=20 Message 3 of the 4-Way Handshake andMessage 1 of the=20 Group Key Handshake, where it is used to synchronize the IEEE 802.11 = replay
state. It may also be used in the = Michael MIC=20 Failure Report frame, to report the TSC field value ofthe = frame=20 experiencing a MIC failure. It shall contain 0 in other messages. = The Key=20 RSC field gives
the current message number for the GTK, = to allow=20 a STA to identify replayed MPDUs. If the KeyRSC = field value=20 is less than 8 octets in length, the remaining octets shall be set = to 0. The=20 least significant
octet of the TSC or PN should be in the = first=20 octet of the Key RSC field."

The intent of adding this = value=20 in message 3 was to immediately minimize the number of
replayed = frames=20 that a STA would potentially process: "The Key RSC field = gives
the=20 current message number for the GTK, to allow a STA to identify = replayed=20 MPDUs."
Setting the value to 0 in Msg 3 does not provide the = current=20 sequence counter (in most cases
not even close) of the=20 GTK..

Perhaps the WTP could periodically/frequently notify = the AC of=20 its current GTK sequence counter, and the
AC would use the most = recently=20 received value in the message 3 sent to new STAs. The RSC = value
would not=20 be  up to date at all times, but would be closer than "0", not = require=20 an "in-the-critical-path
message exchange between the AC and WTP, = and=20 still be close to the intended use of the = field.

Dorothy

On 9/28/06, Bob=20 O'Hara (boohara) <boohara@cisco.com> = wrote:=20
Please=20 understand that 802.11i specifies no behavior in this area = for
the=20 802.1X authenticator.  Our choice to send a group key = KeyRSC=20 value
of zero in the EAPOL-key frame requires no change to = 802.11i or=20 to
802.1X .  It requires us to state this in the = CAPWAP spec,=20 if we want
this behavior to be consistent across all=20 implementations.

The problem with what Bechet and Saranavan = are=20 asking is that either of
three different things are required: =
1:=20 the WTP must communicate the group key TSC to the AC every time it = is
updated, or
2: the AC must request the current value of = the group=20 key TSC for the
KeyRSC before constructing the EAPOL-key frame, = or
3: the AC must send the KCK to the AC so  that it = can=20 insert the KeyRSC
value and also calculate the correct MIC, = inserting=20 that into the proper
EAPOL-key frame.

The first item = requires a=20 tremendous amount of additional CAPWAP
communication between = WTP and=20 AC, at least one new CAPWAP packet for
every multicast frame = sent by=20 the WTP, if the packet is not
acknowledged, or two new CAPWAP = packets,=20 if it is acknowledged.  This is
a very expensive = addition to=20 the protocol.

The second item requires new protocol = between the AC=20 and WTP during what
can be a time critical portion of the = 802.11=20 transition (handoff, roam)
from one WTP to = another.  It also=20 introduces a race condition that is
not present in the = protocol=20 today.  Once the value for the KeyRSC is
sent from = the WTP to=20 the AC, it is possible that the WTP can send
another multicast = frame=20 encrypted with the group key.  This puts the
value of = the=20 sequence counter out of sync with the value that will be =
shortly=20 communicated to the client in the EAPOL-key frame from the = AC.
This=20 will behave exactly the same as if a value of zero is sent in=20 the
EAPOL-key frame.

The third item requires a new = architecture=20 split that is not required in
our objectives.  The = new split=20 is not splitting the MAC, but splitting
the=20 authenticator.  Placing the KCK in the WTP is also a=20 potential
reduction in the security of the overall WLAN system, = since=20 these
devices are normally not in a secured wiring closet, but = exposed=20 and
more easily compromised than the AC.

The simplest = to=20 implement, least expensive, and most secure option is to
use = the=20 protocol as it is now specified and have the AC send a value = of
zero in=20 the KeyRSC field of the EAPOL-key frame. =

-Bob

-----Original=20 Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun = (pacalhou); Bob=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J = (LI/EAB)
Cc:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Issue 43 - Explanation for 802.11i = Considerations

Hi=20 Pat and all,

So, based on this, I would say that we have = consensus=20 that setting the
correct KeyRSC is an issue for the CAPWAP = protocol=20 design.

So far, we have three option/solutions:

1) = As=20 proposed by Bob: Using a static value (0) for the = KeyRSC.

2) As=20 suggested by Behcet: AC communicate a correct KeyRSC to WTP =

3) As=20 suggested by Saravanana: Some exchange mechanism between WTP=20 and
AC

Among the three, the first option seems the = easiest.=20 However, it
requires a mandated Authenticator behavior(in this = case AC)=20 that is not
mandated by 802.11. Therefore, we have to specify = that=20 (e.g. as proposed
by Bob: "We could include a note to the = effect that=20 the group KeyRSC
should be zero in the EAPOL-key frame.") = either in=20 CAPWAP or 802.11,
because otherwise there is no = interoperability. For=20 example, AC provided
by another vendor does not have to set = KeyRSC to 0=20 to be compliant with
CAPWAP and 802.11i.

Another = implication is=20 that we don't really understand the impact of
mandating a = static=20 KeyRSC value. Although Bob provided an excellent
analysis, I = still have=20 some doubts about the profoundness of the impact.
If the KeyRSC = value=20 is as described of no use, why would it appear in
the EAPOL = frames in=20 the first place? By mandating it to static value,
what have we = lost?=20 Maybe some liaison letter to 802.1 or 802.11 could
provide us a = better=20 understanding of the issue.

For the last two options, I = think they=20 are both within CAPWAP's scope.
Further analysis could help us = to=20 decide which one  is better (or
someone could propose = other=20 solutions).

cheers

Cheng=20 Hong







> -----Original=20 Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara=20 (boohara); T. Charles Clancy;
> Peter Nilsson J = (LI/EAB)
> Cc:=20 capwap@frascone.com
>=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this = way=20 today. The AP (or in
> this case AC) can set the RSC to = whatever=20 value it wishes.
> Bob used zero (0) as an example. = Implementations=20 could use
> any other value, which would require some form=20 of
> communication to the WTP, as suggested by Behcet.=20
>
> Pat Calhoun
> CTO, Wireless Networking = Business=20 Unit
> Cisco Systems
>
>
>
> >=20 -----Original Message-----
> > From: Cheng Hong = [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, = September 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles = Clancy;=20 Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > = Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 Considerations
> >
> > Hi Bob,
> = >
> >=20 If I understand your description below correct, you are proposing = a=20
> > solution (to the problem pointed out by
> > = Saravanan) by mandating the behavior of the AC to always set = the
>=20 > KeyRSC in the 4-way handshake to zero.
> >
> = > This=20 is not a defined behavior according to the current
> > = 802.11=20 standard.
> > Are you suggesting that we CAPWAP WG should = specifically
> mandate that
> > in our CAPWAP = protocol=20 spec, e.g. something like "a CAPWAP
> compatible
> = > AC=20 MUST set KeyRSC to zero"? Otherwise, the problem still = exists,
>=20 > since not all AC implementation have to follow what you=20 described.
> >
> > Or, are you planning to take = this=20 issue to TGm for 802.11 standard
> > revision? (since = based on=20 your description, there is essentially no
> > use of the=20 KeyRSC).
> >
> > cheers
> >
> = > Cheng=20 Hong
> >
> >
> >
> >
> = >=20 > -----Original Message-----
> > > From: Bob O'Hara = (boohara) [mailto:boohara@cisco.com]
> = > >=20 Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: = T.=20 Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > = > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i =
>=20 > > Considerations
> > >
> > > = Charles,=20 Peter,
> > >
> > > Below is an expansion = of a=20 snippet from a thread on this
> > topic that I
> = > >=20 sent to the list on July 25, 2006.  I think this will be =
> helpful to
> > > understand why the exchange = that=20 Saranavan is requesting is not
> > > = necessary.  In=20 fact, there are several systems from several
> > >=20 manufacturers in the field using precursor protocols to
> = CAPWAP=20 that
> > > are Wi-Fi certified for WPA2/802.11i = operation=20 using the
> > protocol as
> > > it is = described=20 below.
> > >
> > > BTW, this whole = discussion is=20 about the KeyRSC for the
> > group key, not
> > = >=20 the pairwise key.  This is so because the WTP and AC=20 both
> know the
> > > initial sequence counter = value for=20 the pairwise key, since it has
> > > never been used = to send a=20 frame.   802.11i requires the
> first = frame
> >=20 > sent on a key to use the sequence counter value of=20 1.  See
> > 8.3.2.6=20 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i = for=20 this requirement.
> > >
> > > The same is = not true=20 of the group key, i.e., after the WTP begins
> > > = operation,=20 the AC will not know the value of the sequence
> > = counter for=20
> > > the group key when it needs to complete the=20 EAPOL-key
> > handshake with a
> > > newly = associated=20 STA.
> > > However, as you will see from the tutorial = below,=20 it is not
> > necessary
> > > for the AC and = WTP to=20 exchange any information about the
> group key
> > = >=20 KeyRSC for the protocol to operate as it is intended.
> > = >
> > > 1. A value for the KeyRSC in the EAPOL-key = frame is=20 necessary to
> > > calculate the KeyMIC.
> > = >
> > > 2. This value does not need to bear any=20 specific
> > relationship to the
> > > RSC = value=20 maintained by the WTP.  A value of zero in the
>=20 EAPOL-key
> > > frame for the group key will always=20 work.
> > >
> > > 3. The client STA will = use the=20 value of KeyRSC received in the
> > > EAPOL-key frame = to=20 validate frame using the KeyMIC.
> > >
> > = > 4.=20 The client STA will also set its group key RSC to the = value
> >=20 > received in KeyRSC, say, zero.
> > >
> > = > 5.=20 The value in the client STA's RSC will be compared against the =
>=20 > > sequence number in subsequent received frames to = identify=20 replay
> > > attacks.  Any frame received = with a=20 sequence counter value
> > within the
> > > = replay=20 window will be checked to have a valid MIC.  If the =
>=20 > MIC is not
> > > valid, the frame is = dropped.
>=20 > >
> > > 6. For any frame that is determined = not to be=20 a replay
> attack frame
> > > and meets all = other=20 validity and authenticity requirements,
> > the = client
>=20 > > STA updates its RSC value to the sequence number in the=20 received
> > > frame, if the value is greater than its = current=20 RSC value.
> > Only the
> > > AP can meet = these=20 criteria as the source of a frame
> received by the
> = >=20 > STA.
> > >
> > > 7. Please see item = 6,=20 immediately above, for the reason
> that the AC
> > = >=20 and WTP do not need to coordinate and exchange the RSC.
> = >=20 >
> > >
> > > The only possible attack = mode is=20 for the attacker to send
> frames to
> > > the = client=20 STA between the time of the EAPOL-key frame and
> > the = first=20
> > > frame encrypted with the group key.
> = > >=20 During this time, the client will receive the frame and
> = proceed=20 to
> > > validate its MIC.  This is a = potential=20 attack against the STA
> > > = resources.  But, the=20 MIC validation is done in the STA's
> > > 802.11 chip = and=20 consumes no more resources than receiving
> any = other
> >=20 > frame.  Thus, the attack does not actually consume = any STA=20
> > resources
> > > beyond those of = receiving a=20 frame.
> > >
> > > This attack is not = unique to=20 the use of the value zero for
> > the KeyRSC,
> = > >=20 either.  The same attack is available to an attacker at = any=20 other
> > > time, as well.  It is no more = nor less=20 effective at either time.
> > >
> > > For = these=20 reasons, the protocol is not in need of any changes to
> = > >=20 address the issue raised by Saranavan.
> > >
> = >=20 >  -Bob
> > > -----Original = Message-----
>=20 > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
> = > >=20 Sent: Monday, September 25, 2006 11:37 AM
> > > To: = Peter=20 Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > = > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > >
> > > This is a = very=20 interesting solution.  The AC selects the
> KeyRSC = and
> > > performs the 4-way handshake.  The = WTP=20 sniffs the 4-way handshake
> > > traffic and grabs the = KeyRSC=20 value and uses it to
> > initialize its own
> > = >=20 counter.
> > >
> > > Pat/Bob: Is this how = the=20 Cisco implementation works?  I
> > have to=20 agree
> > > with Saravanan that I've yet to see a = technical=20
> description of how
> > > Cisco implements = it.
>=20 > >
> > > IMHO, this is somewhat hackish, and it = would=20 be cleaner to
> > have the AC
> > > generate = the=20 KeyRSC and include it in the AddMobile message
> > as=20 Behcet
> > > suggests.
> > >
> > = >=20 --
> > > t. charles clancy, = ph.d.  |  tcc@umd.edu  |
> = www.cs.umd.edu/~clancy
>= =20 > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J = (LI/EAB)=20 wrote:
> > >
> > > > I think Saravanan = has a=20 point. We did a prototype
> > impelementation of
> = >=20 > the
> > > > protocol a year ago when it was = still=20 called LWAPP. The way
> > > we solved
> > = > >=20 this issue then was to let the WTP sniff on all CAPWAP = data
> >=20 > messages
> > > > from the AC and when message = 3 of=20 the 4-way handshake or
> > > message 1 of
> > = >=20 > the groupkey handshake was sent the WTP inserted the correct=20 RSC
> > > before
> > > > sending it = off to the=20 supplicant. To avoid the sniffing on
> > > all = CAPWAP
>=20 > > > data messages we would need a mechanism with in = CAPWAP=20 to
> > > handle these
> > > > two=20 messages.
> > > >
> > > > Peter=20 Nilsson
> > > >
> > > > = -----Original=20 Message-----
> > > > From: Saravanan = Govindan
> >=20 > [mailto:Saravanan.Govindan@sg= .panasonic.com]
>=20 > > > Sent: den 22 september 2006 11:03
> > > = >=20 To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > = > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
>=20 > > Considerations
> > > >
> > > = > Hi=20 Margaret,
> > > >
> > > > Thank you = for=20 reviewing the discussion on this issue.
> > > = >
>=20 > > > The issue here is the working of IEEE 802.11i when = the=20 802.11i
> > > > authenticator element is at the AC = and the=20 802.11i crypto
> > element is
> > > = at
> >=20 > > the WTP. Particularly, it is for the 4-way handshake = between=20
> > > > authenticator and supplicant.
> > = >=20 >
> > > > Now, the 4-way handshake requires = knowing the=20 value of
> > > KeyRSC sequence
> > > > = counter.=20 The KeyRSC helps both authenticator and supplicant
> > = > keep=20 track
> > > > of their exchanges. It serves to = protect=20 against threats by
> > > tracking
> > > = >=20 sequential frames. The KeyRSC is maintained at the at the
> = >=20 point of
> > > > encryption, i.e. just before = transmission=20 over the
> > wireless channel.
> > > = >
>=20 > > > In the case of CAPWAP, the 4-way handshake is = between the=20 AC
> > > > (authenticator) and the wireless = station=20 (supplicant).
> > > >
> > > > The = problem=20 arises, when the authenticator is at the AC and
> > > = the=20 crypto
> > > > element (together with KeyRSC) is at = the=20 WTP. This is a
> > > fairly common
> > > = >=20 design. Now in this case, the AC starts the 4-way
> = handshake but=20 it
> > > does
> > > > not know the = value of the=20 KeyRSC. The KeyRSC is maintained
> > > by the = WTP.
>=20 > > >
> > > > Based on this, the current = CAPWAP=20 specification does not
> > allow for a
> > >=20 way
> > > > to conduct the 4-way handshake with the = correct=20 KeyRSC.
> > > >
> > > > The = functionality I=20 would like to see is a way for the
> > = authenticator
> >=20 > > (AC) to use the correct prevailing value of = KeyRSC
> >=20 > (maintained by the
> > > > WTP) in its 4-way=20 handshake.
> > > >
> > > > One way = to=20 introduce this functionality in to CAPWAP is
> > to have=20 part
> > > of
> > > > the 4-way = handshake be=20 sent from AC to WTP. This will allow
> > > the = 4-way
>=20 > > > handshake to use the correct value of the KeyRSC=20 before
> > > being sent to
> > > > the = wireless=20 station.
> > > >
> > > > I hope this = helps=20 clarify my view on the issue.
> > > >
> > = >=20 > Cheers,
> > > >
> > > >=20 Saravanan
> > > >
> > > >
> = > >=20 >
> > > >
> > > >
> > = >=20 >
> > > > -----Original Message-----
> = > >=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
&= gt;=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> = >=20 > > To: Saravanan Govindan
> > > > Cc: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
> > = > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
>=20 > > Considerations
> > > >
> > >=20 >
> > > >
> > > > Hi = again,
> >=20 > >
> > > > Okay, I am even more confused = than I=20 thought I was...
> > > >
> > > > = Saravanan,=20 you wrote:
> > > >
> > > > On Sep = 17, 2006,=20 at 10:24 PM, Saravanan Govindan wrote:
> > > = >
> >=20 > >> Pat,
> > > >>
> > > = >>=20 The issue here is about how 802.11i exchanges are done = when
> >=20 > >> authenticator is at the AC and crypto elements are=20 at
> > the WTP. This
> > > is
> > = >=20 >> the requirement.
> > > >
> > > = >=20 And, in response, Pat Calhoun wrote:
> > > = >
> >=20 > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) = wrote:=20
> > > >> The current specification allows the=20 authenticator to
> > > reside in the
> > > = >> AC, while the data packet crypto elements in the WTP.=20 This
> > > feature is
> > > >> = already in=20 the specification.
> > > >
> > > > = Pat's=20 message matches my reading of the specification.
> > > = >
> > > > So, Saravanan, what functionality are = you=20 asking for
> that is not
> > > > already = supported=20 by the specification?  And why do you
> > think = it=20 is
> > > > necessary?  it will not be = helpful to=20 my understanding to
> > > re-send your
> > = > >=20 proposal or to cite the requirements = document...  Please
>=20 > summarize
> > > > what functionality you think = is=20 missing from the current
> > > specification
> = > >=20 > and why you think that functionality is necessary to
> = support=20 IEEE
> > > > 802.11i or any important use = case.
>=20 > > >
> > > > At some point, the chairs = may need=20 to make a consensus
> > call on this
> > > = >=20 issue, and I'd like to understand your view and make sure
> = >=20 > that it has
> > > > been clearly communicated = to the=20 WG before we ask the WG to
> > > decide on
> = > >=20 > this issue.
> > > >
> > > > = Thanks,=20
> > > > Margaret
> > > >
> = > >=20 >
> > > >
> > > >
> > = >=20 >
> > > >
> > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
> > >=20 _________________________________________________________________ =
>=20 > > To unsubscribe or modify your subscription options, = please=20 visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >=20 = _________________________________________________________________
>= =20 > > To unsubscribe or modify your subscription options, = please=20 visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >
>=20 = _________________________________________________________________
>= =20 To unsubscribe or modify your subscription options, please = visit:
>=20 http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________=20
To unsubscribe or modify your subscription options, please=20 visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap

------_=_NextPart_001_01C6E5E4.AA897A5F-- --===============1530292894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1530292894==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 02 03:08:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUHuy-0007Hd-94 for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 03:08:48 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUHuu-0007Bd-Tz for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 03:08:48 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 0AEAD4302ED for ; Mon, 2 Oct 2006 00:08:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3A7434300EA for ; Sun, 1 Oct 2006 23:54:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F07191448008 for ; Sun, 1 Oct 2006 23:54:16 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 9C27C1448023 for ; Sun, 1 Oct 2006 23:54:08 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k926s4Ei011730; Mon, 2 Oct 2006 15:54:04 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k926s5303192; Mon, 2 Oct 2006 15:54:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k926s1115872; Mon, 2 Oct 2006 15:54:01 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Oct 2006 14:53:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F22B4@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjWSU6kmN21tK8RGapj3fA5vIt8gClty6A From: "Saravanan Govindan" To: "Michael Montemurro" , "Bob O'Hara (boohara)" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: capwap@frascone.com, Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175612706==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 86687e0dc8d18807724b35d3f2d155ea This is a multi-part message in MIME format. --===============1175612706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E5EF.674E7F32" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E5EF.674E7F32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 Regarding Section 11.3, I think the GTK update procedure has to reflect the KeyRSC step. I will send text shortly for the WG's consideration. Cheers, =20 Saravanan =20 =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Friday, September 29, 2006 7:41 AM To: Bob O'Hara (boohara) Cc: capwap@frascone.com; Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =20 Bob and all interested parties, =20 In the last round of edits, I updated Section 11.3 to describe the GTK update procedure. I thought that it lines up pretty well with what's in IEEE 802.11i (and implementations of IEEE 802.11i that I am aware of). =20 Could someone make recommendations on how you think this section should be updated? =20 Thanks, =20 Mike =20 On 9/28/06, Bob O'Hara (boohara) wrote:=20 Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations =20 All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the=20 GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of=20 the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant=20 octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases=20 not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value=20 would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field.=20 Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value=20 of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of=20 three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or=20 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com ] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design.=20 So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 3) As suggested by Saravanana: Some exchange mechanism between WTP and=20 AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent=20 analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value,=20 what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or=20 someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes.=20 > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit=20 > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com ] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto: boohara@cisco.com ] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this=20 > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several=20 > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below.=20 > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has=20 > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence=20 > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not=20 > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto: clancy@cs.umd.edu ] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the=20 > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter.=20 > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it.=20 > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet=20 > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:=20 > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way=20 > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on=20 > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson=20 > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto: Saravanan.Govindan@sg.panasonic.com ] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track=20 > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant).=20 > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common=20 > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP.=20 > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto: margaret@thingmagic.com ] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again,=20 > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:=20 > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at=20 > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap=20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap=20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap=20 > > > > > > > _________________________________________________________________=20 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=20 > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap=20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap=20 > _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap=20 =20 ------_=_NextPart_001_01C6E5EF.674E7F32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

Regarding Section 11.3, I think the GTK update = procedure has to reflect the KeyRSC step. I will send text shortly for the WG’s consideration.


Cheers,

 

Saravanan

 

 

 

 

From: = Michael Montemurro [mailto:montemurro.michael@gmail.com]
Sent: Friday, September = 29, 2006 7:41 AM
To: Bob O'Hara = (boohara)
Cc: capwap@frascone.com; Cheng Hong
Subject: Re: [Capwap] = Issue 43 - Explanation for 802.11i Considerations

 

Bob and all interested parties,

 

In the last round of edits, I updated Section 11.3 to describe = the GTK update procedure. I thought that it lines up pretty well with what's in = IEEE 802.11i (and implementations of IEEE 802.11i that I am aware = of).

 

Could someone make recommendations on how you think this section = should be updated?

 

Thanks,

 

Mike

 

On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:

Dorothy,

 

The problem with this proposal is = that it is no more effective than sending a value of zero for the = KeyRSC.  It doesn't eliminate any potential attacks.  It doesn't add any functionality.  However, it does add cost and complexity = to the protocol. 

 -Bob
 

 

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28, 2006 1:17 PM
To: Bob = O'Hara (boohara)
Cc: Cheng Hong; Pat = Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com


Subject: = Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations


 

All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, = describing the Key RSC field.:

"g) Key RSC. = This field is 8 octets in length. It contains the receive sequence counter (RSC) = for the
GTK being installed in IEEE 802.11. It is used in = Message 3 of the 4-Way Handshake and
Message 1 of the Group Key Handshake, where it is used = to synchronize the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure = Report frame, to report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 = in other messages. The Key RSC field gives
the current message number for the GTK, to allow a STA = to identify replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the = remaining octets shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of = the Key RSC field."

The intent of adding this value in message 3 was to = immediately minimize the number of
replayed frames that a STA would potentially process: = "The Key RSC field gives
the current message number for the GTK, to allow a STA = to identify replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the = current sequence counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the = AC of its current GTK sequence counter, and the
AC would use the most recently received value in the = message 3 sent to new STAs. The RSC value
would not be  up to date at all times, but would be = closer than "0", not require an "in-the-critical-path
message exchange between the AC and WTP, and still be = close to the intended use of the field.

Dorothy

On 9/28/06, Bob O'Hara (boohara) <boohara@cisco.com > wrote: =

Please understand that 802.11i specifies no behavior in this = area for
the 802.1X authenticator.  Our choice to send a group key = KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if = we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either of =
three different things are required:
1: the WTP must communicate the group key TSC to the AC every time it = is
updated, or
2: the AC must request the current value of the group key TSC for = the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert = the KeyRSC
value and also calculate the correct MIC, inserting that into the = proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is = acknowledged.  This is
a very expensive addition to the protocol.

The second item requires new protocol between the AC and WTP during = what
can be a time critical portion of the 802.11 transition (handoff, = roam)
from one WTP to another.  It also introduces a race condition = that is
not present in the protocol today.  Once the value for the = KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This = puts the
value of the sequence counter out of sync with the value that will be =
shortly communicated to the client in the EAPOL-key frame from the = AC.
This will behave exactly the same as if a value of zero is sent in = the
EAPOL-key frame.

The third item requires a new architecture split that is not required in =
our objectives.  The new split is not splitting the MAC, but splitting
the authenticator.  Placing the KCK in the WTP is also a = potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and =
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is = to
use the protocol as it is now specified and have the AC send a value = of
zero in the KeyRSC field of the EAPOL-key frame.

-Bob

-----Original Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com ]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; =
Peter Nilsson J (LI/EAB)
Cc: capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i = Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the =
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested by Saravanana: Some exchange mechanism between WTP and =
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not =
mandated by 802.11. Therefore, we have to specify that (e.g. as proposed =
by Bob: "We could include a note to the effect that the group = KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or = 802.11,
because otherwise there is no interoperability. For example, AC provided =
by another vendor does not have to set KeyRSC to 0 to be compliant = with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of =
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the = impact.
If the KeyRSC value is as described of no use, why would it appear = in
the EAPOL frames in the first place? By mandating it to static value, =
what have we lost? Maybe some liaison letter to 802.1 or 802.11 = could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope. =
Further analysis could help us to decide which one  is better = (or
someone could propose other solutions).

cheers

Cheng Hong







> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap@frascone.com
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are = proposing a
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set = the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a = CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you = described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 = standard
> > revision? (since based on your description, there is = essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto: = boohara@cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i =
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on this =
> > topic that I
> > > sent to the list on July 25, 2006.  I think = this will be
> helpful to
> > > understand why the exchange that Saranavan is requesting = is not
> > > necessary.  In fact, there are several systems = from several
> > > manufacturers in the field using precursor protocols to =
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using = the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the =
> > group key, not
> > > the pairwise key.  This is so because the WTP = and AC both
> know the
> > > initial sequence counter value for the pairwise key, = since it has
> > > never been used to send a frame.   802.11i = requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 = c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the = WTP begins
> > > operation, the AC will not know the value of the sequence =
> > counter for
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is = not
> > necessary
> > > for the AC and WTP to exchange any information about = the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame is = necessary to
> > > calculate the KeyMIC.
> > >
> > > 2. This value does not need to bear any specific
> > relationship to the
> > > RSC value maintained by the WTP.  A value of = zero in the
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received = in the
> > > EAPOL-key frame to validate frame using the KeyMIC.
> > >
> > > 4. The client STA will also set its group key RSC to the = value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared = against the
> > > sequence number in subsequent received frames to identify = replay
> > > attacks.  Any frame received with a sequence = counter value
> > within the
> > > replay window will be checked to have a valid = MIC.  If the
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 6. For any frame that is determined not to be a = replay
> attack frame
> > > and meets all other validity and authenticity = requirements,
> > the client
> > > STA updates its RSC value to the sequence number in the = received
> > > frame, if the value is greater than its current RSC = value.
> > Only the
> > > AP can meet these criteria as the source of a frame
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the = reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC. =
> > >
> > >
> > > The only possible attack mode is for the attacker to = send
> frames to
> > > the client STA between the time of the EAPOL-key frame = and
> > the first
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame = and
> proceed to
> > > validate its MIC.  This is a potential attack = against the STA
> > > resources.  But, the MIC validation is done in = the STA's
> > > 802.11 chip and consumes no more resources than = receiving
> any other
> > > frame.  Thus, the attack does not actually = consume any STA
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero = for
> > the KeyRSC,
> > > either.  The same attack is available to an = attacker at any other
> > > time, as well.  It is no more nor less = effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any = changes to
> > > address the issue raised by Saranavan.
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto: = clancy@cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > >
> > > This is a very interesting solution.  The AC = selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs = the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner = to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile = message
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  tcc@umd.edu =   |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a = prototype
> > impelementation of
> > > the
> > > > protocol a year ago when it was still called LWAPP. = The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all = CAPWAP data
> > > messages
> > > > from the AC and when message 3 of the 4-way = handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before
> > > > sending it off to the supplicant. To avoid the = sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in = CAPWAP to
> > > handle these
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan = Govindan
> > > [mailto: Saravanan.Govindan@sg.panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this = issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when = the 802.11i
> > > > authenticator element is at the AC and the 802.11i = crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value = of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and = supplicant
> > > keep track
> > > > of their exchanges. It serves to protect against = threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the = at the
> > point of
> > > > encryption, i.e. just before transmission over = the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is = between the AC
> > > > (authenticator) and the wireless station = (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the = AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This = is a
> > > fairly common
> > > > design. Now in this case, the AC starts the = 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is = maintained
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does = not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct = KeyRSC.
> > > >
> > > > The functionality I would like to see is a way for = the
> > authenticator
> > > > (AC) to use the correct prevailing value of = KeyRSC
> > > (maintained by the
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP = is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This = will allow
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC = before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue.
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto: = margaret@thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan = Govindan
> > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I = was...
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat,
> > > >>
> > > >> The issue here is about how 802.11i exchanges = are done when
> > > >> authenticator is at the AC and crypto elements = are at
> > the WTP. This
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) = wrote:
> > > >> The current specification allows the = authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the = WTP. This
> > > feature is
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the = specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for =
> that is not
> > > > already supported by the = specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the = current
> > > specification
> > > > and why you think that functionality is necessary to =
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a = consensus
> > call on this
> > > > issue, and I'd like to understand your view and make = sure
> > > that it has
> > > > been clearly communicated to the WG before we ask = the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > Thanks,
> > > > Margaret
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> _________________________________________________________________ =
> > > > To unsubscribe or modify your subscription = options,
> please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap =
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> _________________________________________________________________ =
> > > > To unsubscribe or modify your subscription = options,
> please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap =
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, = please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap > > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > > = _________________________________________________________________
> > > To unsubscribe or modify your subscription options, = please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap > > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> > = _________________________________________________________________
> > To unsubscribe or modify your subscription options, please = visit:
> > http://lists.frascone.com/mailman/listinfo/capwap > >
> > Archives: http://lists.frascone.com/pipermail/capwap
> >
> = _________________________________________________________________
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.frascone.com/mailman/listinfo/capwap >
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap




_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap

 

------_=_NextPart_001_01C6E5EF.674E7F32-- --===============1175612706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1175612706==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 02 12:41:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQrW-00019i-QG for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 12:41:50 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQrT-0003Sm-2m for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 12:41:50 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3AA023980BA for ; Mon, 2 Oct 2006 09:41:35 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4F7D5430018 for ; Mon, 2 Oct 2006 09:36:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 40559398028 for ; Mon, 2 Oct 2006 09:36:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0406F398035 for ; Mon, 2 Oct 2006 09:36:33 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2006 09:36:33 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="444695522:sNHT151228212" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92GaXnk019535; Mon, 2 Oct 2006 09:36:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k92GaWYp015756; Mon, 2 Oct 2006 09:36:33 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 09:36:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Oct 2006 09:36:31 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbk5dk/jHe9QPtjQ1ebZ0mRqvN5zQBWHskA From: "Bob O'Hara (boohara)" To: "Charles Clancy" , "Margaret Wasserman" X-OriginalArrivalTime: 02 Oct 2006 16:36:32.0665 (UTC) FILETIME=[EB4D6090:01C6E640] Authentication-Results: sj-dkim-1.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea2fecb570ff0fcea6acb63c501a031d Charles, Please see my comments below. -Bob -----Original Message----- From: Charles Clancy [mailto:clancy@cs.umd.edu] Sent: Saturday, September 30, 2006 4:11 PM To: Margaret Wasserman Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations I've reread the thread and reread the relevent portions of 11i. I think my statements before were partially inaccurate. The security and overhead ramifications are not insignificant. We can: 1. Set the KeyRSC to a static value. This increases the risk of replay attacks of multicast/broadcast packets encrypted with the group key between the time the client authenticates and when the first legitimate group key-encrypted packet is transmitted. Bob>> I don't believe that this increases the risk of replay attack. The risk of attack is related to the presence of an attacker and the time between the 4-way handshake and the next multicast frame transmitted by the AP. As long as the possibility exists that the KeyRSC does not match the actual TSC, this attack is feasible. Bob>> It should be noted that "replay" of encrypted/MICed multicast frames is inherent in the design of an 802.11 WLAN that has more than one AP in it. Because the load and availability of transmit opportunities varies with time, location, and channel, it is likely that the STA will encounter a situation where it has received one or more multicast frames from one AP that it will receive again from a second AP that it has just roamed to. The multicast frames at the second AP have been delayed due to that AP having fewer opportunities to transmit, resulting in longer queuing delays for the first transmission of those multicast frames. 2. Periodically transmit the KeyRSC from the WTP to the AC. This would allow for fewer packets to be replayed, but would not completely prevent replay attacks. Probabalistically, it would weaken their effectiveness. The added price is more protocol overhead. 3. Have the WTP request the GTK prior to initiating the 4-way handshake. This would eliminate replay attacks, but add one round trip to the authentication process. This could possibly be optimized by having the WTP detect EAPOL message 1 being sent to the STA, and immediately transmit it to the AC before it needs it for EAPOL message 3. Bob>> The WTP already has the GTK, if it has any STAs associated. There is no need for it to request it from the AC. I am not sure what this would accomplish. Transporting the KCK to the WTP breaks the security model, and should not be considered a viable option. Bob>> Agreed. None of the approaches affect the STA operation, or require any changes to 802.11. Bob>> Agreed. Here's a question: what happens if the newly authenticated STA tries to transmit a GTK-encrypted packet using RSC=0? Would it get dropped? Is this a problem, particularly for protocols such as DHCP? Bob>> The STA cannot transmit on the GTK, this is not allowed by 802.11. Any frame sent to a multicast destination in 802.11 by an associated STA must be sent directly to the AP, encrypted on the PTK, where it is then decrypted and forwarded (both to the wire and to the BSS encrypted on the GTK) as a multicast frame. Only the frame from the AP will be encrypted on the GTK. All STAs are required to drop any frames addressed to them that are not sent from the AP, when associated to an AP. This is done prior to checking MIC or decrypting the frame. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Sat, September 30, 2006 12:00 pm, Margaret Wasserman wrote: > > > Could one of you explain to me what the implications would be of the > AC always using an RSC value of 0 to compute the MIC in message 3 of > the 4-way handshake? > > Would this reduce/eliminate the value of the RSC as a security > mechanism? Does it imply something about how the WTP needs to > behave? Something about how the supplicant needs to behave? > > Thanks, > Margaret > > > On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote: > >> To be fair, one option requires that message 3 be created, and >> encrypted, in the WTP. This implies that encryption and authentication >> keys required to formulate message 3 be sent to the WTP. >> >> Seems to me simpler to include text that either states the value of >> zero >> is always used (simplest), or some configurable value be sent to >> the WTP >> (simpler). >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>> Sent: Friday, September 29, 2006 12:07 PM >>> To: Cheng Hong >>> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun >>> (pacalhou); Peter Nilsson J (LI/EAB); capwap@frascone.com; >>> Saravanan Govindan >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> All, >>> >>> I'm glad to see we're finally arguing about the right issue. >>> As discussed, the Cisco solution to the problem is "set it to zero". >>> Certainly sniffing the value works as well. From a security >>> standpoint either is just fine. >>> >>> We do have an interoperability issue, however, if a Cisco WTP >>> were used with an AC that's randomly generating a KeyRSC and >>> expecting the WTP to sniff it. So, I think some text is >>> necessary to address the issue. >>> >>> What remains are two entrenched opinions about protocol >>> flexibility vs simplicity, neither of which would >>> significantly tilt the flexibility vs simplicity balance in >>> either of direction. Let's flip a coin and move on to more >>> important issues. >>> >>> -- >>> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >>> >>> On Fri, 29 Sep 2006, Cheng Hong wrote: >>> >>>> Hi Bob, >>>> >>>> As Dorothy correctly pointed out below, setting the KeyRSC >>> to a value >>>> closer to the current RSC would be better than setting it to a >>>> pre-defined value zero. >>>> >>>> It is true that 802.11i and 802.1X do not specify what is the KeyRSC >>>> value to be used, since they are trying to provide us a tool to >>>> correctly synchronize the RSC using the Msg 3. By mandating >>> the KeyRSC >>>> to zero, we are just disabling the tool. It is not wrong, but just >>>> deprives the system a designed function. >>>> >>>> As for the effectiveness of KeyRSC, setting it to a >>> predefined value of >>>> 0 would pose a greater threat. In a simple example, if the RSC is >>>> currently 1000, and we are mandating the KeyRSC to be >>> always zero, the >>>> attacker basically can safely replay the last 1000 packets >>> to the STA >>>> without being detected. If the KeyRSC can be set to a >>> closer value of >>>> the current RSC, say, 900, the number of possible replayed >>> packets can >>>> be reduced to 10 percent, 100 packets. >>>> >>>> Therefore, I would say, setting the KeyRSC value to zero >>> does place a >>>> bigger threat. Is that how the cisco products implemented? Maybe you >>>> could share with us some other implementation/testing data to prove >>>> otherwise. Or, you have some other considerations that >>> could defend the >>>> replay attack? >>>> >>>> cheers >>>> >>>> Cheng Hong >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>> Sent: Friday, September 29, 2006 5:21 AM >>>> To: Dorothy Stanley >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >>> Peter Nilsson >>>> J (LI/EAB); capwap@frascone.com >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> >>>> Dorothy, >>>> >>>> The problem with this proposal is that it is no more effective than >>>> sending a value of zero for the KeyRSC. It doesn't eliminate any >>>> potential attacks. It doesn't add any functionality. >>> However, it does >>>> add cost and complexity to the protocol. >>>> >>>> -Bob >>>> >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Dorothy Stanley [mailto:dstanley1389@gmail.com] >>>> Sent: Thursday, September 28, 2006 1:17 PM >>>> To: Bob O'Hara (boohara) >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; >>> Peter Nilsson >>>> J (LI/EAB); capwap@frascone.com >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> >>>> All, >>>> >>>> Below is the text from 802.11REV-maD8.0 Clause 8.5.2, >>> describing the Key >>>> RSC field.: >>>> >>>> "g) Key RSC. This field is 8 octets in length. It contains >>> the receive >>>> sequence counter (RSC) for the >>>> GTK being installed in IEEE 802.11. It is used in Message 3 >>> of the 4-Way >>>> Handshake and >>>> Message 1 of the Group Key Handshake, where it is used to >>> synchronize >>>> the IEEE 802.11 replay >>>> state. It may also be used in the Michael MIC Failure >>> Report frame, to >>>> report the TSC field value of >>>> the frame experiencing a MIC failure. It shall contain 0 in other >>>> messages. The Key RSC field gives >>>> the current message number for the GTK, to allow a STA to identify >>>> replayed MPDUs. If the Key >>>> RSC field value is less than 8 octets in length, the >>> remaining octets >>>> shall be set to 0. The least significant >>>> octet of the TSC or PN should be in the first octet of the Key RSC >>>> field." >>>> >>>> The intent of adding this value in message 3 was to >>> immediately minimize >>>> the number of >>>> replayed frames that a STA would potentially process: "The >>> Key RSC field >>>> gives >>>> the current message number for the GTK, to allow a STA to identify >>>> replayed MPDUs." >>>> Setting the value to 0 in Msg 3 does not provide the >>> current sequence >>>> counter (in most cases >>>> not even close) of the GTK.. >>>> >>>> Perhaps the WTP could periodically/frequently notify the AC of its >>>> current GTK sequence counter, and the >>>> AC would use the most recently received value in the >>> message 3 sent to >>>> new STAs. The RSC value >>>> would not be up to date at all times, but would be closer >>> than "0", not >>>> require an "in-the-critical-path >>>> message exchange between the AC and WTP, and still be close to the >>>> intended use of the field. >>>> >>>> Dorothy >>>> >>>> >>>> On 9/28/06, Bob O'Hara (boohara) wrote: >>>> >>>> Please understand that 802.11i specifies no behavior in >>> this area for >>>> the 802.1X authenticator. Our choice to send a group key >>> KeyRSC value >>>> of zero in the EAPOL-key frame requires no change to 802.11i or to >>>> 802.1X . It requires us to state this in the CAPWAP spec, >>> if we want >>>> this behavior to be consistent across all implementations. >>>> >>>> The problem with what Bechet and Saranavan are asking is >>> that either of >>>> three different things are required: >>>> 1: the WTP must communicate the group key TSC to the AC >>> every time it is >>>> updated, or >>>> 2: the AC must request the current value of the group key >>> TSC for the >>>> KeyRSC before constructing the EAPOL-key frame, or >>>> 3: the AC must send the KCK to the AC so that it can >>> insert the KeyRSC >>>> value and also calculate the correct MIC, inserting that >>> into the proper >>>> EAPOL-key frame. >>>> >>>> The first item requires a tremendous amount of additional CAPWAP >>>> communication between WTP and AC, at least one new CAPWAP packet for >>>> every multicast frame sent by the WTP, if the packet is not >>>> acknowledged, or two new CAPWAP packets, if it is >>> acknowledged. This is >>>> a very expensive addition to the protocol. >>>> >>>> The second item requires new protocol between the AC and >>> WTP during what >>>> can be a time critical portion of the 802.11 transition >>> (handoff, roam) >>>> from one WTP to another. It also introduces a race >>> condition that is >>>> not present in the protocol today. Once the value for the KeyRSC is >>>> sent from the WTP to the AC, it is possible that the WTP can send >>>> another multicast frame encrypted with the group key. This puts the >>>> value of the sequence counter out of sync with the value >>> that will be >>>> shortly communicated to the client in the EAPOL-key frame >>> from the AC. >>>> This will behave exactly the same as if a value of zero is >>> sent in the >>>> EAPOL-key frame. >>>> >>>> The third item requires a new architecture split that is >>> not required in >>>> >>>> our objectives. The new split is not splitting the MAC, >>> but splitting >>>> the authenticator. Placing the KCK in the WTP is also a potential >>>> reduction in the security of the overall WLAN system, since these >>>> devices are normally not in a secured wiring closet, but exposed and >>>> more easily compromised than the AC. >>>> >>>> The simplest to implement, least expensive, and most secure >>> option is to >>>> use the protocol as it is now specified and have the AC >>> send a value of >>>> zero in the KeyRSC field of the EAPOL-key frame. >>>> >>>> -Bob >>>> >>>> -----Original Message----- >>>> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] >>>> Sent: Wednesday, September 27, 2006 6:50 PM >>>> To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; >>>> Peter Nilsson J (LI/EAB) >>>> Cc: capwap@frascone.com >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> Hi Pat and all, >>>> >>>> So, based on this, I would say that we have consensus that >>> setting the >>>> correct KeyRSC is an issue for the CAPWAP protocol design. >>>> >>>> So far, we have three option/solutions: >>>> >>>> 1) As proposed by Bob: Using a static value (0) for the KeyRSC. >>>> >>>> 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP >>>> >>>> 3) As suggested by Saravanana: Some exchange mechanism >>> between WTP and >>>> AC >>>> >>>> Among the three, the first option seems the easiest. However, it >>>> requires a mandated Authenticator behavior(in this case AC) >>> that is not >>>> mandated by 802.11. Therefore, we have to specify that >>> (e.g. as proposed >>>> by Bob: "We could include a note to the effect that the group KeyRSC >>>> should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, >>>> because otherwise there is no interoperability. For >>> example, AC provided >>>> by another vendor does not have to set KeyRSC to 0 to be >>> compliant with >>>> CAPWAP and 802.11i. >>>> >>>> Another implication is that we don't really understand the impact of >>>> mandating a static KeyRSC value. Although Bob provided an excellent >>>> analysis, I still have some doubts about the profoundness >>> of the impact. >>>> If the KeyRSC value is as described of no use, why would it >>> appear in >>>> the EAPOL frames in the first place? By mandating it to >>> static value, >>>> what have we lost? Maybe some liaison letter to 802.1 or >>> 802.11 could >>>> provide us a better understanding of the issue. >>>> >>>> For the last two options, I think they are both within >>> CAPWAP's scope. >>>> Further analysis could help us to decide which one is better (or >>>> someone could propose other solutions). >>>> >>>> cheers >>>> >>>> Cheng Hong >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] >>>>> Sent: Thursday, September 28, 2006 1:39 AM >>>>> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; >>>>> Peter Nilsson J (LI/EAB) >>>>> Cc: capwap@frascone.com >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>> Considerations >>>>> >>>>> Bob's point is 802.11i works this way today. The AP (or in >>>>> this case AC) can set the RSC to whatever value it wishes. >>>>> Bob used zero (0) as an example. Implementations could use >>>>> any other value, which would require some form of >>>>> communication to the WTP, as suggested by Behcet. >>>>> >>>>> Pat Calhoun >>>>> CTO, Wireless Networking Business Unit >>>>> Cisco Systems >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Cheng Hong [mailto: >>>> Hong.Cheng@sg.panasonic.com] >>>>>> Sent: Tuesday, September 26, 2006 6:03 PM >>>>>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson >>>>> J (LI/EAB) >>>>>> Cc: capwap@frascone.com >>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>> Considerations >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> If I understand your description below correct, you are >>> proposing a >>>>>> solution (to the problem pointed out by >>>>>> Saravanan) by mandating the behavior of the AC to always set the >>>>>> KeyRSC in the 4-way handshake to zero. >>>>>> >>>>>> This is not a defined behavior according to the current >>>>>> 802.11 standard. >>>>>> Are you suggesting that we CAPWAP WG should specifically >>>>> mandate that >>>>>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP >>>>> compatible >>>>>> AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, >>>>>> since not all AC implementation have to follow what you described. >>>>>> >>>>>> Or, are you planning to take this issue to TGm for 802.11 standard >>>>>> revision? (since based on your description, there is >>> essentially no >>>>>> use of the KeyRSC). >>>>>> >>>>>> cheers >>>>>> >>>>>> Cheng Hong >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] >>>>>>> Sent: Wednesday, September 27, 2006 2:32 AM >>>>>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) >>>>>>> Cc: capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>> >>>>>>> Charles, Peter, >>>>>>> >>>>>>> Below is an expansion of a snippet from a thread on this >>>>>> topic that I >>>>>>> sent to the list on July 25, 2006. I think this will be >>>>> helpful to >>>>>>> understand why the exchange that Saranavan is requesting is not >>>>>>> necessary. In fact, there are several systems from several >>>>>>> manufacturers in the field using precursor protocols to >>>>> CAPWAP that >>>>>>> are Wi-Fi certified for WPA2/802.11i operation using the >>>>>> protocol as >>>>>>> it is described below. >>>>>>> >>>>>>> BTW, this whole discussion is about the KeyRSC for the >>>>>> group key, not >>>>>>> the pairwise key. This is so because the WTP and AC both >>>>> know the >>>>>>> initial sequence counter value for the pairwise key, since it has >>>>>>> never been used to send a frame. 802.11i requires the >>>>> first frame >>>>>>> sent on a key to use the sequence counter value of 1. See >>>>>> 8.3.2.6 c) >>>>>>> and >>>>>>> 8.3.3.4.3 c) in 802.11i for this requirement. >>>>>>> >>>>>>> The same is not true of the group key, i.e., after the WTP begins >>>>>>> operation, the AC will not know the value of the sequence >>>>>> counter for >>>>>>> the group key when it needs to complete the EAPOL-key >>>>>> handshake with a >>>>>>> newly associated STA. >>>>>>> However, as you will see from the tutorial below, it is not >>>>>> necessary >>>>>>> for the AC and WTP to exchange any information about the >>>>> group key >>>>>>> KeyRSC for the protocol to operate as it is intended. >>>>>>> >>>>>>> 1. A value for the KeyRSC in the EAPOL-key frame is necessary to >>>>>>> calculate the KeyMIC. >>>>>>> >>>>>>> 2. This value does not need to bear any specific >>>>>> relationship to the >>>>>>> RSC value maintained by the WTP. A value of zero in the >>>>> EAPOL-key >>>>>>> frame for the group key will always work. >>>>>>> >>>>>>> 3. The client STA will use the value of KeyRSC received in the >>>>>>> EAPOL-key frame to validate frame using the KeyMIC. >>>>>>> >>>>>>> 4. The client STA will also set its group key RSC to the value >>>>>>> received in KeyRSC, say, zero. >>>>>>> >>>>>>> 5. The value in the client STA's RSC will be compared against the >>>>>>> sequence number in subsequent received frames to identify replay >>>>>>> attacks. Any frame received with a sequence counter value >>>>>> within the >>>>>>> replay window will be checked to have a valid MIC. If the >>>>>> MIC is not >>>>>>> valid, the frame is dropped. >>>>>>> >>>>>>> 6. For any frame that is determined not to be a replay >>>>> attack frame >>>>>>> and meets all other validity and authenticity requirements, >>>>>> the client >>>>>>> STA updates its RSC value to the sequence number in the received >>>>>>> frame, if the value is greater than its current RSC value. >>>>>> Only the >>>>>>> AP can meet these criteria as the source of a frame >>>>> received by the >>>>>>> STA. >>>>>>> >>>>>>> 7. Please see item 6, immediately above, for the reason >>>>> that the AC >>>>>>> and WTP do not need to coordinate and exchange the RSC. >>>>>>> >>>>>>> >>>>>>> The only possible attack mode is for the attacker to send >>>>> frames to >>>>>>> the client STA between the time of the EAPOL-key frame and >>>>>> the first >>>>>>> frame encrypted with the group key. >>>>>>> During this time, the client will receive the frame and >>>>> proceed to >>>>>>> validate its MIC. This is a potential attack against the STA >>>>>>> resources. But, the MIC validation is done in the STA's >>>>>>> 802.11 chip and consumes no more resources than receiving >>>>> any other >>>>>>> frame. Thus, the attack does not actually consume any STA >>>>>> resources >>>>>>> beyond those of receiving a frame. >>>>>>> >>>>>>> This attack is not unique to the use of the value zero for >>>>>> the KeyRSC, >>>>>>> either. The same attack is available to an attacker at any other >>>>>>> time, as well. It is no more nor less effective at either time. >>>>>>> >>>>>>> For these reasons, the protocol is not in need of any changes to >>>>>>> address the issue raised by Saranavan. >>>>>>> >>>>>>> -Bob >>>>>>> -----Original Message----- >>>>>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] >>>>>>> Sent: Monday, September 25, 2006 11:37 AM >>>>>>> To: Peter Nilsson J (LI/EAB) >>>>>>> Cc: capwap@frascone.com >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>> >>>>>>> This is a very interesting solution. The AC selects the >>>>> KeyRSC and >>>>>>> performs the 4-way handshake. The WTP sniffs the 4-way handshake >>>>>>> traffic and grabs the KeyRSC value and uses it to >>>>>> initialize its own >>>>>>> counter. >>>>>>> >>>>>>> Pat/Bob: Is this how the Cisco implementation works? I >>>>>> have to agree >>>>>>> with Saravanan that I've yet to see a technical >>>>> description of how >>>>>>> Cisco implements it. >>>>>>> >>>>>>> IMHO, this is somewhat hackish, and it would be cleaner to >>>>>> have the AC >>>>>>> generate the KeyRSC and include it in the AddMobile message >>>>>> as Behcet >>>>>>> suggests. >>>>>>> >>>>>>> -- >>>>>>> t. charles clancy, ph.d. | tcc@umd.edu | >>>>> www.cs.umd.edu/~clancy >>>>>>> >>>>>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: >>>>>>> >>>>>>>> I think Saravanan has a point. We did a prototype >>>>>> impelementation of >>>>>>> the >>>>>>>> protocol a year ago when it was still called LWAPP. The way >>>>>>> we solved >>>>>>>> this issue then was to let the WTP sniff on all CAPWAP data >>>>>>> messages >>>>>>>> from the AC and when message 3 of the 4-way handshake or >>>>>>> message 1 of >>>>>>>> the groupkey handshake was sent the WTP inserted the correct RSC >>>>>>> before >>>>>>>> sending it off to the supplicant. To avoid the sniffing on >>>>>>> all CAPWAP >>>>>>>> data messages we would need a mechanism with in CAPWAP to >>>>>>> handle these >>>>>>>> two messages. >>>>>>>> >>>>>>>> Peter Nilsson >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Saravanan Govindan >>>>>>> [mailto:Saravanan.Govindan@sg.panasonic.com] >>>>>>>> Sent: den 22 september 2006 11:03 >>>>>>>> To: Margaret Wasserman >>>>>>>> Cc: capwap@frascone.com >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>>> >>>>>>>> Hi Margaret, >>>>>>>> >>>>>>>> Thank you for reviewing the discussion on this issue. >>>>>>>> >>>>>>>> The issue here is the working of IEEE 802.11i when the 802.11i >>>>>>>> authenticator element is at the AC and the 802.11i crypto >>>>>> element is >>>>>>> at >>>>>>>> the WTP. Particularly, it is for the 4-way handshake between >>>>>>>> authenticator and supplicant. >>>>>>>> >>>>>>>> Now, the 4-way handshake requires knowing the value of >>>>>>> KeyRSC sequence >>>>>>>> counter. The KeyRSC helps both authenticator and supplicant >>>>>>> keep track >>>>>>>> of their exchanges. It serves to protect against threats by >>>>>>> tracking >>>>>>>> sequential frames. The KeyRSC is maintained at the at the >>>>>> point of >>>>>>>> encryption, i.e. just before transmission over the >>>>>> wireless channel. >>>>>>>> >>>>>>>> In the case of CAPWAP, the 4-way handshake is between the AC >>>>>>>> (authenticator) and the wireless station (supplicant). >>>>>>>> >>>>>>>> The problem arises, when the authenticator is at the AC and >>>>>>> the crypto >>>>>>>> element (together with KeyRSC) is at the WTP. This is a >>>>>>> fairly common >>>>>>>> design. Now in this case, the AC starts the 4-way >>>>> handshake but it >>>>>>> does >>>>>>>> not know the value of the KeyRSC. The KeyRSC is maintained >>>>>>> by the WTP. >>>>>>>> >>>>>>>> Based on this, the current CAPWAP specification does not >>>>>> allow for a >>>>>>> way >>>>>>>> to conduct the 4-way handshake with the correct KeyRSC. >>>>>>>> >>>>>>>> The functionality I would like to see is a way for the >>>>>> authenticator >>>>>>>> (AC) to use the correct prevailing value of KeyRSC >>>>>>> (maintained by the >>>>>>>> WTP) in its 4-way handshake. >>>>>>>> >>>>>>>> One way to introduce this functionality in to CAPWAP is >>>>>> to have part >>>>>>> of >>>>>>>> the 4-way handshake be sent from AC to WTP. This will allow >>>>>>> the 4-way >>>>>>>> handshake to use the correct value of the KeyRSC before >>>>>>> being sent to >>>>>>>> the wireless station. >>>>>>>> >>>>>>>> I hope this helps clarify my view on the issue. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Saravanan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>>>>>>> Sent: Thursday, September 21, 2006 8:26 PM >>>>>>>> To: Saravanan Govindan >>>>>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>>>>> Considerations >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Okay, I am even more confused than I thought I was... >>>>>>>> >>>>>>>> Saravanan, you wrote: >>>>>>>> >>>>>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: >>>>>>>> >>>>>>>>> Pat, >>>>>>>>> >>>>>>>>> The issue here is about how 802.11i exchanges are done when >>>>>>>>> authenticator is at the AC and crypto elements are at >>>>>> the WTP. This >>>>>>> is >>>>>>>>> the requirement. >>>>>>>> >>>>>>>> And, in response, Pat Calhoun wrote: >>>>>>>> >>>>>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: >>>>>>>>> The current specification allows the authenticator to >>>>>>> reside in the >>>>>>>>> AC, while the data packet crypto elements in the WTP. This >>>>>>> feature is >>>>>>>>> already in the specification. >>>>>>>> >>>>>>>> Pat's message matches my reading of the specification. >>>>>>>> >>>>>>>> So, Saravanan, what functionality are you asking for >>>>> that is not >>>>>>>> already supported by the specification? And why do you >>>>>> think it is >>>>>>>> necessary? it will not be helpful to my understanding to >>>>>>> re-send your >>>>>>>> proposal or to cite the requirements document... Please >>>>>> summarize >>>>>>>> what functionality you think is missing from the current >>>>>>> specification >>>>>>>> and why you think that functionality is necessary to >>>>> support IEEE >>>>>>>> 802.11i or any important use case. >>>>>>>> >>>>>>>> At some point, the chairs may need to make a consensus >>>>>> call on this >>>>>>>> issue, and I'd like to understand your view and make sure >>>>>>> that it has >>>>>>>> been clearly communicated to the WG before we ask the WG to >>>>>>> decide on >>>>>>>> this issue. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Margaret >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> _________________________________________________________________ >>>>>>>> To unsubscribe or modify your subscription options, >>>>> please visit: >>>>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>>>>>> >>>>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>>>> >>>>> _________________________________________________________________ >>>>>>>> To unsubscribe or modify your subscription options, >>>>> please visit: >>>>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>>>>>> >>>>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> To unsubscribe or modify your subscription options, please visit: >>>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>>>> >>>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>>> _________________________________________________________________ >>>>>>> To unsubscribe or modify your subscription options, please visit: >>>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>>>> >>>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>>>> >>>>>> _________________________________________________________________ >>>>>> To unsubscribe or modify your subscription options, please visit: >>>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>>> >>>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>>>>> >>>>> _________________________________________________________________ >>>>> To unsubscribe or modify your subscription options, please visit: >>>>> http://lists.frascone.com/mailman/listinfo/capwap >>>>> >>>>> Archives: http://lists.frascone.com/pipermail/capwap >>>>> >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>>> >>>> >>>> >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 02 22:06:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUZfm-0001F3-Kw for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 22:06:18 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUZfj-0006Ec-3X for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 22:06:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A08491448012 for ; Mon, 2 Oct 2006 19:06:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E4AE14300EA for ; Mon, 2 Oct 2006 18:54:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CA5E9398021 for ; Mon, 2 Oct 2006 18:54:36 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9FD7B398097 for ; Mon, 2 Oct 2006 18:54:32 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k931rMZa006998; Tue, 3 Oct 2006 10:53:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k931rM106772; Tue, 3 Oct 2006 10:53:22 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id k931rJ328576; Tue, 3 Oct 2006 10:53:20 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Oct 2006 09:49:15 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F23AE@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbk5dk/jHe9QPtjQ1ebZ0mRqvN5zQBWHskAABK2g9A= From: "Cheng Hong" To: "Bob O'Hara (boohara)" , "Charles Clancy" , "Margaret Wasserman" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ed7d9c7c8d25b2053aac33a860e1606d Dear all, Some comments below: cheers Cheng Hong > Bob>> I don't believe that this increases the risk of replay attack. > The risk of attack is related to the presence of an attacker > and the time between the 4-way handshake and the next > multicast frame transmitted by the AP. As long as the > possibility exists that the KeyRSC does not match the actual > TSC, this attack is feasible. As already discussed in previous emails, unless the KeyRSC follows the exact RSC value, there could be possible replay attacks. However, setting the KeyRSC to a static value does make things worse, since it opens the possibility for the attacker to replay any previous frames. Repeat the same example: Setting KeyRSC to 0 allows 1000 frames to be replayed, and setting KeyRSC to a value close to 1000, say 900, will reduce the possible replay frames to 100. The risk is not measured with the "time between the 4-way handshake and the next multicast frame transmitted by the AP". By looking at the sheer number of possible replayed frames, the risk is increased by setting KeyRSC to a static value 0. > Bob>> It should be noted that "replay" of encrypted/MICed multicast > frames is inherent in the design of an 802.11 WLAN that has > more than one AP in it. Because the load and availability of > transmit opportunities varies with time, location, and > channel, it is likely that the STA will encounter a situation > where it has received one or more multicast frames from one > AP that it will receive again from a second AP that it has > just roamed to. The multicast frames at the second AP have > been delayed due to that AP having fewer opportunities to > transmit, resulting in longer queuing delays for the first > transmission of those multicast frames. As already pointed out in several emails, the RSC is maintained per GTKSA. So, if the different APs are using different GTK, different RSCs will be used. Not issue exists, since the frames from different APs are checked against different TSC space (suppose TKIP is used as stated in clause 8.3.2.6). Even in the case that all the APs are sharing the same GTK, the procedure defined in clause 8.3.2.6 will be carried out at STA. Duplicated frames will be dropped. There is no place showing the "replay" is "inherent in the design of an 802.11 WLAN that has more than one AP in it". > -----Original Message----- > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > Sent: Tuesday, October 03, 2006 12:37 AM > To: Charles Clancy; Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Charles, > > Please see my comments below. > > -Bob > > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Saturday, September 30, 2006 4:11 PM > To: Margaret Wasserman > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > I've reread the thread and reread the relevent portions of > 11i. I think my statements before were partially inaccurate. > The security and overhead ramifications are not insignificant. > > We can: > > 1. Set the KeyRSC to a static value. This increases the risk > of replay attacks of multicast/broadcast packets encrypted > with the group key between the time the client authenticates > and when the first legitimate group key-encrypted packet is > transmitted. > > Bob>> I don't believe that this increases the risk of replay attack. > The risk of attack is related to the presence of an attacker > and the time between the 4-way handshake and the next > multicast frame transmitted by the AP. As long as the > possibility exists that the KeyRSC does not match the actual > TSC, this attack is feasible. > > Bob>> It should be noted that "replay" of encrypted/MICed multicast > frames is inherent in the design of an 802.11 WLAN that has > more than one AP in it. Because the load and availability of > transmit opportunities varies with time, location, and > channel, it is likely that the STA will encounter a situation > where it has received one or more multicast frames from one > AP that it will receive again from a second AP that it has > just roamed to. The multicast frames at the second AP have > been delayed due to that AP having fewer opportunities to > transmit, resulting in longer queuing delays for the first > transmission of those multicast frames. > > 2. Periodically transmit the KeyRSC from the WTP to the AC. > This would allow for fewer packets to be replayed, but would > not completely prevent replay attacks. Probabalistically, it > would weaken their effectiveness. > > The added price is more protocol overhead. > > 3. Have the WTP request the GTK prior to initiating the 4-way > handshake. > > This would eliminate replay attacks, but add one round trip > to the authentication process. This could possibly be > optimized by having the WTP detect EAPOL message 1 being sent > to the STA, and immediately transmit it to the AC before it > needs it for EAPOL message 3. > > Bob>> The WTP already has the GTK, if it has any STAs > associated. There > is no need for it to request it from the AC. I am not sure > what this would accomplish. > > Transporting the KCK to the WTP breaks the security model, > and should not be considered a viable option. > > Bob>> Agreed. > > None of the approaches affect the STA operation, or require > any changes to 802.11. > > Bob>> Agreed. > > Here's a question: what happens if the newly authenticated > STA tries to transmit a GTK-encrypted packet using RSC=0? > Would it get dropped? Is this a problem, particularly for > protocols such as DHCP? > > Bob>> The STA cannot transmit on the GTK, this is not allowed > by 802.11. > Any frame sent to a multicast destination in 802.11 by an > associated STA must be sent directly to the AP, encrypted on > the PTK, where it is then decrypted and forwarded (both to > the wire and to the BSS encrypted on the GTK) as a multicast > frame. Only the frame from the AP will be encrypted on the > GTK. All STAs are required to drop any frames addressed to > them that are not sent from the AP, when associated to an AP. > This is done prior to checking MIC or decrypting the frame. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > On Sat, September 30, 2006 12:00 pm, Margaret Wasserman wrote: > > > > > > Could one of you explain to me what the implications would > be of the > > AC always using an RSC value of 0 to compute the MIC in > message 3 of > > the 4-way handshake? > > > > Would this reduce/eliminate the value of the RSC as a security > > mechanism? Does it imply something about how the WTP needs > to behave? > > Something about how the supplicant needs to behave? > > > > Thanks, > > Margaret > > > > > > On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote: > > > >> To be fair, one option requires that message 3 be created, and > >> encrypted, in the WTP. This implies that encryption and > authentication > >> keys required to formulate message 3 be sent to the WTP. > >> > >> Seems to me simpler to include text that either states the > value of > >> zero is always used (simplest), or some configurable value > be sent to > >> the WTP (simpler). > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit Cisco Systems > >> > >> > >> > >>> -----Original Message----- > >>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > >>> Sent: Friday, September 29, 2006 12:07 PM > >>> To: Cheng Hong > >>> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun > >>> (pacalhou); Peter Nilsson J (LI/EAB); capwap@frascone.com; > >>> Saravanan Govindan > >>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>> > >>> All, > >>> > >>> I'm glad to see we're finally arguing about the right issue. > >>> As discussed, the Cisco solution to the problem is "set > it to zero". > >>> Certainly sniffing the value works as well. From a security > >>> standpoint either is just fine. > >>> > >>> We do have an interoperability issue, however, if a Cisco WTP > >>> were used with an AC that's randomly generating a KeyRSC and > >>> expecting the WTP to sniff it. So, I think some text is > >>> necessary to address the issue. > >>> > >>> What remains are two entrenched opinions about protocol > >>> flexibility vs simplicity, neither of which would > >>> significantly tilt the flexibility vs simplicity balance in > >>> either of direction. Let's flip a coin and move on to more > >>> important issues. > >>> > >>> -- > >>> t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > >>> > >>> On Fri, 29 Sep 2006, Cheng Hong wrote: > >>> > >>>> Hi Bob, > >>>> > >>>> As Dorothy correctly pointed out below, setting the KeyRSC > >>> to a value > >>>> closer to the current RSC would be better than setting it to a > >>>> pre-defined value zero. > >>>> > >>>> It is true that 802.11i and 802.1X do not specify what is the > KeyRSC > >>>> value to be used, since they are trying to provide us a tool to > >>>> correctly synchronize the RSC using the Msg 3. By mandating > >>> the KeyRSC > >>>> to zero, we are just disabling the tool. It is not > wrong, but just > >>>> deprives the system a designed function. > >>>> > >>>> As for the effectiveness of KeyRSC, setting it to a > >>> predefined value of > >>>> 0 would pose a greater threat. In a simple example, if the RSC is > >>>> currently 1000, and we are mandating the KeyRSC to be > >>> always zero, the > >>>> attacker basically can safely replay the last 1000 packets > >>> to the STA > >>>> without being detected. If the KeyRSC can be set to a > >>> closer value of > >>>> the current RSC, say, 900, the number of possible replayed > >>> packets can > >>>> be reduced to 10 percent, 100 packets. > >>>> > >>>> Therefore, I would say, setting the KeyRSC value to zero > >>> does place a > >>>> bigger threat. Is that how the cisco products implemented? Maybe > you > >>>> could share with us some other implementation/testing > data to prove > >>>> otherwise. Or, you have some other considerations that > >>> could defend the > >>>> replay attack? > >>>> > >>>> cheers > >>>> > >>>> Cheng Hong > >>>> > >>>> > >>>> > >>>> _____ > >>>> > >>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > >>>> Sent: Friday, September 29, 2006 5:21 AM > >>>> To: Dorothy Stanley > >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; > >>> Peter Nilsson > >>>> J (LI/EAB); capwap@frascone.com > >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>>> > >>>> > >>>> Dorothy, > >>>> > >>>> The problem with this proposal is that it is no more > effective than > >>>> sending a value of zero for the KeyRSC. It doesn't eliminate any > >>>> potential attacks. It doesn't add any functionality. > >>> However, it does > >>>> add cost and complexity to the protocol. > >>>> > >>>> -Bob > >>>> > >>>> > >>>> > >>>> > >>>> _____ > >>>> > >>>> From: Dorothy Stanley [mailto:dstanley1389@gmail.com] > >>>> Sent: Thursday, September 28, 2006 1:17 PM > >>>> To: Bob O'Hara (boohara) > >>>> Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; > >>> Peter Nilsson > >>>> J (LI/EAB); capwap@frascone.com > >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>>> > >>>> > >>>> All, > >>>> > >>>> Below is the text from 802.11REV-maD8.0 Clause 8.5.2, > >>> describing the Key > >>>> RSC field.: > >>>> > >>>> "g) Key RSC. This field is 8 octets in length. It contains > >>> the receive > >>>> sequence counter (RSC) for the > >>>> GTK being installed in IEEE 802.11. It is used in Message 3 > >>> of the 4-Way > >>>> Handshake and > >>>> Message 1 of the Group Key Handshake, where it is used to > >>> synchronize > >>>> the IEEE 802.11 replay > >>>> state. It may also be used in the Michael MIC Failure > >>> Report frame, to > >>>> report the TSC field value of > >>>> the frame experiencing a MIC failure. It shall contain 0 in other > >>>> messages. The Key RSC field gives > >>>> the current message number for the GTK, to allow a STA > to identify > >>>> replayed MPDUs. If the Key > >>>> RSC field value is less than 8 octets in length, the > >>> remaining octets > >>>> shall be set to 0. The least significant > >>>> octet of the TSC or PN should be in the first octet of > the Key RSC > >>>> field." > >>>> > >>>> The intent of adding this value in message 3 was to > >>> immediately minimize > >>>> the number of > >>>> replayed frames that a STA would potentially process: "The > >>> Key RSC field > >>>> gives > >>>> the current message number for the GTK, to allow a STA > to identify > >>>> replayed MPDUs." > >>>> Setting the value to 0 in Msg 3 does not provide the > >>> current sequence > >>>> counter (in most cases > >>>> not even close) of the GTK.. > >>>> > >>>> Perhaps the WTP could periodically/frequently notify the > AC of its > >>>> current GTK sequence counter, and the > >>>> AC would use the most recently received value in the > >>> message 3 sent to > >>>> new STAs. The RSC value > >>>> would not be up to date at all times, but would be closer > >>> than "0", not > >>>> require an "in-the-critical-path > >>>> message exchange between the AC and WTP, and still be > close to the > >>>> intended use of the field. > >>>> > >>>> Dorothy > >>>> > >>>> > >>>> On 9/28/06, Bob O'Hara (boohara) wrote: > >>>> > >>>> Please understand that 802.11i specifies no behavior in > >>> this area for > >>>> the 802.1X authenticator. Our choice to send a group key > >>> KeyRSC value > >>>> of zero in the EAPOL-key frame requires no change to > 802.11i or to > >>>> 802.1X . It requires us to state this in the CAPWAP spec, > >>> if we want > >>>> this behavior to be consistent across all implementations. > >>>> > >>>> The problem with what Bechet and Saranavan are asking is > >>> that either of > >>>> three different things are required: > >>>> 1: the WTP must communicate the group key TSC to the AC > >>> every time it is > >>>> updated, or > >>>> 2: the AC must request the current value of the group key > >>> TSC for the > >>>> KeyRSC before constructing the EAPOL-key frame, or > >>>> 3: the AC must send the KCK to the AC so that it can > >>> insert the KeyRSC > >>>> value and also calculate the correct MIC, inserting that > >>> into the proper > >>>> EAPOL-key frame. > >>>> > >>>> The first item requires a tremendous amount of additional CAPWAP > >>>> communication between WTP and AC, at least one new CAPWAP packet > for > >>>> every multicast frame sent by the WTP, if the packet is not > >>>> acknowledged, or two new CAPWAP packets, if it is > >>> acknowledged. This is > >>>> a very expensive addition to the protocol. > >>>> > >>>> The second item requires new protocol between the AC and > >>> WTP during what > >>>> can be a time critical portion of the 802.11 transition > >>> (handoff, roam) > >>>> from one WTP to another. It also introduces a race > >>> condition that is > >>>> not present in the protocol today. Once the value for the KeyRSC > is > >>>> sent from the WTP to the AC, it is possible that the WTP can send > >>>> another multicast frame encrypted with the group key. This puts > the > >>>> value of the sequence counter out of sync with the value > >>> that will be > >>>> shortly communicated to the client in the EAPOL-key frame > >>> from the AC. > >>>> This will behave exactly the same as if a value of zero is > >>> sent in the > >>>> EAPOL-key frame. > >>>> > >>>> The third item requires a new architecture split that is > >>> not required in > >>>> > >>>> our objectives. The new split is not splitting the MAC, > >>> but splitting > >>>> the authenticator. Placing the KCK in the WTP is also a > potential > >>>> reduction in the security of the overall WLAN system, since these > >>>> devices are normally not in a secured wiring closet, but exposed > and > >>>> more easily compromised than the AC. > >>>> > >>>> The simplest to implement, least expensive, and most secure > >>> option is to > >>>> use the protocol as it is now specified and have the AC > >>> send a value of > >>>> zero in the KeyRSC field of the EAPOL-key frame. > >>>> > >>>> -Bob > >>>> > >>>> -----Original Message----- > >>>> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > >>>> Sent: Wednesday, September 27, 2006 6:50 PM > >>>> To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles > Clancy; > >>>> Peter Nilsson J (LI/EAB) > >>>> Cc: capwap@frascone.com > >>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>>> > >>>> Hi Pat and all, > >>>> > >>>> So, based on this, I would say that we have consensus that > >>> setting the > >>>> correct KeyRSC is an issue for the CAPWAP protocol design. > >>>> > >>>> So far, we have three option/solutions: > >>>> > >>>> 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > >>>> > >>>> 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > >>>> > >>>> 3) As suggested by Saravanana: Some exchange mechanism > >>> between WTP and > >>>> AC > >>>> > >>>> Among the three, the first option seems the easiest. However, it > >>>> requires a mandated Authenticator behavior(in this case AC) > >>> that is not > >>>> mandated by 802.11. Therefore, we have to specify that > >>> (e.g. as proposed > >>>> by Bob: "We could include a note to the effect that the group > KeyRSC > >>>> should be zero in the EAPOL-key frame.") either in CAPWAP or > 802.11, > >>>> because otherwise there is no interoperability. For > >>> example, AC provided > >>>> by another vendor does not have to set KeyRSC to 0 to be > >>> compliant with > >>>> CAPWAP and 802.11i. > >>>> > >>>> Another implication is that we don't really understand the impact > of > >>>> mandating a static KeyRSC value. Although Bob provided > an excellent > >>>> analysis, I still have some doubts about the profoundness > >>> of the impact. > >>>> If the KeyRSC value is as described of no use, why would it > >>> appear in > >>>> the EAPOL frames in the first place? By mandating it to > >>> static value, > >>>> what have we lost? Maybe some liaison letter to 802.1 or > >>> 802.11 could > >>>> provide us a better understanding of the issue. > >>>> > >>>> For the last two options, I think they are both within > >>> CAPWAP's scope. > >>>> Further analysis could help us to decide which one is better (or > >>>> someone could propose other solutions). > >>>> > >>>> cheers > >>>> > >>>> Cheng Hong > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > >>>>> Sent: Thursday, September 28, 2006 1:39 AM > >>>>> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > >>>>> Peter Nilsson J (LI/EAB) > >>>>> Cc: capwap@frascone.com > >>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>> Considerations > >>>>> > >>>>> Bob's point is 802.11i works this way today. The AP (or in > >>>>> this case AC) can set the RSC to whatever value it wishes. > >>>>> Bob used zero (0) as an example. Implementations could use > >>>>> any other value, which would require some form of > >>>>> communication to the WTP, as suggested by Behcet. > >>>>> > >>>>> Pat Calhoun > >>>>> CTO, Wireless Networking Business Unit > >>>>> Cisco Systems > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Cheng Hong [mailto: > >>>> Hong.Cheng@sg.panasonic.com] > >>>>>> Sent: Tuesday, September 26, 2006 6:03 PM > >>>>>> To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > >>>>> J (LI/EAB) > >>>>>> Cc: capwap@frascone.com > >>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>>> Considerations > >>>>>> > >>>>>> Hi Bob, > >>>>>> > >>>>>> If I understand your description below correct, you are > >>> proposing a > >>>>>> solution (to the problem pointed out by > >>>>>> Saravanan) by mandating the behavior of the AC to > always set the > >>>>>> KeyRSC in the 4-way handshake to zero. > >>>>>> > >>>>>> This is not a defined behavior according to the current > >>>>>> 802.11 standard. > >>>>>> Are you suggesting that we CAPWAP WG should specifically > >>>>> mandate that > >>>>>> in our CAPWAP protocol spec, e.g. something like "a CAPWAP > >>>>> compatible > >>>>>> AC MUST set KeyRSC to zero"? Otherwise, the problem > still exists, > >>>>>> since not all AC implementation have to follow what you > described. > >>>>>> > >>>>>> Or, are you planning to take this issue to TGm for 802.11 > standard > >>>>>> revision? (since based on your description, there is > >>> essentially no > >>>>>> use of the KeyRSC). > >>>>>> > >>>>>> cheers > >>>>>> > >>>>>> Cheng Hong > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > >>>>>>> Sent: Wednesday, September 27, 2006 2:32 AM > >>>>>>> To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > >>>>>>> Cc: capwap@frascone.com > >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>>>> Considerations > >>>>>>> > >>>>>>> Charles, Peter, > >>>>>>> > >>>>>>> Below is an expansion of a snippet from a thread on this > >>>>>> topic that I > >>>>>>> sent to the list on July 25, 2006. I think this will be > >>>>> helpful to > >>>>>>> understand why the exchange that Saranavan is > requesting is not > >>>>>>> necessary. In fact, there are several systems from several > >>>>>>> manufacturers in the field using precursor protocols to > >>>>> CAPWAP that > >>>>>>> are Wi-Fi certified for WPA2/802.11i operation using the > >>>>>> protocol as > >>>>>>> it is described below. > >>>>>>> > >>>>>>> BTW, this whole discussion is about the KeyRSC for the > >>>>>> group key, not > >>>>>>> the pairwise key. This is so because the WTP and AC both > >>>>> know the > >>>>>>> initial sequence counter value for the pairwise key, since it > has > >>>>>>> never been used to send a frame. 802.11i requires the > >>>>> first frame > >>>>>>> sent on a key to use the sequence counter value of 1. See > >>>>>> 8.3.2.6 c) > >>>>>>> and > >>>>>>> 8.3.3.4.3 c) in 802.11i for this requirement. > >>>>>>> > >>>>>>> The same is not true of the group key, i.e., after the WTP > begins > >>>>>>> operation, the AC will not know the value of the sequence > >>>>>> counter for > >>>>>>> the group key when it needs to complete the EAPOL-key > >>>>>> handshake with a > >>>>>>> newly associated STA. > >>>>>>> However, as you will see from the tutorial below, it is not > >>>>>> necessary > >>>>>>> for the AC and WTP to exchange any information about the > >>>>> group key > >>>>>>> KeyRSC for the protocol to operate as it is intended. > >>>>>>> > >>>>>>> 1. A value for the KeyRSC in the EAPOL-key frame is > necessary to > >>>>>>> calculate the KeyMIC. > >>>>>>> > >>>>>>> 2. This value does not need to bear any specific > >>>>>> relationship to the > >>>>>>> RSC value maintained by the WTP. A value of zero in the > >>>>> EAPOL-key > >>>>>>> frame for the group key will always work. > >>>>>>> > >>>>>>> 3. The client STA will use the value of KeyRSC received in the > >>>>>>> EAPOL-key frame to validate frame using the KeyMIC. > >>>>>>> > >>>>>>> 4. The client STA will also set its group key RSC to the value > >>>>>>> received in KeyRSC, say, zero. > >>>>>>> > >>>>>>> 5. The value in the client STA's RSC will be compared against > the > >>>>>>> sequence number in subsequent received frames to > identify replay > >>>>>>> attacks. Any frame received with a sequence counter value > >>>>>> within the > >>>>>>> replay window will be checked to have a valid MIC. If the > >>>>>> MIC is not > >>>>>>> valid, the frame is dropped. > >>>>>>> > >>>>>>> 6. For any frame that is determined not to be a replay > >>>>> attack frame > >>>>>>> and meets all other validity and authenticity requirements, > >>>>>> the client > >>>>>>> STA updates its RSC value to the sequence number in > the received > >>>>>>> frame, if the value is greater than its current RSC value. > >>>>>> Only the > >>>>>>> AP can meet these criteria as the source of a frame > >>>>> received by the > >>>>>>> STA. > >>>>>>> > >>>>>>> 7. Please see item 6, immediately above, for the reason > >>>>> that the AC > >>>>>>> and WTP do not need to coordinate and exchange the RSC. > >>>>>>> > >>>>>>> > >>>>>>> The only possible attack mode is for the attacker to send > >>>>> frames to > >>>>>>> the client STA between the time of the EAPOL-key frame and > >>>>>> the first > >>>>>>> frame encrypted with the group key. > >>>>>>> During this time, the client will receive the frame and > >>>>> proceed to > >>>>>>> validate its MIC. This is a potential attack against the STA > >>>>>>> resources. But, the MIC validation is done in the STA's > >>>>>>> 802.11 chip and consumes no more resources than receiving > >>>>> any other > >>>>>>> frame. Thus, the attack does not actually consume any STA > >>>>>> resources > >>>>>>> beyond those of receiving a frame. > >>>>>>> > >>>>>>> This attack is not unique to the use of the value zero for > >>>>>> the KeyRSC, > >>>>>>> either. The same attack is available to an attacker at any > other > >>>>>>> time, as well. It is no more nor less effective at > either time. > >>>>>>> > >>>>>>> For these reasons, the protocol is not in need of any > changes to > >>>>>>> address the issue raised by Saranavan. > >>>>>>> > >>>>>>> -Bob > >>>>>>> -----Original Message----- > >>>>>>> From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > >>>>>>> Sent: Monday, September 25, 2006 11:37 AM > >>>>>>> To: Peter Nilsson J (LI/EAB) > >>>>>>> Cc: capwap@frascone.com > >>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>>>> Considerations > >>>>>>> > >>>>>>> This is a very interesting solution. The AC selects the > >>>>> KeyRSC and > >>>>>>> performs the 4-way handshake. The WTP sniffs the 4-way > handshake > >>>>>>> traffic and grabs the KeyRSC value and uses it to > >>>>>> initialize its own > >>>>>>> counter. > >>>>>>> > >>>>>>> Pat/Bob: Is this how the Cisco implementation works? I > >>>>>> have to agree > >>>>>>> with Saravanan that I've yet to see a technical > >>>>> description of how > >>>>>>> Cisco implements it. > >>>>>>> > >>>>>>> IMHO, this is somewhat hackish, and it would be cleaner to > >>>>>> have the AC > >>>>>>> generate the KeyRSC and include it in the AddMobile message > >>>>>> as Behcet > >>>>>>> suggests. > >>>>>>> > >>>>>>> -- > >>>>>>> t. charles clancy, ph.d. | tcc@umd.edu | > >>>>> www.cs.umd.edu/~clancy > >>>>>>> > >>>>>>> On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > >>>>>>> > >>>>>>>> I think Saravanan has a point. We did a prototype > >>>>>> impelementation of > >>>>>>> the > >>>>>>>> protocol a year ago when it was still called LWAPP. The way > >>>>>>> we solved > >>>>>>>> this issue then was to let the WTP sniff on all CAPWAP data > >>>>>>> messages > >>>>>>>> from the AC and when message 3 of the 4-way handshake or > >>>>>>> message 1 of > >>>>>>>> the groupkey handshake was sent the WTP inserted the correct > RSC > >>>>>>> before > >>>>>>>> sending it off to the supplicant. To avoid the sniffing on > >>>>>>> all CAPWAP > >>>>>>>> data messages we would need a mechanism with in CAPWAP to > >>>>>>> handle these > >>>>>>>> two messages. > >>>>>>>> > >>>>>>>> Peter Nilsson > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Saravanan Govindan > >>>>>>> [mailto:Saravanan.Govindan@sg.panasonic.com] > >>>>>>>> Sent: den 22 september 2006 11:03 > >>>>>>>> To: Margaret Wasserman > >>>>>>>> Cc: capwap@frascone.com > >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>>>> Considerations > >>>>>>>> > >>>>>>>> Hi Margaret, > >>>>>>>> > >>>>>>>> Thank you for reviewing the discussion on this issue. > >>>>>>>> > >>>>>>>> The issue here is the working of IEEE 802.11i when > the 802.11i > >>>>>>>> authenticator element is at the AC and the 802.11i crypto > >>>>>> element is > >>>>>>> at > >>>>>>>> the WTP. Particularly, it is for the 4-way handshake between > >>>>>>>> authenticator and supplicant. > >>>>>>>> > >>>>>>>> Now, the 4-way handshake requires knowing the value of > >>>>>>> KeyRSC sequence > >>>>>>>> counter. The KeyRSC helps both authenticator and supplicant > >>>>>>> keep track > >>>>>>>> of their exchanges. It serves to protect against threats by > >>>>>>> tracking > >>>>>>>> sequential frames. The KeyRSC is maintained at the at the > >>>>>> point of > >>>>>>>> encryption, i.e. just before transmission over the > >>>>>> wireless channel. > >>>>>>>> > >>>>>>>> In the case of CAPWAP, the 4-way handshake is between the AC > >>>>>>>> (authenticator) and the wireless station (supplicant). > >>>>>>>> > >>>>>>>> The problem arises, when the authenticator is at the AC and > >>>>>>> the crypto > >>>>>>>> element (together with KeyRSC) is at the WTP. This is a > >>>>>>> fairly common > >>>>>>>> design. Now in this case, the AC starts the 4-way > >>>>> handshake but it > >>>>>>> does > >>>>>>>> not know the value of the KeyRSC. The KeyRSC is maintained > >>>>>>> by the WTP. > >>>>>>>> > >>>>>>>> Based on this, the current CAPWAP specification does not > >>>>>> allow for a > >>>>>>> way > >>>>>>>> to conduct the 4-way handshake with the correct KeyRSC. > >>>>>>>> > >>>>>>>> The functionality I would like to see is a way for the > >>>>>> authenticator > >>>>>>>> (AC) to use the correct prevailing value of KeyRSC > >>>>>>> (maintained by the > >>>>>>>> WTP) in its 4-way handshake. > >>>>>>>> > >>>>>>>> One way to introduce this functionality in to CAPWAP is > >>>>>> to have part > >>>>>>> of > >>>>>>>> the 4-way handshake be sent from AC to WTP. This will allow > >>>>>>> the 4-way > >>>>>>>> handshake to use the correct value of the KeyRSC before > >>>>>>> being sent to > >>>>>>>> the wireless station. > >>>>>>>> > >>>>>>>> I hope this helps clarify my view on the issue. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> > >>>>>>>> Saravanan > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Margaret Wasserman [mailto:margaret@thingmagic.com] > >>>>>>>> Sent: Thursday, September 21, 2006 8:26 PM > >>>>>>>> To: Saravanan Govindan > >>>>>>>> Cc: Pat Calhoun (pacalhou); capwap@frascone.com > >>>>>>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>>>>> Considerations > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi again, > >>>>>>>> > >>>>>>>> Okay, I am even more confused than I thought I was... > >>>>>>>> > >>>>>>>> Saravanan, you wrote: > >>>>>>>> > >>>>>>>> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > >>>>>>>> > >>>>>>>>> Pat, > >>>>>>>>> > >>>>>>>>> The issue here is about how 802.11i exchanges are done when > >>>>>>>>> authenticator is at the AC and crypto elements are at > >>>>>> the WTP. This > >>>>>>> is > >>>>>>>>> the requirement. > >>>>>>>> > >>>>>>>> And, in response, Pat Calhoun wrote: > >>>>>>>> > >>>>>>>> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > >>>>>>>>> The current specification allows the authenticator to > >>>>>>> reside in the > >>>>>>>>> AC, while the data packet crypto elements in the WTP. This > >>>>>>> feature is > >>>>>>>>> already in the specification. > >>>>>>>> > >>>>>>>> Pat's message matches my reading of the specification. > >>>>>>>> > >>>>>>>> So, Saravanan, what functionality are you asking for > >>>>> that is not > >>>>>>>> already supported by the specification? And why do you > >>>>>> think it is > >>>>>>>> necessary? it will not be helpful to my understanding to > >>>>>>> re-send your > >>>>>>>> proposal or to cite the requirements document... Please > >>>>>> summarize > >>>>>>>> what functionality you think is missing from the current > >>>>>>> specification > >>>>>>>> and why you think that functionality is necessary to > >>>>> support IEEE > >>>>>>>> 802.11i or any important use case. > >>>>>>>> > >>>>>>>> At some point, the chairs may need to make a consensus > >>>>>> call on this > >>>>>>>> issue, and I'd like to understand your view and make sure > >>>>>>> that it has > >>>>>>>> been clearly communicated to the WG before we ask the WG to > >>>>>>> decide on > >>>>>>>> this issue. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Margaret > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > _________________________________________________________________ > >>>>>>>> To unsubscribe or modify your subscription options, > >>>>> please visit: > >>>>>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>>>>>> > >>>>>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>>>>>> > >>>>> > _________________________________________________________________ > >>>>>>>> To unsubscribe or modify your subscription options, > >>>>> please visit: > >>>>>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>>>>>> > >>>>>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>>>>>> > >>>>>>> > _________________________________________________________________ > >>>>>>> To unsubscribe or modify your subscription options, please > visit: > >>>>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>>>>> > >>>>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>>>>> > _________________________________________________________________ > >>>>>>> To unsubscribe or modify your subscription options, please > visit: > >>>>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>>>>> > >>>>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>>>>> > >>>>>> > _________________________________________________________________ > >>>>>> To unsubscribe or modify your subscription options, > please visit: > >>>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>>>> > >>>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>> > >>>>>> > >>>>> > _________________________________________________________________ > >>>>> To unsubscribe or modify your subscription options, > please visit: > >>>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>>> > >>>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>>> > >>>> _________________________________________________________________ > >>>> To unsubscribe or modify your subscription options, please visit: > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>> > >>>> > >>>> > >>>> > >>> > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 02 22:30:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUa3O-0007Ap-Ta for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 22:30:42 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUa3J-0000du-DN for capwap-archive@lists.ietf.org; Mon, 02 Oct 2006 22:30:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 273001448012 for ; Mon, 2 Oct 2006 19:30:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 91CF543005F for ; Mon, 2 Oct 2006 19:20:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7E4911448012 for ; Mon, 2 Oct 2006 19:20:51 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id B0ADA1448025 for ; Mon, 2 Oct 2006 19:20:45 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k932KTP5008062; Tue, 3 Oct 2006 11:20:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k932KVZ16811; Tue, 3 Oct 2006 11:20:31 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id k932KRq07573; Tue, 3 Oct 2006 11:20:28 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Oct 2006 10:19:19 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD012F23CF@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbjOwaBxAxmTegASwKjGKmQD0OreAAB7o8QAAZYQgAAILorcACsWBLA From: "Cheng Hong" To: "Bob O'Hara (boohara)" , "Dorothy Stanley" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.6 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP X-Spam-Level: Cc: Saravanan Govindan , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896095452==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 3f8115f1ca7975d69428d020de75047c This is a multi-part message in MIME format. --===============0896095452== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E692.58739154" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E692.58739154 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now to address technical portion of your comment: Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity. A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions. And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary. =20 [[Cheng Hong]] The mechanism defined in 802.11i detects the replay frame if the frame contains a sequence number out of order. However, if the KeyRSC has been set to 0, it means the initial RSC at the STA is forced to be 0 when it joins the BSS. This makes the STA to take any received frame as a valid frame since the sequence is in order. So, if the attacker replay frames with sequence in order, the STA has no way to detect that, until a frame of higher sequence order is received (supposedly by the actual AP instead of another attacker). =20 =20 As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC. This must be done for EVERY frame received, whether it is a replayed frame or not. This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA. So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame. =20 [[Cheng Hong]] As commented above, the risk of setting the KeyRSC to 0 is to allow those replay frames to pass 802.11 chipset replay check procedures, and left the detection of the replay to higher layer, and it obviously poses higher DOS threats to the STA. Setting KeyRSC to a value closer to RSC will allow the replay being detected earlier, and reduces the possible DOS attack frames. =20 -Bob =20 =20 _____ =20 From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: Thursday, September 28, 2006 5:34 PM To: Bob O'Hara (boohara); Dorothy Stanley Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com; Saravanan Govindan Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Bob, =20 As Dorothy correctly pointed out below, setting the KeyRSC to a value closer to the current RSC would be better than setting it to a pre-defined value zero.=20 =20 It is true that 802.11i and 802.1X do not specify what is the KeyRSC value to be used, since they are trying to provide us a tool to correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the tool. It is not wrong, but just deprives the system a designed function. =20 As for the effectiveness of KeyRSC, setting it to a predefined value of 0 would pose a greater threat. In a simple example, if the RSC is currently 1000, and we are mandating the KeyRSC to be always zero, the attacker basically can safely replay the last 1000 packets to the STA without being detected. If the KeyRSC can be set to a closer value of the current RSC, say, 900, the number of possible replayed packets can be reduced to 10 percent, 100 packets.=20 =20 Therefore, I would say, setting the KeyRSC value to zero does place a bigger threat. Is that how the cisco products implemented? Maybe you could share with us some other implementation/testing data to prove otherwise. Or, you have some other considerations that could defend the replay attack? =20 cheers =20 Cheng Hong =20 _____ =20 From: Bob O'Hara (boohara) [mailto:boohara@cisco.com]=20 Sent: Friday, September 29, 2006 5:21 AM To: Dorothy Stanley Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Dorothy, =20 The problem with this proposal is that it is no more effective than sending a value of zero for the KeyRSC. It doesn't eliminate any potential attacks. It doesn't add any functionality. However, it does add cost and complexity to the protocol. =20 -Bob =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 1:17 PM To: Bob O'Hara (boohara) Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations All, Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key RSC field.: "g) Key RSC. This field is 8 octets in length. It contains the receive sequence counter (RSC) for the GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state. It may also be used in the Michael MIC Failure Report frame, to report the TSC field value of the frame experiencing a MIC failure. It shall contain 0 in other messages. The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs. If the Key RSC field value is less than 8 octets in length, the remaining octets shall be set to 0. The least significant octet of the TSC or PN should be in the first octet of the Key RSC field." The intent of adding this value in message 3 was to immediately minimize the number of=20 replayed frames that a STA would potentially process: "The Key RSC field gives the current message number for the GTK, to allow a STA to identify replayed MPDUs." Setting the value to 0 in Msg 3 does not provide the current sequence counter (in most cases not even close) of the GTK.. Perhaps the WTP could periodically/frequently notify the AC of its current GTK sequence counter, and the AC would use the most recently received value in the message 3 sent to new STAs. The RSC value would not be up to date at all times, but would be closer than "0", not require an "in-the-critical-path message exchange between the AC and WTP, and still be close to the intended use of the field. Dorothy On 9/28/06, Bob O'Hara (boohara) wrote:=20 Please understand that 802.11i specifies no behavior in this area for the 802.1X authenticator. Our choice to send a group key KeyRSC value of zero in the EAPOL-key frame requires no change to 802.11i or to 802.1X . It requires us to state this in the CAPWAP spec, if we want this behavior to be consistent across all implementations. The problem with what Bechet and Saranavan are asking is that either of three different things are required:=20 1: the WTP must communicate the group key TSC to the AC every time it is updated, or 2: the AC must request the current value of the group key TSC for the KeyRSC before constructing the EAPOL-key frame, or 3: the AC must send the KCK to the AC so that it can insert the KeyRSC value and also calculate the correct MIC, inserting that into the proper EAPOL-key frame. The first item requires a tremendous amount of additional CAPWAP=20 communication between WTP and AC, at least one new CAPWAP packet for every multicast frame sent by the WTP, if the packet is not acknowledged, or two new CAPWAP packets, if it is acknowledged. This is a very expensive addition to the protocol.=20 The second item requires new protocol between the AC and WTP during what can be a time critical portion of the 802.11 transition (handoff, roam) from one WTP to another. It also introduces a race condition that is=20 not present in the protocol today. Once the value for the KeyRSC is sent from the WTP to the AC, it is possible that the WTP can send another multicast frame encrypted with the group key. This puts the value of the sequence counter out of sync with the value that will be=20 shortly communicated to the client in the EAPOL-key frame from the AC. This will behave exactly the same as if a value of zero is sent in the EAPOL-key frame. The third item requires a new architecture split that is not required in our objectives. The new split is not splitting the MAC, but splitting the authenticator. Placing the KCK in the WTP is also a potential reduction in the security of the overall WLAN system, since these devices are normally not in a secured wiring closet, but exposed and=20 more easily compromised than the AC. The simplest to implement, least expensive, and most secure option is to use the protocol as it is now specified and have the AC send a value of zero in the KeyRSC field of the EAPOL-key frame.=20 -Bob -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Wednesday, September 27, 2006 6:50 PM To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy;=20 Peter Nilsson J (LI/EAB) Cc: capwap@frascone.com Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Pat and all, So, based on this, I would say that we have consensus that setting the=20 correct KeyRSC is an issue for the CAPWAP protocol design. So far, we have three option/solutions: 1) As proposed by Bob: Using a static value (0) for the KeyRSC. 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP=20 3) As suggested by Saravanana: Some exchange mechanism between WTP and AC Among the three, the first option seems the easiest. However, it requires a mandated Authenticator behavior(in this case AC) that is not=20 mandated by 802.11. Therefore, we have to specify that (e.g. as proposed by Bob: "We could include a note to the effect that the group KeyRSC should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, because otherwise there is no interoperability. For example, AC provided by another vendor does not have to set KeyRSC to 0 to be compliant with CAPWAP and 802.11i. Another implication is that we don't really understand the impact of=20 mandating a static KeyRSC value. Although Bob provided an excellent analysis, I still have some doubts about the profoundness of the impact. If the KeyRSC value is as described of no use, why would it appear in the EAPOL frames in the first place? By mandating it to static value, what have we lost? Maybe some liaison letter to 802.1 or 802.11 could provide us a better understanding of the issue. For the last two options, I think they are both within CAPWAP's scope.=20 Further analysis could help us to decide which one is better (or someone could propose other solutions). cheers Cheng Hong > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > Sent: Thursday, September 28, 2006 1:39 AM > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > Peter Nilsson J (LI/EAB) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Bob's point is 802.11i works this way today. The AP (or in=20 > this case AC) can set the RSC to whatever value it wishes. > Bob used zero (0) as an example. Implementations could use > any other value, which would require some form of > communication to the WTP, as suggested by Behcet.=20 > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > Sent: Tuesday, September 26, 2006 6:03 PM > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Bob, > > > > If I understand your description below correct, you are proposing a=20 > > solution (to the problem pointed out by > > Saravanan) by mandating the behavior of the AC to always set the > > KeyRSC in the 4-way handshake to zero. > > > > This is not a defined behavior according to the current=20 > > 802.11 standard. > > Are you suggesting that we CAPWAP WG should specifically > mandate that > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > compatible > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > since not all AC implementation have to follow what you described. > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > revision? (since based on your description, there is essentially no > > use of the KeyRSC). > > > > cheers > > > > Cheng Hong > > > >=20 > > > > > > > -----Original Message----- > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > Sent: Wednesday, September 27, 2006 2:32 AM=20 > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i=20 > > > Considerations > > > > > > Charles, Peter, > > > > > > Below is an expansion of a snippet from a thread on this > > topic that I > > > sent to the list on July 25, 2006. I think this will be=20 > helpful to > > > understand why the exchange that Saranavan is requesting is not > > > necessary. In fact, there are several systems from several > > > manufacturers in the field using precursor protocols to=20 > CAPWAP that > > > are Wi-Fi certified for WPA2/802.11i operation using the > > protocol as > > > it is described below. > > > > > > BTW, this whole discussion is about the KeyRSC for the=20 > > group key, not > > > the pairwise key. This is so because the WTP and AC both > know the > > > initial sequence counter value for the pairwise key, since it has > > > never been used to send a frame. 802.11i requires the > first frame > > > sent on a key to use the sequence counter value of 1. See > > 8.3.2.6 c) > > > and > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > operation, the AC will not know the value of the sequence > > counter for=20 > > > the group key when it needs to complete the EAPOL-key > > handshake with a > > > newly associated STA. > > > However, as you will see from the tutorial below, it is not > > necessary > > > for the AC and WTP to exchange any information about the > group key > > > KeyRSC for the protocol to operate as it is intended. > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to=20 > > > calculate the KeyMIC. > > > > > > 2. This value does not need to bear any specific > > relationship to the > > > RSC value maintained by the WTP. A value of zero in the=20 > EAPOL-key > > > frame for the group key will always work. > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > EAPOL-key frame to validate frame using the KeyMIC.=20 > > > > > > 4. The client STA will also set its group key RSC to the value > > > received in KeyRSC, say, zero. > > > > > > 5. The value in the client STA's RSC will be compared against the=20 > > > sequence number in subsequent received frames to identify replay > > > attacks. Any frame received with a sequence counter value > > within the > > > replay window will be checked to have a valid MIC. If the=20 > > MIC is not > > > valid, the frame is dropped. > > > > > > 6. For any frame that is determined not to be a replay > attack frame > > > and meets all other validity and authenticity requirements,=20 > > the client > > > STA updates its RSC value to the sequence number in the received > > > frame, if the value is greater than its current RSC value. > > Only the > > > AP can meet these criteria as the source of a frame=20 > received by the > > > STA. > > > > > > 7. Please see item 6, immediately above, for the reason > that the AC > > > and WTP do not need to coordinate and exchange the RSC.=20 > > > > > > > > > The only possible attack mode is for the attacker to send > frames to > > > the client STA between the time of the EAPOL-key frame and > > the first=20 > > > frame encrypted with the group key. > > > During this time, the client will receive the frame and > proceed to > > > validate its MIC. This is a potential attack against the STA=20 > > > resources. But, the MIC validation is done in the STA's > > > 802.11 chip and consumes no more resources than receiving > any other > > > frame. Thus, the attack does not actually consume any STA=20 > > resources > > > beyond those of receiving a frame. > > > > > > This attack is not unique to the use of the value zero for > > the KeyRSC, > > > either. The same attack is available to an attacker at any other=20 > > > time, as well. It is no more nor less effective at either time. > > > > > > For these reasons, the protocol is not in need of any changes to > > > address the issue raised by Saranavan.=20 > > > > > > -Bob > > > -----Original Message----- > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > Sent: Monday, September 25, 2006 11:37 AM=20 > > > To: Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations=20 > > > > > > This is a very interesting solution. The AC selects the > KeyRSC and > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > traffic and grabs the KeyRSC value and uses it to=20 > > initialize its own > > > counter. > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > have to agree > > > with Saravanan that I've yet to see a technical=20 > description of how > > > Cisco implements it. > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > have the AC > > > generate the KeyRSC and include it in the AddMobile message=20 > > as Behcet > > > suggests. > > > > > > -- > > > t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > I think Saravanan has a point. We did a prototype > > impelementation of=20 > > > the > > > > protocol a year ago when it was still called LWAPP. The way > > > we solved > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > messages=20 > > > > from the AC and when message 3 of the 4-way handshake or > > > message 1 of > > > > the groupkey handshake was sent the WTP inserted the correct RSC > > > before=20 > > > > sending it off to the supplicant. To avoid the sniffing on > > > all CAPWAP > > > > data messages we would need a mechanism with in CAPWAP to > > > handle these=20 > > > > two messages. > > > > > > > > Peter Nilsson > > > > > > > > -----Original Message----- > > > > From: Saravanan Govindan > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > Sent: den 22 september 2006 11:03 > > > > To: Margaret Wasserman > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > Hi Margaret, > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > authenticator element is at the AC and the 802.11i crypto > > element is > > > at > > > > the WTP. Particularly, it is for the 4-way handshake between=20 > > > > authenticator and supplicant. > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > KeyRSC sequence > > > > counter. The KeyRSC helps both authenticator and supplicant=20 > > > keep track > > > > of their exchanges. It serves to protect against threats by > > > tracking > > > > sequential frames. The KeyRSC is maintained at the at the > > point of > > > > encryption, i.e. just before transmission over the > > wireless channel. > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC=20 > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > The problem arises, when the authenticator is at the AC and > > > the crypto > > > > element (together with KeyRSC) is at the WTP. This is a=20 > > > fairly common > > > > design. Now in this case, the AC starts the 4-way > handshake but it > > > does > > > > not know the value of the KeyRSC. The KeyRSC is maintained=20 > > > by the WTP. > > > > > > > > Based on this, the current CAPWAP specification does not > > allow for a > > > way > > > > to conduct the 4-way handshake with the correct KeyRSC.=20 > > > > > > > > The functionality I would like to see is a way for the > > authenticator > > > > (AC) to use the correct prevailing value of KeyRSC > > > (maintained by the=20 > > > > WTP) in its 4-way handshake. > > > > > > > > One way to introduce this functionality in to CAPWAP is > > to have part > > > of > > > > the 4-way handshake be sent from AC to WTP. This will allow=20 > > > the 4-way > > > > handshake to use the correct value of the KeyRSC before > > > being sent to > > > > the wireless station. > > > > > > > > I hope this helps clarify my view on the issue.=20 > > > > > > > > Cheers, > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > Sent: Thursday, September 21, 2006 8:26 PM=20 > > > > To: Saravanan Govindan > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > > > > > > > > > > > Hi again, > > > > > > > > Okay, I am even more confused than I thought I was...=20 > > > > > > > > Saravanan, you wrote: > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > >> Pat,=20 > > > >> > > > >> The issue here is about how 802.11i exchanges are done when > > > >> authenticator is at the AC and crypto elements are at > > the WTP. This=20 > > > is > > > >> the requirement. > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:=20 > > > >> The current specification allows the authenticator to > > > reside in the > > > >> AC, while the data packet crypto elements in the WTP. This > > > feature is=20 > > > >> already in the specification. > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > So, Saravanan, what functionality are you asking for=20 > that is not > > > > already supported by the specification? And why do you > > think it is > > > > necessary? it will not be helpful to my understanding to > > > re-send your=20 > > > > proposal or to cite the requirements document... Please > > summarize > > > > what functionality you think is missing from the current > > > specification > > > > and why you think that functionality is necessary to=20 > support IEEE > > > > 802.11i or any important use case. > > > > > > > > At some point, the chairs may need to make a consensus > > call on this > > > > issue, and I'd like to understand your view and make sure=20 > > > that it has > > > > been clearly communicated to the WG before we ask the WG to > > > decide on > > > > this issue. > > > > > > > > Thanks,=20 > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap =20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________=20 > > > > To unsubscribe or modify your subscription options, > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap =20 > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > _________________________________________________________________=20 > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit:=20 > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit:=20 > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap =20 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6E692.58739154 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Now to=20 address technical portion of your comment:
Again, your proposal does not eliminate any = attack=20 mechanism and does not add any functionality to the protocol, only = cost and=20 complexity.  A replayed frame will be discarded by the MAC, using = the=20 normal duplicate frame detection mechanisms.  See section=20 8.3.3.3.2 of 802.11i (where the frame = sequence number=20 is part of the additional authenticated data) and section 9.2.9 of=20 802.11-1999 for the description of these functions.  And = PLEASE read=20 802.11 and 802.11i before again asserting that this proposal is=20 necessary.
 
[[Cheng Hong]] The = mechanism defined=20 in 802.11i detects the replay frame if the frame contains a = sequence=20 number out of order. However, if the KeyRSC has been set to 0, it = means the=20 initial RSC at the STA is forced to be 0 when it joins the BSS. This = makes the=20 STA to take any received frame as a valid frame since the sequence is = in=20 order. So, if the attacker replay frames with sequence in order, the = STA has=20 no way to detect that, until a frame of higher sequence order is = received=20 (supposedly by the actual AP instead of another=20 attacker).
 
 
As I said several emails ago, the ONLY = effect of=20 using zero as the value for the KeyRSC is that the 802.11 chipset in = the STA=20 (client) will have to receive the frame, attempt to decrypt it, and = validate=20 the MIC.  This must be done for EVERY frame received, whether it = is a=20 replayed frame or not.  This set of functions is performed in the = 802.11=20 STA chipset and does not consume any additional resources of the = STA. =20 So, the attack, if it can even be characterized as an attack, is no = more=20 effective at DOSing the STA than sending it any other frame.
 
[[Cheng Hong]]  As commented = above, the=20 risk of setting the KeyRSC to 0 is to allow those replay frames to = pass 802.11=20 chipset replay check procedures, and left the detection of the replay = to=20 higher layer, and it obviously poses higher DOS threats to the STA. = Setting=20 KeyRSC to a value closer to RSC will allow the replay being detected = earlier,=20 and reduces the possible DOS attack=20 frames.
 

 -Bob
 

 

From: Cheng Hong=20 [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Thursday, = September 28,=20 2006 5:34 PM
To: Bob O'Hara (boohara); Dorothy = Stanley
Cc:=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com; Saravanan Govindan
Subject: RE: = [Capwap] Issue=20 43 - Explanation for 802.11i Considerations

Hi=20 Bob,
 
As=20 Dorothy correctly pointed out below, setting the KeyRSC to a value = closer to=20 the current RSC would be better than setting it to a pre-defined value = zero.=20
 
It=20 is true that 802.11i and 802.1X do not specify what is the KeyRSC = value to be=20 used, since they are trying to provide us a tool to correctly = synchronize the=20 RSC using the Msg 3. By mandating the KeyRSC to zero, we are just = disabling=20 the tool. It is not wrong, but just deprives the system a designed=20 function.
 
As=20 for the effectiveness of KeyRSC, setting it to a predefined value of 0 = would=20 pose a greater threat. In a simple example, if the RSC is currently = 1000, and=20 we are mandating the KeyRSC to be always zero, the attacker = basically can=20 safely replay the last 1000 packets to the STA without being = detected. If=20 the KeyRSC can be set to a closer value of the current RSC, say, 900, = the=20 number of possible replayed packets can be reduced to 10 percent, = 100=20 packets.
 
Therefore, I would say, setting the KeyRSC value to zero does = place a=20 bigger threat. Is that how the cisco products implemented? Maybe you = could=20 share with us some other implementation/testing data to prove = otherwise. Or,=20 you have some other considerations that could defend the replay=20 attack?
 
cheers
 
Cheng Hong
 

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
Sent: Friday, September 29, = 2006 5:21=20 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat = Calhoun=20 (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subject: RE: [Capwap] Issue 43 - = Explanation=20 for 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it = is no more=20 effective than sending a value of zero for the KeyRSC.  It = doesn't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and = complexity to=20 the protocol. 

 -Bob
 

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28,=20 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng = Hong;=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); = capwap@frascone.com
Subject: Re: [Capwap] Issue 43 - = Explanation=20 for 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 = Clause 8.5.2,=20 describing the Key RSC field.:

"g)=20 Key RSC. This field is 8 octets in length. It contains the receive = sequence=20 counter (RSC) for the
GTK being installed in IEEE 802.11. It = is used in=20 Message 3 of the 4-Way Handshake andMessage 1 of the=20 Group Key Handshake, where it is used to synchronize the IEEE 802.11 = replay
state. It may also be used in the = Michael MIC=20 Failure Report frame, to report the TSC field value ofthe = frame=20 experiencing a MIC failure. It shall contain 0 in other messages. = The Key=20 RSC field gives
the current message number for the GTK, = to allow=20 a STA to identify replayed MPDUs. If the KeyRSC = field value=20 is less than 8 octets in length, the remaining octets shall be set = to 0. The=20 least significant
octet of the TSC or PN should be in the = first=20 octet of the Key RSC field."

The intent of adding this = value=20 in message 3 was to immediately minimize the number of
replayed = frames=20 that a STA would potentially process: "The Key RSC field = gives
the=20 current message number for the GTK, to allow a STA to identify = replayed=20 MPDUs."
Setting the value to 0 in Msg 3 does not provide the = current=20 sequence counter (in most cases
not even close) of the=20 GTK..

Perhaps the WTP could periodically/frequently notify = the AC of=20 its current GTK sequence counter, and the
AC would use the most = recently=20 received value in the message 3 sent to new STAs. The RSC = value
would not=20 be  up to date at all times, but would be closer than "0", not = require=20 an "in-the-critical-path
message exchange between the AC and WTP, = and=20 still be close to the intended use of the = field.

Dorothy

On 9/28/06, Bob=20 O'Hara (boohara) <boohara@cisco.com> = wrote:=20
Please=20 understand that 802.11i specifies no behavior in this area = for
the=20 802.1X authenticator.  Our choice to send a group key = KeyRSC=20 value
of zero in the EAPOL-key frame requires no change to = 802.11i or=20 to
802.1X .  It requires us to state this in the = CAPWAP spec,=20 if we want
this behavior to be consistent across all=20 implementations.

The problem with what Bechet and Saranavan = are=20 asking is that either of
three different things are required: =
1:=20 the WTP must communicate the group key TSC to the AC every time it = is
updated, or
2: the AC must request the current value of = the group=20 key TSC for the
KeyRSC before constructing the EAPOL-key frame, = or
3: the AC must send the KCK to the AC so  that it = can=20 insert the KeyRSC
value and also calculate the correct MIC, = inserting=20 that into the proper
EAPOL-key frame.

The first item = requires a=20 tremendous amount of additional CAPWAP
communication between = WTP and=20 AC, at least one new CAPWAP packet for
every multicast frame = sent by=20 the WTP, if the packet is not
acknowledged, or two new CAPWAP = packets,=20 if it is acknowledged.  This is
a very expensive = addition to=20 the protocol.

The second item requires new protocol = between the AC=20 and WTP during what
can be a time critical portion of the = 802.11=20 transition (handoff, roam)
from one WTP to = another.  It also=20 introduces a race condition that is
not present in the = protocol=20 today.  Once the value for the KeyRSC is
sent from = the WTP to=20 the AC, it is possible that the WTP can send
another multicast = frame=20 encrypted with the group key.  This puts the
value of = the=20 sequence counter out of sync with the value that will be =
shortly=20 communicated to the client in the EAPOL-key frame from the = AC.
This=20 will behave exactly the same as if a value of zero is sent in=20 the
EAPOL-key frame.

The third item requires a new = architecture=20 split that is not required in
our objectives.  The = new split=20 is not splitting the MAC, but splitting
the=20 authenticator.  Placing the KCK in the WTP is also a=20 potential
reduction in the security of the overall WLAN system, = since=20 these
devices are normally not in a secured wiring closet, but = exposed=20 and
more easily compromised than the AC.

The simplest = to=20 implement, least expensive, and most secure option is to
use = the=20 protocol as it is now specified and have the AC send a value = of
zero in=20 the KeyRSC field of the EAPOL-key frame. =

-Bob

-----Original=20 Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun = (pacalhou); Bob=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J = (LI/EAB)
Cc:=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Issue 43 - Explanation for 802.11i = Considerations

Hi=20 Pat and all,

So, based on this, I would say that we have = consensus=20 that setting the
correct KeyRSC is an issue for the CAPWAP = protocol=20 design.

So far, we have three option/solutions:

1) = As=20 proposed by Bob: Using a static value (0) for the = KeyRSC.

2) As=20 suggested by Behcet: AC communicate a correct KeyRSC to WTP =

3) As=20 suggested by Saravanana: Some exchange mechanism between WTP=20 and
AC

Among the three, the first option seems the = easiest.=20 However, it
requires a mandated Authenticator behavior(in this = case AC)=20 that is not
mandated by 802.11. Therefore, we have to specify = that=20 (e.g. as proposed
by Bob: "We could include a note to the = effect that=20 the group KeyRSC
should be zero in the EAPOL-key frame.") = either in=20 CAPWAP or 802.11,
because otherwise there is no = interoperability. For=20 example, AC provided
by another vendor does not have to set = KeyRSC to 0=20 to be compliant with
CAPWAP and 802.11i.

Another = implication is=20 that we don't really understand the impact of
mandating a = static=20 KeyRSC value. Although Bob provided an excellent
analysis, I = still have=20 some doubts about the profoundness of the impact.
If the KeyRSC = value=20 is as described of no use, why would it appear in
the EAPOL = frames in=20 the first place? By mandating it to static value,
what have we = lost?=20 Maybe some liaison letter to 802.1 or 802.11 could
provide us a = better=20 understanding of the issue.

For the last two options, I = think they=20 are both within CAPWAP's scope.
Further analysis could help us = to=20 decide which one  is better (or
someone could propose = other=20 solutions).

cheers

Cheng=20 Hong







> -----Original=20 Message-----
> From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> = Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob = O'Hara=20 (boohara); T. Charles Clancy;
> Peter Nilsson J = (LI/EAB)
> Cc:=20 capwap@frascone.com
>=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this = way=20 today. The AP (or in
> this case AC) can set the RSC to = whatever=20 value it wishes.
> Bob used zero (0) as an example. = Implementations=20 could use
> any other value, which would require some form=20 of
> communication to the WTP, as suggested by Behcet.=20
>
> Pat Calhoun
> CTO, Wireless Networking = Business=20 Unit
> Cisco Systems
>
>
>
> >=20 -----Original Message-----
> > From: Cheng Hong = [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, = September 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles = Clancy;=20 Peter Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> > = Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> = >=20 Considerations
> >
> > Hi Bob,
> = >
> >=20 If I understand your description below correct, you are proposing = a=20
> > solution (to the problem pointed out by
> > = Saravanan) by mandating the behavior of the AC to always set = the
>=20 > KeyRSC in the 4-way handshake to zero.
> >
> = > This=20 is not a defined behavior according to the current
> > = 802.11=20 standard.
> > Are you suggesting that we CAPWAP WG should = specifically
> mandate that
> > in our CAPWAP = protocol=20 spec, e.g. something like "a CAPWAP
> compatible
> = > AC=20 MUST set KeyRSC to zero"? Otherwise, the problem still = exists,
>=20 > since not all AC implementation have to follow what you=20 described.
> >
> > Or, are you planning to take = this=20 issue to TGm for 802.11 standard
> > revision? (since = based on=20 your description, there is essentially no
> > use of the=20 KeyRSC).
> >
> > cheers
> >
> = > Cheng=20 Hong
> >
> >
> >
> >
> = >=20 > -----Original Message-----
> > > From: Bob O'Hara = (boohara) [mailto:boohara@cisco.com]
> = > >=20 Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: = T.=20 Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > = > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i =
>=20 > > Considerations
> > >
> > > = Charles,=20 Peter,
> > >
> > > Below is an expansion = of a=20 snippet from a thread on this
> > topic that I
> = > >=20 sent to the list on July 25, 2006.  I think this will be =
> helpful to
> > > understand why the exchange = that=20 Saranavan is requesting is not
> > > = necessary.  In=20 fact, there are several systems from several
> > >=20 manufacturers in the field using precursor protocols to
> = CAPWAP=20 that
> > > are Wi-Fi certified for WPA2/802.11i = operation=20 using the
> > protocol as
> > > it is = described=20 below.
> > >
> > > BTW, this whole = discussion is=20 about the KeyRSC for the
> > group key, not
> > = >=20 the pairwise key.  This is so because the WTP and AC=20 both
> know the
> > > initial sequence counter = value for=20 the pairwise key, since it has
> > > never been used = to send a=20 frame.   802.11i requires the
> first = frame
> >=20 > sent on a key to use the sequence counter value of=20 1.  See
> > 8.3.2.6=20 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i = for=20 this requirement.
> > >
> > > The same is = not true=20 of the group key, i.e., after the WTP begins
> > > = operation,=20 the AC will not know the value of the sequence
> > = counter for=20
> > > the group key when it needs to complete the=20 EAPOL-key
> > handshake with a
> > > newly = associated=20 STA.
> > > However, as you will see from the tutorial = below,=20 it is not
> > necessary
> > > for the AC and = WTP to=20 exchange any information about the
> group key
> > = >=20 KeyRSC for the protocol to operate as it is intended.
> > = >
> > > 1. A value for the KeyRSC in the EAPOL-key = frame is=20 necessary to
> > > calculate the KeyMIC.
> > = >
> > > 2. This value does not need to bear any=20 specific
> > relationship to the
> > > RSC = value=20 maintained by the WTP.  A value of zero in the
>=20 EAPOL-key
> > > frame for the group key will always=20 work.
> > >
> > > 3. The client STA will = use the=20 value of KeyRSC received in the
> > > EAPOL-key frame = to=20 validate frame using the KeyMIC.
> > >
> > = > 4.=20 The client STA will also set its group key RSC to the = value
> >=20 > received in KeyRSC, say, zero.
> > >
> > = > 5.=20 The value in the client STA's RSC will be compared against the =
>=20 > > sequence number in subsequent received frames to = identify=20 replay
> > > attacks.  Any frame received = with a=20 sequence counter value
> > within the
> > > = replay=20 window will be checked to have a valid MIC.  If the =
>=20 > MIC is not
> > > valid, the frame is = dropped.
>=20 > >
> > > 6. For any frame that is determined = not to be=20 a replay
> attack frame
> > > and meets all = other=20 validity and authenticity requirements,
> > the = client
>=20 > > STA updates its RSC value to the sequence number in the=20 received
> > > frame, if the value is greater than its = current=20 RSC value.
> > Only the
> > > AP can meet = these=20 criteria as the source of a frame
> received by the
> = >=20 > STA.
> > >
> > > 7. Please see item = 6,=20 immediately above, for the reason
> that the AC
> > = >=20 and WTP do not need to coordinate and exchange the RSC.
> = >=20 >
> > >
> > > The only possible attack = mode is=20 for the attacker to send
> frames to
> > > the = client=20 STA between the time of the EAPOL-key frame and
> > the = first=20
> > > frame encrypted with the group key.
> = > >=20 During this time, the client will receive the frame and
> = proceed=20 to
> > > validate its MIC.  This is a = potential=20 attack against the STA
> > > = resources.  But, the=20 MIC validation is done in the STA's
> > > 802.11 chip = and=20 consumes no more resources than receiving
> any = other
> >=20 > frame.  Thus, the attack does not actually consume = any STA=20
> > resources
> > > beyond those of = receiving a=20 frame.
> > >
> > > This attack is not = unique to=20 the use of the value zero for
> > the KeyRSC,
> = > >=20 either.  The same attack is available to an attacker at = any=20 other
> > > time, as well.  It is no more = nor less=20 effective at either time.
> > >
> > > For = these=20 reasons, the protocol is not in need of any changes to
> = > >=20 address the issue raised by Saranavan.
> > >
> = >=20 >  -Bob
> > > -----Original = Message-----
>=20 > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu]
> = > >=20 Sent: Monday, September 25, 2006 11:37 AM
> > > To: = Peter=20 Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > = > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
> >=20 > Considerations
> > >
> > > This is a = very=20 interesting solution.  The AC selects the
> KeyRSC = and
> > > performs the 4-way handshake.  The = WTP=20 sniffs the 4-way handshake
> > > traffic and grabs the = KeyRSC=20 value and uses it to
> > initialize its own
> > = >=20 counter.
> > >
> > > Pat/Bob: Is this how = the=20 Cisco implementation works?  I
> > have to=20 agree
> > > with Saravanan that I've yet to see a = technical=20
> description of how
> > > Cisco implements = it.
>=20 > >
> > > IMHO, this is somewhat hackish, and it = would=20 be cleaner to
> > have the AC
> > > generate = the=20 KeyRSC and include it in the AddMobile message
> > as=20 Behcet
> > > suggests.
> > >
> > = >=20 --
> > > t. charles clancy, = ph.d.  |  tcc@umd.edu  |
> = www.cs.umd.edu/~clancy
>= =20 > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J = (LI/EAB)=20 wrote:
> > >
> > > > I think Saravanan = has a=20 point. We did a prototype
> > impelementation of
> = >=20 > the
> > > > protocol a year ago when it was = still=20 called LWAPP. The way
> > > we solved
> > = > >=20 this issue then was to let the WTP sniff on all CAPWAP = data
> >=20 > messages
> > > > from the AC and when message = 3 of=20 the 4-way handshake or
> > > message 1 of
> > = >=20 > the groupkey handshake was sent the WTP inserted the correct=20 RSC
> > > before
> > > > sending it = off to the=20 supplicant. To avoid the sniffing on
> > > all = CAPWAP
>=20 > > > data messages we would need a mechanism with in = CAPWAP=20 to
> > > handle these
> > > > two=20 messages.
> > > >
> > > > Peter=20 Nilsson
> > > >
> > > > = -----Original=20 Message-----
> > > > From: Saravanan = Govindan
> >=20 > [mailto:Saravanan.Govindan@sg= .panasonic.com]
>=20 > > > Sent: den 22 september 2006 11:03
> > > = >=20 To: Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > = > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
>=20 > > Considerations
> > > >
> > > = > Hi=20 Margaret,
> > > >
> > > > Thank you = for=20 reviewing the discussion on this issue.
> > > = >
>=20 > > > The issue here is the working of IEEE 802.11i when = the=20 802.11i
> > > > authenticator element is at the AC = and the=20 802.11i crypto
> > element is
> > > = at
> >=20 > > the WTP. Particularly, it is for the 4-way handshake = between=20
> > > > authenticator and supplicant.
> > = >=20 >
> > > > Now, the 4-way handshake requires = knowing the=20 value of
> > > KeyRSC sequence
> > > > = counter.=20 The KeyRSC helps both authenticator and supplicant
> > = > keep=20 track
> > > > of their exchanges. It serves to = protect=20 against threats by
> > > tracking
> > > = >=20 sequential frames. The KeyRSC is maintained at the at the
> = >=20 point of
> > > > encryption, i.e. just before = transmission=20 over the
> > wireless channel.
> > > = >
>=20 > > > In the case of CAPWAP, the 4-way handshake is = between the=20 AC
> > > > (authenticator) and the wireless = station=20 (supplicant).
> > > >
> > > > The = problem=20 arises, when the authenticator is at the AC and
> > > = the=20 crypto
> > > > element (together with KeyRSC) is at = the=20 WTP. This is a
> > > fairly common
> > > = >=20 design. Now in this case, the AC starts the 4-way
> = handshake but=20 it
> > > does
> > > > not know the = value of the=20 KeyRSC. The KeyRSC is maintained
> > > by the = WTP.
>=20 > > >
> > > > Based on this, the current = CAPWAP=20 specification does not
> > allow for a
> > >=20 way
> > > > to conduct the 4-way handshake with the = correct=20 KeyRSC.
> > > >
> > > > The = functionality I=20 would like to see is a way for the
> > = authenticator
> >=20 > > (AC) to use the correct prevailing value of = KeyRSC
> >=20 > (maintained by the
> > > > WTP) in its 4-way=20 handshake.
> > > >
> > > > One way = to=20 introduce this functionality in to CAPWAP is
> > to have=20 part
> > > of
> > > > the 4-way = handshake be=20 sent from AC to WTP. This will allow
> > > the = 4-way
>=20 > > > handshake to use the correct value of the KeyRSC=20 before
> > > being sent to
> > > > the = wireless=20 station.
> > > >
> > > > I hope this = helps=20 clarify my view on the issue.
> > > >
> > = >=20 > Cheers,
> > > >
> > > >=20 Saravanan
> > > >
> > > >
> = > >=20 >
> > > >
> > > >
> > = >=20 >
> > > > -----Original Message-----
> = > >=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
&= gt;=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> = >=20 > > To: Saravanan Govindan
> > > > Cc: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
> > = > > Subject: Re: [Capwap] Issue 43 - Explanation for = 802.11i
>=20 > > Considerations
> > > >
> > >=20 >
> > > >
> > > > Hi = again,
> >=20 > >
> > > > Okay, I am even more confused = than I=20 thought I was...
> > > >
> > > > = Saravanan,=20 you wrote:
> > > >
> > > > On Sep = 17, 2006,=20 at 10:24 PM, Saravanan Govindan wrote:
> > > = >
> >=20 > >> Pat,
> > > >>
> > > = >>=20 The issue here is about how 802.11i exchanges are done = when
> >=20 > >> authenticator is at the AC and crypto elements are=20 at
> > the WTP. This
> > > is
> > = >=20 >> the requirement.
> > > >
> > > = >=20 And, in response, Pat Calhoun wrote:
> > > = >
> >=20 > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) = wrote:=20
> > > >> The current specification allows the=20 authenticator to
> > > reside in the
> > > = >> AC, while the data packet crypto elements in the WTP.=20 This
> > > feature is
> > > >> = already in=20 the specification.
> > > >
> > > > = Pat's=20 message matches my reading of the specification.
> > > = >
> > > > So, Saravanan, what functionality are = you=20 asking for
> that is not
> > > > already = supported=20 by the specification?  And why do you
> > think = it=20 is
> > > > necessary?  it will not be = helpful to=20 my understanding to
> > > re-send your
> > = > >=20 proposal or to cite the requirements = document...  Please
>=20 > summarize
> > > > what functionality you think = is=20 missing from the current
> > > specification
> = > >=20 > and why you think that functionality is necessary to
> = support=20 IEEE
> > > > 802.11i or any important use = case.
>=20 > > >
> > > > At some point, the chairs = may need=20 to make a consensus
> > call on this
> > > = >=20 issue, and I'd like to understand your view and make sure
> = >=20 > that it has
> > > > been clearly communicated = to the=20 WG before we ask the WG to
> > > decide on
> = > >=20 > this issue.
> > > >
> > > > = Thanks,=20
> > > > Margaret
> > > >
> = > >=20 >
> > > >
> > > >
> > = >=20 >
> > > >
> > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
>=20 _________________________________________________________________ =
>=20 > > > To unsubscribe or modify your subscription = options,
>=20 please visit:
> > > > http://lists.f= rascone.com/mailman/listinfo/capwap=20
> > > >
> > > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > > >
> > >=20 _________________________________________________________________ =
>=20 > > To unsubscribe or modify your subscription options, = please=20 visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >=20 = _________________________________________________________________
>= =20 > > To unsubscribe or modify your subscription options, = please=20 visit:
> > > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone= .com/pipermail/capwap
>=20 > >
> >=20 = _________________________________________________________________
>= =20 > To unsubscribe or modify your subscription options, please = visit:=20
> > http://lists.f= rascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone= .com/pipermail/capwap=20
> >
>=20 = _________________________________________________________________
>= =20 To unsubscribe or modify your subscription options, please = visit:
>=20 http://lists.f= rascone.com/mailman/listinfo/capwap
>
>=20 Archives: http://lists.frascone= .com/pipermail/capwap
>
____________________________________= _____________________________=20
To unsubscribe or modify your subscription options, please=20 visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap

------_=_NextPart_001_01C6E692.58739154-- --===============0896095452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0896095452==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 05:53:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUgyA-0003Nx-IY for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 05:53:46 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUgy9-0006Xu-34 for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 05:53:46 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DAFB143099B for ; Tue, 3 Oct 2006 02:53:34 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 9D795430018 for ; Tue, 3 Oct 2006 02:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3A71E39800F for ; Tue, 3 Oct 2006 02:52:49 -0700 (PDT) Received: from mcfeely.cs.umd.edu (mcfeely.cs.umd.edu [128.8.128.218]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1307C39800E for ; Tue, 3 Oct 2006 02:52:44 -0700 (PDT) Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k939qYOX015900; Tue, 3 Oct 2006 05:52:34 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k939qW7v015898; Tue, 3 Oct 2006 05:52:32 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 153.26.176.34 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Tue, 3 Oct 2006 05:52:32 -0400 (EDT) Message-ID: <38379.153.26.176.34.1159869152.squirrel@webmail.cs.umd.edu> In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> References: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> Date: Tue, 3 Oct 2006 05:52:32 -0400 (EDT) From: "Charles Clancy" To: "Bob O'Hara (boohara)" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Margaret Wasserman , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Bob, >> 1. Set the KeyRSC to a static value. This increases the risk of replay >> attacks of multicast/broadcast packets encrypted with the group key >> between the time the client authenticates and when the first legitimate >> group key-encrypted packet is transmitted. > > Bob>> I don't believe that this increases the risk of replay attack. > The risk of attack is related to the presence of an attacker and the > time between the 4-way handshake and the next multicast frame > transmitted by the AP. As long as the possibility exists that the > KeyRSC does not match the actual TSC, this attack is feasible. > > Bob>> It should be noted that "replay" of encrypted/MICed multicast > frames is inherent in the design of an 802.11 WLAN that has more than > one AP in it. Because the load and availability of transmit > opportunities varies with time, location, and channel, it is likely that > the STA will encounter a situation where it has received one or more > multicast frames from one AP that it will receive again from a second AP > that it has just roamed to. The multicast frames at the second AP have > been delayed due to that AP having fewer opportunities to transmit, > resulting in longer queuing delays for the first transmission of those > multicast frames. I'm trying to distinguish between replay attacks and *useful* replay attacks. Just because something can be replayed doesn't mean it's useful for launching some sort of attack. The probability of a useful replay attack increases with the number of available packets that can be replayed. Setting RSC=0 increases the number of packets available to be replayed. For all practical purposes, we're talking about quite the corner case. Any sensitive, multicast protocol running over the wireless link that would be vulnerable to replay would have it's own security mechanism to prevent such attacks. If such a protocol was attacked, I would personally blame the protocol rather than CAPWAP's handling of the RSC. >> 3. Have the WTP request the GTK prior to initiating the 4-way handshake. > > Bob>> The WTP already has the GTK, if it has any STAs associated. There > is no need for it to request it from the AC. I am not sure what this > would accomplish. Sorry... I mistyped. I meant have the *AC* request the *RSC*. > Bob>> The STA cannot transmit on the GTK, this is not allowed by 802.11. Good. Then that's not a problem. If the consensus is to use RSC=0, then I think a disclaimer statement should be added to the security considerations section about the replay possibility in multicast protocols. Overall this is probably sufficient. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 08:07:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUj43-0007d4-Db for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 08:07:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUj3x-0008Tz-WF for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 08:07:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C0FF13980CB for ; Tue, 3 Oct 2006 05:07:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 7D12243005F for ; Tue, 3 Oct 2006 05:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6732E431297 for ; Tue, 3 Oct 2006 05:07:04 -0700 (PDT) X-Greylist-Status: Sender first seen 12 days 03:19:55 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 987C3431037 for ; Tue, 3 Oct 2006 05:07:02 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1343892; Tue, 03 Oct 2006 08:07:01 -0400 In-Reply-To: <38379.153.26.176.34.1159869152.squirrel@webmail.cs.umd.edu> References: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> <38379.153.26.176.34.1159869152.squirrel@webmail.cs.umd.edu> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Message-Id: <6037C65A-A80D-4BEE-B10B-55427B912F34@thingmagic.com> From: Margaret Wasserman Date: Tue, 3 Oct 2006 08:05:09 -0400 To: Charles Clancy X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi Charles, > If the consensus is to use RSC=0, then I think a disclaimer statement > should be added to the security considerations section about the > replay > possibility in multicast protocols. Overall this is probably > sufficient. This does seem like the simplest approach. So, if there is no objection from our security advisors (you and Scott Kelly), then I'm for it. Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 09:23:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUkFO-00020G-OV for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 09:23:46 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUkFN-0002w8-BA for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 09:23:46 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 3D86A4313CD for ; Tue, 3 Oct 2006 06:23:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 14BDA4300EF for ; Tue, 3 Oct 2006 06:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 03FD539801C for ; Tue, 3 Oct 2006 06:22:24 -0700 (PDT) Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [204.127.225.93]) by zoidberg.tigertech.net (Postfix) with ESMTP id CB00B39802E for ; Tue, 3 Oct 2006 06:22:20 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (alnrmhc13) with ESMTP id <20061003132219b1300l92u2e>; Tue, 3 Oct 2006 13:22:19 +0000 Message-ID: <4522640A.2090108@hyperthought.com> Date: Tue, 03 Oct 2006 06:22:18 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Margaret Wasserman References: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> <38379.153.26.176.34.1159869152.squirrel@webmail.cs.umd.edu> <6037C65A-A80D-4BEE-B10B-55427B912F34@thingmagic.com> In-Reply-To: <6037C65A-A80D-4BEE-B10B-55427B912F34@thingmagic.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 I agree with Charles - a note in the security considerations is appropriate. Margaret Wasserman wrote: > Hi Charles, > > > >> If the consensus is to use RSC=0, then I think a disclaimer statement >> should be added to the security considerations section about the >> replay >> possibility in multicast protocols. Overall this is probably >> sufficient. > > This does seem like the simplest approach. So, if there is no > objection from our security advisors > (you and Scott Kelly), then I'm for it. > > > > Margaret > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 10:24:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUlBo-00086w-HJ for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 10:24:08 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUlBm-0006Xf-39 for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 10:24:08 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 16CA039809C for ; Tue, 3 Oct 2006 07:24:01 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E44AD43005F for ; Tue, 3 Oct 2006 07:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D2CDB398052 for ; Tue, 3 Oct 2006 07:23:07 -0700 (PDT) Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [204.127.225.93]) by zoidberg.tigertech.net (Postfix) with ESMTP id 58052398035 for ; Tue, 3 Oct 2006 07:23:04 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (alnrmhc13) with ESMTP id <20061003142304b1300l95mie>; Tue, 3 Oct 2006 14:23:04 +0000 Message-ID: <45227247.602@hyperthought.com> Date: Tue, 03 Oct 2006 07:23:03 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Margaret Wasserman References: <17B8C6DE4E228348B4939BDA6B05A9DC021893C9@xmb-sjc-237.amer.cisco.com> <38379.153.26.176.34.1159869152.squirrel@webmail.cs.umd.edu> <6037C65A-A80D-4BEE-B10B-55427B912F34@thingmagic.com> <4522640A.2090108@hyperthought.com> In-Reply-To: <4522640A.2090108@hyperthought.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Just re-reading this thread, and I realized I still have a few questions, so I want to get my foot in the door briefly while I run down answers. Just want to make sure to give this an appropriately diligent response - please indulge me. I will aim to resolve my questions today. Scott G Kelly wrote: > I agree with Charles - a note in the security considerations is appropriate. > > Margaret Wasserman wrote: >> Hi Charles, >> >> >> >>> If the consensus is to use RSC=0, then I think a disclaimer statement >>> should be added to the security considerations section about the >>> replay >>> possibility in multicast protocols. Overall this is probably >>> sufficient. >> This does seem like the simplest approach. So, if there is no >> objection from our security advisors >> (you and Scott Kelly), then I'm for it. >> >> >> >> Margaret >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 11:46:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmT8-0005Es-Te for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 11:46:06 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmT5-0001Ue-Rg for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 11:46:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 7800D4315F3 for ; Tue, 3 Oct 2006 08:45:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 87D0643005F for ; Tue, 3 Oct 2006 08:39:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6980C431603 for ; Tue, 3 Oct 2006 08:39:37 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 8E3DA4315FD for ; Tue, 3 Oct 2006 08:39:35 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so195175nfb for ; Tue, 03 Oct 2006 08:39:33 -0700 (PDT) Received: by 10.49.26.18 with SMTP id d18mr983853nfj; Tue, 03 Oct 2006 08:39:33 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Tue, 3 Oct 2006 08:39:33 -0700 (PDT) Message-ID: <5bfe7a820610030839x367c7a77o7e8d69055d47bbd8@mail.gmail.com> Date: Tue, 3 Oct 2006 08:39:33 -0700 From: "Dorothy Stanley" To: "Michael Montemurro" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Proposed resolution to Issue 85/ wasRe: Issue with state machine X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1054719950==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 --===============1054719950== Content-Type: multipart/alternative; boundary="----=_Part_8737_7541798.1159889973337" ------=_Part_8737_7541798.1159889973337 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 85 was closed in -02 and then re-opened to address the following comment: I just noticed that the latest specification's state machine requires that in order to perform a firmware download, the state must transition from the join to configure to image data. This is a departure from the original protocol, and I believe introduces some challenges. One of the benefits of bypassing the configure state is that it maximizes interoperability across version numbers. If we require the configure state to be run, then we need to ensure that the configure message does not introduce any new message elements that can create a backward compatiblity issue. However, the way the protocol used to be only required that the Join state have to deal with backward compatibility. I'd like to see this changed back to the old way. Sorry I missed this in my reviews. The -02 specification has state transitions from Join to Configure to Image data, with corresponding text descriptions. This is unchanged from the -01 specification. The -00 specification had a transition from DTLS-Complete to Configure and to Image Data. The current text description includes: Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information. WTP: The WTP enters the Configure state when it successfully completes the Join operation. If it determines that its version number and the version number advertised by the AC are the same, the WTP transmits the Configuration Status message (see Section 8.2) to the AC with a snapshot of its current configuration. The WTP also starts the ResponseTimeout timer (see ). (Section 4.5) If the version numbers are not the same, the WTP will immediately transition to Image Data state (see transition (i)). and for the AC: AC: This state transition occurs immediately after the AC transmits the Join Response message to the WTP. If the AC receives the Configuration Status message from the WTP, the AC must transmit a Configuration Status Response message(see Section 8.3) to the WTP, and may include specific message elements to override the WTP's configuration. If the AC instead receives the Image Data Request from the WTP, it immediately transitions to the Image Data state (see transition (i)). In the current specification, if the WTP received a Discovery Response message from the AC, it has the AC descriptor data, including the AC Hardware and Software version numbers, and does not need to exchange configuration messages to obtain AC HW & SW version info. If the WTP does not execute the Discovery exchange, then it will need to obtain the data. Proposed Resolution: Insert the following text at the end of 6.2 "Join Response", so that in all cases, the Configuration messages are not sent: "The following message element MUST be included in the Join Response message: - AC Descriptor, see Section 4.4.1" ------------------------------------------------------------------------------------------------ Related observation 1: The current text states that " If it [WTP] determines that its version number and the version number advertised by the AC are the same, the WTP transmits the Configuration Status message (see Section 8.2) to the AC with a snapshot of its current configuration." This can't be correct - multiple vendors will have different version numbering schemes. Proposed change: from If it determines that its version number and the version number advertised by the AC are the same, the WTP transmits the Configuration Status message (see Section 8.2) to the AC with a snapshot of its current configuration. to If it determines that its version number and the version number advertised by the AC are compatible, the WTP transmits the Configuration Status message (see Section 8.2) to the AC with a snapshot of its current configuration. ---------------------------------------------------------------------------------------------------------------------- Related observation 2: The current specification provides a means for the WTP to initiate the move to Image Data from the Configure State, but does not provide the AC with a similar capability. The current text expects that the WTP has knowledge of all of the AC versions that it can interoperate with. How the WTP would make this determination is of course out of scope. It is also likely that the AC would have similar knowledge, in one central location. Proposed Change: Insert the following sentence as indicated: AC: This state transition occurs immediately after the AC transmits the Join Response message to the WTP. If the AC receives the Configuration Status message from the WTP, the AC must transmit a Configuration Status Response message(see Section 8.3) to the WTP, and may include specific message elements to override the WTP's configuration. If the AC instead receives the Image Data Request from the WTP, it immediately transitions to the Image Data state (see transition (i)). If the AC determines that a new firmware image should be installed on the WTP, the AC initiates a firmware download by sending an Image Data Request Message with an Initiate Download message element to the WTP. Comments welcome, Thanks, Dorothy On 6/30/06, Michael Montemurro wrote: > > Pat, > > I re-openned issue 85 to deal with this issue. > > Cheers, > > Mike > > > On 6/27/06, Pat Calhoun (pacalhou) wrote: > > > I just noticed that the latest specification's state machine requires > > that in order to perform a firmware download, the state must transition from > > the join to configure to image data. This is a departure from the original > > protocol, and I believe introduces some challenges. One of the benefits of > > bypassing the configure state is that it maximizes interoperability across > > version numbers. If we require the configure state to be run, then we need > > to ensure that the configure message does not introduce any new message > > elements that can create a backward compatiblity issue. However, the way the > > protocol used to be only required that the Join state have to deal with > > backward compatibility. > > > > I'd like to see this changed back to the old way. Sorry I missed this in > > my reviews. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_8737_7541798.1159889973337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Issue 85 was closed in -02 and then re-opened to address the following comment:

I just noticed that the latest specification's state machine requires that in order to perform a firmware download, the state must transition from the join to configure to image data. This is a departure from the original protocol, and I believe introduces some challenges. One of the benefits of bypassing the configure state is that it maximizes interoperability across version numbers. If we require the configure state to be run, then we need to ensure that the configure message does not introduce any new message elements that can create a backward compatiblity issue. However, the way the protocol used to be only required that the Join state have to deal with backward compatibility.
 
I'd like to see this changed back to the old way. Sorry I missed this in my reviews.

The -02 specification has state transitions from Join to Configure to Image data, with corresponding text descriptions.
This is unchanged from the -01  specification. The -00 specification had a transition from
DTLS-Complete to Configure and to Image Data.

The current text description includes:

   Join to Configure (g): This state transition is used by the WTP and
      the AC to exchange configuration information.

      WTP: The WTP enters the Configure state when it successfully
         completes the Join operation.  If it determines that its
         version number and the version number advertised by the AC are
         the same, the WTP transmits the Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration.  The WTP also starts the ResponseTimeout timer
         (see ).  (Section 4.5) If the version numbers are not the same,
         the WTP will immediately transition to Image Data state (see
         transition (i)).

and for the AC:

      AC: This state transition occurs immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the Configuration Status message from the WTP, the AC
         must transmit a Configuration Status Response message(see
         Section 8.3) to the WTP, and may include specific message
         elements to override the WTP's configuration.  If the AC
         instead receives the Image Data Request from the WTP, it
         immediately transitions to the Image Data state (see transition
         (i)).

In the current specification, if the WTP received a Discovery Response
message from the AC, it has the AC descriptor data, including the
AC Hardware and Software version numbers, and does not need
to exchange configuration messages to obtain AC HW & SW version info.

If the WTP does not execute the Discovery exchange, then it will
need to obtain the data.

Proposed Resolution:  Insert the following text at the end of 6.2 "Join Response",
so that in all cases, the Configuration messages are not sent:

"The following message element MUST be included in the Join Response message:

- AC Descriptor, see Section 4.4.1"
------------------------------------------------------------------------------------------------
Related observation 1: The current text states that
" If it [WTP] determines that its
         version number and the version number advertised by the AC are
         the same, the WTP transmits the Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration."

This can't be correct - multiple vendors will have different version numbering
schemes.

Proposed change:

from

If it determines that its
         version number and the version number advertised by the AC are
         the same, the WTP transmits the Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration.

to

If it determines that its
         version number and the version number advertised by the AC are
         compatible, the WTP transmits the Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration.

----------------------------------------------------------------------------------------------------------------------
Related observation 2: The current specification provides a means for the WTP to
initiate the move to Image Data from the Configure State, but does not
provide the AC with a similar capability. The current text expects that
the WTP has knowledge of all of the AC versions that it can interoperate with.
How the WTP would make this determination is of course out of scope.
It is also likely that the AC would have similar knowledge, in one central
location.

Proposed Change:

Insert the following sentence as indicated:

      AC: This state transition occurs immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the Configuration Status message from the WTP, the AC
         must transmit a Configuration Status Response message(see
         Section 8.3) to the WTP, and may include specific message
         elements to override the WTP's configuration.  If the AC
         instead receives the Image Data Request from the WTP, it
         immediately transitions to the Image Data state (see transition
         (i)). If the AC determines that a new firmware image should be
         installed on the WTP, the AC initiates a firmware download by sending an Image Data Request
         Message with an Initiate Download message element to the WTP.

Comments welcome,

Thanks,

Dorothy

On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com > wrote:
Pat,
 
I re-openned issue 85 to deal with this issue.
 
Cheers,
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) < pcalhoun@cisco.com> wrote:
I just noticed that the latest specification's state machine requires that in order to perform a firmware download, the state must transition from the join to configure to image data. This is a departure from the original protocol, and I believe introduces some challenges. One of the benefits of bypassing the configure state is that it maximizes interoperability across version numbers. If we require the configure state to be run, then we need to ensure that the configure message does not introduce any new message elements that can create a backward compatiblity issue. However, the way the protocol used to be only required that the Join state have to deal with backward compatibility.
 
I'd like to see this changed back to the old way. Sorry I missed this in my reviews.
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_8737_7541798.1159889973337-- --===============1054719950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1054719950==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 11:56:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmdJ-0003MO-HY for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 11:56:37 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmdI-0003Va-3X for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 11:56:37 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 7E8924315F3 for ; Tue, 3 Oct 2006 08:56:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4D5C743005F for ; Tue, 3 Oct 2006 08:54:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C3024316EE for ; Tue, 3 Oct 2006 08:54:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 056CB4316E2 for ; Tue, 3 Oct 2006 08:54:04 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2006 08:54:05 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208"; a="344346756:sNHT46985812" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k93Fs419031513; Tue, 3 Oct 2006 08:54:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k93Fs3ql005500; Tue, 3 Oct 2006 08:54:03 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Oct 2006 08:54:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Oct 2006 08:54:02 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC021DD5A1@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbm0a2ehp4qLeSgQUyP74tngh7/+gAMlwQw From: "Bob O'Hara (boohara)" To: "Charles Clancy" X-OriginalArrivalTime: 03 Oct 2006 15:54:03.0783 (UTC) FILETIME=[26769970:01C6E704] Authentication-Results: sj-dkim-3.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Margaret Wasserman , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Charles said: If the consensus is to use RSC=0, then I think a disclaimer statement should be added to the security considerations section about the replay possibility in multicast protocols. Overall this is probably sufficient. Bob>> I agree. -Bob _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From mackenzii@dale-carnegie.com Tue Oct 03 17:39:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrym-0006ya-8y for capwap-archive@ietf.org; Tue, 03 Oct 2006 17:39:08 -0400 Received: from 122.84-90-202.mana.pf ([202.90.84.122] helo=dale-carnegie.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUryi-0006hy-Jf for capwap-archive@ietf.org; Tue, 03 Oct 2006 17:39:08 -0400 Message-ID: <01c6e734$59c00570$61555aca@hypersup8c4f80> Date: Tue, 3 Oct 2006 11:39:05 -1000 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Hajar Arevalo" From: "Hajar Arevalo" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_27267_01C6E6E0.88166670" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 2.4 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format. ------=_NextPart_000_27267_01C6E6E0.88166670 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, AMBvlEN ClAvLIS VlAvGRA VALvlUM Economize 60% http://www.tholionmdesunkas.com =20 _____ =20 Blow it out your rocket tubes. Steengo snarled, running his we talk, make decisions. About the future. We have a leader-I dare not Power, Power, Power-hear them protons swirl! ------=_NextPart_000_27267_01C6E6E0.88166670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

AMBvlEN

ClAvLIS

VlAvGRA

VALvlUM

 

Blow it out your rocket tubes. Steengo snarled, running = his
we talk, make decisions. About the future. We have a leader-I dare = not
Power, Power, Power-hear them protons swirl!

------=_NextPart_000_27267_01C6E6E0.88166670-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 18:36:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsrq-0005jh-2d for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 18:36:02 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUsiT-0004ip-AI for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 18:26:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CF3531448033 for ; Tue, 3 Oct 2006 15:26:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3BB6643005F for ; Tue, 3 Oct 2006 15:10:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 075DC144802F for ; Tue, 3 Oct 2006 15:10:04 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 1F6181448036 for ; Tue, 3 Oct 2006 15:09:56 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so293875nfb for ; Tue, 03 Oct 2006 15:09:55 -0700 (PDT) Received: by 10.49.41.12 with SMTP id t12mr1480076nfj; Tue, 03 Oct 2006 15:09:55 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Tue, 3 Oct 2006 15:09:54 -0700 (PDT) Message-ID: <5bfe7a820610031509j5cd0408bhd83476d0e9d1ce1b@mail.gmail.com> Date: Tue, 3 Oct 2006 15:09:55 -0700 From: "Dorothy Stanley" To: "Bob O'Hara (boohara)" In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DC02188E2C@xmb-sjc-237.amer.cisco.com> MIME-Version: 1.0 References: <17B8C6DE4E228348B4939BDA6B05A9DC02188E2C@xmb-sjc-237.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.1 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: Saravanan Govindan , Cheng Hong , capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1120761865==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 8f8f86533ca78e8189563dd2b8fa61af --===============1120761865== Content-Type: multipart/alternative; boundary="----=_Part_17205_4739635.1159913395002" ------=_Part_17205_4739635.1159913395002 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob, all, Comments inline. Thanks, Dorothy On 9/29/06, Bob O'Hara (boohara) wrote: > > > Again, your proposal does not eliminate any attack mechanism and does not > add any functionality to the protocol, only cost and complexity. A repla= yed > frame will be discarded by the MAC, using the normal duplicate frame > detection mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame > sequence number is part of the additional authenticated data) and section > 9.2.9 of 802.11-1999 for the description of these functions. And PLEASE > read 802.11 and 802.11i before again asserting that this proposal is > necessary. > In Section 8.3.3.3.2, the AAD construction for CCMP includes the frame sequence control field =96 and the sequence number, bits 4-15 of the frame equence control field - is masked to 0 in the AAD; s= o that only the fragment number is protected. The TKIP MIC protects neither the fragment number nor the sequence number of the 802.11 frame sequence control field, as the TKIP MIC is MSDU based. In 9.2.9, Duplicate detection and recovery, the text indicates that a STA may omit broadcast/multicast frame data from its duplicate detection cache; if bc/mc data is not included, then normal duplicate frame detection will not apply. As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC. This must be done for EVERY frame received, whether it is a replayed frame or not. This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA. So, the attack, if it can eve= n be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame. The MIC calculation, and encrpt/decrypt is typically performed in hardware in the chipset for CCMP. However, the TKIP MIC calculation is typically performed in the driver, in software. If a STA does not have the proper RSC value, there is a "window of vulnerability" before it receives the correct value, during which the STA can receive and process replayed bc/mc frames. The magnitude of the DOS aspect of this depends on the STA crypto implementation - hw/ccmp - virtually no impact or sw/tkip-some small impact. The larger issue is that the replay protection mechanism guarrantees provided by 802.11i are lost. > -Bob > > > > ------------------------------ > *From:* Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > *Sent:* Thursday, September 28, 2006 5:34 PM > *To:* Bob O'Hara (boohara); Dorothy Stanley > *Cc:* Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB)= ; > capwap@frascone.com; Saravanan Govindan > *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Bob, > > As Dorothy correctly pointed out below, setting the KeyRSC to a value > closer to the current RSC would be better than setting it to a pre-define= d > value zero. > > It is true that 802.11i and 802.1X do not specify what is the KeyRSC valu= e > to be used, since they are trying to provide us a tool to correctly > synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we = are > just disabling the tool. It is not wrong, but just deprives the system a > designed function. > > As for the effectiveness of KeyRSC, setting it to a predefined value of 0 > would pose a greater threat. In a simple example, if the RSC is currently > 1000, and we are mandating the KeyRSC to be always zero, the attacker > basically can safely replay the last 1000 packets to the STA without bein= g > detected. If the KeyRSC can be set to a closer value of the current RSC, > say, 900, the number of possible replayed packets can be reduced to 10 > percent, 100 packets. > > Therefore, I would say, setting the KeyRSC value to zero does place a > bigger threat. Is that how the cisco products implemented? Maybe you coul= d > share with us some other implementation/testing data to prove otherwise. = Or, > you have some other considerations that could defend the replay attack? > > cheers > > Cheng Hong > > > ------------------------------ > *From:* Bob O'Hara (boohara) [mailto:boohara@cisco.com] > *Sent:* Friday, September 29, 2006 5:21 AM > *To:* Dorothy Stanley > *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsso= n > J (LI/EAB); capwap@frascone.com > *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Dorothy, > > The problem with this proposal is that it is no more effective than > sending a value of zero for the KeyRSC. It doesn't eliminate any potenti= al > attacks. It doesn't add any functionality. However, it does add cost an= d > complexity to the protocol. > > -Bob > > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Thursday, September 28, 2006 1:17 PM > *To:* Bob O'Hara (boohara) > *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsso= n > J (LI/EAB); capwap@frascone.com > *Subject:* Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > All, > > Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key > RSC field.: > > "g) Key RSC. This field is 8 octets in length. It contains the receive > sequence counter (RSC) for the > GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way > Handshake and > Message 1 of the Group Key Handshake, where it is used to synchronize the > IEEE 802.11 replay > state. It may also be used in the Michael MIC Failure Report frame, to > report the TSC field value of > the frame experiencing a MIC failure. It shall contain 0 in other > messages. The Key RSC field gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs. If the Key > RSC field value is less than 8 octets in length, the remaining octets > shall be set to 0. The least significant > octet of the TSC or PN should be in the first octet of the Key RSC field.= " > > The intent of adding this value in message 3 was to immediately minimize > the number of > replayed frames that a STA would potentially process: "The Key RSC field > gives > the current message number for the GTK, to allow a STA to identify > replayed MPDUs." > Setting the value to 0 in Msg 3 does not provide the current sequence > counter (in most cases > not even close) of the GTK.. > > Perhaps the WTP could periodically/frequently notify the AC of its curren= t > GTK sequence counter, and the > AC would use the most recently received value in the message 3 sent to ne= w > STAs. The RSC value > would not be up to date at all times, but would be closer than "0", not > require an "in-the-critical-path > message exchange between the AC and WTP, and still be close to the > intended use of the field. > > Dorothy > > On 9/28/06, Bob O'Hara (boohara) wrote: > > > > Please understand that 802.11i specifies no behavior in this area for > > the 802.1X authenticator. Our choice to send a group key KeyRSC value > > of zero in the EAPOL-key frame requires no change to 802.11i or to > > 802.1X . It requires us to state this in the CAPWAP spec, if we want > > this behavior to be consistent across all implementations. > > > > The problem with what Bechet and Saranavan are asking is that either of > > three different things are required: > > 1: the WTP must communicate the group key TSC to the AC every time it i= s > > updated, or > > 2: the AC must request the current value of the group key TSC for the > > KeyRSC before constructing the EAPOL-key frame, or > > 3: the AC must send the KCK to the AC so that it can insert the KeyRSC > > value and also calculate the correct MIC, inserting that into the prope= r > > EAPOL-key frame. > > > > The first item requires a tremendous amount of additional CAPWAP > > communication between WTP and AC, at least one new CAPWAP packet for > > every multicast frame sent by the WTP, if the packet is not > > acknowledged, or two new CAPWAP packets, if it is acknowledged. This i= s > > a very expensive addition to the protocol. > > > > The second item requires new protocol between the AC and WTP during wha= t > > can be a time critical portion of the 802.11 transition (handoff, roam) > > from one WTP to another. It also introduces a race condition that is > > not present in the protocol today. Once the value for the KeyRSC is > > sent from the WTP to the AC, it is possible that the WTP can send > > another multicast frame encrypted with the group key. This puts the > > value of the sequence counter out of sync with the value that will be > > shortly communicated to the client in the EAPOL-key frame from the AC. > > This will behave exactly the same as if a value of zero is sent in the > > EAPOL-key frame. > > > > The third item requires a new architecture split that is not required i= n > > > > our objectives. The new split is not splitting the MAC, but splitting > > the authenticator. Placing the KCK in the WTP is also a potential > > reduction in the security of the overall WLAN system, since these > > devices are normally not in a secured wiring closet, but exposed and > > more easily compromised than the AC. > > > > The simplest to implement, least expensive, and most secure option is t= o > > use the protocol as it is now specified and have the AC send a value of > > zero in the KeyRSC field of the EAPOL-key frame. > > > > -Bob > > > > -----Original Message----- > > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > > Sent: Wednesday, September 27, 2006 6:50 PM > > To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; > > Peter Nilsson J (LI/EAB) > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > > > Hi Pat and all, > > > > So, based on this, I would say that we have consensus that setting the > > correct KeyRSC is an issue for the CAPWAP protocol design. > > > > So far, we have three option/solutions: > > > > 1) As proposed by Bob: Using a static value (0) for the KeyRSC. > > > > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP > > > > 3) As suggested by Saravanana: Some exchange mechanism between WTP and > > AC > > > > Among the three, the first option seems the easiest. However, it > > requires a mandated Authenticator behavior(in this case AC) that is not > > mandated by 802.11. Therefore, we have to specify that (e.g. as propose= d > > by Bob: "We could include a note to the effect that the group KeyRSC > > should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11, > > because otherwise there is no interoperability. For example, AC provide= d > > by another vendor does not have to set KeyRSC to 0 to be compliant with > > CAPWAP and 802.11i. > > > > Another implication is that we don't really understand the impact of > > mandating a static KeyRSC value. Although Bob provided an excellent > > analysis, I still have some doubts about the profoundness of the impact= . > > If the KeyRSC value is as described of no use, why would it appear in > > the EAPOL frames in the first place? By mandating it to static value, > > what have we lost? Maybe some liaison letter to 802.1 or 802.11 could > > provide us a better understanding of the issue. > > > > For the last two options, I think they are both within CAPWAP's scope. > > Further analysis could help us to decide which one is better (or > > someone could propose other solutions). > > > > cheers > > > > Cheng Hong > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com] > > > Sent: Thursday, September 28, 2006 1:39 AM > > > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; > > > Peter Nilsson J (LI/EAB) > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > Considerations > > > > > > Bob's point is 802.11i works this way today. The AP (or in > > > this case AC) can set the RSC to whatever value it wishes. > > > Bob used zero (0) as an example. Implementations could use > > > any other value, which would require some form of > > > communication to the WTP, as suggested by Behcet. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Cheng Hong [mailto: Hong.Cheng@sg.panasonic.com] > > > > Sent: Tuesday, September 26, 2006 6:03 PM > > > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson > > > J (LI/EAB) > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > Considerations > > > > > > > > Hi Bob, > > > > > > > > If I understand your description below correct, you are proposing a > > > > solution (to the problem pointed out by > > > > Saravanan) by mandating the behavior of the AC to always set the > > > > KeyRSC in the 4-way handshake to zero. > > > > > > > > This is not a defined behavior according to the current > > > > 802.11 standard. > > > > Are you suggesting that we CAPWAP WG should specifically > > > mandate that > > > > in our CAPWAP protocol spec, e.g. something like "a CAPWAP > > > compatible > > > > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists, > > > > since not all AC implementation have to follow what you described. > > > > > > > > Or, are you planning to take this issue to TGm for 802.11 standard > > > > revision? (since based on your description, there is essentially no > > > > use of the KeyRSC). > > > > > > > > cheers > > > > > > > > Cheng Hong > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob O'Hara (boohara) [mailto:boohara@cisco.com] > > > > > Sent: Wednesday, September 27, 2006 2:32 AM > > > > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > Charles, Peter, > > > > > > > > > > Below is an expansion of a snippet from a thread on this > > > > topic that I > > > > > sent to the list on July 25, 2006. I think this will be > > > helpful to > > > > > understand why the exchange that Saranavan is requesting is not > > > > > necessary. In fact, there are several systems from several > > > > > manufacturers in the field using precursor protocols to > > > CAPWAP that > > > > > are Wi-Fi certified for WPA2/802.11i operation using the > > > > protocol as > > > > > it is described below. > > > > > > > > > > BTW, this whole discussion is about the KeyRSC for the > > > > group key, not > > > > > the pairwise key. This is so because the WTP and AC both > > > know the > > > > > initial sequence counter value for the pairwise key, since it has > > > > > never been used to send a frame. 802.11i requires the > > > first frame > > > > > sent on a key to use the sequence counter value of 1. See > > > > 8.3.2.6 c) > > > > > and > > > > > 8.3.3.4.3 c) in 802.11i for this requirement. > > > > > > > > > > The same is not true of the group key, i.e., after the WTP begins > > > > > operation, the AC will not know the value of the sequence > > > > counter for > > > > > the group key when it needs to complete the EAPOL-key > > > > handshake with a > > > > > newly associated STA. > > > > > However, as you will see from the tutorial below, it is not > > > > necessary > > > > > for the AC and WTP to exchange any information about the > > > group key > > > > > KeyRSC for the protocol to operate as it is intended. > > > > > > > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to > > > > > calculate the KeyMIC. > > > > > > > > > > 2. This value does not need to bear any specific > > > > relationship to the > > > > > RSC value maintained by the WTP. A value of zero in the > > > EAPOL-key > > > > > frame for the group key will always work. > > > > > > > > > > 3. The client STA will use the value of KeyRSC received in the > > > > > EAPOL-key frame to validate frame using the KeyMIC. > > > > > > > > > > 4. The client STA will also set its group key RSC to the value > > > > > received in KeyRSC, say, zero. > > > > > > > > > > 5. The value in the client STA's RSC will be compared against the > > > > > sequence number in subsequent received frames to identify replay > > > > > attacks. Any frame received with a sequence counter value > > > > within the > > > > > replay window will be checked to have a valid MIC. If the > > > > MIC is not > > > > > valid, the frame is dropped. > > > > > > > > > > 6. For any frame that is determined not to be a replay > > > attack frame > > > > > and meets all other validity and authenticity requirements, > > > > the client > > > > > STA updates its RSC value to the sequence number in the received > > > > > frame, if the value is greater than its current RSC value. > > > > Only the > > > > > AP can meet these criteria as the source of a frame > > > received by the > > > > > STA. > > > > > > > > > > 7. Please see item 6, immediately above, for the reason > > > that the AC > > > > > and WTP do not need to coordinate and exchange the RSC. > > > > > > > > > > > > > > > The only possible attack mode is for the attacker to send > > > frames to > > > > > the client STA between the time of the EAPOL-key frame and > > > > the first > > > > > frame encrypted with the group key. > > > > > During this time, the client will receive the frame and > > > proceed to > > > > > validate its MIC. This is a potential attack against the STA > > > > > resources. But, the MIC validation is done in the STA's > > > > > 802.11 chip and consumes no more resources than receiving > > > any other > > > > > frame. Thus, the attack does not actually consume any STA > > > > resources > > > > > beyond those of receiving a frame. > > > > > > > > > > This attack is not unique to the use of the value zero for > > > > the KeyRSC, > > > > > either. The same attack is available to an attacker at any other > > > > > time, as well. It is no more nor less effective at either time. > > > > > > > > > > For these reasons, the protocol is not in need of any changes to > > > > > address the issue raised by Saranavan. > > > > > > > > > > -Bob > > > > > -----Original Message----- > > > > > From: T. Charles Clancy [mailto:clancy@cs.umd.edu] > > > > > Sent: Monday, September 25, 2006 11:37 AM > > > > > To: Peter Nilsson J (LI/EAB) > > > > > Cc: capwap@frascone.com > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > This is a very interesting solution. The AC selects the > > > KeyRSC and > > > > > performs the 4-way handshake. The WTP sniffs the 4-way handshake > > > > > traffic and grabs the KeyRSC value and uses it to > > > > initialize its own > > > > > counter. > > > > > > > > > > Pat/Bob: Is this how the Cisco implementation works? I > > > > have to agree > > > > > with Saravanan that I've yet to see a technical > > > description of how > > > > > Cisco implements it. > > > > > > > > > > IMHO, this is somewhat hackish, and it would be cleaner to > > > > have the AC > > > > > generate the KeyRSC and include it in the AddMobile message > > > > as Behcet > > > > > suggests. > > > > > > > > > > -- > > > > > t. charles clancy, ph.d. | tcc@umd.edu | > > > www.cs.umd.edu/~clancy > > > > > > > > > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote: > > > > > > > > > > > I think Saravanan has a point. We did a prototype > > > > impelementation of > > > > > the > > > > > > protocol a year ago when it was still called LWAPP. The way > > > > > we solved > > > > > > this issue then was to let the WTP sniff on all CAPWAP data > > > > > messages > > > > > > from the AC and when message 3 of the 4-way handshake or > > > > > message 1 of > > > > > > the groupkey handshake was sent the WTP inserted the correct RS= C > > > > > before > > > > > > sending it off to the supplicant. To avoid the sniffing on > > > > > all CAPWAP > > > > > > data messages we would need a mechanism with in CAPWAP to > > > > > handle these > > > > > > two messages. > > > > > > > > > > > > Peter Nilsson > > > > > > > > > > > > -----Original Message----- > > > > > > From: Saravanan Govindan > > > > > [mailto:Saravanan.Govindan@sg.panasonic.com] > > > > > > Sent: den 22 september 2006 11:03 > > > > > > To: Margaret Wasserman > > > > > > Cc: capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > Hi Margaret, > > > > > > > > > > > > Thank you for reviewing the discussion on this issue. > > > > > > > > > > > > The issue here is the working of IEEE 802.11i when the 802.11i > > > > > > authenticator element is at the AC and the 802.11i crypto > > > > element is > > > > > at > > > > > > the WTP. Particularly, it is for the 4-way handshake between > > > > > > authenticator and supplicant. > > > > > > > > > > > > Now, the 4-way handshake requires knowing the value of > > > > > KeyRSC sequence > > > > > > counter. The KeyRSC helps both authenticator and supplicant > > > > > keep track > > > > > > of their exchanges. It serves to protect against threats by > > > > > tracking > > > > > > sequential frames. The KeyRSC is maintained at the at the > > > > point of > > > > > > encryption, i.e. just before transmission over the > > > > wireless channel. > > > > > > > > > > > > In the case of CAPWAP, the 4-way handshake is between the AC > > > > > > (authenticator) and the wireless station (supplicant). > > > > > > > > > > > > The problem arises, when the authenticator is at the AC and > > > > > the crypto > > > > > > element (together with KeyRSC) is at the WTP. This is a > > > > > fairly common > > > > > > design. Now in this case, the AC starts the 4-way > > > handshake but it > > > > > does > > > > > > not know the value of the KeyRSC. The KeyRSC is maintained > > > > > by the WTP. > > > > > > > > > > > > Based on this, the current CAPWAP specification does not > > > > allow for a > > > > > way > > > > > > to conduct the 4-way handshake with the correct KeyRSC. > > > > > > > > > > > > The functionality I would like to see is a way for the > > > > authenticator > > > > > > (AC) to use the correct prevailing value of KeyRSC > > > > > (maintained by the > > > > > > WTP) in its 4-way handshake. > > > > > > > > > > > > One way to introduce this functionality in to CAPWAP is > > > > to have part > > > > > of > > > > > > the 4-way handshake be sent from AC to WTP. This will allow > > > > > the 4-way > > > > > > handshake to use the correct value of the KeyRSC before > > > > > being sent to > > > > > > the wireless station. > > > > > > > > > > > > I hope this helps clarify my view on the issue. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > > > > > > Sent: Thursday, September 21, 2006 8:26 PM > > > > > > To: Saravanan Govindan > > > > > > Cc: Pat Calhoun (pacalhou); capwap@frascone.com > > > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > > > > Considerations > > > > > > > > > > > > > > > > > > > > > > > > Hi again, > > > > > > > > > > > > Okay, I am even more confused than I thought I was... > > > > > > > > > > > > Saravanan, you wrote: > > > > > > > > > > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote: > > > > > > > > > > > >> Pat, > > > > > >> > > > > > >> The issue here is about how 802.11i exchanges are done when > > > > > >> authenticator is at the AC and crypto elements are at > > > > the WTP. This > > > > > is > > > > > >> the requirement. > > > > > > > > > > > > And, in response, Pat Calhoun wrote: > > > > > > > > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: > > > > > >> The current specification allows the authenticator to > > > > > reside in the > > > > > >> AC, while the data packet crypto elements in the WTP. This > > > > > feature is > > > > > >> already in the specification. > > > > > > > > > > > > Pat's message matches my reading of the specification. > > > > > > > > > > > > So, Saravanan, what functionality are you asking for > > > that is not > > > > > > already supported by the specification? And why do you > > > > think it is > > > > > > necessary? it will not be helpful to my understanding to > > > > > re-send your > > > > > > proposal or to cite the requirements document... Please > > > > summarize > > > > > > what functionality you think is missing from the current > > > > > specification > > > > > > and why you think that functionality is necessary to > > > support IEEE > > > > > > 802.11i or any important use case. > > > > > > > > > > > > At some point, the chairs may need to make a consensus > > > > call on this > > > > > > issue, and I'd like to understand your view and make sure > > > > > that it has > > > > > > been clearly communicated to the WG before we ask the WG to > > > > > decide on > > > > > > this issue. > > > > > > > > > > > > Thanks, > > > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > To unsubscribe or modify your subscription options, > > > please visit: > > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > > > > > > To unsubscribe or modify your subscription options, > > > please visit: > > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options, please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------=_Part_17205_4739635.1159913395002 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob, all,

Comments inline.

Thanks,

Dorothy

On 9/29/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:
 
Again, your proposal does not eliminate any attack=20 mechanism and does not add any functionality to the protocol, only cost and= =20 complexity.  A replayed frame will be discarded by the MAC, using the= =20 normal duplicate frame detection mechanisms.  See section=20 8.3.3= .3.2 of 802.11i (where the frame sequence number is part of the=20 additional authenticated data) and section 9.2.9 of 802.11-1999 for th= e=20 description of these functions.  And PLEASE read 802.11 and 802.11i be= fore=20 again asserting that this proposal is necessary.
<= /blockquote>

In Section 8.3.3.3.2, the AAD construction for CCMP&= nbsp; includes the frame=20 sequence control field =96 and the sequence number,
bits 4-15 of the frame equence control field - is masked to 0=20 in the AAD; so that only the fragment number is protected.

The TKIP MIC protects neither the fragment number nor the sequence number of  the 802.11 frame sequence control field, as the TKIP MIC
is MSDU based.

In 9.2.9, Duplicate detection and recovery, the text= indicates=20 that a STA may omit
broadcast/multicast frame data from its duplicate=20 detection cache; if bc/mc data is not included, then normal
duplicate frame detection will not=20 apply.

 As I said several emails ago, the ONLY effect of us= ing zero=20 as the value for the KeyRSC is that the 802.11 chipset in the STA (client) = will=20 have to receive the frame, attempt to decrypt it, and validate the MIC.&nbs= p;=20 This must be done for EVERY frame received, whether it is a replayed frame = or=20 not.  This set of functions is performed in the 802.11 STA chipset and= does=20 not consume any additional resources of the STA.  So, the attack, if i= t can=20 even be characterized as an attack, is no more effective at DOSing the STA = than=20 sending it any other frame.

The MIC calculation, and encrpt/decrypt is typically= performed in hardware in the chipset for CCMP.
However, the TKIP MIC calculation is typically performed=20 in the driver, in software.

If a STA does not have the proper RSC value, there i= s a "window of vulnerability" before it receives
the correct value, during
which the STA can receive and process replayed  bc/mc frames. The magn= itude of the DOS aspect of this
depends on the STA crypto implementation - hw/ccmp - virtually no impact or= sw/tkip-some small impact.
The larger issue is that the replay protection mechanism guarrantees provid= ed by 802.11i are lost.

 -Bob
 

 

From: Cheng Hong= =20 [mailto:Hong.Cheng@sg.panaso= nic.com]
Sent: Thursday, September 28,=20 2006 5:34 PM

To: Bob O'Hara (boohara); Dorothy Stanley
Cc:=20 Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com; Saravanan G= ovindan
Subject: RE: [Capwap] Issue 43=20 - Explanation for 802.11i Considerations

<= div>
Hi=20 Bob,
=  
As=20 Dorothy correctly pointed out below, setting the KeyRSC to a value closer t= o the=20 current RSC would be better than setting it to a pre-defined value zero.=20
=  
It is=20 true that 802.11i and 802.1X do not specify what is the KeyRSC value to be = used,=20 since they are trying to provide us a tool to correctly synchronize the RSC= =20 using the Msg 3. By mandating the KeyRSC to zero, we are just disabling the= =20 tool. It is not wrong, but just deprives the system a designed=20 function.
=  
As for=20 the effectiveness of KeyRSC, setting it to a predefined value of 0 would po= se a=20 greater threat. In a simple example, if the RSC is currently 1000, and we a= re=20 mandating the KeyRSC to be always zero, the attacker basically can saf= ely=20 replay the last 1000 packets to the STA without being detected. If the= =20 KeyRSC can be set to a closer value of the current RSC, say, 900, the numbe= r of=20 possible replayed packets can be reduced to 10 percent, 100 packets.= =20
=  
Therefore, I w= ould say, setting the KeyRSC value to zero does place a=20 bigger threat. Is that how the cisco products implemented? Maybe you could = share=20 with us some other implementation/testing data to prove otherwise. Or, you = have=20 some other considerations that could defend the replay=20 attack?
=  
cheers<= /span>
=  
Cheng=20 Hong
=  

From: Bob O'Hara (boohara)=20 [mailto:boohara@cisco.com]
<= b>Sent: Friday, September 29, 2006 5:21=20 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat Calhoun=20 (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);=20 capwap@frascone.com
Subj= ect: RE: [Capwap] Issue 43 - Explanation for=20 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it is no more=20 effective than sending a value of zero for the KeyRSC.  It does= n't=20 eliminate any potential attacks.  It doesn't add any=20 functionality.  However, it does add cost and complexity t= o the=20 protocol. 

 -Bob
 

 

All,

Below is the text from 802.11REV-maD8.0 Clause 8.5= .2,=20 describing the Key RSC field.:

"g) Key=20 RSC. This field is 8 octets in length. It contains the receive sequence= =20 counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in= =20 Message 3 of the 4-Way Handshake and
Message 1 of the=20 Group Key Handshake, where it is used to synchronize the IEEE 802.11=20 replay
state. It may also be used in the Michael MIC=20 Failure Report frame, to report the TSC field value of
the frame=20 experiencing a MIC failure. It shall contain 0 in other messages. The Key= RSC=20 field gives
the current message number for the GTK, to allow a=20 STA to identify replayed MPDUs. If the Key
RSC field value is=20 less than 8 octets in length, the remaining octets shall be set to 0. The= =20 least significant
octet of the TSC or PN should be in the first octet=20 of the Key RSC field."

The intent of adding this value= in=20 message 3 was to immediately minimize the number of
replayed frames t= hat a=20 STA would potentially process: "The Key RSC field gives
the curre= nt message=20 number for the GTK, to allow a STA to identify replayed MPDUs."
S= etting the=20 value to 0 in Msg 3 does not provide the current sequence counter (in mos= t=20 cases
not even close) of the GTK..

Perhaps the WTP could=20 periodically/frequently notify the AC of its current GTK sequence counter= , and=20 the
AC would use the most recently received value in the message 3 sen= t to=20 new STAs. The RSC value
would not be  up to date at all times, bu= t=20 would be closer than "0", not require an "in-the-critical-= path
message=20 exchange between the AC and WTP, and still be close to the intended use o= f the=20 field.

Dorothy

On 9/28/06, Bob O'Hara=20 (boohara) <boohara@cisco.com<= /a>>=20 wrote:=20
Please=20 understand that 802.11i specifies no behavior in this area for
the 8= 02.1X=20 authenticator.  Our choice to send a group key KeyRSC valueof=20 zero in the EAPOL-key frame requires no change to 802.11i or to
802.= 1X=20 .  It requires us to state this in the CAPWAP spec, if we=20 want
this behavior to be consistent across all=20 implementations.

The problem with what Bechet and Saranavan are= =20 asking is that either of
three different things are required:
1:= the=20 WTP must communicate the group key TSC to the AC every time it=20 is
updated, or
2: the AC must request the current value of the gr= oup=20 key TSC for the
KeyRSC before constructing the EAPOL-key frame, or3:=20 the AC must send the KCK to the AC so  that it can insert the= =20 KeyRSC
value and also calculate the correct MIC, inserting that into= the=20 proper
EAPOL-key frame.

The first item requires a tremendous= =20 amount of additional CAPWAP
communication between WTP and AC, at le= ast=20 one new CAPWAP packet for
every multicast frame sent by the WTP, if = the=20 packet is not
acknowledged, or two new CAPWAP packets, if it is=20 acknowledged.  This is
a very expensive addition to the=20 protocol.

The second item requires new protocol between the AC = and=20 WTP during what
can be a time critical portion of the 802.11 transit= ion=20 (handoff, roam)
from one WTP to another.  It also introduc= es a=20 race condition that is
not present in the protocol=20 today.  Once the value for the KeyRSC is
sent from the WTP= to=20 the AC, it is possible that the WTP can send
another multicast frame= =20 encrypted with the group key.  This puts the
value of the= =20 sequence counter out of sync with the value that will be
shortly=20 communicated to the client in the EAPOL-key frame from the AC.
This = will=20 behave exactly the same as if a value of zero is sent in the
EAPOL-k= ey=20 frame.

The third item requires a new architecture split that is = not=20 required in
our objectives.  The new split is not splitti= ng=20 the MAC, but splitting
the authenticator.  Placing the KCK= in=20 the WTP is also a potential
reduction in the security of the overall= WLAN=20 system, since these
devices are normally not in a secured wiring clo= set,=20 but exposed and
more easily compromised than the AC.

The sim= plest=20 to implement, least expensive, and most secure option is to
use the= =20 protocol as it is now specified and have the AC send a value of
zero= in=20 the KeyRSC field of the EAPOL-key frame.

-Bob

-----Origi= nal=20 Message-----
From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]
Sent:=20 Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bo= b=20 O'Hara (boohara); T. Charles Clancy;
Peter Nilsson J (LI/EAB)
Cc= : capwap@frascone.com
Subject= : RE:=20 [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Pa= t and=20 all,

So, based on this, I would say that we have consensus that= =20 setting the
correct KeyRSC is an issue for the CAPWAP protocol=20 design.

So far, we have three option/solutions:

1) As pro= posed=20 by Bob: Using a static value (0) for the KeyRSC.

2) As suggested= by=20 Behcet: AC communicate a correct KeyRSC to WTP

3) As suggested = by=20 Saravanana: Some exchange mechanism between WTP and
AC

Among = the=20 three, the first option seems the easiest. However, it
requires a=20 mandated Authenticator behavior(in this case AC) that is not
mandat= ed by=20 802.11. Therefore, we have to specify that (e.g. as proposed
by Bob:= "We=20 could include a note to the effect that the group KeyRSC
should be z= ero=20 in the EAPOL-key frame.") either in CAPWAP or 802.11,
because o= therwise=20 there is no interoperability. For example, AC provided
by another ve= ndor=20 does not have to set KeyRSC to 0 to be compliant with
CAPWAP and=20 802.11i.

Another implication is that we don't really understand = the=20 impact of
mandating a static KeyRSC value. Although Bob provided an= =20 excellent
analysis, I still have some doubts about the profoundness = of=20 the impact.
If the KeyRSC value is as described of no use, why would= it=20 appear in
the EAPOL frames in the first place? By mandating it to st= atic=20 value,
what have we lost? Maybe some liaison letter to 802.1 or 802.= 11=20 could
provide us a better understanding of the issue.

For the= last=20 two options, I think they are both within CAPWAP's scope.
Further= =20 analysis could help us to decide which one  is better=20 (or
someone could propose other solutions).

cheers

Che= ng=20 Hong







> -----Original Message-----
= >=20 From: Pat Calhoun (pacalhou) [mailto: pcalhoun@cisco.com]
> Sent:=20 Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara= =20 (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> = Cc:=20 capwap@frascone.com
>= =20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
>=20 Considerations
>
> Bob's point is 802.11i works this way to= day.=20 The AP (or in
> this case AC) can set the RSC to whatever value = it=20 wishes.
> Bob used zero (0) as an example. Implementations could= =20 use
> any other value, which would require some form of
>= =20 communication to the WTP, as suggested by Behcet.
>
> Pat= =20 Calhoun
> CTO, Wireless Networking Business Unit
> Cisco=20 Systems
>
>
>
> > -----Original=20 Message-----
> > From: Cheng Hong [mailto:=20 Hong.Cheng@sg.panasonic.com]
> > Sent: Tuesday, September = 26,=20 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; = Peter=20 Nilsson
> J (LI/EAB)
> > Cc: capwap@frascone.com
> >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> >= =20 Considerations
> >
> > Hi Bob,
> >
> &= gt;=20 If I understand your description below correct, you are proposing a >=20 > solution (to the problem pointed out by
> > Saravanan) by= =20 mandating the behavior of the AC to always set the
> > KeyRSC = in=20 the 4-way handshake to zero.
> >
> > This is not a de= fined=20 behavior according to the current
> > 802.11 standard.
>= ;=20 > Are you suggesting that we CAPWAP WG should specifically
>= =20 mandate that
> > in our CAPWAP protocol spec, e.g. something l= ike=20 "a CAPWAP
> compatible
> > AC MUST set KeyRSC to ze= ro"?=20 Otherwise, the problem still exists,
> > since not all AC=20 implementation have to follow what you described.
> >
> = >=20 Or, are you planning to take this issue to TGm for 802.11 standard
&= gt;=20 > revision? (since based on your description, there is essentially= =20 no
> > use of the KeyRSC).
> >
> > cheers>=20 >
> > Cheng Hong
> >
> >
> >>=20 >
> > > -----Original Message-----
> > > Fro= m:=20 Bob O'Hara (boohara) [mailto:booha= ra@cisco.com]
> > >=20 Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T.= =20 Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > >= =20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > = >=20 Considerations
> > >
> > > Charles, Peter,
&= gt;=20 > >
> > > Below is an expansion of a snippet from a t= hread=20 on this
> > topic that I
> > > sent to the list on= July=20 25, 2006.  I think this will be
> helpful to
> &= gt;=20 > understand why the exchange that Saranavan is requesting is not>=20 > > necessary.  In fact, there are several systems from= =20 several
> > > manufacturers in the field using precursor=20 protocols to
> CAPWAP that
> > > are Wi-Fi certified= for=20 WPA2/802.11i operation using the
> > protocol as
> > = >=20 it is described below.
> > >
> > > BTW, this wh= ole=20 discussion is about the KeyRSC for the
> > group key, not
= >=20 > > the pairwise key.  This is so because the WTP and A= C=20 both
> know the
> > > initial sequence counter value = for=20 the pairwise key, since it has
> > > never been used to sen= d a=20 frame.   802.11i requires the
> first frame
> >= ;=20 > sent on a key to use the sequence counter value of=20 1.  See
> > 8.3.2.6= =20 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for = this=20 requirement.
> > >
> > > The same is not true o= f the=20 group key, i.e., after the WTP begins
> > > operation, the = AC=20 will not know the value of the sequence
> > counter for
&g= t;=20 > > the group key when it needs to complete the EAPOL-key
>= >=20 handshake with a
> > > newly associated STA.
> > &= gt;=20 However, as you will see from the tutorial below, it is not
> >= ;=20 necessary
> > > for the AC and WTP to exchange any informat= ion=20 about the
> group key
> > > KeyRSC for the protocol t= o=20 operate as it is intended.
> > >
> > > 1. A val= ue=20 for the KeyRSC in the EAPOL-key frame is necessary to
> > >= ;=20 calculate the KeyMIC.
> > >
> > > 2. This value= does=20 not need to bear any specific
> > relationship to the
> = >=20 > RSC value maintained by the WTP.  A value of zero in the= =20
> EAPOL-key
> > > frame for the group key will alway= s=20 work.
> > >
> > > 3. The client STA will use th= e=20 value of KeyRSC received in the
> > > EAPOL-key frame to=20 validate frame using the KeyMIC.
> > >
> > > 4= . The=20 client STA will also set its group key RSC to the value
> > &g= t;=20 received in KeyRSC, say, zero.
> > >
> > > 5. T= he=20 value in the client STA's RSC will be compared against the
> >= ;=20 > sequence number in subsequent received frames to identify=20 replay
> > > attacks.  Any frame received with a= =20 sequence counter value
> > within the
> > > replay= =20 window will be checked to have a valid MIC.  If the
> = >=20 MIC is not
> > > valid, the frame is dropped.
> >= =20 >
> > > 6. For any frame that is determined not to be a= =20 replay
> attack frame
> > > and meets all other valid= ity=20 and authenticity requirements,
> > the client
> > &g= t;=20 STA updates its RSC value to the sequence number in the received
>= ;=20 > > frame, if the value is greater than its current RSC value.>=20 > Only the
> > > AP can meet these criteria as the sourc= e of=20 a frame
> received by the
> > > STA.
> >=20 >
> > > 7. Please see item 6, immediately above, for the= =20 reason
> that the AC
> > > and WTP do not need to=20 coordinate and exchange the RSC.
> > >
> >=20 >
> > > The only possible attack mode is for the attacke= r to=20 send
> frames to
> > > the client STA between the tim= e of=20 the EAPOL-key frame and
> > the first
> > > frame= =20 encrypted with the group key.
> > > During this time, the c= lient=20 will receive the frame and
> proceed to
> > > validat= e its=20 MIC.  This is a potential attack against the STA
> >= ;=20 > resources.  But, the MIC validation is done in the=20 STA's
> > > 802.11 chip and consumes no more resources than= =20 receiving
> any other
> > > frame.  Thus, t= he=20 attack does not actually consume any STA
> > resources
>= ;=20 > > beyond those of receiving a frame.
> > >
> = >=20 > This attack is not unique to the use of the value zero for
>= >=20 the KeyRSC,
> > > either.  The same attack is=20 available to an attacker at any other
> > > time, as=20 well.  It is no more nor less effective at either time.
&g= t;=20 > >
> > > For these reasons, the protocol is not in n= eed=20 of any changes to
> > > address the issue raised by Saranav= an.=20
> > >
> > >  -Bob
> > >= =20 -----Original Message-----
> > > From: T. Charles Clancy=20 [mailto:clancy@cs.umd.edu]>=20 > > Sent: Monday, September 25, 2006 11:37 AM
> > > = To:=20 Peter Nilsson J (LI/EAB)
> > > Cc: capwap@frascone.com
> > >=20 Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > &= gt;=20 Considerations
> > >
> > > This is a very=20 interesting solution.  The AC selects the
> KeyRSC=20 and
> > > performs the 4-way handshake.  The WTP= =20 sniffs the 4-way handshake
> > > traffic and grabs the KeyR= SC=20 value and uses it to
> > initialize its own
> > >= =20 counter.
> > >
> > > Pat/Bob: Is this how the C= isco=20 implementation works?  I
> > have to agree
> &= gt;=20 > with Saravanan that I've yet to see a technical
> descripti= on of=20 how
> > > Cisco implements it.
> > >
> &g= t;=20 > IMHO, this is somewhat hackish, and it would be cleaner to
>= >=20 have the AC
> > > generate the KeyRSC and include it in the= =20 AddMobile message
> > as Behcet
> > >=20 suggests.
> > >
> > > --
> > > t.= =20 charles clancy, ph.d.  |  tcc@umd.edu  |
> www.cs.umd.edu/~clancy
> >=20 >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB)=20 wrote:
> > >
> > > > I think Saravanan has a= =20 point. We did a prototype
> > impelementation of
> >= >=20 the
> > > > protocol a year ago when it was still called= =20 LWAPP. The way
> > > we solved
> > > > this = issue=20 then was to let the WTP sniff on all CAPWAP data
> > > mess= ages=20
> > > > from the AC and when message 3 of the 4-way=20 handshake or
> > > message 1 of
> > > > the= =20 groupkey handshake was sent the WTP inserted the correct RSC
> &g= t;=20 > before
> > > > sending it off to the supplicant. T= o=20 avoid the sniffing on
> > > all CAPWAP
> > > &g= t;=20 data messages we would need a mechanism with in CAPWAP to
> > = >=20 handle these
> > > > two messages.
> > >=20 >
> > > > Peter Nilsson
> > > >
>= ;=20 > > > -----Original Message-----
> > > > From:= =20 Saravanan Govindan
> > > [mailto:Saravanan.Govindan@sg.panasonic.com]
&g= t;=20 > > > Sent: den 22 september 2006 11:03
> > > >= To:=20 Margaret Wasserman
> > > > Cc: capwap@frascone.com
> > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> &= gt;=20 > Considerations
> > > >
> > > > Hi=20 Margaret,
> > > >
> > > > Thank you for= =20 reviewing the discussion on this issue.
> > > >
> = >=20 > > The issue here is the working of IEEE 802.11i when the=20 802.11i
> > > > authenticator element is at the AC and t= he=20 802.11i crypto
> > element is
> > > at
> >= ;=20 > > the WTP. Particularly, it is for the 4-way handshake between= =20
> > > > authenticator and supplicant.
> > >= =20 >
> > > > Now, the 4-way handshake requires knowing t= he=20 value of
> > > KeyRSC sequence
> > > > count= er.=20 The KeyRSC helps both authenticator and supplicant
> > > k= eep=20 track
> > > > of their exchanges. It serves to protect= =20 against threats by
> > > tracking
> > > >=20 sequential frames. The KeyRSC is maintained at the at the
> > = point=20 of
> > > > encryption, i.e. just before transmission ove= r=20 the
> > wireless channel.
> > > >
> > = >=20 > In the case of CAPWAP, the 4-way handshake is between the AC
&= gt;=20 > > > (authenticator) and the wireless station=20 (supplicant).
> > > >
> > > > The problem= =20 arises, when the authenticator is at the AC and
> > > the= =20 crypto
> > > > element (together with KeyRSC) is at the = WTP.=20 This is a
> > > fairly common
> > > > desig= n.=20 Now in this case, the AC starts the 4-way
> handshake but it
&= gt;=20 > > does
> > > > not know the value of the KeyRSC.= The=20 KeyRSC is maintained
> > > by the WTP.
> > >= =20 >
> > > > Based on this, the current CAPWAP specifica= tion=20 does not
> > allow for a
> > > way
> > &g= t;=20 > to conduct the 4-way handshake with the correct KeyRSC.
> &= gt;=20 > >
> > > > The functionality I would like to see = is a=20 way for the
> > authenticator
> > > > (AC) to u= se=20 the correct prevailing value of KeyRSC
> > > (maintained by= the=20
> > > > WTP) in its 4-way handshake.
> > >= =20 >
> > > > One way to introduce this functionality in = to=20 CAPWAP is
> > to have part
> > > of
> > &= gt;=20 > the 4-way handshake be sent from AC to WTP. This will allow
&g= t;=20 > > the 4-way
> > > > handshake to use the correct= =20 value of the KeyRSC before
> > > being sent to
> >= >=20 > the wireless station.
> > > >
> > > >= ; I=20 hope this helps clarify my view on the issue.
> > >=20 >
> > > > Cheers,
> > > >
> >= >=20 > Saravanan
> > > >
> > > >
> &g= t;=20 > >
> > > >
> > > >
> > &= gt;=20 >
> > > > -----Original Message-----
> > >= ;=20 > From: Margaret Wasserman [mailto:margaret@thingmagic.com]
>=20 > > > Sent: Thursday, September 21, 2006 8:26 PM
> >= >=20 > To: Saravanan Govindan
> > > > Cc: Pat Calhoun=20 (pacalhou); capwap@frascone.com<= /a>
> > >=20 > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> &= gt;=20 > Considerations
> > > >
> > > >
&g= t;=20 > > >
> > > > Hi again,
> > >=20 >
> > > > Okay, I am even more confused than I though= t I=20 was...
> > > >
> > > > Saravanan, you=20 wrote:
> > > >
> > > > On Sep 17, 2006, a= t=20 10:24 PM, Saravanan Govindan wrote:
> > > >
> >= >=20 >> Pat,
> > > >>
> > > >> Th= e=20 issue here is about how 802.11i exchanges are done when
> > &g= t;=20 >> authenticator is at the AC and crypto elements are at
> = >=20 the WTP. This
> > > is
> > > >> the=20 requirement.
> > > >
> > > > And, in resp= onse,=20 Pat Calhoun wrote:
> > > >
> > > > On Sep= 18,=20 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > >= >=20 The current specification allows the authenticator to
> > >= =20 reside in the
> > > >> AC, while the data packet cryp= to=20 elements in the WTP. This
> > > feature is
> > &g= t;=20 >> already in the specification.
> > > >
> &= gt;=20 > > Pat's message matches my reading of the specification.
>= ;=20 > > >
> > > > So, Saravanan, what functionality= are=20 you asking for
> that is not
> > > > already supp= orted=20 by the specification?  And why do you
> > think it= =20 is
> > > > necessary?  it will not be helpful = to my=20 understanding to
> > > re-send your
> > > >= =20 proposal or to cite the requirements document...  Please
&= gt;=20 > summarize
> > > > what functionality you think is= =20 missing from the current
> > > specification
> > &= gt;=20 > and why you think that functionality is necessary to
> supp= ort=20 IEEE
> > > > 802.11i or any important use case.
> = >=20 > >
> > > > At some point, the chairs may need to = make=20 a consensus
> > call on this
> > > > issue, and= I'd=20 like to understand your view and make sure
> > > that it= =20 has
> > > > been clearly communicated to the WG before w= e ask=20 the WG to
> > > decide on
> > > > this=20 issue.
> > > >
> > > > Thanks,
> &= gt;=20 > > Margaret
> > > >
> > > >
>= ;=20 > > >
> > > >
> > > >
> &g= t;=20 > >
> > > >
>=20 _________________________________________________________________
&= gt;=20 > > > To unsubscribe or modify your subscription options,
&= gt;=20 please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capw= ap=20
> > > >
> > > > Archives: http://lists.frascone.com/pipe= rmail/capwap
>=20 > > >
>=20 _________________________________________________________________
&= gt;=20 > > > To unsubscribe or modify your subscription options,
&= gt;=20 please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capw= ap=20
> > > >
> > > > Archives: http://lists.frascone.com/pipe= rmail/capwap
>=20 > > >
> > >=20 _________________________________________________________________
&= gt;=20 > > To unsubscribe or modify your subscription options, please=20 visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
&g= t;=20 > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
&g= t;=20 > >=20 _________________________________________________________________
&g= t;=20 > > To unsubscribe or modify your subscription options, please vi= sit:=20
> > > http://lists.frascone.com/mailman/listinfo/capwap
>=20 > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
>= ;=20 > >
> >=20 _________________________________________________________________
&g= t;=20 > To unsubscribe or modify your subscription options, please visit:= =20
> > http://lists.frascone.com/mailman/listinfo/capwap
>=20 >
> > Archives: http://lists.frascone.com/pipermail/capwap=20
> >
>=20 _________________________________________________________________
&g= t; To=20 unsubscribe or modify your subscription options, please visit:
> = http://lists.= frascone.com/mailman/listinfo/capwap
>
>=20 Archives: http:/= /lists.frascone.com/pipermail/capwap
>
_______________________= __________________________________________=20
To unsubscribe or modify your subscription options, please visit:http://list= s.frascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.fra= scone.com/pipermail/capwap


------=_Part_17205_4739635.1159913395002-- --===============1120761865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1120761865==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 18:41:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUswl-0000KI-98 for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 18:41:07 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUswg-0000Sc-EM for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 18:41:07 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id F09F2431DBA for ; Tue, 3 Oct 2006 15:40:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ABD0D43005F for ; Tue, 3 Oct 2006 15:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 98C2E1448033 for ; Tue, 3 Oct 2006 15:28:22 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by hermes.tigertech.net (Postfix) with ESMTP id 1C2421448032 for ; Tue, 3 Oct 2006 15:28:14 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so298121nfb for ; Tue, 03 Oct 2006 15:28:13 -0700 (PDT) Received: by 10.49.8.1 with SMTP id l1mr1543690nfi; Tue, 03 Oct 2006 15:28:13 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Tue, 3 Oct 2006 15:28:13 -0700 (PDT) Message-ID: <5bfe7a820610031528q55c3a59fu8cd8359610d81258@mail.gmail.com> Date: Tue, 3 Oct 2006 15:28:13 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Subject: [Capwap] Proposed Resolution to Issue 143: Specification for the usage of CERTS for CAPWAP/was CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1833388578==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce --===============1833388578== Content-Type: multipart/alternative; boundary="----=_Part_17429_13988300.1159914493225" ------=_Part_17429_13988300.1159914493225 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Proposed resolutions for the several components of Issue 143 are included below. Issue 143 is also copied below. Comments please. Thanks, Dorothy ---------------------------------------------------------------------------------------------------------- 1) It should be OK for the clock on a WTP to be "wacky", due to having no battery backed up clock, the battery going bad, the clock never set properly. On the other hand, an AC's clock should be set pretty accurately. I't not sure that the recommendations support this scenario. In general, want to support: 0) WTPs with no management interface (other than CAPWAP) 1) first time use of WTP after being manufactured 2) continued use of WTP after long time operation 3) continued use in short term deployments (such as WiFi network used by a Circus that moves from town to town (setting up and tearing down for for each move), or for the WiFi network used at conferences (such as the IETF). Proposed resolution: Adopt Charles' Clancy's recommendation to Replace the following text: Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real- time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD attempt to determine the current time using NTP prior to certificate validation. If neither is available, devices SHOULD verify that the start validity date of its peer's certificate is less than its own certificate's expiration date, and its peer's expiration date is greater than its own start date. Note that failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation. with Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD make a best-effort attempt to validate the certificate validity dates through other means. Failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation. ---------------------------------------------------------------------------------------------- 2) The new text suggests the common name in the format "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies that "DOMAIN.NET " is the "administrative domain". To me, "administrative domain" implies the user of the WTP. But, I believe that the WTP manufacturer must be required to generate a CERT (and the WTP should come "preloaded" with the CERT), and the user of the WTP should not have to create the WTP CERT. (By the way, not sure how long the CERT should be valid.) Thus, I see no need or desire for "@DOMAIN.NET " added to the common name, and suggest that it be removed. (Also, I think that we have now a new requirement to be able via CAPWAP to replace the WTP's CERT with another, and may be to add CA CERTs for the AC's CERT chain. Also, what is the min depth that a WTP should support?) Proposed Resolution: Adopt David's suggestion to drop the @DOMAIN.NET and add a sentence describing the storage requirements on the WTP and AC: Change from: Another important part of certificate authentication is binding a certificate to a particular device. There are many ways to accomplish this. CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, followed by an @ symbol, and then an administrative domain. For example, 01:23:45:67:89:ab@DOMAIN.NET. During authentication, devices SHOULD ensure that the MAC matches the MAC specified in the CAPWAP header, and that the domain in both the AC and WTP certificates match. to Another important part of certificate authentication is binding a certificate to a particular device. There are many ways to accomplish this. CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab. During authentication, devices SHOULD ensure that the MAC address matches the MAC address specified in the CAPWAP header. If this mechanism is used, the ACs SHOULD maintain list of all authorized WTP MAC addresses and the WTP SHOULD save the AC credential or credential identifier. --------------------------------------------------------------------------------------------------------- 3) specify that WTP CERTs cannot be selfsigned, and MUST have a common name of the ASCII of the MAC address (or other unique ID, such as serial number) Proposed resolution: No change to the text regarding use of self-signed certs. While the use of self-signed certs may not be widespread, there isn't a compelling need to preclude their use in a CAPWAP application. Change the text to require that WTP certs MUST have a common mane of the ASCII of the MAC address: from: CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab. to Specificaiton of the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab is REQUIRED for use with the CAPWAP protocol. --------------------------------------------------------------------------------------------------------- 4) The Join Request must be updated to include the common name as a message element Proposed resolution: No change to the text. The join request currenly includes the BSSID. Also, since the JOIN occurs inside the DTLS tunnel, it is implicitly bound to the MAC (assuming certs were used for authentication, and this is N/A for preshared key authentication). ---------------------------------------------------------------------------------------------------------- 5) specify that WTPs must continue even when it believes its CERT or the AC's CERT is outside the time window Proposed resolution: No change to the document. That seems equivalent to mandating WTPs never validate timestamps on any AC certs. What if the WTP has a real-time clock and actually CAN distinguish between good and bad certs? ----------------------------------------------------------------------------------------------------------- . 6) Tthe CAPWAP protocol must have a new message to install an updated CERT for the WTP. Proposed resolution: Defer for consideration in the next version of CAPWAP; the mechanisms for certificate distribution and management are quite complex re: certifcate formats, content, generation etc. ---------------------------------------------------------------------------------------------------------------- 7) the CAPWAP protocol must have a new message to install a CA CERT. Proposed resolution: Defer for consideration in the next version of CAPWAP; the mechanisms for certificate distribution and management are quite complex re: certifcate formats, content, management. ------------------------------------------------------------------------------ Issue 143: 1) Cipher Suites for CERTS CAPWAP-01 has the following cipher suites specified: TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DH_RSA_WITH_AES_256_CBC_SHA The above is a mistake, and the following should be used: TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DHE_RSA_WITH_AES_256_CBC_SHA 2) CERT usage type: CAPWAP-01 has the folllwing about CERTS: 2.4.4.3 . Certificate Usage Validation of the certificates by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509v3 certificates MUST include the Extensions field [11] and MUST include the NetscapeComment [15] extension. For an AC, the value of the NetscapeComment extension MUST be the string "CAPWAP AC Device Certificate". For a WTP, the value of the NetscapeComment extension MUST be the string "CAPWAP WTP Device Certificate". Part of the CAPWAP certificate validation process includes ensuring that the proper string is included in the NetscapeComment extension, and only allowing the CAPWAP session to be established if the extension does not represent the same role as the device validating the certificate. For instance, a WTP MUST NOT accept a certificate whose NetscapeComment field is set to "CAPWAP WTP Device Certificate". Using the "NetscapeComment extension" is not appropriate. 3) Selfsigned CERTs, CA CERTs, and validity checking I didn't see anything about whether or not the CERTs were selfsigned. And if not selfsigned, who would sign them. Also, how would a limited resource WTP verify an AC's cert? What if the WTP had no realtime clock (or a realtime clock with an unknown certainty)? 4) Common Name in a WTP's CERT I believe that the common name on the WTP's CERT must be the WTP's ID (which would be either the serial number or "base MAC address"), and should be provided as a parameter on the join. Two small, but important issues are: 1) It should be OK for the clock on a WTP to be "wacky", due to having no battery backed up clock, the battery going bad, the clock never set properly. On the other hand, an AC's clock should be set pretty accurately. I't not sure that the recommendations support this scenario. In general, want to support: 0) WTPs with no management interface (other than CAPWAP) 1) first time use of WTP after being manufactured 2) continued use of WTP after long time operation 3) continued use in short term deployments (such as WiFi network used by a Circus that moves from town to town (setting up and tearing down for for each move), or for the WiFi network used at conferences (such as the IETF). 2) The new text suggests the common name in the format "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies that "DOMAIN.NET " is the "administrative domain". To me, "administrative domain" implies the user of the WTP. But, I believe that the WTP manufacturer must be required to generate a CERT (and the WTP should come "preloaded" with the CERT), and the user of the WTP should not have to create the WTP CERT. (By the way, not sure how long the CERT should be valid.) Thus, I see no need or desire for "@DOMAIN.NET " added to the common name, and suggest that it be removed. (Also, I think that we have now a new requirement to be able via CAPWAP to replace the WTP's CERT with another, and may be to add CA CERTs for the AC's CERT chain. Also, what is the min depth that a WTP should support?) So, it appears to me that the following changes are required to CAPWAP-01: 1) specify that WTP CERTs cannot be selfsigned, and MUST have a common name of the ASCII of the MAC address (or other unique ID, such as serial number) 2) The Join Request must be updated to include the common name as a message element 3) specify that WTPs must continue even when it believes its CERT or the AC's CERT is outside the time window 4) the CAPWAP protocol must have a new message to install an updated CERT for the WTP. 5) the CAPWAP protocol must have a new message to install a CA CERT. On 6/15/06, Michael Montemurro wrote: > > All, > > I've created issue 143 to deal with this problemm. > > > On 6/15/06, Scott G Kelly wrote: > > > > Hi David, > > > > Like I said previously, I agree with pretty much everything Charles > > said, so I won't re-iterate his points, and will instead simply add a > > few comments below: > > > > David T. Perkins wrote: > > > HI, > > > > > > Thank you for responding to my issues. It seems to me that > > > we are not yet looking at the same problem. So let me try > > > again. > > > > > > What I was trying to point out is that there are a few > > > VERY common scenarios (use cases) where the clock on > > > a WTP can be totally wrong. If a WTP is coded so that > > > it will not continue and communicate with an AC when > > > it thinks the AC's CERTs are outside the time window, > > > (or it thinks that it's on CERTs are outside the time > > > window) then you will have a useless device (a brick). > > > In many (maybe most) deployments, it costs more to > > > physically touch a WTP than the equipment cost of the WTP. > > > At the Dallas IETF, there were APs that were "somewhere" > > > in the ceiling not doing any useful work, but sending > > > out beacons with their config'ed SSID because it was > > > too expensive to find them, and take them down. It > > > was more cost effective to just new new APs. > > > > > > For an AC, it's clock must be accurate, > > > and it would be OK for it to not proceed if it believes > > > its CERTs are outside their time window. But, the > > > CAPWAP protocol should allow an AC to establish > > > a session with a WTP that has a WACKY clock (and > > > even a CERT that has expired). NOTE: the AC clock > > > must be pretty accurate for management (such as > > > logs) to be useful (or work). The CAPWAP protocol has > > > support to set the WTP's clock. But it doesn't have support > > > to update a CERT in a WTP. It seems like this is > > > needed. > > > > > > Assume the clocks are OK, now lets talk about WTP > > > CERT validation by the AC. This wasn't addressed, but > > > I believe that WTP CERTs MUST be signed by the > > > WTP manufacturer, or one of the WELL KNOWN certification > > > authorities. Adding the CA CERTs in an AC is done through > > > means outside of CAPWAP (such as via the CLI > > > on the AC). Thus, WTP CERTs MUST NOT be selfsigned. > > > And, I believe that the WTPs CERTs should have > > > for the common name the ASCII of MAC address, > > > or other unique ID of the WTP (and this must be provided > > > in the Join Request message). I didn't understand > > > in the previous text, nor in your message below > > > why the common name would have a suffix of > > > "@DOMAIN.NET". > > > > > > Now lets talk about AC CERT validation by the WTP. > > > The CERT for the AC can be created by the AC > > > manufacturer, the user, or 3rd party. It could > > > be selfsigned, or have a chain from the manufacturer > > > or a WELL KNOWN CA. Given this, it will be difficult > > > for a WTP to verify a AC CERT, at least the first > > > time. This is just a "leap of faith" if the CERT > > > cannot be verified. After this first connection, > > > the AC through the CAPWAP protocol could configure > > > the WTP with the needed CA CERT(s). However, there > > > may be some WTPs that have no additional persistent > > > storage for these CERTs. > > > > > > So, it appears to me that the following changes > > > are required to CAPWAP-01: > > > 1) specify that WTP CERTs cannot be selfsigned, > > > and MUST have a common name of the ASCII > > > of the MAC address (or other unique ID, > > > such as serial number) > > > > While we may not think self-signing is a good idea for our typical > > deployment models, I'm not sure we have to say you MUST NOT do this, but > > I'll give this some more thought. > > > > > 2) The Join Request must be updated to include > > > the common name as a message element > > > > What is your objective with this requirement? > > > > > 3) specify that WTPs must continue even when it > > > believes its CERT or the AC's CERT is outside > > > the time window > > > > Charles addressed this. > > > > > 4) the CAPWAP protocol must have a new message > > > to install an updated CERT for the WTP. > > > 5) the CAPWAP protocol must have a new message > > > to install a CA CERT. > > > > I agree that we should discuss this, but I'm a little leary of taking on > > > > the task of fully specifying every nuance of cert use and mgmt. > > Remember, the ipsec group spun out a whole new wg to handle this > > particular problem. It's complicated. > > > > What we're trying to do in the base protocol is come up with minimal and > > > > sufficient guidelines to get people going. I think cert mgmt and usage > > could be revisited in detail later, perhaps under a new charter, but > > that we might want to consciously avoid getting too bogged down in this > > for rev 1. > > > > Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_17429_13988300.1159914493225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Proposed resolutions for the several components of Issue 143 are included below.
Issue 143 is also copied below.

Comments please.

Thanks,

Dorothy
----------------------------------------------------------------------------------------------------------
1) It should be OK for the clock on a WTP to be "wacky",
  due to having no battery backed up clock, the battery
  going bad, the clock never set properly. On the other
  hand, an AC's clock should be set pretty accurately.
  I't not sure that the recommendations support this
  scenario. In general, want to support:
    0) WTPs with no management interface (other than CAPWAP)
    1) first time use of WTP after being manufactured
    2) continued use of WTP after long time operation
    3) continued use in short term deployments (such
        as WiFi network used by a Circus that moves from
        town to town (setting up and tearing down for
        for each move), or for the WiFi network used
        at conferences (such as the IETF).

 Proposed resolution: Adopt Charles' Clancy's recommendation to
Replace the following text:

 Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a real-
   time clock, they SHOULD verify the certificate validity dates.  If no
    real-time clock is available, the device SHOULD attempt to determine
   the current time using NTP prior to certificate validation.  If
   neither is available, devices SHOULD verify that the start validity
   date of its peer's certificate is less than its own certificate's
   expiration date, and its peer's expiration date is greater than its
    own start date.  Note that failure to check a certificate's temporal
   validity can make a device vulnerable to man-in-the-middle attacks
   launched using compromised, expired certificates, and therefore
   devices should make every effort to perform this validation.


with


Proper validation of certificates typically requires checking to
   ensure the certificate has not yet expired.  If devices have a
   real-time clock, they SHOULD verify the certificate validity dates.
   If no real-time clock is available, the device SHOULD make a
   best-effort attempt to validate the certificate validity dates
   through other means.  Failure to check a certificate's temporal
   validity can make a device vulnerable to man-in-the-middle attacks
   launched using compromised, expired certificates, and therefore
   devices should make every effort to perform this validation.
----------------------------------------------------------------------------------------------

2) The new text suggests the common name in the format
  "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies
  that "DOMAIN.NET" is the "administrative domain".
  To me, "administrative domain" implies the user
  of the WTP. But, I believe that the WTP manufacturer
  must be required to generate a CERT (and the WTP
  should come "preloaded" with the CERT), and the user
  of the WTP should not have to create the WTP CERT.
  (By the way, not sure how long the CERT should be
  valid.) Thus, I see no need or desire for
   "@DOMAIN.NET" added to the common name, and suggest
  that it be removed. (Also, I think that we have
  now a new requirement to be able via CAPWAP to
  replace the WTP's CERT with another, and may be
  to add CA CERTs for the AC's CERT chain. Also,
  what is the min depth that a WTP should support?)

 Proposed Resolution:
Adopt David's suggestion to drop the @DOMAIN.NET and
add a sentence describing the storage requirements on the WTP and AC:

Change from:

  Another important part of certificate authentication is binding a
   certificate to a particular device.  There are many ways to
   accomplish this.  CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
   followed by an @ symbol, and then an administrative domain.  For
   example, 01:23:45:67:89:ab@DOMAIN.NET.  During authentication,
   devices SHOULD ensure that the MAC matches the MAC specified in the
   CAPWAP header, and that the domain in both the AC and WTP
   certificates match.

 to
  Another important part of certificate authentication is binding a
   certificate to a particular device.  There are many ways to
   accomplish this.  CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
    for example, 01:23:45:67:89:ab.  During authentication,
   devices SHOULD ensure that the MAC address matches the MAC
   address  specified in the CAPWAP header. If this mechanism is used, the ACs SHOULD
   maintain list of all authorized WTP MAC addresses and the WTP SHOULD
   save the AC credential or credential identifier.

---------------------------------------------------------------------------------------------------------
3) specify that WTP CERTs cannot be selfsigned,
    and MUST have a common name of the ASCII
    of the MAC address (or other unique ID,
    such as serial number)

 Proposed resolution:
No change to the text regarding use of self-signed certs. While the use
of self-signed certs may not
be widespread,  there isn't a compelling need to preclude their
use in a CAPWAP application.

Change the text to require that WTP certs MUST have a
common mane of the ASCII of the MAC address:

from:
CAPWAP RECOMMENDS specifying the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
    for example, 01:23:45:67:89:ab.

to

Specificaiton of the certificate common
   name (CN) as the WTP or AC MAC address formatted as ASCII HEX,
    for example, 01:23:45:67:89:ab is REQUIRED for use with the CAPWAP protocol.

---------------------------------------------------------------------------------------------------------
  4)  The Join Request must be updated to include
    the common name as a message element

 Proposed resolution: No change to the text. The join request
currenly includes the BSSID. Also, since the JOIN occurs inside the DTLS tunnel, it is
 implicitly bound to the MAC (assuming certs were used for authentication, and
this is N/A for preshared key authentication).

----------------------------------------------------------------------------------------------------------
  5) specify that WTPs must continue even when it
    believes its CERT or the AC's CERT is outside
    the time window

 Proposed resolution: No change to the document.
That seems equivalent to mandating WTPs never validate timestamps on any
AC certs.  What if the WTP has a real-time clock and actually CAN
distinguish between good and bad certs?
 -----------------------------------------------------------------------------------------------------------
.
 6) Tthe CAPWAP protocol must have a new message
      to install an updated CERT for the WTP.
Proposed resolution: Defer for consideration in the next version of CAPWAP;
the mechanisms for certificate distribution and management are
quite complex re: certifcate formats, content, generation etc.
----------------------------------------------------------------------------------------------------------------

 7) the CAPWAP protocol must have a new message
      to install a CA CERT.

 Proposed resolution: Defer for consideration in the next version of CAPWAP;
the mechanisms for certificate distribution and management are
quite complex re: certifcate formats, content, management.

------------------------------------------------------------------------------
Issue 143: 


1) Cipher Suites for CERTS
CAPWAP-01 has the following cipher suites specified:
TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DH_RSA_WITH_AES_256_CBC_SHA

The above is a mistake, and the following should be used:


TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2) CERT usage type:
CAPWAP-01 has the folllwing about CERTS:
  
2.4.4.3
.  Certificate Usage

  Validation of the certificates by the AC and WTP is required so that
  only an AC may perform the functions of an AC and that only a WTP may
  perform the functions of a WTP.  This restriction of functions to the


  AC or WTP requires that the certificates used by the AC MUST be
  distinguishable from the certificate used by the WTP.  To accomplish
  this differentiation, the x.509v3 certificates MUST include the
  Extensions field [11] and MUST include the NetscapeComment [15]


  extension.

  For an AC, the value of the NetscapeComment extension MUST be the
  string "CAPWAP AC Device Certificate".  For a WTP, the value of the
  NetscapeComment extension MUST be the string "CAPWAP WTP Device


  Certificate".

  Part of the CAPWAP certificate validation process includes ensuring
  that the proper string is included in the NetscapeComment extension,
  and only allowing the CAPWAP session to be established if the


  extension does not represent the same role as the device validating
  the certificate.  For instance, a WTP MUST NOT accept a certificate
  whose NetscapeComment field is set to "CAPWAP WTP Device

  Certificate".


Using the "NetscapeComment extension" is not appropriate.

3) Selfsigned CERTs, CA CERTs, and validity checking
I didn't see anything about whether or not the CERTs
were selfsigned. And if not selfsigned, who would sign them.


Also, how would a limited resource WTP verify an AC's cert?
What if the WTP had no realtime clock (or a realtime clock
with an unknown certainty)?

4) Common Name in a WTP's CERT
I believe that the common name on the WTP's CERT


must be the WTP's ID (which would be either the serial
number or "base MAC address"), and should be provided
as a parameter on the join.

Two small, but important issues are:
1) It should be OK for the clock on a WTP to be "wacky",
  due to having no battery backed up clock, the battery
  going bad, the clock never set properly. On the other
  hand, an AC's clock should be set pretty accurately.
  I't not sure that the recommendations support this
  scenario. In general, want to support:
    0) WTPs with no management interface (other than CAPWAP)
    1) first time use of WTP after being manufactured
    2) continued use of WTP after long time operation
    3) continued use in short term deployments (such
        as WiFi network used by a Circus that moves from
        town to town (setting up and tearing down for
        for each move), or for the WiFi network used
        at conferences (such as the IETF).
2) The new text suggests the common name in the format
  "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies
  that "DOMAIN.NET" is the "administrative domain".
  To me, "administrative domain" implies the user
  of the WTP. But, I believe that the WTP manufacturer
  must be required to generate a CERT (and the WTP
  should come "preloaded" with the CERT), and the user
  of the WTP should not have to create the WTP CERT.
  (By the way, not sure how long the CERT should be
  valid.) Thus, I see no need or desire for
   "@DOMAIN.NET" added to the common name, and suggest
  that it be removed. (Also, I think that we have
  now a new requirement to be able via CAPWAP to
  replace the WTP's CERT with another, and may be
  to add CA CERTs for the AC's CERT chain. Also,
  what is the min depth that a WTP should support?)

So, it appears to me that the following changes
are required to CAPWAP-01:
 1) specify that WTP CERTs cannot be selfsigned,
    and MUST have a common name of the ASCII
    of the MAC address (or other unique ID,
    such as serial number)
  2) The Join Request must be updated to include
    the common name as a message element
  3) specify that WTPs must continue even when it
    believes its CERT or the AC's CERT is outside
    the time window
  4) the CAPWAP protocol must have a new message
    to install an updated CERT for the WTP.
 5) the CAPWAP protocol must have a new message
    to install a CA CERT.

On 6/15/06, Michael Montemurro < montemurro.michael@gmail.com> wrote:
All,
 
I've created issue 143 to deal with this problemm.

 
On 6/15/06, Scott G Kelly <scott@hyperthought.com > wrote:
Hi David,

Like I said previously, I agree with pretty much everything Charles
said, so I won't re-iterate his points, and will instead simply add a
few comments below:

David T. Perkins wrote:
> HI,
>
> Thank you for responding to my issues. It seems to me that
> we are not yet looking at the same problem. So let me try
> again.
>
> What I was trying to point out is that there are a few
> VERY common scenarios (use cases) where the clock on
> a WTP can be totally wrong. If a WTP is coded so that
> it will not continue and communicate with an AC when
> it thinks the AC's CERTs are outside the time window,
> (or it thinks that it's on CERTs are outside the time
> window) then you will have a useless device (a brick).
> In many (maybe most) deployments, it costs more to
> physically touch a WTP than the equipment cost of the WTP.
> At the Dallas IETF, there were APs that were "somewhere"
> in the ceiling not doing any useful work, but sending
> out beacons with their config'ed SSID because it was
> too expensive to find them, and take them down. It
> was more cost effective to just new new APs.
>
> For an AC, it's clock must be accurate,
> and it would be OK for it to not proceed if it believes
> its CERTs are outside their time window. But, the
> CAPWAP protocol should allow an AC to establish
> a session with a WTP that has a WACKY clock (and
> even a CERT that has expired). NOTE: the AC clock
> must be pretty accurate for management (such as
> logs) to be useful (or work). The CAPWAP protocol has
> support to set the WTP's clock. But it doesn't have support
> to update a CERT in a WTP. It seems like this is
> needed.
>
> Assume the clocks are OK, now lets talk about WTP
> CERT validation by the AC. This wasn't addressed, but
> I believe that WTP CERTs MUST be signed by the
> WTP manufacturer, or one of the WELL KNOWN certification
> authorities. Adding the CA CERTs in an AC is done through
> means outside of CAPWAP (such as via the CLI
> on the AC). Thus, WTP CERTs MUST NOT be selfsigned.
> And, I believe that the WTPs CERTs should have
> for the common name the ASCII of MAC address,
> or other unique ID of the WTP (and this must be provided
> in the Join Request message). I didn't understand
> in the previous text, nor in your message below
> why the common name would have a suffix of
> "@DOMAIN.NET".
>
> Now lets talk about AC CERT validation by the WTP.
> The CERT for the AC can be created by the AC
> manufacturer, the user, or 3rd party. It could
> be selfsigned, or have a chain from the manufacturer
> or a WELL KNOWN CA. Given this, it will be difficult
> for a WTP to verify a AC CERT, at least the first
> time. This is just a "leap of faith" if the CERT
> cannot be verified. After this first connection,
> the AC through the CAPWAP protocol could configure
> the WTP with the needed CA CERT(s). However, there
> may be some WTPs that have no additional persistent
> storage for these CERTs.
>
> So, it appears to me that the following changes
> are required to CAPWAP-01:
>   1) specify that WTP CERTs cannot be selfsigned,
>      and MUST have a common name of the ASCII
>      of the MAC address (or other unique ID,
>      such as serial number)

While we may not think self-signing is a good idea for our typical
deployment models, I'm not sure we have to say you MUST NOT do this, but
I'll give this some more thought.

>   2) The Join Request must be updated to include
>      the common name as a message element

What is your objective with this requirement?

>   3) specify that WTPs must continue even when it
>      believes its CERT or the AC's CERT is outside
>      the time window

Charles addressed this.

>   4) the CAPWAP protocol must have a new message
>      to install an updated CERT for the WTP.
>   5) the CAPWAP protocol must have a new message
>      to install a CA CERT.

I agree that we should discuss this, but I'm a little leary of taking on
the task of fully specifying every nuance of cert use and mgmt.
Remember, the ipsec group spun out a whole new wg to handle this
particular problem. It's complicated.

What we're trying to do in the base protocol is come up with minimal and
sufficient guidelines to get people going. I think cert mgmt and usage
could be revisited in detail later, perhaps under a new charter, but
that we might want to consciously avoid getting too bogged down in this
for rev 1.

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_17429_13988300.1159914493225-- --===============1833388578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1833388578==-- From zsbpfop@webgaia.com Tue Oct 03 20:14:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuPT-0003kT-Fw for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 20:14:51 -0400 Received: from [200.57.90.65] (helo=customer-65.xertix.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuPQ-0001ty-DU for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 20:14:51 -0400 Message-ID: <000b01c6e74a$230bcd50$415a39c8@operador4> From: "rival" To: capwap-archive@lists.ietf.org Subject: Subscribe Date: Tue, 3 Oct 2006 18:15:02 +0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6E717.D8715D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.6 (+++) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b ------=_NextPart_000_0007_01C6E717.D8715D50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6E717.D8715D50" ------=_NextPart_001_0008_01C6E717.D8715D50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Plus: Beat charge Cameras BluRay delight heels Pannys pair recorders place where find reference material which radio Desktop Digital cameras Hifi separates cinema Palmtops Portable =20 video Give heels Pannys pair recorders Sonys revealed couple stunners blue Cinema =20 Wibree: lite No Try different keywords. general HTML text versions easy gadgets Plus: Beat charge Cameras Cars What special America wont sending till next year. And by Stuff Magazine Hot Issue Top Forums Register Contact Us below White Christmas selling phones iPodwhite treatment time rating =20 soars MP substance Vaio five poor owner double history author legal Desktop Digital cameras BluRay delight heels Pannys Search Zen Plu ------=_NextPart_001_0008_01C6E717.D8715D50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Plus: Beat charge Cameras
BluRay = delight heels=20 Pannys pair recorders
place where find reference material = which
radio=20 Desktop Digital cameras Hifi separates cinema Palmtops Portable video=20 Give
3D""
heels Pannys pair recorders Sonys = revealed couple=20 stunners blue Cinema Wibree: lite No
Try different keywords. = general
HTML=20 text versions easy
gadgets Plus: Beat charge Cameras Cars
What = special=20 America wont sending till next year. And
by Stuff Magazine Hot Issue = Top=20 Forums Register Contact Us
below White Christmas selling phones = iPodwhite=20 treatment time rating soars MP
substance Vaio five
poor=20 owner
double
history author legal
Desktop Digital = cameras
BluRay=20 delight heels Pannys
Search
Zen Plus = adds
------=_NextPart_001_0008_01C6E717.D8715D50-- ------=_NextPart_000_0007_01C6E717.D8715D50 Content-Type: image/gif; name="Magazine.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6e74a$230a46b0$415a39c8@operador4> R0lGODlhnAEMAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAPAAAALAAAAACcAQwCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aBO+S8u2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXszYqa7GkCNLnky5suXL mDNr3sy5s+fPoEOLHk0aKYTSqLOeTs166urWsJ++jk076ezauIvezs375+6MwXoLD/l7uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4V23TGjhhRhmWOARGnbo4Yd/KQGi ZiKOiFmJJlqGYoostujiixw9A+OMNNZoI2NB3Kjjjjz26OOPQAbJXXFCFmnkkUgmqeSSTDbp 5JNQRinlW9dMaeWVWGap5ZZcdunll2DSGE6YZJZp5plopqnmmmy26eabOskC55x01mnnnXjm qeeefPbp50vZ/CnooIQWelI0hiaq6KKMNuroo5BGKumklFZq6aWYZqrpppzqyIxc9ET5aacv jVqdDO+ZSipLqq6qUqv/rqIEa6wmzUrrrbjC506uvPbqq4JhuIXGr8QWayxLNhyr7LLMNuvs swcCAy1G0k5rUbXWUoRtthJtyy1E3n4rLpb2jGvuueimq+667Lbr7rvwxivvvA8FR++9+Oar 77789uvvv+k2kq/AA+tLMMAIJzlKwgw37LBVTjws8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSX bPLJKKes8sos/yhNyzDHTJA1WWUh880456zzzjz37PPPQActtMOsGCpGXXgMrfTSTDft9NMI GQP11FRXzRkHVmet9dZc0yVC12CHLfbYZJdt9qbf6Js2vmvf2za9b88bN01VSjo3fjYfdze8 9XsrFwN9fZ8t+OCEF2744YgnrvjijDfu+OOQRy755FkuQfnlDPeB+eacd+7552blCPropJdu upGonq766tOl4noqrMcu++y012777bjnrvvuvPfu++/ABy/88MQXb/zxyCev/PLMN+/889BH L/301Fdv/fXYZ6/99tx3771RLLT1wvfkl2++7TKer/767GvkQfsfwQH//PTXbz/FyNyv//7T 5o1vFv7jnwAHSMACGvCACETM0RJ4FgAw8IEQjKAEJ0jBClrwghjMoAbRcol8ddCD+vrgBkdI wsrUrYQoTGG8xqDCFrrwhTCMoQxn2LQJ0PCGJAkIACH5BAASAAAALAAAAACcAQwCBwj+AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPK nEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy48VRMjiNL nky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIML H068uPHjyJMrX868ufPn0KNLn76aGvXr2LNr3869u/fv4MP+ix9Pvrz5imXO706vPjf79rff k4wF37H8+rPv449dRv/+/wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhVh5gOGGHHbo 4YcghijiiCSWaOKJKKao4oostujiizDGKOOMNNZo44045qijegfs6OOPQAYp5JBEFmlkhX0c qeSSTDbp5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmVdwmZSbr55VJxy FkVnnXjmqeeefPbp55+ABirooIQWauihiMKnRqKMcgRFo5BGSl4FktbZTaWYZqrpppx26umn oIYq6qiklmqqWVmcquqqrLbq6qv/sMYq66y01mrrrbjmquuuvPbqq5h7/Crsa20Ma+yxyCar 7LLMokhOs9BGK+201FZr7bXYZqutaL1s6+234IYr7rjklmvuueimq65FR0BlAJntLhuvsvMi W6+9zN5rrL77ruvvvwAHLPDABHMKTcEIJ6zwwgw37PDDECM1QMQUV2zxxRhnrPHGHDc7wrIf l4bGgiErW3KyJyObsrErs+yahgKWzITKHdu0Ts04u6ULnonk7PPPQAct9NBEF2300bLugPTS TDc9bhFORy311FT7OHLVWGet9ba+bE1bIV7/+oJPwIRt9tlop6322my37fbbKnYbIQ1w1203 bGTkCJlW7Z3EeufdgC+WTeCEF2744YgnrvjijDfu+OOQRy755G/PTPnlmGeu+eacd+7556Av 2ACzo5Me+umop6766qy3vph1y8J+bCUCyZ6s7cjifqzu07X81yQ88T6s8MIS/6vxrievfF+v LO/882n6AP301Fdv/fXYZz/gH4j6rv334IdvUznkl19Os+eLr/767Lfv/vvwxy///PTXb//9 +Oev//73r7Ks/8oCYLIEyL8CGvCACEzgipCgwAY68IEQjKAEJ0jBCuLvHCoCwLI0qCwOJsuD FgyhCMtSAvKwYoQoTKEKV8jCFrrwhTCMoYoCAgAh+QQAEQAAACwAAAAAnAEMAgcI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkygNWknJsqXLlzBjypxJ s6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1L tqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLBhqUkOK17MuLHjx5AjS55M mXHiypgza97MubPnz6BDi9aqR3K+0ahTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9O vLjx48iT336ivO2q5sfNQJ9Ovbr169iza9/O3Wq57uDD/osfT768+fPo06tfz749UQPu48uf T7++/fv48+/so983//68/QegbgIOiFuBIo1jYGMILkhbgw5GKOGEFLr3QIUYZqjhhhx26OGH IIYo4ogklliZESamqOKKLLYIES4uxijjjDTWyOIVNuaoY4ZH7BhZjzvF4eNUQA7Z2BFFGrlY kkoexmSThSFJkg5QkvVkR1RWaViWWhLGZZeCfQkmYGKO6VeZZvKFZpp6rckmXm6+KeecdNZp 55145lndB3r26VY0fgYqKGbVDBpXoYbChWiibi3KKFuOPiqpU8ZMaumlmGaq6aacdtplG56K BWqoClVg1aikfoVqR3Sk6uqr/7DGKuustNZq66245qrrrnB1w+uvwAYr7LDEFmvssRQJOZAL yBbFbLNDPQttUNJOGx8V1mar7bbcduvtt+CGK+645JZr7rnoBoVtui+ty25L7r6bUrzynkRv vSENMdC9+I7Eb78h/QvwRwIPbPDBCCes8MLfhoOedAx7BHHEHE1MsUYWX4xRxhpbxDG6qKD0 cccTjUxyRCafrPLKLLfs8sswYxdFzDTXbPPNOOesM1NL7Ozzz0AHLfTQRBdt9NFIJ6300kw3 7fTTUEct9dRUV231bwNcrfXWXC9YQNdghy322GSXDbUfZqet9tpst+3223DHLffcdNdt9914 56333v589410Mn4H3lW1ghdu+OGIJ6744ow37vjjkEcu+eS5Pkf55ZhnrvnmnHfueXoRfC76 6KSXbvrpqKeu+uqst+7667DHLvvstIPXSe2456777rz37vvvwAef0yPCF2/88cgnr/zyzDfv /PPQR38TB4ZjIP312Gev/fbcd+/99+BXRED45Jdv/vnop6/++uy37/778Mcv//z012///fhP NU3R+xPd/9D/E1oAgzbA/BnwgAhMoAIXyMAGOvCBEARTFyJIwQpa8IIYHJMaMsjBDnrwgyDc DARCCKVfkPCEKEyhClfIwha68G0UeKEMZ0jDGtrwhjjMoQ53Aokd+vCHQCZkyCYSIoMgGvGI SEyiEpfIRIa5o4lQjKIUp0jFKlrxiljMYqoCAgAh+QQAHQAAACwAAAAAnAEMAgcI/gD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJ s6bNmzhz6tzJs6fPn0CDCh1KtKhRo+uOKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih36 Y6zZs2jTqhUKb63bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55M ubLly5gza97MubPnz6BDix5NurTp06hTq17NurXr17A7iolNu7bt27hz697Nu7fv38CDCx9O vLjx48iTK1/eshTz5xGdQ5/OUDr16wetY9/Ovbv37+DD/osfT768+fPo06tfz769+/fw48uf T7++/fv48+vfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26CFM +Hwo4ogu+UDiiSimqOKKLLboVAQuxijjjDTWyFUrNuYYViE6/sVjj379CCRfQtqnjm5FDplX kkrexWSTdT0J5VxSThlXlVa+hSVNW2Tp5ZdgjlREmESlQ+aZaKap5ppstunmm3B+aUKcdNZp 55145qnnnnz26eefgAYqaINWDGrooYgmqigTijbq6KOQRirpfjFMaumlmGaq6aacdurppwep AeqopJYKoTympqrqqqy26uqr/7DGKuustP7FTK245qrrrryulUqvwAYr7LDEFmvsscgmq+yy zDbr7LO3NQDttNRWa+212Ga7ahraduvtt+CGiyE94pZrLmFvnKvuuuy26+678MYr77z01mvv vT6xgu++/Pbr778AG5ZJwAQXbPDBCKNmRMIMN+wwWAM/LPHEA8FI8cUSuoLxxhx37PHHIIcs 8pvdjGzyySj36M25K7Oc8sswx3xmPufSXLPMOOes884MXXGuzz+rC7S5Q5dbtLhHh5s0uEuD ZAnPUEctNbsjIHbO1FhnvdAYWnft9ddgnzuDumOLTXakOhhV9npt8JW22o++DXejcotbd9h4 56333vB89+3334AHLvjghBdu+OGIJx6REoo37vjjkEe+0mySV64aAJZnrvnmnHfu+eeghy76 6KSXbvrpqKeu+uqst+7667DHLvvstDNEQ+0G3nBo1U/pfu4NvpsbfLnAqzs87pkvgfzyzDfv /PPQRy89Q5FMb/312Gev/fbcd985GN6HL/745JdvfoLNnK/++uynqIW6Wrzf/vz0148aBPLZ YP/+/EOYQv8ADKAAB0jAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa8IIYzKAGN8jBDnrwgyAM oQhHSEKaTKKEKEyhClfIwha6EDsqeKEMZ5iYgAAAIfkEAEzNAAAsAAAAAJwBDAIHCP4A/wkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qc SbOmzZs4cwoQMHBnz508Bfo8OFQo0KL/kB4NmvRowaJKmTZ1CpXnUqlNCSI16PQp1qU/c4od S/bi0Kpdt4b92dWoVrBXpQJ1u9YoVaY+477di/Cq17dgs5YdTLgw16BnE1vFWrfxVLyIFzee K/jxX7pZq7KF3Ffx5rqJDYsePTYv57BqMTtuGzq1XcmvL1c2DZpyZdmzbad2Tbq3b5WBbzse vhXxZsWM7/YUKluzXuZJh6t+Cj229N/Ys4sMjlw4cbmRX/6DL25VcOjaqLmH90437Xrr7LXL n5/xfHfy3qO6VxjV8uP+mNE2lXjvXeZeW3zxRt+CDDpkn3NfwcYXgdNpthZlfqHnloUZuqZb ZPtN1+CIJDbEoV8oIhggeMI9156AKx4HI4yZBUeghDUGpmCJPDZo4X8UDnjYZDiK1xyOPwJ5 G4KmqagkgOr1KOWUVFZp5ZVYZqnlllx26dAMXoYp5phklmnmmWimqeaabLbp5ptwxinnnHTW aSdHttzJ5gd89vkPnwMBCuiffX5wUKGBGiqQoIUquqiijSI0aEGRPopoo4YymiihhF5aqaV+ cvqoqJxOyqiniI6qp5mYkqoppv+OgjpoqKeGOiqsh8aaaKqt9prprL926meru3q6Ka2/Qprs sMROumqZpjr6qrSxIpvsrboeS61BqRIEbLDe6noqtpuqyu220XaKrbKkmgvsTIw8W1O65DpL abXLlpotuQp1W66+9wZsLL3thqutttNOG7Cq9hamjLwiRRvpt9k6W6u+/lIs6aLnIswsssIC 7O6nwjLrMcbB+lppwxB3KbGxoC5cL8oWU9vwuwav+/G7gorsKsnNopspwClP/CnLLW9JsKYy t5swuB03XbK4Qkv99M//LmxyvSbDXC7ISYu5dNFZWyvq1h0TLCvVlhZsL9Noq52zz3DXDfXI YbO6Ldf+JE/NcK01T43v3H77/Ta4cdtsK9a4fns24FDjnLfLe4vcd8x4E/v34k7ja6uvAlc9 csaDryw6zXczPfnqrLfe0iauxy777LTXbvvtuOeu++689+7778AHL/zwxBdfPAEEDJS8QMgT 1LzyyEcP/fP/UE999ctjP3321zufvfbeg6999NIb1D3z3H9/vfXQi38++e2jb375229/vvgF 0a+/9fcbnz/38ZOf/ZZHvufxL3zuK6AA54fA9hmQgApkoATxtz4Ayu+B84Mf9iD4Pw1usHwF /B76RDjC5inwhB70H0JMWD0K0m+BIDRh+hD4QAgmr38V/B/4MJiQFMIwfTn+vOEOOeg9G25w gUc8YgxneJAXOvCGUBxfFPunwgu2sILdO+ATAyhFLspwheoT4Re1CMb3MfGD4RMiBs2YRunl cIsBvJ8PdTjGKZKwigxUo/qYp0MkDjCM+2viHV1IRw+G0Hx87KAhE2nFKH6QhEF0Yxjb2MM7 OhKMXawjFfHIwkvy8IeCjGAJmQg/HE6yjfvz4SdHycMD6nGUE8wkIeEoyDwOUnuoqKMUnYjH 6fGRfykkYwsTSEMillKMl8RfF4dYSVWSUpQgZKYyI4lGLybzlEXkJfhyacdM3pKTZ3wkNpdI zPjVkJYXxGY6BUjFQzawhi8k4yqTKMkRFtGe5PT/ozhruU5dbrKK8hwnIGNoTXMe8qDBRCEx 3YnENy4TlBCdZgTPmU1gxvOWX7TfIzcqyl72sZwRLWEcBarRfSZxgA+VYUIbuFCSRtSMAc0g MrOI0WtqMJW+9KhOc/LNnfq0Nz39qVCHStSiGvWoSE2qUpfK1KY69alQjapUp0rVqlr1qljN qla3ytWuevWrYA2rWMdK1rKatZfcOKta18rWtrr1rXCNq1znSte62vWueM2rXvfK17769a+A DaxgB0vYwhr2sIhNrGIXy9jGOvaxkI2sZCdL2cpa9rKYzaxmN8vZznr2s6ANrWhHS9rSmva0 qE2talcrJgC4FgAj4sdA/mT7D9rSViC3rS0/crvb2+YWtwTxLW57+1vi2ja4w+1tcou7W+Ai d7bOja5ufxvd5j4XItadbnaVWxDhzna7BmEueIFLXS25ViDnZdBxnTve2kLXveztLnzh692D UHe8933vfNc7X/bWt77vXa9sy6sQ/vYXwPS9roGlu9/49pdL6SXRgJ+LXwoHWL7C5W1C7uvd /Dr4w8Ud7oX1+2H3TvghGq7udcm74gU/uMMHDlOEB/Ja9NY4va+F7T9qvGMenzfHKDlxfAVs 3/BiGLopLvKREyzfEiPXwyd2sYW/q1zfHjfJDWbwkFdMYgbDGMtbmnGPx/xj2JZ5zDYms5nX /qwS7m6ZyW6Os4KTG1zidtfOJvYvd/FM3+w++M1SHjGLmxtl3TZZxVquc4r3bGRFWxnM5tUx jdl85krr+MZs3rGm2xzjBBsYyo6+MpdHLeo/8xfL5SVyoEs84StXudGI/vOTW6zlEC850VjC MaV3rWYy91rXkg4yoq0s3VMXe8QIJvV3ay3oTjeZ2M5mdZ6nzWz9AtjW1x72oQVN4Cvp+te8 rjS4bRzskxh7v//VtpeZLOtqG9rU1iZxqqub7jl7msXUnvKx1+3sc9ta3932No97fOlw+xjT aN60mEcC42i7ebpU9jO1bcvn5X7a4vuG+KjZfWCJd5zK/sW1xMXL/21FR/zdHFd3nRa+kHLP SQ41CbiE9cRyhNR8qDKPLWt3zvOe+/znQA+60IeOVyA/5OYJj8m129tloh+94E9XCNI53W93 Ox0i33YI0qeeEiF32sNXx/rAywxkYEv64Elvidfnve2wax3tZTf4uGfycIq7OOduP4iPNW3p cZ+Z7g63upmGsNWsI7zviHe5S84NYlznXe9QJ7jf5c51YVc9y3h/PLmDDXVLRxjuiqd6xx89 4MxrPiGhP32bKq/61rv+9bBXSB1iT/va2z7s+RBIPnafe4LsfiC8v/2khy/2rNsk+MD3ve6X n5IsiPbzqYd8mlmfktxbn/nJ/8f1hU8Q6P6LvSDUR8n2sc986/+e+5I/eMHFzP71Ex/N4afI +LVfkN5vv/fCxzTlOV/uxPPdzOJ3fvSnfANIfrYXd5PXff1ncGQXfR9xffiXfREYgQcIgP43 Y9/Wd9PngB4BgQUogQSYfxa4fwq4gb92gibhgRQ4gPc3WqJwEj8Gfxm4gIbnfWmWdiCBfBOo e/gngOg3JSv4g0I4hNoRBUR4hEiYhFtlD0rYhKEVAEgYAFI4hf8ghQRhhS2BhQKhhR1BhVWI hV44EF4YhgmhhVMIhmdYEGi4hWMIhWrohmyYhnEIh2xYh3Noh1Z4hnT4hWRohnJoh3zIhV8I iHKYh1BoiG3ih/9XuIcpwYWC+BCMeIVVyIeBOIh1mIaP+IZi6IaIaImXyImg6ImbaBCOeIh7 uIaDiIqdWIqECIeo6ImvSIlrOIumKIppoogzwYoSkYliOImL2ImpSIW8eIeWuIp0aIyamIyL OIqASIyKSIvNqIptiIfTKIrCWIufGIy2iCZ+KI2kiIa4uIxxmI3geIpteIzXaI7qiI3BCIwH wYnUWIzoGI7NWI+w6Irr2IryuI/MCIZbGI++GIrWiIjPWIvueIv4qI15uIwEaZAMqZAGGZEM KZGjeJBhqIf3WInDGJDxGIsY2Y7b+IjhKJIJmY3tKIgfyZH8CI+BuI7A2JDayCYFeZL/EwmR ugiROMmKMFmR7LiJpkiRNLmRhRiKHomN0KiMzJiRyjiTOFmTziiQQ2mLhsiOMHmQ3JiQL4mO OcmIM1mVPemVNemIk2iUVPmTZVmSyFiUJumOPamP9jiSZMmPHUmUdLmWWnmNPHmIMbkmXamX OimRC1mRW9mU5PiVQCmLTBmUkTiXdimOaXmMIXmXkfiXjDmQjXmUyJiXJimXbtKXb4mZXImP okmWKHmO30iJb2iWPymPoLiYc3mOpUmN5SiQSImap/mLv0ibcEmL1ZiV/SiajkmbTWWVu+iE vkGGxpmcyrmczNmczvmc0Bmd0nlVrjCd1nmd2Jmd2rmd3Nmd/96ZHabwneI5nuS5OzVQnuiZ nuq5nuyJJXnQnvAZn/JpEJkwn2VRn4UhD3RlBS2Dn/YpFv75nzgRoAJqEwRaoAiaoAq6oAza oA6KoHPwoBJ6J34woRZ6oRiaoaC1ChraoR4qV2XwoSI6oqGFNFGTECYqoilKOLlCoueyoubi og8BKZgDMgrzODGqoTRKN2RzKUTjoryCOHDzJyFzMSPKMyljOekiNx2KpKWipEPzKgXTpOxy NabyNewypTLKEPuypRkBo14apmI6pmRapmY6VxyIocYnfQ2hfuRmc5+3EUbnURtAPGtqEJU3 gmv2dyXIpxjhp8o5g9BXg3FKg3vKf/+TlmNkt3mJuoAJGH+qN4OPmnZzqqg4aHR/d4GZ1qgm CKjoJ6mJ56mSN3fgd3idR4J9ymt8h4SgKnc3CH7/Z4Jw2muPuqmdmmkDN4St6neU+n9nZ6u3 KoO1Wqpzl6u6CnqMKqyleqh7SqmD+qunmqycKq1pqp3V2hGiyhDXOqLG2qbbeqbgGq7iOq7k Wq708a0dOqcR4aajSqyvyqZaJ3Usl621d6dt6qu0iqe/Kq9RN6sLR6+0t6tmR2Ob1qh+qn9v mqxmp3/A2n6y+oOtGoPt533A+qamyqsYGG4KmIH5+qnRqqgV2672mn6aSnCbaqoTe6gdy32G F6vvSrD7ioP/vlayNuiq0kex6Pp4hDqz/YevIHuzwyqxl8arwyduALs7z/A7lVqD+up+yjp9 MgitkTewKyuy0To8SZtUOTtXWWuuENG1XusQYEuuS/AQYxu2aJu2agsTvbC2bvu2cBu3cju3 dFu3dnu3eJu3eru3fNu3fvu3gBu4gju4YxUHhJugfZC4iqu4h9u4FXEEjhu5kju5lOuhAzAA AnG5mXu5mPsPmlsQn0sQoQsTnMu5ntu5ClG6mDu6BsG6rYu6n+u6EsG6pTtYmhu7nXu7qDsQ riu7LhG6viu6uxu8p5u6w6u7B7G7DDG6uCtYyFu8wvu6oGu6MwG8ypu812u82su7/88bvQ/B vNn7V7W7udMrvaKbuZuLu9abu6vbvtbLvfBrvqf7vt5LvuM7v8pruverv+6Lv8irus0bv9wL u+x7VuCwEKprv90rwOjruQpcvP/bvhAswbcLwRZcvg9cwQMcwRMMvRl8vPtLwSIcveA7v/Cr wXb1vM3bu/lLvRz8wiPcvbV7vwIcwSV8wjF8vB2Mw+ybwx7Mv96rvviLVytcwMzrwdALwx2s xDLcwvLLwRj8wTssxTzswEycu1OcxKv7w+ELV0X8wLyLxF98xUscwxYswVH8wvVbxlkMxQq8 xWRsxWhMvmcMx138VgE8vgmMxFrMxkKcviPMxQxcw2hMu/86rMLUO8B0TMe6W8SIvMBDHMkB XLlIOA+UfMmYnMmavMmcPDxnV7D3Cqvaqq4ckbMxa7LQiqcEm6ir3H0t58oS0bOhbBFbC4NY RyZDG8uqrK0kYcro9cutXLCyzHmr7HIOGKe6PBG1HMzL7BEAaHOu3MwM8szJDMuvPBLomsvA LMzW/MvEXMy7jHqfrMzkfBHfLBPUHM6rOibUbIEwe4PNqnAvC8rrDH+r2s7Q3M6pp83cvM2w nM6KZ8yvnMs4BsyRB8oH7c0G7bQJV6isPLEKXc8Ffc/vl7ExSLLrp89hVqjufNEAvc78jMoz 680jGNF6N9L0DM6tPM5w+s17J8r/qCfPQ9vR8ozQNQ21z0zMM63QGHjT0VzSOS3T7gzSP23T Oj3U0uwb+LzTN+1+zwrTBm2yNc3UJ03V0GzT2xx9H63S3ZyrO112FI3VUS3Keuq0UuvTQb2x Mh3RQW3V6prWNxbNJA2p80HQa93Pbe3T3XzXY23VsOrXu3zOLE3P2uzSXH3VvvbO+OzPg73W hj3WkE3U4MzUeU3U5yzXlo3Z6Zwldv3VeU3Zej3Md32yUjfaiM3Pgk3W1lzY/nzSUEvRSM3Y aE3TmZ3ZPY3abG3alJbbuA3aOp3bnK3YUe3UFrvQTevR8PzOsq3ZryrLL0uDXM1/Z811Ls3S qYzVXj3V/9eNdiZdtXEt2Q5N0KecsE693fN8Jkn9p8ycEektFtfa3l3VrSkxdntdEfCNE+/d yfq93/zd32nSD3sL4F4q3xch4OocEhyY1L+92bRs36Xd2tXsraQMee3N4Ead0sEc3BCOEf1g 4BneEpd9y3893xQR0q4d0+u64VB94vEa0Kq8zxBW3yBx3w7+4fE64iixtRZ+4DzOyxi+4j1e 2i6O4yyea2ya00hd0Kyt3GMH3c1t2y4r0S+d0Dw90kNdz7Yt3kULqFeu3MmtsgrX2TY+3O8n 1UCNzFqO5bCd5F6u4f98ghdN0nz92sCN40DN05+94GF91FYeqyVdtIkd218t2/9xnrBCveeO 3eaBHduKXdlV/tlFLbFZHuOqLeZhDteEvdAmnn5vPuhmTuiwvdyQXtmGLeZgfdh1btKnLugl qOiq7at6ntVyXdZY7tuwrtfextyWTurdbdqt7da8jdagTtul/ui+TuaJvt6/HtqR7ekf/cla jewj/tjG/tuTbeyobuTBfui8DuG2jt2OfeemrueMLueDnud9OtW1Xe6SrdK2vtvtfszIHuvA Tuy1HuiIHrICF7Om/tCy/ursysoNneinDNCLfalQjunWzu/NfaoLD9NTa+5hDtkhru69qs+2 at1+zeoHveNqsq00XuRlUfFBPhYh7xsMwM5HZxIn/xH/xnrMLY/g/j3zNF/zNn/zvWSDjgXz BE7yBC7zhJHgqU7Xs/x90yrvLa3iP47iS48m8l4FiJ3SjX3NQD/jDWEBY97py830Il7OK930 Pw7tXL/yMT8iSB/1zg32QI6tIvGtQt/uYO/LJQ7xcX/aS+/LZS8aSr6sIVvwc47hE93R9M3k Ltvx8fzlFd3vCHfPYi/wMJvWJLvliNrwUm3Pxnz43Hz4gb/iSJ7m7i7SeT8YM/3suD7uUe7t vM3q6Y7cvF7qqt/W9s76MtuzkL/u4P7u3K71G9vbVd60dI7owi34at8joE34rv3taT/vul3p ZH7qjP3dW936nz79Tm7n1P/3/9M960Pf643/3efN3Jz+1qFe+xpe+wf/5rbf1ctf29ee7Ft/ +7oP6YeN24Av7N+O/sO+/Wou9vUeztLv4gAB4J9AggMNHvyXUOFChg0dPoQYUeJEigsFGrx4 MWHBjA07YhzIUaNCjQVBAjBpEiFJjhtdpjyoMubMjjVD0sSJE6VFlyRf9vwJUmhPmDaLAs3p 86dNoSMRHj2JtOVUpBWtXsWateLOmT53onT6tGRSi1xvLn35kadarhlLui1LdONbrzQJsh3r FCxDs2aJ0j07F+5cwYS7sqwK9uPes2pZLi48mKdcxmG1XsacWfNmzhPDWubbWfRo0qVNn0ad WvVq1v6eHYJG3Fr2bNq1bd/GnVv3bt69ff8GHlz4cOLFjR9Hnlz5cubNnT+HHl36dOrVrV/H nl37du7dvX8HH168dthpy68+fzW91vWvM/tdmbV9+vYRW8Z+eF/0SKrjL9dXyjWKAJSIwAHj Y40/BG/7jL2V1hsrNAdDM9C/ydTbKsPOKixwQdUU5LC0BuV78MCqPBRwLQtjMyomxQyrDKO+ XLyrLRltVJGxwFgUSy4X7YtPJKBSgizIGgVTCb7AcLQRLsnq2ksx+CDTT0rARJIypLv4UnIq qpJEUboWv/ryMBmHuglEu1T0Ss0SzzyqP9AiJIypqKKSyU44zWTqvi2/av5qLTelwhNNN8uE 8sQSySwU0C0XCsC6vIJC9DGyFnM0KC3fdMuxAPssNMwslXox0Bf7o4zNGvV6DCYf9ZusUxpz DPWvPO+MUku9/AJVTjOz6xWtW02NVSdKNc2JzmKJrRIiZT2FSthiD0XRsQipXDBYaxtdFFlE YSV1WmlBJU/YOIlFN1U8Xb0V0EDD1RZX9y4sEqpKL01WXHmx3dZdP2lFFd0yW+RUUGPjDPG4 XPdt6q2iro0M1YXr2rRiSzH91NI3MzZsyI6VhbEsjLkcTFZsd6SUUR09vtPWkIWM8lGRKTy4 K5nCS9i2nFfkebedlVvZuKB7JlphJYtGOmmll/5mummnn4Y6aqmnprpqq6/GOmutt+a6a6/9 +wwwlL8mW+sKIWRVYM5+LrvtBNfG6mb30rYXbrfvJu5nAuXOT8K6N2Mb764RTrRUIi8O22N2 jeJv4qPpzlfjxs6MVdaPBTJB8LIdJZzXNNslNFlf/TXY1QvVNV3VNAnt91jNySY32oVbf1BH iO1d+eEu/c435mFLNc9yhwN/vefYI2dX9QA5/tfTY2GDnFx1faQ5XOqL/zpTnZIv0vVXf2z+ +r9P7z30v6kNNkzsqTZ9xiRJr31sHOWdvOPCfvSIVLG7bAsvvx2+34zW949vXK0+xDMRbRA4 QIjIgoESss/RPlSbnf7144EXxGAGNXgcbWzQg+vr4AdFKLgQjtCEollDz0p4QhZuJoUWWmEL ZYiZF4onhjPEYVZq+J0b5tCHVlnDDn84RCIW0YhHRGISlbhEJjbRiU+EYhSlOEUqVtGKoxnA FbW4RS520YtfBGMYxThGMpbRjGdEYxrVuEY2ttGNb4ziCeA4RzrW0Y53xGMe9bhHPvbRj38E ZCCJwwBBwpGQhXTjIRHJRkUuMokVgGQFFBLJSP6DkpBsCCX/QUhMJqSTnrykJSUJSlGCspKZ PGUpSXnJUZLSlaL8ZCwnOcpPOtI4rDRlJXG5kF2espa4jKUkMcnKVuayk74UZihnSUtmav9S lZac5SttSRxkJtMhtTRlNpGJymiu0prSrCYsvfmQbYazlMJ8JjanGZxffpMh6uwkJ5M5zGK+ MpjnrCcvi0lPej7znbp0pyqHCc17rpOa+YRlKuG5z3kG1J7AbGY+25lQfDozl/jU5yoJ2kp1 GtQ3xwSoRRea0YGO1Jj9vGhGo1nShk7UmhM950a76VF2RtSfM8VpPy0603uaFJwvBSg5G+pP kNIynQil6W4U6lBpZlOcReXmQzH602YKFKVRDalTj5pU5BAzoQX9pzOh+k+eAlWZy9zmU89q 1YjClKhI5apulLnLm6K1rFHdalE7KlKOtpShZcUmWOsaV8Iq5wD+hUVsYhW7WMY21rGPhWxk JTtZyn5xrRSVKj9T+dW2InSvc/0raHfqVs32VZN0JetdL5vOnDKUr2Bt52n7ytbPBrOasTXt ba+6W7MGFbCBredZL9vL0MI1K3QlLjMrulmvohanaE1raaWrUqdOl7Oc9axrvblT1v5Un2IF bWtlu1K/Ble0IdVtZ/2aV5Aut71vHa1rZbtWr1q1qZmBajjLOdvUTlWoPn0vb5/72nGqtb8L tW2BNxvTgHI3wQa+L2yBKl5tKre9+uXvVrdb4Ld696gS1rBU7TvYy/S0uDrNsGqNy90Qg1eo Yc2tf68q4u/GWMAklaldqevSFNMYxRD+4bGCG+xOEG93wk11sHJTWteO+nipojExSX1LXeh2 NpOeRGV8bWved2L5ogKG6GqN+mUicxmdv/TyXbPM4i37ls0nRu+MpZthE/8YyQtGbpoxu+Qq 1/i5+J1tkJmK4PSmFrhJhjGVA3zmMl/XuSNmaYg12ugO3xe7eG1ujBXdUmN6F7UgjrRgI8xX qsoXxsClsmaiTN49/3nV1xxuipssWOJS9NWuxHN4x3tno7b5r+CksZr921op99fTVXXyciU9 6jV/Fq+Sdutm8jttrbo60HB1Lq3pLOvwQnjKwb4uW8V9YPmSltrMBqUQxqntqqL6uxUW9qqn 7FNru5jD5k7/9WiQ2+0FMznMzP31SQNeX2h/M85W1nax1criFg+83Er29yzVjVGCn/TOzYa4 hEN57ogbu8OZpu+nAy7tJBc538kF+KYRDd0dF5e8S911sMHM8Ia3PNHg3qq6UbraPbv75pXG bcYpfXIud1O4Jc91vivrkIkvHYpNd3oToR51Jk6d6lfHeta1vvU/toLrXzcN0lV8aoyzt9M1 1mvQGy3yl897vX1+9ZbVTHNA7tveww433K996Sq/3eJ1BriFdW3lPsu4zOAVPN37iOF2712l /Qb10M0O5G2TeL/cjDaz5T1twVv6j0FmNYdxHnkST/7FmUXqeGvr8cHmmtu2Ljoi350deryL +sO7fjPiIZ/bg/vZuuIkOoHffWw5G3fx2VV47Xt8e7cfutDk3njIZWp31lN/+B9n9J8FiWbs 0370laf3rTHteMx/e5nVz655X69Z7QeS8fAW/bhtvu7Xx5/c3n/8jEVP73sb/Nz9nia7S6/1 erSamzO0+7148ztxq7XMC7eZK7yxKj33c71y+zuaI72vOjXCmz/3cjhHq7wNND25SzawM8ET RMEUVEGtEIMVdMEXhMEYlMEZpMEatMEbxCNOwMEd5MEe9MEfBMIgFMIhJMIiNMIjRMIkVEIa DAgAIfkEABcAAAAsAAAAAJwBDAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rc yLGjx48gQ4ocSbKkyZMoU6oMGW2ly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypd yrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7Ytzjxu48qdS7eu3bt48+rd W/AV37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6te XZYW69ewY8ueTbu27du4c+vezbu379/AeWIJTry48ePIkytfzry58+fQo0ufTr269evYs2vf zr279+/gw/4/zya+vPnz6NOrX8++vfv38OPLn0+/vv37+PPr38+/f056/gUo4IAEFmggXcMd qOCCDDbo4IMQRijhhBRWaGFyC1yo4YYcdujhhyCGGBsaIpZo4ol1rYPiissVwOKLMMYo44w0 1mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JLf8RHhFZ45yeRZUk5ZVpVWjoVllkAJAdKW XPrk5UdghsnTmB6VaeZWaq6ZVZtuxinnnHTWaeedeOap5558WkZCn4AGKuighBZq6KGIJqro oow26uijkEYq6aSUVmrppZhmqummnHZKVjee0gRqqDKNSipMpp7qUqqqqsRqq/8ovQqrSbLO SlKttoqEa6689urrr8AGK+ywxBZrbHTe0KXIfhHkisOx0EYr7bTUVmvttdhmq+22UA3CrUOD hPstQ+KOa+656Kar7rrstusunk+8K++89NZr77345qvvvvz26+9xuPwr8MAEF2zwwQgnrPDC DDfs8MMQRyzxxJxpcq/F9WKc8cUc26sxSvDY+jHFJGPkQMkop6zyyiwn9U3LMGeGSsw012zz zTjnrPPOPPfs889AB43tDEIXbfTRSCet9NJMG+hC01A7eEnUVFdt9dVYZ6311lx37fXXYId9 YQxil2322WinrfbabHunQNtwL0Re3HTXbffdeOet997+fBuIRN+ABy744IQXbvjhiCd+NtmK R+RO45BHLvnklFceloqWZ6755px37vnnoIdeYAuiJ9Usvaejbm/qX5FhJuvywv6u7KPBRSDt 7eLOru6l9+7778AHL/zwxOPZw73H15u88vYuX/zz0Ecv/fTU62xA9dhnr/323FvUysqChG8R GNeGL8i95qOfVBEph9P9+/DHL//89A98R/3456///vz37///nBIHAAdIwAIa8IAITKACF3ij EDDwgY7RAwQnSMFGyaGCGMygBjfIwQ568IMbekShtgDCEprwhChMoQpP+Il6tZBeL5xXDOU1 w3fV0F03XKEOd8jDHr4mDj4IDKIQh8iygAAAIfkEABcAAAAsAAAAAJwBDAIHCP4A/wkcSLCg wYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odK2+s 2bNo06pdy7at27dw48qdS7eu3bswjeDdy7ev37+AAwseTLiwYcJADitezLix48eQI0ueTLmy 5cuYM2vezHlzjc6g3X4OTVrt6NKox55Ozdrr6taws76OTZvq7Nq4c+vezduiht7Ak/4OTpzo 8OLIfx5Pzlzn8ubQa2p4Hr269evYqy7Kzr279+/gw/67vCO+vPnzJjmgX8++vc4Y7uPLn0+/ vv37+PPr349+C///AAboVjsCskdggegdiKB5Ci4oXjsNOijhhBRWaOGFGGao4YYcdujhhyCG KOKIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbYWRY+BinkkPqhQOSRSCbpFxFE KOnkk1BGKeWUVFZp5ZVYZumkNmjVoeWXYIbmRphklmnmmWimqeaabLaZIQtuxinnnHTWaeed eOap5544JsHnn4CmtEaghBZq6KGImnlEoow26uijkJ6UTKSUVmrppZhmqummnHbq6aeghirq qKSWGhUvpqaq6qqsturqQ//VYGTMq7TWauutuOaq66689urrr8AGK+ywxBZr7LHIJqvsssw2 6+yz0EYrbXkyTPupMNZmq+2zGWy74xzehivuuOSWa+656Kar7rrstuvuu/DGK++89NZr770z moHvvvz2+2Qf9gIc8L0C+2vwwQgnrPDCDDfs8MMQRyzxxBRXbPHFGGfMkwP2cqzxxyCHLDJr XtxrDb3WnDyvyivXy7K8L8cbM7wzv1vzyDjnrPPOPPfs889AB83UNEIXbfTRSNf7TtJMN+30 01DDtU3UVFdt9dVYZ6311lx37XXTxHwtNr5SjG32kZ/Umza9a8/b9tlwxy333HTXbffdeOet 997nfPft99+ABy744BG5QHiZdhyu+OKMA0VN45BHLvnklFdu+eWYZ6755k/qUa/nn0fpxGKg z1u66aHTezrnrLfu+uuwx971JLLXbvvtuOeu++689+7778AHL/zwxBdv/PHIJ29lP8o37/zz 0Ecv/fTUV58kkNZnr/323Hfv/feVXgD++ORjSl756Kev/vrWIsL++/DHL//89Ndv//3456// /vz37///AAygAAdIwAIa8IAIpE0TEsjABjpQLEZ6oAQnSMEK9iYAH8GWBbV2vp+YY4MgxNMy QkjCEprwhCiMiihSyMIWSi8gADs= ------=_NextPart_000_0007_01C6E717.D8715D50-- From hxmomujjbx@wtbp.net Tue Oct 03 20:14:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUuPW-0003kf-3K for capwap-archive@ietf.org; Tue, 03 Oct 2006 20:14:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUuPV-0001uO-Ve for capwap-archive@ietf.org; Tue, 03 Oct 2006 20:14:54 -0400 Received: from [200.57.90.65] (helo=customer-65.xertix.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GUuPS-0003nx-2y for capwap-archive@ietf.org; Tue, 03 Oct 2006 20:14:52 -0400 Message-ID: <001201c6e74a$2305b2d0$415a39c8@operador4> From: "each every" To: capwap-archive@ietf.org Subject: Zen Plus adds Date: Tue, 3 Oct 2006 18:15:02 +0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6E717.D869BC30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.6 (+++) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 ------=_NextPart_000_000E_01C6E717.D869BC30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6E717.D869BC30" ------=_NextPart_001_000F_01C6E717.D869BC30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Policy copy The Console luxury cables Worlds Best Selling weeks podcast: Sept cut from single piece Plexiglas know VideoNew News Maps more raquo Advanced Search Members: users: blue Cinema Wibree: lite No sooner does Ericsson develop watch than =20 Nokia there will contains time rating soars MP Buy Dog mouse want improve play increase scores then need Palmtops Portable video Give On sale Greatest gadgets cant seem anything decent though. Benjamin DAB radio Desktop Digital =20 cameras Hifi raquo Advanced Search Members: users: Join Alerts Create new group About new group About Searched all groups Your search Register Contact Us Try different keywords. video Give On year. And works what do search. Get the func ------=_NextPart_001_000F_01C6E717.D869BC30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Policy copy The Console
luxury = cables Worlds=20 Best Selling weeks podcast: Sept
cut from single piece Plexiglas=20 know
VideoNew News Maps more raquo Advanced Search Members:=20 users:
3D""
blue Cinema Wibree: lite No sooner does = Ericsson=20 develop watch than Nokia
there will contains
time rating soars MP = Buy=20 Dog
mouse want improve play increase scores then need
Palmtops = Portable=20 video Give On sale Greatest gadgets
cant seem anything decent though. = Benjamin DAB radio Desktop Digital cameras Hifi
raquo Advanced Search = Members: users: Join Alerts Create new group About
new group About = Searched=20 all groups Your search
Register Contact Us
Try different=20 keywords.
video Give On
year. And
works what do
search. Get=20 the
function
------=_NextPart_001_000F_01C6E717.D869BC30-- ------=_NextPart_000_000E_01C6E717.D869BC30 Content-Type: image/gif; name="group.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6e74a$23042c30$415a39c8@operador4> R0lGODlhnAEMAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAKAAAALAAAAACcAQwCBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOVMJ5KnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOm7Ka2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAODJCW4sOGPhA8rXlwxMePHkBeSchy5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrH15qufPn0KNLn069uvXr2LNr3869u/egtL7+ix9Pvrz588jxoKeufv1PbYrbu9+pDf5i +fNv2n+MP//M/fz5VxOAkPUnYEsERmbggSklqCCDCHK2IIQjOUjhhRhmqOGGHHbo4Ycghiji bs6MaOKJKKao4oostujiixg6AeOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JMhKQPllD/yQeVhVl5pWJZaCsZll399CaZfYo5p5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPbpp2GH/Cmod24MauihiCaq6KKMNvpWFo5GKumklFZq6aWYtqlBplJtymlTnn66VKhC BrIZqaIihWqqrLbqqm//d7wq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMxsVL s9BGK+201FZr7bXYItVHttzKFmt5rUz3bbccjUuuRuZah0136Z57UbvuVgRvvBPNS29E9t6r 77789uvvvwCbpEPABBds8MGixYHwwgw37PDDEPs4QcQUV2zxxRhTy1bGHHfs8ccgU1xFqpWE bPLJKKes8sost+zyyzDHLPPMNNds8804jydDzjz37HObk/ws9NBEF+2bI0YnrfTSTDft9NNQ Ry311FRfKUrVWGet9dZcd+3112AbxkrYZJdt9tkmsoP22my3Xbapbue8btx007RxVR9EenfF /ntT3HfEf0Mc+MOD12344ZPagvjijDfu+OOQt5l35JRXbvnlmLOaTeacd+7556CHLvroMQlA +umop666Xeqs7vrrsMcu++y012777bjnrnuGQOzu++/ABy/88MQXb/zxyCev/PJdj8D889BH L/30U+VD/fXYZ6/99tMvw/334Icv/ozSjG/++einr/767Lfv/vvwxy///Fr7EdIg2drv2SdC +qE//QAMoAAHSMACGvCACEygAhfIwAY68IEQjGDy5iHBClrwghjUniuqVTKLddCDGPtgxURI MRJGzIQQQ+HDVMg2XZDGDiAZQgZnSEMiZaCGOMzhd/agwx768IdAFwyiEIdIxCIa8YhITKIS l8jEJjoxMwEBACH5BAAMAAAALAAAAACcAQwCBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0 qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rcsfbuPKnUu3 rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3nwzB+fPoEOLHk26 tOnTqFOrXs26tevXsGPLnk27tu3bc1Xg3i1TN+/bnWL6/k185fDiyE0eT8485PLm0Dk+j069 uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv3u8+vjz69/Pnziq/gAGKOCA BHJ0S4Gz3XIgggw26OCDEEYo4YQUVmjhhRhmeJ0sGnbo4YcgovdHiCaJQeKJKKao4oostrgS GC4+CFeMNNZo44045riTMzr26OOPQAYp5JBEFmnkkUgmqeSSTDbp5JNQRinllFRWaeWVWGap 5ZZcdunll2CGmd8DYpZp5plopqkmgQqs6eabcMYp55x01nlXDHaOBEKefPbp55+ALnRGoIQS akqhR5lyKKJEKcpoo4s+KlSkklZq6aWYWgVAppx26umnoIYq6qiklvoSP6ZG2UWqrLbq6qv/ sMYq66y0TsZFftHUmlKuup7Ea68l/QrsSMIOG1Kxxib7FwTKNuvss9BGK+201FZr7bXYeqhB ttw+uG234IYrrlO4jBsZDOamq+667Lbr7qwGvCvvvPTWa++9+Oar777/qIOvv/cCbK/A9RJM r8HzIiyvwgdFMC7D7kLcrsT8VmzxxRhnrPHGHHfs8ccghyzyyCSXbPLJKIcGir4r49vyvS/D nG/MKdds86xJ3Kzzzjz37PPPteAb9L1D21t0vUfTm/S8S8vb9M9QRy311FRXbfXVWF9KSdZc d+3112CHLfbYZJdt9tlop6322my37fbbcMctd2uqzG333Xjnrffe/nz37fffEh0B+OCEF274 4YgnTjg8SFKh+OOQRy755JRXbnnkCVxuWz6ad/7q054XSXPopJdu+umop6766ik/wvrrsMcu ++y012777bjnrvvuEtHD++/AB9/uO8IXb/zxyCev/PLMN+/889BH3/kB+lKfr/X4Yn+v9vZy X6/39B4AvvTkl2/++ein35oa6rfv/vvwxy+/vczOb//9+OcvoDD69w/SGv4L4GjmIEA0RaGA CEygAhfIwAY68IEQjKAEJ0jBnQWjghjMoAYzY40NevCDIAyhCEdIwhKa8IQoRBsp9LXCfJGi hSmMoQxnSMMa0okNNsyhDnc4Ginw8Ic4AgkIACH5BAA14AAALAAAAACcAQwCBwj+AP8JHEiw oMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePICPaCkmypMmTKFOqXMmypcuXMGPKnEmz ps2bOHPqTClAwMCeP3v6FAj0YFGiQo/+U5p06NKkBY8ydfoUqlSfTak+JajUINSoWpsG3Um2 rNmLRa9+7To26FekXMVmpSoUblukVp0CnRu3L8KsYOOK3Xq2sOHDXoemXYxV693HVfUqbvy4 LuHIge1uvepW8l/Gne8uRky6dNm9nsey1Qz57ejVeCnHznwZtWjLl2nXxr0atunfwFkOzg25 eFfFnRk7zvuTKG3OfJ0vLc46qvTZ1INr305yuHLixun+To4t/jhWwqNvq/Y+Hrzdte2xu+dO v37G9N/Ng58KX+FUzJH9p5ltVZEXX2bwveWXb/Y16KBD+EEXlmx+GVgdZ21ZBph6cGG4IWy8 TdZfdQ+WaGJDHgKmooIDikdcdO8R2GJyMsq42XAGUnjjYAye6GNEOxSGYYAWFphYZTqS95yO QxKZm4KoseikgOz9aOWVWFq0RpZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnn nXjmqeeeIClA5geABvoPoAMRSuiggX5wUKKFKiqQoYk6+qijkSJ0aEGVTspopIpC2iiiiG6a qaaCgjqpqaBeCqmojJ7Kp5r/nKLqKaeSknpoqauWeiqti9baaKuxBtvprcOGKmisv4r6Ka7D Utrssche+mqaqko6q7W1Mtvsrr4ui61BrRJEbLHi+roqt5+6Cu631YbKrbOoqkvstGu2i660 mGb7bKrdoqtQuOnym+/Aytobb7neenvttQO7ii+9ZVZb6bjdSpsrvwBTbOmj6yoMLbPGCizv qMZC6zHGxQqb6cMQjymxsqQ2fC/KFmP78LwIv/vxvIaKLCvJ0bLbqcApTzwqyy2fxUFIBnsq c7wLk9vx0yWbKzTVUf8ccMMm32syzOmCnLSZTRe9tbamdt2xwbZarenB+DqtNts5+yz33VKP PDas/t96TXLVDudac9X61g044HGTO7fNumrN67hpCy41znu73LfIf8esN7KBNw61vroKS/DV I2dc+Mqk05y305W37nqcI70u++wExU777a7bjvvuSevO+++v+m6aMcAXP5Pwxic/J/LKN+8m 885HLz2XBBAwkPUCVU+Q9tdX73333P8TfvjiY18++OaTv73556/f/vnef2+Q+tmnzz7543f/ Pv3x61///PJDH/ro976CBPCA4yPg9BSSv//5r379K18EE+i+/cUPewrEH/vgh8EORtCAG3Rg ATV4Pf1xj38XhKAIIYjACaYQhCGUoPZSSMMPLrAhMxTfCAMoQvl9j4L+/juhEK2XwfttcIYd XCEAUfhAG+aQiEksoARV6EMjenCKWJQi+A6CRA56sYs3dMgTd6g+IP7PjF5cIRgBWEETQvGB XORhD+1HQiK2b41wRCIe62hEOAowIV0M5BvDCJEx4i97IPQjC3n4Qi06coeJbOQFQ4jBJX6w kibU4RCZ6MY99lGBjhwkQgT5RTkSEpB2FKUQ20jASVoRiP0rYhvPeMlGOrCMk7yl/TR5Rxuq 8Y2ihCQomTjMJJLSlqcc5Qkt6MRdltCCFVylDKXoyUhGsZi+hKUklylNXLpPj3104/ZmucgY UvCYwUymMvNoywReEY3dPOcRg+nNeKIym87M/2UT8znPd15xi1OsojPX58s5ljKN6kTlPln5 SmlCUpc1jGUzJQpNff6SoQ+FpkEJWkUVctSdjIwhLT8qQyj+sKAJxehFlVhLdu5ToAKF4Ukr 2s5wGpSEG9UoRxcq056S85sN9WgWTZnSoupEpEZNKn2QqtSmOvWpUI2qVKdK1apa9apYzapW t8rVrnr1q2ANq1jHStaymvWsaE2rWtd6kE6w9a1wjatcrwSJudpVrX+4q14Hkte96vUPffXr tEwg2MIa9rCITaxiF8vYxjr2sZCNrGQnS9nKrikFls2sZjcLkWFw9rOgDa1oR0va0pr2tKhN rWpXy9rWuva1sI2tbP5nS9va2va2uM2tbnfL29769rfADa5wh6tbABgXACXix0CU+w/mMlcg z20uP6I73edGF7oEsS50q3td7jo3u9utbni7O13sgne55k2vdK+b3vKeFyLuXW98xVsQ7S53 vgYhL36xy14wGVcg/3XQd8273+ai18AEri+CEWzfg7B3vw8+8IIHvGACN7jBBx6wcvurEApX GMMMfq+H1TvhBFdYTAE20YbPC2EWZ1jB2qVuQh5s3wib+Mbd3e6LJXxjA6/4ITJu73v5O+QR n7jGHy5TigdyXAA3OcDHRe4/mjxlKv83yir5cYI17OD8whi9Qe7yl0Os4B6D18Y/NrKL7/4r Xut+N8wlJvGWh8xjEiMZzmFacpX3fGXk9nnPTuaznwfNEvrOmcyGTrSIw5td7tbX0T62MH0h zeD4nvjQat4xkcubZumWWchybnSQJ+1lUbsZz/6VMpMJ/edWS/nJhJ6yrAud5BB7GM2mfjOd d63rS1MYzv3lcqZ7vOI3t7nUoL70mYss5xyPOdRegjKrpy1oPldb2qrOMqjdrN5fd3vHIOb1 fZut6VqXmdvmJnak101uCWPY2e/e9qc1zeEuSfva1G41vp2c7ZR4e8IXlredyazsdnva1+7m cbDbG/BF25rI7F7ztwdu7n87W+L1tjeVq/zqfFsZ1oCetZ5Lgv/kdBt6vWy2NLudS+nx3trl E0f5rgn+YZXXnM0WhrbK9UtvUaf84DQXeJ5GvpB+SzXjKuYT0RGydKgiPbnEjbrUp071qlv9 6ljPOm+x/JCmh3wm7y5wnbU+kXs7xOtep3XFDU52ipi9IWg3Oky0XGsbt93tG+8zlrGt6o9/ /SV0X/i87y4Rruvd4/tO+0pOznIjP53wRYeyrF2d+FjTJPASHzvk4d5xflf+8zX5N46hXTk5 FNXsIKe86uUO+JhbfPNl37jIPZ5ivyv+JGE/9YYfD/uz9/5Vt/+98IdP/OIbfyZDOL7yl0/4 fAgkH9B3PkGgP5DoM/8gtWd9Qgyv/Zj+WL/603+++K+P/b533yD3Dv5KnM/+8YP/H+0nf/lX DRE9q18l8Xf/+NlPfec9YYGw1nEC2G/2J4D0F2h/9xH5B38FIX3xJ33y53mpR20HSH+qZ20p 8X0MGH4bqH/yt3eIt2QFiG+Ht34MCIHvh4Io+IF+9nki2HmUF2j3lxHtt4D7x4ERaG2r93Xp l2/X1hBsQIMn2IEpuIErSH5XBmi2R4B+x3EV+HYFwQZBqBHfp4LPB4H9l4NlMYUccYTC5YVl woWFVQtcAoZkIoaGRYZYYoZigoZpmCVsqIUKoYY/EodyOIdWYod3mBB0uIdq0oeiFQBUBYh7 EwCGeIj/YIj/BKGIL8GIAuGIHYGIiciIkjgQkliJCeGIh0iJm1gQnPiIlyiIniiKoNiJpUiK oJiKp6iKiriJqDiJmKiJpqiKsAiJk0iLptiKgqiLcSKLi/iKKwGJtvgQwLiIiQiLtXiLqdiJ wziKliiKvKiMywiN1CiNz2gQwriLr/iJt8iN0ZiNuEiK3CiN44iMn3iO2miNbeKLNQGOEtGM lniMvxiN3YiI8LiKyviNqKiPztiPv3iNtIiPvoiOAemNociKB2mN9piO01iP6sgmsmiQ2MiJ 7PiPpdiQFLmNobiPC6mRHsmQ9UiPBwGNCJmPHFmRAZmS5CiOHxmOJvmSAEmJj1iS//JYjQrJ iwOZjiK5jizpkK34jzipk0DpkzpZlEBplNe4k5XoiiuZjPdYkyVZjkwZkg85jBVplT3ZkCFp i1MJlTBJkrX4kfQYlA4JJzm5lUdJlO5IlGwJjmSZlCD5jNqIlGj5lLlYjVLJkATpjwDZlP54 lmyZlgJpk3epjroIkmS5kxDZk2PJkW0JjGeZmHEpmWkpjMeol4g5l5mZlfyYl1opknHpkip5 lZgJk1GJl6j5mY65kHC5i2X5JpHpmm5plD+ZlI8ZmBg5mXRpjoBZl8V4mqppkZ25j1W5msU4 m8B5k8G5l/zYmlppmnISm6PJnJDJktaJmVy5kROJjKOomf9zaZLU+JunuZHZiZAZaZN8yZ3b OY/ziJ6kiY4J2ZgxaZ3CiZ5apZjv6If2gYn62Z/++Z8AGqACOqAEihO8V6C9FwMIuqAM2qAO +qAQGqESOqEUWqEWeqEYmqEauqEc2qEB6iceGqIiKiZMMKImeqIomqIqOqF2sKKk0aIuehgw GqOFMaM0ahY2eqNkkaM6qhN2wKM9GqRCOqREWqRGeqRImqRKuqRM2qRO+qRQGqWHhTRTkxBU KqXqshBXejAh6lYlATBW2i9lAj1ZRymaAzIMEzlZCqVmajdmsylEUzyGwFnAojhyMyghczFY GjhxijcJs6ZRyjMpgzk9Mytcyqb/8JI1qhI28HKoe/oQYvqoHLGlklqplnqpmJqpmspa5/ek UIh+nep5TjiqoCpl1hCqZyd7CPqpBXF7LRiAlmeBsXoRf8agPZh9qJd3s7ZqJfiEURaA/GZ+ I7iDM1h8PeiCf8d1HFerBMF9ShiCs+qsMeiHx7p6zNqs1Sp3IPisLsiE+zZ5/pmt35qA4Hqs TEeBxBqtiEeq1AqD0Dp5BAiv5peAO9itybquqrqH0jqACDhysDpo6iqswiqD/IqtuNp3KIqq HXGtXbep5aewFeiwEjuxFFtbQlCxGNtaECulyhoRH2eAoBqxIduw20d0DJuDrMoQrzqtrTqv Jdt12ney/ycbgeLKd0y2q8F6rcBKqs66rLB6ry1LsO0qtHt3r9kHrw/rhOmKtLKKgcEqg9Wm r+7qs7MqqtxaqkoLrcw6gQVYgjPLgv3KtOTagv2qrStrr56ghOMaskdbrMKXq6yWrPJKtfP3 rq3mCZJ3gU2bhF/Lgrhatlg7qlDItyC7rIBruFFrsAfYtxC6sRvhCWmbsZI7uZRbuZZ7uZib uZq7uZzbuZ77uaAbuqI7uqRbupvHBabLW+fwn5iVuq77urAbu7I7u7Rbux8RBLbLVdCQu7zb u777u8ArfwMwAAIxvMU7vMT7D8ZbEMtLEM0rE8iLvMqbvAoRvcT7vAaBvdlLvf/Lq70Sgb3R +1nG273JO77UOxDa670w0bzq67zn277TW73va74Hcb4M8bzky1n0G7/uu73MK701wb72W78D LL8GjL77278Pgb8FnFnhe7z/67/OW7zHS74CXL7Xm8ECjMAcLMHTu8EKDMEP/MH2K70jbMIa TML0a73528EIzL0Y3FjWK8IJ7MIUrLw0HL8rnME6zMPjq8NAHME5/MMvvMM9zL9DPL8n7MNM 3L8M/MEcTMTBsQLJs7/5m74lDMBGvMVNnMDhO8IuvMNPHMVdPL9HTMYYXMZIjMIKbMEkDFlX HMP4i8T8y8VHbMdenMUebMRCnMRn7MdojMN4XL5/XMf/17vGDYxYcZzD6EvHizzId9zFQMzD fbzFIRzJhczHNHzIkCzIlAzBk8zJiXxYLfzAM0zHhozJblzBTYzINhzGlAy+ZmzFAPzCoAzK 5hvHtFzDb9zLLRy8wBzMwjzMxFzMxnzMOIGwEGt0ofqrIOG4u3qwA9uqN8ur1dysRYfNhUfN cIcR0KwSy4wmr1Z26NfNJQHN44yz2Yaw2rzO1czMkXfN9ed23qzNNEG22IfN32wi+Oyx5ayy JuG46Qxg1+zO+mzPIvfPL0vQ5LzNtIrQMtHP3EzQ+1wi+PyqN9t5c5vQ9ErNLovRF8104IqA +azOBV3S/aytCi3S6Sx5HF17/+0cry1duEdL0dbctTY90mpbrr5qsGS7s0VL0goxChYN03yL gSk90gOdszpI0Wer0+V81DjbzvbMzudq0Fa20vk8zlzN0y190OoM0gyd0z8ttkq91Wdb1lyN 0Wed0UntzlJd0doR0l3N0bNneR071WudhC891WAt0f9s0NGsEEn9ziste11dtGwt2HZt2AAL sgLb2GWtuHWt1mQd1iL40nx92XmdJV9d2Y5t00sN0XXN0J+9fQl9fktt1Yxt11ht2IRtgQcd 0mM92FRd2Oz82hld26Dd25wN0b8N1ZaNYqad2kh91qBN2sGN17Gd3Aq92lXNzYI90KP93JYt 1pIt2f/YPdzXDde8vdzGzdfc/dfGvdttHW27fdpKK4GmzcxBrdHKLM8y3d7yHNYTbbXUrbhP q3hYzdrWbNLsOtl/K7jx3bQtO94ht9gkjdN3XWUKKrhC3SZyrRFW7dcNzc8kC1n5uhK6Wt8V MeFmobAgzltgMFUjjswonuIqvuLAu+HPfBKdCuLeDdgfXuOoXdsXznmdHbgZQeMzfuN55uEv PhOtneHmnRLfXN1aveQAbeH3XdINq9IeDeRfUuRDHtHA7XtTDs703MzZ7M9OnuVijtpSDtZQ XuXzp9SLnbdj7d08y4Quy9NeneDRnNWzF9VIK9YF/tsu3bYMy9ZmrraPTd//5R3mpf2CR613 sA3fel2ua37kaC7dP7jZeZ7Tsm3eKp3Y3R3eP67gbt3UaW3WhBvefP7dlM6zTi3n1w3pge3p oj3coo3cJq1vCl61XALPbS3g4m3pxQ3hWPvaib3fpj7nAL7qCF7cpx3UvU7eZv7esh6xNL7o iBvrbT7b8gro5Q3ST4bj9kbe6o3gEu3c8SrcpV7s1u7q2U7sk43s7M7YFX7evQ7sha7T0R7v Fo7t0I3dvO7buD0mBS7gTX3euH7s6R63cf3q5w7vcTvnmo6tuf7s6L7u9i7rC7/uqs3us97X nU7qnx7sDe/vNZ3sN13tkk7gcL7gpB7nKU3bHW3s/xrP7Dsd8gAL8yTf5wFv899d8hqd3jc9 3Yvb6KtO5yfu2fMc0KRh5U9eGENvVSKOEktPEqqq2k9v9Cxe9VZ/9VZFAlhv9TWtWlLv4lbu 4iEx9WPf5BLvtubssets51R+4Nwu5LH99m5y8VSO62F+5h9B9nLf9iid3XEP5jk+2HT/3IZO znqP4X9/5uO+93jvEYe/sTF+2XA/+YkP+NU++BNd7+h89xrH64Zrsk847/cu8srq5k+984r+ 8ypP+rX61MJtf8ctgfOK2KuPuGwetIid3iGP4/Pt67Cf2soe5JXO836d7K7P7b1d67h/3OMN 7MqP3NvN/GM75fke3Bjv8v/Dj/G8Wv1y7vZOq+oJH+rErfCNTdUQn/S+/eyhzemUvva7Lu8U v+2fz/ugv9fNn/nyT+1n7/n/3v4XP9MAAeCfQAAFBf5DSHDgQoUHDyKEGFHiRIoVLV7EmFGj RIcLPSb8+DBiR4YgSUIUqbDkSpUqUZoEWTLlSJovV8Zs6bFhzZkfdVLM+bLj0Iknfe5kydNn yKQzRcZsCvOpVJk/N17FmlUrVqJHk3LEybDh1Ic5CZq1ORIp0a4uf7Z9OxAtXJk97VqFGdUm 2qp0wz4tqzdoWr5rae40vFXxYsZXC4YVepYsysBdOT5OWPmt0bxlSWKWm1ktZNClm56Fahow aNH+rfd6di3XIWzZrTljXo0782zIaj/v1jn5r+7GxY0fR55cq/CLU5U/hx5d+nTq1a1fx94c KEbW2b1/Bx9e/Hjy5c2fR59e/Xr27d2/hx9f/nz69e3fx59f/37+/f3/BzBAAQcksEADD0Qw QQUXZLBB+5w7rDvvINyKQsYs1G6iLTbqDkPuOMzIwxBvCs0ipJBzikQHuVoORI1EdDE5t65L 0TzmWOzpQ6jSymoyGFfcrscYdTTuR8eWsq7G8m48MscMkTSypsN2ALJEtoIzyDbdJBMKOIPY ynKpsWgb7SbiPrNwxrFSC460y2qTzSUJS0Ozs5Z8rO3LDv8yU0/KpNL+k8sO56yrL6aipO/K xxY11CtGU3LLMNYiLbEzpR6lKrGieGTUzKhOjCuyr/isSqzQNDW1S04NpVRVxBzFS0pTMV1z zQI1+1TFLC2zatdQ81QKTucCy3UwoL7kKUyzfAWV12X33G2w32YkrdMwMy0Vp06xBRZZ3y7F 1i8C4VLUK71IlZRUdHncy9JXdwRrx9t+bVTdczc1t1eq8J1LXlZhJfHVK/kF999RGxNGPUX7 LYxecme1FzVxH/6XM3iJndbdbB0O9a6Bg0JV4n1TFPgwjd8N2V9rG7V13JUZds3XVHtd9F1g TRZ2UJCJDYm4iwnLkTc23zzqTLJwQxPkNsH+mk1iaOOyC+lMBUXtMsCK1RfR/rQej+sqv7aR wWvjGxtss+Er+2y112a7bbffhjtuueemu26778Y7b7335rtvv/8G/L6j/4wtcMP11lpEaBsu zuvDH8fOcXZH9FBNjZGsEHLN25McXsqH7DjWxTrf/O+5NJOsLc+qLhN1bQH1Tc5h42UcONtm fh3OSiUsve9HT690VkqNyvjU02IV2eKrBdtuKGOfD713wOni62bikb8WY8HGfpZJiqlu1VuT lPVZfOl9t5T5r2p0cuh0Ma8e33Ynzqs3nHuz+Hy+MYVa6d9cDdadSqU0ACqPdtFb1/8uVzv9 7U1arvOS/WpWlJP+JKZ8ucldvJa2u6MJjUwZJJ/QMNfAuf2IdCz6zglJuEIUNod31FHhkVg4 QxrW0IY3xGEOdbhDHvbQhz/8jxOAOES8CZGIR5ybEZG4RCY20YlPhGIUpThFKlbRilfEYha1 uEUudtGLXwRjGMU4RjJ20QRSpAQlyrhG9KSRjW8kjxvhOMfvpFGNdMTjde6YRz720Y9/BGQg BTlIQhbSkIdEZCLxFglFNtKRj4RkJCU5SUpW0pKXxGQmNblJTl6SBXCsQCgrABFRivIfpQzl REpJylEiJJWsXOUrTznKV6KSIqt0ZStnOUtc5pKVsNSlLIPZSll2sj2oJKYtkSmRZfL/0pfA TKUwaTlNW0akmabcZTNzmcxtYlOYv9ylMY9Zy2jq0prm3GY6vYnOcLaznO405zqp6ctinpOb 8qTnKeEpTuvgQSvFfKcq2QlQak5ToODMpkErQlBeGrSewEzoOfOp0HbyMz0Pbag0D/rLWA50 mMpM5kMZ2tGMxtOUAX1mNPWpUazEIIxaQBA5y9lLkZo0mxV9Zkkp2sucRtSh1ZwoRcOp0p2y 06LlkalQEbrUd/I0pxqtqUQ5WlCcThWlQ63lPo96UagataYhxapHEdrUYdpTnWDFaFiduVat btU9yCwoS5lZTZludJ8zdeo10QpUtZZUqhVNq1vFQ1egppWm/mWd61gVyleIPjWuNnVsPeVa VcFW1rKXxWxmNbtZznbWs58FbWhFO9pKMvawU/UrNEOKzcQKFJcjfS1fGUrPw3bUqUwtK2Pd iVt7sva0PV1mV7vpVd/GlrUNVe1wi3rXxwL2o5JFZ2HzSliJBvaf0jUubVOr3ObatbfrpC1I eUrQexLWtrd1bnmnS0reJje1kw1ubh8bXfOetL5JtS9Jw6tdvQJXtiYV73j7i1Xk1BWf4J2s Yynb2L+SU7sK7i0sH2zf1la1thOG7krTS18JOzPBbSUrbveK4bVSGMLMLW97ZytNuaJ0tgSG sXGEa9WfLlXB1r1ti8F7S/qyuMYP/lasa58b0Z7eVKjr9W9bg8xfoybZwU+2qY6DTNIEI9nH Nl4wiItbYPlW18R/da822avPuQr4ymAm85Bd3Fy4qtKVEF1zYmkJ2Dc3mLi69bGJcxzlAF8V r1u+MYWrfNztEjPCDHZvN7G8mBnz18IeNS6hHfxdDh86yQT+cULPG1VMExmnRNXqizHa5gq3 +cy8va+T/zvlOce5wtAEJ3kB3GNJQ1bGXUbtnu161TLXur27njWU45xhtio3vMs160qfK+p4 nnjJnv41tD/N53SemKyuRvOj0ctpZ7+4OAYGd7Wz3WghE9u5z5b1pPXM60HH9qzifvZ24Tni ImvZ0+R9/zeaD4xYe4e73twOM67PfWnoaHPAhNb2pm294ePmWcqo9fB9ka3qs26b38ymtLOt /VPTUnfcHtcySPP9aO+e29RiJjXBv81TUvyW5L3G78LTXenh2tnLNF72kfl977gu9OK2hu7D bY5hhCO3yKMGdEqDHWgsA3zg2A26rxdNWqpX3epXx3rWtY6QQ2zd618He9jF3snpSjnqkP5y QDse6ZmjuOHy1a+m3x53bLs8qZw0OMjZvfa0c9zMCs94V818bCgbO+DMDbh6iz7JfdNb2nUt dZfhK3Aes9rnKZbzwv+9XMjnl8SZhO3NgazxfivV5jj++YKpfOdX17vYbIXt3t41iXTRP37n kdXvntkuVu7Ke/UX/jjwO2zyL2dZkrSHuO2bnvOinn213D65gJVdaHMnutY7b6qSMQlQio9e +6X3LrmBnfzM8xreLy9z+inuctCD2/Gyfz34J0/+8Xs/1ub3M+9rr3Z/L372UI85NtMt+UO5 +NK1QJO+iHM3bzO8Ycs5pbu99ou67zK2AQS/jIK559M/wXs7nJu4r+q7kEs91xu7EjTBE0TB FFRBHfqAFXTBF+Sba4DBGaTBGrTBG8TBHNTBHeTBHvTBHwTCIBTCISTCIjTCI0TCJHSQgAAA IfkEAB0AAAAsAAAAAJwBDAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGj x48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp 06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev 37+AAwumC2XwWUiGEytezLix48eQI0ueTLlkocqYM2vezLmzZ6ptPotuu2a06dOoU6tezbq1 69ewY8ueTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQo0ufTr269evYs2vfzr27 9+/gw/6LH0++vPnz6NOrX8++vfv38OPLn68TAn3o3+7r38+/v///AAYo4IAARkDggQgmqOCC DDbo4IMR2QPhhBRWaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqiiUCqs6OKLMGpkQ2xGxNhX jTbuhWOOee3I410+/lhXkOQZOByR4xmZlgVCMqRkk3Q9CaVcUk4JV5VWZqnlllx26aVY8nwp 5phklmnmmWimqeaabLbp5ptwxinnnHT+dU6deOap55589nngEH4GKuighBZq6KGIJqrooow2 6uhDnjwqlCeRSgpUpeFdYemmnHbq6aeghirqqKSWauqpqKaq6qqsturqq/+wxirrrLTWauut uOaq66689urrr8AGK+ywxBZr7LHIJqvsssw266yAmD4r7bTUVmvttdhmq+223Hbr7bfgEseO t+PihU246Kar7rrstuvuu/DGK++89NZr772lAoHvvvz26++/AKPXybcDd1uwnodUdfC2CzMc 8MMQR9wbPBJXbPHFGGes8cYcd+zxxyCHLPLIJJds8snzTYDyyiy37PLLMMcs88w012zzzTjn rPPOuYrD80Fx/Cy0X+YMbfTRSCddoNJMN+3001BHLfXUVFdt9dVYZ6311jb9wvXXYGuoQdhk V11N2Winrfbaco7C9ttwxy333HTXbbeJnNyt997sfPft99/nZQD44IQXbvjhiCeu+OKMM3RN 45BHLvnklN9VROWYZ6755px37vnnoIcu+uikE4VB6ainrnq/eYs6zOqwxy777LTjjE/tQxvT re7c8r6t7389kSLw2RK/pR9rGX+t8tYyH+sqITmPO1oKTG/99dhbqEv23Hfv/ffgh+9eOuKX b/756IP0Qfrst+9+opfhdvt88ctPP2/zv1f/bvmztz/+7fnf+waYJlMQ8IAITKACF8jABjrw gRBU2yl2hZiOnGKC2rpgBDfIwQ568IMgZM8sQkjCEppQNOs4oQpX6EFNsPCFMFxVQAAAIfkE AA8AAAAsAAAAAJwBDAIHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx41v PoocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQ o0qdSrWqVYQ4rmrdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+A AwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLkzXXOeQ4seTbq06dOoU6tezbq169ew Y8ueTbu27du4c+vezbu379/AgwsfTrxyreLIkytfzry58+fQo0ufTr269bfhrmvfzr279+/g w/6LJ+nAwfjl5c8rT68eufn28OPLn0+/vv37+PPr38+/v///AAYo4IAEFsjYOwYmqKBK5Szo 4IMQRijhhBRWaOGFwOWD4YYcdujhhyCGKOKIJJZo4okodndEipCtyGJjLr64WIx6WSHjQzTe eFiOOhrGY4+D/QikYEIO+VeRRiaJ1yZKNunkk1BGKeWUVNrWS5VYJhZLlnptySVesXj55Zhk lmnmmWimqaZ8Rqzp5ptwxinnnHQa1k+deOap55589unnn4AGKuighBZq6KGIJqrooow26uij kEYq6aSUVmrppZhmqummnHbq6aeghirqqKSWauqpqH4nS6oyrcpqTP+uvirrrIlhQOutuOaq 66689urrr65B0uQfwBZr7LHIJqvsssw26+yz0EYr7bTUVmvttdhmq+223Hbr7bfghivuuOSW a+5DSpz7kS7JmaDuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEF2zwwQgnrPDCDDdcVRZ4 3enwxBRXbPHFGGes8cYcd+zxxyCHLPLIJJds8sksmYHyyiy37PLL+9oC82qvmOpFTTWTm7PO 5u48rs/iAh2u0DMXbfTRSCet0BhKN430CU57pUDUVL9GQNVYZy2UM1p37fXXAsYANlVomFt2 uWeTm/a4aKzNnD9jxw1bMZaeUhTd5eJNrt714/ItbjF+81mN3IQXbvjhiCf+rxvlMi4tBBI5 /i0LBEk+ruXiYq745px37vnnoH+KZOikl2766ainjtweqrfu+utNIQH77LTXbvvtuOeu++68 QxZG78AHL/zwxBdvfL6WHK/8P+os7/zz0Ecv/fTUV2/99dhnr/323HePoT7eUyhm+OSXb/75 I42D/vrst+/++/DHL//89Ndv//3459+jrfr37///AAygAAdIwAIakCbfOKACF8jABrbFACdx mwMnSMEKWvCCGMygBjfIwQ4CC24eDKEIR0jCEprwhMT5RblUuEIUuvCFMIyhWAIgwxra8Iac CQgAOw== ------=_NextPart_000_000E_01C6E717.D869BC30-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 21:44:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUvo9-0003tY-50 for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 21:44:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUvo7-0002GU-K0 for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 21:44:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 027E039803B for ; Tue, 3 Oct 2006 18:44:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C9CAE43005F for ; Tue, 3 Oct 2006 18:43:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AFD151448009 for ; Tue, 3 Oct 2006 18:43:23 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 533AF1448024 for ; Tue, 3 Oct 2006 18:43:21 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k941h6L7017987; Wed, 4 Oct 2006 10:43:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k941h7x11432; Wed, 4 Oct 2006 10:43:07 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k941h5500632; Wed, 4 Oct 2006 10:43:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Oct 2006 09:42:03 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01365C7D@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbm5GWvbPQ30Bi0Rreg76ey9cp8aAAb98TQ From: "Cheng Hong" To: "Margaret Wasserman" , "Charles Clancy" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Dear all, We have been dragged into the discussion of the virtue of KeyRSC value (which should have been done in IEEE802.1 & 11i - a liaison to ask those experts why the KeyRSC is incorporated into their protocol in the first place), and the real problem about the CAPWAP protocol design has been put aside. So, is the conclusion now about demanding all CAPWAP compliant AC to always set KeyRSC to zero? (This is about the interoperability of the CAPWAP devices.) Is this the consensus of the WG? Will the disclaimer clearly state that by setting KeyRSC to zero the replay mechanism provided by 802.11i will be turned off and possible replay possibility has been increased? cheers Cheng Hong > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Tuesday, October 03, 2006 8:05 PM > To: Charles Clancy > Cc: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > Hi Charles, > > > > > If the consensus is to use RSC=0, then I think a disclaimer > statement > > should be added to the security considerations section about the > > replay possibility in multicast protocols. Overall this is > probably > > sufficient. > > This does seem like the simplest approach. So, if there is > no objection from our security advisors (you and Scott > Kelly), then I'm for it. > > > > Margaret > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 03 22:31:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwY8-0000bL-0s for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 22:31:56 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwY6-0007Zs-AO for capwap-archive@lists.ietf.org; Tue, 03 Oct 2006 22:31:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5D98F398043 for ; Tue, 3 Oct 2006 19:31:53 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 05DD143005F for ; Tue, 3 Oct 2006 19:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D42821448024 for ; Tue, 3 Oct 2006 19:31:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 3D7321448020 for ; Tue, 3 Oct 2006 19:31:13 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 19:31:13 -0700 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k942VCm0014506 for ; Tue, 3 Oct 2006 19:31:13 -0700 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k942VAlJ018592 for ; Wed, 4 Oct 2006 02:31:10 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 08:01:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Oct 2006 08:01:08 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01DED66A@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: discovery interval timer question Thread-Index: AcbnXSYmgj+5hOtMSUqeJWF2tPB/VQ== From: "Smitha Smitha (ssmitha)" To: X-OriginalArrivalTime: 04 Oct 2006 02:31:10.0451 (UTC) FILETIME=[27553C30:01C6E75D] Authentication-Results: sj-dkim-2.cisco.com; header.From=ssmitha@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0061205736==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This is a multi-part message in MIME format. --===============0061205736== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E75D.2757FD08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E75D.2757FD08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Idle to Discovery transition talks about Discovery Interval timer: =20 Idle to Discovery (a): This transition occurs once device initialization is complete. =20 WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request message (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 4.5). The WTP resets the DiscoveryCount counter to zero (0) (see Section 4.6). The WTP also clears all information from ACs it may have received during a previous Discovery phase. =20 But DiscoveryInterval timer is described as: =20 4.5.1. DiscoveryInterval =20 The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response, before initiating a DTLS handshake. =20 Should Idle to Discovery actually be based on MaxDiscoveryInterval timer? Also, there is mention of DiscoveryInterval timer even in transition from Discovery to Discovery. =20 4.5.6. MaxDiscoveryInterval =20 The maximum time allowed between sending discovery requests from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds. =20 Default: 20 seconds. =20 Thanks Smitha ------_=_NextPart_001_01C6E75D.2757FD08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
Idle to = Discovery=20 transition talks about Discovery Interval timer:
 
 Idle to=20 Discovery (a): This transition occurs once=20 device
      initialization is=20 complete.
 
      WTP: The WTP = enters the=20 Discovery state prior to transmitting=20 the
         first Discovery = Request=20 message (see Section 5.1). =20 Upon
         entering this = state,=20 the WTP sets the DiscoveryInterval=20 timer
         (see Section=20 4.5).  The WTP resets the DiscoveryCount=20 counter
         to zero (0) = (see=20 Section 4.6).  The WTP also clears=20 all
         information from = ACs it=20 may have received during a=20 previous
         Discovery=20 phase.
 
But = DiscoveryInterval timer=20 is described as:
 

4.5.1.  DiscoveryInterval
 
  =20 The minimum time, in seconds, that a WTP MUST wait after receiving=20 a
   Discovery Response, before initiating a DTLS=20 handshake.
 
Should Idle to Discovery actually be based on = MaxDiscoveryInterval=20 timer? Also, there is mention of DiscoveryInterval timer even in = transition from=20 Discovery to Discovery.
 
4.5.6. =20 MaxDiscoveryInterval
 
  =20 The maximum time allowed between sending discovery requests from=20 the
   interface, in seconds.  Must be no less than 2 = seconds=20 and no greater
   than 180 seconds.
 
   Default: 20 seconds.
 
Thanks
Smitha

------_=_NextPart_001_01C6E75D.2757FD08-- --===============0061205736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0061205736==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 04 02:36:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0N3-0002Tt-0l for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 02:36:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0Mz-0006Eg-FJ for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 02:36:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 3CB5B144805E for ; Tue, 3 Oct 2006 23:36:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 88FBC43005F for ; Tue, 3 Oct 2006 23:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 74F1B398025 for ; Tue, 3 Oct 2006 23:35:45 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id E321439800D for ; Tue, 3 Oct 2006 23:35:43 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6L006OIM6DR7@usaga01-in.huawei.com> for capwap@frascone.com; Tue, 03 Oct 2006 23:32:37 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6L00146M6CMW@usaga01-in.huawei.com> for capwap@frascone.com; Tue, 03 Oct 2006 23:32:37 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Wed, 04 Oct 2006 11:35:43 +0500 Date: Wed, 04 Oct 2006 11:35:43 +0500 From: zhaoyujin 31390 To: capwap@frascone.com Message-id: <299ff62299ce21.299ce21299ff62@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] One description issue for Type of message element TLV X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The following figure (In section 4.4) is different with the context. The type is 16bits, but the figure is 32bits Thanks Michael The format of a message element uses the TLV format shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Where Type (16 bit) identifies the character of the information carried in the Value field and Length (16 bits) indicates the number of bytes in the Value field. Type field values are allocated as follows: Usage Type Values CAPWAP Protocol Message Elements 1-1023 IEEE 802.11 Message Elements 1024-2047 Reserved for Future Use 2048 - 65024 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From haraldaroys@garetina.com Wed Oct 04 08:26:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5pL-0003U7-Ud for capwap-archive@ietf.org; Wed, 04 Oct 2006 08:26:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV5pL-0004gv-T5 for capwap-archive@ietf.org; Wed, 04 Oct 2006 08:26:19 -0400 Received: from 125-230-31-112.dynamic.hinet.net ([125.230.31.112] helo=garetina.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GV5pG-0007mO-9C for capwap-archive@ietf.org; Wed, 04 Oct 2006 08:26:19 -0400 Message-ID: <01c6e7b0$46490a10$701fe67d@GIGA> Date: Wed, 4 Oct 2006 20:26:10 +0800 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Enya Kennamer" From: "Enya Kennamer" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_21E37_01C6E7F3.548417D0" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_21E37_01C6E7F3.548417D0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, ClAvLIS AMBvlEN VALvlUM VlAvGRA Economize 60% http://www.yiavlavieb.info =20 _____ =20 militaristic status quo and war forever. Who perhaps prefer a future didnt understand it-yet I think that it affected you emotionally. enlist others of like age and mind. ------=_NextPart_000_21E37_01C6E7F3.548417D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

ClAvLIS

AMBvlEN

VALvlUM

VlAvGRA

 

militaristic status quo and war forever. Who perhaps prefer a = future
didnt understand it-yet I think that it affected you emotionally.
enlist others of like age and mind.

------=_NextPart_000_21E37_01C6E7F3.548417D0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 04 11:20:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8YN-0002dP-I7 for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 11:20:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8YJ-0003qh-QZ for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 11:20:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id F268439809F for ; Wed, 4 Oct 2006 08:20:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 490BC43009A for ; Wed, 4 Oct 2006 08:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 296914311F7 for ; Wed, 4 Oct 2006 08:20:14 -0700 (PDT) Received: from web60320.mail.yahoo.com (web60320.mail.yahoo.com [209.73.178.128]) by hermes.tigertech.net (Postfix) with SMTP id 9FD8D4311E5 for ; Wed, 4 Oct 2006 08:20:11 -0700 (PDT) Received: (qmail 99515 invoked by uid 60001); 4 Oct 2006 15:20:10 -0000 Message-ID: <20061004152010.99513.qmail@web60320.mail.yahoo.com> Received: from [12.129.211.52] by web60320.mail.yahoo.com via HTTP; Wed, 04 Oct 2006 08:20:10 PDT Date: Wed, 4 Oct 2006 08:20:10 -0700 (PDT) From: Behcet Sarikaya To: Dorothy Stanley MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE X-Spam-Level: ** Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039947351==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --===============2039947351== Content-Type: multipart/alternative; boundary="0-2001680706-1159975210=:99098" --0-2001680706-1159975210=:99098 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dorothy,=0A=0A=0A----- Original Message ----=0AFrom: Dorothy Stanley =0ATo: Bob O'Hara (boohara) =0ACc: = Saravanan Govindan ; Cheng Hong ; capwap@frascone.com=0ASent: Tuesday, October 3, 20= 06 5:09:55 PM=0ASubject: Re: [Capwap] Issue 43 - Explanation for 802.11i Co= nsiderations=0A=0ABob, all,=0A=0AComments inline.=0A=0AThanks,=0A=0ADorothy= =0A=0A=0AOn 9/29/06, Bob O'Hara (boohara) wrote:=0A =0A= Again, your proposal does not eliminate any attack mechanism and does not a= dd any functionality to the protocol, only cost and complexity. A replayed= frame will be discarded by the MAC, using the normal duplicate frame detec= tion mechanisms. See section 8.3.3.3.2 of 802.11i (where the frame sequenc= e number is part of the additional authenticated data) and section 9.2.9 of= 802.11-1999 for the description of these functions. And PLEASE read 802.1= 1 and 802.11i before again asserting that this proposal is necessary.=0A=0A= =0AIn Section 8.3.3.3.2, the AAD construction for CCMP includes the frame = sequence control field =96 and the sequence number, =0Abits 4-15 of the fra= me equence control field - is masked to 0 in the AAD; so that only the frag= ment number is protected.=0AThe TKIP MIC protects neither the fragment numb= er nor the sequence number of the 802.11 frame sequence control field, as = the TKIP MIC=0Ais MSDU based.=0A=0AIn 9.2.9, Duplicate detection and recove= ry, the text indicates that a STA may omit =0Abroadcast/multicast frame dat= a from its duplicate detection cache; if bc/mc data is not included, then n= ormal=0Aduplicate frame detection will not apply.=0A As I said several emai= ls ago, the ONLY effect of using zero as the value for the KeyRSC is that t= he 802.11 chipset in the STA (client) will have to receive the frame, attem= pt to decrypt it, and validate the MIC. This must be done for EVERY frame = received, whether it is a replayed frame or not. This set of functions is = performed in the 802.11 STA chipset and does not consume any additional res= ources of the STA. So, the attack, if it can even be characterized as an a= ttack, is no more effective at DOSing the STA than sending it any other fra= me.=0A=0AThe MIC calculation, and encrpt/decrypt is typically performed in = hardware in the chipset for CCMP.=0AHowever, the TKIP MIC calculation is ty= pically performed in the driver, in software.=0A=0AIf a STA does not have t= he proper RSC value, there is a "window of vulnerability" before it receive= s=0Athe correct value, during=0Awhich the STA can receive and process repla= yed bc/mc frames. The magnitude of the DOS aspect of this=0Adepends on the= STA crypto implementation - hw/ccmp - virtually no impact or sw/tkip-some = small impact.=0AThe larger issue is that the replay protection mechanism gu= arrantees provided by 802.11i are lost.=0A--snip=0A=3D=3D>=0AAre you favori= ng a solution Charles sketched, i.e. WTP sends keyRSC value during authenti= cation/reassociation of each new STA so that AC can use the correct (or clo= se to correct) value in Message 3 of 4-way handshake and Message 1 of group= key handshake?=0ACan you clarify this?=0A=0AThanks=0ABehcet --0-2001680706-1159975210=:99098 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Dorothy,

=0A
----- Original Mess= age ----
From: Dorothy Stanley <dstanley1389@gmail.com>
To: Bob= O'Hara (boohara) <boohara@cisco.com>
Cc: Saravanan Govindan <S= aravanan.Govindan@sg.panasonic.com>; Cheng Hong <Hong.Cheng@sg.panaso= nic.com>; capwap@frascone.com
Sent: Tuesday, October 3, 2006 5:09:55 = PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Consideratio= ns

Bob, all,

Comments inline.

Thanks,

Dorothy
=0A
On 9/29/06, Bob O'Hara (boohara) <boohara@cisco.com> wrote:=0A=0A
=0A
=  
=0A
Again, your proposal does not eliminate any attack mech= anism and does not add any functionality to the protocol, only cost and com= plexity.  A replayed frame will be discarded by the MAC, using the nor= mal duplicate frame detection mechanisms.  See section <= SPAN>8.3.3.3.2 of 802.11i (wher= e the frame sequence number is part of the additional authenticated data) a= nd section 9.2.9 of 802.11-1999 for the description of these functions= .  And PLEASE read 802.11 and 802.11i before again asserting that this= proposal is necessary.
=0A

= =0A

In Section 8.3.3.3.2, the AAD construction for CCMP&nb= sp; includes the frame sequence control field =96 and the sequence number, =
bits 4-15 of the frame equence control field - is masked to 0 in the AA= D; so that only the fragment number is protected.

=0A

The TKIP MIC protects neither the fragment number nor the sequ= ence number of  the 802.11 frame sequence control field, as the TKIP M= IC
is MSDU based.

=0A

In 9.2.9, Duplicate detection and recovery, the text indicates that a STA = may omit
broadcast/multicast frame data from its duplicate detection ca= che; if bc/mc data is not included, then normal
duplicate frame detectio= n will not apply.

=0A

 As I said several emails= ago, the ONLY effect of using zero as the value for the KeyRSC is that the= 802.11 chipset in the STA (client) will have to receive the frame, attempt= to decrypt it, and validate the MIC.  This must be done for EVERY fra= me received, whether it is a replayed frame or not.  This set of funct= ions is performed in the 802.11 STA chipset and does not consume any additi= onal resources of the STA.  So, the attack, if it can even be characte= rized as an attack, is no more effective at DOSing the STA than sending it = any other frame.

=0A

The MIC calculat= ion, and encrpt/decrypt is typically performed in hardware in the chipset f= or CCMP.
However, the TKIP MIC calculation is typically performed in the= driver, in software.

=0A

If a STA do= es not have the proper RSC value, there is a "window of vulnerability" befo= re it receives
the correct value, during
which the STA can receive an= d process replayed  bc/mc frames. The magnitude of the DOS aspect of t= his
depends on the STA crypto implementation - hw/ccmp - virtually no im= pact or sw/tkip-some small impact.
The larger issue is that the replay p= rotection mechanism guarrantees provided by 802.11i are lost.=

=0A

--snip

=0A

=3D= =3D>

=0A

Are you favoring a solution C= harles sketched, i.e. WTP sends keyRSC value during authentication/reassoci= ation of each new STA so that AC can use the correct (or close to correct) = value in Message 3 of 4-way handshake and Message 1 of group key handshake?=

=0A

Can you clarify this?<= /P>=0A

 

=0A

Thanks=

=0A

Behcet

=
--0-2001680706-1159975210=:99098-- --===============2039947351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2039947351==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 04 12:26:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9aD-0000l4-SD for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 12:26:57 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9Mu-0006CU-IZ for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 12:13:18 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF925398044 for ; Wed, 4 Oct 2006 09:13:06 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5B38743009A for ; Wed, 4 Oct 2006 09:08:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33A65431831 for ; Wed, 4 Oct 2006 09:08:21 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id ADA1143185E for ; Wed, 4 Oct 2006 09:07:49 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id m19so510533nfc for ; Wed, 04 Oct 2006 09:07:48 -0700 (PDT) Received: by 10.48.254.1 with SMTP id b1mr2550118nfi; Wed, 04 Oct 2006 09:07:48 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Wed, 4 Oct 2006 09:07:47 -0700 (PDT) Message-ID: <5bfe7a820610040907n6113d32cq4f875a72795f8f14@mail.gmail.com> Date: Wed, 4 Oct 2006 09:07:47 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_60_70, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed Resolution for Issue 204: More General wireless support /was Re: suggestion for Issue # 204, "More general wireless support" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183930124==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 0489daa2bca46f53f2cc9214d1b54371 --===============1183930124== Content-Type: multipart/alternative; boundary="----=_Part_32828_33497798.1159978067877" ------=_Part_32828_33497798.1159978067877 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Issue 204 and proposed resolutions to its components are listed below. Comments please. Thanks, Dorothy ------------------------------------------------------------------------------------------------------------------------- 1) 4.4.38. WTP Radio Information Comment: As the section should be work for any wireless implement, I suggest the following value should be moved to 802.11 binding. The value should be defined by wireless technology binding. 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. Proposed Resolution: Move the "need to know" the 802.11 technology specific radio types to the 802.11 binding, modifying the WTP Radio Information element as follows: IEEE 802.11 Radio Information The IEEE 802.11 radio information message element is used to communicate the radio information for each IEEE 802.11 radio on the WTP. The Discovery Request message MUST include one such message element per radio in the WTP. The Radio- Type field is used by the AC to determine which 802.11 technology specific binding is to be used with the WTP. The value contains two fields, as shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Radio Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio Type | +-+-+-+-+-+-+-+-+ Type: 38 for WTP Radio Information Length: 5 Radio ID: The Radio Identifier, which typically refers to an interface index on the WTP Radio Type: The type of IEEE 802.11 radio present. The following values are supported: 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types indicated are supported in the WTP. ------------------------------------------------------------------------------------------- 2) 11.9.18. IEEE 802.11 Tx Power Comment: I think it could be moved to the section 4.4, as channel and Tx power are common parameters for RF management. Proposed Resolution: No change to the draft. Agree with the commenter that TX power level is a common parameter for RF management; however the IEEE 802.11 TX Power field values are defined as being the values defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions. --------------------------------------------------------------------------- 3) Add "WTP radio channel" Comment: As per 2), we could define a TLV to report current channel (AP to AC) or to configure channel (AC to AP). Now,. 11.9.12. IEEE 802.11 OFDM Control and 11.9.5. IEEE 802.11 Direct Sequence Control has channel configuration information. But I think that a specific TLV for it is better. By this way, 4.4 will provide more common parameter for any wireless technology. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Current Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The commenter suggests the following: 3) Add "WTP RF Radio configuration" in the section 4.4 The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5. IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. Proposed Resolution: No change to the draft. While there may be common elements, it's not clear that the CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems. ------------------------------------------------------------------------------------ 4) 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indications Comment: I think it could be moved to the section 4.4, it could be a common event for any wireless technology. Proposed Resolution: No change to the draft. Agree with the commmenter that a fail alarm indication could be a common event for any wireless technology. Each radio technology may want to have additional information reported with the event however. Not sure there is sufficient benefit shown for a common defintiion at this point. --------------------------------------------------------------------------------------- 5) 11.9.1. IEEE 802.11 Add WLAN How about we rename "WLAN" as wireless service? By this way, we could achieve abstract while make it work for most wireless technology. If it is ok, we could define "add wireless service, delete wireless service, update wireless service" in the section 4.4. Any wireless technology could add its specific parameter in the binding section. The commenter suggests a solution: 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here). While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using (Probably eventually managed by IANA) Proposed resolution: Close, no change to the draft. The IEEE 802.11 Add WLAN message element is 802.11 specific and used together with several other message elements to define a WLAN service. The intent of the comment seems to be to have the ability in the CAPWAP protocol to add a generic wireless service. It's not clear that there are enough additional elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. -------------------------------------------------------------------------------- 6) 11.9.22. IEEE 802.11 WTP Quality of Service As per 5), I think we could define "WTP Quality of Service"in the section 4.4. Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality of Service". While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of Service. The commenter suggests the following solution: 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. Proposed resolution: Close, no change to the draft. The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed to convey the CWMin , CWMax and other very specific 802.11 data. The intent of the comment seems to be to have the ability in the CAPWAP protocol to include a "generic QOS" message element. It's not clear that there are enough elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. There is at least 1 - the Tag packets type, which each binding can inlcude if desired. ---------------------------------------------------------------------------------------------------------------------------------- 7. Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4 Comment: Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. Proposed resolution: No change to the draft. Agree with the commenter that many of the statistics are common across wireless technologies. However the IEEE 802.11 Statistics values are defined as being the values defined in various IEEE 802.11 MIB variables and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions. On 9/28/06, young wrote: > > Hi Pat and all, > > I used to raise issue #204, and here intend to give solution. > > 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", > and put it in the section 4.4 > > The glossary "wireless service" will be more abstract than "WLAN". > > Refer to current "IEEE 802.11 add WLAN" format, we could keep > > Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode > > these kinds common element (more element maybe put here). > > While for any specific wireless binding could follow the Wireless binding > identifier. > > The Wireless binding identifier will identify what kinds binding are using > > (Probably eventually managed by IANA) > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | WLAN ID | MAC Mode | Tunnel > Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Wireless binding identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Value... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update > WLAN". > > * * > > 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality > of Service" > > Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the > "WTP Quality of Service". > > For any binding, we use Wireless binding identifier to suggest them. > > For Tag Packets, if IANA already have some kind assignment, it will be > great. > > > > 3) Add "WTP RF Radio configuration" in the section 4.4 > > The Tx power, radio type, channel assignment and so on these kind > parameter are common for any kind wireless binding. > > I suggest CAPWAP define it in the base protocol part. > > Although the protocol already has "WTP Radio Information", while Tx power > these kind Info should not be sent > > during discovery and join phase. So the separated "WTP RF Radio > configuration" is better. > > If keep them in one, which element will be mandatory in what kind message > should be suggested by protocol. > > The TLV of "WTP RF Radio configuration" will include radio ID, radio type, > Tx power, Channel, country code and so on. > > For any binding, we use Wireless binding identifier to suggest them. > > The "WTP RF Radio configuration" could be sent by bi-direction, by this > way, AC could configure WTP's RF parameter > > and know current configuration on the WTP radio. > > If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE > 802.11 OFDM Control "and "11.9.5. > > IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE > 802.11 related element. > > > > 4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the > section 4.4 > > Most case, the wireless binding will be link layer protocol, I think most > the element in the "IEEE 802.11 Statistics" > > could be put on the section 4.4, except the element like "RTS Success > Count" and so on. > > For any binding, we use Wireless binding identifier to suggest them. > > > > Any way, I thought many TLV will change their location as new CAPWAP will > be divided into two parts. > > > > Cheers > > > > Richard (Shiyang) > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_32828_33497798.1159978067877 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

Issue 204 and proposed resolutions to its components are
listed below.

Comments please.

Thanks,

Dorothy

-------------------------------------------------------------------------------------------------------------------------
1) 4.4.38.  WTP Radio Information

Comment: As the section should be work for any wireless implement, I suggest the 

following value

 should be moved to 802.11 binding. The value should be defined by wireless 

technology binding.

      1 - 802.11b:  An IEEE 802.11b radio.


      2 - 802.11a:  An IEEE 802.11a radio.

      4 - 
802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n radio.

Proposed Resolution: Move the "need to know" the 
802.11 technology specific
radio types to the 802.11 binding, modifying the WTP Radio Information element
as follows:

IEEE 802.11 Radio Information

   The IEEE 802.11 radio information message element is used to communicate the

   radio information for each IEEE 802.11 radio on the WTP.  The Discovery Request message MUST
   include one such message element per radio in the WTP.  The Radio-
   Type field is used by the AC to determine which 
802.11 technology
   specific binding is to be used with the WTP.

   The value contains two fields, as shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |           Radio Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | Radio Type    |
     +-+-+-+-+-+-+-+-+

   Type:  38 for WTP Radio Information

   Length:  5

   Radio ID:  The Radio Identifier, which typically refers to an
      interface index on the WTP


   Radio Type:  The type of IEEE 802.11 radio present.  
      The following values are supported:

      1 - 802.11b:  An IEEE 802.11b radio.

      2 - 802.11a:  An IEEE 802.11a radio.

      4 - 
802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n radio.

      0xOF - 802.11b, 802.11a, 802.11g and 802.11n:  The 4 radio types
         indicated are supported in the WTP.
 
-------------------------------------------------------------------------------------------

2) 11.9.18.  IEEE 802.11 Tx Power

Comment: I think it could be moved to the section 4.4, as channel and Tx power are 
common parameters for RF management.

Proposed Resolution: No change to the draft. Agree with the commenter

that TX power level is a common parameter for RF management; however the
IEEE 802.11 TX Power field values are defined as being the values
defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not

extensible to other bindings. Expect that each binding will define
values relative to its definitions.
---------------------------------------------------------------------------
3)  Add "WTP radio channel"


Comment: As per 2), we could define a TLV to report current channel (AP to AC) or to 

configure channel (AC to AP).

Now,. 11.9.12.  IEEE 802.11 OFDM Control and 11.9.5.  IEEE 802.11 Direct 

Sequence Control

has channel configuration information. 


But I think that a specific TLV for it is better. By this way, 4.4 will provide


more common parameter for any wireless technology.

     0                   1                   2                   3


        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    Radio ID   |    Reserved   |        Current Channel       |


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The commenter suggests the following:

3)      Add "WTP RF Radio configuration" in the section 4.4

The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding.

I suggest CAPWAP define it in the base protocol part.

Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent

during discovery and join phase. So the separated "WTP RF Radio configuration" is better.

If keep them in one, which element will be mandatory in what kind message should be suggested by protocol.

The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on.

For any binding, we use Wireless binding identifier to suggest them.

The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter

and know current configuration on the WTP radio.

If this way, current "11.9.18.  IEEE 802.11 Tx Power", "11.9.12.  IEEE 802.11 OFDM Control "and "11.9.5. 

IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element.

 Proposed Resolution: No change to the draft.  While there may be common elements, it's not clear that the
CAPWAP base specification should take on the task of extracting/unifying the common elements
across wireless systems. 


------------------------------------------------------------------------------------
4) 11.9.24.  IEEE 802.11 WTP Radio Fail Alarm Indications

Comment: I think it could be moved to the section 4.4, it could be a common event for 

any wireless technology.

 Proposed Resolution: No change to the draft. Agree with the commmenter
that a fail alarm indication could be a common event for
any wireless technology. Each radio technology may want to

have additional information reported with the event however. Not
sure there is sufficient benefit shown for a common defintiion at this point.
---------------------------------------------------------------------------------------

5) 11.9.1.  IEEE 802.11 Add WLAN

How about we rename "WLAN" as wireless service? By this way, we could achieve 

abstract while make it work

for most wireless technology.


If it is ok, we could define "add wireless service, delete wireless service, 
update wireless service" in the section 
4.4.

Any wireless technology could add its specific parameter in the binding 

section.


The commenter suggests a solution:

1)       Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4

The glossary "wireless service" will be more abstract than "WLAN".

Refer to current "IEEE 802.11 add WLAN" format, we could keep

Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode

these kinds common element (more element maybe put here).

While for any specific wireless binding could follow the Wireless binding identifier.

The Wireless binding identifier will identify what kinds binding are using

( Probably eventually managed by IANA)

Proposed resolution: Close, no change to the draft.
The IEEE 802.11 Add WLAN message element is 802.11 specific and used
together with several other message elements to define a WLAN service.

The intent of the comment seems to be to have the ability in the
CAPWAP protocol to add a generic wireless service. It's not clear that
there are enough additional elements common to multiple wireless
services to have a separate CAPWAP level element at this at this time.



--------------------------------------------------------------------------------
6) 11.9.22.  IEEE 802.11 WTP Quality of Service

As per 5), I think we could define "WTP Quality of Service"in the section 
4.4.

Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality of 

Service".

While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of 

Service.

The commenter suggests the following solution:

2) Rename "11.9.22.  IEEE 802.11 WTP Quality of Service" as  "WTP Quality of Service"

Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service".

For any binding, we use Wireless binding identifier to suggest them.

For Tag Packets, if IANA already have some kind assignment, it will be great.

Proposed resolution: Close, no change to the draft.
The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed
to convey the CWMin , CWMax and other very specific 802.11 data.

The intent of the comment seems to be to have the ability in the
CAPWAP protocol to include a "generic QOS" message element. It's not clear that
there are enough elements common to multiple wireless
services to have a separate CAPWAP level element at this at this time.
There is at least 1 - the Tag packets type, which each binding can inlcude if
desired.

----------------------------------------------------------------------------------------------------------------------------------

7. Redefine "IEEE 802.11 Statistics" as  "WTP Statistics" in the section 4.4

Comment: Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics"

could be put on the section 4.4, except the element like "RTS Success Count" and so on.

For any binding, we use Wireless binding identifier to suggest them.

Proposed resolution: No change to the draft. Agree with the commenter
that many of the statistics are common across wireless technologies.
However the IEEE 802.11 Statistics values are defined as being the values
defined in various IEEE 802.11 MIB variables and thus are not extensible to
other bindings. Expect that each binding will define values relative to its definitions.


On 9/28/06, young <young@huawei-3com.com> wrote:

Hi Pat and all,

I used to raise issue #204, and here intend to give solution.

1)       Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4

The glossary "wireless service" will be more abstract than "WLAN".

Refer to current "IEEE 802.11 add WLAN" format, we could keep

Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode

these kinds common element (more element maybe put here).

While for any specific wireless binding could follow the Wireless binding identifier.

The Wireless binding identifier will identify what kinds binding are using

( Probably eventually managed by IANA)

 

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    Radio ID   |    WLAN ID    |        MAC Mode    | Tunnel Mode       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |             Wireless binding identifier                      |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |         Type                  |             Length            |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |                          Value...

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN".

 

2) Rename "11.9.22.  IEEE 802.11 WTP Quality of Service" as  "WTP Quality of Service"

Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service".

For any binding, we use Wireless binding identifier to suggest them.

For Tag Packets, if IANA already have some kind assignment, it will be great.

 

3)      Add "WTP RF Radio configuration" in the section 4.4

The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding.

I suggest CAPWAP define it in the base protocol part.

Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent

during discovery and join phase. So the separated "WTP RF Radio configuration" is better.

If keep them in one, which element will be mandatory in what kind message should be suggested by protocol.

The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on.

For any binding, we use Wireless binding identifier to suggest them.

The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter

and know current configuration on the WTP radio.

If this way, current "11.9.18.  IEEE 802.11 Tx Power", "11.9.12.  IEEE 802.11 OFDM Control "and "11.9.5. 

IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element.

 

4)      Redefine "IEEE 802.11 Statistics" as  "WTP Statistics" in the section 4.4

Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics"

could be put on the section 4.4, except the element like "RTS Success Count" and so on.

For any binding, we use Wireless binding identifier to suggest them.

 

Any way, I thought many TLV will change their location as new CAPWAP will be divided into two parts.

 

Cheers

 

Richard  (Shiyang)

 


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_32828_33497798.1159978067877-- --===============1183930124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1183930124==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 04 14:32:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBXX-0006uk-JE for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 14:32:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBXV-0004ms-G1 for capwap-archive@lists.ietf.org; Wed, 04 Oct 2006 14:32:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D9157398076 for ; Wed, 4 Oct 2006 11:32:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 78A7E43009A for ; Wed, 4 Oct 2006 11:29:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 55A70431F3C for ; Wed, 4 Oct 2006 11:29:27 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by hermes.tigertech.net (Postfix) with ESMTP id 828E9431F3E for ; Wed, 4 Oct 2006 11:29:20 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id m19so548111nfc for ; Wed, 04 Oct 2006 11:29:18 -0700 (PDT) Received: by 10.49.91.6 with SMTP id t6mr2712584nfl; Wed, 04 Oct 2006 11:29:18 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Wed, 4 Oct 2006 11:29:18 -0700 (PDT) Message-ID: <5bfe7a820610041129i4703812w37892c2658e534fa@mail.gmail.com> Date: Wed, 4 Oct 2006 11:29:18 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Proposed Resolution to Issue 220 "Ambiguitues with DTLS"/ was Ambiguities with DTLS X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875717914==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be --===============1875717914== Content-Type: multipart/alternative; boundary="----=_Part_37371_8135035.1159986558166" ------=_Part_37371_8135035.1159986558166 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, The proposed resolution to Issue 220 is below. Comments welcome. Thanks, Dorothy ---------------------------------------------------------------------------------------------------------------------- 1. The current draft seems to be ambiguous with respect to two DTLS items. The draft says in the section describing the stat machine transitions: Idle to Init (Z): This transition indicates the beginning of a DTLS session. WTP: The state transition is triggered by receipt of the DTLSStart command from the CAPWAP state machine, and causes the WTP to send a DTLS ClientHello to the AC. AC: The state transition is triggered by receipt of the DTLSStart command from the CAPWAP state machine. The AC starts the WaitJoin timer and awaits reception of a DTLS ClientHello message. In the description of transition aa, the draft says: AC: Upon receipt of a ClientHello message containing a valid cookie, the AC sets the WaitJoin timer. These two transitions seem to require "starting" or "setting" the Waitjoin timer in the AC both before and after the receipt of the ClientHello message. I believe the text in transition z is correct and should either be reflected in the description of transition aa, or removed from it to avoid conflict. Proposed resolution: No change to the description of (aa). The current text describing Transition (aa), listed below, does not reference the WaitJoin Timer: Idle to Join (aa): This transition occurs when the WTP presents a DTLS ClientHello message containing a valid cookie to the AC. WTP: This transition is a no-op for the WTP. AC: The AC does not maintain state information until the WTP presents a DTLS ClientHello message containing a valid cookie. Upon receipt of a DTLS ClientHello message containing a valid cookie, the AC creates session state and transitions to the Join state. The text in 6.2 though is incorrect in its description of WaitJoin timer usage. Change from: After determining that a WTP should join the AC, the AC creates session state containing the WTP address, port and session ID, sets the WaitJoin timer for the session, sends the Join Response message to the WTP. The WTP, receiving a Join Response message checks for success or failure. If the message indicates success, the WTP clears the WaitJoin timer for the session and proceeds to the Configure or Image Data state. Otherwise, the WTP enters the CAPWAP reset state, resulting in shutdown of the DTLS session. to Upon receipt of the DTLSClientHello, the AC creates session state containing the WTP address, port and session ID, sets the WaitJoin timer for the session, sends the Join Response message to the WTP. The WTP, receiving a Join Response message checks for success or failure. If the message indicates success, the WTP clears the WaitJoin timer for the session and proceeds to the Configure State. Otherwise, the WTP enters the CAPWAP reset state, resulting in shutdown of the DTLS session. Similarly, the text in 6.1 is incorrect in its description of WaitJoin Timer usage. Change from: The Join Request message is used by a WTP to inform an AC that it wishes to provide services through the AC. A Join Request message is sent by a WTP after receiving one or more Discovery Responses, and completion of DTLS session establishment. When an AC receives a Join Request message it responds with a Join Response message. Upon completion of the DTLS handshake (synonymous with DTLS "session establishment"), the WTP sends the Join Request message to the AC. Upon receipt of the Join Request Message, the AC generates a Join Response message and sends it to the WTP, indicating success or failure. Upon transmission of the Join Request message, the WTP sets the WaitJoin timer. If the Join Response message has not been received prior to expiration, the WTP aborts the Join process and transitions back to the Discovery state, see Section 2.3.1). Upon receipt of the Join Response message, the WaitJoin timer is deactivated. If the AC rejects the Join Request, it sends a Join Response with a failure indication then enters the CAPWAP reset state, resulting in shutdown of the DTLS session. Upon determining which AC to join, the WTP creates session state containing the AC address and session ID, creates the Join Request message, sets the WaitJoin timer for the session and sends the Join Request message to the AC. to The Join Request message is used by a WTP to inform an AC that it wishes to provide services through the AC. A Join Request message is sent by a WTP after (optionally) receiving one or more Discovery Responses, and completion of DTLS session establishment. When an AC receives a Join Request message it responds with a Join Response message. Upon completion of the DTLS handshake (synonymous with DTLS "session establishment"), the WTP sends the Join Request message to the AC. Upon receipt of the Join Request Message, the AC generates a Join Response message and sends it to the WTP, indicating success or failure. If the AC rejects the Join Request, it sends a Join Response with a failure indication then enters the CAPWAP reset state, resulting in shutdown of the DTLS session. 2. The draft also says, in the description of transition o, that the WTP should send DTLSReset to the state machine. Should this be DTLSShutdown? Proposed resolution: Yes. Change "DTLSReset" to "DTLSShutdown" On 9/14/06, Pat Calhoun (pacalhou) wrote: > > Tracker issue 220 created. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Bob O'Hara (boohara) > > Sent: Thursday, September 14, 2006 9:22 AM > > To: Capwap@frascone.com > > Subject: [Capwap] Ambiguities with DTLS > > > > The current draft seems to be ambiguous with respect to two > > DTLS items. > > > > The draft says in the section describing the stat machine transitions: > > Idle to Init (Z): This transition indicates the beginning of > > a DTLS session. > > > > WTP: The state transition is triggered by receipt of the > > DTLSStart command from the CAPWAP state machine, and causes > > the WTP to send a DTLS ClientHello to the AC. > > > > AC: The state transition is triggered by receipt of the > > DTLSStart command from the CAPWAP state machine. The AC > > starts the WaitJoin timer and awaits reception of a DTLS > > ClientHello message. > > > > In the description of transition aa, the draft says: > > AC: Upon receipt of a ClientHello message containing a valid > > cookie, the AC sets the WaitJoin timer. > > > > These two transitions seem to require "starting" or "setting" > > the Waitjoin timer in the AC both before and after the > > receipt of the ClientHello message. I believe the text in > > transition z is correct and should either be reflected in the > > description of transition aa, or removed from it to avoid conflict. > > > > The draft also says, in the description of transition o, that > > the WTP should send DTLSReset to the state machine. Should > > this be DTLSShutdown? > > > > -Bob > > > > Bob O'Hara > > Cisco Systems - WNBU > > > > Phone: +1 408 853 5513 > > Mobile: +1 408 218 4025 > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_37371_8135035.1159986558166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

The proposed resolution to Issue 220 is below. 

Comments welcome.

Thanks,

Dorothy
----------------------------------------------------------------------------------------------------------------------
1. The current draft seems to be ambiguous with respect to two DTLS items.
 The draft says in the section describing the stat machine transitions:
Idle to Init (Z): This transition indicates the beginning of a DTLS session.
 
WTP: The state transition is triggered by receipt of the DTLSStart command 
from the CAPWAP state machine, and causes the WTP to send a DTLS ClientHello 
to the AC.
 
AC: The state transition is triggered by receipt of the DTLSStart command from 
the CAPWAP state machine. The AC starts the WaitJoin timer and awaits 
reception of a DTLS ClientHello message.
 
In the description of transition aa, the draft says:
AC: Upon receipt of a ClientHello message containing a valid cookie, the AC 
sets the WaitJoin timer.  
 
These two transitions seem to require "starting" or "setting" the Waitjoin 
timer in the AC both before and after the receipt of the ClientHello message.  
I believe the text in transition z is correct and should either be reflected 
in the description of transition aa, or removed from it to avoid conflict.
 
Proposed resolution: No change to the description of (aa). The current text describing
Transition (aa), listed below, does not reference the WaitJoin Timer:

   Idle to Join (aa): This transition occurs when the WTP presents a

      DTLS ClientHello message containing a valid cookie to the AC.

      WTP: This transition is a no-op for the WTP.

      AC: The AC does not maintain state information until the WTP

         presents a DTLS ClientHello message containing a valid cookie.

         Upon receipt of a DTLS ClientHello message containing a valid

         cookie, the AC creates session state and transitions to the

         Join state.


The text in 6.2 though is incorrect in its description of WaitJoin timer
usage. Change from:

   After determining that a WTP should join the AC, the AC creates

   session state containing the WTP address, port and session ID, sets
   the WaitJoin timer for the session, sends the Join Response message
   to the WTP.

   The WTP, receiving a Join Response message checks for success or

   failure.  If the message indicates success, the WTP clears the
   WaitJoin timer for the session and proceeds to the Configure or Image
   Data state.  Otherwise, the WTP enters the CAPWAP reset state,
   resulting in shutdown of the DTLS session.


to

   Upon receipt of the DTLSClientHello, the AC creates
   session state containing the WTP address, port and session ID, sets
   the WaitJoin timer for the session, sends the Join Response message

   to the WTP.

   The WTP, receiving a Join Response message checks for success or
   failure.  If the message indicates success, the WTP clears the
   WaitJoin timer for the session and proceeds to the Configure State.  

   Otherwise, the WTP enters the CAPWAP reset state,
   resulting in shutdown of the DTLS session.

Similarly, the text in 6.1 is incorrect in its description of
WaitJoin Timer usage. 

Change from:


The Join Request message is used by a WTP to inform an AC that it
   wishes to provide services through the AC.  A Join Request message is
   sent by a WTP after receiving one or more Discovery Responses, and

   completion of DTLS session establishment.  When an AC receives a Join
   Request message it responds with a Join Response message.

   Upon completion of the DTLS handshake (synonymous with DTLS "session

   establishment"), the WTP sends the Join Request message to the AC.
   Upon receipt of the Join Request Message, the AC generates a Join
   Response message and sends it to the WTP, indicating success or
   failure.


   Upon transmission of the Join Request message, the WTP sets the
   WaitJoin timer.  If the Join Response message has not been received
   prior to expiration, the WTP aborts the Join process and transitions

   back to the Discovery state, see Section 2.3.1).  Upon receipt of the
   Join Response message, the WaitJoin timer is deactivated.

   If the AC rejects the Join Request, it sends a Join Response with a

   failure indication then enters the CAPWAP reset state, resulting in
   shutdown of the DTLS session.

   Upon determining which AC to join, the WTP creates session state
   containing the AC address and session ID, creates the Join Request

   message, sets the WaitJoin timer for the session and sends the Join
   Request message to the AC.

to

The Join Request message is used by a WTP to inform an AC that it
   wishes to provide services through the AC.  A Join Request message is

   sent by a WTP after (optionally) receiving one or more Discovery Responses, and
   completion of DTLS session establishment.  When an AC receives a Join
   Request message it responds with a Join Response message.


   Upon completion of the DTLS handshake (synonymous with DTLS "session
   establishment"), the WTP sends the Join Request message to the AC.
   Upon receipt of the Join Request Message, the AC generates a Join

   Response message and sends it to the WTP, indicating success or
   failure.

   If the AC rejects the Join Request, it sends a Join Response with a
   failure indication then enters the CAPWAP reset state, resulting in

   shutdown of the DTLS session.


2. The draft also says, in the description of transition o, that the WTP should 
send DTLSReset to the state machine.  Should this be DTLSShutdown?
Proposed resolution: Yes. Change "DTLSReset" to "DTLSShutdown"

On 9/14/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
Tracker issue 220 created.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Bob O'Hara (boohara)
> Sent: Thursday, September 14, 2006 9:22 AM
> To: Capwap@frascone.com
> Subject: [Capwap] Ambiguities with DTLS
>
> The current draft seems to be ambiguous with respect to two
> DTLS items.
>
> The draft says in the section describing the stat machine transitions:
> Idle to Init (Z): This transition indicates the beginning of
> a DTLS session.
>
> WTP: The state transition is triggered by receipt of the
> DTLSStart command from the CAPWAP state machine, and causes
> the WTP to send a DTLS ClientHello to the AC.
>
> AC: The state transition is triggered by receipt of the
> DTLSStart command from the CAPWAP state machine. The AC
> starts the WaitJoin timer and awaits reception of a DTLS
> ClientHello message.
>
> In the description of transition aa, the draft says:
> AC: Upon receipt of a ClientHello message containing a valid
> cookie, the AC sets the WaitJoin timer.
>
> These two transitions seem to require "starting" or "setting"
> the Waitjoin timer in the AC both before and after the
> receipt of the ClientHello message.  I believe the text in
> transition z is correct and should either be reflected in the
> description of transition aa, or removed from it to avoid conflict.
>
> The draft also says, in the description of transition o, that
> the WTP should send DTLSReset to the state machine.  Should
> this be DTLSShutdown?
>
>  -Bob
>
> Bob O'Hara
> Cisco Systems - WNBU
>
> Phone:  +1 408 853 5513
> Mobile: +1 408 218 4025
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_37371_8135035.1159986558166-- --===============1875717914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1875717914==-- From lybae@challengediscovery.com Thu Oct 05 08:45:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVSbp-0003Bc-BN for capwap-archive@ietf.org; Thu, 05 Oct 2006 08:45:53 -0400 Received: from 87-196-90-212.net.novis.pt ([87.196.90.212] helo=challengediscovery.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVOd8-0004P4-KM for capwap-archive@ietf.org; Thu, 05 Oct 2006 04:31:00 -0400 Message-ID: <01c6e858$93b86860$9901a8c0@acer> Date: Thu, 5 Oct 2006 09:30:55 +0000 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Ruwa Krull" From: "Ruwa Krull" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14451_01C6E860.F583FC50" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.9 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. ------=_NextPart_000_14451_01C6E860.F583FC50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, VALhlUM ClAhLIS VlAhGRA AMBhlEN Save 60 % with http://www.linkunhertiondefunhades.com =20 _____ =20 there when I came out. Shaking his joined hands over his head when I I turned to thank my temporal saviors, but they were already gone. Well, Jim, I said to my smiling and sleek image in the mirror, as I ------=_NextPart_000_14451_01C6E860.F583FC50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VALhlUM

ClAhLIS

VlAhGRA

AMBhlEN

 

there when I came out. Shaking his joined hands over his head when = I
I turned to thank my temporal saviors, but they were already = gone.
Well, Jim, I said to my smiling and sleek image in the mirror, as = I

------=_NextPart_000_14451_01C6E860.F583FC50-- From ctggpzoi@transcor-usa.com Thu Oct 05 11:41:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVM4-00063E-MN for capwap-archive@ietf.org; Thu, 05 Oct 2006 11:41:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVM4-00045A-Kq for capwap-archive@ietf.org; Thu, 05 Oct 2006 11:41:48 -0400 Received: from [81.172.90.130] (helo=[81.172.90.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GVVM1-0004m8-7N for capwap-archive@ietf.org; Thu, 05 Oct 2006 11:41:46 -0400 Message-ID: <001d01c6e894$be18ad90$825aac51@mirandal4hvdqp> From: "Rights" To: capwap-archive@ietf.org Subject: package date Date: Thu, 5 Oct 2006 17:41:36 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C6E8A5.81A17D90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ------=_NextPart_000_0019_01C6E8A5.81A17D90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Alert for all investors! Important news released by Search Advanced and colorkey on this page Recently In zip View older ------=_NextPart_000_0019_01C6E8A5.81A17D90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Alert for all investors!
 
released by
Search Advanced
and=20 colorkey
on this page Recently
In
.zip View=20 older
------=_NextPart_000_0019_01C6E8A5.81A17D90-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 11:58:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVcQ-0004CA-Io for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 11:58:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVcO-0006NZ-Mb for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 11:58:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4A8D9398011 for ; Thu, 5 Oct 2006 08:58:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 3DA994300F2 for ; Thu, 5 Oct 2006 08:57:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 21729144803A for ; Thu, 5 Oct 2006 08:57:55 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 97A25144804B for ; Thu, 5 Oct 2006 08:57:51 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so863597nfb for ; Thu, 05 Oct 2006 08:57:50 -0700 (PDT) Received: by 10.49.29.3 with SMTP id g3mr4076817nfj; Thu, 05 Oct 2006 08:57:49 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 5 Oct 2006 08:57:49 -0700 (PDT) Message-ID: <5bfe7a820610050857l51e9b915ra3283f95a17002ec@mail.gmail.com> Date: Thu, 5 Oct 2006 08:57:49 -0700 From: "Dorothy Stanley" To: "Behcet Sarikaya" In-Reply-To: <20061004152010.99513.qmail@web60320.mail.yahoo.com> MIME-Version: 1.0 References: <20061004152010.99513.qmail@web60320.mail.yahoo.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_50_60, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641802699==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb --===============1641802699== Content-Type: multipart/alternative; boundary="----=_Part_11157_31406632.1160063869870" ------=_Part_11157_31406632.1160063869870 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Behcet, Comment inline below. Dorothy On 10/4/06, Behcet Sarikaya wrote: > > Hi Dorothy, > > ----- Original Message ---- > From: Dorothy Stanley < dstanley1389@gmail.com> > To: Bob O'Hara (boohara) > Cc: Saravanan Govindan < Saravanan.Govindan@sg.panasonic.com>; Cheng Hong > < Hong.Cheng@sg.panasonic.com>; capwap@frascone.com > Sent: Tuesday, October 3, 2006 5:09:55 PM > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Bob, all, > > Comments inline. > > Thanks, > > Dorothy > > On 9/29/06, Bob O'Hara (boohara) < boohara@cisco.com> wrote: > > > > > > Again, your proposal does not eliminate any attack mechanism and does > > not add any functionality to the protocol, only cost and complexity. A > > replayed frame will be discarded by the MAC, using the normal duplicate > > frame detection mechanisms. See section 8.3.3.3.2 of 802.11i (where th= e > > frame sequence number is part of the additional authenticated data) and > > section 9.2.9 of 802.11-1999 for the description of these functions. > > And PLEASE read 802.11 and 802.11i before again asserting that this > > proposal is necessary. > > > > In Section 8.3.3.3.2, the AAD construction for CCMP includes the frame > sequence control field =96 and the sequence number, > bits 4-15 of the frame equence control field - is masked to 0 in the AAD; > so that only the fragment number is protected. > > The TKIP MIC protects neither the fragment number nor the sequence number > of the 802.11 frame sequence control field, as the TKIP MIC > is MSDU based. > > In 9.2.9, Duplicate detection and recovery, the text indicates that a STA > may omit > broadcast/multicast frame data from its duplicate detection cache; if > bc/mc data is not included, then normal > duplicate frame detection will not apply. > > As I said several emails ago, the ONLY effect of using zero as the value > for the KeyRSC is that the 802.11 chipset in the STA (client) will have t= o > receive the frame, attempt to decrypt it, and validate the MIC. This mus= t > be done for EVERY frame received, whether it is a replayed frame or not. > This set of functions is performed in the 802.11 STA chipset and does not > consume any additional resources of the STA. So, the attack, if it can e= ven > be characterized as an attack, is no more effective at DOSing the STA tha= n > sending it any other frame. > > The MIC calculation, and encrpt/decrypt is typically performed in hardwar= e > in the chipset for CCMP. > However, the TKIP MIC calculation is typically performed in the driver, i= n > software. > > If a STA does not have the proper RSC value, there is a "window of > vulnerability" before it receives > the correct value, during > which the STA can receive and process replayed bc/mc frames. The > magnitude of the DOS aspect of this > depends on the STA crypto implementation - hw/ccmp - virtually no impact > or sw/tkip-some small impact. > The larger issue is that the replay protection mechanism guarrantees > provided by 802.11i are lost. > > --snip > > =3D=3D> > > Are you favoring a solution Charles sketched, i.e. WTP sends keyRSC value > during authentication/reassociation of each new STA so that AC can use th= e > correct (or close to correct) value in Message 3 of 4-way handshake and > Message 1 of group key handshake? > > Can you clarify this? > It seems that there are three categories of solutions being discussed: (a) Those that remove the possibility of replayed frames - ideal, but alternatives on the table are viewed as too complex and introduce time constraints. (b) Those that reduce the number of previously sent bc/mc frames that can b= e replayed - less than ideal, but less complex. (c) Those that allow any previously sent bc/mc frame with a given GTK to be replayed. If asked to select between (b) and (c), I would favor a (b) category solution over a (c) category solution. Thanks > > Behcet > ------=_Part_11157_31406632.1160063869870 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Behcet,

Comment inline below.

Dorothy

On 10/4/06, Behcet Sarikaya < behcetsarikaya@yahoo.com> wrote:
Hi Dorothy,

----- Original Message ----
From: Dorothy Stanley < dstanley1389@gmail.com>
To: Bob O'Hara (boohara) <boohara@cisco.com>
Cc: Saravanan Govinda= n < Saravanan.Govindan@s= g.panasonic.com>; Cheng Hong < Hong.Cheng@sg.panasonic.com>; capwap@frascone.com
Sent: Tuesday, October 3, 2006 5:09:55 PM
Su= bject: Re: [Capwap] Issue 43 - Explanation for=20 802.11i Considerations

Bob, all,

Comments inline.
<= br>Thanks,

Dorothy

On 9/29/06, Bob O'Hara (boohara) < boohara@cisco.com> wrote:
 
Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity.  A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms.  See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions.  And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary.

In Section 8.3.3.3.2, the AAD construction for CCMP  includes the f= rame sequence control field =96 and the sequence number,
bits 4-15 of t= he frame equence control field - is masked to 0 in the AAD; so that only th= e fragment number is protected.

The TKIP MIC protects neither the fragment number nor the sequence number of  the 802.11 frame sequence control field, as the TKIP MIC
is MSD= U based.

In 9.2.9, Duplicate detection and recovery, the text indicates that a ST= A may omit
broadcast/multicast frame data from its duplicate detection = cache; if bc/mc data is not included, then normal
duplicate frame detection will not apply.

 As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC.  This must be done for EVERY frame received, whether it is a replayed frame or not.  This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA.  So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame.

The MIC calculation, and encrpt/decrypt is typically performed in hardwa= re in the chipset for CCMP.
However, the TKIP MIC calculation is typical= ly performed in the driver, in software.

If a STA does not have the proper RSC value, there is a "window of = vulnerability" before it receives
the correct value, during
whic= h the STA can receive and process replayed  bc/mc frames. The magnitud= e of the DOS aspect of this
depends on the STA crypto implementation - hw/ccmp - virtually no impac= t or sw/tkip-some small impact.
The larger issue is that the replay prot= ection mechanism guarrantees provided by 802.11i are lost.

--snip

=3D=3D>

Are you favoring a solution Charles sketched, i.e. WTP sends keyRSC value during authentication/reassociation of each new STA so that AC can use the correct (or close to correct) value in Message 3 of 4-way handshake and Message 1 of group key handshake?

Can you clarify this?

It seems that there are three categories of solutions = being discussed:
(a) Those that remove the possibility of replayed frames - ideal, but alternatives on the table are viewed as too complex and introduce time constraints.
(b) Those that reduce the number of previously sent bc/mc frames that can b= e replayed - less than ideal, but less complex.
(c) Those that allow any previously sent bc/mc frame with a given GTK to be= replayed.

If asked to select between (b) and (c), I would favor a (b) category soluti= on over a (c) category solution.

Thanks

Behcet


------=_Part_11157_31406632.1160063869870-- --===============1641802699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1641802699==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 12:50:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWQq-0002WT-Ms for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 12:50:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWJY-0005PK-5q for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 12:43:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A5A8E3980AA for ; Thu, 5 Oct 2006 09:43:15 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A28224300F2 for ; Thu, 5 Oct 2006 09:41:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8640D398079 for ; Thu, 5 Oct 2006 09:41:32 -0700 (PDT) X-Greylist-Status: Sender first seen 14 days 07:54:22 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 325C1398081 for ; Thu, 5 Oct 2006 09:41:27 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1352748; Thu, 05 Oct 2006 12:41:25 -0400 In-Reply-To: <5bfe7a820610050934k245312ebrdf168d059d938084@mail.gmail.com> References: <5bfe7a820610050934k245312ebrdf168d059d938084@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <82E78D5D-C43D-4FFF-91A1-708918E5DBAB@thingmagic.com> From: Margaret Wasserman Date: Thu, 5 Oct 2006 12:39:31 -0400 To: Dorothy Stanley X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Hi All, This request is based on the assumption that the WTP's power level will actually be set in dBm. If that is true, why not use dBm (or centi-dBm) as the unit for this attribute, instead of mW (or 0.1 mW)? Margaret On Oct 5, 2006, at 12:34 PM, Dorothy Stanley wrote: > All, > > The proposed resolution to the 11.9.18 comment is: Accept the > commenters suggestion, change > > > From "Current Tx Power: This attribute contains the transmit > output power in mW." > to "Current Tx Power: This attribute contains the transmit > output power in 0.1mW." > > > Comments welcome, > > Thanks, > > Dorothy > > On 9/25/06, zhaoyujin 31390 wrote: Section > 11.9.18 has following discripiton, I suggestion some change > > From "Current Tx Power: This attribute contains the transmit > output power in mW." > to "Current Tx Power: This attribute contains the transmit > output power in 0.1mW." > > The reason is: normally WLAN will use dbm. The conversion between > dbm and mw can not satisfy this TLV requirement. If capwap > transimit one mw value, the device can't precise get corresponding > dbm. > > For example > 1 dbm<----->1.3mw ----> 1mw > 2 dbm<----->1.6mw ----> 2mw > 3 dbm<----->2.0mw ----> 2mw > > This time, if capwap transmits 2 mw, system doesn't know it is > 2dbm or 3 dbm. > > The following is suggestion: > For example > 1 dbm<----->1.3mw ----> 13mw > 2 dbm<-----> 1.6mw ----> 16mw > 3 dbm<----->2.0mw ----> 20mw > > Thanks > Michael > > > The Tx power message element value is bi-directional. When > sent by > > the WTP, it contains the current power level of the radio in > > question. When sent by the AC, it contains the power level the > WTP > > MUST adhere to. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > | Radio ID | Reserved | Current Tx > Power | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > > > Type: 1041 for IEEE 802.11 Tx Power > > > > Length: 4 > > > > Radio ID: An 8-bit value representing the radio to configure. > > > > Reserved: MUST be set to zero > > > > Current Tx Power: This attribute contains the transmit output > power > > in mW. > > This e-mail and attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose > address is listed above. Any use of the information contained > herein in any way (including, but not limited to, total or partial > disclosure, reproduction, or dissemination) by persons other than > the intended recipient's) is prohibited. If you receive this e-mail > in error, please notify the sender by phone or email > immediately and delete it! > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 12:53:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWR2-0002fu-UM for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 12:51:00 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWD7-0004dh-HM for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 12:36:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB6ED398070 for ; Thu, 5 Oct 2006 09:36:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1BB034300F2 for ; Thu, 5 Oct 2006 09:34:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E8296144804B for ; Thu, 5 Oct 2006 09:34:23 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by hermes.tigertech.net (Postfix) with ESMTP id 15095144803C for ; Thu, 5 Oct 2006 09:34:20 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so872625nfb for ; Thu, 05 Oct 2006 09:34:19 -0700 (PDT) Received: by 10.48.210.16 with SMTP id i16mr4073161nfg; Thu, 05 Oct 2006 09:34:19 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 5 Oct 2006 09:34:18 -0700 (PDT) Message-ID: <5bfe7a820610050934k245312ebrdf168d059d938084@mail.gmail.com> Date: Thu, 5 Oct 2006 09:34:18 -0700 From: "Dorothy Stanley" To: "zhaoyujin 31390" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0450677499==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 --===============0450677499== Content-Type: multipart/alternative; boundary="----=_Part_12023_161462.1160066058919" ------=_Part_12023_161462.1160066058919 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, The proposed resolution to the 11.9.18 comment is: Accept the commenters suggestion, change From "Current Tx Power: This attribute contains the transmit output power in mW." to "Current Tx Power: This attribute contains the transmit output power in 0.1mW." Comments welcome, Thanks, Dorothy On 9/25/06, zhaoyujin 31390 wrote: > > Section 11.9.18 has following discripiton, I suggestion some change > > From "Current Tx Power: This attribute contains the transmit output > power in mW." > to "Current Tx Power: This attribute contains the transmit output > power in 0.1mW." > > The reason is: normally WLAN will use dbm. The conversion between dbm and > mw can not satisfy this TLV requirement. If capwap transimit one mw value, > the device can't precise get corresponding dbm. > > For example > 1 dbm<----->1.3mw ----> 1mw > 2 dbm<----->1.6mw ----> 2mw > 3 dbm<----->2.0mw ----> 2mw > > This time, if capwap transmits 2 mw, system doesn't know it is 2dbm or 3 > dbm. > > The following is suggestion: > For example > 1 dbm<----->1.3mw ----> 13mw > 2 dbm<----->1.6mw ----> 16mw > 3 dbm<----->2.0mw ----> 20mw > > Thanks > Michael > > > The Tx power message element value is bi-directional. When sent by > > the WTP, it contains the current power level of the radio in > > question. When sent by the AC, it contains the power level the WTP > > MUST adhere to. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | Reserved | Current Tx Power | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Type: 1041 for IEEE 802.11 Tx Power > > > > Length: 4 > > > > Radio ID: An 8-bit value representing the radio to configure. > > > > Reserved: MUST be set to zero > > > > Current Tx Power: This attribute contains the transmit output power > > in mW. > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email > immediately and delete it! > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_12023_161462.1160066058919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

The proposed resolution to the 11.9.18 comment is: Accept the commenters suggestion, change


   From "Current Tx Power:  This attribute contains the transmit output power in mW."
   to   "Current Tx Power:  This attribute contains the transmit output power in 0.1mW."


Comments welcome,

Thanks,

Dorothy

On 9/25/06, zhaoyujin 31390 <zhaoyujin@huawei.com> wrote:
Section 11.9.18 has following discripiton, I suggestion some change

   From "Current Tx Power:  This attribute contains the transmit output power in mW."
   to   "Current Tx Power:  This attribute contains the transmit output power in 0.1mW."

The reason is: normally WLAN will use dbm. The conversion between dbm and mw can not satisfy this TLV requirement. If capwap transimit one mw value, the device can't precise get corresponding dbm.

  For example
         1 dbm<----->1.3mw  ----> 1mw
         2 dbm<----->1.6mw  ----> 2mw
         3 dbm<----->2.0mw  ----> 2mw

  This time, if capwap transmits 2 mw, system doesn't know it is 2dbm or 3 dbm.

The following is suggestion:
  For example
         1 dbm<----->1.3mw  ----> 13mw
         2 dbm<-----> 1.6mw  ----> 16mw
         3 dbm<----->2.0mw  ----> 20mw

Thanks
Michael

>   The Tx power message element value is bi-directional.  When sent by
>   the WTP, it contains the current power level of the radio in
>   question.  When sent by the AC, it contains the power level the WTP
>   MUST adhere to.
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Radio ID   |    Reserved   |        Current Tx Power       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   Type:  1041 for IEEE 802.11 Tx Power
>
>   Length:  4
>
>   Radio ID:  An 8-bit value representing the radio to configure.
>
>   Reserved:  MUST be set to zero
>
>   Current Tx Power:  This attribute contains the transmit output power
>      in mW.

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email
immediately and delete it!

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_12023_161462.1160066058919-- --===============0450677499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0450677499==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 16:17:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZet-0003xA-Pi for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 16:17:31 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZer-0006Vs-1Q for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 16:17:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B7DCA144804E for ; Thu, 5 Oct 2006 13:17:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 485E14300F2 for ; Thu, 5 Oct 2006 13:15:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 356A9398062 for ; Thu, 5 Oct 2006 13:15:45 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1466D39806B for ; Thu, 5 Oct 2006 13:15:41 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GVZd7-0003Dy-3S for capwap@frascone.com; Thu, 05 Oct 2006 16:15:41 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 5 Oct 2006 16:15:40 -0400 Message-ID: <25818848.1160079340870.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Thu, 5 Oct 2006 16:15:40 -0400 (EDT) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710c4ca365323226bd2cc836ee5c29fafa9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Following up once again - after careful review, I still agree with Charles, and here's some suggested text for the security considerations: 13.5. IEEE 802.11 Security When used with an IEEE 802.11 infrastructure with WEP encryption, the CAPWAP protocol does not add any new vulnerabilities. Derived session keys between the STA and WTP can be compromised, resulting in many well-documented attacks. Implementors SHOULD discourage the use of WEP and encourage use of technically sound cryptographic solutions such as those in an IEEE 802.11 RSN. When used with IEEE 802.11 RSN security, the CAPWAP protocol may introduce new vulnerabilities, depending on whether the link security (packet encryption and integrity verification) is provided by the WTP or the AC. When the link security function is provided by the AC, no new security concerns are introduced. However, when the WTP provides link security, a new vulnerability will exist when the following conditions are true: o the client is not the first to associate to the WTP/ESSID (i.e. other clients are associated), and a GTK already exists o traffic has been broadcast under the existing GTK Under these circumstances, the receive sequence counter (KeyRSC) associated with the GTK is non-zero, but because the AC anchors the 4-way handshake with the client, the exact value of the KeyRSC is not known when the AC constructs the message containing the GTK. The client will update its Key RSC value to the current valid KeyRSC upon receipt of a valid multicast/broadcast message, but prior to this, previous multicast/broadcast traffic which was secured with the existing GTK may be replayed, and the client will accept this traffic as valid. Typically, busy networks will produce numerous multicast or broadcast frames per second, so the window of opportunity with respect to such replay is expected to be very small. In most conditions, it is expected that replayed frames could be detected (and logged) by the WTP. The only way to completely close this window is to provide the exact KeyRSC value in message 3 of the 4-way handshake; any other approach simply narrows the window to varying degrees. Given the low relative threat level this presents, the additional complexity introduced by providing the exact KeyRSC value is not warranted. That is, this specification provides for a calculated risk in this regard. Margaret Wasserman wrote: > Hi Charles, > > > >> If the consensus is to use RSC=0, then I think a disclaimer statement >> should be added to the security considerations section about the >> replay >> possibility in multicast protocols. Overall this is probably >> sufficient. > > This does seem like the simplest approach. So, if there is no > objection from our security advisors > (you and Scott Kelly), then I'm for it. > > > > Margaret > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ______ _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 16:57:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVaHb-0007E0-7Q for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 16:57:31 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVaHV-0004LE-GM for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 16:57:31 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id CAB6C398058 for ; Thu, 5 Oct 2006 13:57:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 54FD14300F2 for ; Thu, 5 Oct 2006 13:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 38E9A398055 for ; Thu, 5 Oct 2006 13:56:39 -0700 (PDT) Received: from web60325.mail.yahoo.com (web60325.mail.yahoo.com [209.73.178.133]) by zoidberg.tigertech.net (Postfix) with SMTP id E76BA398042 for ; Thu, 5 Oct 2006 13:56:35 -0700 (PDT) Received: (qmail 7733 invoked by uid 60001); 5 Oct 2006 20:56:29 -0000 Message-ID: <20061005205629.7731.qmail@web60325.mail.yahoo.com> Received: from [12.129.211.52] by web60325.mail.yahoo.com via HTTP; Thu, 05 Oct 2006 13:56:29 PDT Date: Thu, 5 Oct 2006 13:56:29 -0700 (PDT) From: Behcet Sarikaya To: "Scott G. Kelly" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.747 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: ** Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1438990598==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 --===============1438990598== Content-Type: multipart/alternative; boundary="0-1641367754-1160081789=:4947" --0-1641367754-1160081789=:4947 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable I agree with this and suggest adding Peter's fix as a possibility. As far a= s interoperability is concerned, value 0 is interoperable but not correct. = If we allow implementations to snif in and modify then any value should be = acceptable which may be a concern for interoperability?=0A=0A=0A----- Origi= nal Message ----=0AFrom: Scott G. Kelly =0ATo: capwa= p =0ASent: Thursday, October 5, 2006 3:15:40 PM=0ASubj= ect: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations=0A=0A= =0AFollowing up once again - after careful review, I still agree with Charl= es, and here's some suggested text for the security considerations:=0A=0A13= .5. IEEE 802.11 Security=0A=0A When used with an IEEE 802.11 infrastruc= ture with WEP encryption, the=0A CAPWAP protocol does not add any new vul= nerabilities. Derived=0A session keys between the STA and WTP can be com= promised, resulting in=0A many well-documented attacks. Implementors SHO= ULD discourage the use=0A of WEP and encourage use of technically sound c= ryptographic solutions=0A such as those in an IEEE 802.11 RSN.=0A=0A Wh= en used with IEEE 802.11 RSN security, the CAPWAP protocol=0A may introdu= ce new vulnerabilities, depending on whether the link security=0A (packet = encryption and integrity verification) is provided by the WTP or the AC. = =0A When the link security function is provided by the AC, no new securit= y =0A concerns are introduced. =0A=0A However, when the WTP provides li= nk security, a new vulnerability will=0A exist when the following conditi= ons are true:=0A=0A o the client is not the first to associate to the WT= P/ESSID=0A (i.e. other clients are associated), and a GTK already ex= ists=0A=0A o traffic has been broadcast under the existing GTK=0A=0A= Under these circumstances, the receive sequence counter (KeyRSC) =0A a= ssociated with the GTK is non-zero, but because the AC anchors the=0A 4-w= ay handshake with the client, the exact value of the KeyRSC is not=0A kno= wn when the AC constructs the message containing the GTK.=0A The client w= ill update its Key RSC value to the current valid KeyRSC=0A upon receipt = of a valid multicast/broadcast message, but prior to this, =0A previous m= ulticast/broadcast traffic which was secured with the existing =0A GTK ma= y be replayed, and the client will accept this traffic as valid.=0A=0A Ty= pically, busy networks will produce numerous multicast or broadcast=0A fr= ames per second, so the window of opportunity with respect to such=0A rep= lay is expected to be very small. In most conditions, it is expected that = =0A replayed frames could be detected (and logged) by the WTP. =0A=0A T= he only way to completely close this window is to provide the =0A exact K= eyRSC value in message 3 of the 4-way handshake; any=0A other approach si= mply narrows the window to varying degrees. Given=0A the low relative thr= eat level this presents, the additional complexity=0A introduced by provi= ding the exact KeyRSC value is not warranted. That =0A is, this specifica= tion provides for a calculated risk in this regard.=0A=3D=3D>=0AHowever, WT= P implementations MAY provide the exact KeyRSC value before forwarding mess= age 3 of the 4-way handshake.=0A=0A--behcet --0-1641367754-1160081789=:4947 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
I agree with this and suggest adding Peter's fix as= a possibility. As far as interoperability is concerned, value 0 is interop= erable but not correct. If we allow implementations to snif in and modify t= hen any value should be acceptable which may be a concern for interoperabil= ity?

=0A
----- Original Message ----
From: Scott G. Kell= y <s.kelly@ix.netcom.com>
To: capwap <capwap@frascone.com>Sent: Thursday, October 5, 2006 3:15:40 PM
Subject: Re: [Capwap] Issue= 43 - Explanation for 802.11i Considerations

=0A
Following up on= ce again - after careful review, I still agree with Charles, and here's som= e suggested text for the security considerations:

13.5.  I= EEE 802.11 Security

    When used with an IEEE 8= 02.11 infrastructure with WEP encryption, the
   CAPWAP protoc= ol does not add any new vulnerabilities.  Derived
  = session keys between the STA and WTP can be compromised, resulting in
&= nbsp;  many well-documented attacks.  Implementors SHOULD di= scourage the use
   of WEP and encourage use of technically so= und cryptographic solutions
   such as those in an IEEE 802.11= RSN.

   When used with IEEE 802.11 RSN security, the CAPW= AP protocol
   may introduce new vulnerabilities, depending on= whether the link security
  (packet encryption and integrity = verification) is provided by the WTP or the AC.
   When the link security function is provided by the AC, no new security    concerns are introduced.

   However, when t= he WTP provides link security, a new vulnerability will
   exi= st when the following conditions are true:

    o= the client is not the first to associate to the WTP/ESSID
  &= nbsp;     (i.e. other clients are associated), and= a GTK already exists

       &nbs= p;o traffic has been broadcast under the existing GTK

   U= nder these circumstances, the receive sequence counter (KeyRSC)
 &= nbsp; associated with the GTK is non-zero, but because the AC anchors the   4-way handshake with the client, the exact value of the KeyR= SC is not
   known when the AC constructs the message containi= ng the GTK.
   The client will update its Key RSC value to the= current valid KeyRSC
   upon receipt of a valid multicast/broadcast m= essage, but prior to this,
   previous multicast/broadcast tr= affic which was secured with the existing
   GTK may be repla= yed, and the client will accept this traffic as valid.

   = Typically, busy networks will produce numerous multicast or broadcast
&n= bsp;  frames per second, so the window of opportunity with respect to = such
   replay is expected to be very small. In most condition= s, it is expected that
   replayed frames could be detected (= and logged) by the WTP.

   The only way to completely clo= se this window is to provide the
   exact KeyRSC value in mes= sage 3 of the 4-way handshake; any
   other approach simply na= rrows the window to varying degrees. Given
   the low relative= threat level this presents, the additional complexity
   intr= oduced by providing the exact KeyRSC value is not warranted. That
   i= s, this specification provides for a calculated risk in this regard.
=3D= =3D>
=0A
However, WTP implementations MAY provide the exac= t KeyRSC value before forwarding message 3 of the 4-way handshake.

-= -behcet
--0-1641367754-1160081789=:4947-- --===============1438990598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1438990598==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 17:27:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVakx-0006Vr-OP for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:27:51 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVakv-0008R0-3N for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:27:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id EE663398026 for ; Thu, 5 Oct 2006 14:27:45 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 731764300F2 for ; Thu, 5 Oct 2006 14:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 48D761448037 for ; Thu, 5 Oct 2006 14:26:40 -0700 (PDT) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by hermes.tigertech.net (Postfix) with SMTP id 290131448047 for ; Thu, 5 Oct 2006 14:26:36 -0700 (PDT) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:26:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Oct 2006 14:26:35 -0700 Message-ID: <99C8B9B2AD99664A87E12C839A2E9093F1652B@aruba-mx1.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 2-Port/Mux Issue Discussion Thread-Index: AcbjNAAMI0YnQmC2Rh2tP80FZz6XJgFjS6Dw References: <26298393.1159465449346.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <92EA30D4-8C07-4FC3-A2CB-4EED0CEDEEBB@thingmagic.com> From: "Partha Narasimhan" To: "Margaret Wasserman" , "Scott G. Kelly" X-OriginalArrivalTime: 05 Oct 2006 21:26:35.0479 (UTC) FILETIME=[EF6D4E70:01C6E8C4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=-0.0 tagged_above=-999.0 required=7.0 tests=SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 My two cents below, FWIW. - Assuming that most currently deployed L2 switches can be upgraded to support CAPWAP merely with a software upgrade is well beyond the limits of what I would normally assume in a typical day in my life. - In all of the debate, I haven't seen the proponents of the two-port solution acknowledge significant additional complexity this solution imposes on the entire protocol. Overall, it increases the cost/complexity of implementation and/or trouble-shooting over the single-port mux solution. - The single-port mux solution can be made to work on existing gear, except it may or may not be as efficient as an implementation on some other gear that is more recent or being designed now. The current protocol design work should not be influenced by the inefficiencies of implementing it in gear that was designed well before the need for CAPWAP crept into people's minds. - Choosing a more complicated solution over a simpler one would also lead to the protocol not getting deployed because of the cost of implementing it. I am especially concerned whether the WTP vendors can bear the increased cost of implementation and interoperability testing and whether this will influence their decisions to drop support for CAPWAP in their gear. This is the other side of the coin to the argument that designing the protocol, albeit with a more complex solution, to fit older implementations would increase the chance of it being widely deployed. Thanks partha PS: While debating this issue, we went through what we now know were detours along non-existent routing and QoS issues. Makes one wonder what is really behind every long and drawn-out discussion in this WG. -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, September 28, 2006 12:24 PM To: Scott G. Kelly Cc: capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion Hi Scott, I'd just like to state, for clarity, that the message you are responding to came from all three of the CAPWAP chairs. Although I drafted and sent the message, it did reflect input from Mani and Dorothy. This response is just from me, and the opinions expressed are mine. The other chairs may not agree. On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote: >> - Single-Processor: In this architecture, the control plane and the >> data plane run on a single processor. The demultiplexing of control >> and data packets happens on that processor. >> >> - Separate Data & Control Planes: In this architecture, the >> data and >> control planes run on separate processors (and possibly on separate >> cards), typically connected via a switching fabric. This is >> a common >> hardware architecture for higher-end routing and switching hardware, >> and it relies on a port-based splitting/load-balancing approach to >> separate the control and data traffic. For CAPWAP to work >> efficiently on these systems, it must be possible to distinguish the >> control and data traffic in the switching hardware, which is >> typically done based on the five-tuple of the send & recv IP >> addresses, the protocol (UDP), and the send & recv port >> numbers. The >> switching hardware cannot do the type of deep packet inspection >> required to demultiplex on CAPWAP header fields. > > This is one of the mischaracterizations I see. The issues have > nothing to do with how many processors there are - they have to do > with separation of control and data planes, and with the switching > facility used to distribute packets between these two planes. This > is a critical distinction. I agree with you comment, and your private note on this subject was very helpful to advance my thinking on this matter. However, I do not think that your correction fundamentally changes the situation. It would have been better if we had characterized these systems based on how received packets are handled, rather than based on the number of processors in the system, but that doesn't change the fact that there are two type of systems: (1) Those where the packet is initially received by a component (such as a NPU or a CPU) that can distinguish between control and data traffic by looking at the CAPWAP headers. There may be additional processors on this type of systems, so using the phrase "single- processor" to describe these systems was not correct. AND (2) Those where the packet is initially received by switching hardware that can only efficiently distinguish between control and data traffic using a five-tuple that includes the UDP ports. There are both high- and low-performance systems that correspond to each architecture. > Based on the clarification above, it should be clear that this is > also a mischaracterization. Either approach will work in either of > the architectures, and in particular, in either of the > architectures _as they are deployed today_. The real problem > appears to be that one vendor has made a conscious choice to limit > the control/data switching facility to 5-tuple-based solutions. I am personally aware of switching equipment from more than one vendor that is restricted to using a five-tuple for switching incoming traffic. I am not currently aware of whether these systems are sold as WLAN switches, but I believe that many of them could be software upgraded to serve in that role. Given the widespread deployment of switches that employ this architecture, I believe that it is desirable to make sure that CAPWAP can be added, as a software upgrade, to systems of this type. I could express some opinions about which architecture is better, but my opinion on that subject is immaterial. Both systems are widely deployed, and I think that we are likely to see wider deployment of CAPWAP if it can work well on both architectures. >> This complexity is a consequence of the choice to tunnel all WLAN >> data traffic to the AC. In split-MAC local-forwarding mode, >> only the >> control plane traffic would be sent to the AC, and data plane >> forwarding would be handled by the WTPs themselves. > > This also seems mischaracterized, because in all currently defined > split-MAC modes, a data channel must be established in order to > handle 802.11 management and authentication frames (even when > you're doing local bridging of the data). Perhaps Mani could respond to this point, as he was the originator of this text. > In any event, Margaret is right: the working group needs to speak > up so we can close this and move on. I'm done arguing about this, > and life will go on one way or another regardless of what we > choose. But at least, we should all be clear on what's happened > here, and go into this eyes wide open. Thanks for your comments, and for your continuing efforts to keep this work moving forward. Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 17:47:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb48-0002ls-CA for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:47:40 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVb46-0004qo-HW for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:47:40 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5373C39802D for ; Thu, 5 Oct 2006 14:47:37 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1BEB64300F2 for ; Thu, 5 Oct 2006 14:44:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id F3CE61448022 for ; Thu, 5 Oct 2006 14:44:20 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id E13AF1448009 for ; Thu, 5 Oct 2006 14:44:18 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so948241nfb for ; Thu, 05 Oct 2006 14:44:17 -0700 (PDT) Received: by 10.49.94.20 with SMTP id w20mr4535940nfl; Thu, 05 Oct 2006 14:44:17 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 5 Oct 2006 14:44:16 -0700 (PDT) Message-ID: <5bfe7a820610051444k6e26ca39q417afa6f7cb86f51@mail.gmail.com> Date: Thu, 5 Oct 2006 14:44:16 -0700 From: "Dorothy Stanley" To: "Margaret Wasserman" In-Reply-To: <82E78D5D-C43D-4FFF-91A1-708918E5DBAB@thingmagic.com> MIME-Version: 1.0 References: <5bfe7a820610050934k245312ebrdf168d059d938084@mail.gmail.com> <82E78D5D-C43D-4FFF-91A1-708918E5DBAB@thingmagic.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0686509956==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 --===============0686509956== Content-Type: multipart/alternative; boundary="----=_Part_17889_33048123.1160084656897" ------=_Part_17889_33048123.1160084656897 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Margaret, dBm units could also be used. This message element, and the TX Power Level use mW, the TX Power Level to correspond with the 802.11 MIB definitions, which use mW units. Dorothy On 10/5/06, Margaret Wasserman wrote: > > > Hi All, > > This request is based on the assumption that the WTP's power level > will actually be set in dBm. If that is true, why not use dBm (or > centi-dBm) as the unit for this attribute, instead of mW (or 0.1 mW)? > > Margaret > > On Oct 5, 2006, at 12:34 PM, Dorothy Stanley wrote: > > > All, > > > > The proposed resolution to the 11.9.18 comment is: Accept the > > commenters suggestion, change > > > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > > > Comments welcome, > > > > Thanks, > > > > Dorothy > > > > On 9/25/06, zhaoyujin 31390 wrote: Section > > 11.9.18 has following discripiton, I suggestion some change > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > The reason is: normally WLAN will use dbm. The conversion between > > dbm and mw can not satisfy this TLV requirement. If capwap > > transimit one mw value, the device can't precise get corresponding > > dbm. > > > > For example > > 1 dbm<----->1.3mw ----> 1mw > > 2 dbm<----->1.6mw ----> 2mw > > 3 dbm<----->2.0mw ----> 2mw > > > > This time, if capwap transmits 2 mw, system doesn't know it is > > 2dbm or 3 dbm. > > > > The following is suggestion: > > For example > > 1 dbm<----->1.3mw ----> 13mw > > 2 dbm<-----> 1.6mw ----> 16mw > > 3 dbm<----->2.0mw ----> 20mw > > > > Thanks > > Michael > > > > > The Tx power message element value is bi-directional. When > > sent by > > > the WTP, it contains the current power level of the radio in > > > question. When sent by the AC, it contains the power level the > > WTP > > > MUST adhere to. > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > > 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > | Radio ID | Reserved | Current Tx > > Power | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > > > > Type: 1041 for IEEE 802.11 Tx Power > > > > > > Length: 4 > > > > > > Radio ID: An 8-bit value representing the radio to configure. > > > > > > Reserved: MUST be set to zero > > > > > > Current Tx Power: This attribute contains the transmit output > > power > > > in mW. > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose > > address is listed above. Any use of the information contained > > herein in any way (including, but not limited to, total or partial > > disclosure, reproduction, or dissemination) by persons other than > > the intended recipient's) is prohibited. If you receive this e-mail > > in error, please notify the sender by phone or email > > immediately and delete it! > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_17889_33048123.1160084656897 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Margaret,

dBm units could also be used. This message element, and the TX Power
Level use mW, the TX Power Level to correspond with the 802.11 MIB definitions, which use mW units.

Dorothy

On 10/5/06, Margaret Wasserman <margaret@thingmagic.com> wrote:

Hi All,

This request is based on the assumption that the WTP's power level
will actually be set in dBm.  If that is true, why not use dBm (or
centi-dBm) as the unit for this attribute, instead of mW (or 0.1 mW)?

Margaret

On Oct 5, 2006, at 12:34 PM, Dorothy Stanley wrote:

> All,
>
> The proposed resolution to the 11.9.18 comment is: Accept the
> commenters suggestion, change
>
>
>    From "Current Tx Power:  This attribute contains the transmit
> output power in mW."
>    to   "Current Tx Power:  This attribute contains the transmit
> output power in 0.1mW."
>
>
> Comments welcome,
>
> Thanks,
>
> Dorothy
>
> On 9/25/06, zhaoyujin 31390 <zhaoyujin@huawei.com> wrote: Section
> 11.9.18 has following discripiton, I suggestion some change
>
>    From "Current Tx Power:  This attribute contains the transmit
> output power in mW."
>    to   "Current Tx Power:  This attribute contains the transmit
> output power in 0.1mW."
>
> The reason is: normally WLAN will use dbm. The conversion between
> dbm and mw can not satisfy this TLV requirement. If capwap
> transimit one mw value, the device can't precise get corresponding
> dbm.
>
>   For example
>          1 dbm<----->1.3mw  ----> 1mw
>          2 dbm<----->1.6mw  ----> 2mw
>          3 dbm<----->2.0mw  ----> 2mw
>
>   This time, if capwap transmits 2 mw, system doesn't know it is
> 2dbm or 3 dbm.
>
> The following is suggestion:
>   For example
>          1 dbm<----->1.3mw  ----> 13mw
>          2 dbm<-----> 1.6mw  ----> 16mw
>          3 dbm<-----> 2.0mw  ----> 20mw
>
> Thanks
> Michael
>
> >   The Tx power message element value is bi-directional.  When
> sent by
> >   the WTP, it contains the current power level of the radio in
> >   question.  When sent by the AC, it contains the power level the
> WTP
> >   MUST adhere to.
> >
> >        0                   1                   2                   3
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
> 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+
> >       |    Radio ID   |    Reserved   |        Current Tx
> Power       |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+
> >
> >   Type:  1041 for IEEE 802.11 Tx Power
> >
> >   Length:  4
> >
> >   Radio ID:  An 8-bit value representing the radio to configure.
> >
> >   Reserved:  MUST be set to zero
> >
> >   Current Tx Power:  This attribute contains the transmit output
> power
> >      in mW.
>
> This e-mail and attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose
> address is listed above. Any use of the information contained
> herein in any way (including, but not limited to, total or partial
> disclosure, reproduction, or dissemination) by persons other than
> the intended recipient's) is prohibited. If you receive this e-mail
> in error, please notify the sender by phone or email
> immediately and delete it!
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_17889_33048123.1160084656897-- --===============0686509956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0686509956==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 17:56:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVbCa-0000Lf-6x for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:56:24 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbCY-0006X8-CI for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 17:56:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 8CC0B144803E for ; Thu, 5 Oct 2006 14:56:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 1F0BA4300F2 for ; Thu, 5 Oct 2006 14:54:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 084671448047 for ; Thu, 5 Oct 2006 14:54:02 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by hermes.tigertech.net (Postfix) with ESMTP id 277881448059 for ; Thu, 5 Oct 2006 14:53:59 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so950504nfb for ; Thu, 05 Oct 2006 14:53:58 -0700 (PDT) Received: by 10.49.41.18 with SMTP id t18mr4575954nfj; Thu, 05 Oct 2006 14:53:58 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 5 Oct 2006 14:53:58 -0700 (PDT) Message-ID: <5bfe7a820610051453s6789c214s406f179e27387425@mail.gmail.com> Date: Thu, 5 Oct 2006 14:53:58 -0700 From: "Dorothy Stanley" To: "Behcet Sarikaya" In-Reply-To: <20061005205629.7731.qmail@web60325.mail.yahoo.com> MIME-Version: 1.0 References: <20061005205629.7731.qmail@web60325.mail.yahoo.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_30_40, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811558441==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 --===============0811558441== Content-Type: multipart/alternative; boundary="----=_Part_18045_3407670.1160085238354" ------=_Part_18045_3407670.1160085238354 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Behcet, My understanding of Scott's recommendations is that text be added into the security considerations section. - no additional CAPWAP protocol exchange between the WTP and AC - no specification of setting the keyRSC value to 0. Without some specification in the protocol, how can the WTP provide the KeyRSC info to the AC in a way that the AC is sure to understand? The most we can say with respect to the standard is that an AC implementation is free to comes up with its own algorithm to set the keyRSC value. Dorothy On 10/5/06, Behcet Sarikaya wrote: > > I agree with this and suggest adding Peter's fix as a possibility. As far > as interoperability is concerned, value 0 is interoperable but not correct. > If we allow implementations to snif in and modify then any value should be > acceptable which may be a concern for interoperability? > > ----- Original Message ---- > From: Scott G. Kelly > To: capwap > Sent: Thursday, October 5, 2006 3:15:40 PM > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Following up once again - after careful review, I still agree with > Charles, and here's some suggested text for the security considerations: > > 13.5. IEEE 802.11 Security > > When used with an IEEE 802.11 infrastructure with WEP encryption, the > CAPWAP protocol does not add any new vulnerabilities. Derived > session keys between the STA and WTP can be compromised, resulting in > many well-documented attacks. Implementors SHOULD discourage the use > of WEP and encourage use of technically sound cryptographic solutions > such as those in an IEEE 802.11 RSN. > > When used with IEEE 802.11 RSN security, the CAPWAP protocol > may introduce new vulnerabilities, depending on whether the link > security > (packet encryption and integrity verification) is provided by the WTP or > the AC. > When the link security function is provided by the AC, no new security > concerns are introduced. > > However, when the WTP provides link security, a new vulnerability will > exist when the following conditions are true: > > o the client is not the first to associate to the WTP/ESSID > (i.e. other clients are associated), and a GTK already exists > > o traffic has been broadcast under the existing GTK > > Under these circumstances, the receive sequence counter (KeyRSC) > associated with the GTK is non-zero, but because the AC anchors the > 4-way handshake with the client, the exact value of the KeyRSC is not > known when the AC constructs the message containing the GTK. > The client will update its Key RSC value to the current valid KeyRSC > upon receipt of a valid multicast/broadcast message, but prior to this, > > previous multicast/broadcast traffic which was secured with the > existing > GTK may be replayed, and the client will accept this traffic as valid. > > Typically, busy networks will produce numerous multicast or broadcast > frames per second, so the window of opportunity with respect to such > replay is expected to be very small. In most conditions, it is expected > that > replayed frames could be detected (and logged) by the WTP. > > The only way to completely close this window is to provide the > exact KeyRSC value in message 3 of the 4-way handshake; any > other approach simply narrows the window to varying degrees. Given > the low relative threat level this presents, the additional complexity > introduced by providing the exact KeyRSC value is not warranted. That > is, this specification provides for a calculated risk in this regard. > ==> > However, WTP implementations MAY provide the exact KeyRSC value before > forwarding message 3 of the 4-way handshake. > > --behcet > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_18045_3407670.1160085238354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Behcet,

My understanding of Scott's recommendations is that
 text be added into the security considerations section.
- no additional CAPWAP protocol exchange between the WTP and AC
- no specification of setting the keyRSC value to 0.

Without some specification in the protocol, how can the WTP provide
the KeyRSC info to the AC in a way that the AC is sure to understand? The most we can say
with respect to the standard is that an AC implementation is free to comes up with its own algorithm to
set the keyRSC value. 

Dorothy

On 10/5/06, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
I agree with this and suggest adding Peter's fix as a possibility. As far as interoperability is concerned, value 0 is interoperable but not correct. If we allow implementations to snif in and modify then any value should be acceptable which may be a concern for interoperability?

----- Original Message ----
From: Scott G. Kelly < s.kelly@ix.netcom.com>
To: capwap <capwap@frascone.com>
Sent: Thursday, October 5, 2006 3:15:40 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Following up once again - after careful review, I still agree with Charles, and here's some suggested text for the security considerations:

13.5.  IEEE 802.11 Security

    When used with an IEEE 802.11 infrastructure with WEP encryption, the
   CAPWAP protocol does not add any new vulnerabilities.  Derived
   session keys between the STA and WTP can be compromised, resulting in
   many well-documented attacks.  Implementors SHOULD discourage the use
   of WEP and encourage use of technically sound cryptographic solutions
   such as those in an IEEE 802.11 RSN.

   When used with IEEE 802.11 RSN security, the CAPWAP protocol
   may introduce new vulnerabilities, depending on whether the link security
  (packet encryption and integrity verification) is provided by the WTP or the AC.
   When the link security function is provided by the AC, no new security
   concerns are introduced.

   However, when the WTP provides link security, a new vulnerability will
   exist when the following conditions are true:

    o the client is not the first to associate to the WTP/ESSID
        (i.e. other clients are associated), and a GTK already exists

        o traffic has been broadcast under the existing GTK

   Under these circumstances, the receive sequence counter (KeyRSC)
   associated with the GTK is non-zero, but because the AC anchors the
   4-way handshake with the client, the exact value of the KeyRSC is not
   known when the AC constructs the message containing the GTK.
   The client will update its Key RSC value to the current valid KeyRSC
   upon receipt of a valid multicast/broadcast message, but prior to this,
   previous multicast/broadcast traffic which was secured with the existing
   GTK may be replayed, and the client will accept this traffic as valid.

   Typically, busy networks will produce numerous multicast or broadcast
   frames per second, so the window of opportunity with respect to such
   replay is expected to be very small. In most conditions, it is expected that
   replayed frames could be detected (and logged) by the WTP.

   The only way to completely close this window is to provide the
   exact KeyRSC value in message 3 of the 4-way handshake; any
   other approach simply narrows the window to varying degrees. Given
   the low relative threat level this presents, the additional complexity
   introduced by providing the exact KeyRSC value is not warranted. That
   is, this specification provides for a calculated risk in this regard.
==>
However, WTP implementations MAY provide the exact KeyRSC value before forwarding message 3 of the 4-way handshake.

--behcet

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_18045_3407670.1160085238354-- --===============0811558441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0811558441==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 18:06:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVbMh-000821-Qu for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 18:06:51 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbMc-0008SP-5t for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 18:06:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 77BE51448068 for ; Thu, 5 Oct 2006 15:06:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ADF6C4300F2 for ; Thu, 5 Oct 2006 15:05:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 942781448058 for ; Thu, 5 Oct 2006 15:05:38 -0700 (PDT) Received: from ccerelbas04.cce.hp.com (ccerelbas04.cce.hp.com [161.114.21.107]) by hermes.tigertech.net (Postfix) with ESMTP id 02D3A144804E for ; Thu, 5 Oct 2006 15:05:32 -0700 (PDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id A6B8A343A3; Thu, 5 Oct 2006 17:05:31 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 17:05:15 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Oct 2006 17:05:14 -0500 Message-ID: <08CA2245AFCF444DB3AC415E47CC40AF276EC2@G3W0072.americas.hpqcorp.net> In-Reply-To: <638DF8C4-F0F1-436E-A383-E07F33D59D0B@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 2-Port/Mux Issue Discussion Thread-Index: AcbdY6oGQj2Ivpl7Rn2dikL2XscVAwLZnA+Q From: "Chiu, Ran-Fun" To: "Margaret Wasserman" , X-OriginalArrivalTime: 05 Oct 2006 22:05:15.0611 (UTC) FILETIME=[56555AB0:01C6E8CA] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 We prefer the two-port solution. Ran-Fun Chiu HP Labs > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, September 21, 2006 1:50 AM > To: capwap@frascone.com > Subject: [Capwap] 2-Port/Mux Issue Discussion > > > Hi All, > > As many of you know, we have had a technical issue open in the CAPWAP > WG for some time that is commonly referred to as the 2-port/mux > issue. This issue involves a technical choice between: > > - A solution that uses two different well-known UDP ports for > separate data and control communications (the 2-port solution), > > OR > > - A solution that uses a single well-known UDP port for all > communication, with control and data traffic distinguished by a > CAPWAP header value (the mux solution). > > Strong opinions have been expressed on both sides of this issue, and > the WG has had trouble coming to consensus on a single choice. > Discussions in this area have included a wide variety of networking > topics, such as Quality of Service, NAT Traversal and Mobility. > > Given the breadth of the technical issues under discussion, our Area > Director, Dan Romascanu, decided to solicit advice from the IESG to > help us understand the technical trade-offs, and to help us > understand which factors it would be reasonable to consider in our > working group decision -- specifically whether or not it was > reasonable for us to consider the hardware implications of this > decision. The only IESG members who showed up for the discussion > were Mark Townsley, one of the Internet ADs, and our two OPS ADs, Dan > and David Kessens. We didn't receive a definitive answer from the > IESG, but a clear message was received from Mark Townsley that it is > reasonable for the group to consider the hardware implications of our > work -- both compatibility with currently deployed hardware, and the > hardware architectures we might want to support in the future. > > After much discussion with the interested IESG members, the document > editors, the proponents of both solutions and some people who have > proposed compromise solutions, the chairs believe that the key > technical difference between these two proposals is which hardware > architecture(s) they will support. There are currently two different > classes of AC hardware deployed, and variants on both of these > architectures may be deployed in the future: > > - Single-Processor: In this architecture, the control plane and the > data plane run on a single processor. The demultiplexing of control > and data packets happens on that processor. > > - Separate Data & Control Planes: In this architecture, the data and > control planes run on separate processors (and possibly on separate > cards), typically connected via a switching fabric. This is a common > hardware architecture for higher-end routing and switching hardware, > and it relies on a port-based splitting/load-balancing approach to > separate the control and data traffic. For CAPWAP to work > efficiently on these systems, it must be possible to distinguish the > control and data traffic in the switching hardware, which is > typically done based on the five-tuple of the send & recv IP > addresses, the protocol (UDP), and the send & recv port numbers. The > switching hardware cannot do the type of deep packet inspection > required to demultiplex on CAPWAP header fields. > > The 2-port approach supports both the "Single-Processor" AC > architecture and the "Separate Data & Control Planes" AC > architecture. Proponents of this solution believe that it is > important to support the "Separate Data & Control Planes" > architecture efficiently, both for compatibility with currently > deployed hardware and to allow this hardware architecture to be used > for future CAPWAP-enabled products. > > The mux approach will only operate efficiently on "Single-Processor" > systems. as it relies on the ability to demultiplex the control and > data traffic using CAPWAP header information. Proponents of this > solution believe that it will simplify CAPWAP software > implementation, and that it makes NAT traversal (when the AC and the > WTPs are on different sides of a NAT) simpler to configure. > > This complexity is a consequence of the choice to tunnel all WLAN > data traffic to the AC. In split-MAC local-forwarding mode, only the > control plane traffic would be sent to the AC, and data plane > forwarding would be handled by the WTPs themselves. > > We've heard from a couple of strong voices on this issue. but now > we'd like to hear from the rest of the WG... > > Which hardware architecture(s) does the CAPWAP protocol needs to > support? > > Specifically, do you think that it should be a requirement to > support efficient operation on currently deployed and future ACs that > follow the "Separate Control & Data Planes" architecture described > above? Or do you think that it would be acceptable to produce a > somewhat cleaner and simpler protocol that will not work efficiently > on those ACs? > > Please send your response by Thursday, October 5th (two weeks from > today), so that the chairs can gauge the consensus of the WG in this > matter. > > After we have an understanding of which hardware architecture(s) the > CAPWAP protocol needs to support, we will make an effort to sort > through the various proposals and counter-proposals that meet that > requirement. > > Thanks, > > The CAPWAP Chairs > Dorothy Gellert, Mahalingam Mani & Margaret Wasserman > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 18:51:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVc42-0007im-9a for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 18:51:38 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbzb-0002F7-KV for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 18:47:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 02AD21448040 for ; Thu, 5 Oct 2006 15:46:58 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 4D1454300F2 for ; Thu, 5 Oct 2006 15:39:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0CB19144803D for ; Thu, 5 Oct 2006 15:39:46 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by hermes.tigertech.net (Postfix) with ESMTP id 05868144801F for ; Thu, 5 Oct 2006 15:39:43 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so960190nfb for ; Thu, 05 Oct 2006 15:39:42 -0700 (PDT) Received: by 10.49.29.3 with SMTP id g3mr4629197nfj; Thu, 05 Oct 2006 15:39:42 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Thu, 5 Oct 2006 15:39:41 -0700 (PDT) Message-ID: <5bfe7a820610051539j6174a13fv3f54f78d11b3a4a4@mail.gmail.com> Date: Thu, 5 Oct 2006 15:39:41 -0700 From: "Dorothy Stanley" To: "Partha Narasimhan" In-Reply-To: <99C8B9B2AD99664A87E12C839A2E9093F1652B@aruba-mx1.arubanetworks.com> MIME-Version: 1.0 References: <26298393.1159465449346.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <92EA30D4-8C07-4FC3-A2CB-4EED0CEDEEBB@thingmagic.com> <99C8B9B2AD99664A87E12C839A2E9093F1652B@aruba-mx1.arubanetworks.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170446500==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c --===============1170446500== Content-Type: multipart/alternative; boundary="----=_Part_18529_16241823.1160087981778" ------=_Part_18529_16241823.1160087981778 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, Summary: In one current (and potentially future) AC product implementation(s), packets are initially received by component hardware that can only efficiently distinguish between control and data traffic using a five-tuple that includes the UDP ports. These implementations cannot efficiently distinguish between control and data traffic within a single port. In some 5 known current (and potentially future) AC product implementations, packets are initially received by a component (such as a NPU or a CPU) that can efficiently distinguish between control and data traffic by looking at the CAPWAP headers. These implementations can also distinguish between control and data traffic using a five-tuple that includes the UDP ports. Questions: a) Should the CAPWAP protocol include support for a single port mode? Answer: Yes. to enable capable product implementations to take advantage of the simplicity, reduced complexity and NAT traversal benefits of single port mode operation. b) Should the CAPWAP protocol include a means to enable its efficient implementation on UDP-port-only product implementations? Answer: Desired, not required as support, though not efficient, of a single port mode seems to be available.. It is very disappointing to see the the time and energy of the WG so wantonly wasted in pursuit of non-existent issues surrounding this topic. Dorothy On 10/5/06, Partha Narasimhan wrote: > > My two cents below, FWIW. > > - Assuming that most currently deployed L2 switches can be upgraded to > support CAPWAP merely with a software upgrade is well beyond the limits > of what I would normally assume in a typical day in my life. > > - In all of the debate, I haven't seen the proponents of the two-port > solution acknowledge significant additional complexity this solution > imposes on the entire protocol. Overall, it increases the > cost/complexity of implementation and/or trouble-shooting over the > single-port mux solution. > > - The single-port mux solution can be made to work on existing gear, > except it may or may not be as efficient as an implementation on some > other gear that is more recent or being designed now. The current > protocol design work should not be influenced by the inefficiencies of > implementing it in gear that was designed well before the need for > CAPWAP crept into people's minds. > > - Choosing a more complicated solution over a simpler one would also > lead to the protocol not getting deployed because of the cost of > implementing it. I am especially concerned whether the WTP vendors can > bear the increased cost of implementation and interoperability testing > and whether this will influence their decisions to drop support for > CAPWAP in their gear. This is the other side of the coin to the argument > that designing the protocol, albeit with a more complex solution, to fit > older implementations would increase the chance of it being widely > deployed. > > Thanks > partha > > PS: While debating this issue, we went through what we now know were > detours along non-existent routing and QoS issues. Makes one wonder what > is really behind every long and drawn-out discussion in this WG. > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, September 28, 2006 12:24 PM > To: Scott G. Kelly > Cc: capwap > Subject: Re: [Capwap] 2-Port/Mux Issue Discussion > > > Hi Scott, > > I'd just like to state, for clarity, that the message you are > responding to came from all three of the CAPWAP chairs. Although I > drafted and sent the message, it did reflect input from Mani and > Dorothy. > > This response is just from me, and the opinions expressed are mine. > The other chairs may not agree. > > On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote: > >> - Single-Processor: In this architecture, the control plane and the > >> data plane run on a single processor. The demultiplexing of control > >> and data packets happens on that processor. > >> > >> - Separate Data & Control Planes: In this architecture, the > >> data and > >> control planes run on separate processors (and possibly on separate > >> cards), typically connected via a switching fabric. This is > >> a common > >> hardware architecture for higher-end routing and switching hardware, > >> and it relies on a port-based splitting/load-balancing approach to > >> separate the control and data traffic. For CAPWAP to work > >> efficiently on these systems, it must be possible to distinguish the > >> control and data traffic in the switching hardware, which is > >> typically done based on the five-tuple of the send & recv IP > >> addresses, the protocol (UDP), and the send & recv port > >> numbers. The > >> switching hardware cannot do the type of deep packet inspection > >> required to demultiplex on CAPWAP header fields. > > > > This is one of the mischaracterizations I see. The issues have > > nothing to do with how many processors there are - they have to do > > with separation of control and data planes, and with the switching > > facility used to distribute packets between these two planes. This > > is a critical distinction. > > I agree with you comment, and your private note on this subject was > very helpful to advance my thinking on this matter. However, I do not > think that your correction fundamentally changes the situation. It > would have been better if we had characterized these systems based on > how received packets are handled, rather than based on the number of > processors in the system, but that doesn't change the fact that there > are two type of systems: > > (1) Those where the packet is initially received by a component (such > as a NPU or a CPU) that can distinguish between control and data > traffic by looking at the CAPWAP headers. There may be additional > processors on this type of systems, so using the phrase "single- > processor" to describe these systems was not correct. > > AND > > (2) Those where the packet is initially received by switching > hardware that can only efficiently distinguish between control and > data traffic using a five-tuple that includes the UDP ports. > > There are both high- and low-performance systems that correspond to > each architecture. > > > Based on the clarification above, it should be clear that this is > > also a mischaracterization. Either approach will work in either of > > the architectures, and in particular, in either of the > > architectures _as they are deployed today_. The real problem > > appears to be that one vendor has made a conscious choice to limit > > the control/data switching facility to 5-tuple-based solutions. > > I am personally aware of switching equipment from more than one > vendor that is restricted to using a five-tuple for switching > incoming traffic. I am not currently aware of whether these systems > are sold as WLAN switches, but I believe that many of them could be > software upgraded to serve in that role. Given the widespread > deployment of switches that employ this architecture, I believe that > it is desirable to make sure that CAPWAP can be added, as a software > upgrade, to systems of this type. > > I could express some opinions about which architecture is better, but > my opinion on that subject is immaterial. Both systems are widely > deployed, and I think that we are likely to see wider deployment of > CAPWAP if it can work well on both architectures. > > >> This complexity is a consequence of the choice to tunnel all WLAN > >> data traffic to the AC. In split-MAC local-forwarding mode, > >> only the > >> control plane traffic would be sent to the AC, and data plane > >> forwarding would be handled by the WTPs themselves. > > > > This also seems mischaracterized, because in all currently defined > > split-MAC modes, a data channel must be established in order to > > handle 802.11 management and authentication frames (even when > > you're doing local bridging of the data). > > Perhaps Mani could respond to this point, as he was the originator of > this text. > > > In any event, Margaret is right: the working group needs to speak > > up so we can close this and move on. I'm done arguing about this, > > and life will go on one way or another regardless of what we > > choose. But at least, we should all be clear on what's happened > > here, and go into this eyes wide open. > > Thanks for your comments, and for your continuing efforts to keep > this work moving forward. > > Margaret > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_18529_16241823.1160087981778 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

All,

Summary:

In one current (and potentially future) AC product implementation(s), packets are initially received by component
hardware that can only efficiently distinguish between control and
data traffic using a five-tuple that includes the UDP ports. These implementations
cannot efficiently distinguish between control and data traffic within a single port.

In some  5 known current (and potentially future) AC product implementations, packets are initially received by a component (such
as a NPU or a CPU) that can efficiently distinguish between control and data
traffic by looking at the CAPWAP headers. These implementations can also distinguish between
control and data traffic using a five-tuple that includes the UDP ports.

Questions:

a)       Should the CAPWAP protocol include support for a single port mode?

Answer: Yes. to enable capable product implementations to take advantage of the simplicity, reduced
complexity and  NAT traversal benefits of single port mode operation.

b)       Should the CAPWAP protocol include a means to enable its efficient implementation on UDP-port-only
product implementations?

Answer: Desired, not required as support, though not efficient, of a single port mode seems to be available..

      It is very disappointing to see the the time and energy of the WG so wantonly wasted in pursuit of non-existent
issues surrounding this topic.

Dorothy



On 10/5/06, Partha Narasimhan <partha@arubanetworks.com> wrote:
My two cents below, FWIW.

- Assuming that most currently deployed L2 switches can be upgraded to
support CAPWAP merely with a software upgrade is well beyond the limits
of what I would normally assume in a typical day in my life.

- In all of the debate, I haven't seen the proponents of the two-port
solution acknowledge significant additional complexity this solution
imposes on the entire protocol. Overall, it increases the
cost/complexity of implementation and/or trouble-shooting over the
single-port mux solution.

- The single-port mux solution can be made to work on existing gear,
except it may or may not be as efficient as an implementation on some
other gear that is more recent or being designed now. The current
protocol design work should not be influenced by the inefficiencies of
implementing it in gear that was designed well before the need for
CAPWAP crept into people's minds.

- Choosing a more complicated solution over a simpler one would also
lead to the protocol not getting deployed because of the cost of
implementing it. I am especially concerned whether the WTP vendors can
bear the increased cost of implementation and interoperability testing
and whether this will influence their decisions to drop support for
CAPWAP in their gear. This is the other side of the coin to the argument
that designing the protocol, albeit with a more complex solution, to fit
older implementations would increase the chance of it being widely
deployed.

Thanks
partha

PS: While debating this issue, we went through what we now know were
detours along non-existent routing and QoS issues. Makes one wonder what
is really behind every long and drawn-out discussion in this WG.



-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: Thursday, September 28, 2006 12:24 PM
To: Scott G. Kelly
Cc: capwap
Subject: Re: [Capwap] 2-Port/Mux Issue Discussion


Hi Scott,

I'd just like to state, for clarity, that the message you are
responding to came from all three of the CAPWAP chairs.  Although I
drafted and sent the message, it did reflect input from Mani and
Dorothy.

This response is just from me, and the opinions expressed are mine.
The other chairs may not agree.

On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote:
>> - Single-Processor:  In this architecture, the control plane and the
>> data plane run on a single processor.  The demultiplexing of control
>> and data packets happens on that processor.
>>
>> - Separate Data & Control Planes:  In this architecture, the
>> data and
>> control planes run on separate processors (and possibly on separate
>> cards), typically connected via a switching fabric.  This is
>> a common
>> hardware architecture for higher-end routing and switching hardware,
>> and it relies on a port-based splitting/load-balancing approach to
>> separate the control and data traffic.  For CAPWAP to work
>> efficiently on these systems, it must be possible to distinguish the
>> control and data traffic in the switching hardware, which is
>> typically done based on the five-tuple of the send & recv IP
>> addresses, the protocol (UDP), and the send & recv port
>> numbers.  The
>> switching hardware cannot do the type of deep packet inspection
>> required to demultiplex on CAPWAP header fields.
>
> This is one of the mischaracterizations I see. The issues have
> nothing to do with how many processors there are - they have to do
> with separation of control and data planes, and with the switching
> facility used to distribute packets between these two planes. This
> is a critical distinction.

I agree with you comment, and your private note on this subject was
very helpful to advance my thinking on this matter. However, I do not
think that your correction fundamentally changes the situation.  It
would have been better if we had characterized these systems based on
how received packets are handled, rather than based on the number of
processors in the system, but that doesn't change the fact that there
are two type of systems:

(1) Those where the packet is initially received by a component (such
as a NPU or a CPU) that can distinguish between control and data
traffic by looking at the CAPWAP headers.  There may be additional
processors on this type of systems, so using the phrase "single-
processor" to describe these systems was not correct.

AND

(2) Those where the packet is initially received by switching
hardware that can only efficiently distinguish between control and
data traffic using a five-tuple that includes the UDP ports.

There are both high- and low-performance systems that correspond to
each architecture.

> Based on the clarification above, it should be clear that this is
> also a mischaracterization. Either approach will work in either of
> the architectures, and in particular, in either of the
> architectures _as they are deployed today_. The real problem
> appears to be that one vendor has made a conscious choice to limit
> the control/data switching facility to 5-tuple-based solutions.

I am personally aware of switching equipment from more than one
vendor that is restricted to using a five-tuple for switching
incoming traffic.  I am not currently aware of whether these systems
are sold as WLAN switches, but I believe that many of them could be
software upgraded to serve in that role.  Given the widespread
deployment of switches that employ this architecture, I believe that
it is desirable to make sure that CAPWAP can be added, as a software
upgrade, to systems of this type.

I could express some opinions about which architecture is better, but
my opinion on that subject is immaterial.  Both systems are widely
deployed, and I think that we are likely to see wider deployment of
CAPWAP if it can work well on both architectures.

>> This complexity is a consequence of the choice to tunnel all WLAN
>> data traffic to the AC.  In split-MAC local-forwarding mode,
>> only the
>> control plane traffic would be sent to the AC, and data plane
>> forwarding would be handled by the WTPs themselves.
>
> This also seems mischaracterized, because in all currently defined
> split-MAC modes, a data channel must be established in order to
> handle 802.11 management and authentication frames (even when
> you're doing local bridging of the data).

Perhaps Mani could respond to this point, as he was the originator of
this text.

> In any event, Margaret is right: the working group needs to speak
> up so we can close this and move on. I'm done arguing about this,
> and life will go on one way or another regardless of what we
> choose. But at least, we should all be clear on what's happened
> here, and go into this eyes wide open.

Thanks for your comments, and for your continuing efforts to keep
this work moving forward.

Margaret

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_18529_16241823.1160087981778-- --===============1170446500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1170446500==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 19:17:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcSf-0005LC-V7 for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:17:05 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVcEl-0006WS-Ew for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:02:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7C2739806C for ; Thu, 5 Oct 2006 16:02:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1BD404300F2 for ; Thu, 5 Oct 2006 16:01:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0557239804D for ; Thu, 5 Oct 2006 16:01:40 -0700 (PDT) X-Greylist-Status: Sender first seen 14 days 14:14:31 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0ACF9398011 for ; Thu, 5 Oct 2006 16:01:36 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1354213; Thu, 05 Oct 2006 19:01:34 -0400 In-Reply-To: <5bfe7a820610051444k6e26ca39q417afa6f7cb86f51@mail.gmail.com> References: <5bfe7a820610050934k245312ebrdf168d059d938084@mail.gmail.com> <82E78D5D-C43D-4FFF-91A1-708918E5DBAB@thingmagic.com> <5bfe7a820610051444k6e26ca39q417afa6f7cb86f51@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <6F733085-441E-4F92-91B8-78A892C380B3@thingmagic.com> From: Margaret Wasserman Date: Thu, 5 Oct 2006 18:59:40 -0400 To: Dorothy Stanley X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Hi Dorothy, If the MIB uses mW, then I agree it is better to use mW-related units for compatibility. Thanks, Margaret On Oct 5, 2006, at 5:44 PM, Dorothy Stanley wrote: > Margaret, > > dBm units could also be used. This message element, and the TX Power > Level use mW, the TX Power Level to correspond with the 802.11 MIB > definitions, which use mW units. > > Dorothy > > On 10/5/06, Margaret Wasserman wrote: > Hi All, > > This request is based on the assumption that the WTP's power level > will actually be set in dBm. If that is true, why not use dBm (or > centi-dBm) as the unit for this attribute, instead of mW (or 0.1 mW)? > > Margaret > > On Oct 5, 2006, at 12:34 PM, Dorothy Stanley wrote: > > > All, > > > > The proposed resolution to the 11.9.18 comment is: Accept the > > commenters suggestion, change > > > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > > > Comments welcome, > > > > Thanks, > > > > Dorothy > > > > On 9/25/06, zhaoyujin 31390 wrote: Section > > 11.9.18 has following discripiton, I suggestion some change > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > The reason is: normally WLAN will use dbm. The conversion between > > dbm and mw can not satisfy this TLV requirement. If capwap > > transimit one mw value, the device can't precise get corresponding > > dbm. > > > > For example > > 1 dbm<----->1.3mw ----> 1mw > > 2 dbm<----->1.6mw ----> 2mw > > 3 dbm<----->2.0mw ----> 2mw > > > > This time, if capwap transmits 2 mw, system doesn't know it is > > 2dbm or 3 dbm. > > > > The following is suggestion: > > For example > > 1 dbm<----->1.3mw ----> 13mw > > 2 dbm<-----> 1.6mw ----> 16mw > > 3 dbm<-----> 2.0mw ----> 20mw > > > > Thanks > > Michael > > > > > The Tx power message element value is bi-directional. When > > sent by > > > the WTP, it contains the current power level of the radio in > > > question. When sent by the AC, it contains the power level the > > WTP > > > MUST adhere to. > > > > > > 0 1 > 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > > 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > | Radio ID | Reserved | Current Tx > > Power | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > > > > Type: 1041 for IEEE 802.11 Tx Power > > > > > > Length: 4 > > > > > > Radio ID: An 8-bit value representing the radio to configure. > > > > > > Reserved: MUST be set to zero > > > > > > Current Tx Power: This attribute contains the transmit output > > power > > > in mW. > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity whose > > address is listed above. Any use of the information contained > > herein in any way (including, but not limited to, total or partial > > disclosure, reproduction, or dissemination) by persons other than > > the intended recipient's) is prohibited. If you receive this e-mail > > in error, please notify the sender by phone or email > > immediately and delete it! > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 19:43:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVcs8-0002wS-AQ for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:43:24 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVcs1-0003ik-QA for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:43:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 08F8239806C for ; Thu, 5 Oct 2006 16:43:15 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B5DD74300F2 for ; Thu, 5 Oct 2006 16:41:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 734DD144803D for ; Thu, 5 Oct 2006 16:41:15 -0700 (PDT) Received: from ccerelbas04.cce.hp.com (ccerelbas04.cce.hp.com [161.114.21.107]) by hermes.tigertech.net (Postfix) with ESMTP id 6E0D1144803E for ; Thu, 5 Oct 2006 16:41:08 -0700 (PDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 94F5F342B8; Thu, 5 Oct 2006 18:41:03 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 18:40:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Oct 2006 18:40:43 -0500 Message-ID: <08CA2245AFCF444DB3AC415E47CC40AF276F63@G3W0072.americas.hpqcorp.net> In-Reply-To: <5bfe7a820610051539j6174a13fv3f54f78d11b3a4a4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 2-Port/Mux Issue Discussion Thread-Index: Acbo0D310qY4MjLBRWuTN7ybgtNMLgAA7oXQ From: "Chiu, Ran-Fun" To: "Dorothy Stanley" , "Partha Narasimhan" X-OriginalArrivalTime: 05 Oct 2006 23:40:44.0292 (UTC) FILETIME=[ACE4B440:01C6E8D7] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573191291==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d This is a multi-part message in MIME format. --===============0573191291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E8D7.ACB88B1F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E8D7.ACB88B1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is this the consensus? Or, we are still looking for a consensus? The current draft has a two-port UDP solution, but does not specify how to handle Discovery (or, I missed something). Do we need a third port? We support the two-port solution if the Discovery issue is resolved. We also can agree to a one-port solution. The WG has to make a decision. =20 Ran-Fun Chiu =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, October 05, 2006 3:40 PM To: Partha Narasimhan Cc: Margaret Wasserman; capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion =20 All, Summary:=20 In one current (and potentially future) AC product implementation(s), packets are initially received by component hardware that can only efficiently distinguish between control and data traffic using a five-tuple that includes the UDP ports. These implementations cannot efficiently distinguish between control and data traffic within a single port. In some 5 known current (and potentially future) AC product implementations, packets are initially received by a component (such as a NPU or a CPU) that can efficiently distinguish between control and data traffic by looking at the CAPWAP headers. These implementations can also distinguish between control and data traffic using a five-tuple that includes the UDP ports. Questions: a) Should the CAPWAP protocol include support for a single port mode?=20 Answer: Yes. to enable capable product implementations to take advantage of the simplicity, reduced=20 complexity and NAT traversal benefits of single port mode operation. b) Should the CAPWAP protocol include a means to enable its efficient implementation on UDP-port-only product implementations? Answer: Desired, not required as support, though not efficient, of a single port mode seems to be available.. It is very disappointing to see the the time and energy of the WG so wantonly wasted in pursuit of non-existent=20 issues surrounding this topic. Dorothy On 10/5/06, Partha Narasimhan wrote: My two cents below, FWIW. - Assuming that most currently deployed L2 switches can be upgraded to support CAPWAP merely with a software upgrade is well beyond the limits of what I would normally assume in a typical day in my life.=20 - In all of the debate, I haven't seen the proponents of the two-port solution acknowledge significant additional complexity this solution imposes on the entire protocol. Overall, it increases the cost/complexity of implementation and/or trouble-shooting over the=20 single-port mux solution. - The single-port mux solution can be made to work on existing gear, except it may or may not be as efficient as an implementation on some other gear that is more recent or being designed now. The current=20 protocol design work should not be influenced by the inefficiencies of implementing it in gear that was designed well before the need for CAPWAP crept into people's minds. - Choosing a more complicated solution over a simpler one would also=20 lead to the protocol not getting deployed because of the cost of implementing it. I am especially concerned whether the WTP vendors can bear the increased cost of implementation and interoperability testing and whether this will influence their decisions to drop support for=20 CAPWAP in their gear. This is the other side of the coin to the argument that designing the protocol, albeit with a more complex solution, to fit older implementations would increase the chance of it being widely=20 deployed. Thanks partha PS: While debating this issue, we went through what we now know were detours along non-existent routing and QoS issues. Makes one wonder what is really behind every long and drawn-out discussion in this WG.=20 -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Thursday, September 28, 2006 12:24 PM To: Scott G. Kelly Cc: capwap Subject: Re: [Capwap] 2-Port/Mux Issue Discussion Hi Scott, I'd just like to state, for clarity, that the message you are responding to came from all three of the CAPWAP chairs. Although I=20 drafted and sent the message, it did reflect input from Mani and Dorothy. This response is just from me, and the opinions expressed are mine. The other chairs may not agree. On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote:=20 >> - Single-Processor: In this architecture, the control plane and the >> data plane run on a single processor. The demultiplexing of control >> and data packets happens on that processor. >> >> - Separate Data & Control Planes: In this architecture, the >> data and >> control planes run on separate processors (and possibly on separate >> cards), typically connected via a switching fabric. This is=20 >> a common >> hardware architecture for higher-end routing and switching hardware, >> and it relies on a port-based splitting/load-balancing approach to >> separate the control and data traffic. For CAPWAP to work=20 >> efficiently on these systems, it must be possible to distinguish the >> control and data traffic in the switching hardware, which is >> typically done based on the five-tuple of the send & recv IP=20 >> addresses, the protocol (UDP), and the send & recv port >> numbers. The >> switching hardware cannot do the type of deep packet inspection >> required to demultiplex on CAPWAP header fields.=20 > > This is one of the mischaracterizations I see. The issues have > nothing to do with how many processors there are - they have to do > with separation of control and data planes, and with the switching=20 > facility used to distribute packets between these two planes. This > is a critical distinction. I agree with you comment, and your private note on this subject was very helpful to advance my thinking on this matter. However, I do not=20 think that your correction fundamentally changes the situation. It would have been better if we had characterized these systems based on how received packets are handled, rather than based on the number of processors in the system, but that doesn't change the fact that there=20 are two type of systems: (1) Those where the packet is initially received by a component (such as a NPU or a CPU) that can distinguish between control and data traffic by looking at the CAPWAP headers. There may be additional=20 processors on this type of systems, so using the phrase "single- processor" to describe these systems was not correct. AND (2) Those where the packet is initially received by switching hardware that can only efficiently distinguish between control and=20 data traffic using a five-tuple that includes the UDP ports. There are both high- and low-performance systems that correspond to each architecture. > Based on the clarification above, it should be clear that this is=20 > also a mischaracterization. Either approach will work in either of > the architectures, and in particular, in either of the > architectures _as they are deployed today_. The real problem > appears to be that one vendor has made a conscious choice to limit=20 > the control/data switching facility to 5-tuple-based solutions. I am personally aware of switching equipment from more than one vendor that is restricted to using a five-tuple for switching incoming traffic. I am not currently aware of whether these systems=20 are sold as WLAN switches, but I believe that many of them could be software upgraded to serve in that role. Given the widespread deployment of switches that employ this architecture, I believe that it is desirable to make sure that CAPWAP can be added, as a software=20 upgrade, to systems of this type. I could express some opinions about which architecture is better, but my opinion on that subject is immaterial. Both systems are widely deployed, and I think that we are likely to see wider deployment of=20 CAPWAP if it can work well on both architectures. >> This complexity is a consequence of the choice to tunnel all WLAN >> data traffic to the AC. In split-MAC local-forwarding mode, >> only the=20 >> control plane traffic would be sent to the AC, and data plane >> forwarding would be handled by the WTPs themselves. > > This also seems mischaracterized, because in all currently defined=20 > split-MAC modes, a data channel must be established in order to > handle 802.11 management and authentication frames (even when > you're doing local bridging of the data). Perhaps Mani could respond to this point, as he was the originator of=20 this text. > In any event, Margaret is right: the working group needs to speak > up so we can close this and move on. I'm done arguing about this, > and life will go on one way or another regardless of what we=20 > choose. But at least, we should all be clear on what's happened > here, and go into this eyes wide open. Thanks for your comments, and for your continuing efforts to keep this work moving forward.=20 Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6E8D7.ACB88B1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is this the consensus? Or, we are = still looking for a consensus? The current draft has a two-port UDP solution, = but does not specify how to handle Discovery (or, I missed something). Do we = need a third port?  We support the two-port solution if the Discovery = issue is resolved. We also can agree to a one-port solution. The WG has to make a decision.

 

Ran-Fun Chiu

 

From: = Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Thursday, October = 05, 2006 3:40 PM
To: Partha Narasimhan
Cc: Margaret Wasserman; = capwap
Subject: Re: [Capwap] = 2-Port/Mux Issue Discussion

 

All,

Summary:

In one current (and potentially future) AC product = implementation(s), packets are initially received by component
hardware that can only efficiently distinguish between control and
data traffic using a five-tuple that includes the UDP ports. These implementations
cannot efficiently distinguish between control and data traffic within a = single port.

In some  5 known current (and potentially future) AC = product implementations, packets are initially received by a component (such
as a NPU or a CPU) that can efficiently distinguish between control and = data
traffic by looking at the CAPWAP headers. These implementations can also distinguish between
control and data traffic using a five-tuple that includes the UDP = ports.

Questions:

a)       Should the CAPWAP = protocol include support for a single port mode?

Answer: Yes. to enable capable product implementations to take advantage of the simplicity, reduced
complexity and  NAT traversal benefits of single port mode = operation.

b)       Should the CAPWAP = protocol include a means to enable its efficient implementation on = UDP-port-only
product implementations?

Answer: Desired, not required as support, though not efficient, of a single port = mode seems to be available..

      It is very disappointing to see the the time and energy of the WG so = wantonly wasted in pursuit of non-existent
issues surrounding this topic.

Dorothy


On 10/5/06, Partha Narasimhan <partha@arubanetworks.com>= wrote:

My two cents below, FWIW.

- Assuming that most currently deployed L2 switches can be upgraded = to
support CAPWAP merely with a software upgrade is well beyond the = limits
of what I would normally assume in a typical day in my life.

- In all of the debate, I haven't seen the proponents of the = two-port
solution acknowledge significant additional complexity this solution
imposes on the entire protocol. Overall, it increases the
cost/complexity of implementation and/or trouble-shooting over the
single-port mux solution.

- The single-port mux solution can be made to work on existing gear,
except it may or may not be as efficient as an implementation on = some
other gear that is more recent or being designed now. The current
protocol design work should not be influenced by the inefficiencies = of
implementing it in gear that was designed well before the need for
CAPWAP crept into people's minds.

- Choosing a more complicated solution over a simpler one would also =
lead to the protocol not getting deployed because of the cost of
implementing it. I am especially concerned whether the WTP vendors = can
bear the increased cost of implementation and interoperability = testing
and whether this will influence their decisions to drop support for
CAPWAP in their gear. This is the other side of the coin to the = argument
that designing the protocol, albeit with a more complex solution, to = fit
older implementations would increase the chance of it being widely
deployed.

Thanks
partha

PS: While debating this issue, we went through what we now know were
detours along non-existent routing and QoS issues. Makes one wonder = what
is really behind every long and drawn-out discussion in this WG.



-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: Thursday, September 28, 2006 12:24 PM
To: Scott G. Kelly
Cc: capwap
Subject: Re: [Capwap] 2-Port/Mux Issue Discussion


Hi Scott,

I'd just like to state, for clarity, that the message you are
responding to came from all three of the CAPWAP = chairs.  Although I
drafted and sent the message, it did reflect input from Mani and
Dorothy.

This response is just from me, and the opinions expressed are mine.
The other chairs may not agree.

On Sep 28, 2006, at 1:44 PM, Scott G. Kelly wrote:
>> - Single-Processor:  In this architecture, the = control plane and the
>> data plane run on a single processor.  The = demultiplexing of control
>> and data packets happens on that processor.
>>
>> - Separate Data & Control Planes:  In this = architecture, the
>> data and
>> control planes run on separate processors (and possibly on = separate
>> cards), typically connected via a switching = fabric.  This is
>> a common
>> hardware architecture for higher-end routing and switching = hardware,
>> and it relies on a port-based splitting/load-balancing approach = to
>> separate the control and data traffic.  For CAPWAP to = work
>> efficiently on these systems, it must be possible to = distinguish the
>> control and data traffic in the switching hardware, which = is
>> typically done based on the five-tuple of the send & recv = IP
>> addresses, the protocol (UDP), and the send & recv port
>> numbers.  The
>> switching hardware cannot do the type of deep packet = inspection
>> required to demultiplex on CAPWAP header fields.
>
> This is one of the mischaracterizations I see. The issues have
> nothing to do with how many processors there are - they have to = do
> with separation of control and data planes, and with the switching =
> facility used to distribute packets between these two planes. = This
> is a critical distinction.

I agree with you comment, and your private note on this subject was
very helpful to advance my thinking on this matter. However, I do not =
think that your correction fundamentally changes the = situation.  It
would have been better if we had characterized these systems based = on
how received packets are handled, rather than based on the number of
processors in the system, but that doesn't change the fact that there =
are two type of systems:

(1) Those where the packet is initially received by a component = (such
as a NPU or a CPU) that can distinguish between control and data
traffic by looking at the CAPWAP headers.  There may be = additional
processors on this type of systems, so using the phrase = "single-
processor" to describe these systems was not correct.

AND

(2) Those where the packet is initially received by switching
hardware that can only efficiently distinguish between control and
data traffic using a five-tuple that includes the UDP ports.

There are both high- and low-performance systems that correspond to
each architecture.

> Based on the clarification above, it should be clear that this is =
> also a mischaracterization. Either approach will work in either = of
> the architectures, and in particular, in either of the
> architectures _as they are deployed today_. The real problem
> appears to be that one vendor has made a conscious choice to limit =
> the control/data switching facility to 5-tuple-based solutions.

I am personally aware of switching equipment from more than one
vendor that is restricted to using a five-tuple for switching
incoming traffic.  I am not currently aware of whether these = systems
are sold as WLAN switches, but I believe that many of them could be
software upgraded to serve in that role.  Given the = widespread
deployment of switches that employ this architecture, I believe that
it is desirable to make sure that CAPWAP can be added, as a software =
upgrade, to systems of this type.

I could express some opinions about which architecture is better, = but
my opinion on that subject is immaterial.  Both systems are = widely
deployed, and I think that we are likely to see wider deployment of
CAPWAP if it can work well on both architectures.

>> This complexity is a consequence of the choice to tunnel all = WLAN
>> data traffic to the AC.  In split-MAC = local-forwarding mode,
>> only the
>> control plane traffic would be sent to the AC, and data = plane
>> forwarding would be handled by the WTPs themselves.
>
> This also seems mischaracterized, because in all currently defined =
> split-MAC modes, a data channel must be established in order to
> handle 802.11 management and authentication frames (even when
> you're doing local bridging of the data).

Perhaps Mani could respond to this point, as he was the originator of =
this text.

> In any event, Margaret is right: the working group needs to = speak
> up so we can close this and move on. I'm done arguing about = this,
> and life will go on one way or another regardless of what we
> choose. But at least, we should all be clear on what's happened
> here, and go into this eyes wide open.

Thanks for your comments, and for your continuing efforts to keep
this work moving forward.

Margaret

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone= .com/pipermail/capwap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone= .com/pipermail/capwap

 

------_=_NextPart_001_01C6E8D7.ACB88B1F-- --===============0573191291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0573191291==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 19:59:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVd7J-0003QJ-5j for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:59:05 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVd7H-000109-LZ for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 19:59:05 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id BBFDA1448068 for ; Thu, 5 Oct 2006 16:58:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 91E364300F2 for ; Thu, 5 Oct 2006 16:58:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7E94C1448039 for ; Thu, 5 Oct 2006 16:58:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id E8C35144803E for ; Thu, 5 Oct 2006 16:57:58 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 16:57:58 -0700 X-IronPort-AV: i="4.09,267,1157353200"; d="scan'208"; a="328591494:sNHT34547168" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95NvvaT015679; Thu, 5 Oct 2006 16:57:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k95NvjOf023031; Thu, 5 Oct 2006 16:57:57 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Oct 2006 16:57:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Oct 2006 16:57:45 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8258@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue 214 - Prioritization of IEEE 802.1X frames Thread-Index: Acbe/8Ps7vRlB2fCRnaEaZdadJkT/gJ2jtQg From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" , "Michael Montemurro" X-OriginalArrivalTime: 05 Oct 2006 23:57:46.0245 (UTC) FILETIME=[0E065B50:01C6E8DA] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 - Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Second, 802.1X packet may be encrypted, if the AC supports 802.11i encryption. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com] > Sent: Saturday, September 23, 2006 2:12 AM > To: Michael Montemurro > Cc: capwap > Subject: Re: [Capwap] This is not need.: Proposed resolution > to Issue 214 - Prioritization of IEEE 802.1X frames > > Firstly, I have some doubt one this suggestion. > > 1. If CAPWAP difines like this, AP device must decode the > payload frames of 802.11 frames. > 2. Another problem, the 802.1x priority should be implement > by 802.11e. When station sends 802.11 data frames, it can set > 802.11e priority. AP should transfer 802.11e to actual CAPWAP > packet priority. > > So that I think CAPWAP does not need consider the priority of > 802.11 data frames payload. > > Thanks > Michael > > > > >Practically speaking, IEEE 802.1X frames should be > transmitted at the same priority as >IEEE 802.11 Management frames. > > > >I will update Section 11.5, rename Quality of Service for > IEEE 802.11 > >Control Messages >to "Quality of Service for IEEE 802.11 > control messages and IEEE 802.1X EAPoL frames" and add text > to >indicate that IEEE 802.1X frames are sent at a higher priority. > > > >Cheers, > > > >Mike > > > This e-mail and attachments contain confidential information > from HUAWEI, which is intended only for the person or entity > whose address is listed above. Any use of the information > contained herein in any way (including, but not limited to, > total or partial disclosure, reproduction, or dissemination) > by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please > notify the sender by phone or email immediately and delete it! > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 21:34:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVeb8-0003wK-DS for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 21:33:58 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVeTI-000332-6n for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 21:25:56 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id EBD541448062 for ; Thu, 5 Oct 2006 18:25:47 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 6CB164300F2 for ; Thu, 5 Oct 2006 18:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5B8AE144805D for ; Thu, 5 Oct 2006 18:23:44 -0700 (PDT) Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [204.127.225.94]) by hermes.tigertech.net (Postfix) with ESMTP id 8157E1448054 for ; Thu, 5 Oct 2006 18:23:40 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc14) with ESMTP id <20061006012339b1400jd959e>; Fri, 6 Oct 2006 01:23:39 +0000 Message-ID: <4525B01B.70101@cs.umd.edu> Date: Thu, 05 Oct 2006 21:23:39 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dorothy Stanley References: <20061005205629.7731.qmail@web60325.mail.yahoo.com> <5bfe7a820610051453s6789c214s406f179e27387425@mail.gmail.com> In-Reply-To: <5bfe7a820610051453s6789c214s406f179e27387425@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 We'd definitely need to specify a value for keyRSC in the appropriate section. That would be in addition to the changes to the security considerations. Without specifying a default value, we could have interoperability issues between WTPs and ACs. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Dorothy Stanley wrote: > Behcet, > > My understanding of Scott's recommendations is that > text be added into the security considerations section. > - no additional CAPWAP protocol exchange between the WTP and AC > - no specification of setting the keyRSC value to 0. > > Without some specification in the protocol, how can the WTP provide > the KeyRSC info to the AC in a way that the AC is sure to understand? > The most we can say > with respect to the standard is that an AC implementation is free to > comes up with its own algorithm to > set the keyRSC value. > > Dorothy > > On 10/5/06, *Behcet Sarikaya* > wrote: > > I agree with this and suggest adding Peter's fix as a possibility. > As far as interoperability is concerned, value 0 is interoperable > but not correct. If we allow implementations to snif in and modify > then any value should be acceptable which may be a concern for > interoperability? > > ----- Original Message ---- > From: Scott G. Kelly < s.kelly@ix.netcom.com > > > To: capwap > > Sent: Thursday, October 5, 2006 3:15:40 PM > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Following up once again - after careful review, I still agree with > Charles, and here's some suggested text for the security considerations: > > 13.5. IEEE 802.11 Security > > When used with an IEEE 802.11 infrastructure with WEP > encryption, the > CAPWAP protocol does not add any new vulnerabilities. Derived > session keys between the STA and WTP can be compromised, resulting in > many well-documented attacks. Implementors SHOULD discourage the use > of WEP and encourage use of technically sound cryptographic > solutions > such as those in an IEEE 802.11 RSN. > > When used with IEEE 802.11 RSN security, the CAPWAP protocol > may introduce new vulnerabilities, depending on whether the link > security > (packet encryption and integrity verification) is provided by the > WTP or the AC. > When the link security function is provided by the AC, no new > security > concerns are introduced. > > However, when the WTP provides link security, a new vulnerability > will > exist when the following conditions are true: > > o the client is not the first to associate to the WTP/ESSID > (i.e. other clients are associated), and a GTK already exists > > o traffic has been broadcast under the existing GTK > > Under these circumstances, the receive sequence counter (KeyRSC) > associated with the GTK is non-zero, but because the AC anchors the > 4-way handshake with the client, the exact value of the KeyRSC is not > known when the AC constructs the message containing the GTK. > The client will update its Key RSC value to the current valid KeyRSC > upon receipt of a valid multicast/broadcast message, but prior to > this, > previous multicast/broadcast traffic which was secured with the > existing > GTK may be replayed, and the client will accept this traffic as > valid. > > Typically, busy networks will produce numerous multicast or broadcast > frames per second, so the window of opportunity with respect to such > replay is expected to be very small. In most conditions, it is > expected that > replayed frames could be detected (and logged) by the WTP. > > The only way to completely close this window is to provide the > exact KeyRSC value in message 3 of the 4-way handshake; any > other approach simply narrows the window to varying degrees. Given > the low relative threat level this presents, the additional > complexity > introduced by providing the exact KeyRSC value is not warranted. > That > is, this specification provides for a calculated risk in this regard. > ==> > However, WTP implementations MAY provide the exact KeyRSC value > before forwarding message 3 of the 4-way handshake. > > --behcet > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 05 23:55:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVgoJ-0002kQ-D7 for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 23:55:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVghl-0001Pt-3S for capwap-archive@lists.ietf.org; Thu, 05 Oct 2006 23:48:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DA9901448062 for ; Thu, 5 Oct 2006 20:48:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 104144300F2 for ; Thu, 5 Oct 2006 20:46:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F1916398040 for ; Thu, 5 Oct 2006 20:46:52 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5D9FA398016 for ; Thu, 5 Oct 2006 20:46:50 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k963kdHV003352; Fri, 6 Oct 2006 12:46:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k963kfI05197; Fri, 6 Oct 2006 12:46:41 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with ESMTP id k963ke510393; Fri, 6 Oct 2006 12:46:40 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 11:45:37 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbo5i4byALsl6JxQDuyct94MfDlVQABuubQ From: "Cheng Hong" To: "Charles Clancy" , "Dorothy Stanley" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Hi Charles and all, To specify a "default" value means specifying it to "zero". Otherwise, it would not work. Say, the "default" value is set to 100, but the actual sequence number used could be 50 at the moment. It means the STA is not able to receive the Broadcast/Multicast packets for the next 50 seqeunce count. So, I think we need some clarification on what is the decision here. Is the decision now: - No change to the protocol design except some security disclaimers. And, specify a default value (0) to be used by the AC always. Or, We also allow: - The WTP and AC can choose to implement info exchange methods (a simple element to be specified in the draft). However, if some AC choose not to support such mechanism, it will have to set the KeyRSC to zero. And a security disclaimer to state what is the effect of setting the KeyRSC to zero. cheers Cheng Hong > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Friday, October 06, 2006 9:24 AM > To: Dorothy Stanley > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > We'd definitely need to specify a value for keyRSC in the > appropriate section. That would be in addition to the > changes to the security considerations. Without specifying a > default value, we could have interoperability issues between > WTPs and ACs. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Dorothy Stanley wrote: > > Behcet, > > > > My understanding of Scott's recommendations is that text be added > > into the security considerations section. > > - no additional CAPWAP protocol exchange between the WTP and AC > > - no specification of setting the keyRSC value to 0. > > > > Without some specification in the protocol, how can the WTP provide > > the KeyRSC info to the AC in a way that the AC is sure to > understand? > > The most we can say > > with respect to the standard is that an AC implementation > is free to > > comes up with its own algorithm to set the keyRSC value. > > > > Dorothy > > > > On 10/5/06, *Behcet Sarikaya* > > wrote: > > > > I agree with this and suggest adding Peter's fix as a > possibility. > > As far as interoperability is concerned, value 0 is > interoperable > > but not correct. If we allow implementations to snif in > and modify > > then any value should be acceptable which may be a concern for > > interoperability? > > > > ----- Original Message ---- > > From: Scott G. Kelly < s.kelly@ix.netcom.com > > > > > To: capwap > > > Sent: Thursday, October 5, 2006 3:15:40 PM > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Following up once again - after careful review, I still > agree with > > Charles, and here's some suggested text for the > security considerations: > > > > 13.5. IEEE 802.11 Security > > > > When used with an IEEE 802.11 infrastructure with WEP > > encryption, the > > CAPWAP protocol does not add any new > vulnerabilities. Derived > > session keys between the STA and WTP can be > compromised, resulting in > > many well-documented attacks. Implementors SHOULD > discourage the use > > of WEP and encourage use of technically sound cryptographic > > solutions > > such as those in an IEEE 802.11 RSN. > > > > When used with IEEE 802.11 RSN security, the CAPWAP protocol > > may introduce new vulnerabilities, depending on > whether the link > > security > > (packet encryption and integrity verification) is > provided by the > > WTP or the AC. > > When the link security function is provided by the AC, no new > > security > > concerns are introduced. > > > > However, when the WTP provides link security, a new > vulnerability > > will > > exist when the following conditions are true: > > > > o the client is not the first to associate to the WTP/ESSID > > (i.e. other clients are associated), and a GTK already > > exists > > > > o traffic has been broadcast under the existing GTK > > > > Under these circumstances, the receive sequence > counter (KeyRSC) > > associated with the GTK is non-zero, but because the > AC anchors the > > 4-way handshake with the client, the exact value of > the KeyRSC is not > > known when the AC constructs the message containing the GTK. > > The client will update its Key RSC value to the > current valid KeyRSC > > upon receipt of a valid multicast/broadcast message, > but prior to > > this, > > previous multicast/broadcast traffic which was > secured with the > > existing > > GTK may be replayed, and the client will accept this > traffic as > > valid. > > > > Typically, busy networks will produce numerous > multicast or broadcast > > frames per second, so the window of opportunity with > respect to such > > replay is expected to be very small. In most > conditions, it is > > expected that > > replayed frames could be detected (and logged) by the WTP. > > > > The only way to completely close this window is to > provide the > > exact KeyRSC value in message 3 of the 4-way handshake; any > > other approach simply narrows the window to varying > degrees. Given > > the low relative threat level this presents, the additional > > complexity > > introduced by providing the exact KeyRSC value is > not warranted. > > That > > is, this specification provides for a calculated > risk in this regard. > > ==> > > However, WTP implementations MAY provide the exact KeyRSC value > > before forwarding message 3 of the 4-way handshake. > > > > --behcet > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, > please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 00:15:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVh7a-0006Ot-4U for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 00:15:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVh7Y-000073-7m for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 00:15:37 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99A80398047 for ; Thu, 5 Oct 2006 21:15:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id ECC7B4300F2 for ; Thu, 5 Oct 2006 21:14:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 348B6398046 for ; Thu, 5 Oct 2006 21:14:22 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8B97398016 for ; Thu, 5 Oct 2006 21:14:19 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6P00ACM4YI82@usaga01-in.huawei.com> for capwap@frascone.com; Thu, 05 Oct 2006 21:11:07 -0700 (PDT) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6P00E5W4YGBV@usaga01-in.huawei.com> for capwap@frascone.com; Thu, 05 Oct 2006 21:11:06 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.18.23.62]) by szxmc01-in.huawei.com (mshttpd); Fri, 06 Oct 2006 09:14:10 +0500 Date: Fri, 06 Oct 2006 09:14:10 +0500 From: zhaoyujin 31390 To: Dorothy Stanley Message-id: <2a1c96a2a2236e.2a2236e2a1c96a@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Margaret Wasserman , capwap@frascone.com Subject: [Capwap] =?gb2312?B?u9i4tA==?=:Re: Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 Tx Power" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1921393290==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 --===============1921393290== Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Margaret =26 Dorothy=3A DBm can be used=2C but DBm units is not universal as mM=2E Because deff= erent device maybe defines different DBm level=2C CAPWAP is difficult to = track this difference=2E Regards Michael This e-mail and attachments contain confidential information from HUAWEI=2C= which is intended only for the person or entity whose address is listed = above=2E Any use of the information contained herein in any way (includin= g=2C but not limited to=2C total or partial disclosure=2C reproduction=2C= or dissemination) by persons other than the intended recipient=27s) is p= rohibited=2E If you receive this e-mail in error=2C please notify the sen= der by phone or email = immediately and delete it! ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Dorothy Stanley =3Cdstanley1389=40gmail=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CE=E5=2C =CA=AE=D4=C2 6=C8=D5=2C 2006 =C9=CF= =CE=E73=3A14 =D6=F7=CC=E2=3A Re=3A =5BCapwap=5D Proposed Resolution to =3AOne issue=2C= please discuss=3A I suggest some change for =2211=2E9=2E18=2E IEEE 802=2E= 11 Tx Power=22 =3E Margaret=2C =3E = =3E dBm units could also be used=2E This message element=2C and the TX Po= wer =3E Level use mW=2C the TX Power Level to correspond with the 802=2E11 MI= B =3E definitions=2C which use mW units=2E =3E = =3E Dorothy =3E = =3E On 10/5/06=2C Margaret Wasserman =3Cmargaret=40thingmagic=2Ecom=3E wr= ote=3A =3E =3E =3E =3E =3E =3E Hi All=2C =3E =3E =3E =3E This request is based on the assumption that the WTP=27s power le= vel =3E =3E will actually be set in dBm=2E If that is true=2C why not use dB= m (or =3E =3E centi-dBm) as the unit for this attribute=2C instead of mW (or 0=2E= 1 = =3E mW)=3F=3E =3E =3E Margaret =3E =3E =3E =3E On Oct 5=2C 2006=2C at 12=3A34 PM=2C Dorothy Stanley wrote=3A =3E =3E =3E =3E =3E All=2C =3E =3E =3E =3E =3E =3E The proposed resolution to the 11=2E9=2E18 comment is=3A Acce= pt the =3E =3E =3E commenters suggestion=2C change =3E =3E =3E =3E =3E =3E =3E =3E =3E From =22Current Tx Power=3A This attribute contains the t= ransmit =3E =3E =3E output power in mW=2E=22 =3E =3E =3E to =22Current Tx Power=3A This attribute contains the t= ransmit =3E =3E =3E output power in 0=2E1mW=2E=22 =3E =3E =3E =3E =3E =3E =3E =3E =3E Comments welcome=2C =3E =3E =3E =3E =3E =3E Thanks=2C =3E =3E =3E =3E =3E =3E Dorothy =3E =3E =3E =3E =3E =3E On 9/25/06=2C zhaoyujin 31390 =3Czhaoyujin=40huawei=2Ecom=3E = wrote=3A Section =3E =3E =3E 11=2E9=2E18 has following discripiton=2C I suggestion some ch= ange =3E =3E =3E =3E =3E =3E From =22Current Tx Power=3A This attribute contains the t= ransmit =3E =3E =3E output power in mW=2E=22 =3E =3E =3E to =22Current Tx Power=3A This attribute contains the t= ransmit =3E =3E =3E output power in 0=2E1mW=2E=22 =3E =3E =3E =3E =3E =3E The reason is=3A normally WLAN will use dbm=2E The conversion= between =3E =3E =3E dbm and mw can not satisfy this TLV requirement=2E If capwap =3E =3E =3E transimit one mw value=2C the device can=27t precise get corr= esponding =3E =3E =3E dbm=2E =3E =3E =3E =3E =3E =3E For example =3E =3E =3E 1 dbm=3C-----=3E1=2E3mw ----=3E 1mw =3E =3E =3E 2 dbm=3C-----=3E1=2E6mw ----=3E 2mw =3E =3E =3E 3 dbm=3C-----=3E2=2E0mw ----=3E 2mw =3E =3E =3E =3E =3E =3E This time=2C if capwap transmits 2 mw=2C system doesn=27t k= now it is =3E =3E =3E 2dbm or 3 dbm=2E =3E =3E =3E =3E =3E =3E The following is suggestion=3A =3E =3E =3E For example =3E =3E =3E 1 dbm=3C-----=3E1=2E3mw ----=3E 13mw =3E =3E =3E 2 dbm=3C-----=3E 1=2E6mw ----=3E 16mw =3E =3E =3E 3 dbm=3C-----=3E2=2E0mw ----=3E 20mw =3E =3E =3E =3E =3E =3E Thanks =3E =3E =3E Michael =3E =3E =3E =3E =3E =3E =3E The Tx power message element value is bi-directional=2E= When =3E =3E =3E sent by =3E =3E =3E =3E the WTP=2C it contains the current power level of the r= adio in =3E =3E =3E =3E question=2E When sent by the AC=2C it contains the pow= er = =3E level the =3E =3E =3E WTP =3E =3E =3E =3E MUST adhere to=2E =3E =3E =3E =3E =3E =3E =3E =3E 0 1 2 = = =3E 3 =3E =3E =3E =3E 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 = =3E 7 8 =3E =3E =3E 9 0 1 =3E =3E =3E =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+- =3E +-+-+- =3E =3E =3E +-+-+ =3E =3E =3E =3E =7C Radio ID =7C Reserved =7C Curr= ent Tx =3E =3E =3E Power =7C =3E =3E =3E =3E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+- =3E +-+-+- =3E =3E =3E +-+-+ =3E =3E =3E =3E =3E =3E =3E =3E Type=3A 1041 for IEEE 802=2E11 Tx Power =3E =3E =3E =3E =3E =3E =3E =3E Length=3A 4 =3E =3E =3E =3E =3E =3E =3E =3E Radio ID=3A An 8-bit value representing the radio to c= onfigure=2E =3E =3E =3E =3E =3E =3E =3E =3E Reserved=3A MUST be set to zero =3E =3E =3E =3E =3E =3E =3E =3E Current Tx Power=3A This attribute contains the transm= it output =3E =3E =3E power =3E =3E =3E =3E in mW=2E =3E =3E =3E =3E =3E =3E This e-mail and attachments contain confidential information = from =3E =3E =3E HUAWEI=2C which is intended only for the person or entity who= se =3E =3E =3E address is listed above=2E Any use of the information contain= ed =3E =3E =3E herein in any way (including=2C but not limited to=2C total o= r partial =3E =3E =3E disclosure=2C reproduction=2C or dissemination) by persons ot= her than =3E =3E =3E the intended recipient=27s) is prohibited=2E If you receive t= his e- =3E mail=3E =3E in error=2C please notify the sender by phone or email =3E =3E =3E immediately and delete it! =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E =3E To unsubscribe or modify your subscription options=2C please = visit=3A =3E =3E =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E =3E =3E =3E =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E =3E =3E =3E =3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E =3E =3E To unsubscribe or modify your subscription options=2C please = visit=3A =3E =3E =3E http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap =3E =3E =3E =3E =3E =3E Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap =3E =3E =3E =3E =3E --===============1921393290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1921393290==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 02:24:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVj8T-0000RQ-3x for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 02:24:41 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVj8N-0001iL-5f for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 02:24:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 70C03398045 for ; Thu, 5 Oct 2006 23:24:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 759EC4300F2 for ; Thu, 5 Oct 2006 23:23:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 54973398019 for ; Thu, 5 Oct 2006 23:23:02 -0700 (PDT) Received: from huawei-3com.com (h3cml01-in.huawei-3com.com [210.21.230.96]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF609398016 for ; Thu, 5 Oct 2006 23:22:59 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6P00MVMBC61K@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Fri, 06 Oct 2006 14:28:54 +0800 (CST) Received: from smtp2.huawei-3com.com ([172.19.1.39]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6P00LD1BC6QX@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Fri, 06 Oct 2006 14:28:54 +0800 (CST) Received: from unknown (HELO RichardYoung) ([10.18.23.88]) by smtp2.huawei-3com.com with ESMTP; Fri, 06 Oct 2006 14:22:44 +0800 Date: Fri, 06 Oct 2006 11:52:50 +0530 From: young To: dstanley1389@gmail.com, capwap@frascone.com Message-id: <001201c6e90f$d9f63390$5817120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbpD9jOe9Qb+3ejR6SwwbeHHGk48Q== X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: young@huawei-3com.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Hi, Dorothy: Thanks for your proposed resolutions. In your Proposed Resolution, you mentioned that " While there may be common elements, it's not clear that the = CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems." If it is not clear, I suggest that WG or mailing list had better take time to make it clear. Otherwise, how to decide what info should put in the base part if base part scope is not clear? I thought a clear and common understanding of base part's rule and scope is very important for base part separation from wireless specific binding. I give my comment for the proposed resolutions to issue 204. 1) 4.4.38. WTP Radio Information Sorry for I don't make issue clear in my comment. I suggest that WTP Radio Information could be kept in the current section 4.4. While 802.11a/b/g/n these kinds info could be defined by 802.11binding. We could add a Wireless binding identifier in the WTP Radio Information. = By this way, we could identify any Wireless binding's radio type definition. The Wireless binding identifier could be probably eventually managed by IANA. No matter what method will by used for Wireless binding identifier, it is a key Point to help base protocol to separate any wireless binding. I thought that Wireless binding identifier method will be a common issue. 2) 11.9.18. IEEE 802.11 Tx Power I suggest we could define a =93WTP Radio configuration=94 TLV. By using wireless binding identifier, there will be no conflict with Dot11PhyTxPowerEntry MIB table. Channel also could be put here. As AC will configure AP's RF parameter (AC to AP), and AP will report its current Configuration to AC, the TLV will be carried in the configuration message in bi-direction. More TLV could be added into the TLV if it is required. |---------|-------------|-----------------------------|--------------|------ ---|---------| | Radio ID| country code| wireless binding identifier | Max Tx Power |Tx Power | Channel | |---------|-------------|-----------------------------|--------------|------ -- |----------| = As Tx power these kind info will not be carried in the discovery phase, I suggest that =93WTP Radio configuration=94 is required instead of extenuation of " WTP Radio Information". Regards Richard (shiyang) From: Dorothy Stanley (dstanley1389gmail.com) = Date: Wed, 4 Oct 2006 09:08:21 -0700 (PDT) = All, Issue 204 and proposed resolutions to its components are = listed below. Comments please. Thanks, Dorothy ---------------------------------------------------------------------------- --------------------------------------------- 1) 4.4.38. WTP Radio Information Comment: As the section should be work for any wireless implement, I suggest the = following value should be moved to 802.11 binding. The value should be defined by wireless = technology binding. 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - = 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. Proposed Resolution: Move the "need to know" the 802.11 technology specific radio types to the 802.11 binding, modifying the WTP Radio Information element as follows: IEEE 802.11 Radio Information The IEEE 802.11 radio information message element is used to communicate the radio information for each IEEE 802.11 radio on the WTP. The Discovery Request message MUST include one such message element per radio in the WTP. The Radio-Type field is used by the AC to determine which 802.11 technology specific binding is to be used with the WTP. The value contains two fields, as shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Radio Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio Type | +-+-+-+-+-+-+-+-+ Type: 38 for WTP Radio Information Length: 5 Radio ID: The Radio Identifier, which typically refers to an interface index on the WTP Radio Type: The type of IEEE 802.11 radio present. = The following values are supported: 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - = 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types indicated are supported in the WTP. =A0 ---------------------------------------------------------------------------- --------------- 2) 11.9.18. IEEE 802.11 Tx Power Comment: I think it could be moved to the section 4.4, as channel and Tx power are = common parameters for RF management. Proposed Resolution: No change to the draft. Agree with the commenter that TX power level is a common parameter for RF management; however the IEEE 802.11 TX Power field values are defined as being the values defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions. --------------------------------------------------------------------------- 3) Add "WTP radio channel" Comment: As per 2), we could define a TLV to report current channel (AP to AC) or to = configure channel (AC to AP). Now,. 11.9.12. IEEE 802.11 OFDM Control and 11.9.5. IEEE 802.11 Direct = Sequence Control has channel configuration information. = But I think that a specific TLV for it is better. By this way, 4.4 will provide more common parameter for any wireless technology. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Reserved | Current Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The commenter suggests the following: 3)=A0=A0=A0=A0=A0 Add "WTP RF Radio configuration" in the section 4.4 = The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent = during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. = For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18.=A0 IEEE 802.11 Tx Power", "11.9.12.=A0 IEEE 802.11 OFDM Control "and "11.9.5.=A0 = IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. =A0Proposed Resolution: No change to the draft.=A0 While there may be common elements, it's not clear that the = CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems. = ---------------------------------------------------------------------------- -------- 4) 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indications Comment: I think it could be moved to the section 4.4, it could be a common event for = any wireless technology. Proposed Resolution: No change to the draft. Agree with the commmenter that a fail alarm indication could be a common event for any wireless technology. Each radio technology may want to have additional information reported with the event however. Not sure there is sufficient benefit shown for a common defintiion at this point. ---------------------------------------------------------------------------- ----------- 5) 11.9.1. IEEE 802.11 Add WLAN How about we rename "WLAN" as wireless service? By this way, we could achieve = abstract while make it work for most wireless technology. If it is ok, we could define "add wireless service, delete wireless service, update wireless service" in the section = 4.4. Any wireless technology could add its specific parameter in the binding = section. The commenter suggests a solution: 1) =A0=A0=A0=A0=A0 Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless = service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep = Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here). = While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using ( Probably eventually managed by IANA) Proposed resolution: Close, no change to the draft. The IEEE 802.11 Add WLAN message element is 802.11 specific and used together with several other message elements to define a WLAN service. The intent of the comment seems to be to have the ability in the = CAPWAP protocol to add a generic wireless service. It's not clear that there are enough additional elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. ---------------------------------------------------------------------------- ---- 6) 11.9.22. IEEE 802.11 WTP Quality of Service As per 5), I think we could define "WTP Quality of Service"in the section = 4.4. Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality of = Service". While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of = Service. The commenter suggests the following solution: 2) Rename "11.9.22.=A0 IEEE 802.11 WTP Quality of Service" as =A0"WTP Quali= ty of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. Proposed resolution: Close, no change to the draft. The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed to convey the CWMin , CWMax and other very specific 802.11 data. = The intent of the comment seems to be to have the ability in the = CAPWAP protocol to include a "generic QOS" message element. It's not clear that there are enough elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. There is at least 1 - the Tag packets type, which each binding can inlcude if desired. ---------------------------------------------------------------------------- ------------------------------------------------------ 7. Redefine "IEEE 802.11 Statistics" as =A0"WTP Statistics" in the section = 4.4 Comment: Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" = could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. Proposed resolution: No change to the draft. Agree with the commenter that many of the statistics are common across wireless technologies. However the IEEE 802.11 Statistics values are defined as being the values defined in various IEEE 802.11 MIB variables and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions. On 9/28/06, young wrote: = Hi Pat and all, I used to raise issue #204, and here intend to give solution. 1) =A0=A0=A0=A0=A0 Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless = service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep = Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here). = While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using ( Probably eventually managed by IANA) =A0=A0=A0 =A0=A0=A0=A0=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 =A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ =A0=A0=A0=A0=A0=A0 |=A0=A0=A0 Radio ID=A0=A0 |=A0=A0=A0 WLAN ID=A0=A0=A0 |= =A0=A0=A0=A0=A0=A0=A0 MAC Mode=A0=A0=A0 | Tunnel Mode=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+ =A0=A0=A0=A0=A0=A0 |=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Wireless binding i= dentifier =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ = =A0=A0=A0 =A0=A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0 Type=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 =A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Length=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0| =A0=A0=A0=A0 =A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ = =A0=A0=A0=A0 =A0=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Value... =A0=A0=A0=A0 =A0=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ = It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN". =A0 2) Rename "11.9.22.=A0 IEEE 802.11 WTP Quality of Service" as =A0"WTP Quali= ty of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. =A0 3)=A0=A0=A0=A0=A0 Add "WTP RF Radio configuration" in the section 4.4 = The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent = during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. = For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18.=A0 IEEE 802.11 Tx Power", "11.9.12.=A0 IEEE 802.11 OFDM Control "and "11.9.5.=A0 = IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. =A04)=A0=A0 Redefine "IEEE 802.11 Statistics" as =A0"WTP Statistics" in the= section 4.4 = Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" = could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. =A0 Any way, I thought many TLV will change their location as new CAPWAP will be divided into two parts. =A0 Cheers =A0 Richard =A0(Shiyang) _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From amendolai@centier.net Fri Oct 06 04:10:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVkmq-0000UJ-JX for capwap-archive@ietf.org; Fri, 06 Oct 2006 04:10:28 -0400 Received: from host-82-207-96-204.lv.ukrtel.net ([82.207.96.204] helo=centier.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVkif-0004JL-7Q for capwap-archive@ietf.org; Fri, 06 Oct 2006 04:06:11 -0400 Message-ID: <01c6e91e$29db0cb0$0484a8c0@oper> Date: Fri, 6 Oct 2006 11:05:18 +0200 X-MSMail-Priority: Normal X-Priority: 3 Reply-To: "Farouk Tolliver" From: "Farouk Tolliver" To: Subject: Re: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_92C1_01C6E937.4F2AB5B0" X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. ------=_NextPart_000_92C1_01C6E937.4F2AB5B0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi, ClAjLIS VALjlUM AMBjlEN VlAjGRA SAjVE 60 % with http://www.fertionkinfadesun.com =20 _____ =20 his flag officer carried two chairs. Zach supervised the seating In six months I would be far from here, my trail cold, my bank You are correct. So in the myth you, and every other young man, are ------=_NextPart_000_92C1_01C6E937.4F2AB5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

ClAjLIS

VALjlUM

AMBjlEN

VlAjGRA

 

his flag officer carried two chairs. Zach supervised the = seating
In six months I would be far from here, my trail cold, my = bank
You are correct. So in the myth you, and every other young man, = are

------=_NextPart_000_92C1_01C6E937.4F2AB5B0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 08:36:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVowL-0006G3-Fi for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 08:36:33 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVowJ-00057u-Ph for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 08:36:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 4536043052C for ; Fri, 6 Oct 2006 05:36:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id AD3A84300EA for ; Fri, 6 Oct 2006 05:33:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 872C0398042 for ; Fri, 6 Oct 2006 05:33:38 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [206.18.177.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 23669398031 for ; Fri, 6 Oct 2006 05:33:34 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc11) with ESMTP id <20061006123323b11008ducte>; Fri, 6 Oct 2006 12:33:34 +0000 Message-ID: <45264D14.4010809@cs.umd.edu> Date: Fri, 06 Oct 2006 08:33:24 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cheng Hong References: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 You're suggesting the disclaimer and "static initialization value" (perhaps more accurate term than a "default value") would be mandatory to implement, and there would also be an optional information exchange to synchronize the KeyRSC to something else. That certainly sounds like a good compromise, but I suspect a little more complicated to implement than it first appears. For example, the WTP would need to communicate it's ability to be queried for the KeyRSC to the AC during initialization. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Cheng Hong wrote: > Hi Charles and all, > > To specify a "default" value means specifying it to "zero". Otherwise, > it would not work. Say, the "default" value is set to 100, but the > actual sequence number used could be 50 at the moment. It means the STA > is not able to receive the Broadcast/Multicast packets for the next 50 > seqeunce count. > > So, I think we need some clarification on what is the decision here. Is > the decision now: > - No change to the protocol design except some security disclaimers. > And, specify a default value (0) to be used by the AC always. > > Or, We also allow: > - The WTP and AC can choose to implement info exchange methods (a simple > element to be specified in the draft). However, if some AC choose not to > support such mechanism, it will have to set the KeyRSC to zero. And a > security disclaimer to state what is the effect of setting the KeyRSC to > zero. > > cheers > > Cheng Hong > > > > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Friday, October 06, 2006 9:24 AM >> To: Dorothy Stanley >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> We'd definitely need to specify a value for keyRSC in the >> appropriate section. That would be in addition to the >> changes to the security considerations. Without specifying a >> default value, we could have interoperability issues between >> WTPs and ACs. >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> Dorothy Stanley wrote: >>> Behcet, >>> >>> My understanding of Scott's recommendations is that text be added >>> into the security considerations section. >>> - no additional CAPWAP protocol exchange between the WTP and AC >>> - no specification of setting the keyRSC value to 0. >>> >>> Without some specification in the protocol, how can the WTP provide >>> the KeyRSC info to the AC in a way that the AC is sure to >> understand? >>> The most we can say >>> with respect to the standard is that an AC implementation >> is free to >>> comes up with its own algorithm to set the keyRSC value. >>> >>> Dorothy >>> >>> On 10/5/06, *Behcet Sarikaya* >> > wrote: >>> >>> I agree with this and suggest adding Peter's fix as a >> possibility. >>> As far as interoperability is concerned, value 0 is >> interoperable >>> but not correct. If we allow implementations to snif in >> and modify >>> then any value should be acceptable which may be a concern for >>> interoperability? >>> >>> ----- Original Message ---- >>> From: Scott G. Kelly < s.kelly@ix.netcom.com >>> > >>> To: capwap > >>> Sent: Thursday, October 5, 2006 3:15:40 PM >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Following up once again - after careful review, I still >> agree with >>> Charles, and here's some suggested text for the >> security considerations: >>> 13.5. IEEE 802.11 Security >>> >>> When used with an IEEE 802.11 infrastructure with WEP >>> encryption, the >>> CAPWAP protocol does not add any new >> vulnerabilities. Derived >>> session keys between the STA and WTP can be >> compromised, resulting in >>> many well-documented attacks. Implementors SHOULD >> discourage the use >>> of WEP and encourage use of technically sound cryptographic >>> solutions >>> such as those in an IEEE 802.11 RSN. >>> >>> When used with IEEE 802.11 RSN security, the CAPWAP protocol >>> may introduce new vulnerabilities, depending on >> whether the link >>> security >>> (packet encryption and integrity verification) is >> provided by the >>> WTP or the AC. >>> When the link security function is provided by the AC, no new >>> security >>> concerns are introduced. >>> >>> However, when the WTP provides link security, a new >> vulnerability >>> will >>> exist when the following conditions are true: >>> >>> o the client is not the first to associate to the WTP/ESSID >>> (i.e. other clients are associated), and a GTK already >>> exists >>> >>> o traffic has been broadcast under the existing GTK >>> >>> Under these circumstances, the receive sequence >> counter (KeyRSC) >>> associated with the GTK is non-zero, but because the >> AC anchors the >>> 4-way handshake with the client, the exact value of >> the KeyRSC is not >>> known when the AC constructs the message containing the GTK. >>> The client will update its Key RSC value to the >> current valid KeyRSC >>> upon receipt of a valid multicast/broadcast message, >> but prior to >>> this, >>> previous multicast/broadcast traffic which was >> secured with the >>> existing >>> GTK may be replayed, and the client will accept this >> traffic as >>> valid. >>> >>> Typically, busy networks will produce numerous >> multicast or broadcast >>> frames per second, so the window of opportunity with >> respect to such >>> replay is expected to be very small. In most >> conditions, it is >>> expected that >>> replayed frames could be detected (and logged) by the WTP. >>> >>> The only way to completely close this window is to >> provide the >>> exact KeyRSC value in message 3 of the 4-way handshake; any >>> other approach simply narrows the window to varying >> degrees. Given >>> the low relative threat level this presents, the additional >>> complexity >>> introduced by providing the exact KeyRSC value is >> not warranted. >>> That >>> is, this specification provides for a calculated >> risk in this regard. >>> ==> >>> However, WTP implementations MAY provide the exact KeyRSC value >>> before forwarding message 3 of the 4-way handshake. >>> >>> --behcet >>> >>> >> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, >> please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> >> ---------------------------------------------------------------------- >>> -- >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 09:30:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVpmr-0002YG-Ca for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 09:30:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVpmo-0004cb-MK for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 09:30:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id CF26F430F45 for ; Fri, 6 Oct 2006 06:30:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 77D8E4300EA for ; Fri, 6 Oct 2006 06:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 60C7A430F30 for ; Fri, 6 Oct 2006 06:28:29 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by hermes.tigertech.net (Postfix) with ESMTP id ADC31430F2B for ; Fri, 6 Oct 2006 06:28:25 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20061006132818m1100rta3ve>; Fri, 6 Oct 2006 13:28:24 +0000 Message-ID: <452659F2.4020709@hyperthought.com> Date: Fri, 06 Oct 2006 06:28:18 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Cheng Hong References: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Hi Cheng, I think we have to make the security disclaimer no matter what, as there is a small window of opportunity unless you precisely synchronize the KeyRSC (which I think most agree is more complex than the resulting exposure warrants). As for setting the value, we could be rigid and require it to be set to zero, or we could be a little less precise, and leave some discretion here. The only requirement for interoperability is that the WTP *accept* any value, regardless of what its current KeyRSC value is (which is also true if we require "0"). Of course, if the AC sends the wrong value (i.e. a value greater than the actual KeyRSC), this will be a problem for the STA, and I think all would agree that this particular implementation is broken. On the other hand, strictly requiring the AC to send zero precludes a vendor of a "compliant" implementation from implementing some heuristic or workaround which narrows the window. Frankly, I'm not certain that any such workaround exists (short of some yet to be defined WTP/AC exchange), but I guess the question is, should we firmly slam this door shut, or should we specify only the necessary and sufficient text for interoperability? I think leaving the value unspecified might be a better approach. Scott Cheng Hong wrote: > Hi Charles and all, > > To specify a "default" value means specifying it to "zero". Otherwise, > it would not work. Say, the "default" value is set to 100, but the > actual sequence number used could be 50 at the moment. It means the STA > is not able to receive the Broadcast/Multicast packets for the next 50 > seqeunce count. > > So, I think we need some clarification on what is the decision here. Is > the decision now: > - No change to the protocol design except some security disclaimers. > And, specify a default value (0) to be used by the AC always. > > Or, We also allow: > - The WTP and AC can choose to implement info exchange methods (a simple > element to be specified in the draft). However, if some AC choose not to > support such mechanism, it will have to set the KeyRSC to zero. And a > security disclaimer to state what is the effect of setting the KeyRSC to > zero. > > cheers > > Cheng Hong > > > > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Friday, October 06, 2006 9:24 AM >> To: Dorothy Stanley >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> We'd definitely need to specify a value for keyRSC in the >> appropriate section. That would be in addition to the >> changes to the security considerations. Without specifying a >> default value, we could have interoperability issues between >> WTPs and ACs. >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> Dorothy Stanley wrote: >>> Behcet, >>> >>> My understanding of Scott's recommendations is that text be added >>> into the security considerations section. >>> - no additional CAPWAP protocol exchange between the WTP and AC >>> - no specification of setting the keyRSC value to 0. >>> >>> Without some specification in the protocol, how can the WTP provide >>> the KeyRSC info to the AC in a way that the AC is sure to >> understand? >>> The most we can say >>> with respect to the standard is that an AC implementation >> is free to >>> comes up with its own algorithm to set the keyRSC value. >>> >>> Dorothy >>> >>> On 10/5/06, *Behcet Sarikaya* >> > wrote: >>> >>> I agree with this and suggest adding Peter's fix as a >> possibility. >>> As far as interoperability is concerned, value 0 is >> interoperable >>> but not correct. If we allow implementations to snif in >> and modify >>> then any value should be acceptable which may be a concern for >>> interoperability? >>> >>> ----- Original Message ---- >>> From: Scott G. Kelly < s.kelly@ix.netcom.com >>> > >>> To: capwap > >>> Sent: Thursday, October 5, 2006 3:15:40 PM >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Following up once again - after careful review, I still >> agree with >>> Charles, and here's some suggested text for the >> security considerations: >>> 13.5. IEEE 802.11 Security >>> >>> When used with an IEEE 802.11 infrastructure with WEP >>> encryption, the >>> CAPWAP protocol does not add any new >> vulnerabilities. Derived >>> session keys between the STA and WTP can be >> compromised, resulting in >>> many well-documented attacks. Implementors SHOULD >> discourage the use >>> of WEP and encourage use of technically sound cryptographic >>> solutions >>> such as those in an IEEE 802.11 RSN. >>> >>> When used with IEEE 802.11 RSN security, the CAPWAP protocol >>> may introduce new vulnerabilities, depending on >> whether the link >>> security >>> (packet encryption and integrity verification) is >> provided by the >>> WTP or the AC. >>> When the link security function is provided by the AC, no new >>> security >>> concerns are introduced. >>> >>> However, when the WTP provides link security, a new >> vulnerability >>> will >>> exist when the following conditions are true: >>> >>> o the client is not the first to associate to the WTP/ESSID >>> (i.e. other clients are associated), and a GTK already >>> exists >>> >>> o traffic has been broadcast under the existing GTK >>> >>> Under these circumstances, the receive sequence >> counter (KeyRSC) >>> associated with the GTK is non-zero, but because the >> AC anchors the >>> 4-way handshake with the client, the exact value of >> the KeyRSC is not >>> known when the AC constructs the message containing the GTK. >>> The client will update its Key RSC value to the >> current valid KeyRSC >>> upon receipt of a valid multicast/broadcast message, >> but prior to >>> this, >>> previous multicast/broadcast traffic which was >> secured with the >>> existing >>> GTK may be replayed, and the client will accept this >> traffic as >>> valid. >>> >>> Typically, busy networks will produce numerous >> multicast or broadcast >>> frames per second, so the window of opportunity with >> respect to such >>> replay is expected to be very small. In most >> conditions, it is >>> expected that >>> replayed frames could be detected (and logged) by the WTP. >>> >>> The only way to completely close this window is to >> provide the >>> exact KeyRSC value in message 3 of the 4-way handshake; any >>> other approach simply narrows the window to varying >> degrees. Given >>> the low relative threat level this presents, the additional >>> complexity >>> introduced by providing the exact KeyRSC value is >> not warranted. >>> That >>> is, this specification provides for a calculated >> risk in this regard. >>> ==> >>> However, WTP implementations MAY provide the exact KeyRSC value >>> before forwarding message 3 of the 4-way handshake. >>> >>> --behcet >>> >>> >> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, >> please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >>> >>> >>> >>> >> ---------------------------------------------------------------------- >>> -- >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 09:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVqDN-0001iE-CX for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 09:58:13 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVq1J-0007Ru-Oe for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 09:45:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 665E6144804B for ; Fri, 6 Oct 2006 06:45:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 1E88F4300EA for ; Fri, 6 Oct 2006 06:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1289B39806B for ; Fri, 6 Oct 2006 06:41:03 -0700 (PDT) X-Greylist-Status: Sender first seen 15 days 04:53:54 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 68BB939802A for ; Fri, 6 Oct 2006 06:41:00 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.5]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1356280; Fri, 06 Oct 2006 09:40:59 -0400 In-Reply-To: <452659F2.4020709@hyperthought.com> References: <5F09D220B62F79418461A978CA0921BD01365FF5@pslexc01.psl.local> <452659F2.4020709@hyperthought.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0F430E55-EB5C-44B6-AB3A-75CDA737E558@thingmagic.com> From: Margaret Wasserman Date: Fri, 6 Oct 2006 09:39:05 -0400 To: Scott G Kelly X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap , Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 While I am not against leaving things open to more optimal implementations, I do think that we need to add some text to the protocol portion of the document (as well as the security considerations) to explain how this is handled. How about something like: The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 802.11i handshake, unless the AC has knowledge of a more optimal RSC value to use. Mechanisms for determining a more optimal RSC value are outside the scope of this specification. I do not think that we should simply say nothing and hope that implementors figure this out. Margaret --- On Oct 6, 2006, at 9:28 AM, Scott G Kelly wrote: > Hi Cheng, > > I think we have to make the security disclaimer no matter what, as > there > is a small window of opportunity unless you precisely synchronize the > KeyRSC (which I think most agree is more complex than the resulting > exposure warrants). > > As for setting the value, we could be rigid and require it to be > set to > zero, or we could be a little less precise, and leave some discretion > here. The only requirement for interoperability is that the WTP > *accept* > any value, regardless of what its current KeyRSC value is (which is > also > true if we require "0"). Of course, if the AC sends the wrong value > (i.e. a value greater than the actual KeyRSC), this will be a problem > for the STA, and I think all would agree that this particular > implementation is broken. > > On the other hand, strictly requiring the AC to send zero precludes a > vendor of a "compliant" implementation from implementing some > heuristic > or workaround which narrows the window. Frankly, I'm not certain that > any such workaround exists (short of some yet to be defined WTP/AC > exchange), but I guess the question is, should we firmly slam this > door > shut, or should we specify only the necessary and sufficient text for > interoperability? > > I think leaving the value unspecified might be a better approach. > > Scott > > Cheng Hong wrote: >> Hi Charles and all, >> >> To specify a "default" value means specifying it to "zero". >> Otherwise, >> it would not work. Say, the "default" value is set to 100, but the >> actual sequence number used could be 50 at the moment. It means >> the STA >> is not able to receive the Broadcast/Multicast packets for the >> next 50 >> seqeunce count. >> >> So, I think we need some clarification on what is the decision >> here. Is >> the decision now: >> - No change to the protocol design except some security disclaimers. >> And, specify a default value (0) to be used by the AC always. >> >> Or, We also allow: >> - The WTP and AC can choose to implement info exchange methods (a >> simple >> element to be specified in the draft). However, if some AC choose >> not to >> support such mechanism, it will have to set the KeyRSC to zero. And a >> security disclaimer to state what is the effect of setting the >> KeyRSC to >> zero. >> >> cheers >> >> Cheng Hong >> >> >> >> >>> -----Original Message----- >>> From: Charles Clancy [mailto:clancy@cs.umd.edu] >>> Sent: Friday, October 06, 2006 9:24 AM >>> To: Dorothy Stanley >>> Cc: capwap >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> We'd definitely need to specify a value for keyRSC in the >>> appropriate section. That would be in addition to the >>> changes to the security considerations. Without specifying a >>> default value, we could have interoperability issues between >>> WTPs and ACs. >>> >>> -- >>> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >>> >>> Dorothy Stanley wrote: >>>> Behcet, >>>> >>>> My understanding of Scott's recommendations is that text be added >>>> into the security considerations section. >>>> - no additional CAPWAP protocol exchange between the WTP and AC >>>> - no specification of setting the keyRSC value to 0. >>>> >>>> Without some specification in the protocol, how can the WTP provide >>>> the KeyRSC info to the AC in a way that the AC is sure to >>> understand? >>>> The most we can say >>>> with respect to the standard is that an AC implementation >>> is free to >>>> comes up with its own algorithm to set the keyRSC value. >>>> >>>> Dorothy >>>> >>>> On 10/5/06, *Behcet Sarikaya* >>> > wrote: >>>> >>>> I agree with this and suggest adding Peter's fix as a >>> possibility. >>>> As far as interoperability is concerned, value 0 is >>> interoperable >>>> but not correct. If we allow implementations to snif in >>> and modify >>>> then any value should be acceptable which may be a concern for >>>> interoperability? >>>> >>>> ----- Original Message ---- >>>> From: Scott G. Kelly < s.kelly@ix.netcom.com >>>> > >>>> To: capwap > >>>> Sent: Thursday, October 5, 2006 3:15:40 PM >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>>> Considerations >>>> >>>> Following up once again - after careful review, I still >>> agree with >>>> Charles, and here's some suggested text for the >>> security considerations: >>>> 13.5. IEEE 802.11 Security >>>> >>>> When used with an IEEE 802.11 infrastructure with WEP >>>> encryption, the >>>> CAPWAP protocol does not add any new >>> vulnerabilities. Derived >>>> session keys between the STA and WTP can be >>> compromised, resulting in >>>> many well-documented attacks. Implementors SHOULD >>> discourage the use >>>> of WEP and encourage use of technically sound cryptographic >>>> solutions >>>> such as those in an IEEE 802.11 RSN. >>>> >>>> When used with IEEE 802.11 RSN security, the CAPWAP protocol >>>> may introduce new vulnerabilities, depending on >>> whether the link >>>> security >>>> (packet encryption and integrity verification) is >>> provided by the >>>> WTP or the AC. >>>> When the link security function is provided by the AC, no >>>> new >>>> security >>>> concerns are introduced. >>>> >>>> However, when the WTP provides link security, a new >>> vulnerability >>>> will >>>> exist when the following conditions are true: >>>> >>>> o the client is not the first to associate to the WTP/ESSID >>>> (i.e. other clients are associated), and a GTK already >>>> exists >>>> >>>> o traffic has been broadcast under the existing GTK >>>> >>>> Under these circumstances, the receive sequence >>> counter (KeyRSC) >>>> associated with the GTK is non-zero, but because the >>> AC anchors the >>>> 4-way handshake with the client, the exact value of >>> the KeyRSC is not >>>> known when the AC constructs the message containing the GTK. >>>> The client will update its Key RSC value to the >>> current valid KeyRSC >>>> upon receipt of a valid multicast/broadcast message, >>> but prior to >>>> this, >>>> previous multicast/broadcast traffic which was >>> secured with the >>>> existing >>>> GTK may be replayed, and the client will accept this >>> traffic as >>>> valid. >>>> >>>> Typically, busy networks will produce numerous >>> multicast or broadcast >>>> frames per second, so the window of opportunity with >>> respect to such >>>> replay is expected to be very small. In most >>> conditions, it is >>>> expected that >>>> replayed frames could be detected (and logged) by the WTP. >>>> >>>> The only way to completely close this window is to >>> provide the >>>> exact KeyRSC value in message 3 of the 4-way handshake; any >>>> other approach simply narrows the window to varying >>> degrees. Given >>>> the low relative threat level this presents, the additional >>>> complexity >>>> introduced by providing the exact KeyRSC value is >>> not warranted. >>>> That >>>> is, this specification provides for a calculated >>> risk in this regard. >>>> ==> >>>> However, WTP implementations MAY provide the exact KeyRSC value >>>> before forwarding message 3 of the 4-way handshake. >>>> >>>> --behcet >>>> >>>> >>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, >>> please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>>> >>>> >>>> >>>> >>>> >>> -------------------------------------------------------------------- >>> -- >>>> -- >>>> >>>> _________________________________________________________________ >>>> To unsubscribe or modify your subscription options, please visit: >>>> http://lists.frascone.com/mailman/listinfo/capwap >>>> >>>> Archives: http://lists.frascone.com/pipermail/capwap >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 13:39:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtfF-0001mM-MS for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 13:39:13 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVtf9-0000bx-TD for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 13:39:13 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 62A7A39806E for ; Fri, 6 Oct 2006 10:38:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D65604300EA for ; Fri, 6 Oct 2006 10:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AABFC144804A for ; Fri, 6 Oct 2006 10:36:38 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id 21DD71448046 for ; Fri, 6 Oct 2006 10:36:33 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so1199955nfb for ; Fri, 06 Oct 2006 10:36:32 -0700 (PDT) Received: by 10.49.90.4 with SMTP id s4mr5739375nfl; Fri, 06 Oct 2006 10:36:32 -0700 (PDT) Received: by 10.49.42.6 with HTTP; Fri, 6 Oct 2006 10:36:31 -0700 (PDT) Message-ID: <5bfe7a820610061036r838992cq8187aa9f08202656@mail.gmail.com> Date: Fri, 6 Oct 2006 10:36:31 -0700 From: "Dorothy Stanley" To: young@huawei-3com.com In-Reply-To: <001201c6e90f$d9f63390$5817120a@china.huawei.com> MIME-Version: 1.0 References: <001201c6e90f$d9f63390$5817120a@china.huawei.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1829666503==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.0 (+) X-Scan-Signature: 2df02f1a0db129c5d94869f6959903ec --===============1829666503== Content-Type: multipart/alternative; boundary="----=_Part_34322_30513108.1160156191705" ------=_Part_34322_30513108.1160156191705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard, Notes inline. Thanks, Dorothy On 10/5/06, young wrote: > > Hi, Dorothy: > Thanks for your proposed resolutions. You're welcome. > In your Proposed Resolution, you mentioned that " While there may be > common > elements, it's not clear that the > CAPWAP base specification should take on the task of extracting/unifying > the > common elements > across wireless systems." > If it is not clear, I suggest that WG or mailing list had better take time > to make it clear. > Otherwise, how to decide what info should put in the base part if base > part > scope is not clear? > I thought a clear and common understanding of base part's rule and scope > is > very important for > base part separation from wireless specific binding. I completely agree that the WG needs to clarify on the base vs binding division of labor. The current draft, with the exception (largely) of the WTP Radio information element, puts the wireless-technology specific elements in the binding rather than the base protocol. This is the approach I followed in developing the proposed resolutions. Most of the CAPWAP level message elements are used to establish and manage the session between the AC and WTP. Some message elements, for example the WTP radio statistics and Decryption Error Report are borderline and could arguably move to the binding; but they are not technology specific - e.g. 802.11 vs 802.16. I give my comment for the proposed resolutions to issue 204. > 1) 4.4.38. WTP Radio Information > Sorry for I don't make issue clear in my comment. > I suggest that WTP Radio Information could be kept in the current section > 4.4. > While 802.11a/b/g/n these kinds info could be defined by 802.11binding. > We could add a Wireless binding identifier in the WTP Radio Information. > By this way, we could identify any Wireless binding's radio type > definition. > The Wireless binding identifier could be probably eventually managed by > IANA. > No matter what method will by used for Wireless binding identifier, it is > a > key > Point to help base protocol to separate any wireless binding. > I thought that Wireless binding identifier method will be a common issue. I considered several options on this one. (a) Have both a CAPWAP base element that included the "first level" radio information: 802.11, 802.15, 802.16, 802.22, EPCGlobal, etc, AND specific binding elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first levels churn internally, the base spec isn't impacted. But if the detailed level is provided, is the higher level even needed? (b) Have only binding-specific elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. The binding will need to specify that the element must be included in the control messages that the previous CAPWAP level element was in. (c) keeping the definition as is. Didn't do this, since the change did make the CAPWAP base spec even more wireless-technology agnostic. The WTP Radio information message element includes only 2 fields, the radio type and the radio information. If we want radio specific info in the base spec, then we can leave it there, and add the 802.11,15,16,etc values - and require that the capwap base spec change as new values are added, or we can move the radio-type info to the binding, and then as the wireless technology evolves, only the binding doc has to change. 2) 11.9.18. IEEE 802.11 Tx Power > I suggest we could define a "WTP Radio configuration" TLV. > By using wireless binding identifier, there will be no conflict with > Dot11PhyTxPowerEntry MIB table. > Channel also could be put here. > As AC will configure AP's RF parameter (AC to AP), and AP will report its > current > Configuration to AC, the TLV will be carried in the configuration message > in > bi-direction. > More TLV could be added into the TLV if it is required. > > |---------|-------------|-----------------------------|--------------|------ > ---|---------| > | Radio ID| country code| wireless binding identifier | Max Tx Power |Tx > Power | Channel | > > |---------|-------------|-----------------------------|--------------|------ > -- |----------| > As Tx power these kind info will not be carried in the discovery phase, I > suggest that "WTP Radio configuration" > is required instead of extenuation of " WTP Radio Information". Ok, so the proposal is to have a new base-spec-level message element, that incorporates a binding-defined-identifier for Radio Configuration. This would require the TX power fields to have the same units across wireless types. This level of configuration is currenly in the binding and my preference would be to leave it there. Regards > Richard (shiyang) > > > > > > From: Dorothy Stanley (dstanley1389gmail.com) > Date: Wed, 4 Oct 2006 09:08:21 -0700 (PDT) > All, > > Issue 204 and proposed resolutions to its components are > listed below. > > Comments please. > > Thanks, > > Dorothy > > > ---------------------------------------------------------------------------- > --------------------------------------------- > 1) 4.4.38. WTP Radio Information > Comment: As the section should be work for any wireless implement, I > suggest > the > following value should be moved to 802.11 binding. The value should be > defined by wireless > technology binding. > 1 - 802.11b: An IEEE 802.11b radio. > 2 - 802.11a: An IEEE 802.11a radio. > 4 - > 802.11g: An IEEE 802.11g radio. > 8 - 802.11n: An IEEE 802.11n radio. > Proposed Resolution: Move the "need to know" the 802.11 technology > specific > radio types to the 802.11 binding, modifying the WTP Radio Information > element > as follows: > IEEE 802.11 Radio Information > The IEEE 802.11 radio information message element is used to > communicate > the > radio information for each IEEE 802.11 radio on the WTP. The Discovery > Request message MUST > include one such message element per radio in the WTP. The Radio-Type > field is used by the > AC to determine which 802.11 technology specific binding is to be used > with the WTP. > The value contains two fields, as shown. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | Radio Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio Type | > +-+-+-+-+-+-+-+-+ > > Type: 38 for WTP Radio Information > Length: 5 > Radio ID: The Radio Identifier, which typically refers to an > interface index on the WTP > Radio Type: The type of IEEE 802.11 radio present. > The following values are supported: > 1 - 802.11b: An IEEE 802.11b radio. > 2 - 802.11a: An IEEE 802.11a radio. > 4 - > 802.11g: An IEEE 802.11g radio. > 8 - 802.11n: An IEEE 802.11n radio. > 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types > indicated are supported in the WTP. > > > ---------------------------------------------------------------------------- > --------------- > 2) 11.9.18. IEEE 802.11 Tx Power > Comment: I think it could be moved to the section 4.4, as channel and Tx > power are > common parameters for RF management. > Proposed Resolution: No change to the draft. Agree with the commenter > > that TX power level is a common parameter for RF management; however the > IEEE 802.11 TX Power field values are defined as being the values > defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not > extensible to other bindings. Expect that each binding will define > values relative to its definitions. > > --------------------------------------------------------------------------- > 3) Add "WTP radio channel" > Comment: As per 2), we could define a TLV to report current channel (AP to > AC) or to > configure channel (AC to AP). > Now,. 11.9.12. IEEE 802.11 OFDM Control and 11.9.5. IEEE 802.11 Direct > Sequence Control has channel configuration information. > But I think that a specific TLV for it is better. By this way, 4.4 will > provide > more common parameter for any wireless technology. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Radio ID | Reserved | Current Channel | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The commenter suggests the following: > 3) Add "WTP RF Radio configuration" in the section 4.4 > The Tx power, radio type, channel assignment and so on these kind > parameter > are common for any kind wireless binding. > I suggest CAPWAP define it in the base protocol part. > Although the protocol already has "WTP Radio Information", while Tx power > these kind Info should not be sent > during discovery and join phase. So the separated "WTP RF Radio > configuration" is better. > If keep them in one, which element will be mandatory in what kind message > should be suggested by protocol. > The TLV of "WTP RF Radio configuration" will include radio ID, radio type, > Tx power, Channel, country code and so on. > For any binding, we use Wireless binding identifier to suggest them. > The "WTP RF Radio configuration" could be sent by bi-direction, by this > way, > AC could configure WTP's RF parameter > and know current configuration on the WTP radio. > If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE > 802.11 OFDM Control "and "11.9.5. > IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE > 802.11 related element. > Proposed Resolution: No change to the draft. While there may be common > elements, it's not clear that the > CAPWAP base specification should take on the task of extracting/unifying > the > common elements > across wireless systems. > > > ---------------------------------------------------------------------------- > -------- > 4) 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indications > > Comment: I think it could be moved to the section 4.4, it could be a > common > event for > any wireless technology. > Proposed Resolution: No change to the draft. Agree with the commmenter > that a fail alarm indication could be a common event for > any wireless technology. Each radio technology may want to > have additional information reported with the event however. Not > sure there is sufficient benefit shown for a common defintiion at this > point. > > ---------------------------------------------------------------------------- > ----------- > > 5) 11.9.1. IEEE 802.11 Add WLAN > How about we rename "WLAN" as wireless service? By this way, we could > achieve > abstract while make it work for most wireless technology. > If it is ok, we could define "add wireless service, delete wireless > service, > > update wireless service" in the section > 4.4. > Any wireless technology could add its specific parameter in the binding > section. > > The commenter suggests a solution: > 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", > and put it in the section 4.4 > The glossary "wireless service" will be more abstract than "WLAN". > Refer to current "IEEE 802.11 add WLAN" format, we could keep > Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode > these kinds common element (more element maybe put here). > While for any specific wireless binding could follow the Wireless binding > identifier. > The Wireless binding identifier will identify what kinds binding are using > ( Probably eventually managed by IANA) > Proposed resolution: Close, no change to the draft. > The IEEE 802.11 Add WLAN message element is 802.11 specific and used > together with several other message elements to define a WLAN service. > The intent of the comment seems to be to have the ability in the > CAPWAP protocol to add a generic wireless service. It's not clear that > there are enough additional elements common to multiple wireless > services to have a separate CAPWAP level element at this at this time. > > ---------------------------------------------------------------------------- > ---- > 6) 11.9.22. IEEE 802.11 WTP Quality of Service > > As per 5), I think we could define "WTP Quality of Service"in the section > 4.4. Radio ID, Tag Packets and Queue Depth could be defined in the "WTP > Quality of > Service". > > While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of > Service. > The commenter suggests the following solution: > 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of > Service" > Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the > "WTP > Quality of Service". > For any binding, we use Wireless binding identifier to suggest them. > For Tag Packets, if IANA already have some kind assignment, it will be > great. > Proposed resolution: Close, no change to the draft. > The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed > to convey the CWMin , CWMax and other very specific 802.11 data. > The intent of the comment seems to be to have the ability in the > CAPWAP protocol to include a "generic QOS" message element. It's not clear > that > there are enough elements common to multiple wireless > services to have a separate CAPWAP level element at this at this time. > There is at least 1 - the Tag packets type, which each binding can inlcude > if > desired. > > ---------------------------------------------------------------------------- > ------------------------------------------------------ > 7. Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section > 4.4 > > Comment: Most case, the wireless binding will be link layer protocol, I > think most the element in the "IEEE 802.11 Statistics" > could be put on the section 4.4, except the element like "RTS Success > Count" > and so on. > For any binding, we use Wireless binding identifier to suggest them. > Proposed resolution: No change to the draft. Agree with the commenter > that many of the statistics are common across wireless technologies. > However the IEEE 802.11 Statistics values are defined as being the values > defined in various IEEE 802.11 MIB variables and thus are not extensible > to > other bindings. Expect that each binding will define values relative to > its > definitions. > > On 9/28/06, young wrote: > Hi Pat and all, > I used to raise issue #204, and here intend to give solution. > 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", > and put it in the section 4.4 > The glossary "wireless service" will be more abstract than "WLAN". > Refer to current "IEEE 802.11 add WLAN" format, we could keep > Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode > these kinds common element (more element maybe put here). > While for any specific wireless binding could follow the Wireless binding > identifier. > The Wireless binding identifier will identify what kinds binding are using > ( Probably eventually managed by IANA) > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Radio ID | WLAN ID | MAC Mode | Tunnel > Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Wireless binding identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update > WLAN". > > 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of > Service" > Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the > "WTP > Quality of Service". > For any binding, we use Wireless binding identifier to suggest them. > For Tag Packets, if IANA already have some kind assignment, it will be > great. > > 3) Add "WTP RF Radio configuration" in the section 4.4 > The Tx power, radio type, channel assignment and so on these kind > parameter > are common for any kind wireless binding. > I suggest CAPWAP define it in the base protocol part. > Although the protocol already has "WTP Radio Information", while Tx power > these kind Info should not be sent > during discovery and join phase. So the separated "WTP RF Radio > configuration" is better. > If keep them in one, which element will be mandatory in what kind message > should be suggested by protocol. > The TLV of "WTP RF Radio configuration" will include radio ID, radio type, > Tx power, Channel, country code and so on. > For any binding, we use Wireless binding identifier to suggest them. > The "WTP RF Radio configuration" could be sent by bi-direction, by this > way, > AC could configure WTP's RF parameter > and know current configuration on the WTP radio. > If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE > 802.11 OFDM Control "and "11.9.5. > IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE > 802.11 related element. > 4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section > 4.4 > Most case, the wireless binding will be link layer protocol, I think most > the element in the "IEEE 802.11 Statistics" > could be put on the section 4.4, except the element like "RTS Success > Count" > and so on. > For any binding, we use Wireless binding identifier to suggest them. > > Any way, I thought many TLV will change their location as new CAPWAP will > be > divided into two parts. > > Cheers > > Richard (Shiyang) > > > > ------=_Part_34322_30513108.1160156191705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Richard,

Notes inline.

Thanks,

Dorothy

On 10/5/06, young <young@huawei-3com.com> wrote:
Hi, Dorothy:
Thanks for your proposed resolutions. 
You're welcome.
In your Proposed Resolution, you mentioned that " While there may be common
elements, it's not clear that the
CAPWAP base specification should take on the task of extracting/unifying the
common elements
across wireless systems."
If it is not clear, I suggest that WG or mailing list had better take time
to make it clear.
Otherwise, how to decide what info should put in the base part if base part
scope is not clear?
I thought a clear and common understanding of base part's rule and scope is
very important for
base part separation from wireless specific binding.

I completely agree that the WG needs to clarify on the base vs binding
division of labor.
The current draft, with the exception (largely) of  the WTP Radio information element, puts the
wireless-technology specific elements in the binding rather than the base protocol. This is
the approach I followed in developing the proposed resolutions.
Most of the CAPWAP level message elements are used to establish and manage the
session between the AC and WTP.  Some message elements, for example
 the WTP radio statistics and Decryption Error Report are borderline and could arguably
move to the binding; but they are not technology specific - e.g. 802.11 vs 802.16.


I give my comment for the proposed resolutions to issue 204.
1) 4.4.38.  WTP Radio Information
Sorry for I don't make issue clear in my comment.
I suggest that WTP Radio Information could be kept in the current section
4.4.
While 802.11a/b/g/n these kinds info could be defined by 802.11binding.
We could add a Wireless binding identifier in the WTP Radio Information.
By this way, we could identify any Wireless binding's radio type definition.
The Wireless binding identifier could be probably eventually managed by
IANA.
No matter what method will by used for Wireless binding identifier, it is a
key
Point to help base protocol to separate any wireless binding.
I thought that Wireless binding identifier method will be a common issue.

I considered several options on this one.
(a) Have both a CAPWAP
base element that included the "first level" radio information: 802.11, 802.15,
802.16, 802.22, EPCGlobal, etc, AND specific binding elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first
levels churn internally, the base spec isn't impacted. But if the detailed level
is provided, is the higher level even needed?

(b) Have  only binding-specific  elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc.
The binding will need to specify that the element must be included in the
control messages that the previous CAPWAP level element was in.

(c) keeping the definition as is. Didn't do this, since the change
did make the CAPWAP base spec even more wireless-technology agnostic.

The WTP Radio information message element includes only 2 fields, the
radio type and the radio information. If we want radio specific info in the
base spec, then we can leave it there, and add the 802.11,15,16,etc values - and
require that the capwap base spec change as new values are added, or we can
move the radio-type info to the binding, and then as the wireless technology
evolves, only the binding doc has to change. 

2) 11.9.18.  IEEE 802.11 Tx Power
I suggest we could define a "WTP Radio configuration" TLV.
By using wireless binding identifier, there will be no conflict with
Dot11PhyTxPowerEntry MIB table.
Channel also could be put here.
As AC will configure AP's RF parameter (AC to AP), and AP will report its
current
Configuration to AC, the TLV will be carried in the configuration message in
bi-direction.
More TLV could be added into the TLV if it is required.
|---------|-------------|-----------------------------|--------------|------
---|---------|
| Radio ID| country code| wireless binding identifier | Max Tx Power |Tx
Power | Channel  |
|---------|-------------|-----------------------------|--------------|------
-- |----------|
As Tx power these kind info will not be carried in the discovery phase, I
suggest that "WTP Radio configuration"
is required instead of extenuation of " WTP Radio Information".

Ok, so the proposal is to have a new base-spec-level message element,
that incorporates a binding-defined-identifier for Radio Configuration.
This would require the TX power fields to have the same units across
wireless types. This level of configuration is currenly in the binding and
my preference would be to leave it there.

Regards
Richard (shiyang)





From: Dorothy Stanley ( dstanley1389gmail.com)
Date: Wed, 4 Oct 2006 09:08:21 -0700 (PDT)
All,

Issue 204 and proposed resolutions to its components are
listed below.

Comments please.

Thanks,

Dorothy

----------------------------------------------------------------------------
---------------------------------------------
1) 4.4.38.  WTP Radio Information
Comment: As the section should be work for any wireless implement, I suggest
the
following value should be moved to 802.11 binding. The value should be
defined by wireless
technology binding.
      1 - 802.11b:  An IEEE 802.11b radio.
      2 - 802.11a:  An IEEE 802.11a radio.
      4 -
802.11g:  An IEEE 802.11g radio.
      8 - 802.11n:  An IEEE 802.11n radio.
Proposed Resolution: Move the "need to know" the 802.11 technology specific
radio types to the 802.11 binding, modifying the WTP Radio Information
element
as follows:
IEEE 802.11 Radio Information
   The IEEE 802.11 radio information message element is used to communicate
the
   radio information for each IEEE 802.11 radio on the WTP.  The Discovery
Request message MUST
   include one such message element per radio in the WTP.  The Radio-Type
field is used by the
   AC to determine which 802.11 technology specific binding is to be used
with the WTP.
   The value contains two fields, as shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |           Radio Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | Radio Type    |
     +-+-+-+-+-+-+-+-+

   Type:  38 for WTP Radio Information
   Length:  5
   Radio ID:  The Radio Identifier, which typically refers to an
      interface index on the WTP
   Radio Type:  The type of IEEE 802.11 radio present.
      The following values are supported:
      1 - 802.11b:  An IEEE 802.11b radio.
      2 - 802.11a:  An IEEE 802.11a radio.
      4 -
802.11g:  An IEEE 802.11g radio.
      8 - 802.11n:  An IEEE 802.11n radio.
      0xOF - 802.11b, 802.11a, 802.11g and 802.11n :  The 4 radio types
         indicated are supported in the WTP.

----------------------------------------------------------------------------
---------------
2) 11.9.18.  IEEE 802.11 Tx Power
Comment: I think it could be moved to the section 4.4, as channel and Tx
power are
common parameters for RF management.
Proposed Resolution: No change to the draft. Agree with the commenter

that TX power level is a common parameter for RF management; however the
IEEE 802.11 TX Power field values are defined as being the values
defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not
extensible to other bindings. Expect that each binding will define
values relative to its definitions.
---------------------------------------------------------------------------
3)  Add "WTP radio channel"
Comment: As per 2), we could define a TLV to report current channel (AP to
AC) or to
configure channel (AC to AP).
Now,. 11.9.12.  IEEE 802.11 OFDM Control and 11.9.5.  IEEE 802.11 Direct
Sequence Control has channel configuration information.
But I think that a specific TLV for it is better. By this way, 4.4 will
provide
more common parameter for any wireless technology.

     0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |    Radio ID   |    Reserved   |        Current Channel       |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The commenter suggests the following:
3) Add "WTP RF Radio configuration" in the section 4.4
The Tx power, radio type, channel assignment and so on these kind parameter
are common for any kind wireless binding.
I suggest CAPWAP define it in the base protocol part.
Although the protocol already has "WTP Radio Information", while Tx power
these kind Info should not be sent
during discovery and join phase. So the separated "WTP RF Radio
configuration" is better.
If keep them in one, which element will be mandatory in what kind message
should be suggested by protocol.
The TLV of "WTP RF Radio configuration" will include radio ID, radio type,
Tx power, Channel, country code and so on.
For any binding, we use Wireless binding identifier to suggest them.
The "WTP RF Radio configuration" could be sent by bi-direction, by this way,
AC could configure WTP's RF parameter
and know current configuration on the WTP radio.
If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE
802.11 OFDM Control "and "11.9.5 .
IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE
802.11 related element.
Proposed Resolution: No change to the draft. While there may be common
elements, it's not clear that the
CAPWAP base specification should take on the task of extracting/unifying the
common elements
across wireless systems.

----------------------------------------------------------------------------
--------
4) 11.9.24.  IEEE 802.11 WTP Radio Fail Alarm Indications

Comment: I think it could be moved to the section 4.4, it could be a common
event for
any wireless technology.
Proposed Resolution: No change to the draft. Agree with the commmenter
that a fail alarm indication could be a common event for
any wireless technology. Each radio technology may want to
have additional information reported with the event however. Not
sure there is sufficient benefit shown for a common defintiion at this
point.
----------------------------------------------------------------------------
-----------

5) 11.9.1.  IEEE 802.11 Add WLAN
How about we rename "WLAN" as wireless service? By this way, we could
achieve
abstract while make it work for most wireless technology.
If it is ok, we could define "add wireless service, delete wireless service,

update wireless service" in the section
4.4.
Any wireless technology could add its specific parameter in the binding
section.

The commenter suggests a solution:
1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service",
and put it in the section 4.4
The glossary "wireless service" will be more abstract than "WLAN".
Refer to current "IEEE 802.11 add WLAN" format, we could keep
Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode
these kinds common element (more element maybe put here).
While for any specific wireless binding could follow the Wireless binding
identifier.
The Wireless binding identifier will identify what kinds binding are using
( Probably eventually managed by IANA)
Proposed resolution: Close, no change to the draft.
The IEEE 802.11 Add WLAN message element is 802.11 specific and used
together with several other message elements to define a WLAN service.
The intent of the comment seems to be to have the ability in the
CAPWAP protocol to add a generic wireless service. It's not clear that
there are enough additional elements common to multiple wireless
services to have a separate CAPWAP level element at this at this time.
----------------------------------------------------------------------------
----
6) 11.9.22.  IEEE 802.11 WTP Quality of Service

As per 5), I think we could define "WTP Quality of Service"in the section
4.4. Radio ID, Tag Packets and Queue Depth could be defined in the "WTP
Quality of
Service".

While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of
Service.
The commenter suggests the following solution:
2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of
Service"
Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP
Quality of Service".
For any binding, we use Wireless binding identifier to suggest them.
For Tag Packets, if IANA already have some kind assignment, it will be
great.
Proposed resolution: Close, no change to the draft.
The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed
to convey the CWMin , CWMax and other very specific 802.11 data.
The intent of the comment seems to be to have the ability in the
CAPWAP protocol to include a "generic QOS" message element. It's not clear
that
there are enough elements common to multiple wireless
services to have a separate CAPWAP level element at this at this time.
There is at least 1 - the Tag packets type, which each binding can inlcude
if
desired.
----------------------------------------------------------------------------
------------------------------------------------------
7. Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4

Comment: Most case, the wireless binding will be link layer protocol, I
think most the element in the "IEEE 802.11 Statistics"
could be put on the section 4.4, except the element like "RTS Success Count"
and so on.
For any binding, we use Wireless binding identifier to suggest them.
Proposed resolution: No change to the draft. Agree with the commenter
that many of the statistics are common across wireless technologies.
However the IEEE 802.11 Statistics values are defined as being the values
defined in various IEEE 802.11 MIB variables and thus are not extensible to
other bindings. Expect that each binding will define values relative to its
definitions.

On 9/28/06, young <young [at] huawei-3com.com> wrote:
Hi Pat and all,
I used to raise issue #204, and here intend to give solution.
1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service",
and put it in the section 4.4
The glossary "wireless service" will be more abstract than "WLAN".
Refer to current "IEEE 802.11 add WLAN" format, we could keep
Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode
these kinds common element (more element maybe put here).
While for any specific wireless binding could follow the Wireless binding
identifier.
The Wireless binding identifier will identify what kinds binding are using
( Probably eventually managed by IANA)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | MAC Mode | Tunnel
Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wireless binding identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN".

2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of
Service"
Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP
Quality of Service".
For any binding, we use Wireless binding identifier to suggest them.
For Tag Packets, if IANA already have some kind assignment, it will be
great.

3) Add "WTP RF Radio configuration" in the section 4.4
The Tx power, radio type, channel assignment and so on these kind parameter
are common for any kind wireless binding.
I suggest CAPWAP define it in the base protocol part.
Although the protocol already has "WTP Radio Information", while Tx power
these kind Info should not be sent
during discovery and join phase. So the separated "WTP RF Radio
configuration" is better.
If keep them in one, which element will be mandatory in what kind message
should be suggested by protocol.
The TLV of "WTP RF Radio configuration" will include radio ID, radio type,
Tx power, Channel, country code and so on.
For any binding, we use Wireless binding identifier to suggest them.
The "WTP RF Radio configuration" could be sent by bi-direction, by this way,
AC could configure WTP's RF parameter
and know current configuration on the WTP radio.
If this way, current "11.9.18 . IEEE 802.11 Tx Power", "11.9.12. IEEE
802.11 OFDM Control "and "11.9.5.
IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE
802.11 related element.
4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section
4.4
Most case, the wireless binding will be link layer protocol, I think most
the element in the "IEEE 802.11 Statistics"
could be put on the section 4.4, except the element like "RTS Success Count"
and so on.
For any binding, we use Wireless binding identifier to suggest them.

Any way, I thought many TLV will change their location as new CAPWAP will be
divided into two parts.

Cheers

Richard (Shiyang)




------=_Part_34322_30513108.1160156191705-- --===============1829666503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1829666503==-- From rossignmathie@ecsh.net Fri Oct 06 14:02:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVu1J-00067A-VM for capwap-archive@ietf.org; Fri, 06 Oct 2006 14:02:01 -0400 Received: from 88-136-169-65.adslgp.cegetel.net ([88.136.169.65] helo=ecsh.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVu1I-0003eA-FD for capwap-archive@ietf.org; Fri, 06 Oct 2006 14:02:01 -0400 Message-ID: <000001c6e971$41b82040$22cca8c0@agtsbas> Reply-To: "Eirian Gooch" From: "Eirian Gooch" To: capwap-archive@ietf.org Subject: Re: Hi Date: Fri, 6 Oct 2006 11:00:06 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6E936.95594840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6E936.95594840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VrAGRA 50 % less http://www.cuifendinkasdelio.com =20 _____ =20 Get it, Fido, I whispered. Aida reacted instantly; our plastic pet as he ran back the way he had come. He nodded acceptance. I never did enjoy retirement. Whats next, ------=_NextPart_000_0001_01C6E936.95594840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VrAGRA 50 % less

 

Get it, Fido, I whispered. Aida reacted instantly; our plastic = pet
as he ran back the way he had come.
He nodded acceptance. I never did enjoy retirement. Whats = next,

------=_NextPart_000_0001_01C6E936.95594840-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 16:18:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVw9m-0003hz-SO for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 16:18:54 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVw9j-00078Z-CU for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 16:18:54 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9FC98398075 for ; Fri, 6 Oct 2006 13:18:44 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 90C284300EA for ; Fri, 6 Oct 2006 13:18:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 46B5E1448050 for ; Fri, 6 Oct 2006 13:18:14 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 7DCE61448060 for ; Fri, 6 Oct 2006 13:18:05 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2006 13:17:52 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="328919463:sNHT6572992852" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96KHpIX029437 for ; Fri, 6 Oct 2006 13:17:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k96KHkOd010237 for ; Fri, 6 Oct 2006 13:17:51 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Oct 2006 13:17:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 13:17:43 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0222B846@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: WTP restarts after firmware download Thread-Index: AcbphHq1yfoxv0H0T+yD7g0I0tqT9A== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 06 Oct 2006 20:17:44.0012 (UTC) FILETIME=[7B4B38C0:01C6E984] Authentication-Results: sj-dkim-5.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Issue: WTP restarts after firmware download X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I believe that the expected resolution to Issue 200 (Trickle Firmware Download) is to provide for download of firmware while the WTP is in the RUN state and servicing wireless clients. In this case, it may be expected that the download of firmware to a large group of WTPs will not conclude simultaneously. In fact, one operational scenario is to download new firmware versions to small groups of WTPs, only downloading to new groups of WTPs after the prior group has completed. It will be desirable for the WTPs that have concluded the firmware download to continue in the RUN state, until a RESET message is received. This will allow the orderly restart of the WTPs, so that all come up on the same (or compatible) firmware version. There are two problems that this introduces. First, a WTP may spontaneously restart, due to removal and reapplication of power or other reasons outside of the control of the CAPWAP protocol. Second, the WTP may need to be restarted under the control of the CAPWAP protocol, but continue using the earlier version of firmware. I propose that we add a function to CAPWAP to control the version of firmware that is used when a WTP restarts. Some alternatives are the following. 1. Require the WTP to maintain a nonvolatile "last boot version" that is used as the source of the version of firmware for the next boot and add a new configure message element to change this value. 2. Require that the WTP always restart on the last firmware version it booted from and add a firmware version message element to the Reset Request message to cause the WTP to restart using a different version. I am sure there are other ways to accomplish this and welcome other suggestions. -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 16:23:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwEQ-0005dJ-Hj for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 16:23:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVwEO-0008UX-U6 for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 16:23:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A936398075 for ; Fri, 6 Oct 2006 13:23:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 0E61E4300EA for ; Fri, 6 Oct 2006 13:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CEE9B1448033 for ; Fri, 6 Oct 2006 13:22:32 -0700 (PDT) Received: from mgw-ext14.nokia.com (mgw-ext14.nokia.com [131.228.20.173]) by hermes.tigertech.net (Postfix) with ESMTP id EF4911448043 for ; Fri, 6 Oct 2006 13:22:29 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k96KMOTA004584; Fri, 6 Oct 2006 23:22:25 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 23:22:24 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 15:22:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 13:22:20 -0700 Message-ID: <893AE265F4ADF94AB7FB26D31A788E4102B58C40@mvebe101.NOE.Nokia.com> In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E41029E0CCC@mvebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Final Consensus determination on Split CAPWAP draft Thread-Index: AcbY82fx0AwmEjxkSO+bTrWL20FI8gQkMEuw From: To: , X-OriginalArrivalTime: 06 Oct 2006 20:22:22.0360 (UTC) FILETIME=[2133C180:01C6E985] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE, NO_REAL_NAME X-Spam-Level: Cc: margaret@thingmagic.com Subject: [Capwap] Final Consensus determination on Split CAPWAP draft X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0376078129==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 This is a multi-part message in MIME format. --===============0376078129== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E985.209EE32C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E985.209EE32C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Based on overwhelming support for the Split CAPWAP draft, the Chairs are declaring WG consensus on splitting the current CAPWAP protocol draft into a base draft and an 802.11 binding draft. The Editors will be submitting Version 00 of the 802.11 binding draft by the October 16th IETF 67 draft deadline. Thanks to everyone who submitting their opinions on this consensus call. Best Regards, Dorothy, Mani and Margaret > _____________________________________________=20 > From: Gellert Dorothy (Nokia-ES/MtView) =20 > Sent: Friday, September 15, 2006 11:19 AM > To: Capwap@frascone.com > Cc: ext Mani, Mahalingam (Mani); margaret@thingmagic.com; Kessens > David (Nokia-NET/MtView); dromasca@avaya.com; Gellert Dorothy > (Nokia-ES/MtView) > Subject: Consensus call on Split CAPWAP draft by 9/29. >=20 > Hi All, >=20 > The editors feel that there is WG support to split the current CAPWAP > protocol draft into 2 drafts, a base draft and then a 802.11 binding > draft. The chairs would like to verify consensus with the WG that > there is sufficient interest to split the draft before making this > change. >=20 > This issue has been discussed at the last CAPWAP WG meeting during > IETF 66 in Montreal where there was no opposition to this request, and > limited support on the list. =20 >=20 > The chairs would like establish consensus on the issue of splitting > binding specific details from the base CAPWAP specification.=20 >=20 > Please submit your opinions on this topic to the WG list by Sept 29th, > for a final consensus call on this feature. >=20 > Best Regards, > Dorothy, Mani and Margaret >=20 ------_=_NextPart_001_01C6E985.209EE32C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Final Consensus determination on Split CAPWAP draft

All,

Based on overwhelming = support for the Split CAPWAP draft, the Chairs are declaring WG = consensus on splitting the current CAPWAP protocol draft into a base = draft and an 802.11 binding draft.

The Editors will be = submitting Version 00 of the 802.11 binding draft by the October 16th = IETF 67 draft deadline.

Thanks to everyone = who submitting their opinions on this consensus call.

Best Regards,
Dorothy, Mani and = Margaret

_____________________________________________
From:   Gellert Dorothy (Nokia-ES/MtView) 
Sent:   Friday, September 15, 2006 11:19 AM
To:     Capwap@frascone.com
Cc:     ext Mani, Mahalingam (Mani); margaret@thingmagic.com; = Kessens David (Nokia-NET/MtView); dromasca@avaya.com; Gellert Dorothy = (Nokia-ES/MtView)

Subject:       = Consensus call on Split CAPWAP draft = by 9/29.

Hi All,

The editors feel that there is WG = support to split the current CAPWAP protocol draft into 2 drafts, a base = draft and then a 802.11 binding draft.  The chairs would like to = verify consensus with the WG that there is sufficient interest to split = the draft before making this change.

This issue has been discussed at = the last CAPWAP WG meeting during IETF 66 in Montreal where there was no = opposition to this request, and limited support on the list.  =

The chairs would like establish = consensus on the issue of splitting binding specific details from the = base CAPWAP specification.

Please submit your opinions on = this topic to the WG list by Sept 29th, for a final consensus call on = this feature.

Best Regards,
Dorothy, Mani and = Margaret

------_=_NextPart_001_01C6E985.209EE32C-- --===============0376078129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0376078129==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 18:38:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVyKo-000247-IS for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 18:38:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVyKk-0006oH-Q2 for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 18:38:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id C39FD398051 for ; Fri, 6 Oct 2006 15:38:21 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id CDB8B4300EA for ; Fri, 6 Oct 2006 15:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8435A144806C for ; Fri, 6 Oct 2006 15:36:58 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id EFF761448062 for ; Fri, 6 Oct 2006 15:36:55 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2006 15:36:55 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="328953284:sNHT75457688" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96MatOe016198; Fri, 6 Oct 2006 15:36:55 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k96MafOV005306; Fri, 6 Oct 2006 15:36:41 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Oct 2006 15:36:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 15:36:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8639@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbpTdzSFDp/oAGkSyy0YXCGitJGegASgMdg From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , "Scott G Kelly" X-OriginalArrivalTime: 06 Oct 2006 22:36:40.0930 (UTC) FILETIME=[E47BF420:01C6E997] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap , Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 I agree with Margaret Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Friday, October 06, 2006 6:39 AM > To: Scott G Kelly > Cc: capwap; Cheng Hong > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > While I am not against leaving things open to more optimal > implementations, I do think that we need to add some text to > the protocol portion of the document (as well as the security > considerations) to explain how this is handled. How about something > like: > > The AC SHOULD use an RSC of 0 when computing message-3 of the > 4-way 802.11i handshake, unless the AC has knowledge of a > more optimal RSC value to use. Mechanisms for determining a > more optimal RSC value are outside the scope of this specification. > > I do not think that we should simply say nothing and hope > that implementors figure this out. > > Margaret > > --- > > On Oct 6, 2006, at 9:28 AM, Scott G Kelly wrote: > > > Hi Cheng, > > > > I think we have to make the security disclaimer no matter what, as > > there is a small window of opportunity unless you precisely > > synchronize the KeyRSC (which I think most agree is more > complex than > > the resulting exposure warrants). > > > > As for setting the value, we could be rigid and require it > to be set > > to zero, or we could be a little less precise, and leave some > > discretion here. The only requirement for interoperability > is that the > > WTP > > *accept* > > any value, regardless of what its current KeyRSC value is (which is > > also true if we require "0"). Of course, if the AC sends the wrong > > value (i.e. a value greater than the actual KeyRSC), this will be a > > problem for the STA, and I think all would agree that this > particular > > implementation is broken. > > > > On the other hand, strictly requiring the AC to send zero > precludes a > > vendor of a "compliant" implementation from implementing some > > heuristic or workaround which narrows the window. Frankly, I'm not > > certain that any such workaround exists (short of some yet to be > > defined WTP/AC exchange), but I guess the question is, should we > > firmly slam this door shut, or should we specify only the necessary > > and sufficient text for interoperability? > > > > I think leaving the value unspecified might be a better approach. > > > > Scott > > > > Cheng Hong wrote: > >> Hi Charles and all, > >> > >> To specify a "default" value means specifying it to "zero". > >> Otherwise, > >> it would not work. Say, the "default" value is set to 100, but the > >> actual sequence number used could be 50 at the moment. It > means the > >> STA is not able to receive the Broadcast/Multicast packets for the > >> next 50 seqeunce count. > >> > >> So, I think we need some clarification on what is the > decision here. > >> Is the decision now: > >> - No change to the protocol design except some security > disclaimers. > >> And, specify a default value (0) to be used by the AC always. > >> > >> Or, We also allow: > >> - The WTP and AC can choose to implement info exchange methods (a > >> simple element to be specified in the draft). However, if some AC > >> choose not to support such mechanism, it will have to set > the KeyRSC > >> to zero. And a security disclaimer to state what is the effect of > >> setting the KeyRSC to zero. > >> > >> cheers > >> > >> Cheng Hong > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >>> Sent: Friday, October 06, 2006 9:24 AM > >>> To: Dorothy Stanley > >>> Cc: capwap > >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>> > >>> We'd definitely need to specify a value for keyRSC in the > >>> appropriate section. That would be in addition to the changes to > >>> the security considerations. Without specifying a > default value, we > >>> could have interoperability issues between WTPs and ACs. > >>> > >>> -- > >>> t. charles clancy, ph.d. | tcc@umd.edu | > www.cs.umd.edu/~clancy > >>> > >>> Dorothy Stanley wrote: > >>>> Behcet, > >>>> > >>>> My understanding of Scott's recommendations is that > text be added > >>>> into the security considerations section. > >>>> - no additional CAPWAP protocol exchange between the WTP and AC > >>>> - no specification of setting the keyRSC value to 0. > >>>> > >>>> Without some specification in the protocol, how can the > WTP provide > >>>> the KeyRSC info to the AC in a way that the AC is sure to > >>> understand? > >>>> The most we can say > >>>> with respect to the standard is that an AC implementation > >>> is free to > >>>> comes up with its own algorithm to set the keyRSC value. > >>>> > >>>> Dorothy > >>>> > >>>> On 10/5/06, *Behcet Sarikaya* >>>> > wrote: > >>>> > >>>> I agree with this and suggest adding Peter's fix as a > >>> possibility. > >>>> As far as interoperability is concerned, value 0 is > >>> interoperable > >>>> but not correct. If we allow implementations to snif in > >>> and modify > >>>> then any value should be acceptable which may be a > concern for > >>>> interoperability? > >>>> > >>>> ----- Original Message ---- > >>>> From: Scott G. Kelly < s.kelly@ix.netcom.com > >>>> > > >>>> To: capwap > > >>>> Sent: Thursday, October 5, 2006 3:15:40 PM > >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>>> Considerations > >>>> > >>>> Following up once again - after careful review, I still > >>> agree with > >>>> Charles, and here's some suggested text for the > >>> security considerations: > >>>> 13.5. IEEE 802.11 Security > >>>> > >>>> When used with an IEEE 802.11 infrastructure with WEP > >>>> encryption, the > >>>> CAPWAP protocol does not add any new > >>> vulnerabilities. Derived > >>>> session keys between the STA and WTP can be > >>> compromised, resulting in > >>>> many well-documented attacks. Implementors SHOULD > >>> discourage the use > >>>> of WEP and encourage use of technically sound > cryptographic > >>>> solutions > >>>> such as those in an IEEE 802.11 RSN. > >>>> > >>>> When used with IEEE 802.11 RSN security, the > CAPWAP protocol > >>>> may introduce new vulnerabilities, depending on > >>> whether the link > >>>> security > >>>> (packet encryption and integrity verification) is > >>> provided by the > >>>> WTP or the AC. > >>>> When the link security function is provided by the AC, no > >>>> new > >>>> security > >>>> concerns are introduced. > >>>> > >>>> However, when the WTP provides link security, a new > >>> vulnerability > >>>> will > >>>> exist when the following conditions are true: > >>>> > >>>> o the client is not the first to associate to > the WTP/ESSID > >>>> (i.e. other clients are associated), and a > GTK already > >>>> exists > >>>> > >>>> o traffic has been broadcast under the existing GTK > >>>> > >>>> Under these circumstances, the receive sequence > >>> counter (KeyRSC) > >>>> associated with the GTK is non-zero, but because the > >>> AC anchors the > >>>> 4-way handshake with the client, the exact value of > >>> the KeyRSC is not > >>>> known when the AC constructs the message > containing the GTK. > >>>> The client will update its Key RSC value to the > >>> current valid KeyRSC > >>>> upon receipt of a valid multicast/broadcast message, > >>> but prior to > >>>> this, > >>>> previous multicast/broadcast traffic which was > >>> secured with the > >>>> existing > >>>> GTK may be replayed, and the client will accept this > >>> traffic as > >>>> valid. > >>>> > >>>> Typically, busy networks will produce numerous > >>> multicast or broadcast > >>>> frames per second, so the window of opportunity with > >>> respect to such > >>>> replay is expected to be very small. In most > >>> conditions, it is > >>>> expected that > >>>> replayed frames could be detected (and logged) by the WTP. > >>>> > >>>> The only way to completely close this window is to > >>> provide the > >>>> exact KeyRSC value in message 3 of the 4-way > handshake; any > >>>> other approach simply narrows the window to varying > >>> degrees. Given > >>>> the low relative threat level this presents, the > additional > >>>> complexity > >>>> introduced by providing the exact KeyRSC value is > >>> not warranted. > >>>> That > >>>> is, this specification provides for a calculated > >>> risk in this regard. > >>>> ==> > >>>> However, WTP implementations MAY provide the exact > KeyRSC value > >>>> before forwarding message 3 of the 4-way handshake. > >>>> > >>>> --behcet > >>>> > >>>> > >>> _________________________________________________________________ > >>>> To unsubscribe or modify your subscription options, > >>> please visit: > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > -------------------------------------------------------------------- > >>> -- > >>>> -- > >>>> > >>>> _________________________________________________________________ > >>>> To unsubscribe or modify your subscription options, please visit: > >>>> http://lists.frascone.com/mailman/listinfo/capwap > >>>> > >>>> Archives: http://lists.frascone.com/pipermail/capwap > >>> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > >>> > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > >> > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 18:40:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVyMY-0003KI-WB for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 18:40:15 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVyMX-0006wT-Ax for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 18:40:14 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B39AA398078 for ; Fri, 6 Oct 2006 15:40:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 59E214300EA for ; Fri, 6 Oct 2006 15:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 542451448036 for ; Fri, 6 Oct 2006 15:39:31 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id A3CBB1448062 for ; Fri, 6 Oct 2006 15:39:27 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 06 Oct 2006 15:39:27 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="328954184:sNHT422880450" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k96MdQbr011584; Fri, 6 Oct 2006 15:39:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k96MdDbP024058; Fri, 6 Oct 2006 15:39:23 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Oct 2006 15:39:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 15:39:12 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E863D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 2-Port/Mux Issue Discussion Thread-Index: AcbdY6vEKMFgUw/STFqp1nztobZjogMNGCOQ From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , X-OriginalArrivalTime: 06 Oct 2006 22:39:14.0818 (UTC) FILETIME=[40356620:01C6E998] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] 2-Port/Mux Issue Discussion X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 I fully support the two port approach, and thank Margaret for clearly describing the issue. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, September 21, 2006 1:50 AM > To: capwap@frascone.com > Subject: [Capwap] 2-Port/Mux Issue Discussion > > > Hi All, > > As many of you know, we have had a technical issue open in > the CAPWAP WG for some time that is commonly referred to as > the 2-port/mux issue. This issue involves a technical choice between: > > - A solution that uses two different well-known UDP ports for > separate data and control communications (the 2-port solution), > > OR > > - A solution that uses a single well-known UDP port for all > communication, with control and data traffic distinguished by > a CAPWAP header value (the mux solution). > > Strong opinions have been expressed on both sides of this issue, and > the WG has had trouble coming to consensus on a single choice. > Discussions in this area have included a wide variety of > networking topics, such as Quality of Service, NAT Traversal > and Mobility. > > Given the breadth of the technical issues under discussion, > our Area Director, Dan Romascanu, decided to solicit advice > from the IESG to help us understand the technical trade-offs, > and to help us understand which factors it would be > reasonable to consider in our working group decision -- > specifically whether or not it was reasonable for us to > consider the hardware implications of this decision. The > only IESG members who showed up for the discussion were Mark > Townsley, one of the Internet ADs, and our two OPS ADs, Dan > and David Kessens. We didn't receive a definitive answer > from the IESG, but a clear message was received from Mark > Townsley that it is reasonable for the group to consider the > hardware implications of our work -- both compatibility with > currently deployed hardware, and the hardware architectures > we might want to support in the future. > > After much discussion with the interested IESG members, the > document editors, the proponents of both solutions and some > people who have proposed compromise solutions, the chairs > believe that the key technical difference between these two > proposals is which hardware > architecture(s) they will support. There are currently two > different classes of AC hardware deployed, and variants on > both of these architectures may be deployed in the future: > > - Single-Processor: In this architecture, the control plane > and the data plane run on a single processor. The > demultiplexing of control and data packets happens on that processor. > > - Separate Data & Control Planes: In this architecture, the > data and control planes run on separate processors (and > possibly on separate cards), typically connected via a > switching fabric. This is a common hardware architecture for > higher-end routing and switching hardware, and it relies on a > port-based splitting/load-balancing approach to separate the > control and data traffic. For CAPWAP to work efficiently on > these systems, it must be possible to distinguish the control > and data traffic in the switching hardware, which is > typically done based on the five-tuple of the send & recv IP > addresses, the protocol (UDP), and the send & recv port > numbers. The switching hardware cannot do the type of deep > packet inspection required to demultiplex on CAPWAP header fields. > > The 2-port approach supports both the "Single-Processor" AC > architecture and the "Separate Data & Control Planes" AC > architecture. Proponents of this solution believe that it is > important to support the "Separate Data & Control Planes" > architecture efficiently, both for compatibility with > currently deployed hardware and to allow this hardware > architecture to be used for future CAPWAP-enabled products. > > The mux approach will only operate efficiently on "Single-Processor" > systems. as it relies on the ability to demultiplex the > control and data traffic using CAPWAP header information. > Proponents of this solution believe that it will simplify > CAPWAP software implementation, and that it makes NAT > traversal (when the AC and the WTPs are on different sides of > a NAT) simpler to configure. > > This complexity is a consequence of the choice to tunnel all > WLAN data traffic to the AC. In split-MAC local-forwarding > mode, only the control plane traffic would be sent to the AC, > and data plane forwarding would be handled by the WTPs themselves. > > We've heard from a couple of strong voices on this issue. but > now we'd like to hear from the rest of the WG... > > Which hardware architecture(s) does the CAPWAP protocol needs > to support? > > Specifically, do you think that it should be a requirement to > support efficient operation on currently deployed and future > ACs that follow the "Separate Control & Data Planes" > architecture described above? Or do you think that it would > be acceptable to produce a somewhat cleaner and simpler > protocol that will not work efficiently on those ACs? > > Please send your response by Thursday, October 5th (two weeks > from today), so that the chairs can gauge the consensus of > the WG in this matter. > > After we have an understanding of which hardware > architecture(s) the CAPWAP protocol needs to support, we will > make an effort to sort through the various proposals and > counter-proposals that meet that requirement. > > Thanks, > > The CAPWAP Chairs > Dorothy Gellert, Mahalingam Mani & Margaret Wasserman > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 06 20:26:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW01e-0000i9-0d for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 20:26:46 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW01X-0007jp-FY for capwap-archive@lists.ietf.org; Fri, 06 Oct 2006 20:26:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5E99F3980A3 for ; Fri, 6 Oct 2006 17:26:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A92AA4300EA for ; Fri, 6 Oct 2006 17:25:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 88822144805D for ; Fri, 6 Oct 2006 17:25:40 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by hermes.tigertech.net (Postfix) with ESMTP id 23E6D1448033 for ; Fri, 6 Oct 2006 17:25:37 -0700 (PDT) Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GW00V-0004Fg-Px; Fri, 06 Oct 2006 20:25:35 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Fri, 6 Oct 2006 20:25:35 -0400 Message-ID: <30590544.1160180735753.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Fri, 6 Oct 2006 20:25:35 -0400 (EDT) From: "Scott G. Kelly" To: Margaret Wasserman Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710034783752543512f2e09384884331bb8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi Margaret, Comments inline below... -----Original Message----- >From: Margaret Wasserman >Sent: Oct 6, 2006 9:39 AM >To: Scott G Kelly >Cc: Cheng Hong , capwap >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > >While I am not against leaving things open to more optimal >implementations, I do think that we need to add some text to the >protocol portion of the document (as well as the security >considerations) to explain how this is handled. How about something >like: > >The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way >802.11i handshake, unless the AC has knowledge of a more optimal RSC >value to use. Mechanisms for determining a more optimal RSC value >are outside the scope of this specification. > >I do not think that we should simply say nothing and hope that >implementors figure this out. > >Margaret After thinking long and hard about this, I can't bring myself to agree with the suggested text. Quite frankly, I think always using an RSC value of 0 is a lazy hack, and given that we've acknowledged we are introducing a vulnerability here (however slight), telling implementors they SHOULD do this just doesn't sit right with me. An enlightened implementation could almost certainly do better than always setting this to zero, and explicitly recommending that people nail this window open just rubs me the wrong way. At least, let's hold off on this decision until we've clearly defined what statistics we expect to be available. Seems like if we're going to tell implementors what they SHOULD do, we SHOULD give them sound, well considered advice. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 07 00:54:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW4DD-000298-Gv for capwap-archive@lists.ietf.org; Sat, 07 Oct 2006 00:54:59 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW4D9-0006Go-Am for capwap-archive@lists.ietf.org; Sat, 07 Oct 2006 00:54:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DDB59144809E for ; Fri, 6 Oct 2006 21:54:42 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B5CF34300EA for ; Fri, 6 Oct 2006 21:53:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9638D39806D for ; Fri, 6 Oct 2006 21:53:47 -0700 (PDT) Received: from huawei-3com.com (h3cml01-in.huawei-3com.com [210.21.230.96]) by zoidberg.tigertech.net (Postfix) with ESMTP id CB4E239804E for ; Fri, 6 Oct 2006 21:53:43 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6R0074I1VATI@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Sat, 07 Oct 2006 12:59:35 +0800 (CST) Received: from smtp1.huawei-3com.com ([172.19.1.38]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6R007Z21VAIW@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Sat, 07 Oct 2006 12:59:34 +0800 (CST) Received: from unknown (HELO RichardYoung) ([10.18.23.88]) by smtp1.huawei-3com.com with ESMTP; Sat, 07 Oct 2006 12:52:44 +0800 Date: Sat, 07 Oct 2006 10:23:30 +0530 From: young To: dstanley1389@gmail.com, capwap@frascone.com Message-id: <000001c6e9cc$89af11f0$5817120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbpzIjTGj5mrz0PRZKJsoRdHhnuMg== X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.47 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: young@huawei-3com.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113703614==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 This is a multi-part message in MIME format. --===============0113703614== Content-type: multipart/related; boundary="Boundary_(ID_MMVritD19bABFILYH/Voyg)" This is a multi-part message in MIME format. --Boundary_(ID_MMVritD19bABFILYH/Voyg) Content-type: multipart/alternative; boundary="Boundary_(ID_pwxDHm4xvnDp2RNlIxwb1A)" --Boundary_(ID_pwxDHm4xvnDp2RNlIxwb1A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dorothy: Thanks for your comment, it is fine. Just as you mentioned, WG needs to clarify on the base vs binding division of labor. Anyway, a clear rule and scope of base protocol should be there. Till then, I think discussion on each TLV in detail will be more meaningful. I thought the scope of CAPWAP base protocol will be two way alternative: 1) Take effort on the control and data tunnel, tunnel related TLV is focus. No any wireless related element like Tx power, Channel, wlan and so on. 2) Based on 1), more abstract wireless element put in the base protocol. For example, radio, Tx power, channel and so on. Also, give a way to identify each wireless binding of 802.11, RFID and so on. Whether putting TLV in base or wireless binding just follow the rule made by WG or mailing list is ok. Regards Richard (shiyang) From: Dorothy Stanley (dstanley1389gmail.com) Date: Fri, 6 Oct 2006 10:36:38 -0700 (PDT) Richard, Notes inline. Thanks, Dorothy On 10/5/06, young [at] huawei-3com.com> wrote: Hi, Dorothy: Thanks for your proposed resolutions. You're welcome. In your Proposed Resolution, you mentioned that " While there may be common elements, it's not clear that the CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems." If it is not clear, I suggest that WG or mailing list had better take time to make it clear. Otherwise, how to decide what info should put in the base part if base part scope is not clear? I thought a clear and common understanding of base part's rule and scope is very important for base part separation from wireless specific binding. I completely agree that the WG needs to clarify on the base vs binding division of labor. The current draft, with the exception (largely) of the WTP Radio information element, puts the wireless-technology specific elements in the binding rather than the base protocol. This is the approach I followed in developing the proposed resolutions. Most of the CAPWAP level message elements are used to establish and manage the session between the AC and WTP. Some message elements, for example the WTP radio statistics and Decryption Error Report are borderline and could arguably move to the binding; but they are not technology specific - e.g. 802.11 vs 802.16. I give my comment for the proposed resolutions to issue 204. 1) 4.4.38. WTP Radio Information Sorry for I don't make issue clear in my comment. I suggest that WTP Radio Information could be kept in the current section 4.4. While 802.11a/b/g/n these kinds info could be defined by 802.11binding. We could add a Wireless binding identifier in the WTP Radio Information. By this way, we could identify any Wireless binding's radio type definition. The Wireless binding identifier could be probably eventually managed by IANA. No matter what method will by used for Wireless binding identifier, it is a key Point to help base protocol to separate any wireless binding. I thought that Wireless binding identifier method will be a common issue. I considered several options on this one. (a) Have both a CAPWAP base element that included the "first level" radio information: 802.11, 802.15, 802.16, 802.22, EPCGlobal, etc, AND specific binding elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first levels churn internally, the base spec isn't impacted. But if the detailed level is provided, is the higher level even needed? (b) Have only binding-specific elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. The binding will need to specify that the element must be included in the control messages that the previous CAPWAP level element was in. (c) keeping the definition as is. Didn't do this, since the change did make the CAPWAP base spec even more wireless-technology agnostic. The WTP Radio information message element includes only 2 fields, the radio type and the radio information. If we want radio specific info in the base spec, then we can leave it there, and add the 802.11,15,16,etc values - and require that the capwap base spec change as new values are added, or we can move the radio-type info to the binding, and then as the wireless technology evolves, only the binding doc has to change. 2) 11.9.18. IEEE 802.11 Tx Power I suggest we could define a "WTP Radio configuration" TLV. By using wireless binding identifier, there will be no conflict with Dot11PhyTxPowerEntry MIB table. Channel also could be put here. As AC will configure AP's RF parameter (AC to AP), and AP will report its current Configuration to AC, the TLV will be carried in the configuration message in bi-direction. More TLV could be added into the TLV if it is required. |---------|-------------|-----------------------------|--------------|------ ---|---------| | Radio ID| country code| wireless binding identifier | Max Tx Power |Tx Power | Channel | |---------|-------------|-----------------------------|--------------|------ -- |----------| As Tx power these kind info will not be carried in the discovery phase, I suggest that "WTP Radio configuration" is required instead of extenuation of " WTP Radio Information". Ok, so the proposal is to have a new base-spec-level message element, that incorporates a binding-defined-identifier for Radio Configuration. This would require the TX power fields to have the same units across wireless types. This level of configuration is currenly in the binding and my preference would be to leave it there. Regards Richard (shiyang) --Boundary_(ID_pwxDHm4xvnDp2RNlIxwb1A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dorothy:

 

Thanks for your comment, it is fine.

Just as you mentioned, WG needs to clarify on the base vs binding
division of labor. Anyway, a clear rule and scope of base protocol should be there.

Till then, I think discussion on each TLV in detail will be more meaningful.

 

I thought the scope of CAPWAP base protocol will be two way alternative:

1) Take effort on the control and data tunnel, tunnel related TLV is focus.

No any wireless related element like Tx power, Channel, wlan and so on.

2) Based on 1), more abstract wireless element put in the base protocol.

For example, radio, Tx power, channel and so on. Also, give a way to identify

each wireless binding of 802.11, RFID and so on.

 

Whether putting TLV in base or wireless binding just follow the rule made

by WG or mailing list is ok.

 

Regards

Richard (shiyang)

 

From: Dorothy Stanley (dstanley1389gmail.com)

Date: Fri, 6 Oct 2006 10:36:38 -0700 (PDT)

Richard,

Notes inline.

Thanks,

Dorothy

On 10/5/06, young <young [at] huawei-3com.com> wrote:

Hi, Dorothy:
Thanks for your proposed resolutions. 

You're welcome.

In your Proposed Resolution, you mentioned that " While there may be common
elements, it's not clear that the
CAPWAP base specification should take on the task of extracting/unifying the
common elements
across wireless systems."
If it is not clear, I suggest that WG or mailing list had better take time
to make it clear.
Otherwise, how to decide what info should put in the base part if base part
scope is not clear?
I thought a clear and common understanding of base part's rule and scope is
very important for
base part separation from wireless specific binding.


I completely agree that the WG needs to clarify on the base vs binding
division of labor.
The current draft, with the exception (largely) of  the WTP Radio information element, puts the
wireless-technology specific elements in the binding rather than the base protocol. This is
the approach I followed in developing the proposed resolutions.
Most of the CAPWAP level message elements are used to establish and manage the
session between the AC and WTP.  Some message elements, for example
 the WTP radio statistics and Decryption Error Report are borderline and could arguably
move to the binding; but they are not technology specific - e.g. 802.11 vs 802.16.

 

I give my comment for the proposed resolutions to issue 204.
1) 4.4.38.  WTP Radio Information
Sorry for I don't make issue clear in my comment.
I suggest that WTP Radio Information could be kept in the current section
4.4.
While 802.11a/b/g/n these kinds info could be defined by 802.11binding.
We could add a Wireless binding identifier in the WTP Radio Information.
By this way, we could identify any Wireless binding's radio type definition.
The Wireless binding identifier could be probably eventually managed by
IANA.
No matter what method will by used for Wireless binding identifier, it is a
key
Point to help base protocol to separate any wireless binding.
I thought that Wireless binding identifier method will be a common issue.


I considered several options on this one.
(a) Have both a CAPWAP
base element that included the "first level" radio information: 802.11, 802.15,
802.16, 802.22, EPCGlobal, etc, AND specific binding elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first
levels churn internally, the base spec isn't impacted. But if the detailed level
is provided, is the higher level even needed?

(b) Have  only binding-specific  elements that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc.
The binding will need to specify that the element must be included in the
control messages that the previous CAPWAP level element was in.

(c) keeping the definition as is. Didn't do this, since the change
did make the CAPWAP base spec even more wireless-technology agnostic.

The WTP Radio information message element includes only 2 fields, the
radio type and the radio information. If we want radio specific info in the
base spec, then we can leave it there, and add the 802.11,15,16,etc values - and
require that the capwap base spec change as new values are added, or we can
move the radio-type info to the binding, and then as the wireless technology
evolves, only the binding doc has to change. 

 

2) 11.9.18.  IEEE 802.11 Tx Power
I suggest we could define a "WTP Radio configuration" TLV.
By using wireless binding identifier, there will be no conflict with
Dot11PhyTxPowerEntry MIB table.
Channel also could be put here.
As AC will configure AP's RF parameter (AC to AP), and AP will report its
current
Configuration to AC, the TLV will be carried in the configuration message in
bi-direction.
More TLV could be added into the TLV if it is required.
|---------|-------------|-----------------------------|--------------|------
---|---------|
| Radio ID| country code| wireless binding identifier | Max Tx Power |Tx
Power | Channel  |
|---------|-------------|-----------------------------|--------------|------
-- |----------|
As Tx power these kind info will not be carried in the discovery phase, I
suggest that "WTP Radio configuration"
is required instead of extenuation of " WTP Radio Information".


Ok, so the proposal is to have a new base-spec-level message element,
that incorporates a binding-defined-identifier for Radio Configuration.
This would require the TX power fields to have the same units across
wireless types. This level of configuration is currenly in the binding and
my preference would be to leave it there.

 

Regards
Richard (shiyang)

 

--Boundary_(ID_pwxDHm4xvnDp2RNlIxwb1A)-- --Boundary_(ID_MMVritD19bABFILYH/Voyg) Content-id: Content-type: image/gif; name=image001.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.gif R0lGODlhDQAMAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== --Boundary_(ID_MMVritD19bABFILYH/Voyg)-- --===============0113703614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0113703614==-- From vlzgggzazf@taycoeng.com Sat Oct 07 14:48:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHDn-0007jD-7J for capwap-archive@ietf.org; Sat, 07 Oct 2006 14:48:27 -0400 Received: from aczw139.neoplus.adsl.tpnet.pl ([83.11.232.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWH8c-0005aH-DN for capwap-archive@ietf.org; Sat, 07 Oct 2006 14:43:09 -0400 Message-ID: <001201c6ea40$8cb05250$8be80b53@michal> From: "required." To: capwap-archive@ietf.org Subject: its way store near Date: Sat, 7 Oct 2006 20:43:58 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6EA51.50361510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f ------=_NextPart_000_000E_01C6EA51.50361510 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6EA51.50361510" ------=_NextPart_001_000F_01C6EA51.50361510 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable The world or getting smaller retro. Emitting diode timepiece. Moustache of Aviators am now! Dvd Creatives Xmod promises am bit surround am sound audio source aims =20 wii. Kick battle hidef Suddenly in Hddvds look like bloaters am Worlds or =20 Best Selling this weeks. Itunes Archive does support. London of There will a tantrums or Just is browsing Nintendo. Losers or from last nights British Academy Games in Awards. Video am Give on is sale Greatest gadgets ever Plus Beat charge Cameras =20 Cars bikes Gadgets. Fri oct pm people is who is dont have Sharp Turh twin digital am tuners =20 and? Top Forums Register in Contact us a Subscribe or Freeview gets in sky in =20 treatment? Many or shiny reckons well buy am before years over quite is. Last nights am British. Oyster. Up in! Cinema Laptops? Stuff Magazine hot. Mp what upscalers of. Sportsman Like how or ab ------=_NextPart_001_000F_01C6EA51.50361510 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
The world or getting smaller = retro.
Emitting=20 diode timepiece.
Moustache of Aviators am now!
Dvd Creatives Xmod = promises=20 am bit surround am sound audio source aims wii.
3D""
Kick battle hidef Suddenly in Hddvds = look like=20 bloaters am Worlds or Best Selling this weeks.
Itunes Archive does=20 support.
London of There will a tantrums or Just is browsing=20 Nintendo.
Losers or from last nights British Academy Games in=20 Awards.
Video am Give on is sale Greatest gadgets ever Plus Beat = charge=20 Cameras Cars bikes Gadgets.
Fri oct pm people is who is dont have = Sharp Turh=20 twin digital am tuners and?
Top Forums Register in Contact us a = Subscribe or=20 Freeview gets in sky in treatment?
Many or shiny reckons well buy am = before=20 years over quite is.
Last nights am British.
Oyster.
Up = in!
Cinema=20 Laptops?
Stuff Magazine hot.
Mp what upscalers of.
Sportsman = Like how=20 or about Sport.
------=_NextPart_001_000F_01C6EA51.50361510-- ------=_NextPart_000_000E_01C6EA51.50361510 Content-Type: image/gif; name="Networked.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6ea40$8cad4510$8be80b53@michal> R0lGODlhdAEQAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BACjxgAALAAAAAB0ARABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypUuUA2IO+BeT4Mya AmvKlJlzZ0+fNHfODAr0J06bQ2kOPBoUKVChPZEaFDr0qE6oL7Nq3RoSJ8+cTaMyDQs2qlmx Sb0mVSqV6Nmib9felLuWbFOraety3cu370O1acleLcg071K6gqvKJaxY8eGxeG3ahYw48lm/ mDNrDju37GC7oA+LFm15LGOwjjkjvnyZslTLoTfLns3Sq1i0RgEXNkwaa+6DPouqbRuaquve o2PTXs5cpO27uJXHTX63M0LTwb+qJo59NfXPiZv+ix8P8rnbn9TZTm9t3Srxx3N1C+eN2jv7 8KzJ698v0bz2/3V5B1t1o9mX3ICwFTZZgJXRZxp/EEYIHE8C4vUUXLtd2JZvp63nIVHDpQei hbtJaOKJKKao4oostujiizDGKOOMNNZo4404NmdCjjz26OOPLwkB5JBEFmlkcyckmaRASirJ 5AkEQflPk1JGWeVAS2J5ZZZTQkmllFQmxGVBYz75ZJNmmvllmke2udGYXla5pJNMdhklmXBy iWaaWZYJ50F74rnlnIPaqeaVbLqpqEV/6hmnnIbWaWWfdHbpaKR+bglopZOC6WSemMZpUJmL lgoRqZeKOmWkgFpKKJ//noJq5UKUjuqqqLK+ymqipvbqUJi3gqnmmaieCSusiK5566a8rmrp obPaSemepPpqLUO6SjssnmRiqeWxrkaLEKqe2iqptIWi22y117Z7rrrbPpuut6M+Gma2fopL bKDvfivrs826K3Cr/srppZYHf3tnvazqWuvCvP7bL7QKA7zrxQM3lA2RwCqbLrAQzwpqqh3z m2i+DAc7KcJ0spvxyzDHLPPMNNds880456zzzjzbCEXPQAct9NBEh6RnxQ2X3PK8LMe69MIg N20vuZ06arLKDXOrtceaClqp0pzui/SPpLw0LZsmX+qtxFmTDOmfKYfaacUPM1swpCsjnLTF /skWCjfGartctKFPE6t120wjfvfaXR+utuEnq2r3oXizbPjIR+ubrbOAGxzw4Hw6+/C/VI9d urZ9Yuy45+BiLqbfhHd7r+SoC6s57frSXS7o43769e5oIxosuUtTu23U4irbut/IjxyvpE87 r+3tqlcbuPC8X/575GPv/brc5QpvveeZgkvx5NPP2e25m6s/PdKb5y7157yjSe2XrCtuusjk 65148MFbk+t6JzK9haxgBTQW9f4mOPplT3fwy1+jEsc8f/lPfnIzH7wIhz3uGSxZzJKexTzY uAY+7oHJy18Gxea9qu3Ldshi1wnbN7UPhk1lr6Cg3TwmP+VFTYac/mogCodIxCIa8YhITKIS l8jEJjrxiVCMohSnSEWCpKGKWHQIIbLIxS568YsaQQUYx0jGMprxjGhMoxrXyMY2uvGNcIyj HOdIxzra0UZ4uKMe98hHFHmgj4AMpCAHSchCGvKQiEykEXekyEY68pGQjKQkJ+kQYhCjkpek kSVDwo9O8kMlnRzIJ1liyVL+Y5MCQeUpVanKVRKklKiE5SVlOUtZrtKUtiwILF2Zylu2Mpep xGUmTxlMU75ymLlk5TAlksxmGnMgtmwmNIv5y13yMpbL3MgoWRJKgWwzJa3kpTifWc1jBlOc 0MymMs2JznPespfYdOdBsJnJWiYknudc/+dE9DnObKZTl/WsZT3b+U9XbpKf2jyIJ70Zym56 cpsL/cdDvSlKgnxylBh1aEMh2k2JViSc+jxoQNnpTpEaBKTIXCY+2blLe+bTnwVtKUHluc6W WtOX+SQpP1HaznjKNJwxFag6YWqRb1KUohhFakUt6lGlHtWpRr3oUaU61Y9ak5YjXSk6nYnQ fgpTnjHFaU1vGlabImSnLr2mS0VaTpqmFKC+DKgxhRpXuBoUqEC9iFGb6tGk9nWpE4WoUwHb 1MBW9aF73adZS7pWlTr2pScdakGpCdNYFrOflLWrXGeKWcgyNq5pnSxa77nYg162rumcK16J WpG9CtavVP3rYP6TGlWlvvawIDHpS6P52KASlKdg1a1m/9lV4L41r529q2+Bq9O3gvWsjSXm c9uaWsl2pLZQnS1fYyvYgnB0u4XVLl8tItzyhratwp2sW1nqT8tOU6vTHeh7iTrakIb2t85N bnzVKt1emjO9ylWvNiNK4MNGVKIL7e54n6rRhlYVwQpm5lWPS2FhWpiexU3pV4OLy1ei9sPU 7K90gelWcuoWw/fNrHp5i9pkeliaxh3pVhK7EBqvEbk/ugZnV7JXOdSYjjj2UZApSeQiG/nI SDYiG4YIgCRrZaLepVGTBwKAKhukylj+B5at7GS9LvVGW9YylRPS5CmzSEhYvC1VCf7cURsz p8xjFoiZCzLlOa8IzVR8LW2Z+mD+wFnOcb6ynLN8ZjxHEcq3FSWUTURoM9sZ0IJukaGfiF3Z PlVFcHb0QR4t5r6EgSOTbmKlYwveBe8n03HWdKA5rZVPb0QIof6RIPwyaoZmNML6CfOgVd1p KnPZL64Gdbt8wTtWRyjYXaaNsY+d7CEieySeaLa0MUONaVtbJc24No9/rO1FLZohbjb1ZsBB bnL/o9zmPjc4BrJudZd7LwHYY7gREu557yXd7G63ud99bnX7Jd7yjjJSN2prjsJ2NvgWSLr3 /e51J3wrAH/ZMExU4OxamrvhlQ269Y1uhbvb4R3XSsRhNv+MiVPc4nvWrr3v3fGFO1zhLuc3 GUsuoZQfPNGWbg7DYd5vnhPk4WOkOX8UfPOKJnrlXNm5v9vt8Z8z/Ywmb863u0vbA1cc6S7Z OMz5/XSQy7zbrQX70LC+on6I/exoT7va1852U5E9122/7rcF7hDEehkldna0roEmAxkIzN5v f7tC8d5oXsf9IW5GtEO/zPgC3/rWtr60R/686sNHZO6lNjrjJT9wBoP3m6P8wEcoD2ktE9ry iIdwqREtbtAn+MsXNexJTt9rgiwb9XT3PNVbD/vMk1rcIqE8p2+PelzjHNe9F+/Fxyv4iAi/ 8rhXyIEtyuY205v6DlZ0gxXNeY7+7P30tI/+dROaFeKLn5MYmb5LzH/+9rv//fCPv/znT//6 2//++M+//vfP//77//8AGIACOIAEWID/kAOR9AstYQAG6BH2IBEK2IA5EoESaCMUWIEy4w0Y uIED8wcc+IEgGIIiOIIkWIIykwgmmIIqCG8B0ILx5oItKBAxKIMyCIMEAYMRh4P/MIM16IID 4YM/aIM6uIM2GIRAOIRECIRJGIQ1mIQvmIM9qIRE+INO+IRNOIVVuEc8eIUxeIRYaBAzGIYj t4Vb2INMeINjOHJo2IRieIVomINWyIVh+IVgOIdkCHBtWIZ6VIZ56INxWIdyuIZnyIRtKIhu WBB92AX/WMiHcViEctiFdIiIfkiHhdiFaqiHcDSEmuiEWSiIYuiHaXiEjViEOoiEUYiHqIgN nWiJZuiJnIiJNCiEpGiFn1iIdVSKqLiDrWiKSHiHhsiGcAiKkiiFfeiCqhiJrLiErriEn3iD ZsiIOBiMsHiLo6iLh0iJf+iLg1iFjBiJ29iHX3iHOMgJjriIhAiHzgiMw9iKv6iF1TiGkuiJ ufiNabiNUwiL2piMthiOtIiO1hiL/kiDVKiH+3iOdqSJpOiMpsiPWYiLwgiMogiKUriK6IiL BnmPk0iF3JiOAKmEtoiQKxiSIjmSJFmSJnmS4nF7qCYQPqAS7HciLzkRMakQ/y/5a5gxkzeZ ZSopZjtZeg0RfpFGk5smkzb5EHtnlHTmfEA5lAxBfHO2lDhJZoH2k0vpk9CnGXm3ECsplVbZ lF6pld5HEYYnkxAxk1HJlFNpextxlmOZll2JlXQGflyWaXJZZ1ZWeHVWe532fTqZand5lzy5 a75mbHb5a1WpaX/WaGNWmIU5mGp5ZYY5l4K5a4k5l5L5mLqGl4BWZn/pmKZXmYyZlKWnmJ8p mJwZmUXJEqSpl6iGmIt5lZwZaa65ma+5ank5m0LZa6SHlrGpm775fLj5mMIJnL/5mqy2m3lJ m6NpepCWnLUZmMpZe6oWnNBZnc/HFdcZZlt5moA5mv/ayZS4CZy8hpja2ZPUCZmX6ZvQKZ46 +WiNuWXEGZ7VSZmsuZzjqZ7J+Z3ReZ30SZmgSZz7uRcAGpgDupxWOXz2+Zx6p57z6WtceZ6i CZvKWaAOOpXIaZwKOp/U6Zz8mZ0BKp+Gx6FJCaIZip3FSZsD2qHPiZkZGqIMyp97KZsrWp/D KaHymZYkiqItKp0zKqL3OZ0fuqM+CaQ6GqQB+hKZ6ZeAyZ2eyZxOupqOOZ14eZoOKqWNeaDd uZfpeaC2Z5NWeqVQqZmTeaWfCZr0+ZRZSnqrmZ/92Z1rKpxamp+FZ539WRCikD1n2SJ5miOP dqfFNiRV2SZA6acoaRFHUKj/iJqoihp8oLOnWQSfNJmadBqUZaqagUqWWimpFeqkF7GbbmR+ y9aTBpoSbVkRoJqpm2oRjspFaOqebVqaYFqjk1matOqaYFqUtjqmdYmiaSqaR0mgcVqnmSmZ ZHpGVzSa6sClxTmWappqKwqizsmgv+mjLSqiyuqirSmkdHqhbHSfLFqkcaqmddmZCXqk/tml 6QmtfTmkehmj7BqjObqt4dpG3uqs4Fqg1hqXJzqpb0mj+8qtPOqq0sqm8Rqf0ppG9dqcGGqk Boqt2vqUFhqhBXuwCDqwI/qwy3qwaNSqcQmgbrqu7yqmtFqpHDuyyqqrqDmkbQmyEIuZ6dqm xFqn/yPIlqq5qDRLeKv6EYNARDqwqD77swfhDkA7tERbtEZ7tJC0CtemgUjbtE77tFAbtVI7 tVRbtVZ7tVibtVq7tZmRAlz7tWAbth2xAmJbtiUBDGabtmq7tmzbtr0iAHAbtwIwEHIrtwQR t3dbtwgBtwfBt3SLt3+rtwJRt4BrEHb7t337D35bEIe7uHeruIQ7t3mbuIEruYNruYo7uZDb Ro7rt45ruJ2LuZ8LuZhLuperuaF7uguRuqbLuJvbt5ZbuHT7ugkhu4Oruqq7uIXruaWLRqw7 uoiru6Lbu7YLuL87vLhbu8hLuqU7t8BLu4c7u89bua5Lu68rvLErudNLRv/Hq7zQ27zNC72b O7p8270KQb7O27q3+7y6q76Zu73v27nWe7rYi7jz67vZW7nRW775q7nSq730S7zO27/MG73J S7+XG7v3i7va276RG77qO8CgG8DjS8BqRLj+y7j9+7kcjMAVPMEYbL/eq8GZm8Dr27sMHLgn vLoqHL8T/MH8K8IX3MAZnLeCy8EQ/L33G8PWC7/oW8ImLMGwO7sqLMS1a8MuTMIwbMTwC0bC K8NQHMNKcMBA/MQ9TMMMjMJKnLsazMMvDMQJbMR728VYnMXYq8UzjLoojMOQO8VUrMW8q8Zy vLrLK8Bi7L92vMCP28XJG7rZu7xrxMYPPL/8a8BZe/zFzFvDhSy4oCu/IBzCjTvEg/wPhwrG MmzIhAzIjeTGA3OM0cfJbhvKojzKpFzKpnzKqJzKNxIEqtzKrvzKsBzLslwkRQAkXjvLuJzL DfEGupwQvCwbAQEAOw== ------=_NextPart_000_000E_01C6EA51.50361510-- From jkhssiet@telathena.com Sat Oct 07 14:48:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHDn-0007j2-5t for capwap-archive@lists.ietf.org; Sat, 07 Oct 2006 14:48:27 -0400 Received: from aczw139.neoplus.adsl.tpnet.pl ([83.11.232.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWH8g-0005aG-JU for capwap-archive@lists.ietf.org; Sat, 07 Oct 2006 14:43:13 -0400 Message-ID: <001001c6ea40$8cabbe70$8be80b53@michal> From: "Mini BluRay" To: capwap-archive@lists.ietf.org Subject: moustache Aviators Date: Sat, 7 Oct 2006 20:43:58 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6EA51.50348E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.3 (+++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 ------=_NextPart_000_000C_01C6EA51.50348E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6EA51.50348E70" ------=_NextPart_001_000D_01C6EA51.50348E70 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Reckons well buy am before of years over. Bluray a mini side. Promises bit surround. Many shiny in reckons well is buy is before years of over. Info hydrogen car reviewed verdict Test Drive itunes Archive does =20 support. Hifi of separates cinema a Laptops. Weeks podcast Sept official. Wii high lets know how am many? Baftas dished Find winners a losers from. Archive does support therefore poll a Poll Using bargains cool kitin =20 retailer in zone. Greatest of gadgets in ever Plus or Beat charge Cameras in Cars bikes =20 Gadgets am! Alerts Create new group About Searched is all groups Your search. Pearl in of. Sure words. Latest or messages emailed a to Alerts. Quite Mini Bluray. Hidef Suddenly Hddvds? Advanced! Emailed to in Alerts Terms is of Servi ------=_NextPart_001_000D_01C6EA51.50348E70 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Reckons well buy am before of years = over.
Bluray=20 a mini side.
Promises bit surround.
Many shiny in reckons well is = buy is=20 before years of over.
3D""
Info hydrogen car reviewed verdict Test = Drive=20 itunes Archive does support.
Hifi of separates cinema a = Laptops.
Weeks=20 podcast Sept official.
Wii high lets know how am many?
Baftas = dished Find=20 winners a losers from.
Archive does support therefore poll a Poll = Using=20 bargains cool kitin retailer in zone.
Greatest of gadgets in ever = Plus or=20 Beat charge Cameras in Cars bikes Gadgets am!
Alerts Create new group = About=20 Searched is all groups Your search.
Pearl in of.
Sure = words.
Latest or=20 messages emailed a to Alerts.
Quite Mini Bluray.
Hidef Suddenly=20 Hddvds?
Advanced!
Emailed to in Alerts Terms is of Service=20 of.
------=_NextPart_001_000D_01C6EA51.50348E70-- ------=_NextPart_000_000C_01C6EA51.50348E70 Content-Type: image/gif; name="PM.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6ea40$8cabbe70$8be80b53@michal> R0lGODlhdAEQAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BACW2wAALAAAAAB0ARABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypUuUA2IO+BeT4Mya AmvKlJlzZ0+fNHfODAr0J06bQ2kOPBoUKVChPZEaFDr0qE6oL7Nq3RoSJ8+cTaMyDQs2qlmx Sb0mVSqV6Nmib9felLuWbFOraety3cu370O1acleLcg071K6gqvKJaxY8eGxeG3ahYw48lm/ mDNrDju37GC7oA+LFm15LGOwjjkjvnyZslTLoTfLns3Sq1i0RgEXNkwaa+6DPouqbRuaquve o2PTXs5cpO27uJXHTX63M0LTwb+qJo59NfXPiZv+ix8P8rnbn9TZTm9t3Srxx3N1C+eN2jv7 8KzJ698v0bz2/3V5B1t1o9mX3ICwFTZZgJXRZxp/EEYIHE8C4vUUXLtd2JZvp63nIVHDpQei hbtJaOKJKKao4ooWIcDiizDGKOOMNNZo44045qjjjjz26OOPQAYpJEEoDGnkkS+doKSSAi25 ZJMnEBTlP05OKaWVAzGZJZZaUhlllVNWmVCXBZEJJZROnnkmmGoi6WZGZH5pJZNPNumllGXG 2WWaamppZpwH8Zknl3QSeueaWLb55qIUAbqnnHMeaueVftbp5aOS/slloJZSGuaTemYqp0Fm MmqqQ6ViOiqVkgZ6aaH/fX4a6pULVUrqq6POCmurip7qK0Ni4hrmmmimimassSbKJq6c9srq pYjSemelfJb667UK7TotsXmWmeWWyL4qLUKpfnrrpNMamq6z1mLrrqGqbvnluOjSCiasmOIJ rqeC1gvurNA66+7Arv4757zHqvstqatGe+if9LYKMcMSH3wwxQRnzKyw9VJrLMWhqhpssPRO 3C3H8spbZ7sat+zyyzDHLPPMNNdsM4p63azzzjz37PPPQActdKORKqpntUhHvPGygG7ML6Sd Gk3ysk8bfbK0TG86qKUjk6zyxUOTK2ub/YqKJ8BWixxp01fnW+y+DydaMqQLp5xyyHtevW7d /tbmy/LQ1JIdtdusoi2x2VwfjrHZKsO9d7MGF924uHhLLrXivAoucNgPP2trxY5frnS8fma+ uNuf4z0mvJ2fnaa225Y+t+mm+y03528L+rnmW5e99Mjcej0u1XFfTjzo5ip77OPbNu847Eoz /jfgoHJtLtzlRm/wv9xGL3Ke6RS/vdj2do/uxSGbj/zttGdt0he+vr7yvdhvaji86N/tPdiP sqk6+dxbXt3sxToBGk9rtNMe7oYHNt4d7n4EDCC0FMbAfWkpfNra3eKcN7hmpc+A69NXAh24 wAqKrmLzGx3SqoU135EQdoXSnfBQRsFnnYxpKpRhp9rVr+mV8IdA/iwIO4KYo0UQ8Yj8MSIS lygeJTLxibNxIhSniJlFSJGKWOTKFbPIxS568YtgDKMYx0jGMprxjGhMoxrXyEbxlKCNcIyj HOdIxzra8Y54zKMeJUSFPfrxj4AMpCAHSchC8igNhkykIhfJyEY68pGQjKQkJ0nJSloyiMQg hkMyeSNOgoQfoOSHSkA5EFGyJJOo/IcnValJgaTSla2EJUFQ6UlaatKWt7QlK1Opy4LQkpUD yeUrYTnMXeYymMRcpSyT2cpVKjMivcQlM335y2jGspm/DGY2a4nNj5iSJaQUyDdT8kxnXtOc s4wlMIH5zHVq853wbCc3m7lObiZknq50/6dB7ClLdE7En+5s5zLjKcx8CrSexwToRsZZynCG 8h8Ofag4I+rQUhJElKbMKEUh+k2JQrQi5TxnP7sJz2VyUp7qDKg6+ZnOZKpSpfqkpkuPeRCA npSX2TRmP1s6UIWyM6X2rGZMCapTni7UIB39qFIxatGLKvWjSbVoRgvC1KU+daoUsaY1EWpU Y2JzmCHVJk4HGk+dorOXPBUmTfcp0pESNajFtGlb36nVWpo1pyYtqEw5wtCrWhWqTQ1lVa3K 0KlqlJRYxahgM6JLf96UrMqEK1v3qk+0ppWYMPXqXr861J6K1LFqfSxl5XrPanaTs5oVKz4p q5G+JjWxfn1tYP6fKs7aDraqhgWJaH/a2JX61q2szSxwN0vXuZK1nsVFCGlBG1OUltSnNaXp SUsKWaAWs7MXKaxUawtY226Xu7QFL2K/m1vu9vWfa93tbit72pQ217gsLSsy43tcu87XvZ5N bl7fO9n81te6XF2pTNf7064uVKIINi9Hw7ng2zbVqROd6Hj/6tHzbnKbn80wTjc8T5+ac6zV ne59wYpXs85ymkZFK4g7vNZ0xtW3Y60rPUcs2bSSVCsWVkiO43jQIPV4lBLZMY/xC6Qfa6UX l+SID5KMGXsw+clQjnIaASBlriyWqjai8kAAwGWDcPnL//hyl6uckajmSMxh3nJCqP6sZTIf 1bu43Sh498NmNQukzQXRMp7djJHXlle8c9ZPne9sZy/fGcx8zm6CvdtQj0oI0W3eM6ENneiK aJfRgUZRnSN9EEmnGUmVENqluwvo8NI5zZz+tKpV7elKO2TUh5Xwg+mM6DCPmdV5vrWrCdbq Xfes174OtrCHTexi04YOxoaRkIXMEWQnezlXbsiyTeJsjIDj2tf+B7azrW1wDMTb3cb2s0Wg 44lMmyTVvgi3vw3ubItb291+9kNgvWCOSrijFTX1RtKtbnCzWyDuFre31y1vhiy6u392MFY3 s+12bxvg4R74wwsubUbDVraYpk3D4x1vh3uc4BRHSHkv/v9dUjcn4AAf+L8JAvKQI/XBJMc0 bk8u8ZTD+9sFabnLo+1XwlY438zWysYj3m6WE93lr0Y6zYKu9EnWoOlQf4ksoo7GY1B9j0yH ELBx1IExCjbHWW9w2A8ydozsOdJovvrLDR7kMqMk7bfe+tV3fOWDu/aiFT1srOut740MutBy pzrPS13yu78836QebN818vdJ21rXaid7vaNad32Pc7FmVuxDy26RWq+60JFfO8x7rvjRy7zk mR7J3z0deKSbGdCZF/noY4/x1Hdk9YCXkR7M6OhG633WEL43bevOYMR/JO2P3zLkQ5/dN1PE F4zfjNWHzXmqMrgi0Dc7kLIAdV/+ZJ/54AeSDhQ5gvBjq/zmvxb6X4YOpa8//ad6P/wXJf/5 u6n+9kcS/vM/pP3z//8AGIACOIAEWIAGeIAImIAKuIAMmH6P0IAQGIESOIEUCEgTcDMkUIEa uIEc2IEeKBDa8IGLEgAkSIL/UIImeIIBMBArqIIlSBAo2IIuaIIpKBAxyII1OIMreIM6CIMo aIM/CIQvKIQ4CIQzqIIsKIRDaIQ22IMp+IQtyIOAlINIiIRDuIMyWBBQyIRcWIU+KINUmINU WIRWGIVmaBBLSINgaIZR6IVoSILwcIJuuIVlaEhheIY/iIUIQYdimIV3WIV/SIZvaIR8mIV1 eIRkmIf/bqiFL6iHiYiHhjiGd8SDlHiEUsiEUNiIfhiEaqiEbKiGS+iJmPiJkEiEPtiEeWiI MGiJnKiHmUiHfnSDW8iGooiDabiJp3iKNSiLkRiEo9iDXXiIoQiIRJiJq+iCixiDtziMgdSJ ViiIXeiMc4iLtuiLhKiK0ViKu7iJvNiHTXiN0LiGyWiMjGiHjkiDxxiOZziNuciFfyiJ7CiM 6+iOriiOcpiE25iOcjiGsKiL2GhHlMiJq3iJXgiKBomFmliEAamJwxiQCpmKD3mN6JiEOuiH A+mLsOiQIriRHNmRHgmASHaA1+AjIWmAI7kZW7dpFVGSFdF6J+KSEwGTCuGS/8vHFzB5kn2B ZimJaguRagLBkp1WkwQhd6wXk0LZk57nEGcXEcg3kw1BlENZkzLplI73lEk5lJ1WaDhpk3nW kzxJlaoGlAgBlV7pdxThk2cJETI5lWPZlVkZfTEJelhJaQSxlVwZlXE3ZptWa5DWZX2pZ5+n Z3wJZqlGmH75lYPZa4KZl63GaYMGaWq2mIupfHjGeow5aYn5mHqpl24Jd5sJmGzml2g3mZP5 eEvpeJCZfMkXmozJlh6RmoHJk44ZmblHaMsHmLZJm7kJeKCpm1Q5m2AZmqiJa7gHnG45l18p m76pkll5msbpmLiJm8tJnKBXmL65m8mJe1yhnTqZnf+mqZ3f+XmYOZ3QWZuoppM7SZ0zCZvW 2Zu2iZ6UZpiESZvPmZyHdphzWZ/YGZ33WZzTSZmjiZ/duZ+4tp3qqZzGOZxVKZ6fVp8+iZ8H GpVrNpzpaZ7u6Z9eVplYeZrKSaCNl6AN+p/eGaIOKqIhuqAY6p1omRUAUAElmqLgCaLj6aHV WaAjOqP5eZ2xiZwPSp41yqMHypwqumogKp0xWqDuOaQEWpuzWaJL6hJwZ2fdyZqjqXyHdp8L uppS+pesaaWF+ZlyOZ+YyZnIWZWe96Vgqpq5lqaqWZqm2aCf+aEQKqdGOqOeCad1+qOpeafc eZUl5JoPgQ/iAag7Qqg1Y6j/mnaUR+KnH9moFOEIjuoz1RepjoSovKZHYgZsfgqeZdqUb8eo aYmUmop2GdF4dhR4mlqWCpoSK9p5T4mUVqp9O5IIPFKZt9mf76mZ0mmjiYml1FmaSdmkvop8 kNmlKyqZXcmcXAqgw4qnddSjOSoIHRqbGoqjH0qeu4qW5RmkxJmnO6qtCOqjNMqhcQStUkqf Wwqhb9qfwkmhJpqpeOmtxTmgRCqe3nqiMMqtumqpMgIGWmee1qqk9nmvXiqu9fqWFhqhNmqf AXuuApuvQsqvU2SuAQuxQLqwFmumP5qwTrqjnWlnFUCtBuufnFozlKAVtnp2cwqneHqt6eqr akqv/20KeeS6rM0aq/a6smF6sy3brMjqEAkwMCfLRK4psUxJREOLREXLqooaNklLqfvxtFCb EUGbElI7teJxtVjLHFqrEbu3tSLRtWA7tmRbtmZ7tmibtmq7tmzbtsZmCm4bt3I7t3Rbt3Z7 t3ibt3q7t3zbtyThAX4rb8AQuIRbuH80DoZbEoiLRwLQuI4rAAPxuI9LEI5LuZKLEI17EJkb uZXLuZcrEJLbuQYxuZyruf+wuQVBuqhLuacbupBruabrua8LurN7urDbunS0upu7uqOru7XL u61bu8FLu7fru8S7EMY7vKmLu5o7u6IbucybEM8Lusd7vKgruo2LuMDLRv/Ju73Ee72/K7zK 67nVy7zdK769W7zTC7neC768y77oa7nvW76767zg+w/j4L1qdL7SC7+le7vQe724C7yZy78K QcDsO762277Oq8D+e8AOHL2l677/q79pdL+0G7oTbL+pK7wP/LoFLL4h/L/B+7kkPMEZHMDx K8DjC78azLotLMHW678jXL5w9MI2TML128HLO8DfK8Iu/LwWLMM+nMILvMINbMQPLL3ke8Tp O8A0zMFztMMnLL+q68EerMNLvMH0G79VXMQpvMUAHL4JPMRk7MQ8DMVQzA05zL1STMQyXMM5 /MZUPMNazBDd28FynMa2a8VwDMOy28WBnMFezB90v/AmBszHPwzA0Nu8gizBddy/xdu7YqzD lPzHjSy/j2zEDlzIaPS+QTy5oFzC7Yu5ZBy+POy6SKy7juy6hEy96avKPazIpMvIkOzJiZvL urzLvNzLvvzLm4ELwDzMxFzMxnzMyJzMyrzMzNzMzvzM0Ey4AQEAOw== ------=_NextPart_000_000C_01C6EA51.50348E70-- From pxvkkavyw@tolltex.com Sat Oct 07 18:42:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWKsB-0005Ok-1C for capwap-archive@ietf.org; Sat, 07 Oct 2006 18:42:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWKsA-0000pd-Tj for capwap-archive@ietf.org; Sat, 07 Oct 2006 18:42:23 -0400 Received: from p548fe60e.dip.t-dialin.net ([84.143.230.14] helo=p548FD927.dip.t-dialin.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GWKs8-0002Zc-2r for capwap-archive@ietf.org; Sat, 07 Oct 2006 18:42:22 -0400 Message-ID: <000701c6ea61$d72792a0$27d98f54@teste43a8efb59> From: "did not" To: capwap-archive@ietf.org Subject: which fixes sources Date: Sun, 8 Oct 2006 00:42:16 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6EA72.9AB062A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 ------=_NextPart_000_0003_01C6EA72.9AB062A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6EA72.9AB062A0" ------=_NextPart_001_0004_01C6EA72.9AB062A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Already reported same or problem theres or. Hasnt been always. Someone else has am already reported. Alerts Terms of Service Privacy or Policy or copy Orisinal Morning =20 Flash. Available a Build please am bear mind that am these link is specific =20 sections. Xml finalview feedback? Answers in for expert help with. Search get the of latest am messages emailed to is Alerts Terms of. Spelled of try or different keywords general fewer your a on am can try =20 am Answers for expert am help am with or. Orisinal Morning Flash in Games Effects Version Control Open Source =20 online home. Your on can try a Answers for expert help with search? News Maps more raquo in Advanced Search a Members users Join in. Searched. More raquo Advanced. Tarbz a archive in Kbview in books Docbook. From each get. Effects Version is? Toremain stable years. T ------=_NextPart_001_0004_01C6EA72.9AB062A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Already reported same or problem theres = or.
Hasnt been always.
Someone else has am already = reported.
Alerts=20 Terms of Service Privacy or Policy or copy Orisinal Morning = Flash.
3D""
Available a Build please am bear mind = that am these=20 link is specific sections.
Xml finalview feedback?
Answers in for = expert=20 help with.
Search get the of latest am messages emailed to is Alerts = Terms=20 of.
Spelled of try or different keywords general fewer your a on am = can try=20 am Answers for expert am help am with or.
Orisinal Morning Flash in = Games=20 Effects Version Control Open Source online home.
Your on can try a = Answers=20 for expert help with search?
News Maps more raquo in Advanced Search = a=20 Members users Join in.
Searched.
More raquo Advanced.
Tarbz a = archive=20 in Kbview in books Docbook.
From each get.
Effects Version = is?
Toremain=20 stable years.
Trunk or.
------=_NextPart_001_0004_01C6EA72.9AB062A0-- ------=_NextPart_000_0003_01C6EA72.9AB062A0 Content-Type: image/gif; name="Images.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6ea61$d72792a0$27d98f54@teste43a8efb59> R0lGODlhdAEQAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAB35QAALAAAAAB0ARABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypUuUA2IO+BeT4Mya AmvKlJlzZ0+fNHfODAr0J06bQ2kOPBoUKVChPZEaFDr0qE6oL7Nq3RoSJ8+cTaMyDQs2qlmx Sb0mVSqV6Nmib9felLuWbFOraety3cu370O1acleLcg071K6gqvKJaxY8eGxeG3ahYw48lm/ mDNrDju37GC7oA+LFm15LGOwjjkjvnyZslTLoTfLns3Sq1i0RgEXNkwaa+6DPouqbRuaquve o2PTXu4XjUrbd3Erj5v8bmeEpoN/VU08++rqnxP+Mx9PfiR0tz+rs6Xe+rpV4o/n6hbOG/X3 9uJZl9/Pv+L57QDW9R1s1o12X3IEwlbYZAJWVp9p/UUooULBdYfXU3DthmFbvp3G3odEDade iBfuNuGJJ4KA4oostujiiwaNAeOMNNZo440iRVFQAzj2OKEIPgZZXixCFmnkkUgmqeSSTDbp pEsnRBmlQFJKSeUJ6Ax0wpVWFjSll1tqGeaVYv5T5ZdnJvSlQWuWaWaab5Z5ZphtPmlnR21u ueaUXZoZp5ZgjvnmmFW6iaagf1J5UKFs5smnoI/KiWiid1aqUZ6JPkoopYgyyuighOoZKpgE TQrqol0W6mimojZq6av/GdXJqp9oUsomqK3+eeiqpZraK5le4honr5HaaiysyEIE55yKDsul rHQeCuyugab66a/GRhstp9vuam2y4FpUrLPkYgtos7pue6qbCEGrbqnnDgtpt++yG+69Cs07 a6h6movur3NGumen/uLa57+SmtunrPg2vJC+A/vJpcTAxgswxOrWqa+/GqPKrZijkurwyNVq myq2cMLr6qoRMyusyBUjPG3Kg4L8Lck454ysBDr37POL8Pws9NBEF2300UgnrfTSTDftdJN7 2uuop1QX/LLLmL7cq6o0x+yywY1WbXG2Jks7NtjPlj1pygw/LfLN67KLKa9S7xt11jBHbLPc /vXCLO+mWwfOctQc54ouw3q37bahZsdd8dwb193y3ZB6/Pi8epOp+OCA730q52MPrvKxifu6 +LQSm023uwWzrrmux+YdcrpeG+6qnLDDm+a4ztZaeOyIh6z46Z8vXG/mNl+bdtp0vq617Neq jrHyLDt/7rfVl1s78KaWTryaVn7a+Kx+Dz8un9bby7et0l8MPsDpUzxq9uj/3vb9y5qOZApQ hm/t18izXccSZr3wWY18A2OW6NoFMZAFa2UNnJj9KhczBn6vIZlb3exoFbl/na9fE+vg+mbm PhJaEHcSPJu84JfC7eFteOS74O1iSMP8WS1/nkKZ8kaouekZb4dY/mud5YKoPrQ9D390k6ES l8jEJjoRSXJ4ohTLE8UpWpE2VbyiFrfIxS568YtgDKMYx0jGMprxjC6CAhrXyMY2uvGNcIyj HOdIxzra8Y54zKMe98ikNPDxj4AMpCAHSchCGvKQiEykIhfJyEY68pGQjGQYvSHJSlrykpjM 5IsQQRFiEMMhngxSKEHCj1LyAyVx+EcpB3JKlnjylf8YZSw/KRBY1pKWtyTIK0e5y0/20pe9 nCUsg1mQXc5yIMC05S2VKUxiIEKWtCQmMnFJTGjiUiLVzCYzm5lMXlJzmbLkZi6PSc6OtJIl qxTIOVMSznJak5rXDKc3yznNYsJTl9G8/+Y4bQnMfeoTn8usJT3tOc5jWrOT9yxoO+sJUIPy cqAMDaVEE8qRdbIynaZUZStNec6MahSjrCTIKTeqToyuMp0fDSlCCepPcsoznvmEaDsPGtF/ elOi7uwnQm7qS4gq9J7GlKYxDdrQnDK0njONaVB96tJusnQjFlVlSEkq1Y4WZKRTVak6pcrV rHIVq1vtKjaH+kulxvSo4kzrQN850YJGtJlGleZbg/rPnyI1oW116EuPStO78pOscJVrU4Vp kIVeJKpWpSpYv5pRq1b1qlvdaGPDOlKOZiSYNM3rXmsqU332Va0NzadOm7rNhxLWsEbNZWa7 mdei9hW14pynaP7BCdO/2rSuFkGsV0maWK9+Vay/XSxYeQuS1k4UszAN7WjRmlrV1tW0DmVu UgXq3J1S1LhmfSpfr4tbgMpWusnF53TNCdnIUrarwkWvVrV60t2a97wYwW5cw9vShY6XnvNk aTwHq12X6pKprx2tbD172+2Cl6DfRSaClxtd5mrEsin9bVU9+tH0hlWkFy1peyVM4ag+JJt3 9etxRyzaz+Z0mBQN7H+FOtRp4lTBoD3xO/mL3IPI9aUoTms1V0xWBucXtirx8EKEPKHuLgnI RzZySoicECbTEclIgrImp0zlKlu5SdK48hOz3BcAaJkhGTAJhDEMkizjgC9eHggA1v5skDW7 +R9uZvOXM+JYknAZzW9OM5wT4mU9z/nBWR2uSev8kDtzpc9qTvRB0uznP2MkscRl74UdYuhD 71kgem60ouPs6Ed7tLcXpXBEKn1oOWd60ajudEUsCupJT4TUe0H0qducalVPhNW+VS9w+yPr TSsa07+2dURwTdlBr5c/nMa0nC/NbGVrWtj4eja0mSbtQKJi2i+ZA7a3ze1ue7tpTnbyt400 ZoaEezzgSHe6/6HudbMbHAOB97vVPe4h39rey3F3vOW9bnqz+931dgixJ1xZDXcUpLv2i74F 4u5+0xveCw+4Qj7t3se+1+Li1kq7+d1uhs8b4h2XuLnfq/9Y9baaNhsHOMA5zvKIi9wgkS55 qxeLbpAzHOL7LojLX05mXUfa4hivucr7TRB555znIhW1Y3nbYYRnPCsp/zi/iy51pI/c6kJ7 Ota3zvWue102/Pu62F+i9QhVe+wI4SiRy672w2JkFRBpdKaTjfaMl93VFLn7RZK97LN7nckQ pjje10lxyRo7wnqPe7OZ7feul/vCuCY03icMeZP3fCCY2AiiCTL3ZaMdw5MtNkg9TPjQm9yy ia/Im4PN+s8P3MI0l/TFT55wkWx+8cB2/bFnfmzZA533hCfJ7WeN+6+LOtSGl/x6UZ/0w2t0 8ppfPZz77vnPrxqqWmm89ens6dT+e0T72w8/f+oh/vKb//zoT7/618/+9rv//fCPv/x71Ir5 279GhLi//p3Ggn9UYf9F0n8AGIADSICO1AdkxAICWIAM2IAO+IAQGIESOIEUWIEWeIEYmIEa uIFOEwAe6IH/8IEgGIIBMBAlSIIfSBAieIIoCIIjKBAraIIv2IIlGIM0qIIiCIM5qIMpyIMy qIMtSIImyIM9CIQweIMjmIQnaIODNINCKIQ9WIMsWBBKaIRW+IQ4yIJOOINO+INQuIRgaBBF 6IJaCIZLiIVimIRoWIVfmEhbGIY5KIUIwYZcOIVv+IR36IVpCIR0OIVtGIReGIdoSIUpKIeB CId+2IX/emSDjBiETGiESliIdriDZEiEZkiGRWiJkHiJiOiDOHiEceiHKuiIlCiHkciGgRSD VWiGmiiDYziJn/iJL6iKibiDm3iDV/iHmYiHPhiJo4iCg7iCr7iLIGEMX1SJUKiHV4iMawiL rmiLfCiKy9iJsziJtFiHRxiNyliGweiLhOiGhuiCv7iNYdiMsWiFd6iI5qiL5YiOpsiNITiK 1TiO8diFqCiL0phHjEiJ8giNWIiJACmFkviD+yiJu7iPBBmKCRmN4jiENGiH/fiK7hiF+fg0 hcCBGJmRGrmRh6QjWjQPHPkzftdrLQF+K2KSE4GSCmGS1ddlE8JpI7lnMZl7/w4hfQjReM+m ks6WkjZZkwWhknS3kg2Bk5zXksVHEcQ3lD3JebWmkyohdwtBknzWelHJEESpeUhJlYr3EECp EVBZaxjhlIx3k2ApG3Infasna2hpamyWlqa2eIy2lm25aW05l5snl1M5fdQnbad2l28JbHHJ lp3HlG22l7knl34ZmDR5mG6pmDKpl9OnZoJ5aY35lYz3l40pk4iZfX8Jl4/Zl4lGfH2paYwW mqYJmIQZmY+JmlU5ljOpmTQ5fKs5m7eXmr8mm7hpmnzpma55m6pZmp4JmqzZbLMmnKdJm2Np acWZZ8gZZ7LpbHNJa705nH0mmqEJkzNpnDeZlr65mv+4iZ3SmWcwqZvHKZXQyZvGmZ6HeZ7q mZR055yUyZzUmZxbkZuoaZ/dyZs/GZvTeZn0WZuSmZfaWZbW6Z39WZS2CaCg2Z7EeZzrOZ8Q WpoMCqEPGpzl2Z9iCRL42WsT+p/FB5zNGWzPiZy+tp8Hqp/8maIhupiWuaEr+pmpqaD8aZ3F OZ8d6mc1ep8Xqp4vwXd0aZd6OZjKNqSQiXvyGZ+CWZ1zl5yZuZiQuZwg6qQ46nlQ6phLGaQ7 maWOiaVWeqRP6qDc+aCBGZdIqqINWqRjOqTPGZQQgQBIk6EsogJa+SpwajQZagstcqWWoqcs UgEhyRwVEKh/OhuB6qeDeqj/TVOnOKOoYwSffGaUI5qgfDoSbLp3VmmUAUqklsqoYqR9Z/ea 9IkSSWmpVhmVSxqWgTSlpHmempmYLHqbhomm5Imm1begWoqXnxmd6NmTHHqre2mlZXpHBVqi MCqlZ0qZYLqjUeqe1zmjyqqiX8msvWqjO4qiczSsFSqVaaqqnVeXvsmj0Mmt0Oqa4/mqqxqq wOmiDJqmdpRpz2CsvdmhyOqkalqtr0qg3+qg6GqkZpquGPqv2iqs+ZmtL1qbOdqgNxqjtumh CbuwBMt66lqtkXqtRXmW9hmd5XqvTVqkXFqxWQqxHoulWoqg9HqkOGqiYYqkwMquNWIN1rBI Ysmp/xKRZmSwkTGbEpOKqDq7szyLgdfQs0AbtEI7tERbtD7iA0abtEq7tEzbtE57NGr0p5XA HFH7tCxRtZBkCGCEtY2ktWHEtYrktVabEmI7tidRtmZbEmhrRhxQHoBQNGv7bW87NHGLECYg bHPrM3Vbb3mbtn77t4AbuII7uDgjAIZ7uAIwEIiLuARxuI27uAhhuAchuYrruJULuQKxuJZr EIxbuZP7D5RbEJ0buo0LupqbuI/7uZeLupnLuqCbuqZ7R6RLuaTLubPrurVruq6ru60Lu7fb uwvxu7wrurE7uay7uYpbvAmBvJkLvMAbuptLu7srR8Kbu54Lvbg7vcxruf/Vm73Ou7zeq7u7 m7jWq7ydm7zlu7rEq7zFi73Hi7rp60bdC77mO77ja76xm7uSO78Kob/kO7zNW77QC8CvG78F PLvs27vu67kJTL3vu7rnu78PDLvoC78KrL3kO8Hie77fq8Cte7wN7LzwO8Cne78AnMG2e8H5 q8F0pLkULLoTXLsy7MErnMIuzMD0C8Ov+8EBPL0ifLk9HLxAfMApXMMSjMMtPMIv/LiYK8Mm XL8NfMTsa8D+u8M8jMLGm7xAjMXLy8RErMNGzMUGzEbYi8RmLMUdbMVlPMVKLMI+DMbPC8No DMf2O8eqq75sjMfiOyGJgC/8C8cqbMZWDMZ/3L5ib/zCtGu7XEzHihzCpSvH33u77xu+TKQK IOHEG+y4mHzDnBu52Su813u6nozANnzDo5vFJby+gMzBHQzKhPvKsBzLsjzLtFzLtnzLuJzL urzLvNzLvvzLwBzMwjzMxPzLAQEAOw== ------=_NextPart_000_0003_01C6EA72.9AB062A0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 01:23:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWnc7-0001KJ-AT for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 01:23:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWnc3-0000qD-QB for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 01:23:43 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id A977F1448072 for ; Sun, 8 Oct 2006 22:23:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 46C594300EE for ; Sun, 8 Oct 2006 22:22:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1F42939806F for ; Sun, 8 Oct 2006 22:22:49 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 01B81398060 for ; Sun, 8 Oct 2006 22:22:47 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k995Mj7c016319; Mon, 9 Oct 2006 14:22:45 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k995MjS14816; Mon, 9 Oct 2006 14:22:45 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k995MiI11606; Mon, 9 Oct 2006 14:22:45 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 13:21:16 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013661C8@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbppxXG8vlRVt+XTGCZp/uvRyEy0wBuaiJg From: "Cheng Hong" To: "Scott G. Kelly" , "Margaret Wasserman" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Hi Scott, Some comments below: > After thinking long and hard about this, I can't bring myself > to agree with the suggested text. Quite frankly, I think > always using an RSC value of 0 is a lazy hack, and given that > we've acknowledged we are introducing a vulnerability here > (however slight), telling implementors they SHOULD do this > just doesn't sit right with me. > > An enlightened implementation could almost certainly do > better than always setting this to zero, and explicitly > recommending that people nail this window open just rubs me > the wrong way. At least, let's hold off on this decision > until we've clearly defined what statistics we expect to be > available. Seems like if we're going to tell implementors > what they SHOULD do, we SHOULD give them sound, well > considered advice. I absolutely agree with you on this point. What I was trying to state in my previous emails was: - I would against setting a static value for the KeyRSC as a solution to this issue. - However if the WG decided to go for a static value, the draft should clearly point out that NOT all static value could work (value other than zero may be a problem for interoperability). - And the draft needs to clearly point out what is the danger of setting a static KeyRSC value in the security consideration section. - Also, the draft should not prohibit other implementation for sync the KeyRSC value between WTP and AC (the CAPWAP standard should not dictate such implementation incompatible). If there is a alternative solution than setting a static KeyRSC value to narrow the window, I would vote for it. cheers Cheng Hong > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Saturday, October 07, 2006 8:26 AM > To: Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Margaret, > > Comments inline below... > > -----Original Message----- > >From: Margaret Wasserman > >Sent: Oct 6, 2006 9:39 AM > >To: Scott G Kelly > >Cc: Cheng Hong , capwap > > > >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > >While I am not against leaving things open to more optimal > >implementations, I do think that we need to add some text to the > >protocol portion of the document (as well as the security > >considerations) to explain how this is handled. How about something > >like: > > > >The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way > >802.11i handshake, unless the AC has knowledge of a more optimal RSC > >value to use. Mechanisms for determining a more optimal RSC > value are > >outside the scope of this specification. > > > >I do not think that we should simply say nothing and hope that > >implementors figure this out. > > > >Margaret > > After thinking long and hard about this, I can't bring myself > to agree with the suggested text. Quite frankly, I think > always using an RSC value of 0 is a lazy hack, and given that > we've acknowledged we are introducing a vulnerability here > (however slight), telling implementors they SHOULD do this > just doesn't sit right with me. > > An enlightened implementation could almost certainly do > better than always setting this to zero, and explicitly > recommending that people nail this window open just rubs me > the wrong way. At least, let's hold off on this decision > until we've clearly defined what statistics we expect to be > available. Seems like if we're going to tell implementors > what they SHOULD do, we SHOULD give them sound, well > considered advice. > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 03:11:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWpHx-0005Tw-Rq for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 03:11:01 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWpHv-0002xz-7N for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 03:11:01 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D77CF430300 for ; Mon, 9 Oct 2006 00:10:54 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id B4C754300EE for ; Mon, 9 Oct 2006 00:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 96243430278 for ; Mon, 9 Oct 2006 00:09:07 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 5B2714301AA for ; Mon, 9 Oct 2006 00:09:04 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id k99793YY003784; Mon, 9 Oct 2006 16:09:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k99793S25598; Mon, 9 Oct 2006 16:09:03 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k99794101367; Mon, 9 Oct 2006 16:09:04 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 15:07:49 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0136620B@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbppxXG8vlRVt+XTGCZp/uvRyEy0wBuaiJgAAQFBzA= From: "Saravanan Govindan" To: "Cheng Hong" , "Scott G. Kelly" , "Margaret Wasserman" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Hi Cheng Hong, Scott, I share your concerns for setting the KeyRSC to 0. In my opinion, it is clear that the protocol is "broken" in this case and needs to be fixed. My suggestion is to have the KeyRSC field be updated by the WTP. So the AC could send Message-3 of the 4-way handshake to the WTP with an empty KeyRSC field. The WTP could then correctly update the field, compute the KeyMIC, update Message-3 and then forward it to the STA. Of course, this requires a CAPWAP message from the AC and WTP to exchange the incomplete Message-3. I think this is an acceptable addition because it maintains the integrity of 802.11i exchanges and provides a complete fix to the problem. Saravanan -----Original Message----- From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] Sent: Monday, October 09, 2006 1:21 PM To: Scott G. Kelly; Margaret Wasserman Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Hi Scott, Some comments below: > After thinking long and hard about this, I can't bring myself > to agree with the suggested text. Quite frankly, I think > always using an RSC value of 0 is a lazy hack, and given that > we've acknowledged we are introducing a vulnerability here > (however slight), telling implementors they SHOULD do this > just doesn't sit right with me. > > An enlightened implementation could almost certainly do > better than always setting this to zero, and explicitly > recommending that people nail this window open just rubs me > the wrong way. At least, let's hold off on this decision > until we've clearly defined what statistics we expect to be > available. Seems like if we're going to tell implementors > what they SHOULD do, we SHOULD give them sound, well > considered advice. I absolutely agree with you on this point. What I was trying to state in my previous emails was: - I would against setting a static value for the KeyRSC as a solution to this issue. - However if the WG decided to go for a static value, the draft should clearly point out that NOT all static value could work (value other than zero may be a problem for interoperability). - And the draft needs to clearly point out what is the danger of setting a static KeyRSC value in the security consideration section. - Also, the draft should not prohibit other implementation for sync the KeyRSC value between WTP and AC (the CAPWAP standard should not dictate such implementation incompatible). If there is a alternative solution than setting a static KeyRSC value to narrow the window, I would vote for it. cheers Cheng Hong > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Saturday, October 07, 2006 8:26 AM > To: Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Margaret, > > Comments inline below... > > -----Original Message----- > >From: Margaret Wasserman > >Sent: Oct 6, 2006 9:39 AM > >To: Scott G Kelly > >Cc: Cheng Hong , capwap > > > >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > > > > >While I am not against leaving things open to more optimal > >implementations, I do think that we need to add some text to the > >protocol portion of the document (as well as the security > >considerations) to explain how this is handled. How about something > >like: > > > >The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way > >802.11i handshake, unless the AC has knowledge of a more optimal RSC > >value to use. Mechanisms for determining a more optimal RSC > value are > >outside the scope of this specification. > > > >I do not think that we should simply say nothing and hope that > >implementors figure this out. > > > >Margaret > > After thinking long and hard about this, I can't bring myself > to agree with the suggested text. Quite frankly, I think > always using an RSC value of 0 is a lazy hack, and given that > we've acknowledged we are introducing a vulnerability here > (however slight), telling implementors they SHOULD do this > just doesn't sit right with me. > > An enlightened implementation could almost certainly do > better than always setting this to zero, and explicitly > recommending that people nail this window open just rubs me > the wrong way. At least, let's hold off on this decision > until we've clearly defined what statistics we expect to be > available. Seems like if we're going to tell implementors > what they SHOULD do, we SHOULD give them sound, well > considered advice. > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 04:33:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqaB-0005ka-3v for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 04:33:55 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWoXl-0003Yk-Py for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 02:23:21 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id EFA861448045 for ; Sun, 8 Oct 2006 23:23:09 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 7A7704300EE for ; Sun, 8 Oct 2006 23:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A22939803E for ; Sun, 8 Oct 2006 23:21:25 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0269D39803D for ; Sun, 8 Oct 2006 23:21:22 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k996L5MX008306; Mon, 9 Oct 2006 15:21:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k996L5A07191; Mon, 9 Oct 2006 15:21:05 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with ESMTP id k996L5120770; Mon, 9 Oct 2006 15:21:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 14:20:01 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013661EE@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbpQ4LS1YbmmH+RSIWr69IX+R2VgACJvF6A From: "Cheng Hong" To: "Charles Clancy" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Hi Charles, > appears. For example, the WTP would need to communicate it's > ability to be queried for the KeyRSC to the AC during initialization. Yes. It would require AC to know if WTP supports the sync of KeyRSC value. If WTP doesn't, AC could choose to set a static value for KeyRSC. The capability exchange has already been in the CAPWAP protocol for initialize the connection between AC and WTP. This probably is just another bit to be defined. cheers Cheng Hong > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Friday, October 06, 2006 8:33 PM > To: Cheng Hong > Cc: Dorothy Stanley; capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > You're suggesting the disclaimer and "static initialization value" > (perhaps more accurate term than a "default value") would be > mandatory to implement, and there would also be an optional > information exchange to synchronize the KeyRSC to something > else. That certainly sounds like a good compromise, but I > suspect a little more complicated to implement than it first > appears. For example, the WTP would need to communicate it's > ability to be queried for the KeyRSC to the AC during initialization. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Cheng Hong wrote: > > Hi Charles and all, > > > > To specify a "default" value means specifying it to "zero". > Otherwise, > > it would not work. Say, the "default" value is set to 100, but the > > actual sequence number used could be 50 at the moment. It means the > > STA is not able to receive the Broadcast/Multicast packets for the > > next 50 seqeunce count. > > > > So, I think we need some clarification on what is the > decision here. > > Is the decision now: > > - No change to the protocol design except some security disclaimers. > > And, specify a default value (0) to be used by the AC always. > > > > Or, We also allow: > > - The WTP and AC can choose to implement info exchange methods (a > > simple element to be specified in the draft). However, if some AC > > choose not to support such mechanism, it will have to set > the KeyRSC > > to zero. And a security disclaimer to state what is the effect of > > setting the KeyRSC to zero. > > > > cheers > > > > Cheng Hong > > > > > > > > > >> -----Original Message----- > >> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Friday, October 06, 2006 9:24 AM > >> To: Dorothy Stanley > >> Cc: capwap > >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >> Considerations > >> > >> We'd definitely need to specify a value for keyRSC in the > appropriate > >> section. That would be in addition to the changes to the security > >> considerations. Without specifying a default value, we could have > >> interoperability issues between WTPs and ACs. > >> > >> -- > >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >> > >> Dorothy Stanley wrote: > >>> Behcet, > >>> > >>> My understanding of Scott's recommendations is that text > be added > >>> into the security considerations section. > >>> - no additional CAPWAP protocol exchange between the WTP and AC > >>> - no specification of setting the keyRSC value to 0. > >>> > >>> Without some specification in the protocol, how can the > WTP provide > >>> the KeyRSC info to the AC in a way that the AC is sure to > >> understand? > >>> The most we can say > >>> with respect to the standard is that an AC implementation > >> is free to > >>> comes up with its own algorithm to set the keyRSC value. > >>> > >>> Dorothy > >>> > >>> On 10/5/06, *Behcet Sarikaya* >>> > wrote: > >>> > >>> I agree with this and suggest adding Peter's fix as a > >> possibility. > >>> As far as interoperability is concerned, value 0 is > >> interoperable > >>> but not correct. If we allow implementations to snif in > >> and modify > >>> then any value should be acceptable which may be a concern for > >>> interoperability? > >>> > >>> ----- Original Message ---- > >>> From: Scott G. Kelly < s.kelly@ix.netcom.com > >>> > > >>> To: capwap > > >>> Sent: Thursday, October 5, 2006 3:15:40 PM > >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > >>> Considerations > >>> > >>> Following up once again - after careful review, I still > >> agree with > >>> Charles, and here's some suggested text for the > >> security considerations: > >>> 13.5. IEEE 802.11 Security > >>> > >>> When used with an IEEE 802.11 infrastructure with WEP > >>> encryption, the > >>> CAPWAP protocol does not add any new > >> vulnerabilities. Derived > >>> session keys between the STA and WTP can be > >> compromised, resulting in > >>> many well-documented attacks. Implementors SHOULD > >> discourage the use > >>> of WEP and encourage use of technically sound cryptographic > >>> solutions > >>> such as those in an IEEE 802.11 RSN. > >>> > >>> When used with IEEE 802.11 RSN security, the > CAPWAP protocol > >>> may introduce new vulnerabilities, depending on > >> whether the link > >>> security > >>> (packet encryption and integrity verification) is > >> provided by the > >>> WTP or the AC. > >>> When the link security function is provided by the > AC, no new > >>> security > >>> concerns are introduced. > >>> > >>> However, when the WTP provides link security, a new > >> vulnerability > >>> will > >>> exist when the following conditions are true: > >>> > >>> o the client is not the first to associate to the > WTP/ESSID > >>> (i.e. other clients are associated), and a > GTK already > >>> exists > >>> > >>> o traffic has been broadcast under the existing GTK > >>> > >>> Under these circumstances, the receive sequence > >> counter (KeyRSC) > >>> associated with the GTK is non-zero, but because the > >> AC anchors the > >>> 4-way handshake with the client, the exact value of > >> the KeyRSC is not > >>> known when the AC constructs the message > containing the GTK. > >>> The client will update its Key RSC value to the > >> current valid KeyRSC > >>> upon receipt of a valid multicast/broadcast message, > >> but prior to > >>> this, > >>> previous multicast/broadcast traffic which was > >> secured with the > >>> existing > >>> GTK may be replayed, and the client will accept this > >> traffic as > >>> valid. > >>> > >>> Typically, busy networks will produce numerous > >> multicast or broadcast > >>> frames per second, so the window of opportunity with > >> respect to such > >>> replay is expected to be very small. In most > >> conditions, it is > >>> expected that > >>> replayed frames could be detected (and logged) by the WTP. > >>> > >>> The only way to completely close this window is to > >> provide the > >>> exact KeyRSC value in message 3 of the 4-way handshake; any > >>> other approach simply narrows the window to varying > >> degrees. Given > >>> the low relative threat level this presents, the additional > >>> complexity > >>> introduced by providing the exact KeyRSC value is > >> not warranted. > >>> That > >>> is, this specification provides for a calculated > >> risk in this regard. > >>> ==> > >>> However, WTP implementations MAY provide the exact > KeyRSC value > >>> before forwarding message 3 of the 4-way handshake. > >>> > >>> --behcet > >>> > >>> > >> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, > >> please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > >>> > >>> > >>> > >>> > >>> > >> > --------------------------------------------------------------------- > >> - > >>> -- > >>> > >>> _________________________________________________________________ > >>> To unsubscribe or modify your subscription options, please visit: > >>> http://lists.frascone.com/mailman/listinfo/capwap > >>> > >>> Archives: http://lists.frascone.com/pipermail/capwap > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From camdeni@gambrobct.com Mon Oct 09 08:30:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuGp-0004Hu-Uh for capwap-archive@ietf.org; Mon, 09 Oct 2006 08:30:11 -0400 Received: from [86.57.255.181] (helo=gambrobct.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWuGj-0006GX-E7 for capwap-archive@ietf.org; Mon, 09 Oct 2006 08:30:11 -0400 Message-ID: <000001c6eb9e$37383b30$08eaa8c0@xxtrz> Reply-To: "Hena Fitzsimmons" From: "Hena Fitzsimmons" To: capwap-archive@ietf.org Subject: Re: VbAGRA Date: Mon, 9 Oct 2006 05:26:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EB63.8ADBAD20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EB63.8ADBAD20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 VbAGRA for less http://www.badeyunjinmdasetion.com =20 _____ =20 Very much so, Jim. We have all been awaiting your report. Can you I slammed the panel shut and punched in a command. A cup of steaming Wazza? I said incoherently, still numbed with sleep. ------=_NextPart_000_0001_01C6EB63.8ADBAD20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
 

Very much so, Jim. We have all been awaiting your report. Can = you
I slammed the panel shut and punched in a command. A cup of = steaming
Wazza? I said incoherently, still numbed with sleep.

------=_NextPart_000_0001_01C6EB63.8ADBAD20-- From qhjqoohxyd@txdemocrats.org Mon Oct 09 08:43:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuU9-00049j-HW for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 08:43:57 -0400 Received: from ppp15-32.adsl.forthnet.gr ([62.1.238.32] helo=ppp89-139.adsl.forthnet.gr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWuU3-0001Cc-Mq for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 08:43:57 -0400 Message-ID: <000701c6eba0$85c85030$8bfe4ac3@livingRoom> From: "month" To: capwap-archive@lists.ietf.org Subject: Cite Date: Mon, 9 Oct 2006 15:43:29 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6EBB9.AB158830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ------=_NextPart_000_0003_01C6EBB9.AB158830 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6EBB9.AB158830" ------=_NextPart_001_0004_01C6EBB9.AB158830 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Help or with search a get the latest. Create group About Searched. Downloads Podcasts Funny Videos. Would of killing kindle such hatred or nation make necessary them. Asia Movie Review or Kung of Slovakia Viva Liptov part Vijuice of =20 Revered. Fantasy plain of fashion retro. Layouts gtgt much choose a never decide is. With search get the latest or messages is emailed. Masters cruela Voyage Abyssinia Lobo had respect of father best tempered =20 revolt youth who has Fantasies am Stevenson Robert. Drop juice Song in if like Hong of Kong Asia Movie. Cruela Voyage Abyssinia Lobo had respect is father best tempered is =20 revolt in. Surfers is Browser extension day Myspace Layouts Pollsbull Upload or =20 Picsbull! Smoothly? About Searched all groups. Help with of search get. Members users Join Alerts? Add site warning only. In Wikipedia sec Page. ------=_NextPart_001_0004_01C6EBB9.AB158830 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Help or with search a get the = latest.
Create=20 group About Searched.
Downloads Podcasts Funny Videos.
Would of = killing=20 kindle such hatred or nation make necessary them.
3D""
Asia Movie Review or Kung of Slovakia = Viva Liptov=20 part Vijuice of Revered.
Fantasy plain of fashion retro.
Layouts = gtgt much=20 choose a never decide is.
With search get the latest or messages is=20 emailed.
Masters cruela Voyage Abyssinia Lobo had respect of father = best=20 tempered revolt youth who has Fantasies am Stevenson Robert.
Drop = juice Song=20 in if like Hong of Kong Asia Movie.
Cruela Voyage Abyssinia Lobo had = respect=20 is father best tempered is revolt in.
Surfers is Browser extension = day=20 Myspace Layouts Pollsbull Upload or Picsbull!
Smoothly?
About = Searched all=20 groups.
Help with of search get.
Members users Join Alerts?
Add = site=20 warning only.
In Wikipedia sec = Page.
Google.
------=_NextPart_001_0004_01C6EBB9.AB158830-- ------=_NextPart_000_0003_01C6EBB9.AB158830 Content-Type: image/gif; name="killing.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6eba0$85c85030$8bfe4ac3@livingRoom> R0lGODlhdAEQAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVAAAALAAAAAB0ARABBwj+AP8JHEiwoMGD BQ4qXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGMmiUmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrtstmsePHkCNTdSG5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk279tEhtnNnxK27N0XevoM/HAJcLTfh yJMrb2psufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djr7wgv779 +/JJ4FctYb///wAGKKB/ogxo4IEI6nVEggw26OCDEIL3QYQUVmjhhRhmaNQvGnbo4Ycghiji iCQixUKJKIZXzlMLCOVOijDGKOOMNJqnBlqO1Kjjjjx+eKNXWvTYmwxCFmnkkUgmqeSSTDbp 5JNQRinllFRWaaVcESjUwpVcdunll2DuFEuYZLJFSZlOnYkmU2quqVSbVYIip5t0XhlPnXjm qWeCd+7p55+ABirooIQWauihYXaC6KJWPaBWNzw6GlM9jA4kaaU1PXApppx26umnYDUC6qik lmrqqaimquqqrPbFwonU5KXS6qy01hqYPLbmquuuICnD66/hDQPssMRq5kSxyJ76Y7LMNuts RiY8K+201FZr7bXYZqutZRNs6+234IYr7rjfbfmtud6iu6262rKbrbvYwnutvAN9Iy291eJL rb7ksoSKuP+GGzC4Aw/WhwIPFuwtKgr36/DDEEcs8cQUZ4RLxRhnnNYBGg9ETscghyzyyCTv yUnJKEO0R7grsyxuy+DC7F4YXLFjM1Aye5vztjtr23PKQAfN7CdCF2300QPZgvTSTJtlSNNQ Ry311FRXbTWMAQEAIfkEAJDbAAAsAAAAAHQBEAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKlS5QDYg74F5PgzJoCa8qUmXNnT580d84M CvQnTptDaQ48GhQpUKE9kRoUOvSoTqgvs2rdGhInz5xNozINCzaqWbFJvSZVKpXo2aJv196U u5ZsU6tp63Ldy7fvQ7VpyV4tyDTvUrqCq8olrFjx4bF4bdqFjDjyWb+YM2sOO7fsYLugD4sW bXksY7COOSO+fJmyVMuhN8uezdKrWLRGARc2TBpr7oM+i6ptG5qq696jY9Nezlyk7bu4lcdN frczQtPBv6omjn019c+Jm/6LHw/yuduf1NlOb23dKvHHc3UL543aO/vwrMnr3y/RvPb/dXkH W3Wj2ZfcgLAVNlmAldFnGn8QRggcTwLi9RRcu13Ylm+nrechUcOlB6KFu0lo4okopqjiiiy2 6OKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkCaeYKSRAh15ZJInENTkP0o+6aSUAyFZJZVW QtlklE9GmVCWBYHJJJNKjjkml2YSqWZGYG4pJZJLJqmlk2G2mWWZZlopZpsH4VknlnACOueZ VKa55qEU8Xmnm28OKueUesap5aKO7olln5JC2uWSdlbqpkFiIiqqQ6FS+imUjvY5aaB5btrp lP8LRQrqqp++ymqqho6qK0Ne0trlmWSWSmarrRaKJq2Y5orqpITCOmekeIa667QK3fossHWG WeWVxK7qLEKlbjrro88KWq6y0lKrrqCmXrnlt+TCyiWrlNLJraZ+xsvtq8wqq+6/qu775rvD mrstqKc2O+ie8KbKMMIODzwwxABXjKyv8UIrLMSdmtprr/A+nC3G7robZ7oWp6zyyiy37PLL MMcs88wWM0PzzTjnrPOu5ezs889fNmqondEW3fDFx/J5Mb6MZjo0yMcyPfTIziZ96Z+Sfgyy yRMDHfSwnlp6r5z8Tu1xo0pTXW+wY8sKLrt3/glpxP0uO/a5B+Oaptv+Xifb76Jim22w4AKj fbXaXbP9tN53Byq0yWx3HHfICdstbb0oe63nsm7zG27DnwO7eeZ7J9453F/vu7C2Xlp77eaU M8445oX2ram33ZaOcNRcBws7nL6/zbW5fJebL93iGgu268BfG3u6l3dNukEO3Fymn8Wv3Xjt 8k6cPMWI4xopKMhzv/j39lpeefPNby879FpHVD3N1588b9uXlm033s4zOzj+peMSKCSXOmzV TV8KM6DTCJi36U1PIfOb2do8lzhU6Q91Cmzf7EwnLoHdC2UdK1n6uicvEbovbaTT3kMiGLMJ Goxo2aud1qJVteMB0IOFy9rWfPeru+3vgx/+O1rUtgY//a0wFrbjEflkhsQk6miJMGuiE3ME Cii2TIpTzOKJsKjFLu6Hi14Mo3jAKMYyyoaMZkyjGtfIxja68Y1wjKMcZ1aIiBhhjnjcCBls xI48jmqPN+qjHw8FyEAOUk2FpAgiICTIQwYpkYpkpCOBBMmKLJI/7GjkJHNUSYsg4pKbxGMn LwLKUMJxlKZM5Yr+oMpWuvJl2HilLGdJy1ra8pa4zCW1wKDLXvryl8AMpjCHScxiGlONxCCG Q5JZI2aChB/Q5IdKoDkQabIkmdj8hzO1qUyBZNOb3QQnQbDpTHIq05znNCc3s6nOgpCTmwNJ 5zfBOc91pjOe9Nz/pjjz2c1t6jMi7UQnP935zoCGs5/vjGdCy4nQj1iTJdQUyENT8k9/HtSi 4wwnPOH5z40q9KMg7ShD+7lRhiZkpN70qEFMKk6MTsSlHu3oPkMqz5TKtKT3hOlGJlrNiEbz Hz79qUSD6tNqEkSa1kwqUYH6UKECtSIVvWhLGwrSfTJTpBqNqUZZmtF8alOrKiWoV+95EJhe lZ0JtWdLuzpTnXI0qyYtaFhpqla27tQgTX2qXpFq1KPq9al5NWpSC8LXvf51sBQxqEFxald7 InSeUVUoWmcaUrVitJ1slSdZVyrVqdI1rvU0a2c/qthyWjatVq2pWDnC08MaFrB9jWZh/g3L 08EqlZqIRapsM6JOl56VsvoELWdXq1LMZpaeYHXsah8717ZK1bea/S1xRXvSgjaUucqVLEqJ q5HW5jW3rv1ubP8q0fLOtrC2BYl039rbrbrXs9xNLnyXS9rRUrak9UUIdaG70QPcV75uLStZ r1pV4MK1ns29SG0FW17YmpfBDSZvhHEL4fQ2uLUv3ex611vc62Y1rDrlamXxKeL7mpbEH3Zu flPrUf9itapujWxcxylWDr+1sQPpgoKFyuMLMzWiPz5vX/061KFS+LVOxfAyF/rcJqP1ySON 8UUna2ACoxiyqLUsjbML47RSOcqbzWho3TvZ0pL0ysLNLFW1/qJkhbT5lTediH9VFOdpSuTN cE6xnOms52O6aM5+9iOgA43HQRP60JMEAKLFs1vC0kjRAwGApA8iaUhHetF2jrCNKq1oS1ta IJ6O9KcxXRLxonepmtZPpy8N6oKE+h+rJvVJvmvhCaeaPLGGNat3HetRy1okjRZvT50qoUq3 +tgE4TSsld0QDfzaIgt+8JBVtOpXUzrZzy61o6Vtawnvp9qsHrW4s02SaO8V1d4eD7OXbe1J u5rcOfM1vMMobxo5Y974zre+JzKCffv73zrDM54BvqZGN0TgzQGHwhX+j4UzvOHgGEjEIb5w gmdk4AdB+HIeLvGJM7ziDYe4xVm7/23A4va2TS1quvvCcYE8/OMVj3jLR46RHku71kJGbEXc UBKHe9zhLqe4zIFO8+7e3MfCdvDGgf5ymbu86SAvuoKPTlsIKz3hQ396yLVOkJlLfSKBRXJ4 K4x1kYt84kHvOtrJc4ZUGty1tE2yyjGeFZ8/HeRrH3rUv15zvnuN7n4PvOAHHxEtZCYdsuEG 4RfPeBQBnj/1bnzN317yg1P+zikZN6jXLXmHYPzxtwY7Spjtbl13XvQJCbbKvT3RHqPcyLBf uUZyjezIn97NxO621b2bcabaOumyzwjtTc9u298+9T+Ge7DT3fqfhl23zh996YmP7eNDxNxC vvqQkw784P5/JNfyNr714b598iv5+eYf+7RBAn5e46gWccy9kV8fevLutvnoXv33jb15T09/ /A51V1khfgA4EqCXcUD2EgRYgGtUAmvyCww4SOgQgRRYgRZ4gRgIM1aQgRzYgR74gSAYgiI4 giRYggghDhjxCCa4gizYgi74giUhCzA4gzRYgzbIFfB3gzq4gzzYgz7od+ZAI4PAgvrwg0Z4 hEiYhEooEQHQhE34D074hFAYAANBhVPohAQRhVZ4hU8ohQKhhVXohVxIhWA4hlkYhV+IhmmI hWsYhmnIhVNYhWvIhm/4hWYohXhohWUITGIYh3HIhmS4hQWRh3VYiH54hlvYh/9i2Idu+Id6 +IgGQYddmIiPqIeHGIl4eImE6IjGpIiQiIaBiBCbuIiC6Il+aIqNiIlvOIqCyIlw2IigeImD iIWhCIuf2IqMeEtluItwuId1mIe0WIpqOIlzWImTSIfF+IvGeItteIZ2CIqtmIW9OIyhCIyb mEQk4BJgSIiVmIxhKInC6IzO6IXbiItqqIxmaIiuiIyn2IbAKI1XKItaCI7sGEzE+IepaIj3 qInh+I3nuIrRqI/MSI7CWI6kaIcAmY+UKI/vOIudWItdCI8KCYn8KI6FaIq5WJHrSJEXWY0L CYXSSJASCZKMeI3jGJC2tIvDGJL/eIjH+JKBGIxuqJL/wciOKjmT0IiTABmRcjiGpciS4NiR gIiSS2hKDliUSJmUSrmUTOlnxgduLbGAJyKVE0GVCiGV/9cXVokZyvaUuuaVyNYQ/JcQ4hd+ VZmVYjmWD6F5a6mWZCmWDPFpbhmWF2FtaYmWdFl7ssGWCAGVb5mXC1GWcckRW6mXC0GU1DeY EFGY11Z9BsGYjSkRdumYlLmXrjaW/FdtmOluxpaZnJmYkLZuXRluk9aZX9l/ohZ5obmZ9RZq vfaZrbaanFl6ahl+tAmbrPmaskmXsrmb7Babv3mbu+mbnEd8/heaqBmcxZeakEmYsAmap+ma l9Zu0+lryAmc2HmavIac0hmY/3oJll95ndoZndNZno95ntnpl+03fOYZbu3pmtcpnulpnPTp fvQ5bt05ns3pEe23nOpZfP0JoIl5bPm5ntQZm10JlvnZl5lpn712nwmKnp05msBZoOPZf8Mn ngHan/FpmvNpl6JJoRSqn/VJEjwAlxb6n2w5mWZ5n+8paiXKnsv2lwsamYZpeg9ao5tHmRla nilKfTWqoTFan9z5ohbqnrzpoh+6a1qxnj6qpCT6nY35o2G5oSWKoxLanknqmAdKoiD6bkta oUYKpFqKpfN5pkUaplFqmNJJpWsalQ1KoKbZaawJozP6mwPqoTjqmaV5m0Q6myxamqQpn9CZ mlyKof/JOZfLiad46pv+mah6qpzZ2ahI2ps7SpxMKpeJiqgzyqGK6kT7SW3UEqovQ6om8qlE gqpNuaqs2qquiiKmqi6xCkecZnuKGqA8qqoiUZx1GZd4uaPA2quzSh6RcCMEaKveaZ+Zx6S9 qphk6X/C5yPFWiNymZWWGp66WaXbeZybKqaN+n9tCqnCWaGCuqXFCW7EmZub6qg1Mq0z0qUE +qRJqqnxOqkpKp9fiqBS+qFCaq6ZSp5u6qR8SSOR4K4wAq9mSp5yWq6cKqC0OaZVynmk537w qaeaap03aqZOqqZQyauqhLBCurEX2q+XCaW42ppgarKFSqYYe6XxqbI/iqv/rgSyUuqmRPqv AXuozEqdOVuZ9Uqm2Jaz4TqZrVSt4sawr7mnDAu0fGqoiGq0ybmzyQao3AqkRGuxlYmpC4up 15qEjDmsa/mqPusQYBuYvyq2aJu2aru2PnIPbPu2cBu3cju3dFu3dnu3eJu3eru3fNu3frsm 3vC3gju4hAshMlC4iJu4iru4jNu4RDKEaWsBjju5lFu5ICGDLigAmru5AjAQnMu5BLG5ofu5 CKG5B2G6niu6qUu6AvG5qmsQoJu6p/sPqFsQsVu7oUu7rtu5ozu7q8u7rQu8tNu7uktLuIu6 uAu7xyu8yau7wuu8wUu8yxu9CzG90Gu7xXu6wPu6/56bvQnBva1LvdRbu6+LvM/bStbbvLJL vsx7vuCruunbvuL7vfLrvM/buerrvbHbvfn7u9jrvdnLvtvLu/0bSvFLv/p7v/erv8XbvKZ7 wArhwPh7veGbv+RLwcNbwBl8vAAcvQIsux2MvgP8u/v7wCNMvPxLwB7svvh7wva7v/PrwcG7 vSEsvgR8wbu7wBTcwsq7wg3swq/kuihsuyecvEYswz/cw0IMwghMxMM7wxV8vja8ulFcvVS8 wT2cxCbMxEF8w0M8uqxrxDqcwCG8xQCswRL8xFDMw9rbvVTMxt8LxljsxFoMxxpMEUfZRezL xXxsxjGsxnt8xl5sw1JMx5jjS8R+bMgKnMi+67+C7Mj2OxJ5rMf1q75i/Mj/m8UQPL6FPMTI q7xwrMigDMAZALujjMlQnMp/fBGTTMlOnMMdbMIwnLttDMmx3MJLDMrM28a7O8MqrMS9TMuG HMnDjMoZ0cqWqxHInMzM3MzO/MzQTLdlG83UXM3W3BK6cM3aTEt0sM0xUwfeDEd7EM7kXM7m fM7ozCMBAQAh+QQAFwAAACwAAAAAdAEQAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIseLD DxYzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJk6SEnhODAR1aUxLR o0iTKl3KtKnTp1CjSp1KdaKQqlizat3KtavXr2DDih1LtqzZkHRUMjvLtq3bt3Djljwgt67d u3jz6t3Lt6/fv4ADCx5MuLDhw4gTK3a4YrHNU46fNo78b5dMyJSZTs4c8xRmzkg3gx7tVzTp 03lNo17NurXr17Bjy55Nu3bbB7Zz697Nu7fv38CDCx9OvLhxgleOK1/OvLnz59CjS59Ovbr1 69iza9/Ovfvvd97D/osfT768+ZtgzotPrz48+/bd38OfT7++/fv4808MoL+///8ABijggAQi ZkeBCLZXQYIMNujggxBGKKF+Pkxo4YUYZqjhhhx26OGHIIYoIkpSjGjiiSimqOKKLLbo4osw xijjjDTWaKOHAtyo44489ujjj0AGiVCOQhZp5JFIJqnkkkw2mR8nQGLj5JRUVmllV/hkeSVc WeLTGgkodrnlW16OaeaZaKapZl/erOnmm3DGKeecdNZp550CboHnnnz26eefgAYq6KCEFmro oYgmquiijDYaVT+ORiopShNMaumlmGaq6aYQ3sLpp6CGKuqopJZq6qk8zrLlGWypmmYO62K5 impJss46Uq22hoTrQinkGtGuvnYEbLAbDUtsRsaeBA91I+S37LEfPQttR9JOu1G11l4ZQkLx ZOvtt+CGKy6c6YxrHCjmpqvuugsds2Is7MYr77z01mvvvWHRhS9qpHz6yb4AByzwwAQXbPDB CCes8MIMN+zwwxBHjNoaElsLQsXl7VGwxgRzPLDHAoNsKDtAiQywyWsmsBXK+LK8oTUYxyzz zDRv9EbNOM8JTs489+zzz/1RA/TQRBdt9NFIJ21wBAUzTbDTSkct9dRUVw2TLQVjTbDWA3Mt sNcBg83WDlOKbfXZaKfNZ0AAIfkEABgAAAAsAAAAAHQBEAEHCP4A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkSY4FTqpcybKly5cwY8qcSbOmzZs4c+rcybOn z59AgwodStRgnaJIkypdyrSp06dQo0qdSrWq1atYs2rdyrWrV5IMHPL6Sras2bNo06pdy7at 27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIE+tFdliO4seQI0ueTLmy5bLPLmvezLmz 58+gQ4v26UAio9GobZZOzbro6tawgb6OTXvn7Nq4aYr5dzu375i9fwsfTry48ePI955Kzry5 8+fQo0ufTr269evYs2vfzr279+/gw/6LH08+KY3y6NNrDaa+vXuO9t7Ln0+/vv37+OV2ys+/ v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhyBGhEKIhI1I4mAm nhhYiireBMNQLLbYV4xdTSNjRjTemFeOOt7FY49ABinkkBluQeSRSCap5JJMNunkk1BGKeWU VFZp5ZVYZqnlllx26aWF5CiJxJdklmmmTK2cmd0PiGWm5ptwxinnnHTWaeedeKaFQ5589gnb UX4GKuighBZq6KFeiYMoT4ouqlOjjuIEaaSUVsqhO5ZmKqUzmnbq6aeghioqZ6iMauqpqKaq 6qqsturqq+OwxjpeKbLWiio6tvZUj0Ps5OorZLT+miUuwhY7kzzGJjsQKETeoaxxaDwr7bTU VmvttdhmC1I82i7EbbdNeQAuQuKOa1C55hKEbroCrbvUIJLloNEkkLnLFLzsFjQIvvn26++/ AAcscEdHDGzwwQgnrDB3cyzs8MMQcxWIspxEbPHFGGes8cYcd+yxZbN8LHKggPxbsn2wzEQH XifXl7K/L/cbc74zs1vzyDjnTOI7Ovfs889ABy300EQXjRYGHvFQK9IAY8C00VBHLfXUVFdt 9dVYZ21hM1p35guUZnQttqwBAQA7 ------=_NextPart_000_0003_01C6EBB9.AB158830-- From reed@chopped.com Mon Oct 09 09:25:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWv8l-00063U-IF for capwap-archive@ietf.org; Mon, 09 Oct 2006 09:25:55 -0400 Received: from vpn-224-43.aichyna.com ([87.252.224.43] helo=chopped.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWuyG-00044V-JJ for capwap-archive@ietf.org; Mon, 09 Oct 2006 09:15:06 -0400 Message-ID: <000001c6eba4$b23fd710$6ec4a8c0@qmdirk> Reply-To: "Pericles Hausmann" From: "Pericles Hausmann" To: capwap-archive@ietf.org Subject: Re: VbAGRA Date: Mon, 9 Oct 2006 06:13:22 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EB6A.05E0FF10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EB6A.05E0FF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 VbAGRA for less http://www.ironequestrian.info =20 _____ =20 No one seems to be following us-so lets keep it that way. Five- Only on alternate years. Lets get to the next one. Remote controlled gun turret. Note that the top of it is ------=_NextPart_000_0001_01C6EB6A.05E0FF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
 

No one seems to be following us-so lets keep it that way. = Five-
Only on alternate years. Lets get to the next one.
Remote controlled gun turret. Note that the top of it = is

------=_NextPart_000_0001_01C6EB6A.05E0FF10-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 10:54:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWY-0002vB-OM for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 10:54:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwT4-00067U-JQ for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 10:51:00 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id BDA983980B9 for ; Mon, 9 Oct 2006 07:50:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 82DAA430018 for ; Mon, 9 Oct 2006 07:50:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 67CB939807D for ; Mon, 9 Oct 2006 07:50:03 -0700 (PDT) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by zoidberg.tigertech.net (Postfix) with ESMTP id 629D739800D for ; Mon, 9 Oct 2006 07:50:01 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (sccrmhc15) with ESMTP id <2006100914495901500mdj0se>; Mon, 9 Oct 2006 14:50:00 +0000 Message-ID: <452A6196.2080209@hyperthought.com> Date: Mon, 09 Oct 2006 07:49:58 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Saravanan Govindan References: <5F09D220B62F79418461A978CA0921BD0136620B@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD0136620B@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Margaret Wasserman , capwap , Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Hi Everyone, I think I was careless in my wording, and that has led to some confusion. Charles already pointed out that splitting the authenticator role across the WTP and AC significantly changes the security model, and I thought our various posts on this made clear that the minimal security exposure resulting from KeyRSC imprecision does not warrant this level of change to the protocol. However, what I meant to suggest in my Friday post was that rather than telling implementors they SHOULD set the value to zero right off the bat, we should hold off to see what sort of opportunities arise to derive a more accurate value from existing (or simply-added new) statistics. If it turns out that there are statistics from which an AC might unambiguously derive a "better" value, then (in my opinion) that's what implementors SHOULD use. However, we have yet to see if such a mechanism exists. Scott Saravanan Govindan wrote: > Hi Cheng Hong, Scott, > > I share your concerns for setting the KeyRSC to 0. > > In my opinion, it is clear that the protocol is "broken" in this case > and needs to be fixed. > > My suggestion is to have the KeyRSC field be updated by the WTP. So the > AC could send Message-3 of the 4-way handshake to the WTP with an empty > KeyRSC field. The WTP could then correctly update the field, compute the > KeyMIC, update Message-3 and then forward it to the STA. > > Of course, this requires a CAPWAP message from the AC and WTP to > exchange the incomplete Message-3. I think this is an acceptable > addition because it maintains the integrity of 802.11i exchanges and > provides a complete fix to the problem. > > Saravanan > > > > > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Monday, October 09, 2006 1:21 PM > To: Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Scott, > > Some comments below: > >> After thinking long and hard about this, I can't bring myself >> to agree with the suggested text. Quite frankly, I think >> always using an RSC value of 0 is a lazy hack, and given that >> we've acknowledged we are introducing a vulnerability here >> (however slight), telling implementors they SHOULD do this >> just doesn't sit right with me. >> >> An enlightened implementation could almost certainly do >> better than always setting this to zero, and explicitly >> recommending that people nail this window open just rubs me >> the wrong way. At least, let's hold off on this decision >> until we've clearly defined what statistics we expect to be >> available. Seems like if we're going to tell implementors >> what they SHOULD do, we SHOULD give them sound, well >> considered advice. > > I absolutely agree with you on this point. > > What I was trying to state in my previous emails was: > - I would against setting a static value for the KeyRSC as a solution to > this issue. > - However if the WG decided to go for a static value, the draft should > clearly point out that NOT all static value could work (value other than > zero may be a problem for interoperability). > - And the draft needs to clearly point out what is the danger of setting > a static KeyRSC value in the security consideration section. > - Also, the draft should not prohibit other implementation for sync the > KeyRSC value between WTP and AC (the CAPWAP standard should not dictate > such implementation incompatible). > > If there is a alternative solution than setting a static KeyRSC value to > narrow the window, I would vote for it. > > cheers > > Cheng Hong > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Saturday, October 07, 2006 8:26 AM >> To: Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Margaret, >> >> Comments inline below... >> >> -----Original Message----- >>> From: Margaret Wasserman >>> Sent: Oct 6, 2006 9:39 AM >>> To: Scott G Kelly >>> Cc: Cheng Hong , capwap >>> >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >>> >>> While I am not against leaving things open to more optimal >>> implementations, I do think that we need to add some text to the >>> protocol portion of the document (as well as the security >>> considerations) to explain how this is handled. How about something >>> like: >>> >>> The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way >>> 802.11i handshake, unless the AC has knowledge of a more optimal RSC >>> value to use. Mechanisms for determining a more optimal RSC >> value are >>> outside the scope of this specification. >>> >>> I do not think that we should simply say nothing and hope that >>> implementors figure this out. >>> >>> Margaret >> After thinking long and hard about this, I can't bring myself >> to agree with the suggested text. Quite frankly, I think >> always using an RSC value of 0 is a lazy hack, and given that >> we've acknowledged we are introducing a vulnerability here >> (however slight), telling implementors they SHOULD do this >> just doesn't sit right with me. >> >> An enlightened implementation could almost certainly do >> better than always setting this to zero, and explicitly >> recommending that people nail this window open just rubs me >> the wrong way. At least, let's hold off on this decision >> until we've clearly defined what statistics we expect to be >> available. Seems like if we're going to tell implementors >> what they SHOULD do, we SHOULD give them sound, well >> considered advice. >> >> Scott >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 12:12:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxk2-00061R-Jn for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 12:12:34 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxhl-0000GH-Qc for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 12:10:16 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B5752398090 for ; Mon, 9 Oct 2006 09:10:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4F8DA430018 for ; Mon, 9 Oct 2006 09:08:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3045E398043 for ; Mon, 9 Oct 2006 09:08:17 -0700 (PDT) Received: from bay0-omc1-s14.bay0.hotmail.com (bay0-omc1-s14.bay0.hotmail.com [65.54.246.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2BA52398051 for ; Mon, 9 Oct 2006 09:08:14 -0700 (PDT) Received: from hotmail.com ([207.46.8.230]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 09:08:14 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Oct 2006 09:08:13 -0700 Message-ID: Received: from 207.46.8.251 by by118fd.bay118.hotmail.msn.com with HTTP; Mon, 09 Oct 2006 16:08:11 GMT X-Originating-IP: [202.156.10.12] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com In-Reply-To: <452A6196.2080209@hyperthought.com> From: "Saravanan Govindan" To: scott@hyperthought.com, Saravanan.Govindan@sg.panasonic.com Date: Tue, 10 Oct 2006 00:08:11 +0800 Mime-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2006 16:08:13.0497 (UTC) FILETIME=[1F692A90:01C6EBBD] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=1.748 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, MSGID_FROM_MTA_HEADER, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: margaret@thingmagic.com, capwap@frascone.com, Hong.Cheng@sg.panasonic.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Hi Scott, I am not sure the suggestion below affects any security model. As long as there is an established security framework between the AC and WTP, the suggested approach remains transparent. Furthermore, given that the protocol is still in development, I think we should seriously consider all options. Saravanan ----Original Message Follows---- From: Scott G Kelly To: Saravanan Govindan CC: Margaret Wasserman ,capwap ,Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Date: Mon, 09 Oct 2006 07:49:58 -0700 Hi Everyone, I think I was careless in my wording, and that has led to some confusion. Charles already pointed out that splitting the authenticator role across the WTP and AC significantly changes the security model, and I thought our various posts on this made clear that the minimal security exposure resulting from KeyRSC imprecision does not warrant this level of change to the protocol. However, what I meant to suggest in my Friday post was that rather than telling implementors they SHOULD set the value to zero right off the bat, we should hold off to see what sort of opportunities arise to derive a more accurate value from existing (or simply-added new) statistics. If it turns out that there are statistics from which an AC might unambiguously derive a "better" value, then (in my opinion) that's what implementors SHOULD use. However, we have yet to see if such a mechanism exists. Scott Saravanan Govindan wrote: > Hi Cheng Hong, Scott, > > I share your concerns for setting the KeyRSC to 0. > > In my opinion, it is clear that the protocol is "broken" in this case > and needs to be fixed. > > My suggestion is to have the KeyRSC field be updated by the WTP. So the > AC could send Message-3 of the 4-way handshake to the WTP with an empty > KeyRSC field. The WTP could then correctly update the field, compute the > KeyMIC, update Message-3 and then forward it to the STA. > > Of course, this requires a CAPWAP message from the AC and WTP to > exchange the incomplete Message-3. I think this is an acceptable > addition because it maintains the integrity of 802.11i exchanges and > provides a complete fix to the problem. > > Saravanan > > > > > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Monday, October 09, 2006 1:21 PM > To: Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > Hi Scott, > > Some comments below: > >> After thinking long and hard about this, I can't bring myself >> to agree with the suggested text. Quite frankly, I think >> always using an RSC value of 0 is a lazy hack, and given that >> we've acknowledged we are introducing a vulnerability here >> (however slight), telling implementors they SHOULD do this >> just doesn't sit right with me. >> >> An enlightened implementation could almost certainly do >> better than always setting this to zero, and explicitly >> recommending that people nail this window open just rubs me >> the wrong way. At least, let's hold off on this decision >> until we've clearly defined what statistics we expect to be >> available. Seems like if we're going to tell implementors >> what they SHOULD do, we SHOULD give them sound, well >> considered advice. > > I absolutely agree with you on this point. > > What I was trying to state in my previous emails was: > - I would against setting a static value for the KeyRSC as a solution to > this issue. > - However if the WG decided to go for a static value, the draft should > clearly point out that NOT all static value could work (value other than > zero may be a problem for interoperability). > - And the draft needs to clearly point out what is the danger of setting > a static KeyRSC value in the security consideration section. > - Also, the draft should not prohibit other implementation for sync the > KeyRSC value between WTP and AC (the CAPWAP standard should not dictate > such implementation incompatible). > > If there is a alternative solution than setting a static KeyRSC value to > narrow the window, I would vote for it. > > cheers > > Cheng Hong > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Saturday, October 07, 2006 8:26 AM >> To: Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Margaret, >> >> Comments inline below... >> >> -----Original Message----- >>> From: Margaret Wasserman >>> Sent: Oct 6, 2006 9:39 AM >>> To: Scott G Kelly >>> Cc: Cheng Hong , capwap >>> >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >>> >>> While I am not against leaving things open to more optimal >>> implementations, I do think that we need to add some text to the >>> protocol portion of the document (as well as the security >>> considerations) to explain how this is handled. How about something >>> like: >>> >>> The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way >>> 802.11i handshake, unless the AC has knowledge of a more optimal RSC >>> value to use. Mechanisms for determining a more optimal RSC >> value are >>> outside the scope of this specification. >>> >>> I do not think that we should simply say nothing and hope that >>> implementors figure this out. >>> >>> Margaret >> After thinking long and hard about this, I can't bring myself >> to agree with the suggested text. Quite frankly, I think >> always using an RSC value of 0 is a lazy hack, and given that >> we've acknowledged we are introducing a vulnerability here >> (however slight), telling implementors they SHOULD do this >> just doesn't sit right with me. >> >> An enlightened implementation could almost certainly do >> better than always setting this to zero, and explicitly >> recommending that people nail this window open just rubs me >> the wrong way. At least, let's hold off on this decision >> until we've clearly defined what statistics we expect to be >> available. Seems like if we're going to tell implementors >> what they SHOULD do, we SHOULD give them sound, well >> considered advice. >> >> Scott >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Find just what you are after with the more precise, more powerful new MSN Search. http://search.msn.com.sg/ Try it now. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:42:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz8z-0000Xm-0g for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:42:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWz8t-0000dY-2P for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:42:24 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DAA7F3980A2 for ; Mon, 9 Oct 2006 10:42:13 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 55EE6430018 for ; Mon, 9 Oct 2006 10:39:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 068F11448003 for ; Mon, 9 Oct 2006 10:39:40 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id B277E144800B for ; Mon, 9 Oct 2006 10:39:34 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:39:33 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329561913:sNHT317711568" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HdXwE021169; Mon, 9 Oct 2006 10:39:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HdIOp002492; Mon, 9 Oct 2006 10:39:28 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:39:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:39:27 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E893B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 204 and proposed resolutions to its components Thread-Index: Acbpbly+vxXENvQ8Q72CYwRhDaJfuwCVUhmg From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , X-OriginalArrivalTime: 09 Oct 2006 17:39:27.0970 (UTC) FILETIME=[DE737420:01C6EBC9] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0214875424==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 4047ed98d34f6c3eb2a5aa2dd97f5564 This is a multi-part message in MIME format. --===============0214875424== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBC9.DE40460D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBC9.DE40460D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Again agree with Dorothy. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, October 06, 2006 10:37 AM To: young@huawei-3com.com Cc: capwap@frascone.com Subject: Re: [Capwap] Issue 204 and proposed resolutions to its components =09 =09 Richard,=20 =09 Notes inline.=20 =09 Thanks,=20 =09 Dorothy =09 =09 On 10/5/06, young wrote:=20 Hi, Dorothy: Thanks for your proposed resolutions.=20 You're welcome. =09 In your Proposed Resolution, you mentioned that " While there may be common=20 elements, it's not clear that the CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems." If it is not clear, I suggest that WG or mailing list had better take time=20 to make it clear. Otherwise, how to decide what info should put in the base part if base part scope is not clear? I thought a clear and common understanding of base part's rule and scope is very important for=20 base part separation from wireless specific binding. I completely agree that the WG needs to clarify on the base vs binding division of labor. The current draft, with the exception (largely) of the WTP Radio information element, puts the=20 wireless-technology specific elements in the binding rather than the base protocol. This is the approach I followed in developing the proposed resolutions.=20 Most of the CAPWAP level message elements are used to establish and manage the session between the AC and WTP. Some message elements, for example the WTP radio statistics and Decryption Error Report are borderline and could arguably move to the binding; but they are not technology specific - e.g. 802.11 vs 802.16. =09 =09 I give my comment for the proposed resolutions to issue 204. 1) 4.4.38. WTP Radio Information=20 Sorry for I don't make issue clear in my comment. I suggest that WTP Radio Information could be kept in the current section 4.4. While 802.11a/b/g/n these kinds info could be defined by 802.11binding. We could add a Wireless binding identifier in the WTP Radio Information.=20 By this way, we could identify any Wireless binding's radio type definition. The Wireless binding identifier could be probably eventually managed by IANA. No matter what method will by used for Wireless binding identifier, it is a=20 key Point to help base protocol to separate any wireless binding. I thought that Wireless binding identifier method will be a common issue. I considered several options on this one.=20 (a) Have both a CAPWAP base element that included the "first level" radio information: 802.11, 802.15, 802.16, 802.22, EPCGlobal, etc, AND specific binding elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. Thus as the first levels churn internally, the base spec isn't impacted. But if the detailed level is provided, is the higher level even needed? =09 (b) Have only binding-specific elements that specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc.=20 The binding will need to specify that the element must be included in the control messages that the previous CAPWAP level element was in. =09 (c) keeping the definition as is. Didn't do this, since the change did make the CAPWAP base spec even more wireless-technology agnostic. =09 The WTP Radio information message element includes only 2 fields, the radio type and the radio information. If we want radio specific info in the base spec, then we can leave it there, and add the 802.11,15,16,etc values - and require that the capwap base spec change as new values are added, or we can move the radio-type info to the binding, and then as the wireless technology evolves, only the binding doc has to change. =20 =09 2) 11.9.18. IEEE 802.11 Tx Power I suggest we could define a "WTP Radio configuration" TLV.=20 By using wireless binding identifier, there will be no conflict with Dot11PhyTxPowerEntry MIB table. Channel also could be put here. As AC will configure AP's RF parameter (AC to AP), and AP will report its current Configuration to AC, the TLV will be carried in the configuration message in bi-direction. More TLV could be added into the TLV if it is required. =09 |---------|-------------|-----------------------------|--------------|-- ----=20 ---|---------| | Radio ID| country code| wireless binding identifier | Max Tx Power |Tx Power | Channel | =09 |---------|-------------|-----------------------------|--------------|-- ---- -- |----------| As Tx power these kind info will not be carried in the discovery phase, I=20 suggest that "WTP Radio configuration" is required instead of extenuation of " WTP Radio Information". Ok, so the proposal is to have a new base-spec-level message element, that incorporates a binding-defined-identifier for Radio Configuration. This would require the TX power fields to have the same units across wireless types. This level of configuration is currenly in the binding and my preference would be to leave it there.=20 =09 Regards Richard (shiyang) =09 =09 =09 =09 =09 From: Dorothy Stanley ( dstanley1389gmail.com ) Date: Wed, 4 Oct 2006 09:08:21 -0700 (PDT) All, =09 Issue 204 and proposed resolutions to its components are listed below. =09 Comments please. =09 Thanks, =09 Dorothy =09 =09 ------------------------------------------------------------------------ ---- --------------------------------------------- 1) 4.4.38. WTP Radio Information Comment: As the section should be work for any wireless implement, I suggest=20 the following value should be moved to 802.11 binding. The value should be defined by wireless technology binding. 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. Proposed Resolution: Move the "need to know" the 802.11 technology specific radio types to the 802.11 binding, modifying the WTP Radio Information=20 element as follows: IEEE 802.11 Radio Information The IEEE 802.11 radio information message element is used to communicate the radio information for each IEEE 802.11 radio on the WTP. The Discovery=20 Request message MUST include one such message element per radio in the WTP. The Radio-Type field is used by the AC to determine which 802.11 technology specific binding is to be used with the WTP. The value contains two fields, as shown. =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Radio Type | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Radio Type | +-+-+-+-+-+-+-+-+ =09 Type: 38 for WTP Radio Information Length: 5=20 Radio ID: The Radio Identifier, which typically refers to an interface index on the WTP Radio Type: The type of IEEE 802.11 radio present. The following values are supported: 1 - 802.11b: An IEEE 802.11b radio. 2 - 802.11a: An IEEE 802.11a radio. 4 - 802.11g: An IEEE 802.11g radio. 8 - 802.11n: An IEEE 802.11n radio. 0xOF - 802.11b, 802.11a, 802.11g and 802.11n : The 4 radio types indicated are supported in the WTP. =09 =09 ------------------------------------------------------------------------ ---- --------------- 2) 11.9.18. IEEE 802.11 Tx Power Comment: I think it could be moved to the section 4.4, as channel and Tx power are common parameters for RF management. Proposed Resolution: No change to the draft. Agree with the commenter =09 that TX power level is a common parameter for RF management; however the=20 IEEE 802.11 TX Power field values are defined as being the values defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions.=20 =09 ------------------------------------------------------------------------ --- 3) Add "WTP radio channel" Comment: As per 2), we could define a TLV to report current channel (AP to AC) or to configure channel (AC to AP).=20 Now,. 11.9.12. IEEE 802.11 OFDM Control and 11.9.5. IEEE 802.11 Direct Sequence Control has channel configuration information. But I think that a specific TLV for it is better. By this way, 4.4 will provide=20 more common parameter for any wireless technology. =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Radio ID | Reserved | Current Channel | =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 The commenter suggests the following: 3) Add "WTP RF Radio configuration" in the section 4.4 The Tx power, radio type, channel assignment and so on these kind parameter=20 are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent=20 during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol.=20 The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way,=20 AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5 . IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. Proposed Resolution: No change to the draft. While there may be common elements, it's not clear that the CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems. =09 =09 ------------------------------------------------------------------------ ---- -------- 4) 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indications =09 Comment: I think it could be moved to the section 4.4, it could be a common event for any wireless technology. Proposed Resolution: No change to the draft. Agree with the commmenter=20 that a fail alarm indication could be a common event for any wireless technology. Each radio technology may want to have additional information reported with the event however. Not sure there is sufficient benefit shown for a common defintiion at this=20 point. =09 ------------------------------------------------------------------------ ---- ----------- =09 5) 11.9.1. IEEE 802.11 Add WLAN How about we rename "WLAN" as wireless service? By this way, we could=20 achieve abstract while make it work for most wireless technology. If it is ok, we could define "add wireless service, delete wireless service, =09 update wireless service" in the section 4.4. Any wireless technology could add its specific parameter in the binding section. =09 The commenter suggests a solution: 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode=20 these kinds common element (more element maybe put here). While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using=20 ( Probably eventually managed by IANA) Proposed resolution: Close, no change to the draft. The IEEE 802.11 Add WLAN message element is 802.11 specific and used together with several other message elements to define a WLAN service.=20 The intent of the comment seems to be to have the ability in the CAPWAP protocol to add a generic wireless service. It's not clear that there are enough additional elements common to multiple wireless services to have a separate CAPWAP level element at this at this time.=20 =09 ------------------------------------------------------------------------ ---- ---- 6) 11.9.22. IEEE 802.11 WTP Quality of Service =09 As per 5), I think we could define "WTP Quality of Service"in the section=20 4.4. Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality of Service". =09 While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of Service. The commenter suggests the following solution:=20 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service".=20 For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. Proposed resolution: Close, no change to the draft. The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed to convey the CWMin , CWMax and other very specific 802.11 data. The intent of the comment seems to be to have the ability in the CAPWAP protocol to include a "generic QOS" message element. It's not clear=20 that there are enough elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. There is at least 1 - the Tag packets type, which each binding can inlcude if desired. =09 ------------------------------------------------------------------------ ---- ------------------------------------------------------ 7. Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4 =09 Comment: Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" could be put on the section 4.4, except the element like "RTS Success Count"=20 and so on. For any binding, we use Wireless binding identifier to suggest them. Proposed resolution: No change to the draft. Agree with the commenter that many of the statistics are common across wireless technologies.=20 However the IEEE 802.11 Statistics values are defined as being the values defined in various IEEE 802.11 MIB variables and thus are not extensible to other bindings. Expect that each binding will define values relative to its=20 definitions. =09 On 9/28/06, young wrote: Hi Pat and all, I used to raise issue #204, and here intend to give solution. 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here). While for any specific wireless binding could follow the Wireless binding=20 identifier. The Wireless binding identifier will identify what kinds binding are using ( Probably eventually managed by IANA) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Radio ID | WLAN ID | MAC Mode | Tunnel Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wireless binding identifier | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN". =09 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP=20 Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. =09 3) Add "WTP RF Radio configuration" in the section 4.4 The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power=20 these kind Info should not be sent during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message=20 should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on. For any binding, we use Wireless binding identifier to suggest them.=20 The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18 . IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5. IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. 4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4 Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics" could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. =09 Any way, I thought many TLV will change their location as new CAPWAP will be=20 divided into two parts. =09 Cheers =09 Richard (Shiyang) =09 =09 =09 =09 ------_=_NextPart_001_01C6EBC9.DE40460D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Again=20 agree with Dorothy.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, October 06, = 2006=20 10:37 AM
To: young@huawei-3com.com
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Issue 204 and = proposed=20 resolutions to its components

Richard,

Notes inline.

Thanks,=20

Dorothy

On 10/5/06, young=20 <young@huawei-3com.com>=20 wrote:
Hi,=20 Dorothy:
Thanks for your proposed = resolutions. 
You're=20 welcome.
In=20 your Proposed Resolution, you mentioned that " While there may be = common=20
elements, it's not clear that the
CAPWAP base specification = should=20 take on the task of extracting/unifying the
common = elements
across=20 wireless systems."
If it is not clear, I suggest that WG or = mailing list=20 had better take time
to make it clear.
Otherwise, how to = decide what=20 info should put in the base part if base part
scope is not = clear?
I=20 thought a clear and common understanding of base part's rule and = scope=20 is
very important for
base part separation from wireless = specific=20 binding.

I completely agree that the WG needs to clarify on the base = vs=20 binding
division of labor.
The current draft, with the exception = (largely) of  the WTP Radio information element, puts the=20
wireless-technology specific elements in the binding rather than = the base=20 protocol. This is
the approach I followed in developing the = proposed=20 resolutions.
Most of the CAPWAP level message elements are used to = establish and manage the
session between the AC and WTP.  Some = message=20 elements, for example
 the WTP radio statistics and Decryption = Error=20 Report are borderline and could arguably
move to the binding; but = they are=20 not technology specific - e.g. 802.11 vs 802.16.


I=20 give my comment for the proposed resolutions to issue 204.
1)=20 4.4.38.  WTP Radio Information
Sorry for I don't make = issue=20 clear in my comment.
I suggest that WTP Radio Information could = be kept=20 in the current section
4.4.
While 802.11a/b/g/n these kinds = info could=20 be defined by 802.11binding.
We could add a Wireless binding = identifier=20 in the WTP Radio Information.
By this way, we could identify any = Wireless binding's radio type definition.
The Wireless binding = identifier=20 could be probably eventually managed by
IANA.
No matter what = method=20 will by used for Wireless binding identifier, it is a =
key
Point to=20 help base protocol to separate any wireless binding.
I thought = that=20 Wireless binding identifier method will be a common = issue.

I considered several options on this one.
(a) Have both a = CAPWAP
base element that included the "first level" radio = information:=20 802.11, 802.15,
802.16, 802.22, EPCGlobal, etc, AND specific = binding=20 elements that
specify the details, e.g. = 802.11a,b,g,n,y,180.16a,b,e,etc.=20 Thus as the first
levels churn internally, the base spec isn't = impacted.=20 But if the detailed level
is provided, is the higher level even=20 needed?

(b) Have  only binding-specific  elements=20 that
specify the details, e.g. 802.11a,b,g,n,y,180.16a,b,e,etc. =
The=20 binding will need to specify that the element must be included in=20 the
control messages that the previous CAPWAP level element was=20 in.

(c) keeping the definition as is. Didn't do this, since the = change
did make the CAPWAP base spec even more wireless-technology=20 agnostic.

The WTP Radio information message element includes = only 2=20 fields, the
radio type and the radio information. If we want radio = specific=20 info in the
base spec, then we can leave it there, and add the=20 802.11,15,16,etc values - and
require that the capwap base spec = change as=20 new values are added, or we can
move the radio-type info to the = binding,=20 and then as the wireless technology
evolves, only the binding doc = has to=20 change. 

2)=20 11.9.18.  IEEE 802.11 Tx Power
I suggest we could = define a "WTP=20 Radio configuration" TLV.
By using wireless binding identifier, = there=20 will be no conflict with
Dot11PhyTxPowerEntry MIB = table.
Channel also=20 could be put here.
As AC will configure AP's RF parameter (AC to = AP), and=20 AP will report its
current
Configuration to AC, the TLV will = be=20 carried in the configuration message in
bi-direction.
More TLV = could=20 be added into the TLV if it is=20 = required.
|---------|-------------|-----------------------------|-----= ---------|------=20
---|---------|
| Radio ID| country code| wireless binding = identifier=20 | Max Tx Power |Tx
Power |=20 = Channel  |
|---------|-------------|------------------------= -----|--------------|------
--=20 |----------|
As Tx power these kind info will not be carried in = the=20 discovery phase, I
suggest that "WTP Radio configuration"
is = required=20 instead of extenuation of " WTP Radio Information".

Ok, so the proposal is to have a new base-spec-level message=20 element,
that incorporates a binding-defined-identifier for Radio=20 Configuration.
This would require the TX power fields to have the = same=20 units across
wireless types. This level of configuration is = currenly in the=20 binding and
my preference would be to leave it there. =

Regards
Richard=20 (shiyang)





From: Dorothy Stanley ( = dstanley1389gmail.com)
Date:=20 Wed, 4 Oct 2006 09:08:21 -0700 (PDT)
All,

Issue 204 and = proposed=20 resolutions to its components are
listed below.

Comments=20 = please.

Thanks,

Dorothy

----------------------------= ------------------------------------------------
---------------------= ------------------------
1)=20 4.4.38.  WTP Radio Information
Comment: As the section = should=20 be work for any wireless implement, I suggest
the
following = value=20 should be moved to 802.11 binding. The value should be
defined by = wireless
technology = binding.
      1 -=20 802.11b:  An IEEE 802.11b=20 radio.
      2 - = 802.11a:  An=20 IEEE 802.11a radio.
      4=20 -
802.11g:  An IEEE 802.11g=20 radio.
      8 - = 802.11n:  An=20 IEEE 802.11n radio.
Proposed Resolution: Move the "need to know" = the=20 802.11 technology specific
radio types to the 802.11 binding, = modifying=20 the WTP Radio Information
element
as follows:
IEEE 802.11 = Radio=20 Information
   The IEEE 802.11 radio information = message=20 element is used to communicate
the
   radio = information for=20 each IEEE 802.11 radio on the WTP.  The Discovery =
Request=20 message MUST
   include one such message element per = radio in=20 the WTP.  The Radio-Type
field is used by = the
  =20 AC to determine which 802.11 technology specific binding is to be=20 used
with the WTP.
   The value contains two fields, = as=20 = shown.

      0   &nbs= p;            = ;  =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7=20 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;   =20 |   Radio=20 = ID    |       &nbs= p;  =20 Radio=20 = Type           &nb= sp;           &nbs= p;  |
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=     =20 | Radio Type    |
    =20 +-+-+-+-+-+-+-+-+

   Type:  38 for WTP = Radio=20 Information
   Length:  5
   = Radio=20 ID:  The Radio Identifier, which typically refers to=20 an
      interface index on the=20 WTP
   Radio Type:  The type of IEEE 802.11 = radio=20 present.
      The following values = are=20 supported:
      1 - = 802.11b:  An=20 IEEE 802.11b radio.
      2 -=20 802.11a:  An IEEE 802.11a=20 radio.
      4 = -
802.11g:  An=20 IEEE 802.11g radio.
      8 -=20 802.11n:  An IEEE 802.11n=20 radio.
      0xOF - 802.11b, = 802.11a,=20 802.11g and 802.11n :  The 4 radio=20 types
         indicated = are=20 supported in the=20 = WTP.

-------------------------------------------------------------= ---------------
---------------
2)=20 11.9.18.  IEEE 802.11 Tx Power
Comment: I think it = could be=20 moved to the section 4.4, as channel and Tx
power are
common=20 parameters for RF management.
Proposed Resolution: No change to = the=20 draft. Agree with the commenter

that TX power level is a = common=20 parameter for RF management; however the
IEEE 802.11 TX Power = field=20 values are defined as being the values
defined in IEEE=20 802.11Dot11PhyTxPowerEntry MIB table, and thus are not
extensible = to=20 other bindings. Expect that each binding will define
values = relative to=20 its definitions.=20 =
---------------------------------------------------------------------= ------
3)  Add=20 "WTP radio channel"
Comment: As per 2), we could define a TLV to = report=20 current channel (AP to
AC) or to
configure channel (AC to AP). =
Now,. 11.9.12.  IEEE 802.11 OFDM Control and=20 11.9.5.  IEEE 802.11 Direct
Sequence Control has = channel=20 configuration information.
But I think that a specific TLV for it = is=20 better. By this way, 4.4 will
provide
more common parameter = for any=20 wireless technology.

    =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
        0 1 2 3 4 5 6 7 = 8 9 0 1=20 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=20 1
      =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=       =20 |    Radio ID  =20 |    Reserved  =20 |        Current=20 Channel      =20 |

      =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= The=20 commenter suggests the following:
3) Add "WTP RF Radio = configuration" in=20 the section 4.4
The Tx power, radio type, channel assignment and = so on=20 these kind parameter
are common for any kind wireless = binding.
I=20 suggest CAPWAP define it in the base protocol part.
Although the = protocol=20 already has "WTP Radio Information", while Tx power
these kind = Info=20 should not be sent
during discovery and join phase. So the = separated=20 "WTP RF Radio
configuration" is better.
If keep them in one, = which=20 element will be mandatory in what kind message
should be = suggested by=20 protocol.
The TLV of "WTP RF Radio configuration" will include = radio ID,=20 radio type,
Tx power, Channel, country code and so on.
For any = binding, we use Wireless binding identifier to suggest them.
The = "WTP RF=20 Radio configuration" could be sent by bi-direction, by this way, =
AC=20 could configure WTP's RF parameter
and know current configuration = on the=20 WTP radio.
If this way, current "11.9.18. IEEE 802.11 Tx Power",=20 "11.9.12. IEEE
802.11 OFDM Control "and "11.9.5 .
IEEE 802.11 = Direct=20 Sequence Control" and so on will merely keep the IEEE
802.11 = related=20 element.
Proposed Resolution: No change to the draft. While there = may be=20 common
elements, it's not clear that the
CAPWAP base = specification=20 should take on the task of extracting/unifying the
common=20 elements
across wireless=20 = systems.

---------------------------------------------------------= -------------------
--------
4)=20 11.9.24.  IEEE 802.11 WTP Radio Fail Alarm=20 Indications

Comment: I think it could be moved to the section = 4.4, it=20 could be a common
event for
any wireless = technology.
Proposed=20 Resolution: No change to the draft. Agree with the commmenter =
that a=20 fail alarm indication could be a common event for
any wireless=20 technology. Each radio technology may want to
have additional = information=20 reported with the event however. Not
sure there is sufficient = benefit=20 shown for a common defintiion at this=20 =
point.
-----------------------------------------------------------= -----------------
-----------

5)=20 11.9.1.  IEEE 802.11 Add WLAN
How about we rename = "WLAN" as=20 wireless service? By this way, we could
achieve
abstract = while make=20 it work for most wireless technology.
If it is ok, we could = define "add=20 wireless service, delete wireless service,

update wireless = service"=20 in the section
4.4.
Any wireless technology could add its = specific=20 parameter in the binding
section.

The commenter suggests a = solution:
1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add = wireless=20 service",
and put it in the section 4.4
The glossary "wireless = service" will be more abstract than "WLAN".
Refer to current = "IEEE 802.11=20 add WLAN" format, we could keep
Radio ID, service ID (rename = "WLAN ID" to=20 it), MAC Mode, tunnel mode
these kinds common element (more = element=20 maybe put here).
While for any specific wireless binding could = follow the=20 Wireless binding
identifier.
The Wireless binding identifier = will=20 identify what kinds binding are using
( Probably eventually = managed by=20 IANA)
Proposed resolution: Close, no change to the draft.
The = IEEE=20 802.11 Add WLAN message element is 802.11 specific and = used
together with=20 several other message elements to define a WLAN service.
The = intent of=20 the comment seems to be to have the ability in the
CAPWAP = protocol to add=20 a generic wireless service. It's not clear that
there are enough=20 additional elements common to multiple wireless
services to have = a=20 separate CAPWAP level element at this at this time.=20 =
---------------------------------------------------------------------= -------
----
6)=20 11.9.22.  IEEE 802.11 WTP Quality of Service

As per = 5), I=20 think we could define "WTP Quality of Service"in the section =
4.4. Radio=20 ID, Tag Packets and Queue Depth could be defined in the = "WTP
Quality=20 of
Service".

While CWMin and so on could be defined in the = IEEE=20 802.11 WTP Quality of
Service.
The commenter suggests the = following=20 solution:
2) Rename "11.9.22. IEEE 802.11 WTP Quality of = Service" as=20 "WTP Quality of
Service"
Same idea, we could keep the radio = ID, Tag=20 Packets, Queue Depth in the "WTP
Quality of Service".
For any = binding, we use Wireless binding identifier to suggest them.
For = Tag=20 Packets, if IANA already have some kind assignment, it will=20 be
great.
Proposed resolution: Close, no change to the = draft.
The=20 IEEE 802.11 WTP QOS message element is 802.11 specific and is = needed
to=20 convey the CWMin , CWMax and other very specific 802.11 data.
The = intent=20 of the comment seems to be to have the ability in the
CAPWAP = protocol to=20 include a "generic QOS" message element. It's not clear =
that
there=20 are enough elements common to multiple wireless
services to have = a=20 separate CAPWAP level element at this at this time.
There is at = least 1 -=20 the Tag packets type, which each binding can=20 = inlcude
if
desired.
--------------------------------------------= --------------------------------
-------------------------------------= -----------------
7.=20 Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section = 4.4

Comment: Most case, the wireless binding will be link = layer=20 protocol, I
think most the element in the "IEEE 802.11=20 Statistics"
could be put on the section 4.4, except the element = like "RTS=20 Success Count"
and so on.
For any binding, we use Wireless = binding=20 identifier to suggest them.
Proposed resolution: No change to the = draft.=20 Agree with the commenter
that many of the statistics are common = across=20 wireless technologies.
However the IEEE 802.11 Statistics values = are=20 defined as being the values
defined in various IEEE 802.11 MIB = variables=20 and thus are not extensible to
other bindings. Expect that each = binding=20 will define values relative to its
definitions.

On = 9/28/06, young=20 <young [at] huawei-3com.com>=20 wrote:
Hi Pat and all,
I used to raise issue #204, and here = intend to=20 give solution.
1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add = wireless=20 service",
and put it in the section 4.4
The glossary "wireless = service" will be more abstract than "WLAN".
Refer to current = "IEEE 802.11=20 add WLAN" format, we could keep
Radio ID, service ID (rename = "WLAN ID" to=20 it), MAC Mode, tunnel mode
these kinds common element (more = element maybe=20 put here).
While for any specific wireless binding could follow = the=20 Wireless binding
identifier.
The Wireless binding identifier = will=20 identify what kinds binding are using
( Probably eventually = managed by=20 IANA)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 = 0=20 = 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
|=20 Radio ID | WLAN ID | MAC Mode | Tunnel
Mode=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=20 Wireless binding identifier=20 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
|=20 Type | Length=20 = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|=20 = Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+
It=20 is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update=20 WLAN".

2) Rename "11.9.22. IEEE 802.11 WTP Quality of = Service" as=20 "WTP Quality of
Service"
Same idea, we could keep the radio = ID, Tag=20 Packets, Queue Depth in the "WTP
Quality of Service".
For any = binding, we use Wireless binding identifier to suggest them.
For = Tag=20 Packets, if IANA already have some kind assignment, it will=20 be
great.

3) Add "WTP RF Radio configuration" in the = section=20 4.4
The Tx power, radio type, channel assignment and so on these = kind=20 parameter
are common for any kind wireless binding.
I suggest = CAPWAP=20 define it in the base protocol part.
Although the protocol = already has=20 "WTP Radio Information", while Tx power
these kind Info should = not be=20 sent
during discovery and join phase. So the separated "WTP RF=20 Radio
configuration" is better.
If keep them in one, which = element=20 will be mandatory in what kind message
should be suggested by=20 protocol.
The TLV of "WTP RF Radio configuration" will include = radio ID,=20 radio type,
Tx power, Channel, country code and so on.
For any = binding, we use Wireless binding identifier to suggest them.
The = "WTP RF=20 Radio configuration" could be sent by bi-direction, by this = way,
AC could=20 configure WTP's RF parameter
and know current configuration on = the WTP=20 radio.
If this way, current "11.9.18 . IEEE 802.11 Tx Power", = "11.9.12.=20 IEEE
802.11 OFDM Control "and "11.9.5.
IEEE 802.11 Direct = Sequence=20 Control" and so on will merely keep the IEEE
802.11 related=20 element.
4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" = in the=20 section
4.4
Most case, the wireless binding will be link layer = protocol, I think most
the element in the "IEEE 802.11=20 Statistics"
could be put on the section 4.4, except the element = like "RTS=20 Success Count"
and so on.
For any binding, we use Wireless = binding=20 identifier to suggest them.

Any way, I thought many TLV will = change=20 their location as new CAPWAP will be
divided into two=20 parts.

Cheers

Richard=20 = (Shiyang)




------_=_NextPart_001_01C6EBC9.DE40460D-- --===============0214875424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0214875424==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:44:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzAl-000171-H7 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:44:15 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzAj-0000y6-WB for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:44:15 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 867B83980D3 for ; Mon, 9 Oct 2006 10:44:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id F2F6A4300F2 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D42FA3980D5 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id C0FA63980AE for ; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:10 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857099064:sNHT90991244" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgAcp010617; Mon, 9 Oct 2006 10:42:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg2Ov004245; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to issue 173 - message element exceedframe length. Thread-Index: AcbfQ8pzfM/Ni0loTmCW+1ol48SAnAMe4SLg From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:09.0515 (UTC) FILETIME=[3EBD43B0:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to issue 173 - message element exceedframe length. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294366932==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a multi-part message in MIME format. --===============0294366932== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3E9185E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3E9185E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Mike's assessment. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 12:09 PM To: capwap Subject: [Capwap] Proposed resolution to issue 173 - message element exceedframe length. =09 =09 I do not see why the CAPWAP transport fragmentation mechanism can't be used to address this issue. I propose that we close it with no updates to the draft, unless someone is willing to describe what changes need to be made.=20 =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3E9185E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Mike's assessment.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 12:09 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to issue 173 - message element exceedframe=20 length.

I do not see why the CAPWAP transport fragmentation mechanism = can't be=20 used to address this issue. I propose that we close it with no updates = to the=20 draft, unless someone is willing to describe what changes need to be = made.=20
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3E9185E9-- --===============0294366932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0294366932==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:45:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzC6-0002Iy-6V for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:45:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzC4-0001D0-LA for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:45:38 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 423353980C8 for ; Mon, 9 Oct 2006 10:45:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 65DCF430018 for ; Mon, 9 Oct 2006 10:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 59FF33980CE for ; Mon, 9 Oct 2006 10:42:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6A0B1398085 for ; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:08 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563251:sNHT97355168" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Hg8FV022033; Mon, 9 Oct 2006 10:42:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg7On004332; Mon, 9 Oct 2006 10:42:08 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:07 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to Issue 140 - use of VLAN name Thread-Index: AcbfQq60agH8zTu/RLW/0amzOBiweQMenXoQ From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:07.0943 (UTC) FILETIME=[3DCD6570:01C6EBCA] Authentication-Results: sj-dkim-8.cisco.com; header.DKIM-Signature=pcalhoun@cisco.com; dkim=fail ( 57 extraneous bytes; RSA-96 err: "Pat Calhoun \(pacalhou\)" ; cisco.com/sjdkim8002 fail; ); header.From=pcalhoun@cisco.com; dkim=neutral X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to Issue 140 - use of VLAN name X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0875159617==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a multi-part message in MIME format. --===============0875159617== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3DA7DF75" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3DA7DF75 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree with this change. The reason why a name is better is that the ID may differ across WTPs, while representing the same "user group". For instance, engineering folks may be set to VLAN 101 on one set of WTPs, but 201 on others (based on geography). I believe that the use of the name is a more scalable approach that your proposed change. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 12:01 PM To: capwap Subject: [Capwap] Proposed resolution to Issue 140 - use of VLAN name =09 =09 In section 4.4.8, I propose that we change VLAN name to VLAN Identifier ( as described in IEEE 802.1D). =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3DA7DF75 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 disagree with this change. The reason why a name is better is that the = ID may=20 differ across WTPs, while representing the same "user group". For = instance,=20 engineering folks may be set to VLAN 101 on one set of WTPs, but 201 on = others=20 (based on geography). I believe that the use of the name is a more = scalable=20 approach that your proposed change.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 12:01 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to Issue 140 - use of VLAN name

In section 4.4.8, I propose that we change VLAN name to VLAN = Identifier (=20 as described in IEEE 802.1D).
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3DA7DF75-- --===============0875159617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0875159617==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:46:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzD5-0002Y8-Ke for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:46:39 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzD3-0001M2-W1 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:46:39 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B2F97398107 for ; Mon, 9 Oct 2006 10:46:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 68230430018 for ; Mon, 9 Oct 2006 10:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5CDA23980D5 for ; Mon, 9 Oct 2006 10:42:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id B4AF03980B5 for ; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208"; a="1857099097:sNHT1044747350" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgEZ7022992; Mon, 9 Oct 2006 10:42:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg7Ox004332; Mon, 9 Oct 2006 10:42:13 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:10 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8950@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 TxPower" Thread-Index: AcbonWjbwgkBfGU+Ra6L0IboaXdPUwDI5b/Q From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , "Dorothy Stanley" X-OriginalArrivalTime: 09 Oct 2006 17:42:10.0677 (UTC) FILETIME=[3F6E9250:01C6EBCA] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to :One issue, please discuss: I suggest some change for "11.9.18. IEEE 802.11 TxPower" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 I disagree with changing the baseline from mW to dbm. I unfortunately am not online and only have access to the 802.11-1999 standard with me, but a quick glance at section 14.8.2.1.16 (dot11CurrentTxPowerLevel) uses a value in mW. I would prefer that we remain consistent with the 802.11 standard. Having said that, the IEEE 802.11 Tx Power section should include a reference to the MIB variable. Proposed new text: from: Current Tx Power This attribute contains the transmit output power in mW. to: Current Tx Power This attribute contains the transmit output power in mW, as described in the dot11CurrentTxPowerLevel MIB variable. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, October 05, 2006 9:40 AM > To: Dorothy Stanley > Cc: capwap@frascone.com > Subject: Re: [Capwap] Proposed Resolution to :One > issue,please discuss: I suggest some change for "11.9.18. > IEEE 802.11 TxPower" > > > Hi All, > > This request is based on the assumption that the WTP's power > level will actually be set in dBm. If that is true, why not > use dBm (or > centi-dBm) as the unit for this attribute, instead of mW (or 0.1 mW)? > > Margaret > > On Oct 5, 2006, at 12:34 PM, Dorothy Stanley wrote: > > > All, > > > > The proposed resolution to the 11.9.18 comment is: Accept the > > commenters suggestion, change > > > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > > > Comments welcome, > > > > Thanks, > > > > Dorothy > > > > On 9/25/06, zhaoyujin 31390 wrote: Section > > 11.9.18 has following discripiton, I suggestion some change > > > > From "Current Tx Power: This attribute contains the transmit > > output power in mW." > > to "Current Tx Power: This attribute contains the transmit > > output power in 0.1mW." > > > > The reason is: normally WLAN will use dbm. The conversion > between dbm > > and mw can not satisfy this TLV requirement. If capwap > transimit one > > mw value, the device can't precise get corresponding dbm. > > > > For example > > 1 dbm<----->1.3mw ----> 1mw > > 2 dbm<----->1.6mw ----> 2mw > > 3 dbm<----->2.0mw ----> 2mw > > > > This time, if capwap transmits 2 mw, system doesn't know > it is 2dbm > > or 3 dbm. > > > > The following is suggestion: > > For example > > 1 dbm<----->1.3mw ----> 13mw > > 2 dbm<-----> 1.6mw ----> 16mw > > 3 dbm<----->2.0mw ----> 20mw > > > > Thanks > > Michael > > > > > The Tx power message element value is bi-directional. When > > sent by > > > the WTP, it contains the current power level of the radio in > > > question. When sent by the AC, it contains the power level the > > WTP > > > MUST adhere to. > > > > > > 0 1 2 > 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > > 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > | Radio ID | Reserved | Current Tx > > Power | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > +-+-+ > > > > > > Type: 1041 for IEEE 802.11 Tx Power > > > > > > Length: 4 > > > > > > Radio ID: An 8-bit value representing the radio to configure. > > > > > > Reserved: MUST be set to zero > > > > > > Current Tx Power: This attribute contains the transmit output > > power > > > in mW. > > > > This e-mail and attachments contain confidential information from > > HUAWEI, which is intended only for the person or entity > whose address > > is listed above. Any use of the information contained herein in any > > way (including, but not limited to, total or partial disclosure, > > reproduction, or dissemination) by persons other than the intended > > recipient's) is prohibited. If you receive this e-mail in error, > > please notify the sender by phone or email immediately and > delete it! > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:47:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzDk-0002lv-QT for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:20 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzDj-0001XU-9M for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:20 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D07EC398051 for ; Mon, 9 Oct 2006 10:47:18 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 2FFD4430018 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E04D3980B9 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4FF513980CC for ; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:09 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857099053:sNHT1415841238" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Hg9am019936; Mon, 9 Oct 2006 10:42:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HfsP7004119; Mon, 9 Oct 2006 10:42:09 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to Issue 144 - Need length value forvendor-specific payload Thread-Index: AcbfQ02sg1NxyP/NR1CzZBy/HHZkpgMe8Zqg From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:08.0599 (UTC) FILETIME=[3E317E70:01C6EBCA] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to Issue 144 - Need length value forvendor-specific payload X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883407022==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a multi-part message in MIME format. --===============1883407022== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3E132947" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3E132947 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why? The CAPWAP Message Element header already includes a length. This will cause the said message element to have two length fields. =20 I disagree with the change request. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 12:05 PM To: capwap Subject: [Capwap] Proposed resolution to Issue 144 - Need length value forvendor-specific payload =09 =09 I propose to resolve this issue by accepting the recommendation to add a length field to the vendor-specific element. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3E132947 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why?=20 The CAPWAP Message Element header already includes a length. This will = cause the=20 said message element to have two length fields.
 
I=20 disagree with the change request.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 12:05 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to Issue 144 - Need length value forvendor-specific=20 payload

I propose to resolve this issue by accepting the recommendation = to add a=20 length field to the vendor-specific element.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3E132947-- --===============1883407022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1883407022==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:47:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzDn-0002m7-2j for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:23 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzDl-0001XZ-G6 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:23 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 113F5398116 for ; Mon, 9 Oct 2006 10:47:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 4F769430018 for ; Mon, 9 Oct 2006 10:42:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2643A3980B5 for ; Mon, 9 Oct 2006 10:42:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2FFCB3980B3 for ; Mon, 9 Oct 2006 10:42:08 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:07 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563232:sNHT88222252" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Hg7rQ022894; Mon, 9 Oct 2006 10:42:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HfZP9003999; Mon, 9 Oct 2006 10:42:07 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:07 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8949@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190. Thread-Index: AcbfQeKMfyUP0SjYRh6tcN8kscMZzgMexf4A From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:07.0436 (UTC) FILETIME=[3D8008C0:01C6EBCA] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368309842==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 This is a multi-part message in MIME format. --===============0368309842== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3D546D27" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3D546D27 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, =20 I'm quite confused by this request. First, the WTP already sends back a response message when it receives the request. Why can't we simply embed the status code in that response message? I don't understand the need for a new message. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 11:55 AM To: capwap Subject: [Capwap] Proposed resolution to issues 72, 73, 108, 181, and 190. =09 =09 These issues all have to do with the configuration process and error handing of that process.=20 =20 I propose to resolve these comments by doing the following: 1) Add a add a Configuration Status Acknowledgement Frame. The WTP would send this frame back with a status code to indicate success or failure of its ability to apply the configuration. =20 2) The configuration update response could be modified to include any message elements that could not be applied by the WTP. =20 3) In the case of a configuration message that exceeds the MTU between the WTP and the AC, the CAPWAP fragmentation mechanism would be allow the message to be fragmented by the AC and reassembled by the WTP. I don't think there needs to be any updates to CAPWAP to address this issue.=20 =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3D546D27 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike,
 
I'm=20 quite confused by this request. First, the WTP already sends back a = response=20 message when it receives the request. Why can't we simply embed the = status code=20 in that response message? I don't understand the need for a new=20 message.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 11:55 AM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to issues 72, 73, 108, 181, and 190.

These issues all have to do with the configuration process and = error=20 handing of that process.
 
I propose to resolve these comments by doing the following:
1) Add a add a Configuration Status Acknowledgement Frame. = The WTP=20 would send this frame back with a status code to indicate success or = failure=20 of its ability to apply the configuration.
 
2) The configuration update response could be modified to include = any=20 message elements that could not be applied by the WTP.
 
3) In the case of a configuration message that exceeds the MTU = between=20 the WTP and the AC, the CAPWAP fragmentation mechanism would be allow = the=20 message to be fragmented by the AC and reassembled by the WTP. I don't = think=20 there needs to be any updates to CAPWAP to address this issue.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3D546D27-- --===============0368309842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0368309842==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:47:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzE8-0003m3-Fu for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:44 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzE6-0001eW-KW for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:47:44 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id E138439811E for ; Mon, 9 Oct 2006 10:47:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id C81FC430018 for ; Mon, 9 Oct 2006 10:39:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7AF011448016 for ; Mon, 9 Oct 2006 10:39:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 1BA121448014 for ; Mon, 9 Oct 2006 10:39:34 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:39:34 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329561920:sNHT159185506" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HdYgJ018241; Mon, 9 Oct 2006 10:39:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HdYOV002685; Mon, 9 Oct 2006 10:39:34 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:39:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:39:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8939@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 145 "Need additional detailfor how a STA session is created" /was:Re: Packet flows fornew STA session Thread-Index: AcbkEoNvdSntQRedR8utBQA19CT1TQHsHtBQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:39:26.0282 (UTC) FILETIME=[DD71E2A0:01C6EBC9] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Behcet Sarikaya , capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 145 "Need additional detailfor how a STA session is created" /was:Re: Packet flows fornew STA session X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0837245716==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 This is a multi-part message in MIME format. --===============0837245716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBC9.DD412A6F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBC9.DD412A6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 2:53 PM To: Michael Montemurro Cc: Behcet Sarikaya; capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 145 "Need additional detailfor how a STA session is created" /was:Re: Packet flows fornew STA session =09 =09 All, =20 Issue 145 is listed below: There is a lot of detail missing in CAPWAP describing how a STA session is created for both splitMAC and localMAC. It would be quite useful if someone would take figures 5 and 7 and add the detail. The proposed resolution to Issue 145 is: Close with no change to the text. Figures 5 and 7 are intended to provide an illustration of the division of =09 labor in the local and split-MAC cases, rather than a comprehensive description of session establishment. The lists of message elements are included in the text. Comments welcome, Thanks, Dorothy On 6/30/06, Michael Montemurro wrote:=20 David, =20 I created issue number 145 to track this issue. =20 Cheers, =20 Mike =09 =20 =09 On 6/23/06, Behcet Sarikaya wrote:=20 Hi David, Roaming with key caching and other new developments is a work item for possible rechartering. I think the present text is OK.=20 =09 Regards, =20 =09 --behcet =09 =09 =09 ----- Original Message ---- From: David T. Perkins < dperkins@dsperkins.com > To: capwap@frascone.com Sent: Friday, June 23, 2006 1:16:46 PM Subject: [Capwap] Packet flows for new STA session=20 =09 =09 HI, =09 There is a lot of detail missing in CAPWAP describing how a STA session is created for both splitMAC and localMAC. It would be quite useful if someone would take figures 5 and 7 and add the detail.=20 =09 Regards, /david t. perkins=20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBC9.DD412A6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 2:53 PM
To: Michael Montemurro
Cc: Behcet = Sarikaya;=20 capwap@frascone.com
Subject: [Capwap] Proposed Resolution to = Issue=20 145 "Need additional detailfor how a STA session is created" /was:Re: = Packet=20 flows fornew STA session

All,
 
Issue 145  is listed below:
There is a lot of detail missing in CAPWAP describing
how a STA session is created for both splitMAC and
localMAC. It would be quite useful if someone would
take figures 5 and 7 and add the detail.
The proposed =
resolution to Issue 145 is:
Close with no change to the text. =
Figures 5 and 7 are
intended to provide an illustration of the =
division of

labor in the local and split-MAC cases, rather than
a =
comprehensive description of session establishment.
The lists of =
message elements are included in the text.
Comments =
welcome,
Thanks,
Dorothy
On 6/30/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David,
 
I created issue = number 145 to track this issue.
 
Cheers,
 
Mike

 
On 6/23/06, Behcet=20 Sarikaya <behcetsarikaya@yahoo.com > wrote:=20
Hi=20 David,
  Roaming with key caching and other new = developments is a=20 work item for possible rechartering. I think the present text is = OK.=20

Regards,
 

--behcet


-----=20 Original Message ----
From: David T. Perkins <=20 dperkins@dsperkins.com>
To: capwap@frascone.com
Sent: Friday, June 23, = 2006=20 1:16:46 PM
Subject: [Capwap] Packet flows for new STA session =

HI,

There is a lot of detail missing in CAPWAP=20 describing
how a STA session is created for both splitMAC=20 and
localMAC. It would be quite useful if someone would
take = figures=20 5 and 7 and add the detail.

Regards,
/david t. perkins=20 =

_________________________________________________________________=
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20
 

=

________________________________________= _________________________
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =



_____________________= ____________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBC9.DD412A6F-- --===============0837245716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0837245716==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:52:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzIx-0005hm-CH for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:52:43 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzIw-0002XN-1v for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:52:43 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B4B273980B7 for ; Mon, 9 Oct 2006 10:52:40 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id A3B7F430018 for ; Mon, 9 Oct 2006 10:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 93B7D3980DD for ; Mon, 9 Oct 2006 10:42:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id E6C11398083 for ; Mon, 9 Oct 2006 10:42:11 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:11 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857099076:sNHT169004306" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgBLY019960; Mon, 9 Oct 2006 10:42:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgAOX004412; Mon, 9 Oct 2006 10:42:11 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:09 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames Thread-Index: AcbieUNFx2Heibn8RoyIXIp63oas0QAIb/jgAkkkjMA= From: "Pat Calhoun (pacalhou)" To: "Cheng Hong" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:42:09.0971 (UTC) FILETIME=[3F02D830:01C6EBCA] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2068705550==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 935fcc3d6c448ae30077dce3cfc94471 This is a multi-part message in MIME format. --===============2068705550== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3EE03383" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3EE03383 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Even in the case of EDCA, there is no guarantees that the STA can send an 802.1X frame with a high priority UP field. This is especially true if the WTP requires authorization prior to making use of the QoS class. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: Wednesday, September 27, 2006 6:20 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames =09 =09 Hi Mike, =20 In the HCCA case, the TID value is in the range of 8 to 15, and according to clause 6.1.1.1.1 point b: =20 "b) QoS subtypes, in which case the QAP shall infer the UP value from the TID in the QoS Control field directly for TID values between 0 and 7. For TID values between 8 and 15, the QAP shall extract the UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the associated TCLAS (traffic classification) element, as applicable." =20 It seems that the WTP needs to do much more to obtain the actual UP value. In case the TSPEC or TCLAS elemets are located at the AC, how would the WTP get the UP value in the HCCA case? =20 Or is there any place that prevents sending EAPOL frames using HCCA? If that is the case, it is not a problem. But, then again, all the data traffic sent using HCCA will have difficulty to obtain the correct priority in CAPWAP delivery. =20 cheers =20 Cheng Hong =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Thursday, September 28, 2006 2:23 AM To: Cheng Hong Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214-Prioritization of IEEE 802.1X frames =09 =09 Cheng, =20 In the HCCA case, the TID case should work as well. I don't see why it wouldn't. =20 Cheers, =20 Mike =09 =20 On 9/26/06, Cheng Hong wrote:=20 Hi Mike,=20 =20 It seems OK to use TID in the EDCA case. If the HCCA is used, would the TID still be meaningful in mapping the priority? (Haven't check the 802.11 standards in detail).=20 =20 cheers =20 Cheng Hong=20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Wednesday, September 27, 2006 12:24 AM=20 =09 To: Cheng Hong Cc: zhaoyujin 31390; capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =09 =20 =09 Cheng, =20 Thanks for you input. =20 Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field. =20 Cheers, =20 Mike =20 On 9/25/06, Cheng Hong wrote:=20 Hi Mike, =20 In this case, I tend to agree with the other Michael on the first point.=20 =20 However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?=20 =20 cheers =20 Cheng Hong =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Tuesday, September 26, 2006 1:17 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap=20 =09 Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =09 =20 =09 Cheng Hong, =20 In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. =20 Cheers, =20 Mike =20 On 9/24/06, Cheng Hong wrote:=20 Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20 =09 =20 =09 Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =09 =20 On 9/23/06, zhaoyujin 31390 wrote:=20 Firstly, I have some doubt one this suggestion. =09 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. =09 So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 =09 Thanks Michael =09 =09 =09 >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike =09 =09 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =09 =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 =09 ------_=_NextPart_001_01C6EBCA.3EE03383 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Even=20 in the case of EDCA, there is no guarantees that the STA can send an = 802.1X=20 frame with a high priority UP field. This is especially true if the WTP = requires=20 authorization prior to making use of the QoS class.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Cheng Hong=20 [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Wednesday, = September 27,=20 2006 6:20 PM
To: Michael Montemurro
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution=20 to Issue214-Prioritization of IEEE 802.1X frames

Hi=20 Mike,
 
In=20 the HCCA case, the TID value is in the range of 8 to 15, and according = to=20 clause 6.1.1.1.1 point b:
 
"b) QoS = subtypes, in which=20 case the QAP shall infer the UP value from the TID in the QoS Control=20 field
directly for=20 TID values between 0 and 7. For TID values between 8 and 15, the QAP = shall=20 extract the
UP value in=20 the UP subfield of the TS Info field in the associated TSPEC or from = the UP=20 field in the
associated TCLAS (traffic classification) element, as=20 applicable."
&nbs= p;
It seems that the WTP needs to do much more = to obtain=20 the actual UP value. In case the TSPEC or TCLAS elemets are located at = the AC,=20 how would the WTP get the UP value in the HCCA = case?
&nbs= p;
Or is there any place that prevents sending = EAPOL=20 frames using HCCA? If that is the case, it is not a problem. But, then = again,=20 all the data traffic sent using HCCA will have difficulty to obtain = the=20 correct priority in CAPWAP=20 delivery.
&nbs= p;
cheers
&nbs= p;
Cheng Hong
&nbs= p;
 
 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Thursday, = September=20 28, 2006 2:23 AM
To: Cheng Hong
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed=20 resolution to Issue 214-Prioritization of IEEE 802.1X=20 frames

Cheng,
 
In the HCCA case, the TID case should work as well. I don't see = why it=20 wouldn't.
 
Cheers,
 
Mike

 
On 9/26/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
Hi Mike,=20
 
It seems OK = to use TID in=20 the EDCA case. If the HCCA is used, would the TID still be = meaningful in=20 mapping the priority? (Haven't check the 802.11 standards in = detail).=20
 
cheers
 
Cheng Hong=20

From: = Michael Montemurro=20 [mailto:montemurro.michael@gmail.com ] =
Sent:=20 Wednesday, September 27, 2006 12:24 AM=20

To: = Cheng=20 Hong
Cc: zhaoyujin 31390; capwap
Subject: = Re:=20 [Capwap] This is not need.: Proposed resolution to Issue 214=20 -Prioritization of IEEE 802.1X=20 frames

 
Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP = priority=20 should be based on the TID(UP). Which means yes, the WTP = would need=20 to read into the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com > = wrote:=20
Hi=20 Mike,
 
In this = case, I tend=20 to agree with the other Michael on the first point.=20
 
However, on the=20 mapping 802.11e priority back to CAPWAP priority, I am = not really=20 sure how that is done. Is it based on 802.11e AC or TID (UP)? = For=20 later case, does it mean the WTP need to read into the QoS = Control=20 Field?
 
cheers
 
Cheng=20 Hong
 
 
From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com ]=20
Sent: Tuesday, September 26, 2006 1:17=20 AM
To: Cheng Hong
Cc: zhaoyujin 31390; = capwap=20

Subject: Re: [Capwap] This is not = need.:=20 Proposed resolution to Issue 214 -Prioritization of IEEE = 802.1X=20 frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and management = frames=20 are treated as CAPWAP data frames. Given that, = all CAPWAP=20 data traffic would need to go to the same logical instance = of the=20 AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > = wrote:=20
Hi = Michael &=20 Michael,
 
Sorry if the=20 issue has already been discussed before. Just thinking if = the WTP=20 does not differentiate 802.1X frames from normal data = frames,=20 would it be possible that the 802.1X frames being = forwarded to a=20 different AC instance than the one processing the=20 control/management frames? (in case different ACs are used = to=20 process the control and data channel) Is this=20 acceptable?
 
cheers
 
Cheng=20 Hong
 
 
 

From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com] =
Sent:=20 Sunday, September 24, 2006 3:18 AM
To: = zhaoyujin=20 31390
Cc: capwap
Subject: Re: = [Capwap] This=20 is not need.: Proposed resolution to Issue 214 = -Prioritization=20 of IEEE 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this = feature.
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > = wrote:=20
Firstly, I have some = doubt one=20 this suggestion.

1. If CAPWAP difines like = this, AP=20 device must decode the payload frames of 802.11 = frames.
2.=20 Another problem, the 802.1x priority should be = implement by=20 802.11e. When station sends 802.11 data frames, it can = set=20 802.11e priority. AP should transfer 802.11e to actual = CAPWAP=20 packet priority.

So that I think CAPWAP does = not need=20 consider the priority of 802.11 data frames payload.=20 =

Thanks
Michael



>Practically=20 speaking, IEEE 802.1X frames should be transmitted at = the same=20 priority as >IEEE 802.11 Management=20 frames.
>
>I will update Section 11.5, = rename=20 Quality of Service for IEEE 802.11 Control Messages = >to=20 "Quality
>of Service for IEEE 802.11 control = messages=20 and IEEE 802.1X EAPoL frames" and add text to = >indicate=20 that IEEE 802.1X frames are sent at a higher = priority.
>=20
>Cheers,
>
>Mike


This = e-mail and=20 attachments contain confidential information from = HUAWEI,=20 which is intended only for the person or entity whose = address=20 is listed above. Any use of the information contained = herein=20 in any way (including, but not limited to, total or = partial=20 disclosure, reproduction, or dissemination) by persons = other=20 than the intended recipient's) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by = phone or=20 email
immediately and delete = it!

 

Practically speaking, IEEE 802.1X frames should = be=20 transmitted at the same priority as IEEE 802.11 = Management=20 frames.
 
I will update Section 11.5, rename Quality of = Service for=20 IEEE 802.11 Control Messages to "Quality
of Service = for=20 IEEE 802.11 control messages and IEEE 802.1X EAPoL = frames" and=20 add text to indicate that IEEE 802.1X frames are sent = at a=20 higher priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, = please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =




<= BR>

------_=_NextPart_001_01C6EBCA.3EE03383-- --===============2068705550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2068705550==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:55:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzLj-0006uQ-A7 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:55:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzLh-0003AO-OZ for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:55:35 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5610A3980CB for ; Mon, 9 Oct 2006 10:55:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BE37C4300F7 for ; Mon, 9 Oct 2006 10:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5FADD3980BC for ; Mon, 9 Oct 2006 10:42:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 601013980CA for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:11 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563272:sNHT13862984152" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgBKj022946; Mon, 9 Oct 2006 10:42:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgAOV004412; Mon, 9 Oct 2006 10:42:11 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8946@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to Issue 221 - Fix figure 5: remove"(clear text)" Thread-Index: AcbfPLysG8xYaX+oR+yDTWU7r7BUZwMfkyqg From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:03.0518 (UTC) FILETIME=[3B2A31E0:01C6EBCA] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to Issue 221 - Fix figure 5: remove"(clear text)" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0759644496==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. --===============0759644496== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3B1F5FD5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3B1F5FD5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, =20 The issue is more than simply the figure, and should also include the text that follows the two figures out mention. At one point the Add Station had the "AKM Only" bit, but this has now moved to the "IEEE 802.11 Station Session Key" section. I don't believe that the "Clear Text" should be removed per se, but instead that both the figure and the text be representative of the recent changes in the protocol. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 11:18 AM To: capwap Subject: [Capwap] Proposed resolution to Issue 221 - Fix figure 5: remove"(clear text)" =09 =09 Both figure 5 and figure 7 will to be updated to be consistent with the add mobile message element definition. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3B1F5FD5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mike,
 
The=20 issue is more than simply the figure, and should also include the text = that=20 follows the two figures out mention. At one point the Add Station had = the "AKM=20 Only" bit, but this has now moved to the  "IEEE 802.11 Station = Session=20 Key" section. I don't believe that the "Clear Text" should be = removed per=20 se, but instead that both the figure and the text be representative of = the=20 recent changes in the protocol.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 11:18 AM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to Issue 221 - Fix figure 5: remove"(clear=20 text)"

Both figure 5 and figure 7 will to be updated to be consistent = with the=20 add mobile message element definition.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3B1F5FD5-- --===============0759644496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0759644496==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:56:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzMf-0007nM-SE for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:56:33 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzMb-0003Lc-LK for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:56:33 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 282B93980C2 for ; Mon, 9 Oct 2006 10:56:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B1714430018 for ; Mon, 9 Oct 2006 10:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9C6243980B9 for ; Mon, 9 Oct 2006 10:42:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7D851398027 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563311:sNHT1867884270" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgE5I010680; Mon, 9 Oct 2006 10:42:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg7P5004332; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8952@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Editorial - WTP Event Request Thread-Index: AcbkBoQ052ehncIxTPK7J3IBXAzXnQHuroJQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "sujay" , "Saravanan Govindan" X-OriginalArrivalTime: 09 Oct 2006 17:42:11.0553 (UTC) FILETIME=[3FF43D10:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025020521==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f This is a multi-part message in MIME format. --===============1025020521== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3FC7779D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3FC7779D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 1:28 PM To: sujay; Saravanan Govindan Cc: capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request =09 =09 All, =20 Below is the proposed resolution to issue 225 (also copied below). =20 Comments welcome. =20 Dorothy =20 =09 ------------------------------------------------------------------------ ----------------- Proposed resolution: =20 Insert the following paragraph at the end of section 4.3 "CAPWAP Control Messages" =20 "CAPWAP control messages sent from the WTP to the AC indicate that the WTP is operational, providing an implicit keep-alive=20 mechanism for the WTP. The Echo Request/Echo Response Control channel=20 management messages provide an explicit keep-alive mechanism when other CAPWAP control messages are not exchanged." =20 Also - I notice that the message types in 4.3 are not the same as the message sections. Propose to update the 4.3 list to match the existing text sections: changeFirmware Management to Device Management, add missing Join, Control Channel Management bullet items. =20 =09 ------------------------------------------------------------------------ ------------------------ Issue 225: =20 =20 Hi Scott, =09 I see your point. I agree that any control message serves the purpose of keep alive for the WTP. =09 In this case, I suggest the same text in Section 4.3 (CAPWAP Control Messages) with slight modification; =09 "The exchange of a CAPWAP control message serves as an implicit keep alive mechanism for the WTP. The arrival of a CAPWAP control message at the AC indicates the WTP is operational. In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see Section 7)." =09 Comments? =09 Saravanan From: Scott G Kelly [mailto:scott [at] hyperthought.com] Sent: Monday, July 03, 2006 9:20 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Editorial - WTP Event Request Hi Saravanan, I thought there was general agreement that if *any* authenticated control traffic (not just an event request) is observed during the echo interval, this is implicit proof of liveness, and no echo request is required for that interval. Having text like what's suggested below (that only references the event request) might lead people to incorrectly conclude that only an event request can obviate the need for an echo exchange. Why should we have text which confers this special status only on the event request, rather than on all/any authenticated control channel traffic? Scott Saravanan Govindan wrote: > All, > > > > I would like to suggest an editorial update to Section 9.5 (WTP Event > Request). > > > > This is based on earlier discussions of how WTP Event Request serves as > an implicit keep alive mechanism for the WTP. I believe this observation > can be made explicit in this section. > > > > I suggest the following after the 1^st paragraph of Section 9.5; > > > > "The exchange of WTP Event Request serves as an implicit keep alive > mechanism for the WTP. The arrival of a WTP Event Request message at the > AC indicates the WTP is operational. In cases where WTP Event Request is > not exchanged, explicit keep alive is used (see Section 7)." >=20 =20 On 9/25/06, Pat Calhoun (pacalhou) wrote:=20 I have created issue 225 to track this request. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Monday, August 28, 2006 10:36 AM To: sujay; Saravanan Govindan; capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request =09 =20 I believe the quoted text is the agreed upon text. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Sunday, August 27, 2006 11:18 PM=20 To: 'Saravanan Govindan'; capwap@frascone.com Subject: Re: [Capwap] Editorial - WTP Event Request=20 =09 =20 Saravanan, =20 =20 "The exchange of a CAPWAP control message serves as an implicit keep alive mechanism for the WTP. The arrival of a CAPWAP control message at=20 the AC indicates the WTP is operational. In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see Section 7)."=20 =20 As the understanding is, arrival of *any* authenticated control message obviates the need for an 'echo request' message, to keep up the neighbour as up. I wouldn't prefer the last statement..viz.. "In cases where regular CAPWAP control messages are not exchanged, explicit keep alive is used (see Section 7)." This kind of sounds making the keep alive and control message usage mutually exclusive. Could we put more simpler, " CAPWAP control messages MAY/SHOULD be treated equivalent to an Echo request message=20 received(See Section 7)" , Again noting; WTP event request message is just one of those possible control messages. Regds, Sujay G =09 My Location; =09 http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085 &t=3Dh&hl=3Den =09 =09 =09 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!=20 =09 =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com ]=20 Sent: Monday, August 28, 2006 8:54 AM To: capwap@frascone.com Subject: [Capwap] Editorial - WTP Event Request=20 =09 =20 All, =20 This is a follow-up on an earlier thread; =20 =09 http://lists.frascone.com/pipermail/capwap/msg03208.html=20 =20 Is the proposal ok for the next draft?=20 =20 Cheers, =09 Saravanan =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 ------_=_NextPart_001_01C6EBCA.3FC7779D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Works=20 for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 1:28 PM
To: sujay; Saravanan Govindan
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Editorial - WTP = Event=20 Request

All,
 
Below is the proposed resolution to issue 225 (also = copied=20 below).
 
Comments welcome.
 
Dorothy
 
=
--------------------------------------------------------------------= ---------------------
Proposed=20 resolution:
 
Insert the following paragraph at the end of section 4.3 "CAPWAP = Control=20 Messages"
 
"CAPWAP control messages sent from the WTP to the AC indicate = that
the WTP is operational, providing an implicit keep-alive=20
mechanism for the WTP. The Echo Request/Echo Response Control = channel=20
management messages provide an explicit keep-alive mechanism when = other CAPWAP
control messages are not = exchanged."
 
Also - I notice that the message types in = 4.3 are not=20 the same as the
message sections. Propose to update the=20 4.3 list to match the existing text sections:
changeFirmware Management to Device Management,=20 add
missing Join, Control Channel Management bullet=20 items.
 
----------------------------------------------------------------= --------------------------------
Issue 225:
 
 
Hi Scott,

I see your point. I agree that any control message serves the purpose of
keep alive for the WTP.

In this case, I suggest the same text in Section 4.3 (CAPWAP Control
Messages) with slight modification;

"The exchange of a CAPWAP control message serves as an implicit keep
alive mechanism for the WTP. The arrival of a CAPWAP control message at
the AC indicates the WTP is operational. In cases where regular CAPWAP
control messages are not exchanged, explicit keep alive is used (see
Section 7)."

Comments?

Saravanan
From: Scott G Kelly [mailto:scott [at] hyperthought.com]=20
Sent: Monday, July 03, 2006 9:20 PM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Editorial - WTP Event Request

Hi Saravanan,

I thought there was general agreement that if *any* authenticated=20
control traffic (not just an event request) is observed during the echo=20
interval, this is implicit proof of liveness, and no echo request is=20
required for that interval. Having text like what's suggested below=20
(that only references the event request) might lead people to=20
incorrectly conclude that only an event request can obviate the need for

an echo exchange.

Why should we have text which confers this special status only on the=20
event request, rather than on all/any authenticated control channel
traffic?

Scott

Saravanan Govindan wrote:
> All,
>=20
> =20
>=20
> I would like to suggest an editorial update to Section 9.5 (WTP =
Event=20
> Request).
>=20
> =20
>=20
> This is based on earlier discussions of how WTP Event Request =
serves
as=20
> an implicit keep alive mechanism for the WTP. I believe this
observation=20
> can be made explicit in this section.
>=20
> =20
>=20
> I suggest the following after the 1^st paragraph of Section 9.5;
>=20
> =20
>=20
> "The exchange of WTP Event Request serves as an implicit keep alive =

> mechanism for the WTP. The arrival of a WTP Event Request message =
at
the=20
> AC indicates the WTP is operational. In cases where WTP Event =
Request
is=20
> not exchanged, explicit keep alive is used (see Section 7)."
> 
 

On 9/25/06, Pat Calhoun=20 (pacalhou) <pcalhoun@cisco.com> = wrote:=20
I have = created issue 225 to track this=20 request.
 

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 

From: Pat Calhoun (pacalhou)=20
Sent: Monday, August 28, 2006 10:36 AM
To: = sujay;=20 Saravanan Govindan; capwap@frascone.com
Subject: Re: = [Capwap]=20 Editorial - WTP Event Request

 
I believe = the quoted text=20 is the agreed upon text.
 

Pat Calhoun
CTO, Wireless = Networking=20 Business Unit
Cisco Systems

 

From: sujay [mailto:sujayg@huawei.com]=20
Sent: Sunday, August 27, 2006 11:18 PM
To: = 'Saravanan Govindan'; capwap@frascone.com
Subject: Re: = [Capwap]=20 Editorial - WTP Event Request

 
Saravanan,
 
<snip> 
"The=20 exchange of a CAPWAP control message serves as an implicit = keep
alive=20 mechanism for the WTP. The arrival of a CAPWAP control message = at=20
the AC indicates the WTP is operational. In cases where = regular=20 CAPWAP
control messages are not exchanged, explicit keep = alive is=20 used (see
Section 7)."<snip/>
 
As the = understanding=20 is, arrival of *any* authenticated control message=20 obviates
the need = for an 'echo=20 request' message, to keep up the neighbour as=20 up.
 I = wouldn't prefer=20 the last statement..viz..
"In cases = where regular=20 CAPWAP control messages are not exchanged, explicit keep alive = is used=20 (see
Section 7)."
This kind = of sounds=20 making the keep alive and control message usage mutually = exclusive.=20 Could we put
more = simpler, " CAPWAP=20 control messages MAY/SHOULD  be treated equivalent to an = Echo=20 request message
received(See Section=20 7)" ,
Again = noting; WTP event=20 request message is just one of those possible control=20 messages.
Regds,
Sujay G

My Location;
http://maps.google.com/maps?ll=3D14.626109,76.959229&=
spn=3D4.724852,7.525085&t=3Dh&hl=3Den



This e-mail and attachments contain confidential =
information from HUAWEI, which is intended only for the person or entity =
whose address is listed above. Any use of the information contained =
herein in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than the =
intended recipient's) is prohibited. If you receive this e-mail in =
error, please notify the sender by phone or email immediately and delete =
it!=20
 

From: Saravanan Govindan = [mailto:Saravanan.Govindan@sg.panasonic.com ] =
Sent:=20 Monday, August 28, 2006 8:54 AM
To: capwap@frascone.com
Subject: = [Capwap]=20 Editorial - WTP Event Request

 

All,

 

This is a = follow-up on an=20 earlier thread;

 

http://lists.frascone.com/pipermail/capwap/msg03208.html =

 

Is the proposal ok = for the=20 next draft?

 

Cheers,


Saravanan


_________________________________________________________________<= BR>To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap


------_=_NextPart_001_01C6EBCA.3FC7779D-- --===============1025020521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1025020521==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 13:57:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzNm-00089g-32 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:57:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzNi-0003WK-KS for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 13:57:42 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 07EC93980A1 for ; Mon, 9 Oct 2006 10:57:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 425B9430018 for ; Mon, 9 Oct 2006 10:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3079C3980D2 for ; Mon, 9 Oct 2006 10:39:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3CCE33980D7 for ; Mon, 9 Oct 2006 10:39:37 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:39:37 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857098045:sNHT244556678" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HdbMR018269; Mon, 9 Oct 2006 10:39:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HdbOb002725; Mon, 9 Oct 2006 10:39:37 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:39:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:39:25 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8938@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 163 "WTP Descriptorinformation is not required at Join time" /was Re: Acommentary on CAPWAP-01 operations Thread-Index: AcbkETmbyCYmBckFSum/caEWxlaM9QHsaS4g From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:39:25.0694 (UTC) FILETIME=[DD1829E0:01C6EBC9] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.957 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 163 "WTP Descriptorinformation is not required at Join time" /was Re: Acommentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1766738814==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 2d4a64066b1774fc2641038d4c8545f6 This is a multi-part message in MIME format. --===============1766738814== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBC9.DCF01A7B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBC9.DCF01A7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel very strongly that the AC should not be maintainin significant state for the WTP during the discovery phase. So this message element must be included in the join, regardless of whether the discovery was made or not. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 2:41 PM To: Michael Montemurro Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 163 "WTP Descriptorinformation is not required at Join time" /was Re: Acommentary on CAPWAP-01 operations =09 =09 All, =20 Issue 163 "WTP Descriptor information is not required at Join time" is listed below: 14) The WTP Descriptor information is not required at Join time. =09 Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is=20 provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download. =20 The proposed resolution to Issue 163 is: =20 Close with no change to the draft. The WTP descriptor element is included in the optional Discover Request message and the Join Request to indicate the WTP info to the AC. If the Discover Request is not sent, then the Join Request is the first message in which the AC receives this information. =20 Comments welcome. =20 Thanks, =20 Dorothy =20 On 6/30/06, Michael Montemurro wrote:=20 David, Pat, =20 I created issues 150-198 to deal with the points in David's email. Happy hunting! =20 Mike =09 =20 =09 On 6/27/06, Pat Calhoun (pacalhou) wrote:=20 Going through David's lengthy document, he has raised an interesting number of points that I believe require issues to be created. At one=20 point I'm paraphrasing Dave's comments in order to be brief, and introducing my own numbering scheme. =09 1) Can message elements be in any order? (I believe they should be) =09 Yes, and I suspect we need to include text to make it more=20 obvious. =09 =09 2) Are all specified message elements required? (The obvious answer is "yes", but this document doesn't discuss versioning. For example, what if in a new version of CAPWAP an additional message element was to be=20 added. Would a new message type be created and the additional message element added to it, or the existing type reused?) =09 This is a great question, and one that does need to be addressed in the spec. In the Diameter protocol we dealt with this issue by=20 including a "Mandatory to implement" bit. If any AVP was received, whose bit was set, yet was not recognized, then the request had to be rejected. =09 We could consider something similar here, but I believe with the=20 firmware download component of the protocol it may be less of an issue - although not guaranteed. I would hope (and expect) that as the CAPWAP protocol extends, the AC would push new firmware to the WTP. This does=20 require that the initial part of the state machine be fairly static, and this could be an area where the "Mandatory to implement" bit could be useful as it would allow the AC to fall back to older protocol behavior.=20 =09 3) CAPWAP-01 doesn't do a good job of indicating which message elements can be repeated. =09 Another good point. When we list the message elements, we should note whether the frequently is 0-1 (meaning absent or once), 1 (only=20 once) or 0+ (meaning any number of them could be present. =09 =09 4) Can "additional" message elements be added to a message? (I believe so for reporting capabilities, statistics, and events. For configuration, there is nothing in the protocol that says what happens when one end gets an configuration element it doesn't know about. Should it be ignored, and the other elements processed, or should the complete operation failed?)=20 =09 The "Mandatory to implement" bit above could address this issue. If an unrecognized message element is found to have the bit set, then the whole message needs to be rejected. If the bit is not set, the=20 message element may be safely ignored. =09 =09 5) The config has a concept of "default value" for each configuration attribute. However, the default values are not clearly specified. This needs to be resolved to be able to support "default values".=20 =09 Another good point raised by David. =09 =09 6) the documentation of which "binding specific" message elements are to be included with CAPWAP messages is not consistent, and is difficult to=20 follow. =09 Has this been addressed in the latest (-02) document? =09 =09 7) There are some message elements that cause "actions". This approach to protocol design is problematic and should be eliminated.=20 =09 Could you be more specific as well as provide guidance on what you would like to see? =09 =09 8) The message types are inconsistently named, and do not follow the conventions of well designed protocols. Can the operations be named=20 consistently with the following terminology: 1) request/response (used to get/set/perform action) 2) report/ack (use to tell the other side something) =09 Could you provide your thoughts on which messages fall within=20 which one of your categories? =09 =09 9) Many of the configuration items, and status items are not listed in one section with definitions. (Well make it two sections - one for CAPWAP and the other which is "binding" specific.) For example, not all=20 of the time period lengths are identified and specified in section 4.5. =09 Unfortunately, the document has gone back and forth a few times and before we opt to change the structure of the document, I'd like to=20 ensure that we have broad agreement on what we want - with the understanding that we will never make everyone happy. =09 =09 10) each operation should have listed in which states it can be sent and received =09 I do not understand your comment. =09 =09 11) All strings, such as WTP location, should be changed from US-ASCII encoding to UTF-8 encoding. =09 Agreed. =09 12) The term "mobile" is not really accurate when describing wireless=20 interfaces, since wireless does not imply mobile. Can we just use the techie term "STA" instead. =09 I agree we should use the term Station, or STA for short. =09 =09 13) The WTP Descriptor message element contains too much information,=20 lacks clarity on the WTP encryption field and includes version numbers, which should be in string form. =09 To the first point, I disagree. I think there is value in knowing everything about the WTP. The AC vendors can expose whatever information=20 they want, but I don't believe anything is unnecessary. =09 To the second point, this is one of those areas where the concept of the technology binding creates complexity. Given that we cannot simply discuss 802.11i at this point, the only thing we can do is punt to another section in the technology binding section. That said, I agree with Dave that the 802.11 binding section is too light in this area. However, I would much prefer that instead of trying to address this=20 specific issue, we discuss whether we should even be supporting the mode of operation where 802.11i is performed in the AC - especially with the introduction of DTLS to secure the data plane. Right now, it just feels=20 like we have too many options and I am worried that interoperability will be severely impacted (not to mention protocol complexity). =09 To the last point, I have no issues with including text stating=20 that the version numbers should be in string form. =09 =09 14) The WTP Descriptor information is not required at Join time. =09 Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is=20 provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download. =09 =09 15) Are the values in the WTP Frame Encryption a capabilities bit, or an enum? =09 Looks like an enum to me. Not sure what Dave would prefer the text to read. There are various other similar comments throughout, which I=20 will not repeat here. =09 =09 16) The Discovery Response is broken. The AC SHOULD NOT be providing any info to a WTP (or something that claims to be a WTP). Also, the AC should tell the WTP what to do next, with choices: 1) Ok to try to join,=20 2) don't try to join, 3) try discover on a list of returned ACs) =09 I don't believe there is an issue with sending the AC's information to the WTP, but would solicit input from the list. That=20 said, some of the information in the AC Descriptor is required, such as the current load on the AC. No point is trying to join if he AC indicates it's already at max capacity. I believe if the AC does not return the response, then it implies=20 (2). Otherwise, it is (1). (3) is handled during the join or configure process, which I believe is right. =09 =09 17) Is AC Name text? =09 Yes, and same with WTP Name. =09 =09 18) Primary Discovery are not required.=20 =09 Disagree. Required for failover. =09 =09 19) The text does not make it clear that the contents of the WTP Location is informative only, and as Dave calls it, a "scratchpad". =09 Well, to be honest, I thought the example "next to the fridge"=20 made it clear that the information did not derive from any scientific formula. The description also states this is a user-defined. I believe this should be good enough. =09 =09 20) Session is not required =09 I believe you may be correct that with the transition to DTLS, this is no longer required. =09 =09 21) need to send "common name" as found in the WTP CERT so that the AC can verify =09 The protocol currently relies on the MAC address being the key that binds the certificate to the WTP. I don't see a need to change this. =09 =09 22) Result code in Join Response is not sufficient, for instance WTP HW=20 not supported. =09 Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today). =09 =09 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20 =09 Agreed. =09 =09 24) Change Echo to Keepalive or heartbeat. =09 I call it potato.... =09 =09 25) What if all of the message elements do not fit within a single CAPWAP control frame.=20 =09 We should address this. =09 =09 26) AC Name with Index is all messed up... =09 Not really. You simply include more than one, and the index field is clearly the priority. Don't understand the Multi-AC comment. No=20 inter-AC protocol implied here. =09 =09 27) WTP Board Data belongs in the Join, not configure. =09 Agreed, but wonder even more why we are duplicating this information across both the WTP Descriptor and the WTP Board Data=20 message elements. =09 =09 28) The WTP Static IPv4 Address should not have the Static bit, but instead state that 0.0.0.0 means a static address is not to be used. =09 I don't have an issue with this request, but in the end we have=20 the same function. The reason why I state this is that we can refine this protocol until the cows come home, and at one point we need to draw=20 a line in the sand. =09 =09 29) WTP Reboot Statistics belongs in the Join, and the reasons listed=20 are not clear enough. =09 Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can=20 clarify some of the reasons, as long as it provides value.=20 =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID field should be an array. =09 Disagree. =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's Country Code is not clear enough. =09 The text points to the actual MIB element in the 802.11-1999 standard, which very clearly defines the contents of the field. I don't=20 think there's value in replicating the format of this field in the=20 CAPWAP standard. =09 =09 31) There seems like an awful lot of additional configuration message elements that need to be specified here! =09 Having built a protocol based on this, it's not clear to me what's=20 missing. I think it would be useful if you provided concrete details on what's missing. =09 =09 32) Configuration Status is just plain broken because any configuration=20 change operation may fail and there is no response to the=20 configuration changes specified in this command. =09 There certainly is - I guess I don't understand the concern. =09 =09 33) Use of Change State Event should instead be Radio Admin State.=20 =09 Perhaps the two are not described properly. The first is used by=20 the WTP to inform the AC that something has occurred with a radio. The second is used by the AC to enable/disable a radio. =09 =09 34) Report Timer needs to be in section 4.5 or 11 =09 ok =09 =09 35) Should Idle Timeout be per radio, or per WTP, and should the value be defined in section 4.5 or 11. =09 Per WTP, and yes. I believe it is fine as it is.=20 =09 =09 36) WTP Fallback isn't well defined, and should be removed.=20 =09 Disagree. I believe it is necessary to create enough resiliency in the protocol/service. =09 =09 37) How are the "Rate Set" and "Supported Rates" encoded.=20 =09 This was fixed in the -02=20 =09 =09 38) AC Timestamp doesn't belong in the configuration, but instead in the join. =09 Not sure this really matters.... =09 =09 39) Add MAC ACL Entry - this is so strange and is being managed like no=20 other configuration data. =09 I do not understand the comment =09 =09 40) Decryption Error Report Period is not defined in section 4.5 or 11 =09 ok, and note that the information has been moved to the IEEE=20 802.11 RSNA Error Report From Mobile =09 =09 41) Configuration Update Response. today, there are primarily two types of configuration models. The first is when config is changed, it is only changed in the volatile copy (the memory or running). An explicit=20 command is needed to save the config to nonvolatile storage. The second model has config both running (volatile) and saved (nonvolatile) config changed when a config change is made. And there might be a special command to have a config change apply to only one. In this case, there is no need for a "save config to nonvolatile" command. It is not clear what is suppose to be supported here in CAPWAP, and how does CAPWAP=20 support devices with no or very limited nonvolatile storage for config! =09 CAPWAP does not support WTPs with no nonvolatile storage. The protocol has the AC push configs to the WTP, which saves them at the=20 time they are received. I do not believe anything else is required. =09 =09 42) Configuration Update Response includes the Result Code message element, which includes values that do not appear to be relevant for=20 this message, and there are plenty of other failure cases =09 ok, but note that we are sharing a common message element. Any suggestions on how to address your issue? =09 =09 43) Change State Event Report. This seems a little silly to be sent in=20 the "configure" state. It seems only appropriate for the "run" state. Some might argue that even in the "run" state it shouldn't be sent after a "config update" request that changes the operational state. However,=20 in the "run" state, it may take a while to have the operational state change to follow the admin state. Thus, I think it is OK in the "run" state after config changes." =09 I believe this was addressed in -02.=20 =09 =09 44) Clear Config Request. this operation has several problems, which include: 1) currently, the CAPWAP-01 spec says that this can only be done in the "run" state. This is silly. It should also be possible in the=20 "configure" state. I wonder why the AC would even consider clearing the WTP's state before it even knows how it is configured. =09 2) the value of "manufacturing defaults" is not defined, and a poor=20 term to use, since it implies that that each manufacturer can have different values. If so, then the AC will have no knowledge of the config on the WTP! The problem of "default config values" has already be=20 mentioned above. After each config attribute has been defined with a default value, then the proper term would be "CAPWAP config defaults". Yes, you've raised this point already, and I agree that it does=20 need to be addressed. =09 3) This operation is not defined to have a response. This is broken, since any config change can fail. Also, it is not defined what happens next. Does this cause the WTP to reboot an start a "clean discovery"?=20 This was addressed in -02 =09 =09 45) Image Data Request. Yes, there are actually three different "Image Data Request" messages. Which one is determined by which of the three message elements is contained. This is completely silly! There=20 should be three separate operations! Additionally, how does the WTP know which image to get? The AC should be making that decision. =09 I believe the WTP is the only device that knows what it's filename=20 should be. Why would an AC vendor know about file naming conventions used by the WTP vendors? I believe your other issues are discussed in the next items. =09 =09 46) Image Data Response. this is silly. This operation can fail! There=20 needs to be message element that indicates the result. =09 How so? This is only used to send firmware to the WTP. Not clear what could fail... Reading the image from flash? =09 =09 47) Image Data Request. when starting over again at the WTP start state,=20 the WTP shouldn't use the "normal" discovery process, but instead "fast track" a connection back to the AC that just downloaded the image. With a little more work, we could probably figure out a way to reuse=20 the old DTLS session. =09 To what gain? What is so expensive about the discovery, and what happened if the AC was not longer reachable? =09 =09 48) opcode - if this is here, might as well also have a value that=20 indicates last block of the image file, instead of looking at the block size. =09 But we're just changing for the sake of changing - the protocol works as-is. =09 =09 49) since this operation does not have the block number as a parameter,=20 the WTP must determine the block number via the CAPWAP message header sequence number. NOTE: DTLS does not provide in-order delivery of packets. Also, this requires the WTP to remember state. This message element should be re-engineered to have the following subfields:=20 [edited] =09 The control header includes a sequence number, and while we can change the current protocol to match your recommendations, the protocol does work. If it ain't broken... =09 =09 50) Image Data Response. this is silly. This operation can fail! For=20 example, the WTP can run out of space to store the block, or there could be a failure in writing the block to storage. (Or as "Image Data Request"(9.1a) is presently specified, the checksum match could=20 fail.) There needs to be message element that indicates the result.) Note: don't need a block number field, since request and responses are paired. =09 We can include a result code =09 =09 51) Image Data Request. silly beyond belief=20 =09 Beauty is in the eye of the beholder ;-). Seriously, the protocol does work, so what exactly are you looking for? =09 =09 52) Image Data Response. This is silly. This operation can fail! There needs to be message element that indicates the result. =09 See above comment. =09 53) Reset Request. ... =09 The comment is irrelevant now that Clear Config has changed. =09 =09 54) Reset Response. this is silly. This operation can fail! There needs to be message element that indicates the result. =09 I sense a trend. I will stop including these messages from now on. =09 =09 55)Duplicate IPv4 Address. how often is this reported if the condition remains? =09 Only required once, I think, but we may want to include some text covering that. =09 =09 56) the list of events seems understated!=20 =09 Text and conditions please =09 =09 57) Data Transfer Request. Nice to have - remove. =09 Disagree. Providing diagnostics capabilities is required. =09 =09 58) Mobile Config Request. the actual details of how this works on both=20 splitMAC and especially localMAC are not well specified. That is, only the figures and text in sections 11.1.1 and 11.1.2 provide any clue as to events that would cause an AC to send this message type. Also, there=20 are restrictions on combinations of parameters that can be included in the message. =09 I wonder whether other folks agree that more details are required. =09 =09 59) it doesn't say if one message can be used to update more than one=20 STA. It should be able. =09 No, otherwise you end up with the problem of associating specific message elements with a given mobile. One mobile per request. =09 =09 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so=20 this message element can be matched with a (4.4.8)Add Mobile message element? =09 I believe this is to your previous point, but the protocol assumes one mobile per request. =09 =09 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If so, then why is this an 802.11 message element =09 Intended to be a way to push policies to the WTP to prioritize mobile traffic. =09 =09 62) IEEE 802.11 WLAN Config Request. why is a new message type that is 802.11 specific needed to modify 802.11 WLANs? It seems like the existing "(8.4)Configuration Update Request" message could be used. =09 To be more specific only.=20 =09 =09 63) note here there are information elements to create, delete, and modify WLANs. However, for message type "(10.1)Mobile Config Request", there is only add and delete (and the "add" used to modify).=20 =09 Correct. The protocol requires the AC to resend a new add with a different policy. No specific reason, but if this is deemed inconsistent, we could change it. =09 =09 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs=20 seems like it needs a little more work =09 What exactly would you like to see? =09 =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message-----=20 > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 22, 2006 4:31 PM=20 > To: capwap@frascone.com=20 > Subject: [Capwap] A commentary on CAPWAP-01 operations > > HI,=20 > > I've attached a long file that summarizes the operations in > CAPWAP-01. > > Enjoy, > /david t. perkins=20 > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBC9.DCF01A7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I feel=20 very strongly that the AC should not be maintainin significant state for = the WTP=20 during the discovery phase. So this message element must be included in = the=20 join, regardless of whether the discovery was made or = not.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 2:41 PM
To: Michael Montemurro
Cc:=20 capwap@frascone.com
Subject: [Capwap] Proposed Resolution to = Issue=20 163 "WTP Descriptorinformation is not required at Join time" /was Re:=20 Acommentary on CAPWAP-01 operations

All,
 
Issue 163 "WTP Descriptor information is not required at Join = time" =20 is listed below:

14) The WTP Descriptor information is not required at = Join=20 time.

<PRC> Well, as far as I can tell, I think there's = value in=20 knowing
whether the WTP can even be supported by the AC. So the = more info=20 is
provided by the WTP, the better the AC can determine whether it = should
just ignore the WTP or not. This could be done because it = knows that=20 the
firmware running on the WTP is not compatible, and it has no=20 new
firmware to download.
 
The proposed resolution to Issue 163 is:
 
Close with no change to the draft. The WTP descriptor element is=20 included
in the optional Discover Request message and the Join Request = to
indicate the WTP info to the AC. If the Discover Request is not = sent,=20 then
the Join Request is the first message in which the AC receives = this=20 information.
 
Comments welcome.
 
Thanks,
 
Dorothy
 
On 6/30/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat=20 Calhoun (pacalhou) <pcalhoun@cisco.com >=20 wrote:=20
Going=20 through David's lengthy document, he has raised an = interesting
number=20 of points that I believe require issues to be created. At one =
point=20 I'm paraphrasing Dave's comments in order to be brief, = and
introducing=20 my own numbering scheme.

1) Can message elements be in any = order?=20 (I believe they should be)

<PRC> Yes, and I suspect = we need=20 to include text to make it more
obvious.


2) Are all = specified message elements required? (The obvious answer = is
"yes", but=20 this document doesn't discuss versioning. For example, what
if = in a new=20 version of CAPWAP an additional message element was to be =
added. Would=20 a new message type be created and the additional = message
element added=20 to it, or the existing type reused?)

<PRC> This is a = great=20 question, and one that does need to be addressed
in the spec. = In the=20 Diameter protocol we dealt with this issue by
including a = "Mandatory=20 to implement" bit. If any AVP was received, whose
bit was set, = yet was=20 not recognized, then the request had to = be
rejected.

<PRC>=20 We could consider something similar here, but I believe with the=20
firmware download component of the protocol it may be less of = an issue=20 -
although not guaranteed. I would hope (and expect) that as = the=20 CAPWAP
protocol extends, the AC would push new firmware to the = WTP.=20 This does
require that the initial part of the state machine = be fairly=20 static, and
this could be an area where the "Mandatory to = implement"=20 bit could be
useful as it would allow the AC to fall back to = older=20 protocol behavior.

3) CAPWAP-01 doesn't do a good job of=20 indicating which message elements
can be = repeated.

<PRC>=20 Another good point. When we list the message elements, we = should
note=20 whether the frequently is 0-1 (meaning absent or once), 1 (only =
once)=20 or 0+ (meaning any number of them could be present.


4) = Can=20 "additional" message elements be added to a message? (I = believe
so for=20 reporting capabilities, statistics, and     = events.=20 For
configuration, there is nothing in the protocol that says = what=20 happens
when one end gets an = configuration    =20 element it doesn't know about.
Should it be ignored, and the = other=20 elements processed, or should the
complete=20 operation     failed?)

<PRC> The = "Mandatory to implement" bit above could address this issue.
If = an=20 unrecognized message element is found to have the bit set, = then
the=20 whole message needs to be rejected. If the bit is not set, the =
message=20 element may be safely ignored.


5) The config has a = concept of=20 "default value" for each configuration
attribute. However, the = default=20 values are not clearly specified. This
needs to be resolved to = be able=20 to support "default values".

<PRC> Another good = point raised=20 by David.


6) the documentation of which "binding = specific"=20 message elements are to
be included with CAPWAP messages is not = consistent, and is difficult to
follow.

<PRC> Has = this=20 been addressed in the latest (-02) document?


7) There = are some=20 message elements that cause "actions". This approach
to = protocol design=20 is problematic and should be eliminated.

<PRC> Could = you be=20 more specific as well as provide guidance on what you
would = like to=20 see?


8) The message types are inconsistently named, and = do not=20 follow the
conventions of well designed protocols. Can the = operations=20 be named
consistently with the following=20 terminology:
  1) request/response (used to = get/set/perform=20 action)
  2) report/ack (use to tell the other side=20 something)

<PRC> Could you provide your thoughts on = which=20 messages fall within
which one of your = categories?


9) Many=20 of the configuration items, and status items are not listed = in
one=20 section with definitions. (Well make it two sections - one = for
CAPWAP=20 and the other which is "binding" specific.) For example, not all =
of=20 the time period lengths are identified and specified in section=20 4.5.

<PRC> Unfortunately, the document has gone back = and=20 forth a few times
and before we opt to change the structure of = the=20 document, I'd like to
ensure that we have broad agreement on = what we=20 want - with the
understanding that we will never make everyone=20 happy.


10) each operation should have listed in which = states it=20 can be sent and
received

<PRC> I do not understand = your=20 comment.


11) All strings, such as WTP location, should = be=20 changed from US-ASCII
encoding to UTF-8 = encoding.

<PRC>=20 Agreed.

12) The term "mobile" is not really accurate when=20 describing wireless
interfaces, since wireless does not=20 imply      mobile. Can we just = use
the=20 techie term "STA" instead.

<PRC> I agree we should = use the=20 term Station, or STA for short.


13) The WTP Descriptor = message=20 element contains too much information,
lacks clarity on the = WTP=20 encryption field and includes version numbers,
which should be = in=20 string form.

<PRC> To the first point, I disagree. I = think=20 there is value in knowing
everything about the WTP. The AC = vendors can=20 expose whatever information
they want, but I don't believe = anything is=20 unnecessary.

<PRC> To the second point, this is one = of those=20 areas where the concept
of the technology binding creates = complexity.=20 Given that we cannot
simply discuss 802.11i at this point, the = only=20 thing we can do is punt
to another section in the technology = binding=20 section. That said, I agree
with Dave that the 802.11 binding = section=20 is too light in this area.
However, I would much prefer that = instead of=20 trying to address this
specific issue, we discuss whether we = should=20 even be supporting the mode
of operation where 802.11i is = performed in=20 the AC - especially with the
introduction of DTLS to secure the = data=20 plane. Right now, it just feels
like we have too many options = and I am=20 worried that interoperability
will be severely impacted (not to = mention=20 protocol complexity).

<PRC> To the last point, I have = no=20 issues with including text stating
that the version numbers = should be=20 in string form.


14) The WTP Descriptor information is = not=20 required at Join time.

<PRC> Well, as far as I can = tell, I=20 think there's value in knowing
whether the WTP can even be = supported by=20 the AC. So the more info is
provided by the WTP, the better = the AC can=20 determine whether it should
just ignore the WTP or not. This = could be=20 done because it knows that the
firmware running on the WTP is = not=20 compatible, and it has no new
firmware to = download.


15) Are=20 the values in the WTP Frame Encryption a capabilities bit, or=20 an
enum?

<PRC> Looks like an enum to me. Not sure = what=20 Dave would prefer the text
to read. There are various other = similar=20 comments throughout, which I
will not repeat = here.


16) The=20 Discovery Response is broken. The AC SHOULD NOT be providing = any
info=20 to a WTP (or something that claims to be a WTP). Also, the = AC
should=20 tell the WTP what to do next, with choices: 1) Ok to try to join, =
2)=20 don't try to join, 3)=20 = try           &nbs= p;        =20 discover on a list of
returned ACs)

<PRC> I don't = believe=20 there is an issue with sending the AC's
information to the WTP, = but=20 would solicit input from the list. That
said, some of the = information=20 in the AC Descriptor is required, such as
the current load on = the AC.=20 No point is trying to join if he AC
indicates it's already at = max=20 capacity.
<PRC> I believe if the AC does not return the = response,=20 then it implies
(2). Otherwise, it is (1). (3) is handled = during the=20 join or configure
process, which I believe is = right.


17) Is=20 AC Name text?

<PRC> Yes, and same with WTP=20 Name.


18) Primary Discovery are not required.=20

<PRC> Disagree. Required for = failover.


19) The=20 text does not make it clear that the contents of the = WTP
Location is=20 informative only, and as Dave calls it, a = "scratchpad".

<PRC>=20 Well, to be honest, I thought the example "next to the fridge" =
made it=20 clear that the information did not derive from any = scientific
formula.=20 The description also states this is a user-defined. I = believe
this=20 should be good enough.


20) Session is not=20 required

<PRC> I believe you may be correct that with = the=20 transition to DTLS,
this is no longer required.


21) = need to=20 send "common name" as found in the WTP CERT so that the AC
can=20 verify

<PRC> The protocol currently relies on the MAC = address=20 being the key
that binds the certificate to the WTP. I don't = see a need=20 to change
this.


22) Result code in Join Response is = not=20 sufficient, for instance WTP HW
not = supported.

<PRC>=20 Well, the protocol does not require this because the = Discovery
Response=20 would never be sent (as the protocol stands today).


23) = AC=20 IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20

<PRC> Agreed.


24) Change Echo to = Keepalive or=20 heartbeat.

<PRC> I call it potato....


25) = What if=20 all of the message elements do not fit within a single
CAPWAP = control=20 frame.

<PRC> We should address this.


26) = AC Name=20 with Index is all messed up...

<PRC> Not really. You = simply=20 include more than one, and the index field
is clearly the = priority.=20 Don't understand the Multi-AC comment. No
inter-AC protocol = implied=20 here.


27) WTP Board Data belongs in the Join, not=20 configure.

<PRC> Agreed, but wonder even more why we = are=20 duplicating this
information across both the WTP Descriptor and = the WTP=20 Board Data
message elements.


28) The WTP Static = IPv4=20 Address should not have the Static bit, but
instead state that = 0.0.0.0 means a = static address is=20 not to be used.

<PRC> I don't have an issue with this = request, but in the end we have
the same function. The reason = why I=20 state this is that we can refine
this protocol until the cows = come=20 home, and at one point we need to draw
a line in the=20 sand.


29) WTP Reboot Statistics belongs in the Join, = and the=20 reasons listed
are not clear enough.

<PRC> = Doesn't really=20 matter whether this is included in the
configuration or the = join, but=20 if the WG agrees to move it. We can
clarify some of the = reasons, as=20 long as it provides value.


30) The IEEE 802.11 WTP = Radio=20 Configuration message element's BSSID
field should be an=20 array.

<PRC> Disagree.


30) The IEEE 802.11 = WTP=20 Radio Configuration message element's Country
Code is not clear = enough.

<PRC> The text points to the actual MIB = element in=20 the 802.11-1999
standard, which very clearly defines the = contents of=20 the field. I don't
think there's value in replicating the = format of=20 this field in the
CAPWAP standard.


31) There seems = like an=20 awful lot of additional configuration message
elements that = need to be=20 specified here!

<PRC> Having built a protocol based = on this,=20 it's not clear to me what's
missing. I think it would be = useful if you=20 provided concrete details on
what's missing.


32)=20 Configuration Status is just plain broken because any = configuration=20
change operation may fail and there is=20 no           = response to=20 the
configuration changes specified in this=20 command.

<PRC> There certainly is - I guess I don't=20 understand the concern.


33) Use of Change State Event = should=20 instead be Radio Admin State.

<PRC> Perhaps the two = are not=20 described properly. The first is used by
the WTP to inform the = AC that=20 something has occurred with a radio. The
second is used by the = AC to=20 enable/disable a radio.


34) Report Timer needs to be in = section=20 4.5 or 11

<PRC> ok


35) Should Idle Timeout = be per=20 radio, or per WTP, and should the value
be defined in section = 4.5 or=20 11.

<PRC> Per WTP, and yes. I believe it is fine as = it is.=20


36) WTP Fallback isn't well defined, and should be = removed.=20

<PRC> Disagree. I believe it is necessary to create = enough=20 resiliency in
the protocol/service.


37) How are the = "Rate=20 Set" and "Supported Rates" encoded.

<PRC> This was = fixed in=20 the -02


38) AC Timestamp doesn't belong in the = configuration,=20 but instead in the
join.

<PRC> Not sure this = really=20 matters....


39) Add MAC ACL Entry - this is so strange = and is=20 being managed like no
other configuration = data.

<PRC> I=20 do not understand the comment


40) Decryption Error = Report=20 Period is not defined in section 4.5 or 11

<PRC> ok, = and note=20 that the information has been moved to the IEEE
802.11 RSNA = Error=20 Report From Mobile


41) Configuration Update Response. = today,=20 there are primarily two types
of configuration models. The = first is=20 when config is changed, it is only
changed in the volatile copy = (the=20 memory or running). An explicit
command is needed to save the = config=20 to nonvolatile storage. The second
model has config both = running=20 (volatile) and saved (nonvolatile) config
changed when a config = change=20 is made. And there might be a special
command to have a config = change=20 apply to only one. In this case, there
is no need for a "save = config to=20 nonvolatile" command. It is not clear
what is suppose to be = supported=20 here in CAPWAP, and how does CAPWAP
support devices with no or = very=20 limited nonvolatile storage for config!

<PRC> CAPWAP = does not=20 support WTPs with no nonvolatile storage. The
protocol has the = AC push=20 configs to the WTP, which saves them at the
time they are = received. I=20 do not believe anything else is required.


42) = Configuration=20 Update Response includes the Result Code message
element, which = includes values that do not appear to be relevant for
this = message,=20 and there are plenty of other failure cases

<PRC> ok, = but=20 note that we are sharing a common message element. = Any
suggestions on=20 how to address your issue?


43) Change State Event = Report. This=20 seems a little silly to be sent in
the "configure" state. It = seems=20 only appropriate for the "run" state.
Some might argue that = even in the=20 "run" state it shouldn't be sent after
a "config update" = request that=20 changes the operational state. However,
in the "run" state, it = may=20 take a while to have the operational state
change to follow the = admin=20 state. Thus, I think it is OK in the "run"
state after config=20 changes."

<PRC> I believe this was addressed in -02.=20


44) Clear Config Request. this operation has several = problems,=20 which
include:
   1) currently, the CAPWAP-01 spec = says=20 that this can only be done in
the "run" state. This is silly. = It should=20 also be possible in the
"configure" state.
<PRC> I = wonder why=20 the AC would even consider clearing the WTP's state
before it = even=20 knows how it is configured.

   2) the value of=20 "manufacturing defaults" is not defined, and a poor
term to = use, since=20 it implies that that each manufacturer can have
different = values. If=20 so, then the AC will have no knowledge of the
config on the = WTP! The=20 problem of "default config values" has already be
mentioned = above.=20 After each config attribute has been defined with a
default = value, then=20 the proper term would be "CAPWAP config defaults".
<PRC> = Yes,=20 you've raised this point already, and I agree that it does =
need to be=20 addressed.

   3) This operation is not defined to = have a=20 response. This is broken,
since any config change can fail. = Also, it is=20 not defined what happens
next. Does this cause the WTP to = reboot an=20 start a "clean discovery"?
<PRC> This was addressed in=20 -02


45) Image Data Request. Yes, there are actually = three=20 different "Image
Data Request" messages. Which one is=20 = determined          by = which of the
three message elements is contained. This is = completely=20 silly! There
should be three separate operations! = Additionally, how=20 does the WTP know
which image to get? The AC should be making = that=20 decision.

<PRC> I believe the WTP is the only device = that=20 knows what it's filename
should be. Why would an AC vendor = know about=20 file naming conventions
used by the WTP vendors? I believe your = other=20 issues are discussed in
the next items.


46) Image = Data=20 Response. this is silly. This operation can fail! There
needs = to be=20 message element that indicates=20 = the          result.
<PRC>=20 How so? This is only used to send firmware to the WTP. Not = clear
what=20 could fail... Reading the image from flash?


47) Image = Data=20 Request. when starting over again at the WTP start state,
the = WTP=20 shouldn't use the "normal" discovery process, but instead = "fast
track"=20 a connection back to the AC that just downloaded the image. = With
a=20 little=20 = more          work, we = could probably figure out a way to reuse
the old DTLS=20 session.

<PRC> To what gain? What is so expensive = about the=20 discovery, and what
happened if the AC was not longer=20 reachable?


48) opcode - if this is here, might as well = also=20 have a value that
indicates last block of the image file, = instead of=20 looking at the block
size.

<PRC> But we're just = changing=20 for the sake of changing - the protocol
works = as-is.


49)=20 since this operation does not have the block number as a = parameter,=20
the WTP must determine the block number via the CAPWAP message = header
sequence number.  NOTE: DTLS does not provide = in-order=20 delivery of
packets. Also, this requires the WTP to remember = state.=20 This message
element should be re-engineered to have the = following=20 subfields:
[edited]

<PRC> The control header = includes a=20 sequence number, and while we can
change the current protocol = to match=20 your recommendations, the protocol
does work. If it ain't=20 broken...


50) Image Data Response. this is silly. This=20 operation can fail!  For
example, the WTP can run = out of=20 space to=20 = store          the=20 block, or
there could be a failure in writing the block to = storage. (Or=20 as "Image
Data Request"(9.1a) is presently specified, the = checksum=20 match could
fail.) There needs to be message element that = indicates=20 the result.)
Note: don't need a block number field, since = request and=20 responses are
paired.

<PRC> We can include a = result=20 code


51) Image Data Request. silly beyond belief=20

<PRC> Beauty is in the eye of the beholder ;-). = Seriously,=20 the protocol
does work, so what exactly are you looking=20 for?


52) Image Data Response. This is silly. This = operation can=20 fail! There
needs to be message element that indicates=20 = the          result.
<PRC>=20 See above comment.

53) Reset Request. = ...

<PRC> The=20 comment is irrelevant now that Clear Config has = changed.


54)=20 Reset Response. this is silly. This operation can fail! There = needs
to=20 be message element that indicates=20 = the          result.
<PRC>=20 I sense a trend. I will stop including these messages from now=20 on.


55)Duplicate IPv4 Address. how often is this = reported if=20 the condition
remains?

<PRC> Only required once, I = think,=20 but we may want to include some text
covering = that.


56) the=20 list of events seems understated!

<PRC> Text and = conditions=20 please


57) Data Transfer Request. Nice to have -=20 remove.

<PRC> Disagree. Providing diagnostics = capabilities is=20 required.


58) Mobile Config Request. the actual details = of how=20 this works on both
splitMAC and especially localMAC are not = well=20 specified. That is, only
the figures and text in sections = 11.1.1 and=20 11.1.2 provide any clue as
to events that would cause an AC to = send=20 this message type. Also, there
are restrictions on = combinations of=20 parameters that can be included in
the = message.

<PRC> I=20 wonder whether other folks agree that more details are=20 required.


59) it doesn't say if one message can be used = to=20 update more than one
STA. It should be = able.

<PRC> No,=20 otherwise you end up with the problem of associating = specific
message=20 elements with a given mobile. One mobile per = request.


60) IEEE=20 802.11 Mobile. shouldn't the STA MAC address be included so =
this=20 message element can be matched with a (4.4.8)Add Mobile=20 message
element?

<PRC> I believe this is to your = previous=20 point, but the protocol assumes
one mobile per = request.


61)=20 IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC?=20 If
so, then why is this an 802.11 message = element

<PRC>=20 Intended to be a way to push policies to the WTP to = prioritize
mobile=20 traffic.


62) IEEE 802.11 WLAN Config Request. why is a = new=20 message type that is
802.11 specific needed to modify 802.11 = WLANs? It=20 seems like the
existing "(8.4)Configuration Update Request" = message=20 could be used.

<PRC> To be more specific only.=20


63) note here there are information elements to = create,=20 delete, and
modify WLANs. However, for message type = "(10.1)Mobile=20 Config Request",
there is only add and delete (and the "add" = used to=20 modify).

<PRC> Correct. The protocol requires the AC = to=20 resend a new add with a
different policy. No specific reason, = but if=20 this is deemed
inconsistent, we could change it.


64) = IEEE=20 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs =
seems=20 like it needs a little more work

<PRC> What exactly = would you=20 like to see?


Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems



> -----Original = Message-----=20
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: = Thursday, June 22,=20 2006 4:31 PM
> To: capwap@frascone.com=20
> Subject: [Capwap] A commentary on CAPWAP-01=20 operations
>
> HI,
>
> I've attached a = long file=20 that summarizes the operations in
> = CAPWAP-01.
>
>=20 Enjoy,
> /david t. perkins=20 =
>
_____________________________________________________________= ____=20
To unsubscribe or modify your subscription options, please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap


________________________________________= _________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBC9.DCF01A7B-- --===============1766738814== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1766738814==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:00:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzQl-0000qJ-Tc for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:00:47 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzQj-00045U-GZ for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:00:47 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id F17453980A4 for ; Mon, 9 Oct 2006 11:00:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id D6128430018 for ; Mon, 9 Oct 2006 10:39:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA5871448022 for ; Mon, 9 Oct 2006 10:39:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 3AFEB43117F for ; Mon, 9 Oct 2006 10:39:37 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:39:36 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329561944:sNHT251193248" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HdacA008931; Mon, 9 Oct 2006 10:39:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HdYOh002685; Mon, 9 Oct 2006 10:39:36 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:39:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:39:28 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E893C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 170 "Result code in JoinResponse is not sufficient" /was Re: A commentary onCAPWAP-01 operations Thread-Index: AcbkD+VnnTFPCi8rQj2kMlUlTHltKgHstuBA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:39:29.0016 (UTC) FILETIME=[DF130F80:01C6EBC9] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed Resolution to Issue 170 "Result code in JoinResponse is not sufficient" /was Re: A commentary onCAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0575259555==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 6c4a6fb8ad1fcd7af6c721e70b08a400 This is a multi-part message in MIME format. --===============0575259555== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBC9.DEF7DB1F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBC9.DEF7DB1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ok with me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 2:34 PM To: Michael Montemurro Cc: capwap@frascone.com Subject: [Capwap] Proposed Resolution to Issue 170 "Result code in JoinResponse is not sufficient" /was Re: A commentary onCAPWAP-01 operations =09 =09 All, =20 Issue 170 is listed below: =20 22) Result code in Join Response is not sufficient, for instance WTP HW not supported. =09 Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today).=20 =20 The proposed resolution to Issue 170 is: =20 If Discover Request/Response messages are sent, then the current Result codes are sufficient. But if the Discover Request/Response messages are not sent - they are indicated as optional in the text, then the commenter is correct. =20 Insert the following result code value at the end of 4.4.28: =20 8 Failure (Join Failure, WTP Hardware not supported) =20 =20 Comments welcome. =20 Thanks, =20 Dorothy =09 =20 On 6/30/06, Michael Montemurro wrote:=20 David, Pat, =20 I created issues 150-198 to deal with the points in David's email. Happy hunting! =20 Mike =09 =20 =09 On 6/27/06, Pat Calhoun (pacalhou) wrote:=20 Going through David's lengthy document, he has raised an interesting number of points that I believe require issues to be created. At one=20 point I'm paraphrasing Dave's comments in order to be brief, and introducing my own numbering scheme. =09 1) Can message elements be in any order? (I believe they should be) =09 Yes, and I suspect we need to include text to make it more=20 obvious. =09 =09 2) Are all specified message elements required? (The obvious answer is "yes", but this document doesn't discuss versioning. For example, what if in a new version of CAPWAP an additional message element was to be=20 added. Would a new message type be created and the additional message element added to it, or the existing type reused?) =09 This is a great question, and one that does need to be addressed in the spec. In the Diameter protocol we dealt with this issue by=20 including a "Mandatory to implement" bit. If any AVP was received, whose bit was set, yet was not recognized, then the request had to be rejected. =09 We could consider something similar here, but I believe with the=20 firmware download component of the protocol it may be less of an issue - although not guaranteed. I would hope (and expect) that as the CAPWAP protocol extends, the AC would push new firmware to the WTP. This does=20 require that the initial part of the state machine be fairly static, and this could be an area where the "Mandatory to implement" bit could be useful as it would allow the AC to fall back to older protocol behavior.=20 =09 3) CAPWAP-01 doesn't do a good job of indicating which message elements can be repeated. =09 Another good point. When we list the message elements, we should note whether the frequently is 0-1 (meaning absent or once), 1 (only=20 once) or 0+ (meaning any number of them could be present. =09 =09 4) Can "additional" message elements be added to a message? (I believe so for reporting capabilities, statistics, and events. For configuration, there is nothing in the protocol that says what happens when one end gets an configuration element it doesn't know about. Should it be ignored, and the other elements processed, or should the complete operation failed?)=20 =09 The "Mandatory to implement" bit above could address this issue. If an unrecognized message element is found to have the bit set, then the whole message needs to be rejected. If the bit is not set, the=20 message element may be safely ignored. =09 =09 5) The config has a concept of "default value" for each configuration attribute. However, the default values are not clearly specified. This needs to be resolved to be able to support "default values".=20 =09 Another good point raised by David. =09 =09 6) the documentation of which "binding specific" message elements are to be included with CAPWAP messages is not consistent, and is difficult to=20 follow. =09 Has this been addressed in the latest (-02) document? =09 =09 7) There are some message elements that cause "actions". This approach to protocol design is problematic and should be eliminated.=20 =09 Could you be more specific as well as provide guidance on what you would like to see? =09 =09 8) The message types are inconsistently named, and do not follow the conventions of well designed protocols. Can the operations be named=20 consistently with the following terminology: 1) request/response (used to get/set/perform action) 2) report/ack (use to tell the other side something) =09 Could you provide your thoughts on which messages fall within=20 which one of your categories? =09 =09 9) Many of the configuration items, and status items are not listed in one section with definitions. (Well make it two sections - one for CAPWAP and the other which is "binding" specific.) For example, not all=20 of the time period lengths are identified and specified in section 4.5. =09 Unfortunately, the document has gone back and forth a few times and before we opt to change the structure of the document, I'd like to=20 ensure that we have broad agreement on what we want - with the understanding that we will never make everyone happy. =09 =09 10) each operation should have listed in which states it can be sent and received =09 I do not understand your comment. =09 =09 11) All strings, such as WTP location, should be changed from US-ASCII encoding to UTF-8 encoding. =09 Agreed. =09 12) The term "mobile" is not really accurate when describing wireless=20 interfaces, since wireless does not imply mobile. Can we just use the techie term "STA" instead. =09 I agree we should use the term Station, or STA for short. =09 =09 13) The WTP Descriptor message element contains too much information,=20 lacks clarity on the WTP encryption field and includes version numbers, which should be in string form. =09 To the first point, I disagree. I think there is value in knowing everything about the WTP. The AC vendors can expose whatever information=20 they want, but I don't believe anything is unnecessary. =09 To the second point, this is one of those areas where the concept of the technology binding creates complexity. Given that we cannot simply discuss 802.11i at this point, the only thing we can do is punt to another section in the technology binding section. That said, I agree with Dave that the 802.11 binding section is too light in this area. However, I would much prefer that instead of trying to address this=20 specific issue, we discuss whether we should even be supporting the mode of operation where 802.11i is performed in the AC - especially with the introduction of DTLS to secure the data plane. Right now, it just feels=20 like we have too many options and I am worried that interoperability will be severely impacted (not to mention protocol complexity). =09 To the last point, I have no issues with including text stating=20 that the version numbers should be in string form. =09 =09 14) The WTP Descriptor information is not required at Join time. =09 Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is=20 provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download. =09 =09 15) Are the values in the WTP Frame Encryption a capabilities bit, or an enum? =09 Looks like an enum to me. Not sure what Dave would prefer the text to read. There are various other similar comments throughout, which I=20 will not repeat here. =09 =09 16) The Discovery Response is broken. The AC SHOULD NOT be providing any info to a WTP (or something that claims to be a WTP). Also, the AC should tell the WTP what to do next, with choices: 1) Ok to try to join,=20 2) don't try to join, 3) try discover on a list of returned ACs) =09 I don't believe there is an issue with sending the AC's information to the WTP, but would solicit input from the list. That=20 said, some of the information in the AC Descriptor is required, such as the current load on the AC. No point is trying to join if he AC indicates it's already at max capacity. I believe if the AC does not return the response, then it implies=20 (2). Otherwise, it is (1). (3) is handled during the join or configure process, which I believe is right. =09 =09 17) Is AC Name text? =09 Yes, and same with WTP Name. =09 =09 18) Primary Discovery are not required.=20 =09 Disagree. Required for failover. =09 =09 19) The text does not make it clear that the contents of the WTP Location is informative only, and as Dave calls it, a "scratchpad". =09 Well, to be honest, I thought the example "next to the fridge"=20 made it clear that the information did not derive from any scientific formula. The description also states this is a user-defined. I believe this should be good enough. =09 =09 20) Session is not required =09 I believe you may be correct that with the transition to DTLS, this is no longer required. =09 =09 21) need to send "common name" as found in the WTP CERT so that the AC can verify =09 The protocol currently relies on the MAC address being the key that binds the certificate to the WTP. I don't see a need to change this. =09 =09 22) Result code in Join Response is not sufficient, for instance WTP HW=20 not supported. =09 Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today). =09 =09 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20 =09 Agreed. =09 =09 24) Change Echo to Keepalive or heartbeat. =09 I call it potato.... =09 =09 25) What if all of the message elements do not fit within a single CAPWAP control frame.=20 =09 We should address this. =09 =09 26) AC Name with Index is all messed up... =09 Not really. You simply include more than one, and the index field is clearly the priority. Don't understand the Multi-AC comment. No=20 inter-AC protocol implied here. =09 =09 27) WTP Board Data belongs in the Join, not configure. =09 Agreed, but wonder even more why we are duplicating this information across both the WTP Descriptor and the WTP Board Data=20 message elements. =09 =09 28) The WTP Static IPv4 Address should not have the Static bit, but instead state that 0.0.0.0 means a static address is not to be used. =09 I don't have an issue with this request, but in the end we have=20 the same function. The reason why I state this is that we can refine this protocol until the cows come home, and at one point we need to draw=20 a line in the sand. =09 =09 29) WTP Reboot Statistics belongs in the Join, and the reasons listed=20 are not clear enough. =09 Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can=20 clarify some of the reasons, as long as it provides value.=20 =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID field should be an array. =09 Disagree. =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's Country Code is not clear enough. =09 The text points to the actual MIB element in the 802.11-1999 standard, which very clearly defines the contents of the field. I don't=20 think there's value in replicating the format of this field in the=20 CAPWAP standard. =09 =09 31) There seems like an awful lot of additional configuration message elements that need to be specified here! =09 Having built a protocol based on this, it's not clear to me what's=20 missing. I think it would be useful if you provided concrete details on what's missing. =09 =09 32) Configuration Status is just plain broken because any configuration=20 change operation may fail and there is no response to the=20 configuration changes specified in this command. =09 There certainly is - I guess I don't understand the concern. =09 =09 33) Use of Change State Event should instead be Radio Admin State.=20 =09 Perhaps the two are not described properly. The first is used by=20 the WTP to inform the AC that something has occurred with a radio. The second is used by the AC to enable/disable a radio. =09 =09 34) Report Timer needs to be in section 4.5 or 11 =09 ok =09 =09 35) Should Idle Timeout be per radio, or per WTP, and should the value be defined in section 4.5 or 11. =09 Per WTP, and yes. I believe it is fine as it is.=20 =09 =09 36) WTP Fallback isn't well defined, and should be removed.=20 =09 Disagree. I believe it is necessary to create enough resiliency in the protocol/service. =09 =09 37) How are the "Rate Set" and "Supported Rates" encoded.=20 =09 This was fixed in the -02=20 =09 =09 38) AC Timestamp doesn't belong in the configuration, but instead in the join. =09 Not sure this really matters.... =09 =09 39) Add MAC ACL Entry - this is so strange and is being managed like no=20 other configuration data. =09 I do not understand the comment =09 =09 40) Decryption Error Report Period is not defined in section 4.5 or 11 =09 ok, and note that the information has been moved to the IEEE=20 802.11 RSNA Error Report From Mobile =09 =09 41) Configuration Update Response. today, there are primarily two types of configuration models. The first is when config is changed, it is only changed in the volatile copy (the memory or running). An explicit=20 command is needed to save the config to nonvolatile storage. The second model has config both running (volatile) and saved (nonvolatile) config changed when a config change is made. And there might be a special command to have a config change apply to only one. In this case, there is no need for a "save config to nonvolatile" command. It is not clear what is suppose to be supported here in CAPWAP, and how does CAPWAP=20 support devices with no or very limited nonvolatile storage for config! =09 CAPWAP does not support WTPs with no nonvolatile storage. The protocol has the AC push configs to the WTP, which saves them at the=20 time they are received. I do not believe anything else is required. =09 =09 42) Configuration Update Response includes the Result Code message element, which includes values that do not appear to be relevant for=20 this message, and there are plenty of other failure cases =09 ok, but note that we are sharing a common message element. Any suggestions on how to address your issue? =09 =09 43) Change State Event Report. This seems a little silly to be sent in=20 the "configure" state. It seems only appropriate for the "run" state. Some might argue that even in the "run" state it shouldn't be sent after a "config update" request that changes the operational state. However,=20 in the "run" state, it may take a while to have the operational state change to follow the admin state. Thus, I think it is OK in the "run" state after config changes." =09 I believe this was addressed in -02.=20 =09 =09 44) Clear Config Request. this operation has several problems, which include: 1) currently, the CAPWAP-01 spec says that this can only be done in the "run" state. This is silly. It should also be possible in the=20 "configure" state. I wonder why the AC would even consider clearing the WTP's state before it even knows how it is configured. =09 2) the value of "manufacturing defaults" is not defined, and a poor=20 term to use, since it implies that that each manufacturer can have different values. If so, then the AC will have no knowledge of the config on the WTP! The problem of "default config values" has already be=20 mentioned above. After each config attribute has been defined with a default value, then the proper term would be "CAPWAP config defaults". Yes, you've raised this point already, and I agree that it does=20 need to be addressed. =09 3) This operation is not defined to have a response. This is broken, since any config change can fail. Also, it is not defined what happens next. Does this cause the WTP to reboot an start a "clean discovery"?=20 This was addressed in -02 =09 =09 45) Image Data Request. Yes, there are actually three different "Image Data Request" messages. Which one is determined by which of the three message elements is contained. This is completely silly! There=20 should be three separate operations! Additionally, how does the WTP know which image to get? The AC should be making that decision. =09 I believe the WTP is the only device that knows what it's filename=20 should be. Why would an AC vendor know about file naming conventions used by the WTP vendors? I believe your other issues are discussed in the next items. =09 =09 46) Image Data Response. this is silly. This operation can fail! There=20 needs to be message element that indicates the result. =09 How so? This is only used to send firmware to the WTP. Not clear what could fail... Reading the image from flash? =09 =09 47) Image Data Request. when starting over again at the WTP start state,=20 the WTP shouldn't use the "normal" discovery process, but instead "fast track" a connection back to the AC that just downloaded the image. With a little more work, we could probably figure out a way to reuse=20 the old DTLS session. =09 To what gain? What is so expensive about the discovery, and what happened if the AC was not longer reachable? =09 =09 48) opcode - if this is here, might as well also have a value that=20 indicates last block of the image file, instead of looking at the block size. =09 But we're just changing for the sake of changing - the protocol works as-is. =09 =09 49) since this operation does not have the block number as a parameter,=20 the WTP must determine the block number via the CAPWAP message header sequence number. NOTE: DTLS does not provide in-order delivery of packets. Also, this requires the WTP to remember state. This message element should be re-engineered to have the following subfields:=20 [edited] =09 The control header includes a sequence number, and while we can change the current protocol to match your recommendations, the protocol does work. If it ain't broken... =09 =09 50) Image Data Response. this is silly. This operation can fail! For=20 example, the WTP can run out of space to store the block, or there could be a failure in writing the block to storage. (Or as "Image Data Request"(9.1a) is presently specified, the checksum match could=20 fail.) There needs to be message element that indicates the result.) Note: don't need a block number field, since request and responses are paired. =09 We can include a result code =09 =09 51) Image Data Request. silly beyond belief=20 =09 Beauty is in the eye of the beholder ;-). Seriously, the protocol does work, so what exactly are you looking for? =09 =09 52) Image Data Response. This is silly. This operation can fail! There needs to be message element that indicates the result. =09 See above comment. =09 53) Reset Request. ... =09 The comment is irrelevant now that Clear Config has changed. =09 =09 54) Reset Response. this is silly. This operation can fail! There needs to be message element that indicates the result. =09 I sense a trend. I will stop including these messages from now on. =09 =09 55)Duplicate IPv4 Address. how often is this reported if the condition remains? =09 Only required once, I think, but we may want to include some text covering that. =09 =09 56) the list of events seems understated!=20 =09 Text and conditions please =09 =09 57) Data Transfer Request. Nice to have - remove. =09 Disagree. Providing diagnostics capabilities is required. =09 =09 58) Mobile Config Request. the actual details of how this works on both=20 splitMAC and especially localMAC are not well specified. That is, only the figures and text in sections 11.1.1 and 11.1.2 provide any clue as to events that would cause an AC to send this message type. Also, there=20 are restrictions on combinations of parameters that can be included in the message. =09 I wonder whether other folks agree that more details are required. =09 =09 59) it doesn't say if one message can be used to update more than one=20 STA. It should be able. =09 No, otherwise you end up with the problem of associating specific message elements with a given mobile. One mobile per request. =09 =09 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so=20 this message element can be matched with a (4.4.8)Add Mobile message element? =09 I believe this is to your previous point, but the protocol assumes one mobile per request. =09 =09 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If so, then why is this an 802.11 message element =09 Intended to be a way to push policies to the WTP to prioritize mobile traffic. =09 =09 62) IEEE 802.11 WLAN Config Request. why is a new message type that is 802.11 specific needed to modify 802.11 WLANs? It seems like the existing "(8.4)Configuration Update Request" message could be used. =09 To be more specific only.=20 =09 =09 63) note here there are information elements to create, delete, and modify WLANs. However, for message type "(10.1)Mobile Config Request", there is only add and delete (and the "add" used to modify).=20 =09 Correct. The protocol requires the AC to resend a new add with a different policy. No specific reason, but if this is deemed inconsistent, we could change it. =09 =09 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs=20 seems like it needs a little more work =09 What exactly would you like to see? =09 =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message-----=20 > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 22, 2006 4:31 PM=20 > To: capwap@frascone.com=20 > Subject: [Capwap] A commentary on CAPWAP-01 operations > > HI,=20 > > I've attached a long file that summarizes the operations in > CAPWAP-01. > > Enjoy, > /david t. perkins=20 > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBC9.DEF7DB1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ok=20 with me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 2:34 PM
To: Michael Montemurro
Cc:=20 capwap@frascone.com
Subject: [Capwap] Proposed Resolution to = Issue=20 170 "Result code in JoinResponse is not sufficient" /was Re: A = commentary=20 onCAPWAP-01 operations

All,
 
Issue 170 is listed below:
 
22) Result code in Join Response is not sufficient, for = instance WTP=20 HW
not supported.

<PRC> Well, the protocol does not = require=20 this because the Discovery
Response would never be sent (as the = protocol=20 stands today).
 
The proposed resolution to Issue 170 is:
 
If  Discover Request/Response messages are sent, then the=20 current
Result codes are sufficient. But if the Discover Request/Response = messages
are not sent - they are indicated as optional in the text, then = the=20 commenter
is correct.
 
Insert the following result code value at the end of = 4.4.28:
 
8  Failure (Join Failure, WTP Hardware not supported)
 
 
Comments welcome.
 
Thanks,
 
Dorothy

 
On 6/30/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat=20 Calhoun (pacalhou) <pcalhoun@cisco.com >=20 wrote:=20
Going=20 through David's lengthy document, he has raised an = interesting
number=20 of points that I believe require issues to be created. At one =
point=20 I'm paraphrasing Dave's comments in order to be brief, = and
introducing=20 my own numbering scheme.

1) Can message elements be in any = order?=20 (I believe they should be)

<PRC> Yes, and I suspect = we need=20 to include text to make it more
obvious.


2) Are all = specified message elements required? (The obvious answer = is
"yes", but=20 this document doesn't discuss versioning. For example, what
if = in a new=20 version of CAPWAP an additional message element was to be =
added. Would=20 a new message type be created and the additional = message
element added=20 to it, or the existing type reused?)

<PRC> This is a = great=20 question, and one that does need to be addressed
in the spec. = In the=20 Diameter protocol we dealt with this issue by
including a = "Mandatory=20 to implement" bit. If any AVP was received, whose
bit was set, = yet was=20 not recognized, then the request had to = be
rejected.

<PRC>=20 We could consider something similar here, but I believe with the=20
firmware download component of the protocol it may be less of = an issue=20 -
although not guaranteed. I would hope (and expect) that as = the=20 CAPWAP
protocol extends, the AC would push new firmware to the = WTP.=20 This does
require that the initial part of the state machine = be fairly=20 static, and
this could be an area where the "Mandatory to = implement"=20 bit could be
useful as it would allow the AC to fall back to = older=20 protocol behavior.

3) CAPWAP-01 doesn't do a good job of=20 indicating which message elements
can be = repeated.

<PRC>=20 Another good point. When we list the message elements, we = should
note=20 whether the frequently is 0-1 (meaning absent or once), 1 (only =
once)=20 or 0+ (meaning any number of them could be present.


4) = Can=20 "additional" message elements be added to a message? (I = believe
so for=20 reporting capabilities, statistics, and     = events.=20 For
configuration, there is nothing in the protocol that says = what=20 happens
when one end gets an = configuration    =20 element it doesn't know about.
Should it be ignored, and the = other=20 elements processed, or should the
complete=20 operation     failed?)

<PRC> The = "Mandatory to implement" bit above could address this issue.
If = an=20 unrecognized message element is found to have the bit set, = then
the=20 whole message needs to be rejected. If the bit is not set, the =
message=20 element may be safely ignored.


5) The config has a = concept of=20 "default value" for each configuration
attribute. However, the = default=20 values are not clearly specified. This
needs to be resolved to = be able=20 to support "default values".

<PRC> Another good = point raised=20 by David.


6) the documentation of which "binding = specific"=20 message elements are to
be included with CAPWAP messages is not = consistent, and is difficult to
follow.

<PRC> Has = this=20 been addressed in the latest (-02) document?


7) There = are some=20 message elements that cause "actions". This approach
to = protocol design=20 is problematic and should be eliminated.

<PRC> Could = you be=20 more specific as well as provide guidance on what you
would = like to=20 see?


8) The message types are inconsistently named, and = do not=20 follow the
conventions of well designed protocols. Can the = operations=20 be named
consistently with the following=20 terminology:
  1) request/response (used to = get/set/perform=20 action)
  2) report/ack (use to tell the other side=20 something)

<PRC> Could you provide your thoughts on = which=20 messages fall within
which one of your = categories?


9) Many=20 of the configuration items, and status items are not listed = in
one=20 section with definitions. (Well make it two sections - one = for
CAPWAP=20 and the other which is "binding" specific.) For example, not all =
of=20 the time period lengths are identified and specified in section=20 4.5.

<PRC> Unfortunately, the document has gone back = and=20 forth a few times
and before we opt to change the structure of = the=20 document, I'd like to
ensure that we have broad agreement on = what we=20 want - with the
understanding that we will never make everyone=20 happy.


10) each operation should have listed in which = states it=20 can be sent and
received

<PRC> I do not understand = your=20 comment.


11) All strings, such as WTP location, should = be=20 changed from US-ASCII
encoding to UTF-8 = encoding.

<PRC>=20 Agreed.

12) The term "mobile" is not really accurate when=20 describing wireless
interfaces, since wireless does not=20 imply      mobile. Can we just = use
the=20 techie term "STA" instead.

<PRC> I agree we should = use the=20 term Station, or STA for short.


13) The WTP Descriptor = message=20 element contains too much information,
lacks clarity on the = WTP=20 encryption field and includes version numbers,
which should be = in=20 string form.

<PRC> To the first point, I disagree. I = think=20 there is value in knowing
everything about the WTP. The AC = vendors can=20 expose whatever information
they want, but I don't believe = anything is=20 unnecessary.

<PRC> To the second point, this is one = of those=20 areas where the concept
of the technology binding creates = complexity.=20 Given that we cannot
simply discuss 802.11i at this point, the = only=20 thing we can do is punt
to another section in the technology = binding=20 section. That said, I agree
with Dave that the 802.11 binding = section=20 is too light in this area.
However, I would much prefer that = instead of=20 trying to address this
specific issue, we discuss whether we = should=20 even be supporting the mode
of operation where 802.11i is = performed in=20 the AC - especially with the
introduction of DTLS to secure the = data=20 plane. Right now, it just feels
like we have too many options = and I am=20 worried that interoperability
will be severely impacted (not to = mention=20 protocol complexity).

<PRC> To the last point, I have = no=20 issues with including text stating
that the version numbers = should be=20 in string form.


14) The WTP Descriptor information is = not=20 required at Join time.

<PRC> Well, as far as I can = tell, I=20 think there's value in knowing
whether the WTP can even be = supported by=20 the AC. So the more info is
provided by the WTP, the better = the AC can=20 determine whether it should
just ignore the WTP or not. This = could be=20 done because it knows that the
firmware running on the WTP is = not=20 compatible, and it has no new
firmware to = download.


15) Are=20 the values in the WTP Frame Encryption a capabilities bit, or=20 an
enum?

<PRC> Looks like an enum to me. Not sure = what=20 Dave would prefer the text
to read. There are various other = similar=20 comments throughout, which I
will not repeat = here.


16) The=20 Discovery Response is broken. The AC SHOULD NOT be providing = any
info=20 to a WTP (or something that claims to be a WTP). Also, the = AC
should=20 tell the WTP what to do next, with choices: 1) Ok to try to join, =
2)=20 don't try to join, 3)=20 = try           &nbs= p;        =20 discover on a list of
returned ACs)

<PRC> I don't = believe=20 there is an issue with sending the AC's
information to the WTP, = but=20 would solicit input from the list. That
said, some of the = information=20 in the AC Descriptor is required, such as
the current load on = the AC.=20 No point is trying to join if he AC
indicates it's already at = max=20 capacity.
<PRC> I believe if the AC does not return the = response,=20 then it implies
(2). Otherwise, it is (1). (3) is handled = during the=20 join or configure
process, which I believe is = right.


17) Is=20 AC Name text?

<PRC> Yes, and same with WTP=20 Name.


18) Primary Discovery are not required.=20

<PRC> Disagree. Required for = failover.


19) The=20 text does not make it clear that the contents of the = WTP
Location is=20 informative only, and as Dave calls it, a = "scratchpad".

<PRC>=20 Well, to be honest, I thought the example "next to the fridge" =
made it=20 clear that the information did not derive from any = scientific
formula.=20 The description also states this is a user-defined. I = believe
this=20 should be good enough.


20) Session is not=20 required

<PRC> I believe you may be correct that with = the=20 transition to DTLS,
this is no longer required.


21) = need to=20 send "common name" as found in the WTP CERT so that the AC
can=20 verify

<PRC> The protocol currently relies on the MAC = address=20 being the key
that binds the certificate to the WTP. I don't = see a need=20 to change
this.


22) Result code in Join Response is = not=20 sufficient, for instance WTP HW
not = supported.

<PRC>=20 Well, the protocol does not require this because the = Discovery
Response=20 would never be sent (as the protocol stands today).


23) = AC=20 IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20

<PRC> Agreed.


24) Change Echo to = Keepalive or=20 heartbeat.

<PRC> I call it potato....


25) = What if=20 all of the message elements do not fit within a single
CAPWAP = control=20 frame.

<PRC> We should address this.


26) = AC Name=20 with Index is all messed up...

<PRC> Not really. You = simply=20 include more than one, and the index field
is clearly the = priority.=20 Don't understand the Multi-AC comment. No
inter-AC protocol = implied=20 here.


27) WTP Board Data belongs in the Join, not=20 configure.

<PRC> Agreed, but wonder even more why we = are=20 duplicating this
information across both the WTP Descriptor and = the WTP=20 Board Data
message elements.


28) The WTP Static = IPv4=20 Address should not have the Static bit, but
instead state that = 0.0.0.0 means a = static address is=20 not to be used.

<PRC> I don't have an issue with this = request, but in the end we have
the same function. The reason = why I=20 state this is that we can refine
this protocol until the cows = come=20 home, and at one point we need to draw
a line in the=20 sand.


29) WTP Reboot Statistics belongs in the Join, = and the=20 reasons listed
are not clear enough.

<PRC> = Doesn't really=20 matter whether this is included in the
configuration or the = join, but=20 if the WG agrees to move it. We can
clarify some of the = reasons, as=20 long as it provides value.


30) The IEEE 802.11 WTP = Radio=20 Configuration message element's BSSID
field should be an=20 array.

<PRC> Disagree.


30) The IEEE 802.11 = WTP=20 Radio Configuration message element's Country
Code is not clear = enough.

<PRC> The text points to the actual MIB = element in=20 the 802.11-1999
standard, which very clearly defines the = contents of=20 the field. I don't
think there's value in replicating the = format of=20 this field in the
CAPWAP standard.


31) There seems = like an=20 awful lot of additional configuration message
elements that = need to be=20 specified here!

<PRC> Having built a protocol based = on this,=20 it's not clear to me what's
missing. I think it would be = useful if you=20 provided concrete details on
what's missing.


32)=20 Configuration Status is just plain broken because any = configuration=20
change operation may fail and there is=20 no           = response to=20 the
configuration changes specified in this=20 command.

<PRC> There certainly is - I guess I don't=20 understand the concern.


33) Use of Change State Event = should=20 instead be Radio Admin State.

<PRC> Perhaps the two = are not=20 described properly. The first is used by
the WTP to inform the = AC that=20 something has occurred with a radio. The
second is used by the = AC to=20 enable/disable a radio.


34) Report Timer needs to be in = section=20 4.5 or 11

<PRC> ok


35) Should Idle Timeout = be per=20 radio, or per WTP, and should the value
be defined in section = 4.5 or=20 11.

<PRC> Per WTP, and yes. I believe it is fine as = it is.=20


36) WTP Fallback isn't well defined, and should be = removed.=20

<PRC> Disagree. I believe it is necessary to create = enough=20 resiliency in
the protocol/service.


37) How are the = "Rate=20 Set" and "Supported Rates" encoded.

<PRC> This was = fixed in=20 the -02


38) AC Timestamp doesn't belong in the = configuration,=20 but instead in the
join.

<PRC> Not sure this = really=20 matters....


39) Add MAC ACL Entry - this is so strange = and is=20 being managed like no
other configuration = data.

<PRC> I=20 do not understand the comment


40) Decryption Error = Report=20 Period is not defined in section 4.5 or 11

<PRC> ok, = and note=20 that the information has been moved to the IEEE
802.11 RSNA = Error=20 Report From Mobile


41) Configuration Update Response. = today,=20 there are primarily two types
of configuration models. The = first is=20 when config is changed, it is only
changed in the volatile copy = (the=20 memory or running). An explicit
command is needed to save the = config=20 to nonvolatile storage. The second
model has config both = running=20 (volatile) and saved (nonvolatile) config
changed when a config = change=20 is made. And there might be a special
command to have a config = change=20 apply to only one. In this case, there
is no need for a "save = config to=20 nonvolatile" command. It is not clear
what is suppose to be = supported=20 here in CAPWAP, and how does CAPWAP
support devices with no or = very=20 limited nonvolatile storage for config!

<PRC> CAPWAP = does not=20 support WTPs with no nonvolatile storage. The
protocol has the = AC push=20 configs to the WTP, which saves them at the
time they are = received. I=20 do not believe anything else is required.


42) = Configuration=20 Update Response includes the Result Code message
element, which = includes values that do not appear to be relevant for
this = message,=20 and there are plenty of other failure cases

<PRC> ok, = but=20 note that we are sharing a common message element. = Any
suggestions on=20 how to address your issue?


43) Change State Event = Report. This=20 seems a little silly to be sent in
the "configure" state. It = seems=20 only appropriate for the "run" state.
Some might argue that = even in the=20 "run" state it shouldn't be sent after
a "config update" = request that=20 changes the operational state. However,
in the "run" state, it = may=20 take a while to have the operational state
change to follow the = admin=20 state. Thus, I think it is OK in the "run"
state after config=20 changes."

<PRC> I believe this was addressed in -02.=20


44) Clear Config Request. this operation has several = problems,=20 which
include:
   1) currently, the CAPWAP-01 spec = says=20 that this can only be done in
the "run" state. This is silly. = It should=20 also be possible in the
"configure" state.
<PRC> I = wonder why=20 the AC would even consider clearing the WTP's state
before it = even=20 knows how it is configured.

   2) the value of=20 "manufacturing defaults" is not defined, and a poor
term to = use, since=20 it implies that that each manufacturer can have
different = values. If=20 so, then the AC will have no knowledge of the
config on the = WTP! The=20 problem of "default config values" has already be
mentioned = above.=20 After each config attribute has been defined with a
default = value, then=20 the proper term would be "CAPWAP config defaults".
<PRC> = Yes,=20 you've raised this point already, and I agree that it does =
need to be=20 addressed.

   3) This operation is not defined to = have a=20 response. This is broken,
since any config change can fail. = Also, it is=20 not defined what happens
next. Does this cause the WTP to = reboot an=20 start a "clean discovery"?
<PRC> This was addressed in=20 -02


45) Image Data Request. Yes, there are actually = three=20 different "Image
Data Request" messages. Which one is=20 = determined          by = which of the
three message elements is contained. This is = completely=20 silly! There
should be three separate operations! = Additionally, how=20 does the WTP know
which image to get? The AC should be making = that=20 decision.

<PRC> I believe the WTP is the only device = that=20 knows what it's filename
should be. Why would an AC vendor = know about=20 file naming conventions
used by the WTP vendors? I believe your = other=20 issues are discussed in
the next items.


46) Image = Data=20 Response. this is silly. This operation can fail! There
needs = to be=20 message element that indicates=20 = the          result.
<PRC>=20 How so? This is only used to send firmware to the WTP. Not = clear
what=20 could fail... Reading the image from flash?


47) Image = Data=20 Request. when starting over again at the WTP start state,
the = WTP=20 shouldn't use the "normal" discovery process, but instead = "fast
track"=20 a connection back to the AC that just downloaded the image. = With
a=20 little=20 = more          work, we = could probably figure out a way to reuse
the old DTLS=20 session.

<PRC> To what gain? What is so expensive = about the=20 discovery, and what
happened if the AC was not longer=20 reachable?


48) opcode - if this is here, might as well = also=20 have a value that
indicates last block of the image file, = instead of=20 looking at the block
size.

<PRC> But we're just = changing=20 for the sake of changing - the protocol
works = as-is.


49)=20 since this operation does not have the block number as a = parameter,=20
the WTP must determine the block number via the CAPWAP message = header
sequence number.  NOTE: DTLS does not provide = in-order=20 delivery of
packets. Also, this requires the WTP to remember = state.=20 This message
element should be re-engineered to have the = following=20 subfields:
[edited]

<PRC> The control header = includes a=20 sequence number, and while we can
change the current protocol = to match=20 your recommendations, the protocol
does work. If it ain't=20 broken...


50) Image Data Response. this is silly. This=20 operation can fail!  For
example, the WTP can run = out of=20 space to=20 = store          the=20 block, or
there could be a failure in writing the block to = storage. (Or=20 as "Image
Data Request"(9.1a) is presently specified, the = checksum=20 match could
fail.) There needs to be message element that = indicates=20 the result.)
Note: don't need a block number field, since = request and=20 responses are
paired.

<PRC> We can include a = result=20 code


51) Image Data Request. silly beyond belief=20

<PRC> Beauty is in the eye of the beholder ;-). = Seriously,=20 the protocol
does work, so what exactly are you looking=20 for?


52) Image Data Response. This is silly. This = operation can=20 fail! There
needs to be message element that indicates=20 = the          result.
<PRC>=20 See above comment.

53) Reset Request. = ...

<PRC> The=20 comment is irrelevant now that Clear Config has = changed.


54)=20 Reset Response. this is silly. This operation can fail! There = needs
to=20 be message element that indicates=20 = the          result.
<PRC>=20 I sense a trend. I will stop including these messages from now=20 on.


55)Duplicate IPv4 Address. how often is this = reported if=20 the condition
remains?

<PRC> Only required once, I = think,=20 but we may want to include some text
covering = that.


56) the=20 list of events seems understated!

<PRC> Text and = conditions=20 please


57) Data Transfer Request. Nice to have -=20 remove.

<PRC> Disagree. Providing diagnostics = capabilities is=20 required.


58) Mobile Config Request. the actual details = of how=20 this works on both
splitMAC and especially localMAC are not = well=20 specified. That is, only
the figures and text in sections = 11.1.1 and=20 11.1.2 provide any clue as
to events that would cause an AC to = send=20 this message type. Also, there
are restrictions on = combinations of=20 parameters that can be included in
the = message.

<PRC> I=20 wonder whether other folks agree that more details are=20 required.


59) it doesn't say if one message can be used = to=20 update more than one
STA. It should be = able.

<PRC> No,=20 otherwise you end up with the problem of associating = specific
message=20 elements with a given mobile. One mobile per = request.


60) IEEE=20 802.11 Mobile. shouldn't the STA MAC address be included so =
this=20 message element can be matched with a (4.4.8)Add Mobile=20 message
element?

<PRC> I believe this is to your = previous=20 point, but the protocol assumes
one mobile per = request.


61)=20 IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC?=20 If
so, then why is this an 802.11 message = element

<PRC>=20 Intended to be a way to push policies to the WTP to = prioritize
mobile=20 traffic.


62) IEEE 802.11 WLAN Config Request. why is a = new=20 message type that is
802.11 specific needed to modify 802.11 = WLANs? It=20 seems like the
existing "(8.4)Configuration Update Request" = message=20 could be used.

<PRC> To be more specific only.=20


63) note here there are information elements to = create,=20 delete, and
modify WLANs. However, for message type = "(10.1)Mobile=20 Config Request",
there is only add and delete (and the "add" = used to=20 modify).

<PRC> Correct. The protocol requires the AC = to=20 resend a new add with a
different policy. No specific reason, = but if=20 this is deemed
inconsistent, we could change it.


64) = IEEE=20 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs =
seems=20 like it needs a little more work

<PRC> What exactly = would you=20 like to see?


Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems



> -----Original = Message-----=20
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: = Thursday, June 22,=20 2006 4:31 PM
> To: capwap@frascone.com=20
> Subject: [Capwap] A commentary on CAPWAP-01=20 operations
>
> HI,
>
> I've attached a = long file=20 that summarizes the operations in
> = CAPWAP-01.
>
>=20 Enjoy,
> /david t. perkins=20 =
>
_____________________________________________________________= ____=20
To unsubscribe or modify your subscription options, please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap


________________________________________= _________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBC9.DEF7DB1F-- --===============0575259555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0575259555==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzkU-0001XQ-9w for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:10 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzbI-0005jX-6v for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:11:41 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id B1AE339816D for ; Mon, 9 Oct 2006 11:11:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id BDE5A4300F8 for ; Mon, 9 Oct 2006 10:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A5AA43980E6 for ; Mon, 9 Oct 2006 10:42:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3EBE3980D2 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563307:sNHT2833854722" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgEbr010676; Mon, 9 Oct 2006 10:42:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg7P1004332; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:10 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8951@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] 802.11 Duplicate Removal in Split MAC Thread-Index: AcbhnnpJ1Jwn3/FhSrGG1rb2ro8HsAKIp43g From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , X-OriginalArrivalTime: 09 Oct 2006 17:42:11.0006 (UTC) FILETIME=[3FA0C5E0:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 52 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] 802.11 Duplicate Removal in Split MAC X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0702203331==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This is a multi-part message in MIME format. --===============0702203331== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3F7FF111" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3F7FF111 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Tuesday, September 26, 2006 12:04 PM To: capwap@frascone.com Subject: [Capwap] 802.11 Duplicate Removal in Split MAC =09 =09 In Split MAC (section 11.1.1), I assume that 802.11 Duplicate frame removal is always done by the WTP and a duplicate frame is never forwarded to the AC. Is this a correct assumption? =20 Thanks. =20 -Puneet ------_=_NextPart_001_01C6EBCA.3F7FF111 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Puneet Agarwal=20 [mailto:pagarwal@broadcom.com]
Sent: Tuesday, September 26, = 2006=20 12:04 PM
To: capwap@frascone.com
Subject: [Capwap] = 802.11=20 Duplicate Removal in Split MAC

In = Split MAC=20 (section 11.1.1),  I assume that 802.11 Duplicate frame removal = is always=20 done by the WTP and a duplicate frame is never forwarded to the AC. Is = this a=20 correct assumption?
 
Thanks.
 
-Puneet
------_=_NextPart_001_01C6EBCA.3F7FF111-- --===============0702203331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0702203331==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzkV-0001XQ-0G for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:11 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzb7-0005em-3K for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:11:30 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88E6B39811C for ; Mon, 9 Oct 2006 11:11:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id B78BD430018 for ; Mon, 9 Oct 2006 10:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 75DB83980D2 for ; Mon, 9 Oct 2006 10:42:16 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id C006E3980BF for ; Mon, 9 Oct 2006 10:42:08 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:08 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563244:sNHT240084774" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Hg8uE010591; Mon, 9 Oct 2006 10:42:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg7Ol004332; Mon, 9 Oct 2006 10:42:08 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:05 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8947@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to issue 194 - duplicate IPv4 address. Thread-Index: AcbfPnmteF7lIUS/RX2SvQV+LYGIHwMfQF1g From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:06.0193 (UTC) FILETIME=[3CC25E10:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to issue 194 - duplicate IPv4 address. X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2088516948==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f This is a multi-part message in MIME format. --===============2088516948== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3C95B107" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3C95B107 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text needs to be clearer than that, I believe. If you are planning on adding such language, we need to discuss when the WTP considers the event cleared. A WTP that determines a conflict would generate such an event, but it could be that the same event occurs, possible with another host on the network, days later. A single event being triggered the first time would not be sufficient. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 11:31 AM To: capwap Subject: [Capwap] Proposed resolution to issue 194 - duplicate IPv4 address. =09 =09 I propose that we add a sentence to sections 4.4.19 and 4.4.20 to indicated that the message is transmitted only once. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3C95B107 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 text needs to be clearer than that, I believe. If you are planning on = adding=20 such language, we need to discuss when the WTP considers the event = cleared. A=20 WTP that determines a conflict would generate such an event, but it = could be=20 that the same event occurs, possible with another host on the network, = days=20 later. A single event being triggered the first time would not be=20 sufficient.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 11:31 AM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to issue 194 - duplicate IPv4 address.

I propose that we add a sentence to sections 4.4.19 and 4.4.20 to = indicated that the message is transmitted only once.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3C95B107-- --===============2088516948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2088516948==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzka-0001gX-O5 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:16 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzZd-0005Pa-8D for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:09:58 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 89BD739815B for ; Mon, 9 Oct 2006 11:09:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 86B524300F2 for ; Mon, 9 Oct 2006 10:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 93BD73980DF for ; Mon, 9 Oct 2006 10:42:23 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C4723980BF for ; Mon, 9 Oct 2006 10:42:15 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:10 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563263:sNHT15816100304" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgASf010613; Mon, 9 Oct 2006 10:42:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg2Or004245; Mon, 9 Oct 2006 10:42:09 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to issue 127 - usage of the session IDfield Thread-Index: AcbfQvt5+QD2y4I+QDa945FxEurB+AMezRHA From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:08.0311 (UTC) FILETIME=[3E058C70:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to issue 127 - usage of the session IDfield X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1262575885==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 This is a multi-part message in MIME format. --===============1262575885== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3DD78E7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3DD78E7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree with this change, and would ask that the editor explain the rationale/need for the Session ID in the CAPWAP header when it is part of the DTLS payload. This will be encrypted, and I therefore fail to understand what its purpose is. The DTLS session itself should be sufficient, no? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 12:03 PM To: capwap Subject: [Capwap] Proposed resolution to issue 127 - usage of the session IDfield =09 =09 I propose we adopt David's proposed resolution and add session ID back into the header as described in tracker. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3DD78E7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 disagree with this change, and would ask that the editor explain the=20 rationale/need for the Session ID in the CAPWAP header when it is part = of the=20 DTLS payload. This will be encrypted, and I therefore fail to understand = what=20 its purpose is. The DTLS session itself should be sufficient,=20 no?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 12:03 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to issue 127 - usage of the session = IDfield

I propose we adopt David's proposed resolution and add session ID = back=20 into the header as described in tracker.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3DD78E7D-- --===============1262575885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1262575885==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzkd-0001io-JK for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzYH-0005Dg-QP for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:08:35 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id A2844398124 for ; Mon, 9 Oct 2006 11:08:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id ADADE4300F2 for ; Mon, 9 Oct 2006 10:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 77B801448023 for ; Mon, 9 Oct 2006 10:39:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 27B641448005 for ; Mon, 9 Oct 2006 10:39:41 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:39:41 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208"; a="329561986:sNHT66618424" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Hdfuu020419; Mon, 9 Oct 2006 10:39:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99HdNOb002528; Mon, 9 Oct 2006 10:39:33 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:39:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:39:26 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E893A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbppxXG8vlRVt+XTGCZp/uvRyEy0wBuaiJgAAQFBzAAFKYqQA== From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Cheng Hong" , "Scott G. Kelly" , "Margaret Wasserman" X-OriginalArrivalTime: 09 Oct 2006 17:39:26.0897 (UTC) FILETIME=[DDCFBA10:01C6EBC9] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c This would require the AC to send additional keying information to the WTP, since message three needs to be authenticated. So I disagree with this proposal. The change is much more sinificant than simply leaving the field zero. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Monday, October 09, 2006 12:08 AM > To: Cheng Hong; Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Cheng Hong, Scott, > > I share your concerns for setting the KeyRSC to 0. > > In my opinion, it is clear that the protocol is "broken" in > this case and needs to be fixed. > > My suggestion is to have the KeyRSC field be updated by the > WTP. So the AC could send Message-3 of the 4-way handshake to > the WTP with an empty KeyRSC field. The WTP could then > correctly update the field, compute the KeyMIC, update > Message-3 and then forward it to the STA. > > Of course, this requires a CAPWAP message from the AC and WTP > to exchange the incomplete Message-3. I think this is an > acceptable addition because it maintains the integrity of > 802.11i exchanges and provides a complete fix to the problem. > > Saravanan > > > > > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Monday, October 09, 2006 1:21 PM > To: Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Scott, > > Some comments below: > > > After thinking long and hard about this, I can't bring > myself to agree > > with the suggested text. Quite frankly, I think always using an RSC > > value of 0 is a lazy hack, and given that we've acknowledged we are > > introducing a vulnerability here (however slight), telling > > implementors they SHOULD do this just doesn't sit right with me. > > > > An enlightened implementation could almost certainly do better than > > always setting this to zero, and explicitly recommending > that people > > nail this window open just rubs me the wrong way. At least, > let's hold > > off on this decision until we've clearly defined what statistics we > > expect to be available. Seems like if we're going to tell > implementors > > what they SHOULD do, we SHOULD give them sound, well considered > > advice. > > I absolutely agree with you on this point. > > What I was trying to state in my previous emails was: > - I would against setting a static value for the KeyRSC as a > solution to this issue. > - However if the WG decided to go for a static value, the > draft should clearly point out that NOT all static value > could work (value other than zero may be a problem for > interoperability). > - And the draft needs to clearly point out what is the danger > of setting a static KeyRSC value in the security > consideration section. > - Also, the draft should not prohibit other implementation > for sync the KeyRSC value between WTP and AC (the CAPWAP > standard should not dictate such implementation incompatible). > > If there is a alternative solution than setting a static > KeyRSC value to narrow the window, I would vote for it. > > cheers > > Cheng Hong > > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Saturday, October 07, 2006 8:26 AM > > To: Margaret Wasserman > > Cc: capwap > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Margaret, > > > > Comments inline below... > > > > -----Original Message----- > > >From: Margaret Wasserman > > >Sent: Oct 6, 2006 9:39 AM > > >To: Scott G Kelly > > >Cc: Cheng Hong , capwap > > > > > >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > >While I am not against leaving things open to more optimal > > >implementations, I do think that we need to add some text to the > > >protocol portion of the document (as well as the security > > >considerations) to explain how this is handled. How about > something > > >like: > > > > > >The AC SHOULD use an RSC of 0 when computing message-3 of > the 4-way > > >802.11i handshake, unless the AC has knowledge of a more > optimal RSC > > >value to use. Mechanisms for determining a more optimal RSC > > value are > > >outside the scope of this specification. > > > > > >I do not think that we should simply say nothing and hope that > > >implementors figure this out. > > > > > >Margaret > > > > After thinking long and hard about this, I can't bring > myself to agree > > with the suggested text. Quite frankly, I think always using an RSC > > value of 0 is a lazy hack, and given that we've acknowledged we are > > introducing a vulnerability here (however slight), telling > > implementors they SHOULD do this just doesn't sit right with me. > > > > An enlightened implementation could almost certainly do better than > > always setting this to zero, and explicitly recommending > that people > > nail this window open just rubs me the wrong way. At least, > let's hold > > off on this decision until we've clearly defined what statistics we > > expect to be available. Seems like if we're going to tell > implementors > > what they SHOULD do, we SHOULD give them sound, well considered > > advice. > > > > Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzki-0001kZ-Ih for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:24 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzWI-0004uN-7d for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:06:32 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 74BD339811D for ; Mon, 9 Oct 2006 11:06:28 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 917B44300F5 for ; Mon, 9 Oct 2006 10:42:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 225553980E3 for ; Mon, 9 Oct 2006 10:42:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6C1DC398051 for ; Mon, 9 Oct 2006 10:42:16 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:12 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563276:sNHT9976799388" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgCvu022956; Mon, 9 Oct 2006 10:42:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgCbF026730; Mon, 9 Oct 2006 10:42:12 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:11 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8953@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution for Issue 204: More General wirelesssupport /was Re: suggestion for Issue # 204, "More general wireless support" Thread-Index: Acbn0CE1XNgyWyTaQSaM6zBgDZYc4AD8c4cg From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:12.0140 (UTC) FILETIME=[404DCEC0:01C6EBCA] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed Resolution for Issue 204: More General wirelesssupport /was Re: suggestion for Issue # 204, "More general wireless support" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1978639053==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a3a355dfae86436a50b25410b39c6c18 This is a multi-part message in MIME format. --===============1978639053== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.401FAE9F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.401FAE9F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Dorothy's recommendations. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, October 04, 2006 9:08 AM To: capwap Subject: [Capwap] Proposed Resolution for Issue 204: More General wirelesssupport /was Re: suggestion for Issue # 204,"More general wireless support" =09 =09 All, =09 Issue 204 and proposed resolutions to its components are=20 listed below. =09 Comments please. =09 Thanks, =09 Dorothy =09 =09 ------------------------------------------------------------------------ ------------------------------------------------- =09 1) 4.4.38. WTP Radio Information =09 Comment: As the section should be work for any wireless implement, I suggest the=20 =09 following value =09 should be moved to 802.11 binding. The value should be defined by wireless=20 =09 technology binding. =09 1 - 802.11b: An IEEE 802.11b radio. =09 =09 2 - 802.11a: An IEEE 802.11a radio. =09 4 -=20 802.11g: An IEEE 802.11g radio. =09 8 - 802.11n: An IEEE 802.11n radio. =09 Proposed Resolution: Move the "need to know" the=20 802.11 technology specific radio types to the 802.11 binding, modifying the WTP Radio Information element as follows: =09 IEEE 802.11 Radio Information =09 The IEEE 802.11 radio information message element is used to communicate the =09 radio information for each IEEE 802.11 radio on the WTP. The Discovery Request message MUST include one such message element per radio in the WTP. The Radio- Type field is used by the AC to determine which=20 802.11 technology specific binding is to be used with the WTP. =09 The value contains two fields, as shown. =09 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | Radio Type | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Radio Type | +-+-+-+-+-+-+-+-+ =09 Type: 38 for WTP Radio Information =09 Length: 5 =09 Radio ID: The Radio Identifier, which typically refers to an interface index on the WTP =09 =09 Radio Type: The type of IEEE 802.11 radio present. =20 The following values are supported: =09 1 - 802.11b: An IEEE 802.11b radio. =09 2 - 802.11a: An IEEE 802.11a radio. =09 4 -=20 802.11g: An IEEE 802.11g radio. =09 8 - 802.11n: An IEEE 802.11n radio. =09 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types indicated are supported in the WTP. =20 =09 ------------------------------------------------------------------------ ------------------- =09 2) 11.9.18. IEEE 802.11 Tx Power =09 Comment: I think it could be moved to the section 4.4, as channel and Tx power are=20 common parameters for RF management. =09 Proposed Resolution: No change to the draft. Agree with the commenter =09 that TX power level is a common parameter for RF management; however the IEEE 802.11 TX Power field values are defined as being the values defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus are not =09 extensible to other bindings. Expect that each binding will define values relative to its definitions. =09 ------------------------------------------------------------------------ --- 3) Add "WTP radio channel" =09 =09 Comment: As per 2), we could define a TLV to report current channel (AP to AC) or to=20 =09 configure channel (AC to AP). =09 Now,. 11.9.12. IEEE 802.11 OFDM Control and 11.9.5. IEEE 802.11 Direct=20 =09 Sequence Control =09 has channel configuration information.=20 =09 =09 But I think that a specific TLV for it is better. By this way, 4.4 will provide =09 =09 more common parameter for any wireless technology. =09 0 1 2 3 =09 =09 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 | Radio ID | Reserved | Current Channel | =09 =09 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =09 =09 The commenter suggests the following: 3) Add "WTP RF Radio configuration" in the section 4.4=20 The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent=20 during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on.=20 For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5. =20 IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. Proposed Resolution: No change to the draft. While there may be common elements, it's not clear that the=20 CAPWAP base specification should take on the task of extracting/unifying the common elements across wireless systems.=20 =09 =09 =09 ------------------------------------------------------------------------ ------------ 4) 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indications =09 Comment: I think it could be moved to the section 4.4, it could be a common event for=20 =09 any wireless technology. =09 Proposed Resolution: No change to the draft. Agree with the commmenter that a fail alarm indication could be a common event for any wireless technology. Each radio technology may want to =09 have additional information reported with the event however. Not sure there is sufficient benefit shown for a common defintiion at this point. =09 ------------------------------------------------------------------------ --------------- =09 5) 11.9.1. IEEE 802.11 Add WLAN =09 How about we rename "WLAN" as wireless service? By this way, we could achieve=20 =09 abstract while make it work =09 for most wireless technology. =09 =09 If it is ok, we could define "add wireless service, delete wireless service,=20 update wireless service" in the section=20 4.4. =09 Any wireless technology could add its specific parameter in the binding=20 =09 section. =09 =09 The commenter suggests a solution: =09 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep=20 Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here).=20 While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using ( Probably eventually managed by IANA) =09 Proposed resolution: Close, no change to the draft. The IEEE 802.11 Add WLAN message element is 802.11 specific and used together with several other message elements to define a WLAN service. =09 The intent of the comment seems to be to have the ability in the CAPWAP protocol to add a generic wireless service. It's not clear that there are enough additional elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. =09 =09 =09 =09 ------------------------------------------------------------------------ -------- 6) 11.9.22. IEEE 802.11 WTP Quality of Service =09 As per 5), I think we could define "WTP Quality of Service"in the section=20 4.4. =09 Radio ID, Tag Packets and Queue Depth could be defined in the "WTP Quality of=20 =09 Service". =09 While CWMin and so on could be defined in the IEEE 802.11 WTP Quality of=20 =09 Service. =09 The commenter suggests the following solution: =09 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. Proposed resolution: Close, no change to the draft. The IEEE 802.11 WTP QOS message element is 802.11 specific and is needed to convey the CWMin , CWMax and other very specific 802.11 data. =09 The intent of the comment seems to be to have the ability in the CAPWAP protocol to include a "generic QOS" message element. It's not clear that there are enough elements common to multiple wireless services to have a separate CAPWAP level element at this at this time. There is at least 1 - the Tag packets type, which each binding can inlcude if desired. =09 =09 ------------------------------------------------------------------------ ---------------------------------------------------------- =09 7. Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4=20 Comment: Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics"=20 could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. =09 Proposed resolution: No change to the draft. Agree with the commenter that many of the statistics are common across wireless technologies. However the IEEE 802.11 Statistics values are defined as being the values defined in various IEEE 802.11 MIB variables and thus are not extensible to other bindings. Expect that each binding will define values relative to its definitions. =09 On 9/28/06, young wrote:=20 Hi Pat and all, I used to raise issue #204, and here intend to give solution. 1) Redefine 11.9.1 "IEEE 802.11 add WLAN" as "Add wireless service", and put it in the section 4.4 The glossary "wireless service" will be more abstract than "WLAN". Refer to current "IEEE 802.11 add WLAN" format, we could keep=20 Radio ID, service ID (rename "WLAN ID" to it), MAC Mode, tunnel mode these kinds common element (more element maybe put here).=20 While for any specific wireless binding could follow the Wireless binding identifier. The Wireless binding identifier will identify what kinds binding are using ( Probably eventually managed by IANA) =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Radio ID | WLAN ID | MAC Mode | Tunnel Mode +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wireless binding identifier | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length | =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Value... =09 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 It is similar for "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update WLAN". =20 2) Rename "11.9.22. IEEE 802.11 WTP Quality of Service" as "WTP Quality of Service" Same idea, we could keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of Service". For any binding, we use Wireless binding identifier to suggest them. For Tag Packets, if IANA already have some kind assignment, it will be great. =20 3) Add "WTP RF Radio configuration" in the section 4.4=20 The Tx power, radio type, channel assignment and so on these kind parameter are common for any kind wireless binding. I suggest CAPWAP define it in the base protocol part. Although the protocol already has "WTP Radio Information", while Tx power these kind Info should not be sent=20 during discovery and join phase. So the separated "WTP RF Radio configuration" is better. If keep them in one, which element will be mandatory in what kind message should be suggested by protocol. The TLV of "WTP RF Radio configuration" will include radio ID, radio type, Tx power, Channel, country code and so on.=20 For any binding, we use Wireless binding identifier to suggest them. The "WTP RF Radio configuration" could be sent by bi-direction, by this way, AC could configure WTP's RF parameter and know current configuration on the WTP radio. If this way, current "11.9.18. IEEE 802.11 Tx Power", "11.9.12. IEEE 802.11 OFDM Control "and "11.9.5. =20 IEEE 802.11 Direct Sequence Control" and so on will merely keep the IEEE 802.11 related element. =20 4) Redefine "IEEE 802.11 Statistics" as "WTP Statistics" in the section 4.4=20 Most case, the wireless binding will be link layer protocol, I think most the element in the "IEEE 802.11 Statistics"=20 could be put on the section 4.4, except the element like "RTS Success Count" and so on. For any binding, we use Wireless binding identifier to suggest them. =20 Any way, I thought many TLV will change their location as new CAPWAP will be divided into two parts. =20 Cheers =20 Richard (Shiyang) =20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBCA.401FAE9F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Dorothy's recommendations.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, October = 04, 2006=20 9:08 AM
To: capwap
Subject: [Capwap] Proposed = Resolution=20 for Issue 204: More General wirelesssupport /was Re: suggestion for = Issue #=20 204,"More general wireless support"

All,

Issue 204 and proposed resolutions to its = components=20 are
listed below.

Comments=20 = please.

Thanks,

Dorothy

----------------------------= -------------------------------------------------------------------------= --------------------
1) 4.4.38.  WTP Radio =
Information

Comment: As the =
section should be work for any wireless implement, I suggest the =


following value

 should =
be moved to 802.11 binding. The value should be defined by wireless =


technology binding.

      1 - 802.11b:  An IEEE 802.11b =
radio.


     =
 2 - 802.11a:  An IEEE 802.11a radio.

      4 -=20
802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n =
radio.

Proposed Resolution: Move the "need to know" the=20
802.11 technology specific
radio types to the 802.11 binding, =
modifying the WTP Radio Information element
as follows:

IEEE =
802.11 Radio Information

   The IEEE 802.11 radio information =
message element is used to communicate the

   radio information for each IEEE 802.11 radio on the WTP.  The =
Discovery Request message MUST
   include one such message element =
per radio in the WTP.  The Radio-
   Type field is used by the AC to =
determine which=20
802.11 technology
   specific binding is to be used with the =
WTP.

   The value contains two fields, as shown.

      0   =
                1                   2                   3
      0 1 2 =
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    =
 |   Radio ID    |           Radio Type                          |
   =
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     | Radio Type    |
     +-+-+-+-+-+-+-+-+

   Type:  38 =
for WTP Radio Information

   Length:  5

   Radio ID:  The =
Radio Identifier, which typically refers to an
      interface index =
on the WTP


   Radio Type:  The type of IEEE 802.11 radio present.  
     =
 The following values are supported:

      1 - 802.11b:  An IEEE =
802.11b radio.

      2 - 802.11a:  An IEEE 802.11a radio.

 =
     4 -=20
802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE =
802.11n radio.

      0xOF - 802.11b, 802.11a, 802.11g and =
802.11n:  The 4 radio types
         indicated are supported in the =
WTP.
 
-------------------------------------------------------=
------------------------------------

2) 11.9.18.  IEEE 802.11 Tx Power

Comment: I think it could =
be moved to the section 4.4, as channel and Tx power are 
common =
parameters for RF management.

Proposed Resolution: No change to =
the draft. Agree with the commenter

that TX power level is a common parameter for RF management; however =
the
IEEE 802.11 TX Power field values are defined as being the =
values
defined in IEEE 802.11Dot11PhyTxPowerEntry MIB table, and thus =
are not

extensible to other bindings. Expect that each binding will =
define
values relative to its =
definitions.
---------------------------------------------------------=
------------------
3)  Add "WTP radio channel"


Comment: As per 2), we could define a TLV to report =
current channel (AP to AC) or to 

configure channel (AC to AP).

Now,. =
11.9.12.  IEEE 802.11 OFDM Control and 11.9.5.  IEEE 802.11 Direct =


Sequence Control

has channel configuration information. =



But =
I think that a specific TLV for it is better. By this way, 4.4 will =
provide


more common parameter for any wireless technology.

     0                   1                  =
 2                   3


        0 1 2 3 4 5 6 7 8 9 0 =
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
BR style=3D"FONT-STYLE: italic">
       |    Radio ID   |    Reserved   |    =
    Current Channel       |


       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<=
BR>

The commenter =
suggests the following:

3)      = Add "WTP RF Radio = configuration"=20 in the section 4.4

The Tx power, radio type, channel = assignment and so=20 on these kind parameter are common for any kind wireless=20 binding.

I suggest CAPWAP define it in the base = protocol=20 part.

Although the protocol already has "WTP = Radio=20 Information", while Tx power these kind Info should not be sent=20

during discovery and join = phase. So the=20 separated "WTP RF Radio configuration" is better.

If keep them in one, which = element will=20 be mandatory in what kind message should be suggested by=20 protocol.

The TLV of = "WTP RF Radio=20 configuration" will include radio ID, radio type, Tx power, Channel, = country=20 code and so on.

For any = binding, we use=20 Wireless binding identifier to suggest them.

The "WTP RF = Radio=20 configuration" could be sent by bi-direction, by this way, AC could = configure=20 WTP's RF parameter

and know = current=20 configuration on the WTP radio.

If this way, = current=20 "11.9.18.  IEEE 802.11 Tx Power", "11.9.12.  IEEE 802.11 = OFDM=20 Control "and "11.9.5. 

IEEE 802.11 = Direct Sequence=20 Control" and so on will merely keep the IEEE 802.11 related=20 element.

 Proposed=20 Resolution: No change to the draft.  While there may be common = elements,=20 it's not clear that the
CAPWAP base specification should take on = the task=20 of extracting/unifying the common elements
across wireless systems. = = 


------------------------------------------=
------------------------------------------
4) 11.9.24.  IEEE 802.11 =
WTP Radio Fail Alarm Indications

Comment: I think it could be =
moved to the section 4.4, it could be a common event for=20

any wireless technology.

 Proposed Resolution: No change to =
the draft. Agree with the commmenter
that a fail alarm indication =
could be a common event for
any wireless technology. Each radio =
technology may want to

have additional information reported with the event however. =
Not
sure there is sufficient benefit shown for a common defintiion at =
this =
point.
---------------------------------------------------------------=
------------------------

5) 11.9.1.  IEEE 802.11 Add WLAN

How =
about we rename "WLAN" as wireless service? By this way, we could =
achieve 

abstract while make it work

for most wireless technology.


If =
it is ok, we could define "add wireless service, delete wireless =
service, 
update wireless service" in the section=20
4.4.

Any wireless technology could =
add its specific parameter in the binding 

section.


The commenter =
suggests a solution:

1)       = Redefine = 11.9.1 "IEEE=20 802.11 add WLAN" as "Add wireless service", and put it in the section=20 4.4

The = glossary=20 "wireless service" will be more abstract than = "WLAN".

Refer to = current=20 "IEEE 802.11 add WLAN" format, we could keep

Radio ID, = service ID=20 (rename "WLAN ID" to it), MAC Mode, tunnel mode

these = kinds common=20 element (more element maybe put here).

While for = any=20 specific wireless binding could follow the Wireless binding=20 identifier.

The = Wireless=20 binding identifier will identify what kinds binding are=20 using

( Probably = eventually=20 managed by IANA)

Proposed resolution: Close, no change to = the=20 draft.
The IEEE 802.11 Add WLAN message element is 802.11 specific = and=20 used
together with several other message elements to define a WLAN=20 service.

The intent of the comment seems to be to = have the=20 ability in the
CAPWAP protocol to add a generic wireless service. = It's not=20 clear that
there are enough additional elements common to multiple=20 wireless
services to have a separate CAPWAP level element at this = at this=20 = time.



---------------------------------=
-----------------------------------------------
6) 11.9.22.  IEEE =
802.11 WTP Quality of Service

As per 5), I think we could define "WTP =
Quality of Service"in the section=20
4.4.

Radio ID, Tag Packets and =
Queue Depth could be defined in the "WTP Quality of 

Service".

While CWMin and so on could be defined in =
the IEEE 802.11 WTP Quality of=20

Service.

The = commenter=20 suggests the following solution:

2) Rename = "11.9.22.  IEEE 802.11 WTP Quality of Service" as  "WTP = Quality of=20 Service"

Same = idea, we could=20 keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of=20 Service".

For any = binding, we=20 use Wireless binding identifier to suggest them.

For Tag = Packets, if=20 IANA already have some kind assignment, it will be = great.

Proposed resolution: Close, no change to = the=20 draft.
The IEEE 802.11 WTP QOS message element is 802.11 specific = and is=20 needed
to convey the CWMin , CWMax and other very specific 802.11 = data.=20

The intent of the comment seems to be to = have the=20 ability in the
CAPWAP protocol to include a "generic QOS" message = element.=20 It's not clear that
there are enough elements common to multiple=20 wireless
services to have a separate CAPWAP level element at this = at this=20 time.
There is at least 1 - the Tag packets type, which each = binding can=20 inlcude=20 = if
desired.

-------------------------------------= -------------------------------------------------------------------------= --------------------

7. = Redefine "IEEE=20 802.11 Statistics" as  "WTP Statistics" in the section 4.4 =

Comment: Most case, the wireless binding = will be=20 link layer protocol, I think most the element in the "IEEE 802.11 = Statistics"=20

could be put on the section 4.4, except = the element=20 like "RTS Success Count" and so on.

For any binding, we use Wireless binding = identifier=20 to suggest them.

Proposed resolution: No change to the = draft. Agree=20 with the commenter
that many of the statistics are common across = wireless=20 technologies.
However the IEEE 802.11 Statistics values are defined = as=20 being the values
defined in various IEEE 802.11 MIB variables and = thus are=20 not extensible to
other bindings. Expect that each binding will = define=20 values relative to its definitions.


On 9/28/06, young=20 <young@huawei-3com.com>=20 wrote:

Hi Pat = and=20 all,

I used = to raise=20 issue #204, and here = intend to give=20 solution.

1)      =20 Redefine 11.9.1 "IEEE 802.11 add WLAN" = as "Add=20 wireless service", and put it in the section 4.4

The = glossary=20 "wireless service" will be more abstract than = "WLAN".

Refer = to current=20 "IEEE 802.11 add WLAN" format, we could keep

Radio = ID, service=20 ID (rename "WLAN ID" to it), MAC Mode, tunnel mode

these = kinds common=20 element (more element maybe put here).

While = for any=20 specific wireless binding could follow the Wireless binding=20 identifier.

The = Wireless=20 binding identifier will identify what kinds binding are=20 using

( = Probably eventually=20 managed by IANA)

 

  =20      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1 2=20 3 4 5 6 7 8 9 0 1

      =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

      =20 |    Radio ID   |    WLAN=20 ID    |        MAC = Mode    | Tunnel = Mode      =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /FONT>

      =20 |  =20 =           Wireless binding=20 identifier=20 =             &= nbsp;=20        |

      =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

   =20    |        =20 = Type           &nb= sp;   =20 =   |          =   =20 Length          =20  |

    =20 =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+=20

    =20 =   |          =             &= nbsp;  =20 Value...

    =20 =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+=20

It is = similar for=20 "IEEE 802.11 deletes WLAN" and "IEEE 802.11 Update = WLAN".

 

2) = Rename=20 "11.9.22.  IEEE 802.11 WTP Quality of Service" as  "WTP = Quality of=20 Service"

Same = idea, we could=20 keep the radio ID, Tag Packets, Queue Depth in the "WTP Quality of=20 Service".

For any = binding, we=20 use Wireless binding identifier to suggest them.

For Tag = Packets, if=20 IANA already have some kind assignment, it will be = great.

 

3)     =20 Add "WTP RF Radio=20 configuration" in the section 4.4

The Tx power, radio type, channel = assignment and=20 so on these kind parameter are common for any kind wireless=20 binding.

I suggest CAPWAP define it in the base = protocol=20 part.

Although the protocol already has "WTP = Radio=20 Information", while Tx power these kind Info should not be sent=20

during discovery and join = phase. So the=20 separated "WTP RF Radio configuration" is better.

If keep them in one, which = element will=20 be mandatory in what kind message should be suggested by=20 protocol.

The TLV of = "WTP RF Radio=20 configuration" will include radio ID, radio type, Tx power, Channel, = country=20 code and so on.

For any = binding, we use=20 Wireless binding identifier to suggest them.

The "WTP RF = Radio=20 configuration" could be sent by bi-direction, by this way, AC could=20 configure WTP's RF parameter

and know = current=20 configuration on the WTP radio.

If this way, = current=20 "11.9.18.  IEEE 802.11 Tx Power", "11.9.12.  IEEE 802.11 = OFDM=20 Control "and "11.9.5. 

IEEE 802.11 = Direct=20 Sequence Control" and so on will merely keep the IEEE 802.11 related = element.

 

4)     =20 Redefine "IEEE 802.11 = Statistics" as  "WTP Statistics" in the section 4.4

Most case, the wireless binding will be = link layer=20 protocol, I think most the element in the "IEEE 802.11 Statistics"=20

could be put on the section 4.4, except = the=20 element like "RTS Success Count" and so on.

For any binding, we use Wireless binding = identifier to suggest them.

 

Any way, I thought many TLV will change = their=20 location as new CAPWAP will be divided into two = parts.

 

Cheers

 

Richard =  (Shiyang)

 


____________________= _____________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBCA.401FAE9F-- --===============1978639053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1978639053==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzkR-0001UX-VP for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:07 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzce-0005wn-Gx for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:13:08 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 66BB739818B for ; Mon, 9 Oct 2006 11:13:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E22784300F5 for ; Mon, 9 Oct 2006 10:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id BDFF93980BF for ; Mon, 9 Oct 2006 10:42:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88FC13980D3 for ; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:10 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857099062:sNHT81188204" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgAXG022049; Mon, 9 Oct 2006 10:42:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k99Hg2Ot004245; Mon, 9 Oct 2006 10:42:10 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:08 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E894D@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to Issue 188 Thread-Index: AcbfQ439c1ZSKpzgSeW/CjA+JwhwmQMe7B2w From: "Pat Calhoun (pacalhou)" To: "Michael Montemurro" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 17:42:09.0077 (UTC) FILETIME=[3E7A6E50:01C6EBCA] Authentication-Results: sj-dkim-8.cisco.com; header.DKIM-Signature=pcalhoun@cisco.com; dkim=fail ( 57 extraneous bytes; RSA-96 err: "Pat Calhoun \(pacalhou\)" ; cisco.com/sjdkim8002 fail; ); header.From=pcalhoun@cisco.com; dkim=neutral X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed resolution to Issue 188 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1599625040==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 This is a multi-part message in MIME format. --===============1599625040== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.3E4EC411" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.3E4EC411 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Saturday, September 23, 2006 12:07 PM To: capwap Subject: [Capwap] Proposed resolution to Issue 188 =09 =09 I do not see a problem with the Add MAC ACL Entry issue as defined. Unless there is proposed text to this issue, I recommend that we close it with no changes to the draft. =20 Cheers, =20 Mike ------_=_NextPart_001_01C6EBCA.3E4EC411 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Works=20 for me.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Saturday, = September 23,=20 2006 12:07 PM
To: capwap
Subject: [Capwap] = Proposed=20 resolution to Issue 188

I do not see a problem with the Add MAC ACL Entry issue as = defined.=20 Unless there is proposed text to this issue, I recommend that we close = it with=20 no changes to the draft.
 
Cheers,
 
Mike
------_=_NextPart_001_01C6EBCA.3E4EC411-- --===============1599625040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1599625040==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:21:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzlH-0002mE-JN for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzlF-0000Vp-Pm for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:21:59 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7DEC73980C2 for ; Mon, 9 Oct 2006 11:21:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id D2F8F4300F2 for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C5A82398090 for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 12B143980AE for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563316:sNHT2163869620" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgEIX010684; Mon, 9 Oct 2006 10:42:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgEbH026781; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:12 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8955@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Duplcate IPv6 Address message Element Thread-Index: AcbkC07u28THNQ6jSZ2La9VSUKU0tgHtt/2Q From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:42:12.0990 (UTC) FILETIME=[40CF81E0:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.4 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Duplcate IPv6 Address message Element X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645394477==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 This is a multi-part message in MIME format. --===============0645394477== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.409481D9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.409481D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What would the originator of this comment/issue propose the WTP do if it is using an IP address, and determines another device is also using it. Should it relinquish the address silently and not notify the AC? The question is not what should be done when all is well, but rather when an error occurs. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 2:02 PM To: Michael Montemurro Cc: capwap@frascone.com Subject: Re: [Capwap] Duplcate IPv6 Address message Element =09 =09 All, =20 Issue 147 is: =20 As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol=20 so no other host/WTP with same IPv6 address can join the network, therefore=20 section 4.4.20 for duplicate IPv6 address message element is NOT required in=20 CAPWAP and can be deleted ? =20 The proposed resolution to issue 147 is to delete the Duplicate IPv6 Address message element, 4.4.20. =20 Comments please. =20 Thanks, =20 Dorothy On 6/30/06, Michael Montemurro wrote:=20 Sachin, =20 I created issue 147 to track this. =20 Mike =09 =20 On 6/26/06, Sachin Dutta < sachind@huawei.com > wrote:=20 =09 Hi All, =20 As DAD ( Duplicate address detection ) is the integral part of IPv6 protocol so no other host/WTP with same IPv6 address can join the network, therefore section 4.4.20 for duplicate IPv6 address message element is NOT required in CAPWAP and can be deleted ? =20 Regards Sachin =20 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBCA.409481D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What=20 would the originator of this comment/issue propose the WTP do if it is = using an=20 IP address, and determines another device is also using it. Should it = relinquish=20 the address silently and not notify the AC? The question is not what = should be=20 done when all is well, but rather when an error = occurs.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 2:02 PM
To: Michael Montemurro
Cc:=20 capwap@frascone.com
Subject: Re: [Capwap] Duplcate IPv6 = Address=20 message Element

All,
 
Issue 147 is:
 
As DAD ( Duplicate address detection ) is the integral part = of IPv6=20 protocol
so no other host/WTP with same IPv6 address can join the = network,=20 therefore
section 4.4.20 for duplicate IPv6 address message = element is NOT=20 required in
CAPWAP and can be deleted ?
 
The proposed resolution to issue 147 is to
delete the Duplicate IPv6 Address message element, 4.4.20.
 
Comments please.
 
Thanks,
 
Dorothy


On 6/30/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
Sachin,
 
I created issue 147 = to track=20 this.
 
Mike

 
On=20 6/26/06, Sachin Dutta < = sachind@huawei.com>=20 wrote:

Hi=20 All,

 

As DAD=20 ( Duplicate address detection ) is the integral part of IPv6 = protocol so=20 no other host/WTP with same IPv6 address can join the network, = therefore=20 section 4.4.20 for = duplicate=20 IPv6 address message element is NOT required in CAPWAP and = can be=20 deleted ?

 

Regards

Sachin

 


________= _________________________________________________________
To=20 unsubscribe or modify your subscription options, please visit: =
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap



_________________________________________________= ________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBCA.409481D9-- --===============0645394477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0645394477==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:22:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzlm-0002oF-44 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:22:30 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzlj-0000cB-Lr for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:22:30 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 604033980C2 for ; Mon, 9 Oct 2006 11:22:25 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 56DAF430018 for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3EBC93980DD for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id BEF8F39803C for ; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="1857099095:sNHT1774416830" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgDrb010668; Mon, 9 Oct 2006 10:42:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgDbF026767; Mon, 9 Oct 2006 10:42:13 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 10:42:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:13 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8956@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations Thread-Index: AcbkDlsjzLQGeDgQQJyMj6DjL1v+aAHtBSyQ From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:42:13.0561 (UTC) FILETIME=[4126A290:01C6EBCA] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.957 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0024334113==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 41df209264c4de480abf9be5e33b69e9 This is a multi-part message in MIME format. --===============0024334113== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.40F3DFE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.40F3DFE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I personally prefer to start maintaining configuration and status state on the WTP after the join is complete. Is there a problem that arises with the current draft? Is this just a personal preference, or is there a bug? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Friday, September 29, 2006 2:22 PM To: Michael Montemurro Cc: capwap@frascone.com Subject: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations =09 =09 All, =20 Issue 177, "WTP Reboot Statistics belongs in the Join" is listed below: 29) WTP Reboot Statistics belongs in the Join, and the reasons listed are not clear enough. =09 Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can clarify some of the reasons, as long as it provides value. Believing that there may be times when it is desirable for the WTP to provide=20 information to the AC about its stability, the proposed resolution to Issue 177 is=20 to insert the following text at the end of Section 6.1 "Join Request": =20 The following message element may be included in the Join Request message: - WTP Reboot Statistics, see Section 4.4.44. =20 Comments please, =20 Thanks, =20 Dorothy =09 =20 On 6/30/06, Michael Montemurro wrote:=20 David, Pat, =20 I created issues 150-198 to deal with the points in David's email. Happy hunting! =20 Mike =09 =20 =09 On 6/27/06, Pat Calhoun (pacalhou) wrote:=20 Going through David's lengthy document, he has raised an interesting number of points that I believe require issues to be created. At one=20 point I'm paraphrasing Dave's comments in order to be brief, and introducing my own numbering scheme. =09 1) Can message elements be in any order? (I believe they should be) =09 Yes, and I suspect we need to include text to make it more=20 obvious. =09 =09 2) Are all specified message elements required? (The obvious answer is "yes", but this document doesn't discuss versioning. For example, what if in a new version of CAPWAP an additional message element was to be=20 added. Would a new message type be created and the additional message element added to it, or the existing type reused?) =09 This is a great question, and one that does need to be addressed in the spec. In the Diameter protocol we dealt with this issue by=20 including a "Mandatory to implement" bit. If any AVP was received, whose bit was set, yet was not recognized, then the request had to be rejected. =09 We could consider something similar here, but I believe with the=20 firmware download component of the protocol it may be less of an issue - although not guaranteed. I would hope (and expect) that as the CAPWAP protocol extends, the AC would push new firmware to the WTP. This does=20 require that the initial part of the state machine be fairly static, and this could be an area where the "Mandatory to implement" bit could be useful as it would allow the AC to fall back to older protocol behavior.=20 =09 3) CAPWAP-01 doesn't do a good job of indicating which message elements can be repeated. =09 Another good point. When we list the message elements, we should note whether the frequently is 0-1 (meaning absent or once), 1 (only=20 once) or 0+ (meaning any number of them could be present. =09 =09 4) Can "additional" message elements be added to a message? (I believe so for reporting capabilities, statistics, and events. For configuration, there is nothing in the protocol that says what happens when one end gets an configuration element it doesn't know about. Should it be ignored, and the other elements processed, or should the complete operation failed?)=20 =09 The "Mandatory to implement" bit above could address this issue. If an unrecognized message element is found to have the bit set, then the whole message needs to be rejected. If the bit is not set, the=20 message element may be safely ignored. =09 =09 5) The config has a concept of "default value" for each configuration attribute. However, the default values are not clearly specified. This needs to be resolved to be able to support "default values".=20 =09 Another good point raised by David. =09 =09 6) the documentation of which "binding specific" message elements are to be included with CAPWAP messages is not consistent, and is difficult to=20 follow. =09 Has this been addressed in the latest (-02) document? =09 =09 7) There are some message elements that cause "actions". This approach to protocol design is problematic and should be eliminated.=20 =09 Could you be more specific as well as provide guidance on what you would like to see? =09 =09 8) The message types are inconsistently named, and do not follow the conventions of well designed protocols. Can the operations be named=20 consistently with the following terminology: 1) request/response (used to get/set/perform action) 2) report/ack (use to tell the other side something) =09 Could you provide your thoughts on which messages fall within=20 which one of your categories? =09 =09 9) Many of the configuration items, and status items are not listed in one section with definitions. (Well make it two sections - one for CAPWAP and the other which is "binding" specific.) For example, not all=20 of the time period lengths are identified and specified in section 4.5. =09 Unfortunately, the document has gone back and forth a few times and before we opt to change the structure of the document, I'd like to=20 ensure that we have broad agreement on what we want - with the understanding that we will never make everyone happy. =09 =09 10) each operation should have listed in which states it can be sent and received =09 I do not understand your comment. =09 =09 11) All strings, such as WTP location, should be changed from US-ASCII encoding to UTF-8 encoding. =09 Agreed. =09 12) The term "mobile" is not really accurate when describing wireless=20 interfaces, since wireless does not imply mobile. Can we just use the techie term "STA" instead. =09 I agree we should use the term Station, or STA for short. =09 =09 13) The WTP Descriptor message element contains too much information,=20 lacks clarity on the WTP encryption field and includes version numbers, which should be in string form. =09 To the first point, I disagree. I think there is value in knowing everything about the WTP. The AC vendors can expose whatever information=20 they want, but I don't believe anything is unnecessary. =09 To the second point, this is one of those areas where the concept of the technology binding creates complexity. Given that we cannot simply discuss 802.11i at this point, the only thing we can do is punt to another section in the technology binding section. That said, I agree with Dave that the 802.11 binding section is too light in this area. However, I would much prefer that instead of trying to address this=20 specific issue, we discuss whether we should even be supporting the mode of operation where 802.11i is performed in the AC - especially with the introduction of DTLS to secure the data plane. Right now, it just feels=20 like we have too many options and I am worried that interoperability will be severely impacted (not to mention protocol complexity). =09 To the last point, I have no issues with including text stating=20 that the version numbers should be in string form. =09 =09 14) The WTP Descriptor information is not required at Join time. =09 Well, as far as I can tell, I think there's value in knowing whether the WTP can even be supported by the AC. So the more info is=20 provided by the WTP, the better the AC can determine whether it should just ignore the WTP or not. This could be done because it knows that the firmware running on the WTP is not compatible, and it has no new firmware to download. =09 =09 15) Are the values in the WTP Frame Encryption a capabilities bit, or an enum? =09 Looks like an enum to me. Not sure what Dave would prefer the text to read. There are various other similar comments throughout, which I=20 will not repeat here. =09 =09 16) The Discovery Response is broken. The AC SHOULD NOT be providing any info to a WTP (or something that claims to be a WTP). Also, the AC should tell the WTP what to do next, with choices: 1) Ok to try to join,=20 2) don't try to join, 3) try discover on a list of returned ACs) =09 I don't believe there is an issue with sending the AC's information to the WTP, but would solicit input from the list. That=20 said, some of the information in the AC Descriptor is required, such as the current load on the AC. No point is trying to join if he AC indicates it's already at max capacity. I believe if the AC does not return the response, then it implies=20 (2). Otherwise, it is (1). (3) is handled during the join or configure process, which I believe is right. =09 =09 17) Is AC Name text? =09 Yes, and same with WTP Name. =09 =09 18) Primary Discovery are not required.=20 =09 Disagree. Required for failover. =09 =09 19) The text does not make it clear that the contents of the WTP Location is informative only, and as Dave calls it, a "scratchpad". =09 Well, to be honest, I thought the example "next to the fridge"=20 made it clear that the information did not derive from any scientific formula. The description also states this is a user-defined. I believe this should be good enough. =09 =09 20) Session is not required =09 I believe you may be correct that with the transition to DTLS, this is no longer required. =09 =09 21) need to send "common name" as found in the WTP CERT so that the AC can verify =09 The protocol currently relies on the MAC address being the key that binds the certificate to the WTP. I don't see a need to change this. =09 =09 22) Result code in Join Response is not sufficient, for instance WTP HW=20 not supported. =09 Well, the protocol does not require this because the Discovery Response would never be sent (as the protocol stands today). =09 =09 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20 =09 Agreed. =09 =09 24) Change Echo to Keepalive or heartbeat. =09 I call it potato.... =09 =09 25) What if all of the message elements do not fit within a single CAPWAP control frame.=20 =09 We should address this. =09 =09 26) AC Name with Index is all messed up... =09 Not really. You simply include more than one, and the index field is clearly the priority. Don't understand the Multi-AC comment. No=20 inter-AC protocol implied here. =09 =09 27) WTP Board Data belongs in the Join, not configure. =09 Agreed, but wonder even more why we are duplicating this information across both the WTP Descriptor and the WTP Board Data=20 message elements. =09 =09 28) The WTP Static IPv4 Address should not have the Static bit, but instead state that 0.0.0.0 means a static address is not to be used. =09 I don't have an issue with this request, but in the end we have=20 the same function. The reason why I state this is that we can refine this protocol until the cows come home, and at one point we need to draw=20 a line in the sand. =09 =09 29) WTP Reboot Statistics belongs in the Join, and the reasons listed=20 are not clear enough. =09 Doesn't really matter whether this is included in the configuration or the join, but if the WG agrees to move it. We can=20 clarify some of the reasons, as long as it provides value.=20 =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID field should be an array. =09 Disagree. =09 =09 30) The IEEE 802.11 WTP Radio Configuration message element's Country Code is not clear enough. =09 The text points to the actual MIB element in the 802.11-1999 standard, which very clearly defines the contents of the field. I don't=20 think there's value in replicating the format of this field in the=20 CAPWAP standard. =09 =09 31) There seems like an awful lot of additional configuration message elements that need to be specified here! =09 Having built a protocol based on this, it's not clear to me what's=20 missing. I think it would be useful if you provided concrete details on what's missing. =09 =09 32) Configuration Status is just plain broken because any configuration=20 change operation may fail and there is no response to the=20 configuration changes specified in this command. =09 There certainly is - I guess I don't understand the concern. =09 =09 33) Use of Change State Event should instead be Radio Admin State.=20 =09 Perhaps the two are not described properly. The first is used by=20 the WTP to inform the AC that something has occurred with a radio. The second is used by the AC to enable/disable a radio. =09 =09 34) Report Timer needs to be in section 4.5 or 11 =09 ok =09 =09 35) Should Idle Timeout be per radio, or per WTP, and should the value be defined in section 4.5 or 11. =09 Per WTP, and yes. I believe it is fine as it is.=20 =09 =09 36) WTP Fallback isn't well defined, and should be removed.=20 =09 Disagree. I believe it is necessary to create enough resiliency in the protocol/service. =09 =09 37) How are the "Rate Set" and "Supported Rates" encoded.=20 =09 This was fixed in the -02=20 =09 =09 38) AC Timestamp doesn't belong in the configuration, but instead in the join. =09 Not sure this really matters.... =09 =09 39) Add MAC ACL Entry - this is so strange and is being managed like no=20 other configuration data. =09 I do not understand the comment =09 =09 40) Decryption Error Report Period is not defined in section 4.5 or 11 =09 ok, and note that the information has been moved to the IEEE=20 802.11 RSNA Error Report From Mobile =09 =09 41) Configuration Update Response. today, there are primarily two types of configuration models. The first is when config is changed, it is only changed in the volatile copy (the memory or running). An explicit=20 command is needed to save the config to nonvolatile storage. The second model has config both running (volatile) and saved (nonvolatile) config changed when a config change is made. And there might be a special command to have a config change apply to only one. In this case, there is no need for a "save config to nonvolatile" command. It is not clear what is suppose to be supported here in CAPWAP, and how does CAPWAP=20 support devices with no or very limited nonvolatile storage for config! =09 CAPWAP does not support WTPs with no nonvolatile storage. The protocol has the AC push configs to the WTP, which saves them at the=20 time they are received. I do not believe anything else is required. =09 =09 42) Configuration Update Response includes the Result Code message element, which includes values that do not appear to be relevant for=20 this message, and there are plenty of other failure cases =09 ok, but note that we are sharing a common message element. Any suggestions on how to address your issue? =09 =09 43) Change State Event Report. This seems a little silly to be sent in=20 the "configure" state. It seems only appropriate for the "run" state. Some might argue that even in the "run" state it shouldn't be sent after a "config update" request that changes the operational state. However,=20 in the "run" state, it may take a while to have the operational state change to follow the admin state. Thus, I think it is OK in the "run" state after config changes." =09 I believe this was addressed in -02.=20 =09 =09 44) Clear Config Request. this operation has several problems, which include: 1) currently, the CAPWAP-01 spec says that this can only be done in the "run" state. This is silly. It should also be possible in the=20 "configure" state. I wonder why the AC would even consider clearing the WTP's state before it even knows how it is configured. =09 2) the value of "manufacturing defaults" is not defined, and a poor=20 term to use, since it implies that that each manufacturer can have different values. If so, then the AC will have no knowledge of the config on the WTP! The problem of "default config values" has already be=20 mentioned above. After each config attribute has been defined with a default value, then the proper term would be "CAPWAP config defaults". Yes, you've raised this point already, and I agree that it does=20 need to be addressed. =09 3) This operation is not defined to have a response. This is broken, since any config change can fail. Also, it is not defined what happens next. Does this cause the WTP to reboot an start a "clean discovery"?=20 This was addressed in -02 =09 =09 45) Image Data Request. Yes, there are actually three different "Image Data Request" messages. Which one is determined by which of the three message elements is contained. This is completely silly! There=20 should be three separate operations! Additionally, how does the WTP know which image to get? The AC should be making that decision. =09 I believe the WTP is the only device that knows what it's filename=20 should be. Why would an AC vendor know about file naming conventions used by the WTP vendors? I believe your other issues are discussed in the next items. =09 =09 46) Image Data Response. this is silly. This operation can fail! There=20 needs to be message element that indicates the result. =09 How so? This is only used to send firmware to the WTP. Not clear what could fail... Reading the image from flash? =09 =09 47) Image Data Request. when starting over again at the WTP start state,=20 the WTP shouldn't use the "normal" discovery process, but instead "fast track" a connection back to the AC that just downloaded the image. With a little more work, we could probably figure out a way to reuse=20 the old DTLS session. =09 To what gain? What is so expensive about the discovery, and what happened if the AC was not longer reachable? =09 =09 48) opcode - if this is here, might as well also have a value that=20 indicates last block of the image file, instead of looking at the block size. =09 But we're just changing for the sake of changing - the protocol works as-is. =09 =09 49) since this operation does not have the block number as a parameter,=20 the WTP must determine the block number via the CAPWAP message header sequence number. NOTE: DTLS does not provide in-order delivery of packets. Also, this requires the WTP to remember state. This message element should be re-engineered to have the following subfields:=20 [edited] =09 The control header includes a sequence number, and while we can change the current protocol to match your recommendations, the protocol does work. If it ain't broken... =09 =09 50) Image Data Response. this is silly. This operation can fail! For=20 example, the WTP can run out of space to store the block, or there could be a failure in writing the block to storage. (Or as "Image Data Request"(9.1a) is presently specified, the checksum match could=20 fail.) There needs to be message element that indicates the result.) Note: don't need a block number field, since request and responses are paired. =09 We can include a result code =09 =09 51) Image Data Request. silly beyond belief=20 =09 Beauty is in the eye of the beholder ;-). Seriously, the protocol does work, so what exactly are you looking for? =09 =09 52) Image Data Response. This is silly. This operation can fail! There needs to be message element that indicates the result. =09 See above comment. =09 53) Reset Request. ... =09 The comment is irrelevant now that Clear Config has changed. =09 =09 54) Reset Response. this is silly. This operation can fail! There needs to be message element that indicates the result. =09 I sense a trend. I will stop including these messages from now on. =09 =09 55)Duplicate IPv4 Address. how often is this reported if the condition remains? =09 Only required once, I think, but we may want to include some text covering that. =09 =09 56) the list of events seems understated!=20 =09 Text and conditions please =09 =09 57) Data Transfer Request. Nice to have - remove. =09 Disagree. Providing diagnostics capabilities is required. =09 =09 58) Mobile Config Request. the actual details of how this works on both=20 splitMAC and especially localMAC are not well specified. That is, only the figures and text in sections 11.1.1 and 11.1.2 provide any clue as to events that would cause an AC to send this message type. Also, there=20 are restrictions on combinations of parameters that can be included in the message. =09 I wonder whether other folks agree that more details are required. =09 =09 59) it doesn't say if one message can be used to update more than one=20 STA. It should be able. =09 No, otherwise you end up with the problem of associating specific message elements with a given mobile. One mobile per request. =09 =09 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so=20 this message element can be matched with a (4.4.8)Add Mobile message element? =09 I believe this is to your previous point, but the protocol assumes one mobile per request. =09 =09 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If so, then why is this an 802.11 message element =09 Intended to be a way to push policies to the WTP to prioritize mobile traffic. =09 =09 62) IEEE 802.11 WLAN Config Request. why is a new message type that is 802.11 specific needed to modify 802.11 WLANs? It seems like the existing "(8.4)Configuration Update Request" message could be used. =09 To be more specific only.=20 =09 =09 63) note here there are information elements to create, delete, and modify WLANs. However, for message type "(10.1)Mobile Config Request", there is only add and delete (and the "add" used to modify).=20 =09 Correct. The protocol requires the AC to resend a new add with a different policy. No specific reason, but if this is deemed inconsistent, we could change it. =09 =09 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs=20 seems like it needs a little more work =09 What exactly would you like to see? =09 =09 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =09 =09 =09 > -----Original Message-----=20 > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, June 22, 2006 4:31 PM=20 > To: capwap@frascone.com=20 > Subject: [Capwap] A commentary on CAPWAP-01 operations > > HI,=20 > > I've attached a long file that summarizes the operations in > CAPWAP-01. > > Enjoy, > /david t. perkins=20 > =09 _________________________________________________________________=20 To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap=20 =09 Archives: http://lists.frascone.com/pipermail/capwap =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBCA.40F3DFE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 personally prefer to start maintaining configuration and status state on = the WTP=20 after the join is complete. Is there a problem that arises with the = current=20 draft? Is this just a personal preference, or is there a=20 bug?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, = 2006=20 2:22 PM
To: Michael Montemurro
Cc:=20 capwap@frascone.com
Subject: [Capwap] Proposed resolution to = Issue=20 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on = CAPWAP-01=20 operations

All,
 
Issue 177, "WTP Reboot Statistics belongs in the Join"
is listed below:
29) WTP Reboot Statistics belongs =
in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.
Believing that there may be times when it is desirable for the=20 WTP to provide
information to the AC about its stability, the proposed = resolution to=20 Issue 177 is
to insert the following text at the end of
Section 6.1 "Join Request":
 
The following message element may be included in the Join Request = message:
- WTP Reboot Statistics, see Section 4.4.44.
 
Comments please,
 
Thanks,
 
Dorothy

 
On 6/30/06, Michael=20 Montemurro <montemurro.michael@gmail.com= >=20 wrote:=20
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat=20 Calhoun (pacalhou) <pcalhoun@cisco.com >=20 wrote:=20
Going=20 through David's lengthy document, he has raised an = interesting
number=20 of points that I believe require issues to be created. At one =
point=20 I'm paraphrasing Dave's comments in order to be brief, = and
introducing=20 my own numbering scheme.

1) Can message elements be in any = order?=20 (I believe they should be)

<PRC> Yes, and I suspect = we need=20 to include text to make it more
obvious.


2) Are all = specified message elements required? (The obvious answer = is
"yes", but=20 this document doesn't discuss versioning. For example, what
if = in a new=20 version of CAPWAP an additional message element was to be =
added. Would=20 a new message type be created and the additional = message
element added=20 to it, or the existing type reused?)

<PRC> This is a = great=20 question, and one that does need to be addressed
in the spec. = In the=20 Diameter protocol we dealt with this issue by
including a = "Mandatory=20 to implement" bit. If any AVP was received, whose
bit was set, = yet was=20 not recognized, then the request had to = be
rejected.

<PRC>=20 We could consider something similar here, but I believe with the=20
firmware download component of the protocol it may be less of = an issue=20 -
although not guaranteed. I would hope (and expect) that as = the=20 CAPWAP
protocol extends, the AC would push new firmware to the = WTP.=20 This does
require that the initial part of the state machine = be fairly=20 static, and
this could be an area where the "Mandatory to = implement"=20 bit could be
useful as it would allow the AC to fall back to = older=20 protocol behavior.

3) CAPWAP-01 doesn't do a good job of=20 indicating which message elements
can be = repeated.

<PRC>=20 Another good point. When we list the message elements, we = should
note=20 whether the frequently is 0-1 (meaning absent or once), 1 (only =
once)=20 or 0+ (meaning any number of them could be present.


4) = Can=20 "additional" message elements be added to a message? (I = believe
so for=20 reporting capabilities, statistics, and     = events.=20 For
configuration, there is nothing in the protocol that says = what=20 happens
when one end gets an = configuration    =20 element it doesn't know about.
Should it be ignored, and the = other=20 elements processed, or should the
complete=20 operation     failed?)

<PRC> The = "Mandatory to implement" bit above could address this issue.
If = an=20 unrecognized message element is found to have the bit set, = then
the=20 whole message needs to be rejected. If the bit is not set, the =
message=20 element may be safely ignored.


5) The config has a = concept of=20 "default value" for each configuration
attribute. However, the = default=20 values are not clearly specified. This
needs to be resolved to = be able=20 to support "default values".

<PRC> Another good = point raised=20 by David.


6) the documentation of which "binding = specific"=20 message elements are to
be included with CAPWAP messages is not = consistent, and is difficult to
follow.

<PRC> Has = this=20 been addressed in the latest (-02) document?


7) There = are some=20 message elements that cause "actions". This approach
to = protocol design=20 is problematic and should be eliminated.

<PRC> Could = you be=20 more specific as well as provide guidance on what you
would = like to=20 see?


8) The message types are inconsistently named, and = do not=20 follow the
conventions of well designed protocols. Can the = operations=20 be named
consistently with the following=20 terminology:
  1) request/response (used to = get/set/perform=20 action)
  2) report/ack (use to tell the other side=20 something)

<PRC> Could you provide your thoughts on = which=20 messages fall within
which one of your = categories?


9) Many=20 of the configuration items, and status items are not listed = in
one=20 section with definitions. (Well make it two sections - one = for
CAPWAP=20 and the other which is "binding" specific.) For example, not all =
of=20 the time period lengths are identified and specified in section=20 4.5.

<PRC> Unfortunately, the document has gone back = and=20 forth a few times
and before we opt to change the structure of = the=20 document, I'd like to
ensure that we have broad agreement on = what we=20 want - with the
understanding that we will never make everyone=20 happy.


10) each operation should have listed in which = states it=20 can be sent and
received

<PRC> I do not understand = your=20 comment.


11) All strings, such as WTP location, should = be=20 changed from US-ASCII
encoding to UTF-8 = encoding.

<PRC>=20 Agreed.

12) The term "mobile" is not really accurate when=20 describing wireless
interfaces, since wireless does not=20 imply      mobile. Can we just = use
the=20 techie term "STA" instead.

<PRC> I agree we should = use the=20 term Station, or STA for short.


13) The WTP Descriptor = message=20 element contains too much information,
lacks clarity on the = WTP=20 encryption field and includes version numbers,
which should be = in=20 string form.

<PRC> To the first point, I disagree. I = think=20 there is value in knowing
everything about the WTP. The AC = vendors can=20 expose whatever information
they want, but I don't believe = anything is=20 unnecessary.

<PRC> To the second point, this is one = of those=20 areas where the concept
of the technology binding creates = complexity.=20 Given that we cannot
simply discuss 802.11i at this point, the = only=20 thing we can do is punt
to another section in the technology = binding=20 section. That said, I agree
with Dave that the 802.11 binding = section=20 is too light in this area.
However, I would much prefer that = instead of=20 trying to address this
specific issue, we discuss whether we = should=20 even be supporting the mode
of operation where 802.11i is = performed in=20 the AC - especially with the
introduction of DTLS to secure the = data=20 plane. Right now, it just feels
like we have too many options = and I am=20 worried that interoperability
will be severely impacted (not to = mention=20 protocol complexity).

<PRC> To the last point, I have = no=20 issues with including text stating
that the version numbers = should be=20 in string form.


14) The WTP Descriptor information is = not=20 required at Join time.

<PRC> Well, as far as I can = tell, I=20 think there's value in knowing
whether the WTP can even be = supported by=20 the AC. So the more info is
provided by the WTP, the better = the AC can=20 determine whether it should
just ignore the WTP or not. This = could be=20 done because it knows that the
firmware running on the WTP is = not=20 compatible, and it has no new
firmware to = download.


15) Are=20 the values in the WTP Frame Encryption a capabilities bit, or=20 an
enum?

<PRC> Looks like an enum to me. Not sure = what=20 Dave would prefer the text
to read. There are various other = similar=20 comments throughout, which I
will not repeat = here.


16) The=20 Discovery Response is broken. The AC SHOULD NOT be providing = any
info=20 to a WTP (or something that claims to be a WTP). Also, the = AC
should=20 tell the WTP what to do next, with choices: 1) Ok to try to join, =
2)=20 don't try to join, 3)=20 = try           &nbs= p;        =20 discover on a list of
returned ACs)

<PRC> I don't = believe=20 there is an issue with sending the AC's
information to the WTP, = but=20 would solicit input from the list. That
said, some of the = information=20 in the AC Descriptor is required, such as
the current load on = the AC.=20 No point is trying to join if he AC
indicates it's already at = max=20 capacity.
<PRC> I believe if the AC does not return the = response,=20 then it implies
(2). Otherwise, it is (1). (3) is handled = during the=20 join or configure
process, which I believe is = right.


17) Is=20 AC Name text?

<PRC> Yes, and same with WTP=20 Name.


18) Primary Discovery are not required.=20

<PRC> Disagree. Required for = failover.


19) The=20 text does not make it clear that the contents of the = WTP
Location is=20 informative only, and as Dave calls it, a = "scratchpad".

<PRC>=20 Well, to be honest, I thought the example "next to the fridge" =
made it=20 clear that the information did not derive from any = scientific
formula.=20 The description also states this is a user-defined. I = believe
this=20 should be good enough.


20) Session is not=20 required

<PRC> I believe you may be correct that with = the=20 transition to DTLS,
this is no longer required.


21) = need to=20 send "common name" as found in the WTP CERT so that the AC
can=20 verify

<PRC> The protocol currently relies on the MAC = address=20 being the key
that binds the certificate to the WTP. I don't = see a need=20 to change
this.


22) Result code in Join Response is = not=20 sufficient, for instance WTP HW
not = supported.

<PRC>=20 Well, the protocol does not require this because the = Discovery
Response=20 would never be sent (as the protocol stands today).


23) = AC=20 IPv4/IPv6 Addr discusses clustering, which is unnecessary.=20

<PRC> Agreed.


24) Change Echo to = Keepalive or=20 heartbeat.

<PRC> I call it potato....


25) = What if=20 all of the message elements do not fit within a single
CAPWAP = control=20 frame.

<PRC> We should address this.


26) = AC Name=20 with Index is all messed up...

<PRC> Not really. You = simply=20 include more than one, and the index field
is clearly the = priority.=20 Don't understand the Multi-AC comment. No
inter-AC protocol = implied=20 here.


27) WTP Board Data belongs in the Join, not=20 configure.

<PRC> Agreed, but wonder even more why we = are=20 duplicating this
information across both the WTP Descriptor and = the WTP=20 Board Data
message elements.


28) The WTP Static = IPv4=20 Address should not have the Static bit, but
instead state that = 0.0.0.0 means a = static address is=20 not to be used.

<PRC> I don't have an issue with this = request, but in the end we have
the same function. The reason = why I=20 state this is that we can refine
this protocol until the cows = come=20 home, and at one point we need to draw
a line in the=20 sand.


29) WTP Reboot Statistics belongs in the Join, = and the=20 reasons listed
are not clear enough.

<PRC> = Doesn't really=20 matter whether this is included in the
configuration or the = join, but=20 if the WG agrees to move it. We can
clarify some of the = reasons, as=20 long as it provides value.


30) The IEEE 802.11 WTP = Radio=20 Configuration message element's BSSID
field should be an=20 array.

<PRC> Disagree.


30) The IEEE 802.11 = WTP=20 Radio Configuration message element's Country
Code is not clear = enough.

<PRC> The text points to the actual MIB = element in=20 the 802.11-1999
standard, which very clearly defines the = contents of=20 the field. I don't
think there's value in replicating the = format of=20 this field in the
CAPWAP standard.


31) There seems = like an=20 awful lot of additional configuration message
elements that = need to be=20 specified here!

<PRC> Having built a protocol based = on this,=20 it's not clear to me what's
missing. I think it would be = useful if you=20 provided concrete details on
what's missing.


32)=20 Configuration Status is just plain broken because any = configuration=20
change operation may fail and there is=20 no           = response to=20 the
configuration changes specified in this=20 command.

<PRC> There certainly is - I guess I don't=20 understand the concern.


33) Use of Change State Event = should=20 instead be Radio Admin State.

<PRC> Perhaps the two = are not=20 described properly. The first is used by
the WTP to inform the = AC that=20 something has occurred with a radio. The
second is used by the = AC to=20 enable/disable a radio.


34) Report Timer needs to be in = section=20 4.5 or 11

<PRC> ok


35) Should Idle Timeout = be per=20 radio, or per WTP, and should the value
be defined in section = 4.5 or=20 11.

<PRC> Per WTP, and yes. I believe it is fine as = it is.=20


36) WTP Fallback isn't well defined, and should be = removed.=20

<PRC> Disagree. I believe it is necessary to create = enough=20 resiliency in
the protocol/service.


37) How are the = "Rate=20 Set" and "Supported Rates" encoded.

<PRC> This was = fixed in=20 the -02


38) AC Timestamp doesn't belong in the = configuration,=20 but instead in the
join.

<PRC> Not sure this = really=20 matters....


39) Add MAC ACL Entry - this is so strange = and is=20 being managed like no
other configuration = data.

<PRC> I=20 do not understand the comment


40) Decryption Error = Report=20 Period is not defined in section 4.5 or 11

<PRC> ok, = and note=20 that the information has been moved to the IEEE
802.11 RSNA = Error=20 Report From Mobile


41) Configuration Update Response. = today,=20 there are primarily two types
of configuration models. The = first is=20 when config is changed, it is only
changed in the volatile copy = (the=20 memory or running). An explicit
command is needed to save the = config=20 to nonvolatile storage. The second
model has config both = running=20 (volatile) and saved (nonvolatile) config
changed when a config = change=20 is made. And there might be a special
command to have a config = change=20 apply to only one. In this case, there
is no need for a "save = config to=20 nonvolatile" command. It is not clear
what is suppose to be = supported=20 here in CAPWAP, and how does CAPWAP
support devices with no or = very=20 limited nonvolatile storage for config!

<PRC> CAPWAP = does not=20 support WTPs with no nonvolatile storage. The
protocol has the = AC push=20 configs to the WTP, which saves them at the
time they are = received. I=20 do not believe anything else is required.


42) = Configuration=20 Update Response includes the Result Code message
element, which = includes values that do not appear to be relevant for
this = message,=20 and there are plenty of other failure cases

<PRC> ok, = but=20 note that we are sharing a common message element. = Any
suggestions on=20 how to address your issue?


43) Change State Event = Report. This=20 seems a little silly to be sent in
the "configure" state. It = seems=20 only appropriate for the "run" state.
Some might argue that = even in the=20 "run" state it shouldn't be sent after
a "config update" = request that=20 changes the operational state. However,
in the "run" state, it = may=20 take a while to have the operational state
change to follow the = admin=20 state. Thus, I think it is OK in the "run"
state after config=20 changes."

<PRC> I believe this was addressed in -02.=20


44) Clear Config Request. this operation has several = problems,=20 which
include:
   1) currently, the CAPWAP-01 spec = says=20 that this can only be done in
the "run" state. This is silly. = It should=20 also be possible in the
"configure" state.
<PRC> I = wonder why=20 the AC would even consider clearing the WTP's state
before it = even=20 knows how it is configured.

   2) the value of=20 "manufacturing defaults" is not defined, and a poor
term to = use, since=20 it implies that that each manufacturer can have
different = values. If=20 so, then the AC will have no knowledge of the
config on the = WTP! The=20 problem of "default config values" has already be
mentioned = above.=20 After each config attribute has been defined with a
default = value, then=20 the proper term would be "CAPWAP config defaults".
<PRC> = Yes,=20 you've raised this point already, and I agree that it does =
need to be=20 addressed.

   3) This operation is not defined to = have a=20 response. This is broken,
since any config change can fail. = Also, it is=20 not defined what happens
next. Does this cause the WTP to = reboot an=20 start a "clean discovery"?
<PRC> This was addressed in=20 -02


45) Image Data Request. Yes, there are actually = three=20 different "Image
Data Request" messages. Which one is=20 = determined          by = which of the
three message elements is contained. This is = completely=20 silly! There
should be three separate operations! = Additionally, how=20 does the WTP know
which image to get? The AC should be making = that=20 decision.

<PRC> I believe the WTP is the only device = that=20 knows what it's filename
should be. Why would an AC vendor = know about=20 file naming conventions
used by the WTP vendors? I believe your = other=20 issues are discussed in
the next items.


46) Image = Data=20 Response. this is silly. This operation can fail! There
needs = to be=20 message element that indicates=20 = the          result.
<PRC>=20 How so? This is only used to send firmware to the WTP. Not = clear
what=20 could fail... Reading the image from flash?


47) Image = Data=20 Request. when starting over again at the WTP start state,
the = WTP=20 shouldn't use the "normal" discovery process, but instead = "fast
track"=20 a connection back to the AC that just downloaded the image. = With
a=20 little=20 = more          work, we = could probably figure out a way to reuse
the old DTLS=20 session.

<PRC> To what gain? What is so expensive = about the=20 discovery, and what
happened if the AC was not longer=20 reachable?


48) opcode - if this is here, might as well = also=20 have a value that
indicates last block of the image file, = instead of=20 looking at the block
size.

<PRC> But we're just = changing=20 for the sake of changing - the protocol
works = as-is.


49)=20 since this operation does not have the block number as a = parameter,=20
the WTP must determine the block number via the CAPWAP message = header
sequence number.  NOTE: DTLS does not provide = in-order=20 delivery of
packets. Also, this requires the WTP to remember = state.=20 This message
element should be re-engineered to have the = following=20 subfields:
[edited]

<PRC> The control header = includes a=20 sequence number, and while we can
change the current protocol = to match=20 your recommendations, the protocol
does work. If it ain't=20 broken...


50) Image Data Response. this is silly. This=20 operation can fail!  For
example, the WTP can run = out of=20 space to=20 = store          the=20 block, or
there could be a failure in writing the block to = storage. (Or=20 as "Image
Data Request"(9.1a) is presently specified, the = checksum=20 match could
fail.) There needs to be message element that = indicates=20 the result.)
Note: don't need a block number field, since = request and=20 responses are
paired.

<PRC> We can include a = result=20 code


51) Image Data Request. silly beyond belief=20

<PRC> Beauty is in the eye of the beholder ;-). = Seriously,=20 the protocol
does work, so what exactly are you looking=20 for?


52) Image Data Response. This is silly. This = operation can=20 fail! There
needs to be message element that indicates=20 = the          result.
<PRC>=20 See above comment.

53) Reset Request. = ...

<PRC> The=20 comment is irrelevant now that Clear Config has = changed.


54)=20 Reset Response. this is silly. This operation can fail! There = needs
to=20 be message element that indicates=20 = the          result.
<PRC>=20 I sense a trend. I will stop including these messages from now=20 on.


55)Duplicate IPv4 Address. how often is this = reported if=20 the condition
remains?

<PRC> Only required once, I = think,=20 but we may want to include some text
covering = that.


56) the=20 list of events seems understated!

<PRC> Text and = conditions=20 please


57) Data Transfer Request. Nice to have -=20 remove.

<PRC> Disagree. Providing diagnostics = capabilities is=20 required.


58) Mobile Config Request. the actual details = of how=20 this works on both
splitMAC and especially localMAC are not = well=20 specified. That is, only
the figures and text in sections = 11.1.1 and=20 11.1.2 provide any clue as
to events that would cause an AC to = send=20 this message type. Also, there
are restrictions on = combinations of=20 parameters that can be included in
the = message.

<PRC> I=20 wonder whether other folks agree that more details are=20 required.


59) it doesn't say if one message can be used = to=20 update more than one
STA. It should be = able.

<PRC> No,=20 otherwise you end up with the problem of associating = specific
message=20 elements with a given mobile. One mobile per = request.


60) IEEE=20 802.11 Mobile. shouldn't the STA MAC address be included so =
this=20 message element can be matched with a (4.4.8)Add Mobile=20 message
element?

<PRC> I believe this is to your = previous=20 point, but the protocol assumes
one mobile per = request.


61)=20 IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC?=20 If
so, then why is this an 802.11 message = element

<PRC>=20 Intended to be a way to push policies to the WTP to = prioritize
mobile=20 traffic.


62) IEEE 802.11 WLAN Config Request. why is a = new=20 message type that is
802.11 specific needed to modify 802.11 = WLANs? It=20 seems like the
existing "(8.4)Configuration Update Request" = message=20 could be used.

<PRC> To be more specific only.=20


63) note here there are information elements to = create,=20 delete, and
modify WLANs. However, for message type = "(10.1)Mobile=20 Config Request",
there is only add and delete (and the "add" = used to=20 modify).

<PRC> Correct. The protocol requires the AC = to=20 resend a new add with a
different policy. No specific reason, = but if=20 this is deemed
inconsistent, we could change it.


64) = IEEE=20 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs =
seems=20 like it needs a little more work

<PRC> What exactly = would you=20 like to see?


Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems



> -----Original = Message-----=20
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: = Thursday, June 22,=20 2006 4:31 PM
> To: capwap@frascone.com=20
> Subject: [Capwap] A commentary on CAPWAP-01=20 operations
>
> HI,
>
> I've attached a = long file=20 that summarizes the operations in
> = CAPWAP-01.
>
>=20 Enjoy,
> /david t. perkins=20 =
>
_____________________________________________________________= ____=20
To unsubscribe or modify your subscription options, please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap=20

Archives: http://lists.frascone.com/pipermail/capwap


________________________________________= _________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBCA.40F3DFE9-- --===============0024334113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0024334113==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 14:29:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzsV-0005Y1-B7 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:29:27 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWzsT-0001zR-CZ for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 14:29:27 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 211A91448008 for ; Mon, 9 Oct 2006 11:29:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id E971D4300F5 for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id DBD023980AE for ; Mon, 9 Oct 2006 10:42:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3FDF3980D3 for ; Mon, 9 Oct 2006 10:42:17 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:42:14 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208,217"; a="329563317:sNHT1640828384" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99HgEjW022119; Mon, 9 Oct 2006 10:42:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k99HgEbF026781; Mon, 9 Oct 2006 10:42:14 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:42:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 10:42:12 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8954@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed resolution to issue 137 - Proposal for arevised packet header Thread-Index: AcbjGUFaLBXRUxmORk2YcjlSB4ybRgIqM5Vw From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 09 Oct 2006 17:42:12.0724 (UTC) FILETIME=[40A6EB40:01C6EBCA] Authentication-Results: sj-dkim-8.cisco.com; header.DKIM-Signature=pcalhoun@cisco.com; dkim=fail ( 57 extraneous bytes; RSA-96 err: "Pat Calhoun \(pacalhou\)" ; cisco.com/sjdkim8002 fail; ); header.From=pcalhoun@cisco.com; dkim=neutral X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.459 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Proposed resolution to issue 137 - Proposal for arevised packet header X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898885181==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d This is a multi-part message in MIME format. --===============1898885181== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBCA.405B4969" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBCA.405B4969 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe we need to wait until a resolution has been made before proceeding with any proposed changes to the packet header. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, September 28, 2006 9:11 AM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] Proposed resolution to issue 137 - Proposal for arevised packet header =09 =09 Hi Mike, =20 Use of a mux header, (regardless of 1 or 2 ports, not needed if 3 ports are used) is also one solution to the (recently opened Issue 224, regarding the) need to clearly distinguish Discovery frames in the control channel: =20 "I have a basic question regarding the classification of packets exchanged over control channel. It is stated in the draft that AC in Idle state can receive Discovery as well as DTLS clientHello (+other dtls handshake) packets. The=20 clientHello packets are delivered to the SSL layer and Discovery packets are consumed by the CAPWAP. Question is how? The draft assumes some magic way of doing it. Since both of the packets are in plain, and are received on=20 a single udp port, which state/policy/field classifies such packets from one another? Theoretically speaking, WTP can send a discovery packet which is also a valid clientHello packet! Now AC would respond with a discovery=20 response or a clientHello reponse? =09 In thread http://lists.frascone.com/pipermail/capwap/msg03035.html , Pat talks about the negotiated policy for the appropriate treatment of the received packets. That may=20 mean, if the AC is in join onwards state, it can be assumed that AC will only receive encrypted packets. Though this policy can work, but there would be exceptions in which WTP dies and comes back with a discovery packet. AC still being in join+=20 state, the received packets will be delivered to the SSL layer. Assumptions can be made here that SSL would discard non-dtls packets and with timeouts in picture, WTP and AC would eventually reach a consensus. But is this ok to assume?=20 =09 In the same thread, Perkins suggested the mux header approach for control channel, but it was not acknowledged? Is there some other hidden mechanism for the classification? Or there is some basic point which I miss here?" =20 This issue is noted in the issue 137 text (there is alot of text), and is stated in terms of protected vs unprotected messages, though the note comments that this is essentially the same as identifying the Discover (unprotected contro)l message: =20 NOTE: A CAPWAP MUX header is needed whether or not the same or different UDP ports are used for CAPWAP control and data messages. This is because both CAPWAP data and control messages can be unprotected or protected by=20 DTLS, and the MUX header is needed to distinguish protected from unprotected. Remember that CAPWAP "discovery requests" and "discovery responses" are unprotected, and that all other CAPWAP control=20 message types are protected. =20 The current -02 draft in incomplete in its specification of how=20 Discovery frames are clearly identified. The header definition proposed in issue 137, or a variant - one that differentiates between discovery, control and data CAPWAP messages for example, provides a means to clearly identify Discovery frames. =20 If an implementation has another means - the issue 224 commenter used the term "magic", to=20 disambiguate the frames, that implementation can chose to ignore an added mux field; however the protocol should be explicit. Dorothy =20 On 9/23/06, Michael Montemurro wrote:=20 I don't see why a MUX header is required even if the decision to go with separate control and data ports. I don't see how this header definition is better than what is currently in draft -02.=20 =20 If there are specific edits to the header that are required, I would like to know what they are; otherwise I propose closing this issue. =20 Cheers, =20 Mike =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBCA.405B4969 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 believe we need to wait until a resolution has been made before = proceeding with=20 any proposed changes to the packet header.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, September = 28, 2006=20 9:11 AM
To: Michael Montemurro
Cc:=20 capwap
Subject: Re: [Capwap] Proposed resolution to issue = 137 -=20 Proposal for arevised packet header

Hi Mike,
 
Use of a mux header, (regardless of 1 or 2 ports, not = needed if=20 3 ports are used) is also one solution to the (recently = opened
Issue 224, regarding the) need to clearly distinguish Discovery = frames in=20 the control channel:
 
"I have a basic question regarding the = classification of=20 packets exchanged over
control channel. It is stated in the draft = that AC=20 in Idle state can receive
Discovery as well as DTLS clientHello = (+other=20 dtls handshake) packets. The
clientHello packets are delivered to = the SSL=20 layer and Discovery packets are
consumed by the CAPWAP. Question is = how?=20 The draft assumes some magic
way of doing it. Since both of the = packets are=20 in plain, and are received on
a single udp port, which = state/policy/field=20 classifies such packets from one
another? Theoretically speaking, = WTP can=20 send a discovery packet which is
also a valid clientHello packet! = Now AC=20 would respond with a discovery
response or a clientHello=20 reponse?

In thread http://lists.frascone.com/pipermail/capwap/msg03035.html, Pat talks about
the negotiated policy for the = appropriate=20 treatment of the received packets. That may
mean, if the AC is in = join=20 onwards state, it can be assumed that AC will only = receive
encrypted=20 packets. Though this policy can work, but there would be exceptions=20 in
which WTP dies and comes back with a discovery packet. AC still = being in=20 join+
state, the received packets will be delivered to the SSL = layer.=20 Assumptions can be
made here that SSL would discard non-dtls = packets and=20 with timeouts in picture, WTP
and AC would eventually reach a = consensus.=20 But is this ok to assume?

In the same thread, Perkins = suggested the=20 mux header approach for control channel,
but it was not = acknowledged? Is=20 there some other hidden mechanism for the
classification? Or there = is some=20 basic point which I miss here?"
 
This issue is noted in the issue 137 text (there = is alot of=20 text), and
is stated in terms of protected vs unprotected = messages,=20 though the
note comments that this is essentially the = same as=20 identifying the Discover (unprotected
contro)l message:
 
NOTE: A CAPWAP MUX header is needed whether or not the same=20 or
       different UDP ports are = used for=20 CAPWAP control and
       data = messages. This=20 is because both CAPWAP data = and
      =20 control messages can be unprotected or protected by=20
       DTLS, and the MUX header is = needed to=20 distinguish
       protected from=20 unprotected. Remember that = CAPWAP
      =20 "discovery requests" and "discovery responses"=20 are
       unprotected, and that all = other=20 CAPWAP control
       message types = are=20 protected.
 
The current -02 draft in incomplete in its = specification of=20 how
Discovery frames are clearly identified. = The header=20 definition proposed in issue 137, or a variant = -
one that differentiates between discovery, control = and data=20 CAPWAP messages for example, provides a = means to clearly identify Discovery frames.
 
If an implementation has another means - the = issue 224=20 commenter used the term "magic",  to
disambiguate the frames, that implementation can = chose=20 to ignore an added mux field; however
the protocol should be explicit.

Dorothy


 
On 9/23/06, Michael=20 Montemurro <montemurro.michael@gmail.com > wrote:=20
I don't see why a MUX header is required even if the decision = to go=20 with separate control and data ports. I don't see how this header = definition=20 is better than what is currently in draft -02.
 
If there are specific edits to the header that are required, I = would=20 like to know what they are; otherwise I propose closing this = issue.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6EBCA.405B4969-- --===============1898885181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1898885181==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 17:26:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2e9-0002SN-57 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 17:26:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2e7-0002YP-FC for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 17:26:49 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 87F02144808A for ; Mon, 9 Oct 2006 14:26:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id A4A1D430018 for ; Mon, 9 Oct 2006 14:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7CF41144800A for ; Mon, 9 Oct 2006 14:14:30 -0700 (PDT) Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [204.127.225.93]) by hermes.tigertech.net (Postfix) with ESMTP id 8896D1448071 for ; Mon, 9 Oct 2006 14:14:24 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc13) with ESMTP id <20061009211423b1300l9jkoe>; Mon, 9 Oct 2006 21:14:24 +0000 Message-ID: <452ABBB1.4020400@cs.umd.edu> Date: Mon, 09 Oct 2006 17:14:25 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A2029E893A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2029E893A@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Margaret Wasserman , Saravanan Govindan , Cheng Hong , capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Slight clarification... my previous posts indicated that transporting the PMK to the WTP would break the security model. To accomplish what Saravanan is talking about only requires transporting the KCK after message 2 of the 4-way handshake. In the 11i keying hierarchy, the TK (made up of the KCK, KEK, and PTK) is derived from the PMK based on the 4-way-handshake. We're already transporting the PTK from the AC to the WTP in this scenario for CCMP and TKIP to use. Transporting the KCK too and allowing the WTP to perform the MAC doesn't break the current security model. Now, as to whether or not it makes sense from an implementation standpoint, I'll leave to those with strong opinions than I. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Pat Calhoun (pacalhou) wrote: > This would require the AC to send additional keying information to the > WTP, since message three needs to be authenticated. So I disagree with > this proposal. The change is much more sinificant than simply leaving > the field zero. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] >> Sent: Monday, October 09, 2006 12:08 AM >> To: Cheng Hong; Scott G. Kelly; Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Cheng Hong, Scott, >> >> I share your concerns for setting the KeyRSC to 0. >> >> In my opinion, it is clear that the protocol is "broken" in >> this case and needs to be fixed. >> >> My suggestion is to have the KeyRSC field be updated by the >> WTP. So the AC could send Message-3 of the 4-way handshake to >> the WTP with an empty KeyRSC field. The WTP could then >> correctly update the field, compute the KeyMIC, update >> Message-3 and then forward it to the STA. >> >> Of course, this requires a CAPWAP message from the AC and WTP >> to exchange the incomplete Message-3. I think this is an >> acceptable addition because it maintains the integrity of >> 802.11i exchanges and provides a complete fix to the problem. >> >> Saravanan >> >> >> >> >> >> -----Original Message----- >> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] >> Sent: Monday, October 09, 2006 1:21 PM >> To: Scott G. Kelly; Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Scott, >> >> Some comments below: >> >>> After thinking long and hard about this, I can't bring >> myself to agree >>> with the suggested text. Quite frankly, I think always using an RSC >>> value of 0 is a lazy hack, and given that we've acknowledged we are >>> introducing a vulnerability here (however slight), telling >>> implementors they SHOULD do this just doesn't sit right with me. >>> >>> An enlightened implementation could almost certainly do better than >>> always setting this to zero, and explicitly recommending >> that people >>> nail this window open just rubs me the wrong way. At least, >> let's hold >>> off on this decision until we've clearly defined what statistics we >>> expect to be available. Seems like if we're going to tell >> implementors >>> what they SHOULD do, we SHOULD give them sound, well considered >>> advice. >> I absolutely agree with you on this point. >> >> What I was trying to state in my previous emails was: >> - I would against setting a static value for the KeyRSC as a >> solution to this issue. >> - However if the WG decided to go for a static value, the >> draft should clearly point out that NOT all static value >> could work (value other than zero may be a problem for >> interoperability). >> - And the draft needs to clearly point out what is the danger >> of setting a static KeyRSC value in the security >> consideration section. >> - Also, the draft should not prohibit other implementation >> for sync the KeyRSC value between WTP and AC (the CAPWAP >> standard should not dictate such implementation incompatible). >> >> If there is a alternative solution than setting a static >> KeyRSC value to narrow the window, I would vote for it. >> >> cheers >> >> Cheng Hong >> >> >> >>> -----Original Message----- >>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>> Sent: Saturday, October 07, 2006 8:26 AM >>> To: Margaret Wasserman >>> Cc: capwap >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Hi Margaret, >>> >>> Comments inline below... >>> >>> -----Original Message----- >>>> From: Margaret Wasserman >>>> Sent: Oct 6, 2006 9:39 AM >>>> To: Scott G Kelly >>>> Cc: Cheng Hong , capwap >>>> >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> While I am not against leaving things open to more optimal >>>> implementations, I do think that we need to add some text to the >>>> protocol portion of the document (as well as the security >>>> considerations) to explain how this is handled. How about >> something >>>> like: >>>> >>>> The AC SHOULD use an RSC of 0 when computing message-3 of >> the 4-way >>>> 802.11i handshake, unless the AC has knowledge of a more >> optimal RSC >>>> value to use. Mechanisms for determining a more optimal RSC >>> value are >>>> outside the scope of this specification. >>>> >>>> I do not think that we should simply say nothing and hope that >>>> implementors figure this out. >>>> >>>> Margaret >>> After thinking long and hard about this, I can't bring >> myself to agree >>> with the suggested text. Quite frankly, I think always using an RSC >>> value of 0 is a lazy hack, and given that we've acknowledged we are >>> introducing a vulnerability here (however slight), telling >>> implementors they SHOULD do this just doesn't sit right with me. >>> >>> An enlightened implementation could almost certainly do better than >>> always setting this to zero, and explicitly recommending >> that people >>> nail this window open just rubs me the wrong way. At least, >> let's hold >>> off on this decision until we've clearly defined what statistics we >>> expect to be available. Seems like if we're going to tell >> implementors >>> what they SHOULD do, we SHOULD give them sound, well considered >>> advice. >>> >>> Scott >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 18:01:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3Bi-0002Ft-7U for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 18:01:30 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2zM-0006LF-6a for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 17:48:45 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id 62E3C144800A for ; Mon, 9 Oct 2006 14:48:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 5E865430018 for ; Mon, 9 Oct 2006 14:47:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 47B1B1448070 for ; Mon, 9 Oct 2006 14:47:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 908BD1448064 for ; Mon, 9 Oct 2006 14:47:02 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2006 14:47:02 -0700 X-IronPort-AV: i="4.09,285,1157353200"; d="scan'208,217"; a="445289495:sNHT96533464" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Ll1pq012617 for ; Mon, 9 Oct 2006 14:47:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k99Ll1in004134 for ; Mon, 9 Oct 2006 14:47:01 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Oct 2006 14:47:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 14:47:01 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8AF3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] discovery interval timer question Thread-Index: AcbnXSYmgj+5hOtMSUqeJWF2tPB/VQEeh5Ug From: "Pat Calhoun (pacalhou)" To: "Smitha Smitha (ssmitha)" , X-OriginalArrivalTime: 09 Oct 2006 21:47:01.0858 (UTC) FILETIME=[740EE420:01C6EBEC] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465784355==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 This is a multi-part message in MIME format. --===============1465784355== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBEC.73F8B8CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBEC.73F8B8CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hmmm.... this seems to be a bug. First of all, why would the WTP have to wait prior to establishing the DTLS session? Why is this simply not automatic? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Smitha Smitha (ssmitha)=20 Sent: Tuesday, October 03, 2006 7:31 PM To: Capwap@frascone.com Subject: [Capwap] discovery interval timer question =09 =09 =09 All, =20 Idle to Discovery transition talks about Discovery Interval timer: =20 Idle to Discovery (a): This transition occurs once device initialization is complete. =20 WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request message (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 4.5). The WTP resets the DiscoveryCount counter to zero (0) (see Section 4.6). The WTP also clears all information from ACs it may have received during a previous Discovery phase. =09 =20 But DiscoveryInterval timer is described as: =20 =09 4.5.1. DiscoveryInterval =20 The minimum time, in seconds, that a WTP MUST wait after receiving a Discovery Response, before initiating a DTLS handshake. =20 Should Idle to Discovery actually be based on MaxDiscoveryInterval timer? Also, there is mention of DiscoveryInterval timer even in transition from Discovery to Discovery. =20 4.5.6. MaxDiscoveryInterval =20 The maximum time allowed between sending discovery requests from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds. =20 Default: 20 seconds. =20 Thanks Smitha =09 =09 ------_=_NextPart_001_01C6EBEC.73F8B8CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
hmmm.... this seems to be a bug. First of all, why would the = WTP have to=20 wait prior to establishing the DTLS session? Why is this simply not=20 automatic?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Smitha Smitha (ssmitha) =
Sent:=20 Tuesday, October 03, 2006 7:31 PM
To:=20 Capwap@frascone.com
Subject: [Capwap] discovery interval = timer=20 question

All,
 
Idle to = Discovery=20 transition talks about Discovery Interval timer:
 
 Idle=20 to Discovery (a): This transition occurs once=20 device
      initialization is=20 complete.
 
      WTP: The WTP = enters=20 the Discovery state prior to transmitting=20 the
         first = Discovery=20 Request message (see Section 5.1). =20 Upon
         entering this = state,=20 the WTP sets the DiscoveryInterval=20 timer
         (see Section = 4.5).  The WTP resets the DiscoveryCount=20 counter
         to zero = (0) (see=20 Section 4.6).  The WTP also clears=20 all
         information = from ACs=20 it may have received during a=20 previous
         Discovery = phase.
 
But = DiscoveryInterval=20 timer is described as:
 

4.5.1.  = DiscoveryInterval
 
   The minimum time, in seconds, that a WTP = MUST wait=20 after receiving a
   Discovery Response, before = initiating a DTLS=20 handshake.
 
Should Idle to Discovery actually be based on=20 MaxDiscoveryInterval timer? Also, there is mention of = DiscoveryInterval timer=20 even in transition from Discovery to = Discovery.
 
4.5.6.  = MaxDiscoveryInterval
 
   The maximum time allowed = between sending=20 discovery requests from the
   interface, in = seconds.  Must=20 be no less than 2 seconds and no greater
   than 180=20 seconds.
 
   Default: 20 = seconds.
 
Thanks
Smitha

------_=_NextPart_001_01C6EBEC.73F8B8CF-- --===============1465784355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1465784355==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 18:03:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3BF-00022H-Hl for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 18:01:01 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX3A0-0008Cf-Fo for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 17:59:51 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id D226414480BF for ; Mon, 9 Oct 2006 14:59:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 21614430018 for ; Mon, 9 Oct 2006 14:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 09D711448072 for ; Mon, 9 Oct 2006 14:47:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 07148144805C for ; Mon, 9 Oct 2006 14:47:00 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2006 14:47:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99Ll0Ch011813; Mon, 9 Oct 2006 14:47:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k99Ll0in004103; Mon, 9 Oct 2006 14:47:00 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 14:47:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 14:47:00 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8AF2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Proposed Resolution to Issue 143: Specification for theusage of CERTS for CAPWAP/was CERT issues in CAPWAP-01 Thread-Index: AcbnPTwgQyQ4rGLpQ7uuxjiins45XAEmXnzA From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "capwap" X-OriginalArrivalTime: 09 Oct 2006 21:47:00.0460 (UTC) FILETIME=[733992C0:01C6EBEC] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, NORMAL_HTTP_TO_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Proposed Resolution to Issue 143: Specification for theusage of CERTS for CAPWAP/was CERT issues in CAPWAP-01 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1408918688==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 87bc9a4e89408d8c8661c56a834d56d6 This is a multi-part message in MIME format. --===============1408918688== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EBEC.730CB001" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EBEC.730CB001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm ok with Dorothy's proposed recommendations. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Tuesday, October 03, 2006 3:28 PM To: capwap Subject: [Capwap] Proposed Resolution to Issue 143: Specification for theusage of CERTS for CAPWAP/was CERT issues in CAPWAP-01 =09 =09 All, =09 Proposed resolutions for the several components of Issue 143 are included below. Issue 143 is also copied below. =09 Comments please. =09 Thanks, =09 Dorothy =09 ------------------------------------------------------------------------ ---------------------------------- 1) It should be OK for the clock on a WTP to be "wacky", due to having no battery backed up clock, the battery going bad, the clock never set properly. On the other hand, an AC's clock should be set pretty accurately. I't not sure that the recommendations support this scenario. In general, want to support: 0) WTPs with no management interface (other than CAPWAP) 1) first time use of WTP after being manufactured 2) continued use of WTP after long time operation 3) continued use in short term deployments (such as WiFi network used by a Circus that moves from town to town (setting up and tearing down for for each move), or for the WiFi network used at conferences (such as the IETF). =09 Proposed resolution: Adopt Charles' Clancy's recommendation to=20 Replace the following text: =09 Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real- time clock, they SHOULD verify the certificate validity dates. If no real-time clock is available, the device SHOULD attempt to determine the current time using NTP prior to certificate validation. If neither is available, devices SHOULD verify that the start validity date of its peer's certificate is less than its own certificate's expiration date, and its peer's expiration date is greater than its own start date. Note that failure to check a certificate's temporal validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation. =09 =09 with =09 =09 Proper validation of certificates typically requires checking to ensure the certificate has not yet expired. If devices have a real-time clock, they SHOULD verify the certificate validity dates.=20 =09 If no real-time clock is available, the device SHOULD make a best-effort attempt to validate the certificate validity dates through other means. Failure to check a certificate's temporal=20 =09 validity can make a device vulnerable to man-in-the-middle attacks launched using compromised, expired certificates, and therefore devices should make every effort to perform this validation.=20 =09 ------------------------------------------------------------------------ ---------------------- =09 2) The new text suggests the common name in the format "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies that "DOMAIN.NET " is the "administrative domain". To me, "administrative domain" implies the user of the WTP. But, I believe that the WTP manufacturer must be required to generate a CERT (and the WTP should come "preloaded" with the CERT), and the user of the WTP should not have to create the WTP CERT. (By the way, not sure how long the CERT should be valid.) Thus, I see no need or desire for "@DOMAIN.NET " added to the common name, and suggest that it be removed. (Also, I think that we have now a new requirement to be able via CAPWAP to replace the WTP's CERT with another, and may be to add CA CERTs for the AC's CERT chain. Also, what is the min depth that a WTP should support?) =09 Proposed Resolution: Adopt David's suggestion to drop the @DOMAIN.NET and add a sentence describing the storage requirements on the WTP and AC: =09 Change from: =09 Another important part of certificate authentication is binding a certificate to a particular device. There are many ways to accomplish this. CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, followed by an @ symbol, and then an administrative domain. For example, 01:23:45:67:89:ab@DOMAIN.NET. During authentication, devices SHOULD ensure that the MAC matches the MAC specified in the CAPWAP header, and that the domain in both the AC and WTP certificates match. =09 to=20 Another important part of certificate authentication is binding a certificate to a particular device. There are many ways to accomplish this. CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab. During authentication, devices SHOULD ensure that the MAC address matches the MAC address specified in the CAPWAP header. If this mechanism is used, the ACs SHOULD maintain list of all authorized WTP MAC addresses and the WTP SHOULD save the AC credential or credential identifier. =09 =09 ------------------------------------------------------------------------ --------------------------------- 3) specify that WTP CERTs cannot be selfsigned, and MUST have a common name of the ASCII of the MAC address (or other unique ID, such as serial number) =09 Proposed resolution:=20 No change to the text regarding use of self-signed certs. While the use of self-signed certs may not be widespread, there isn't a compelling need to preclude their use in a CAPWAP application.=20 =09 Change the text to require that WTP certs MUST have a common mane of the ASCII of the MAC address: =09 from: CAPWAP RECOMMENDS specifying the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab. =09 to =09 Specificaiton of the certificate common name (CN) as the WTP or AC MAC address formatted as ASCII HEX, for example, 01:23:45:67:89:ab is REQUIRED for use with the CAPWAP protocol. =09 =09 ------------------------------------------------------------------------ --------------------------------- 4) The Join Request must be updated to include the common name as a message element =09 Proposed resolution: No change to the text. The join request currenly includes the BSSID. Also, since the JOIN occurs inside the DTLS tunnel, it is implicitly bound to the MAC (assuming certs were used for authentication, and=20 this is N/A for preshared key authentication). =09 =09 ------------------------------------------------------------------------ ---------------------------------- 5) specify that WTPs must continue even when it believes its CERT or the AC's CERT is outside the time window =09 Proposed resolution: No change to the document. That seems equivalent to mandating WTPs never validate timestamps on any AC certs. What if the WTP has a real-time clock and actually CAN distinguish between good and bad certs? =09 ------------------------------------------------------------------------ ----------------------------------- . 6) Tthe CAPWAP protocol must have a new message to install an updated CERT for the WTP. =09 =09 Proposed resolution: Defer for consideration in the next version of CAPWAP;=20 the mechanisms for certificate distribution and management are quite complex re: certifcate formats, content, generation etc.=20 =09 =09 ------------------------------------------------------------------------ ---------------------------------------- =09 7) the CAPWAP protocol must have a new message to install a CA CERT. =09 Proposed resolution: Defer for consideration in the next version of CAPWAP;=20 the mechanisms for certificate distribution and management are quite complex re: certifcate formats, content, management. =09 =09 ------------------------------------------------------------------------ ------ Issue 143:=20 =09 =09 =09 1) Cipher Suites for CERTS CAPWAP-01 has the following cipher suites specified: TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DH_RSA_WITH_AES_256_CBC_SHA =09 The above is a mistake, and the following should be used: =09 =09 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_DHE_RSA_WITH_AES_256_CBC_SHA =09 2) CERT usage type: CAPWAP-01 has the folllwing about CERTS: =20 2.4.4.3 . Certificate Usage =09 Validation of the certificates by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the =09 =09 AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509v3 certificates MUST include the Extensions field [11] and MUST include the NetscapeComment [15] =09 =09 extension. =09 For an AC, the value of the NetscapeComment extension MUST be the string "CAPWAP AC Device Certificate". For a WTP, the value of the NetscapeComment extension MUST be the string "CAPWAP WTP Device =09 =09 Certificate". =09 Part of the CAPWAP certificate validation process includes ensuring that the proper string is included in the NetscapeComment extension, and only allowing the CAPWAP session to be established if the =09 =09 extension does not represent the same role as the device validating the certificate. For instance, a WTP MUST NOT accept a certificate whose NetscapeComment field is set to "CAPWAP WTP Device =09 Certificate". =09 =09 Using the "NetscapeComment extension" is not appropriate. =09 3) Selfsigned CERTs, CA CERTs, and validity checking I didn't see anything about whether or not the CERTs were selfsigned. And if not selfsigned, who would sign them. =09 =09 Also, how would a limited resource WTP verify an AC's cert? What if the WTP had no realtime clock (or a realtime clock with an unknown certainty)? =09 4) Common Name in a WTP's CERT I believe that the common name on the WTP's CERT =09 =09 must be the WTP's ID (which would be either the serial number or "base MAC address"), and should be provided as a parameter on the join. =09 Two small, but important issues are: 1) It should be OK for the clock on a WTP to be "wacky", due to having no battery backed up clock, the battery going bad, the clock never set properly. On the other hand, an AC's clock should be set pretty accurately. I't not sure that the recommendations support this scenario. In general, want to support: 0) WTPs with no management interface (other than CAPWAP) 1) first time use of WTP after being manufactured 2) continued use of WTP after long time operation 3) continued use in short term deployments (such as WiFi network used by a Circus that moves from town to town (setting up and tearing down for for each move), or for the WiFi network used at conferences (such as the IETF). 2) The new text suggests the common name in the format "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And implies that "DOMAIN.NET " is the "administrative domain". To me, "administrative domain" implies the user of the WTP. But, I believe that the WTP manufacturer must be required to generate a CERT (and the WTP should come "preloaded" with the CERT), and the user of the WTP should not have to create the WTP CERT. (By the way, not sure how long the CERT should be valid.) Thus, I see no need or desire for "@DOMAIN.NET " added to the common name, and suggest that it be removed. (Also, I think that we have now a new requirement to be able via CAPWAP to replace the WTP's CERT with another, and may be to add CA CERTs for the AC's CERT chain. Also, what is the min depth that a WTP should support?) =09 =09 So, it appears to me that the following changes are required to CAPWAP-01: 1) specify that WTP CERTs cannot be selfsigned, and MUST have a common name of the ASCII of the MAC address (or other unique ID, such as serial number) 2) The Join Request must be updated to include the common name as a message element 3) specify that WTPs must continue even when it believes its CERT or the AC's CERT is outside the time window 4) the CAPWAP protocol must have a new message to install an updated CERT for the WTP. 5) the CAPWAP protocol must have a new message to install a CA CERT. =09 =09 =09 On 6/15/06, Michael Montemurro < montemurro.michael@gmail.com > wrote:=20 All, =20 I've created issue 143 to deal with this problemm. =09 =20 =09 On 6/15/06, Scott G Kelly wrote:=20 Hi David, =09 Like I said previously, I agree with pretty much everything Charles said, so I won't re-iterate his points, and will instead simply add a=20 few comments below: =09 David T. Perkins wrote: > HI, > > Thank you for responding to my issues. It seems to me that > we are not yet looking at the same problem. So let me try > again.=20 > > What I was trying to point out is that there are a few > VERY common scenarios (use cases) where the clock on > a WTP can be totally wrong. If a WTP is coded so that > it will not continue and communicate with an AC when=20 > it thinks the AC's CERTs are outside the time window, > (or it thinks that it's on CERTs are outside the time > window) then you will have a useless device (a brick). > In many (maybe most) deployments, it costs more to=20 > physically touch a WTP than the equipment cost of the WTP. > At the Dallas IETF, there were APs that were "somewhere" > in the ceiling not doing any useful work, but sending > out beacons with their config'ed SSID because it was=20 > too expensive to find them, and take them down. It > was more cost effective to just new new APs. > > For an AC, it's clock must be accurate, > and it would be OK for it to not proceed if it believes=20 > its CERTs are outside their time window. But, the > CAPWAP protocol should allow an AC to establish > a session with a WTP that has a WACKY clock (and > even a CERT that has expired). NOTE: the AC clock=20 > must be pretty accurate for management (such as > logs) to be useful (or work). The CAPWAP protocol has > support to set the WTP's clock. But it doesn't have support > to update a CERT in a WTP. It seems like this is=20 > needed. > > Assume the clocks are OK, now lets talk about WTP > CERT validation by the AC. This wasn't addressed, but > I believe that WTP CERTs MUST be signed by the > WTP manufacturer, or one of the WELL KNOWN certification=20 > authorities. Adding the CA CERTs in an AC is done through > means outside of CAPWAP (such as via the CLI > on the AC). Thus, WTP CERTs MUST NOT be selfsigned. > And, I believe that the WTPs CERTs should have > for the common name the ASCII of MAC address, > or other unique ID of the WTP (and this must be provided > in the Join Request message). I didn't understand > in the previous text, nor in your message below=20 > why the common name would have a suffix of > "@DOMAIN.NET". > > Now lets talk about AC CERT validation by the WTP.=20 > The CERT for the AC can be created by the AC=20 > manufacturer, the user, or 3rd party. It could > be selfsigned, or have a chain from the manufacturer > or a WELL KNOWN CA. Given this, it will be difficult > for a WTP to verify a AC CERT, at least the first=20 > time. This is just a "leap of faith" if the CERT > cannot be verified. After this first connection, > the AC through the CAPWAP protocol could configure > the WTP with the needed CA CERT(s). However, there=20 > may be some WTPs that have no additional persistent > storage for these CERTs. > > So, it appears to me that the following changes > are required to CAPWAP-01: > 1) specify that WTP CERTs cannot be selfsigned,=20 > and MUST have a common name of the ASCII > of the MAC address (or other unique ID, > such as serial number) =09 While we may not think self-signing is a good idea for our typical deployment models, I'm not sure we have to say you MUST NOT do this, but I'll give this some more thought. =09 > 2) The Join Request must be updated to include > the common name as a message element=20 =09 What is your objective with this requirement? =09 > 3) specify that WTPs must continue even when it > believes its CERT or the AC's CERT is outside > the time window =09 Charles addressed this.=20 =09 > 4) the CAPWAP protocol must have a new message > to install an updated CERT for the WTP. > 5) the CAPWAP protocol must have a new message > to install a CA CERT. =09 I agree that we should discuss this, but I'm a little leary of taking on=20 the task of fully specifying every nuance of cert use and mgmt. Remember, the ipsec group spun out a whole new wg to handle this particular problem. It's complicated. =09 What we're trying to do in the base protocol is come up with minimal and=20 sufficient guidelines to get people going. I think cert mgmt and usage could be revisited in detail later, perhaps under a new charter, but that we might want to consciously avoid getting too bogged down in this=20 for rev 1. =09 Scott =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: =09 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6EBEC.730CB001 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm ok=20 with Dorothy's proposed recommendations.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Tuesday, October 03, = 2006=20 3:28 PM
To: capwap
Subject: [Capwap] Proposed = Resolution=20 to Issue 143: Specification for theusage of CERTS for CAPWAP/was CERT = issues=20 in CAPWAP-01

All,

Proposed = resolutions for=20 the several components of Issue 143 are included below.
Issue 143 = is also=20 copied below.

Comments=20 = please.

Thanks,

Dorothy
--------------------------------= -------------------------------------------------------------------------= -
1) It should be OK for the clock on a WTP to be = "wacky",
 =20 due to having no battery backed up clock, the battery
  going = bad, the=20 clock never set properly. On the other
  hand, an AC's clock = should be=20 set pretty accurately.
  I't not sure that the recommendations = support=20 this
  scenario. In general, want to support:
    = 0) WTPs=20 with no management interface (other than CAPWAP)
    1) = first=20 time use of WTP after being manufactured
    2) continued = use of=20 WTP after long time operation
    3) continued use in = short term=20 deployments (such
        as WiFi network used = by a=20 Circus that moves from
        town to town = (setting up=20 and tearing down for
        for each move), or = for the=20 WiFi network used
        at conferences (such = as the=20 IETF).

Proposed resolution: Adopt Charles' Clancy's=20 recommendation to
Replace the following text:

 Proper validation of certificates typically = requires=20 checking to
   ensure the certificate has not yet = expired. =20 If devices have a real-
   time clock, they SHOULD verify = the=20 certificate validity dates.  If no
  =20 real-time clock is available, the device SHOULD attempt to=20 determine
   the current time using NTP prior to = certificate=20 validation.  If
   neither is available, devices = SHOULD=20 verify that the start validity
   date of its peer's = certificate=20 is less than its own certificate's
   expiration date, = and its=20 peer's expiration date is greater than its
   own = start=20 date.  Note that failure to check a certificate's temporal
   validity can make a device vulnerable to=20 man-in-the-middle attacks
   launched using compromised, = expired=20 certificates, and therefore
   devices should make every = effort=20 to perform this validation.


with


Proper = validation=20 of certificates typically requires checking to
   ensure = the=20 certificate has not yet expired.  If devices have a
 =20  real-time clock, they SHOULD verify the certificate validity = dates.=20
   If no real-time clock is = available,=20 the device SHOULD make a
   best-effort attempt to = validate the=20 certificate validity dates
   through other means. =  Failure=20 to check a certificate's temporal
   validity can make a = device=20 vulnerable to man-in-the-middle attacks
   launched using = compromised, expired certificates, and therefore
  =  devices=20 should make every effort to perform this validation.=20 =
-----------------------------------------------------= -----------------------------------------

2) The new text suggests the common name in the=20 format
  "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And=20 implies
  that "DOMAIN.NET" is the = "administrative=20 domain".
  To me, "administrative domain" implies the = user
 =20 of the WTP. But, I believe that the WTP manufacturer
  must be = required to generate a CERT (and the WTP
  should come = "preloaded"=20 with the CERT), and the user
  of the WTP should not have to = create=20 the WTP CERT.
  (By the way, not sure how long the CERT should = be
  valid.) Thus, I see no need or desire for
  =  "@DOMAIN.NET" added to = the common=20 name, and suggest
  that it be removed. (Also, I think that we = have
  now a new requirement to be able via CAPWAP = to
 =20 replace the WTP's CERT with another, and may be
  to add CA = CERTs for=20 the AC's CERT chain. Also,
  what is the min depth that a WTP = should=20 support?)

Proposed Resolution:
Adopt David's = suggestion to=20 drop the @DOMAIN.NET and
add a = sentence=20 describing the storage requirements on the WTP and AC:

Change=20 from:

  Another important part of = certificate=20 authentication is binding a
   certificate to a = particular=20 device.  There are many ways to
   accomplish = this. =20 CAPWAP RECOMMENDS specifying the certificate common
   = name (CN)=20 as the WTP or AC MAC address formatted as ASCII HEX,
   = followed=20 by an @ symbol, and then an administrative domain.  = For
  =20 example, 01:23:45:67:89:ab@DOMAIN.NET.  During=20 authentication,
   devices SHOULD ensure that the MAC = matches the=20 MAC specified in the
   CAPWAP header, and that the = domain in=20 both the AC and WTP
   certificates = match.

to
  Another important part of certificate = authentication is=20 binding a
   certificate to a particular device.  = There are=20 many ways to
   accomplish this.  CAPWAP RECOMMENDS=20 specifying the certificate common
   name (CN) as the WTP = or AC=20 MAC address formatted as ASCII HEX,
   for = example,=20 01:23:45:67:89:ab.  During authentication,
   = devices SHOULD=20 ensure that the MAC address matches the MAC
   = address =20 specified in the CAPWAP header. If this mechanism is used, the ACs=20 SHOULD
   maintain list of all authorized WTP MAC = addresses and=20 the WTP SHOULD
   save the AC credential or credential=20 = identifier.

------------------------------------------------------= ---------------------------------------------------
3) specify that WTP CERTs cannot be = selfsigned,
   =20 and MUST have a common name of the ASCII
    of the MAC = address=20 (or other unique ID,
    such as serial=20 number)

Proposed resolution:
No change to the text = regarding=20 use of self-signed certs. While the use
of self-signed certs may = not
be=20 widespread,  there isn't a compelling need to preclude = their
use in a=20 CAPWAP application.

Change the text to require that WTP certs = MUST=20 have a
common mane of the ASCII of the MAC = address:

from:
CAPWAP RECOMMENDS specifying the certificate = common
  =20 name (CN) as the WTP or AC MAC address formatted as ASCII=20 HEX,
   for example,=20 01:23:45:67:89:ab.

to

Specificaiton of = the=20 certificate common
   name (CN) as the WTP or AC MAC = address=20 formatted as ASCII HEX,
   for example, = 01:23:45:67:89:ab=20 is REQUIRED for use with the CAPWAP=20 = protocol.

--------------------------------------------------------= -------------------------------------------------
 =20 4)  The Join Request must be updated to include
 =20   the common name as a message element

Proposed = resolution:=20 No change to the text. The join request
currenly includes the = BSSID. Also,=20 since the JOIN occurs inside the DTLS tunnel, it = is
 implicitly bound=20 to the MAC (assuming certs were used for authentication, and
this = is N/A=20 for preshared key=20 = authentication).

-------------------------------------------------= ---------------------------------------------------------
  5) specify that WTPs must continue even when = it
 =20   believes its CERT or the AC's CERT is outside
    = the time=20 window

Proposed resolution: No change to the = document.
That seems equivalent to mandating WTPs never validate = timestamps=20 on any
AC certs.  What if the WTP has a real-time clock and = actually=20 CAN
distinguish between good and bad=20 = certs?
--------------------------------------------------------= ---------------------------------------------------
.
 6= )=20 Tthe CAPWAP protocol must have a new message
  =20    to install an updated CERT for the = WTP.
Proposed resolution: Defer for = consideration in=20 the next version of CAPWAP;
the mechanisms for certificate = distribution=20 and management are
quite complex re: certifcate formats, content,=20 generation etc.
--------------------------------------------------------------= --------------------------------------------------

 7) the CAPWAP protocol must have a new=20 message
      to install a CA=20 CERT.

Proposed resolution: Defer for = consideration in the=20 next version of CAPWAP;
the mechanisms for certificate = distribution and=20 management are
quite complex re: certifcate formats, content,=20 = management.

------------------------------------------------= ------------------------------
Issue=20 143:=20 


1) Cipher =
Suites for CERTS
CAPWAP-01 has the following cipher suites =
specified:
TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_RSA_WITH_3DES_ED=
E_CBC_SHA, and
TLS_DH_RSA_WITH_AES_256_CBC_SHA

The above is a =
mistake, and the following should be used:


TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CB=
C_SHA, and
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

2) CERT usage =
type:
CAPWAP-01 has the folllwing about CERTS:
  
2.4.4.3
.  Certificate Usage

  Validation of the =
certificates by the AC and WTP is required so that
  only an AC may =
perform the functions of an AC and that only a WTP may
  perform the =
functions of a WTP.  This restriction of functions to the


  AC or WTP requires that the certificates used by the AC MUST =
be
  distinguishable from the certificate used by the WTP.  To =
accomplish
  this differentiation, the x.509v3 certificates MUST =
include the
  Extensions field [11] and MUST include the =
NetscapeComment [15]


  extension.

  For an AC, the value of the =
NetscapeComment extension MUST be the
  string "CAPWAP AC Device =
Certificate".  For a WTP, the value of the
  NetscapeComment =
extension MUST be the string "CAPWAP WTP Device


  Certificate".

  Part of the CAPWAP certificate =
validation process includes ensuring
  that the proper string is =
included in the NetscapeComment extension,
  and only allowing the =
CAPWAP session to be established if the


  extension does not represent the same role as the device =
validating
  the certificate.  For instance, a WTP MUST NOT accept a =
certificate
  whose NetscapeComment field is set to "CAPWAP WTP =
Device

  Certificate".


Using the "NetscapeComment extension" is not =
appropriate.

3) Selfsigned CERTs, CA CERTs, and validity =
checking
I didn't see anything about whether or not the CERTs
were =
selfsigned. And if not selfsigned, who would sign them.


Also, how would a limited resource WTP verify an AC's =
cert?
What if the WTP had no realtime clock (or a realtime =
clock
with an unknown certainty)?

4) Common Name in a WTP's =
CERT
I believe that the common name on the WTP's CERT


must be the WTP's ID (which would be either the serial
number =
or "base MAC address"), and should be provided
as a parameter on the =
join.

Two small, but = important=20 issues are:
1) It should be OK for the clock on a WTP to be=20 "wacky",
  due to having no battery backed up clock, the=20 battery
  going bad, the clock never set properly. On the=20 other
  hand, an AC's clock should be set pretty = accurately.
 =20 I't not sure that the recommendations support this
  scenario. = In=20 general, want to support:
    0) WTPs with no management=20 interface (other than CAPWAP)
    1) first time use of = WTP after=20 being manufactured
    2) continued use of WTP after long = time=20 operation
    3) continued use in short term deployments=20 (such
        as WiFi network used by a Circus = that=20 moves from
        town to town (setting up and = tearing=20 down for
        for each move), or for the = WiFi=20 network used
        at conferences (such as = the=20 IETF).
2) The new text suggests the common name in the = format
  "01:23:45:67:89:ab@DOMAIN.NET" for WTPs. And=20 implies
  that "DOMAIN.NET" is the = "administrative=20 domain".
  To me, "administrative domain" implies the = user
 =20 of the WTP. But, I believe that the WTP manufacturer
  must be = required to generate a CERT (and the WTP
  should come = "preloaded"=20 with the CERT), and the user
  of the WTP should not have to = create=20 the WTP CERT.
  (By the way, not sure how long the CERT should = be
  valid.) Thus, I see no need or desire for
  =  "@DOMAIN.NET" added to = the common=20 name, and suggest
  that it be removed. (Also, I think that we = have
  now a new requirement to be able via CAPWAP = to
 =20 replace the WTP's CERT with another, and may be
  to add CA = CERTs for=20 the AC's CERT chain. Also,
  what is the min depth that a WTP = should=20 support?)

So, it appears to me = that the=20 following changes
are required to CAPWAP-01:
 1) specify = that WTP=20 CERTs cannot be selfsigned,
    and MUST have a common = name of=20 the ASCII
    of the MAC address (or other unique = ID,
 =20   such as serial number)
 2) The = Join=20 Request must be updated to include
    the common name as = a=20 message element
 3) specify that WTPs = must=20 continue even when it
    believes its CERT or the AC's = CERT is=20 outside
    the time window
 4) the=20 CAPWAP protocol must have a new message
    to install an = updated=20 CERT for the WTP.
 5) the CAPWAP protocol must have a new=20 message
    to install a CA CERT.
On 6/15/06, Michael=20 Montemurro <=20 montemurro.michael@gmail.com> wrote:
All,
 
I've created issue 143 to deal with = this=20 problemm.

 
On 6/15/06, Scott G=20 Kelly <scott@hyperthought.com=20 > wrote:=20
Hi=20 David,

Like I said previously, I agree with pretty much = everything=20 Charles
said, so I won't re-iterate his points, and will = instead simply=20 add a
few comments below:

David T. Perkins = wrote:
>=20 HI,
>
> Thank you for responding to my issues. It = seems to me=20 that
> we are not yet looking at the same problem. So let me = try
> again.
>
> What I was trying to point out = is that=20 there are a few
> VERY common scenarios (use cases) where = the clock=20 on
> a WTP can be totally wrong. If a WTP is coded so = that
>=20 it will not continue and communicate with an AC when
> it = thinks=20 the AC's CERTs are outside the time window,
> (or it thinks = that=20 it's on CERTs are outside the time
> window) then you will = have a=20 useless device (a brick).
> In many (maybe most) = deployments, it=20 costs more to
> physically touch a WTP than the equipment = cost of=20 the WTP.
> At the Dallas IETF, there were APs that were=20 "somewhere"
> in the ceiling not doing any useful work, but=20 sending
> out beacons with their config'ed SSID because it = was=20
> too expensive to find them, and take them down. = It
> was=20 more cost effective to just new new APs.
>
> For an = AC, it's=20 clock must be accurate,
> and it would be OK for it to not = proceed=20 if it believes
> its CERTs are outside their time window. = But,=20 the
> CAPWAP protocol should allow an AC to = establish
> a=20 session with a WTP that has a WACKY clock (and
> even a CERT = that=20 has expired). NOTE: the AC clock
> must be pretty accurate = for=20 management (such as
> logs) to be useful (or work). The = CAPWAP=20 protocol has
> support to set the WTP's clock. But it = doesn't have=20 support
> to update a CERT in a WTP. It seems like this is =
>=20 needed.
>
> Assume the clocks are OK, now lets talk = about=20 WTP
> CERT validation by the AC. This wasn't addressed, = but
>=20 I believe that WTP CERTs MUST be signed by the
> WTP = manufacturer,=20 or one of the WELL KNOWN certification
> authorities. = Adding the CA=20 CERTs in an AC is done through
> means outside of CAPWAP = (such as=20 via the CLI
> on the AC). Thus, WTP CERTs MUST NOT be=20 selfsigned.
> And, I believe that the WTPs CERTs should have =
> for the common name the ASCII of MAC address,
> or = other=20 unique ID of the WTP (and this must be provided
> in the = Join=20 Request message). I didn't understand
> in the previous = text, nor in=20 your message below
> why the common name would have a = suffix=20 of
> "@DOMAIN.NET".
>
>=20 Now lets talk about AC CERT validation by the WTP.
> The = CERT for=20 the AC can be created by the AC
> manufacturer, the user, = or 3rd=20 party. It could
> be selfsigned, or have a chain from the=20 manufacturer
> or a WELL KNOWN CA. Given this, it will be=20 difficult
> for a WTP to verify a AC CERT, at least the = first=20
> time. This is just a "leap of faith" if the CERT
> = cannot=20 be verified. After this first connection,
> the AC through = the=20 CAPWAP protocol could configure
> the WTP with the needed CA = CERT(s). However, there
> may be some WTPs that have no = additional=20 persistent
> storage for these CERTs.
>
> So, it = appears=20 to me that the following changes
> are required to=20 CAPWAP-01:
>   1) specify that WTP CERTs cannot be = selfsigned,
>      and MUST = have a=20 common name of the = ASCII
>      of the=20 MAC address (or other unique=20 ID,
>      such as serial=20 number)

While we may not think self-signing is a good idea = for our=20 typical
deployment models, I'm not sure we have to say you MUST = NOT do=20 this, but
I'll give this some more = thought.

>   2)=20 The Join Request must be updated to=20 include
>      the common name = as a=20 message element

What is your objective with this=20 requirement?

>   3) specify that WTPs must = continue=20 even when it
>      believes = its CERT=20 or the AC's CERT is = outside
>      the=20 time window

Charles addressed this. =

>   4) the=20 CAPWAP protocol must have a new=20 message
>      to install an = updated=20 CERT for the WTP.
>   5) the CAPWAP protocol must = have a=20 new message
>      to install = a CA=20 CERT.

I agree that we should discuss this, but I'm a little = leary=20 of taking on
the task of fully specifying every nuance of cert = use and=20 mgmt.
Remember, the ipsec group spun out a whole new wg to = handle=20 this
particular problem. It's complicated.

What we're = trying to=20 do in the base protocol is come up with minimal and
sufficient = guidelines to get people going. I think cert mgmt and = usage
could be=20 revisited in detail later, perhaps under a new charter, = but
that we=20 might want to consciously avoid getting too bogged down in this =
for=20 rev=20 = 1.

Scott

__________________________________________________= _______________
To=20 unsubscribe or modify your subscription options, please = visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


_________________________= ________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


------_=_NextPart_001_01C6EBEC.730CB001-- --===============1408918688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1408918688==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 18:08:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3IG-0006gt-Tr for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 18:08:16 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX3IF-0001Wa-AI for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 18:08:16 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id DBC5A14480EF for ; Mon, 9 Oct 2006 15:08:11 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 16B0D430018 for ; Mon, 9 Oct 2006 15:01:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 06191398072 for ; Mon, 9 Oct 2006 15:01:42 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4F5C739805C for ; Mon, 9 Oct 2006 15:01:39 -0700 (PDT) Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX3Bp-0005Qi-U8; Mon, 09 Oct 2006 18:01:37 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Mon, 9 Oct 2006 18:01:37 -0400 Message-ID: <8440976.1160431297939.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 9 Oct 2006 18:01:37 -0400 (EDT) From: "Scott G. Kelly" To: Saravanan.Govindan@sg.panasonic.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710c1bad131b26bd38d13fba788f11833e4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: margaret@thingmagic.com, capwap@frascone.com, Hong.Cheng@sg.panasonic.com Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Saravanan, Saravanan Govindan wrote: >Hi Scott, > >I am not sure the suggestion below affects any security model. As long as >there is an established security framework between the AC and WTP, the >suggested approach remains transparent. When you consider the 'security model', you have to consider all assumptions that went into the cryptographic protocol design. Also, you need to carefully consider whether our particular deployment scenarios introduce the need for additional interpretation, since the deployment model 802.11 security has been designed around does not include splitting AP functions in two, with a potentially hostile hop in between. That is what we are doing with CAPWAP. I won't waste time here trying to speculate (or argue) about what clauses might have been worded differently had the 802.11i group been considering CAPWAP-like scenarios. Instead, let me point out just one consequence of passing the KCK to the WTP: the WTP could undetectably modify the content of message 3 of the 4-way handshake. This is bad. Without spending a lot of time thinking about why this might be a problem, we can immediately see that the WTP would be in a position to modify (downgrade) the security capabilities info it sends out, and then modify the IE in message 3 of the 4-way to match. Why would a WTP want to do this? I'm not sure, but we have to keep in mind that we are talking about interoperability here, so the WTP does not necessarily come from the same place as the AC. But the real point is that according to the security model upon which RSN security is based, _this simply should not be possible_ And I should add, I turned this up after only a cursory analysis - there may be other more significant issues. Arguably, the same could be said for the KeyRSC=0 problem, so we are in the difficult position of having to weigh these two against one another in choosing a solution. Having spent more than a few hours mulling this over, I think we are safest if we choose a solution that minimizes protocol complexity and exposure simultaneously. Now, recalling the following for the KeyRSC=0 problem: - the STA's briefly inaccurate view of the RSC (and it's resulting susceptibility to mcast/bcast replays) will be corrected upon receipt of the first valid mcast/bcast message from the WTP - that on "normal" networks we can expect more than a few of these per second (so the exposure is typically sub-second) - that an attempt to replay old frames could likely be detected - that the attacker would either be blindly replaying (outsider attack) and just *hoping* something goes wrong - or that the attacker is an insider who knows the GTK (and could therefore manufacture whatever packets he desires *within* the legal window anyway it seems to me that the window of exposre here is very small indeed. Definitely not worth potentially breaking the RSN security model over. I think that if the WTP, as part of its normal statistics messaging, transmitted per ESSID bcast/mcast counts to the AC, this represents a nice compromise. No new messages, no out of the ordinary processing, and the AC knows which GTK the stats go with, so it can narrow the window of exposure according to how current its stats are vs the xmit rate with the GTK. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 19:33:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX4ca-0000zB-0u for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 19:33:20 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX4cV-0001mQ-Gx for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 19:33:20 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by hermes.tigertech.net (Postfix) with ESMTP id B9A52144803F for ; Mon, 9 Oct 2006 16:33:07 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id DC2D4430018 for ; Mon, 9 Oct 2006 16:32:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B72B31448022 for ; Mon, 9 Oct 2006 16:32:30 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by hermes.tigertech.net (Postfix) with ESMTP id B596D144800C for ; Mon, 9 Oct 2006 16:32:28 -0700 (PDT) Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX4bj-0003cP-Rs; Mon, 09 Oct 2006 19:32:27 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Mon, 9 Oct 2006 19:32:27 -0400 Message-ID: <27418730.1160436747809.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Mon, 9 Oct 2006 19:32:27 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , "Smitha Smitha (ssmitha)" , Capwap@frascone.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7108bfce1887b9d3c81b9de54b9df6265b8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Pat, Pat Calhoun wrote: >hmmm.... this seems to be a bug. First of all, why would the WTP have to >wait prior to establishing the DTLS session? Why is this simply not >automatic? I recall wondering about this during the DTLS text integration. If I recall correctly, this was adapted from the original JOIN language, and I thought maybe there was a delay introduced in case the WTP received more discovery responses. I think the language is confusing, though, and needs work either way. Seems like the behavior varies depending on the discovery method. For a broadcast method, it seems reasonable that a WTP should wait some reasonable period to probabalistically ensure that it has received whatever discovery responses it is going to receive before it acts. Otherwise, you could have kid-in-a-candy-store behavior (I'll take that one! No -- that one! Wait... I want THAT one!) For a directed discover, obviously the WTP can act upon receiving a response. Scott > > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > > >________________________________ > > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 03, 2006 7:31 PM > To: Capwap@frascone.com > Subject: [Capwap] discovery interval timer question > > > > All, > > Idle to Discovery transition talks about Discovery Interval >timer: > > Idle to Discovery (a): This transition occurs once device > initialization is complete. > > WTP: The WTP enters the Discovery state prior to >transmitting the > first Discovery Request message (see Section 5.1). >Upon > entering this state, the WTP sets the DiscoveryInterval >timer > (see Section 4.5). The WTP resets the DiscoveryCount >counter > to zero (0) (see Section 4.6). The WTP also clears all > information from ACs it may have received during a >previous > Discovery phase. > > > But DiscoveryInterval timer is described as: > > > 4.5.1. DiscoveryInterval > > The minimum time, in seconds, that a WTP MUST wait after >receiving a > Discovery Response, before initiating a DTLS handshake. > > Should Idle to Discovery actually be based on >MaxDiscoveryInterval timer? Also, there is mention of DiscoveryInterval >timer even in transition from Discovery to Discovery. > > 4.5.6. MaxDiscoveryInterval > > The maximum time allowed between sending discovery requests >from the > interface, in seconds. Must be no less than 2 seconds and no >greater > than 180 seconds. > > Default: 20 seconds. > > Thanks > Smitha > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 21:30:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6Rt-0004uO-2z for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 21:30:25 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6Rp-0000fj-IO for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 21:30:25 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 106E6398013 for ; Mon, 9 Oct 2006 18:30:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 3A670430018 for ; Mon, 9 Oct 2006 18:28:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 00B0139802E for ; Mon, 9 Oct 2006 18:28:28 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7BBA139808C for ; Mon, 9 Oct 2006 18:28:25 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k9A1SMxp022521; Tue, 10 Oct 2006 10:28:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k9A1SNa02108; Tue, 10 Oct 2006 10:28:23 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id k9A1SMl07586; Tue, 10 Oct 2006 10:28:22 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Oct 2006 09:27:08 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013662C7@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: AcbppxXG8vlRVt+XTGCZp/uvRyEy0wBuaiJgAAQFBzAAFKYqQAARnGMA From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Cheng Hong" , "Scott G. Kelly" , "Margaret Wasserman" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Pat, The WTP does not need any additional key information since the issue at hand considers the WTP to perform crypto functions. I do not think the proposal introduces threats. Also, given CAPWAP development is still in progress, I think we should not preclude any item because it involves change - the protocol is not yet complete. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Tuesday, October 10, 2006 1:39 AM To: Saravanan Govindan; Cheng Hong; Scott G. Kelly; Margaret Wasserman Cc: capwap Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations This would require the AC to send additional keying information to the WTP, since message three needs to be authenticated. So I disagree with this proposal. The change is much more sinificant than simply leaving the field zero. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Monday, October 09, 2006 12:08 AM > To: Cheng Hong; Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Cheng Hong, Scott, > > I share your concerns for setting the KeyRSC to 0. > > In my opinion, it is clear that the protocol is "broken" in > this case and needs to be fixed. > > My suggestion is to have the KeyRSC field be updated by the > WTP. So the AC could send Message-3 of the 4-way handshake to > the WTP with an empty KeyRSC field. The WTP could then > correctly update the field, compute the KeyMIC, update > Message-3 and then forward it to the STA. > > Of course, this requires a CAPWAP message from the AC and WTP > to exchange the incomplete Message-3. I think this is an > acceptable addition because it maintains the integrity of > 802.11i exchanges and provides a complete fix to the problem. > > Saravanan > > > > > > -----Original Message----- > From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] > Sent: Monday, October 09, 2006 1:21 PM > To: Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi Scott, > > Some comments below: > > > After thinking long and hard about this, I can't bring > myself to agree > > with the suggested text. Quite frankly, I think always using an RSC > > value of 0 is a lazy hack, and given that we've acknowledged we are > > introducing a vulnerability here (however slight), telling > > implementors they SHOULD do this just doesn't sit right with me. > > > > An enlightened implementation could almost certainly do better than > > always setting this to zero, and explicitly recommending > that people > > nail this window open just rubs me the wrong way. At least, > let's hold > > off on this decision until we've clearly defined what statistics we > > expect to be available. Seems like if we're going to tell > implementors > > what they SHOULD do, we SHOULD give them sound, well considered > > advice. > > I absolutely agree with you on this point. > > What I was trying to state in my previous emails was: > - I would against setting a static value for the KeyRSC as a > solution to this issue. > - However if the WG decided to go for a static value, the > draft should clearly point out that NOT all static value > could work (value other than zero may be a problem for > interoperability). > - And the draft needs to clearly point out what is the danger > of setting a static KeyRSC value in the security > consideration section. > - Also, the draft should not prohibit other implementation > for sync the KeyRSC value between WTP and AC (the CAPWAP > standard should not dictate such implementation incompatible). > > If there is a alternative solution than setting a static > KeyRSC value to narrow the window, I would vote for it. > > cheers > > Cheng Hong > > > > > -----Original Message----- > > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > > Sent: Saturday, October 07, 2006 8:26 AM > > To: Margaret Wasserman > > Cc: capwap > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > Hi Margaret, > > > > Comments inline below... > > > > -----Original Message----- > > >From: Margaret Wasserman > > >Sent: Oct 6, 2006 9:39 AM > > >To: Scott G Kelly > > >Cc: Cheng Hong , capwap > > > > > >Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > > Considerations > > > > > > > > >While I am not against leaving things open to more optimal > > >implementations, I do think that we need to add some text to the > > >protocol portion of the document (as well as the security > > >considerations) to explain how this is handled. How about > something > > >like: > > > > > >The AC SHOULD use an RSC of 0 when computing message-3 of > the 4-way > > >802.11i handshake, unless the AC has knowledge of a more > optimal RSC > > >value to use. Mechanisms for determining a more optimal RSC > > value are > > >outside the scope of this specification. > > > > > >I do not think that we should simply say nothing and hope that > > >implementors figure this out. > > > > > >Margaret > > > > After thinking long and hard about this, I can't bring > myself to agree > > with the suggested text. Quite frankly, I think always using an RSC > > value of 0 is a lazy hack, and given that we've acknowledged we are > > introducing a vulnerability here (however slight), telling > > implementors they SHOULD do this just doesn't sit right with me. > > > > An enlightened implementation could almost certainly do better than > > always setting this to zero, and explicitly recommending > that people > > nail this window open just rubs me the wrong way. At least, > let's hold > > off on this decision until we've clearly defined what statistics we > > expect to be available. Seems like if we're going to tell > implementors > > what they SHOULD do, we SHOULD give them sound, well considered > > advice. > > > > Scott > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 22:19:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX7DK-0003rg-4I for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 22:19:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX7DG-0007aH-EE for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 22:19:26 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBF2539804C for ; Mon, 9 Oct 2006 19:19:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 45FCC430018 for ; Mon, 9 Oct 2006 19:18:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3260A39802E for ; Mon, 9 Oct 2006 19:18:28 -0700 (PDT) Received: from rwcrmhc15.comcast.net (rwcrmhc15.comcast.net [204.127.192.85]) by zoidberg.tigertech.net (Postfix) with ESMTP id 38CB939804C for ; Mon, 9 Oct 2006 19:18:26 -0700 (PDT) Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc15) with ESMTP id <20061010021824m15009fkope>; Tue, 10 Oct 2006 02:18:25 +0000 Message-ID: <452B02F1.4090308@cs.umd.edu> Date: Mon, 09 Oct 2006 22:18:25 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Saravanan Govindan References: <5F09D220B62F79418461A978CA0921BD013662C7@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD013662C7@pslexc01.psl.local> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Margaret Wasserman , capwap , Cheng Hong Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Saravanan, Your proposal requires the WTP to know the KCK to compute the MIC. In both Split MAC and Local MAC, the 4-way handshake is executed between the AC and STA (hence the whole problem we're talking about). After the handshake is complete, the PTK is transmitted to the WTP. Currently there is no way for the WTP to know the KCK in any of the possible usage scenarios. Key derivation process: EAP MSK = 11i PMK (transported from AAA server to AC after successful EAP authentication) First two messages of 4-way handshake occurs between AC and STA and both the AC and STA now know SNonce, ANonce, SAddr, AAddr. (KEK, KCK, PTK) = TK = KDF(PMK, SNonce, ANonce, SAddr, AAddr) AC and STA now know KEK, KCK, PTK. AC and STA use KCK to properly MIC messages 3 and 4 of handshake If 11i is terminated at the WTP, the AC then transports the PTK to WTP. At no point, and in no scenario, does the KCK currently get transported to the WTP. An additional message would have to be inserted between messages 2 and 3 of the 4-way handshake to inform the WTP of the KCK. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Saravanan Govindan wrote: > Pat, > > The WTP does not need any additional key information since the issue at > hand considers the WTP to perform crypto functions. I do not think the > proposal introduces threats. > > Also, given CAPWAP development is still in progress, I think we should > not preclude any item because it involves change - the protocol is not > yet complete. > > Saravanan > > > > > > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, October 10, 2006 1:39 AM > To: Saravanan Govindan; Cheng Hong; Scott G. Kelly; Margaret Wasserman > Cc: capwap > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations > > This would require the AC to send additional keying information to the > WTP, since message three needs to be authenticated. So I disagree with > this proposal. The change is much more sinificant than simply leaving > the field zero. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] >> Sent: Monday, October 09, 2006 12:08 AM >> To: Cheng Hong; Scott G. Kelly; Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Cheng Hong, Scott, >> >> I share your concerns for setting the KeyRSC to 0. >> >> In my opinion, it is clear that the protocol is "broken" in >> this case and needs to be fixed. >> >> My suggestion is to have the KeyRSC field be updated by the >> WTP. So the AC could send Message-3 of the 4-way handshake to >> the WTP with an empty KeyRSC field. The WTP could then >> correctly update the field, compute the KeyMIC, update >> Message-3 and then forward it to the STA. >> >> Of course, this requires a CAPWAP message from the AC and WTP >> to exchange the incomplete Message-3. I think this is an >> acceptable addition because it maintains the integrity of >> 802.11i exchanges and provides a complete fix to the problem. >> >> Saravanan >> >> >> >> >> >> -----Original Message----- >> From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com] >> Sent: Monday, October 09, 2006 1:21 PM >> To: Scott G. Kelly; Margaret Wasserman >> Cc: capwap >> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >> Considerations >> >> Hi Scott, >> >> Some comments below: >> >>> After thinking long and hard about this, I can't bring >> myself to agree >>> with the suggested text. Quite frankly, I think always using an RSC >>> value of 0 is a lazy hack, and given that we've acknowledged we are >>> introducing a vulnerability here (however slight), telling >>> implementors they SHOULD do this just doesn't sit right with me. >>> >>> An enlightened implementation could almost certainly do better than >>> always setting this to zero, and explicitly recommending >> that people >>> nail this window open just rubs me the wrong way. At least, >> let's hold >>> off on this decision until we've clearly defined what statistics we >>> expect to be available. Seems like if we're going to tell >> implementors >>> what they SHOULD do, we SHOULD give them sound, well considered >>> advice. >> I absolutely agree with you on this point. >> >> What I was trying to state in my previous emails was: >> - I would against setting a static value for the KeyRSC as a >> solution to this issue. >> - However if the WG decided to go for a static value, the >> draft should clearly point out that NOT all static value >> could work (value other than zero may be a problem for >> interoperability). >> - And the draft needs to clearly point out what is the danger >> of setting a static KeyRSC value in the security >> consideration section. >> - Also, the draft should not prohibit other implementation >> for sync the KeyRSC value between WTP and AC (the CAPWAP >> standard should not dictate such implementation incompatible). >> >> If there is a alternative solution than setting a static >> KeyRSC value to narrow the window, I would vote for it. >> >> cheers >> >> Cheng Hong >> >> >> >>> -----Original Message----- >>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >>> Sent: Saturday, October 07, 2006 8:26 AM >>> To: Margaret Wasserman >>> Cc: capwap >>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>> >>> Hi Margaret, >>> >>> Comments inline below... >>> >>> -----Original Message----- >>>> From: Margaret Wasserman >>>> Sent: Oct 6, 2006 9:39 AM >>>> To: Scott G Kelly >>>> Cc: Cheng Hong , capwap >>>> >>>> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i >>> Considerations >>>> >>>> While I am not against leaving things open to more optimal >>>> implementations, I do think that we need to add some text to the >>>> protocol portion of the document (as well as the security >>>> considerations) to explain how this is handled. How about >> something >>>> like: >>>> >>>> The AC SHOULD use an RSC of 0 when computing message-3 of >> the 4-way >>>> 802.11i handshake, unless the AC has knowledge of a more >> optimal RSC >>>> value to use. Mechanisms for determining a more optimal RSC >>> value are >>>> outside the scope of this specification. >>>> >>>> I do not think that we should simply say nothing and hope that >>>> implementors figure this out. >>>> >>>> Margaret >>> After thinking long and hard about this, I can't bring >> myself to agree >>> with the suggested text. Quite frankly, I think always using an RSC >>> value of 0 is a lazy hack, and given that we've acknowledged we are >>> introducing a vulnerability here (however slight), telling >>> implementors they SHOULD do this just doesn't sit right with me. >>> >>> An enlightened implementation could almost certainly do better than >>> always setting this to zero, and explicitly recommending >> that people >>> nail this window open just rubs me the wrong way. At least, >> let's hold >>> off on this decision until we've clearly defined what statistics we >>> expect to be available. Seems like if we're going to tell >> implementors >>> what they SHOULD do, we SHOULD give them sound, well considered >>> advice. >>> >>> Scott >>> >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 22:23:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX7H5-00053Q-R6 for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 22:23:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX7H3-0008JW-Gp for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 22:23:19 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB37E398084 for ; Mon, 9 Oct 2006 19:23:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id 72941430018 for ; Mon, 9 Oct 2006 19:21:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 50E7039804C for ; Mon, 9 Oct 2006 19:21:27 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id C9343398017 for ; Mon, 9 Oct 2006 19:21:25 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id k9A2LNEB026773; Tue, 10 Oct 2006 11:21:23 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k9A2LLa01186; Tue, 10 Oct 2006 11:21:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with ESMTP id k9A2LHd11069; Tue, 10 Oct 2006 11:21:18 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Oct 2006 10:20:10 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0136630C@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames Thread-Index: AcbieUNFx2Heibn8RoyIXIp63oas0QAIb/jgAkkkjMAAFDCDYA== From: "Cheng Hong" To: "Pat Calhoun (pacalhou)" , "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.452 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_60_70, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1062068395==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cc961b79af8d22f2640d5180a0dbc035 This is a multi-part message in MIME format. --===============1062068395== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EC12.9D34E136" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EC12.9D34E136 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 You are right. So, it seems that 802.1X frame may not even always have higher priority over wireless link. =20 Another concern I have is about the CAPWAP QoS preservation. It seems that for the HCCA case, CAPWAP may not be able to guarantee the same QoS over the wired section for the STA.=20 =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Tuesday, October 10, 2006 1:42 AM To: Cheng Hong; Michael Montemurro Cc: capwap Subject: RE: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames Even in the case of EDCA, there is no guarantees that the STA can send an 802.1X frame with a high priority UP field. This is especially true if the WTP requires authorization prior to making use of the QoS class. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Cheng Hong [mailto:Hong.Cheng@sg.panasonic.com]=20 Sent: Wednesday, September 27, 2006 6:20 PM To: Michael Montemurro Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue214-Prioritization of IEEE 802.1X frames Hi Mike, =20 In the HCCA case, the TID value is in the range of 8 to 15, and according to clause 6.1.1.1.1 point b: =20 "b) QoS subtypes, in which case the QAP shall infer the UP value from the TID in the QoS Control field directly for TID values between 0 and 7. For TID values between 8 and 15, the QAP shall extract the UP value in the UP subfield of the TS Info field in the associated TSPEC or from the UP field in the associated TCLAS (traffic classification) element, as applicable." =20 It seems that the WTP needs to do much more to obtain the actual UP value. In case the TSPEC or TCLAS elemets are located at the AC, how would the WTP get the UP value in the HCCA case? =20 Or is there any place that prevents sending EAPOL frames using HCCA? If that is the case, it is not a problem. But, then again, all the data traffic sent using HCCA will have difficulty to obtain the correct priority in CAPWAP delivery. =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Thursday, September 28, 2006 2:23 AM To: Cheng Hong Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214-Prioritization of IEEE 802.1X frames Cheng, =20 In the HCCA case, the TID case should work as well. I don't see why it wouldn't. =20 Cheers, =20 Mike =20 On 9/26/06, Cheng Hong wrote:=20 Hi Mike,=20 =20 It seems OK to use TID in the EDCA case. If the HCCA is used, would the TID still be meaningful in mapping the priority? (Haven't check the 802.11 standards in detail).=20 =20 cheers =20 Cheng Hong=20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Wednesday, September 27, 2006 12:24 AM=20 To: Cheng Hong Cc: zhaoyujin 31390; capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =20 Cheng, =20 Thanks for you input. =20 Also, that's a good question. In my opinion, the CAPWAP priority should be based on the TID(UP). Which means yes, the WTP would need to read into the QoS control field. =20 Cheers, =20 Mike =20 On 9/25/06, Cheng Hong > wrote:=20 Hi Mike, =20 In this case, I tend to agree with the other Michael on the first point. =20 However, on the mapping 802.11e priority back to CAPWAP priority, I am not really sure how that is done. Is it based on 802.11e AC or TID (UP)? For later case, does it mean the WTP need to read into the QoS Control Field?=20 =20 cheers =20 Cheng Hong =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com ]=20 Sent: Tuesday, September 26, 2006 1:17 AM To: Cheng Hong Cc: zhaoyujin 31390; capwap=20 Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames =20 Cheng Hong, =20 In the CAPWAP draft, both wireless data and management frames are treated as CAPWAP data frames. Given that, all CAPWAP data traffic would need to go to the same logical instance of the AC. =20 Cheers, =20 Mike =20 On 9/24/06, Cheng Hong > wrote:=20 Hi Michael & Michael, =20 Sorry if the issue has already been discussed before. Just thinking if the WTP does not differentiate 802.1X frames from normal data frames, would it be possible that the 802.1X frames being forwarded to a different AC instance than the one processing the control/management frames? (in case different ACs are used to process the control and data channel) Is this acceptable? =20 cheers =20 Cheng Hong =20 =20 =20 _____ =20 From: Michael Montemurro [mailto:montemurro.michael@gmail.com]=20 Sent: Sunday, September 24, 2006 3:18 AM To: zhaoyujin 31390 Cc: capwap Subject: Re: [Capwap] This is not need.: Proposed resolution to Issue 214 -Prioritization of IEEE 802.1X frames=20 =20 Michael, =20 Thanks. Is anybody else opinionated on this feature.=20 =20 Cheers, =20 Mike =20 On 9/23/06, zhaoyujin 31390 > wrote:=20 Firstly, I have some doubt one this suggestion. 1. If CAPWAP difines like this, AP device must decode the payload frames of 802.11 frames. 2. Another problem, the 802.1x priority should be implement by 802.11e. When station sends 802.11 data frames, it can set 802.11e priority. AP should transfer 802.11e to actual CAPWAP packet priority. So that I think CAPWAP does not need consider the priority of 802.11 data frames payload.=20 Thanks Michael >Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as >IEEE 802.11 Management frames. > >I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages >to "Quality >of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to >indicate that IEEE 802.1X frames are sent at a higher priority. >=20 >Cheers, > >Mike This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email=20 immediately and delete it! =20 Practically speaking, IEEE 802.1X frames should be transmitted at the same priority as IEEE 802.11 Management frames.=20 =20 I will update Section 11.5, rename Quality of Service for IEEE 802.11 Control Messages to "Quality of Service for IEEE 802.11 control messages and IEEE 802.1X EAPoL frames" and add text to indicate that IEEE 802.1X frames are sent at a higher priority. =20 Cheers, =20 Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap =20 ------_=_NextPart_001_01C6EC12.9D34E136 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Pat,
 
You=20 are right. So, it seems that 802.1X frame may not  even always have = higher=20 priority over wireless link.
 
Another concern I have is about the CAPWAP QoS preservation. It = seems=20 that for the HCCA case, CAPWAP may not be able to guarantee the same QoS = over=20 the wired section for the STA.
 
cheers
 
Cheng=20 Hong
 
 
 

From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Tuesday, October 10, 2006 = 1:42=20 AM
To: Cheng Hong; Michael Montemurro
Cc:=20 capwap
Subject: RE: [Capwap] This is not need.: Proposed = resolution=20 to Issue214-Prioritization of IEEE 802.1X frames

Even=20 in the case of EDCA, there is no guarantees that the STA can send an = 802.1X=20 frame with a high priority UP field. This is especially true if the = WTP=20 requires authorization prior to making use of the QoS=20 class.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Cheng Hong=20 [mailto:Hong.Cheng@sg.panasonic.com]
Sent: Wednesday, = September=20 27, 2006 6:20 PM
To: Michael Montemurro
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed=20 resolution to Issue214-Prioritization of IEEE 802.1X=20 frames

Hi=20 Mike,
 
In=20 the HCCA case, the TID value is in the range of 8 to 15, and = according to=20 clause 6.1.1.1.1 point b:
 
"b) QoS = subtypes, in=20 which case the QAP shall infer the UP value from the TID in the QoS = Control=20 field
directly=20 for TID values between 0 and 7. For TID values between 8 and 15, the = QAP=20 shall extract the
UP value=20 in the UP subfield of the TS Info field in the associated TSPEC or = from the=20 UP field in the
associated TCLAS (traffic classification) element, = as=20 applicable."
&nbs= p;
It seems that the WTP needs to do much = more to=20 obtain the actual UP value. In case the TSPEC or TCLAS elemets are = located=20 at the AC, how would the WTP get the UP value in the HCCA=20 case?
&nbs= p;
Or is there any place that prevents = sending EAPOL=20 frames using HCCA? If that is the case, it is not a problem. But, = then=20 again, all the data traffic sent using HCCA will have difficulty to = obtain=20 the correct priority in CAPWAP=20 delivery.
&nbs= p;
cheers
&nbs= p;
Cheng Hong
&nbs= p;
 
 

From: Michael Montemurro=20 [mailto:montemurro.michael@gmail.com]
Sent: Thursday, = September=20 28, 2006 2:23 AM
To: Cheng Hong
Cc:=20 capwap
Subject: Re: [Capwap] This is not need.: Proposed = resolution to Issue 214-Prioritization of IEEE 802.1X=20 frames

Cheng,
 
In the HCCA case, the TID case should work as well. I don't = see why=20 it wouldn't.
 
Cheers,
 
Mike

 
On 9/26/06, Cheng=20 Hong <Hong.Cheng@sg.panasonic.com>=20 wrote:=20
Hi Mike,=20
 
It seems = OK to use TID=20 in the EDCA case. If the HCCA is used, would the TID still be = meaningful=20 in mapping the priority? (Haven't check the 802.11 standards in = detail).=20
 
cheers
 
Cheng = Hong=20

From: = Michael Montemurro=20 [mailto:montemurro.michael@gmail.com ]=20
Sent: Wednesday, September 27, 2006 12:24 AM =

To: = Cheng=20 Hong
Cc: zhaoyujin 31390; capwap
Subject: = Re:=20 [Capwap] This is not need.: Proposed resolution to Issue 214=20 -Prioritization of IEEE 802.1X=20 frames

 
Cheng,
 
Thanks for you input.
 
Also, that's a good question. In my opinion, the CAPWAP = priority=20 should be based on the TID(UP). Which means yes, the WTP = would=20 need to read into the QoS control field.
 
Cheers,
 
Mike
 
On 9/25/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > = wrote:=20
Hi=20 Mike,
 
In = this case, I=20 tend to agree with the other Michael on the first point.=20
 
However, on the=20 mapping 802.11e priority back to CAPWAP priority, I am = not=20 really sure how that is done. Is it based on 802.11e AC or = TID (UP)?=20 For later case, does it mean the WTP need to read into the = QoS=20 Control Field?
 
cheers
 
Cheng = Hong
 
 
From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com ]=20
Sent: Tuesday, September 26, 2006 1:17=20 AM
To: Cheng Hong
Cc: zhaoyujin 31390; = capwap=20

Subject: Re: [Capwap] This is not = need.:=20 Proposed resolution to Issue 214 -Prioritization of IEEE = 802.1X=20 frames

 
Cheng Hong,
 
In the CAPWAP draft, both wireless data and = management frames=20 are treated as CAPWAP data frames. Given that,=20 all CAPWAP data traffic would need to go to the same = logical=20 instance of the AC.
 
Cheers,
 
Mike


 
On 9/24/06, Cheng Hong <Hong.Cheng@sg.panasonic.com > = wrote:=20
Hi Michael=20 & Michael,
 
Sorry if the=20 issue has already been discussed before. Just thinking = if the=20 WTP does not differentiate 802.1X frames from normal = data=20 frames, would it be possible that the 802.1X frames = being=20 forwarded to a different AC instance than the one = processing the=20 control/management frames? (in case different ACs are = used to=20 process the control and data channel) Is this=20 acceptable?
 
cheers
 
Cheng=20 Hong
 
 
 

From: Michael = Montemurro=20 [mailto:montemurro.michael@gmail.com]=20
Sent: Sunday, September 24, 2006 3:18=20 AM
To: zhaoyujin 31390
Cc:=20 capwap
Subject: Re: [Capwap] This is not = need.:=20 Proposed resolution to Issue 214 -Prioritization of = IEEE=20 802.1X frames

 
Michael,
 
Thanks. Is anybody else opinionated on this = feature.=20
 
Cheers,
 
Mike

 
On 9/23/06, zhaoyujin 31390 <zhaoyujin@huawei.com > = wrote:=20
Firstly, I have some = doubt one=20 this suggestion.

1. If CAPWAP difines like = this, AP=20 device must decode the payload frames of 802.11=20 frames.
2. Another problem, the 802.1x priority = should be=20 implement by 802.11e. When station sends 802.11 data = frames,=20 it can set 802.11e priority. AP should transfer = 802.11e to=20 actual CAPWAP packet priority.

So that I = think CAPWAP=20 does not need consider the priority of 802.11 data = frames=20 payload.=20 =

Thanks
Michael



>Practically=20 speaking, IEEE 802.1X frames should be transmitted = at the=20 same priority as >IEEE 802.11 Management=20 frames.
>
>I will update Section 11.5, = rename=20 Quality of Service for IEEE 802.11 Control Messages = >to=20 "Quality
>of Service for IEEE 802.11 control = messages=20 and IEEE 802.1X EAPoL frames" and add text to = >indicate=20 that IEEE 802.1X frames are sent at a higher=20 priority.
>=20
>Cheers,
>
>Mike


This = e-mail=20 and attachments contain confidential information = from=20 HUAWEI, which is intended only for the person or = entity=20 whose address is listed above. Any use of the = information=20 contained herein in any way (including, but not = limited to,=20 total or partial disclosure, reproduction, or = dissemination)=20 by persons other than the intended recipient's) is=20 prohibited. If you receive this e-mail in error, = please=20 notify the sender by phone or email
immediately = and=20 delete it!

 

Practically speaking, IEEE 802.1X frames should = be=20 transmitted at the same priority as IEEE 802.11 = Management=20 frames.
 
I will update Section 11.5, rename Quality of = Service=20 for IEEE 802.11 Control Messages to "Quality
of = Service=20 for IEEE 802.11 control messages and IEEE 802.1X = EAPoL=20 frames" and add text to indicate that IEEE 802.1X = frames are=20 sent at a higher priority.
 
Cheers,
 
=
Mike

______________________________________________________= ___________
To=20 unsubscribe or modify your subscription options, = please=20 visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =




<= BR>

------_=_NextPart_001_01C6EC12.9D34E136-- --===============1062068395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1062068395==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 09 23:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX7wY-0008TK-TH for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 23:06:10 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX7wW-0005i9-Eo for capwap-archive@lists.ietf.org; Mon, 09 Oct 2006 23:06:10 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E332398055 for ; Mon, 9 Oct 2006 20:06:05 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 932F9430018 for ; Mon, 9 Oct 2006 20:05:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6B74B1448014 for ; Mon, 9 Oct 2006 20:05:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 6606C1448016 for ; Mon, 9 Oct 2006 20:05:01 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2006 20:05:01 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9A350t3021141; Mon, 9 Oct 2006 20:05:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9A350Ao005454; Mon, 9 Oct 2006 20:05:00 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 20:05:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Oct 2006 20:04:59 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2029E8C3E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] discovery interval timer question Thread-Index: Acbr+y++yS6Ll74aTSaLJfYo3b5kBQAHaC/A From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Smitha Smitha (ssmitha)" , X-OriginalArrivalTime: 10 Oct 2006 03:05:00.0623 (UTC) FILETIME=[DFE365F0:01C6EC18] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > Seems like the behavior varies depending on the discovery > method. For a broadcast method, it seems reasonable that a > WTP should wait some reasonable period to probabalistically > ensure that it has received whatever discovery responses it > is going to receive before it acts. Otherwise, you could have > kid-in-a-candy-store behavior (I'll take that one! No -- that > one! Wait... I want THAT one!) For a directed discover, > obviously the WTP can act upon receiving a response. sure, but that seems like a logical "implementation specific" condition. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 10 06:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXFH9-0005zp-I2 for capwap-archive@lists.ietf.org; Tue, 10 Oct 2006 06:55:55 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXF2j-0007qK-OZ for capwap-archive@lists.ietf.org; Tue, 10 Oct 2006 06:41:06 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D49D539805F for ; Tue, 10 Oct 2006 03:41:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by leela.tigertech.net (Postfix) with ESMTP id DDD044300EA for ; Tue, 10 Oct 2006 03:40:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D066D39802D for ; Tue, 10 Oct 2006 03:40:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0F91398029 for ; Tue, 10 Oct 2006 03:40:30 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2006 03:40:30 -0700 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9AAeTcq019197; Tue, 10 Oct 2006 03:40:30 -0700 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9AAeGB3008077; Tue, 10 Oct 2006 10:40:21 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 16:10:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Oct 2006 16:10:17 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01EFFAD0@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] discovery interval timer question Thread-Index: Acbr+y++yS6Ll74aTSaLJfYo3b5kBQAHaC/AAA7f0mA= From: "Smitha Smitha (ssmitha)" To: "Pat Calhoun (pacalhou)" , "Scott G. Kelly" , X-OriginalArrivalTime: 10 Oct 2006 10:40:17.0839 (UTC) FILETIME=[7A37C3F0:01C6EC58] Authentication-Results: sj-dkim-2.cisco.com; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 So, MaxDiscoveryInterval is not specific to an AC, in that it is a global timer which decides how frequently we send out Discovery Requests. But "DiscoveryCount" talks about the maximum # of discoveries transmitted by the WTP to an AC. Also, the spec says: " A WTP MUST send no more than the maximum of MaxDiscoveries Discovery Request messages, waiting for a random delay less than MaxDiscoveryInterval between each successive message." Is it OK to assume that: 1. DiscoveryInterval timer is the delay between successive discovery requests sent to the same AC? 2. DiscoveryCount will be obtained based on DiscoveryInterval timer (when the same expires). 3. MaxDiscoveryInterval - why is this needed? 4. Transition from Discovery to Sulking state occurs when DiscoveryCount reaches the max limit - for a particular AC? However, this does not cover the case of being able to "select" from a set of discovery responses obtained at the WTP. Thanks Smitha -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, October 10, 2006 8:35 AM To: Scott G. Kelly; Smitha Smitha (ssmitha); Capwap@frascone.com Subject: RE: [Capwap] discovery interval timer question > Seems like the behavior varies depending on the discovery method. For > a broadcast method, it seems reasonable that a WTP should wait some > reasonable period to probabalistically ensure that it has received > whatever discovery responses it is going to receive before it acts. > Otherwise, you could have kid-in-a-candy-store behavior (I'll take > that one! No -- that one! Wait... I want THAT one!) For a directed > discover, obviously the WTP can act upon receiving a response. sure, but that seems like a logical "implementation specific" condition. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 10 10:56:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXJ23-0001XH-D9 for capwap-archive@lists.ietf.org; Tue, 10 Oct 2006 10:56:35 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXJ1x-0005YA-Tm for capwap-archive@lists.ietf.org; Tue, 10 Oct 2006 10:56:35 -0400 Received: from leela.tigertech.net (leela-mail.tigertech.net [64.62.209.33]) by zoidberg.tigertech.net (Postfix) with ESMTP id D93BB39807D for ; Tue, 10 Oct 2006 07:56:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by leela.tigertech.net (Postfix) with ESMTP id 8298A4300EA for ; Tue, 10 Oct 2006 07:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6CCA21448027 for ; Tue, 10 Oct 2006 07:55:43 -0700 (PDT) X-Greylist-Status: Sender first seen 19 days 06:08:34 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 570D6144800C for ; Tue, 10 Oct 2006 07:55:39 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1368796; Tue, 10 Oct 2006 10:55:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <2A669DF3-0222-46CC-B9B6-541CCF87A1C6@thingmagic.com> From: Margaret Wasserman Date: Tue, 10 Oct 2006 10:53:41 -0400 To: capwap X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Subject: [Capwap] LACK OF CONSENSUS: 2-port/mux issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi All, Over the past few months, we have had an open issue in the CAPWAP WG that we refer to as the "2-port/mux issue". The current CAPWAP protocol specification indicates that the CAPWAP protocol will run over two UDP ports, one for control traffic and one for data traffic. Proposals have been made to move to a single-port approach or to allow for a single-port option. There has been much discussion of this issue, including e-mail discussion and presentations at WG meetings. We have consulted with the IESG, and the outcome of those discussions has been sent to the group. At this point, we believe that every interested party has had an opportunity to present technical facts in support of his/her position, and we believe that the WG is aware of the technical differences between the two approaches. So, it is time to determine the resolution of this issue. The WG chairs have reviewed the status of this issue, and we have found that the WG does not have consensus to modify the demultiplexing mechanism described in the current CAPWAP specification, either to move to a single-port approach or to add a single-port option. Therefore, in the absence of any new technical information, we are closing this discussion. Editors, please close this issue in the issue tracker with a resolution indicating that there is no WG consensus to make this change. We realize that this has been a contentious issue for the WG, and that some people may be dissatisfied with this resolution. We all would have preferred our technical discussions to converge on a single correct choice, but that hasn't happened. In this case, it is possible to build a viable CAPWAP protocol using either approach, and both approaches have advantages and disadvantages that are weighed differently by different parties. Unless new technical information comes to light, we do not believe that continued discussion of this issue will lead to consensus on the technical superiority of either approach. The WG chairs have reviewed the history of this issue to determine how to move forward, given that our technical discussions have not converged. The two-port approach was part of the original LWAPP specification, and It was also included in the -00 version of the CAPWAP specification that was accepted as a WG work item in early 2006. There was WG consensus to accept LWAPP as the basis of the CAPWAP specification, therefore the WG chairs believe that WG consensus would be required to change the demultiplexing mechanism. Despite lengthy discussion, the WG has not reached consensus to do that. We would like to thank everyone who has participated in this discussion. We hope that we will be able to put this issue behind us and continue to work together towards a well-defined and widely- deployed CAPWAP specification. Best Regards, Dorothy Gellert, Mahalingam Mani & Margaret Wasserman The CAPWAP WG Co-Chairs _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From daithitolman@brookdaleplastics.com Tue Oct 10 15:29:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNHu-0003JY-IW for capwap-archive@ietf.org; Tue, 10 Oct 2006 15:29:14 -0400 Received: from arouen-151-1-29-180.w86-208.abo.wanadoo.fr ([86.208.76.180] helo=brookdaleplastics.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXNHt-00058R-1w for capwap-archive@ietf.org; Tue, 10 Oct 2006 15:29:14 -0400 Message-ID: <000001c6eca2$2b11c600$6972a8c0@causs> Reply-To: "Charlene Dresser" From: "Charlene Dresser" To: capwap-archive@ietf.org Subject: Re: VAGRA Date: Tue, 10 Oct 2006 12:27:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EC67.7EB2EE00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EC67.7EB2EE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VAGRA - save 70% http://www.verindefunhasetrionde.com _____ =20 No. Medical teams are stationed there in the hospital inside the into view, a blown-up image really. He pointed at us. ------=_NextPart_000_0001_01C6EC67.7EB2EE00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VAGRA - save 70% http://www.verindefunhasetr= ionde.com

No. Medical teams are stationed there in the hospital inside = the
into view, a blown-up image really. He pointed at = us.
------=_NextPart_000_0001_01C6EC67.7EB2EE00-- From gdhezbmx@werbach.com Wed Oct 11 03:06:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYAm-0000Ze-7w for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 03:06:36 -0400 Received: from [61.161.76.244] (helo=[61.161.76.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXYAi-0005WO-Mk for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 03:06:36 -0400 Message-ID: <001201c6eceb$bc7b1350$f44ca13d@jf> From: "like me." To: capwap-archive@lists.ietf.org Subject: Tuesday Day History Date: Wed, 11 Oct 2006 12:14:25 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6ED2E.CA9CCCB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 ------=_NextPart_000_000E_01C6ED2E.CA9CCCB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6ED2E.CA9E5350" ------=_NextPart_001_000F_01C6ED2E.CA9E5350 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Ktck Also ability listen am. Resource Tariq of Raja Bell is Cedric. Morning Show Losin it Hastert? Versatile used itself Related gtgt Hometable Contents Console Info Rate. Wrote compiled also hassome links related pages This pure dont any =20 pictures or for in. Stores Songs Plays hrs is. Library Fall Exhibit at Motorists. Never am looked better or ps love of these posts. Broadcast sports mostly of shows Local weekdays is Newy Scruggs Randy =20 Galloway shows Donn Friday pregame postgame? Won Lost Opponent Regular Season in Record of Opponents Last Preseason. Below see a what other cities is check view overall project future =20 close? And such big of eyes! Will of off. Up Posted by steven. Section. Pains in knees didnot is play. Today is Fort Worth am Star or. Records topgame. Comus xxl or Roadcomu ------=_NextPart_001_000F_01C6ED2E.CA9E5350 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Ktck Also ability listen = am.
Resource Tariq of=20 Raja Bell is Cedric.
Morning Show Losin it Hastert?
Versatile used = itself=20 Related gtgt Hometable Contents Console Info Rate.
3D""
Wrote compiled also hassome links = related pages=20 This pure dont any pictures or for in.
Stores Songs Plays hrs = is.
Library=20 Fall Exhibit at Motorists.
Never am looked better or ps love of these = posts.
Broadcast sports mostly of shows Local weekdays is Newy = Scruggs Randy=20 Galloway shows Donn Friday pregame postgame?
Won Lost Opponent = Regular Season=20 in Record of Opponents Last Preseason.
Below see a what other cities = is check=20 view overall project future close?
And such big of eyes!
Will of=20 off.
Up Posted by steven.
Section.
Pains in knees didnot is=20 play.
Today is Fort Worth am Star or.
Records topgame.
Comus = xxl or=20 Roadcomus ski.
------=_NextPart_001_000F_01C6ED2E.CA9E5350-- ------=_NextPart_000_000E_01C6ED2E.CA9CCCB0 Content-Type: image/gif; name="RoadCOMUS.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6eceb$bc798cb0$f44ca13d@jf> R0lGODlhTAFMAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAASAAAALAAAAABMAUwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEnTopea OHNu7KKzp8+fQIMKHUq06MUVRpMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sFZshhMrXsy4sePHLUdAnky5suXK kS5r3sy5s+fPoEM7XSe6tEfSplOrXs26NdBNrmPLnk27tu3buHOHxqK7t2/LjH4LH068uPHj UxMgX858uIHm0KNLn069uvXr2LNr384VEXfI3r/+Ow4vnjH58orPozesfj3h9u7jy1/Lab79 +/jz69/Pv7///wBuFkaABBZo4IEIJqjgggw2GFoLDkYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaCJlLqiUy4kstujiizDGKONkOcxo440xHqMahDj26ONT1fwoJIakDGnkkUgmqeSSTI7Y RJM9PQllTlKChMaUFFUZ0pVYQqSlSGhw2eVCX47poB9mFlVfmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABhojJoIWauihiCaq6KKMNuroo5BGKilIA4LEwKSYZqrppj6xwWmStHx6UKii GkRqqQSdiqpAqq7q6qv/sMYqq1vWzGrrrbjmquuuvPZq2w2+Bivsi3MMa+yxyCar7GqxLGvi Ac5GK62My0xr7bXYZqvtttx26+234IYr7rjklmvuueimq+667Lbr7rsf1gPvvPTWa++9+Oar 77789uvvvwDbtwOFmeX1QcCJFhCrwhqpUijDGTksKMQXSTxxw4ZSXJHFF2PEcaAaT/QxyCFH NDLCKN/qTcq61lEUj3Cyw/LMNB8EH6c3b5qzpjtn2jOmP08aNIcOUDV0zSyV+anS1aXyGNOb Qq2p1JlSjeQ4Mlk9qdZId72dL16HLfbYZJftr6dmp622X32s7fbbcMct99x012333SWOgvfe DHwPBECmT/QtOF0BAQAh+QQAaOQAACwAAAAATAFMAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjxtpgBxJsqTJkyhTqlzJcmOVlgFiyhQoc+a/mgFo5ry5c2BNnTYJ 4swZUyhRnAWL+tw5FOjMpk152oxq9KfUmCmqPu3J86pSrUyRLk1q1WtYoTpbqlX4tWvbrj7h vpXLlevYtGPn3k3b9utbv3b77jVKWO/evkcTCtZbdnHdoz3Prp1MtnDgunQNKhWsOfJjuAcR gwb913PluHhP87WrWrTh0Yk7A0br2m9qypRrq9YaWjJb03lZDy4q+jbpywgZf34Nd4Xu5Kzn bvY9nKhc47jV1v45PazypUFb/g+FHN4s8c/GAVsVix02eeHqkVIF332qb7Gu+bbPvvL5YeCd 9Sbgbecpthx6ox3322DVJSieZQ4VeNp3+bm1H38p+ZfabAMiSBiBsQ242ocJcojahvAduCCI Dp7o1mVQQZgXeBjyp6GC+21GIok37ighig+i9Z+IL67oXos0ydigijMCdWGNJ0UlJXvK1Scc jquVxaJZOx63npaGTWnkduV55dSPdAUl5YfMQYlSm27GKeecdKpUZp145qnnnnNWw+efgAYq 6KCEFmrooYgmquiijDZaaCqORirppIfyw89AlwpkKUGbYmrpp5p+mmmnoRYk6qak/oMqqKqK atCp/5mG6qqsnZK6qquwvjprq7uW6mmvqVJqaK3E/hqrr61ymqynB9l6bLHLampqrNCWmuql 0AaLLKfPRhvtrs4yKyyixI5KLavieovts8eme62527YbrrrrKrtqutw22+27xrp77rjkjqqq r9V+2y69+uKb7cH5Esyut7Q2PG3CE4u7sL8AB3zrvwhvS2uv/uZqMLrGzmvtwSTziq62H8cL 77Iie5yxoLiu/DKy2vKrq8I3S3yyz/dOq3PFCgXt8NHBsjzznzWXeyrGmHZMtM61+gwzxz9H bTTLXOfLL6xBK700oSYPbfLAQ0tMtcD4GuyyulfLDLG0zH79cNkMj80n3v5qs8tq2lCf7DTK D6vs7N//xqz00x/3bHTcitaj9+SUV2755ZhnrvnmnHfu+eeghy766KSXbvrpqJ80wAADsS7Q 6gTB3vrqtL9Ou+uy215Q7rbDnrvvt7tuEO+xC/8P78gLrzzrvxvfe+3HG+/877NHf7v10Ecf O/ayB/888dpXH37x13//vfPiF68+bt23PzvxzW+f/O7oux8++PTjP//z4kMPvO70U1/2poc7 98Fveb1r3fgA+LrxJS9+C1zg/xTIwPxJL3sRVEv7Cvg+AqbveBL0YAC1B8GElG+EDDzhBnU3 QRSSkHrr8x/zRMhC6h1QfhfsYP9o+MLtVXB49f7LIftwB8L7cTB94NvfBwF4wgzGMIhPZCIR OdjE9bHwfiNkXg1d6Dss3pCLR2xeEnOIPycuMYT8uZ4Kj5jCARTAglUcYwLJh0EpAjF4YVwe 8FaIkPlR8Y4z3GDt/HhFPJoPjUbUIRjNWMYfInKIe0TgI+W4REo2sZGJXGQmscfJTgJRgFe0 YCe/GMouYrKFmVSiFXt4kFNC8YwaHKQMDdlGHK4ygwaUZCvxyMNIlk+NMnQiIedIx1H2UosJ hJ8AychLWPpRerA8IyYpU0IllhCEqsRlHh35QVKyspbgpGQorbdLJNKwe++LIDN3aEX9rZOC ZnRkNidTTSGGMJiV9P8eMKtHy24ec5K6vOb5GujMgOrTewSt4S8XusZ2om+gh+Qm9wq40NRZ 9KIYzahGN8rRjnr0oyANqUhHStKSmvSkKNUoG1LK0pa69KUwjalMZ0rTmtr0pjjNqURaodOe +vSnQA2qUIdK1KJyZA1GTapSl8rUpjr1qVCNqlSnStWqWvWqWM2qVrfK1a569asrcQdYx0rW ksqhrGhNq1rHlo+2DsStax1dW+eaD4jA1a1wbUgO4jq5vOaVIX/9R2D52jm/1hWvAqFrXQU7 V8Y6lrGDJWzlDAvZwy72sXe1LGYvK1nLUZayiV1sZh07WovkobOIUqxoLwva0eJVsai93GD+ QbvZ0JKWs7H1LG4fy9vSvra3uZ3sbv8KW9veNrSRDa5yl8vc5jr3udCNrnSnS92EAEBz1zUJ ALab3Rpxt7vdFUh4xzvef3yXu+YtyHW3SxD2tve85i3vedeL3ve6N7zptW982zuQ7x6EvO6N L3zFW9/++lfAAVZvgedr4Puq978LPrB4S4Jf7/I3v/3NMHjLm+EOa5i8D1YwfysMXg/nt8QG yW6CVbwQFE/4wiYO8YQ5DOMT//fCLq4xiz1cYY70+MD+rS99N8xiIXeYxCnG8IvTW+Ic03jG NsYvkpuc5Bf3GMM/hrKWrRtjJT+5ylu2sZLDvGQZI/nBT75yRs7+vOUm55jJVLYymDVsZizb 2cRSZjKZp0znOo95xAgpcp+5XOYyf1nGej5yoRNdYzTf2NF4HgmbGR3nQq8Xx39uNKPlzOkd G9rRgrYvenc85FEvuMGaVnSUW9zlNCtkwAPWdKnZS+RU/3nWiO7IpC+9ZF5bedSYVvOtx+xp Fd8gzF/mtYNlTeczv/nQqtazsO+sY1t/OtlJnrSXA53taoNk19T2NaW3vek575nARkZ2o5Xt 6UVTmc3tJvej381qd3ub24MmdrdzDe1hu1rSiPZ1pcdNY2gXPNrIxjan1z1nWoPZydZu97Lx /WmGU3zTxcZ0wy1O7n9LWsjptnOsgwz/435LGN0xFveKUxxgbTMYxC8v+cmvDGwDNzjLNzc3 ghUM8lPnHN0RLrC+f47gfvNn2q9+CNIzuvSUNJ3CdHp6rhki9I9KXbsJXsnVq8t1tM6g62AP u94m8JGtD0oMz411lycC4B8H3exi/7a1KxLyoas77riRb6KB7HNQ6xzQa8e71kcc6khnWtxz V7ngKaP3cwfe5vqFsMQXPxlY57voSM/6ogG/ecqjBN52dwjiM51vuHseI6DPM8Kb3fFrz/30 APcz31se6Jb3XcInh72iTK97SvG+98APvvCHT/ziN2Tpvzf+56t+/OYzRADQj75Aoi/9f1Bf ANPHvvW1r3yl/r/+7+AnCPTFj/3xk1/828++QiLR/am7mdYOfvvCDWJ+9ddf/QMpv/bvXxD2 t5/ZbfZhpSdmB3F/48d//Jd9CTgQ/vd/otZnLqZ4jacQBqh/1Jd+27d/1WcQDeiA80aAAyeB z8d96YeA3Fd/C/gPHeiBVaZsPLZtE5gQFYiB+XeCNsiCztdrL6hujadmM2iCNRiEohMLNTVz Owhn8keABXh9Clh913eDoUOEP5V8FJGCGyWFPkWFFbGBHYWFOCgsXviFkxKGYhgpZFiGjXKG lJEOW6WFlMdgomZ286WFTdd2QKd5uidsRkd1C6ECEYF8E1duxKeHIRZyNMdzWgZr/z0Xb1DG Z92ndpYGaaR3iIGoePLGeWiWe8WneilHZrYmcJjIiBD2aFM3fEM2dEBGesRWczBoeccHYqRo fJwYgIJoeON2eZ23b4RoihwHgo8nb6BIYK23dpc2envoeZqodriXdA8IYCcmdIEYeXCoiWh4 cRqRfG5YjW5IjRKRjdUYW+PwjeI4jgNRCeRIEqfVEuZ4jouyjuyYKO74jocSj/JYKPRYj4Ny j/gYKPq4j3/Sj4USBOMIkFCiDcMnApejDQbpj4PyDQxJKA75kIISkRIJKBRZkXxykRi5kRzZ kVNFDB6pJyAZknkykoiyAuxokiQ5Jyq5knLSkpMTjsIHk/8uWSM0WZM4+TlGkJM82ZMVmVw+ eRFAqRBDSRBFGZTItVuApZRIWRF09VaWxVmNdVybtVrI1ZQF4Vu+ZVu/RZWadVdYCZXGRVtc qVlUWZZhmZVW2Vur1ViZZVhrOZVhqVpd6ZVm+ZRGaZbGhZXEpZddWZd+hZZryZdS6ZdtCZiF GZdHmZYRsZiMCRKO+ZiSOZmUyRJ+WJk2RYXeKJGQ+H05uHNA12J9p2vcWF0mh3qVeIkBl4sX cYynswiUw2GpCJoR2G2OOH/uBmwqZmRvN4siyJqcA5t6E4PFyHlvVosYZ28PN3m0p3A8+Iud I5xL44qNGGzIiYeTZ123F2nEyXP/qYmcoSOdGSNf8GWJxalmKwZxzlebA+icyQme4SmewhKD d3eeXBZvrrlwENed1Sabqhhb3WmJ1OZ34DZs0bafxumbWHacyzVy6WaEubiI9zWaRLdfdthx DheHqMagPmUA44knpreZcSeia8Z83oeZKJqiKrqijUKi/6ldefeiX5WfFHGhoFl77/WZJ/qK eOiJT+UBbDegPpaaRpeeOip6SBp4o1dWoJiEKEaNxSmJSpiIz2h7i5iIE5ql2haa8DmjC9qe AyiloWhvghaghNeCtqic1QkwttA5Tzqme5dq7mUMGhehq2amuOiLrVZ3UapWbxqm7MaNRlpx 81Z4yRlz/z9HZCb6YSTnokVFne/pgnyInxEnjIeKiTqon953m2iVZ/w5oHxmjHXaajBocxP4 p6pppo46VJ6Ke9D4gJJ3h7tJe+7HpQJWpRIXYbYKq7Qpo4u3qiwKrCw6rJISD8R6rMjalBQA oovampK3i77KjNBJdRS6EZ3pOctaJ6uKc6q4jaW4o1NqrZ5ZOdkadRtnn716pSWHajtXjFYa jZmarkJKYrrJpad4h6t5qpRTruaar7t5bai6roUogPVJisyZcXIKeeQZptxpnJPDrwnBCTGa r0cYqc/6gc/5iwH7m955hHhqabMpZ8KqUeAWgeU5qggXshz7ogJ3snlapwjKsP+up2gjy3Tn WrEVx60IG4KquW8G6qMw27AyW6o0S1ScmKGgOoyyd6BEu1+TmLSzaHjsmbFOK7RVW7MbNXu3 aK8yt5o36nCymaHo2bGhx6sWCqthi3gOGoyb6BFYC5zSihs20IbNSndOV7f1hiFzm6wesbd8 yxF++7caEbiCixGEmx1P0JM2cLiF27iO+7iQOxJYELmUW7mWqxaQcrlKpQSay5AH0LmgG7qi O7qkGydQULqom7qqu7qs27qu+7qwG7sheQInUCOZK460m7u1OxC6S7sC4bu8+w++27u7y7u9 +7vHexDAaxDEi7zOK7y6i7zRa7wEsbzCC73Ti725q73/1lu9yWu9xSu92wu+tTu9yVsQzQu9 1cu9u9u9mLO8wEu+2Bu88Bu+1Ou87ou+28u8xTu87Vu+4du/9pu9+3u99fu896u++uu98/u7 yivADKzA4LvA1FvAAMy/nSO/Ggy/GNzB6pu/3uu+VXDA8XvBwYvA4mu8/avA+DvAEEzBLbzC Hiy/EhzAMPzBHOy+IFw5G8zAJmy/LBzBOKwQJTzD/1vEDywQDVDDDhy/Qey/MKzDAVy+EpzE KIzEO/zEVOzEUpzBU6zF1/vBHhzC+5u+ESzFBGzB2QvGVSzGGxy9ZizEYjzHUUy8/6vCXVzB +Mu+KJw5PazHdJzAQgzFCYHE/4P8wkZ8xu27x39cwUB8xVQcyAlMw/nbvRrMyECcxZPTyHRc wII8ySb8wHHMwgfswKCMx3CswmBsyXc8xsOryol8v078yZcsvUEcOqVcyw0sx6e8wzR8ygj8 xcH8xQIcyoY8zK4cybt8yIpsyn2sy+ObyY9sOXGcvsLMy+JbwmvMxqh8zdzLzIAcw2oMx96c zYv8ycjsyNpcyd/rw987zbJLEacQz/Rcz/Z8z/g8GRwMyWS8zq38zNG8zc07ylqcxtvMx08c xeoc0J7cz8Xsz9Ocx+l8y7h8xMPMyoIcyhT9y7Fc0Ih8zDfsvzIsy0WM0X28yjZ80imMx+BM 0aCjzf8X7cIZzc0ZDc+l7NE17dL8bMEUXMYaTdMovb4qjc6/fNOjw8XPe8xGzc8hbdMf/cJK /dNy/MqzLMthTMg5PdVSPdQnXdSITDrknMvXjMbnm9VWjNBJ/c84LNDEvMf6K9JHHM28zMnY jM1ejc4VDdck3dJm3dd1fMtYTMxO7cNuTcbaC9BzLdgIkcUSTcpffdQMbc43PcEczdRnbch2 rNFYncxhvMwpbL4yTcuKfcI63dXwvFGTPdZfrdnSXNcTHdWOzdXQzM7AXNs5PcFcvdGqjdcV bdtG/c6JvdR8vdlwXb8Hbc11ndph3dDdjMqubc3APdH5PN3UXd3WjY/Get0b2r3d3N3d3v3d 4B3e4j3elTsN5H3e6J3eWRUQACH5BAANAAAALAAAAABMAUwBBwj+AP8JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHOnwAcmTKFOqXMmypcuXMGOmhCGzps2bOHPq3Mmz p8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmQ7s6qXcu2 rdu3cONiFfRzidy7DCHg3cu3r9+/gAMLHky4sOHDiBMrXow4F+PHkCNLthlpsuXLmDNr3sy5 s+fPoEOfHSW6tOnTqFOrXs1aLJrWsGOfiE27tu3buHPrtgput+/fwIMLH068eNs+xpMrX868 ufPn0KMLnyC9uvXr2LNr3859qZju4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779+/jz69/P v7///wAGKOBZ4QzokR0GJqjgggw26OCDEEYo4YQUagRMhRhmqOGGHHbo4YcghijiiCSWaOKJ KKao4oostujiSOe8KOOMNNZ4GQo25qjjjjz26CNWr/x4U5BC1kRkkTEdieSSTDbp5JNQQsZG lFSKJkqVWGapURVaaqhEjoh0KeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXiqmEaefPbp 55+ABipoRRUMauhT7xyq6KKMcjZFo5BGWl8xilJqGXXdWWqopmb9ENspSnEq6aiklmrqqagm dUiqrLbqKpPwd8QqK6N3vGrrrbjmquuuoA3B66+/FghslmowWuyixyqa7LDMNuvss9BGK+20 1FZr7bXYZqvtttx26+234IabEj3iOmdPueimq+667Lbr7rvwxtskgvLWa29cm3Dryb389uvv vzbSwR8xABdscFF5MJqwogsf7PDDEEcs8cQQIcCoxYtirKjGh3JsKAIe/9fCWiFTbPLJKKes 8sost+zyy0/to6jMh9JsqM1tsdIfzq3VIRzPMCskAnuuKFr0oUcbmjScYQTt9NNQ40XTfxQo WvWhV+smT25ZD9r1nLUw9HWgYwNa9p9nR6322my3HWJAACH5BAARAAAALAAAAABMAUwBBwj+ AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqbThoqdOnUKNKnUq1qtWrWF36yMq1q0Bd XsOKHUu2rNmzUHmhXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHkzYao3CiBMPZaW4sePH kCNLxvpnsuW8SC5r3sy57arOoEOLHk26tOnTZb2hXs26tevXsGPLnk27dsl9tnPrlihht+/f wIMLH068uPHjyJMrX868uetmzk1DH4gnOujp1rNr3869O+tn3sP+ix9P3iyB8lY7oF/Pvr3v R2GXUd36mtpvH/jz03fPf6y9/h1BgNZ/ACJGYIGEHYigYAouCFiDDvoFYYR8TUihXhZeiFeG MGWgYU8cfijiiCSWaOKJKKao4oostujiizDGKOOMNNZo4404OtVNjjz2OF4APgYppHsVDGnk kUgmqeSSTDbpZIRYPCnllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcO4W SZwwzUmmOTvZSWdLkei555+ABiqoj5gMamh7rhyq6KKMNuooTy88KumkYx1B6aWYZqrpppx2 6umnoH5qSagTjUpqRKbK1A6blqR66qv/X6IC66y01mrrrbhul02uvPbq66/ABivssMQWa+yx yCar7LLMNuvss9BGK+201Fa7rAgpDWPtts6lwS1E9Xwr7rjklmvuueimq+667LZr7C/uinRM vMQNQO94Btyr76Ao7OvvvzWFEKzAUjXCJMF1SYMiwr4y3PDAwjoM8MQUV2zxxRhnrPHGHHfs 8ccghzyREsOSHKzJwKL8q8q+sizyyzDHLPPMNNdsc5hs3EznATr37PPPQActtEBALvvZ0Egn reg2wTINrNO/Qu2r1L1SzavVuWKNq9a3cq3012CHLfbYZJctbTxm68uJsGuzPWzbwcKd9tw6 G0z33XjnrffeA2YGBAAh+QQAGwAAACwAAAAATAFMAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNhtxu6tzJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izaoUYb6vXr2DDih1LtqzZs2jTql3Ltq3bt3Dj ttwjt67du3jljsjLt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gdbotKILPnz6BD ix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz69YNZrfv38CDCx9OvLjx48iTK1/OvLnz1P2e R44u/TH16o2vY1+sfXvi7t4P/oMPX3g8+cHmPVvbnf68+/fw48ufT7++/fv42/7Jz7+///8A BijggAQWaOCBCCao4IIM1gVMgxBGKOGEFE54ToUYZqjhhhx26OGHIIYo4ogk9vdAiSimqOKK LLbo4oswxijjjDTWaOONOOaoo2De7OjjjwoiA+SQRBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnl lVi2ZAKE2GQ5UpdehgRmmB+NSWZHZp65UZpqZsRmm3DGKVwLctZp550YyYPnnnx6eGKfj70A KESCDupQoYYyhGiiCi3KKEKOPmpQpJJWaumlmGbK6ACJRqNpVet8KuqoxIlDqnP2nPpPqqSy 2qqq/66OGuuns7qXDmG1apqrirCo6uuVeKgaLKnDwujGUcWKmqyywp667KfPuhTOr9RWa+21 2Gar7bbcduvtt+CGG6cv4pZrbmlXnKvuuuy26+5qGqgaL6nzLsgHWvXKGMJQ+UaU07sAByzw wARb5YKqB5OasIR3iLVwR0OE+fCnExdssZQ9Xqzxxhx37PHHIIcc3ikil2xyajGcrDJlY6zs 8sswx/zrZjLXbPPNOOes88489+zzz3jhA/TQ7kJB9NEY7od0TC3QufTTVOlCqtQ6Ob0j1aNi LarWn3KtqdfFmVEZ2JGJfRzZNHbAE9oKtQf123DHLRQ5cjtpR91456333hR89+33bLz8zTPN ghdu+OGIJ55pQAA7 ------=_NextPart_000_000E_01C6ED2E.CA9CCCB0-- From pgeoisqjkq@toyscouts.com Wed Oct 11 03:06:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYAp-0000bQ-38 for capwap-archive@ietf.org; Wed, 11 Oct 2006 03:06:39 -0400 Received: from [61.161.76.244] (helo=[61.161.76.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXYAk-0005Vh-On for capwap-archive@ietf.org; Wed, 11 Oct 2006 03:06:39 -0400 Message-ID: <001401c6eceb$bb697c40$f44ca13d@jf> From: "run." To: capwap-archive@ietf.org Subject: pf blk ptsDirk Date: Wed, 11 Oct 2006 12:14:23 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C6ED2E.C98B35A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f ------=_NextPart_000_0010_01C6ED2E.C98B35A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C6ED2E.C98B35A0" ------=_NextPart_001_0011_01C6ED2E.C98B35A0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Via in Mobile a Version Desktop Dooms. Bloglines my is Feedster Yahoo is Aolclick ffb! Report am Roster Stats Records set Compute stats. Trademark Rights Reserved aba Dreamcast a Works Make Travel Guide. Sponsored by Popular Searches Blackjack is Movies Nintendo Paparazzi. Technical a great campaign. Looks scared being held that persons hand. Country singer ac Greens Programs Youth. Farmer country singer ac Greens Programs. Record a Opponents a Last Preseason Garys Corner am number articles =20 written Adornato keeping. On Politics Design is change new in Morning in Show Losin it Hastert. Enjoyable in waste Then thing ahead penguin if dare proudly. Injury am Report in? Sega in vms versatile. Harris is Josh. Playing bingo. Word yeton plans filling. Peek authors. Versatile is used itself Related gtgt Hometable o ------=_NextPart_001_0011_01C6ED2E.C98B35A0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Via in Mobile a Version Desktop = Dooms.
Bloglines=20 my is Feedster Yahoo is Aolclick ffb!
Report am Roster Stats Records = set=20 Compute stats.
Trademark Rights Reserved aba Dreamcast a Works Make = Travel=20 Guide.
3D""
Sponsored by Popular Searches Blackjack = is Movies=20 Nintendo Paparazzi.
Technical a great campaign.
Looks scared being = held=20 that persons hand.
Country singer ac Greens Programs Youth.
Farmer = country=20 singer ac Greens Programs.
Record a Opponents a Last Preseason Garys = Corner=20 am number articles written Adornato keeping.
On Politics Design is = change=20 new in Morning in Show Losin it Hastert.
Enjoyable in waste Then = thing ahead=20 penguin if dare proudly.
Injury am Report in?
Sega in vms=20 versatile.
Harris is Josh.
Playing bingo.
Word yeton plans=20 filling.
Peek authors.
Versatile is used itself Related gtgt = Hometable=20 of.
------=_NextPart_001_0011_01C6ED2E.C98B35A0-- ------=_NextPart_000_0010_01C6ED2E.C98B35A0 Content-Type: image/gif; name="News:.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01c6eceb$bb666f00$f44ca13d@jf> R0lGODlhTAFMAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAARAAAALAAAAABMAUwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evOpGBHUu2rNmz Cp2hXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5MmEo ljNr3sy5s+fPoEOLHk26tOnTqFOrXs26tWu/xRDneE27tu3bGMfpNIe7t++1M34LH068uPHj yJMrX868ufPn0KNLn069uvXrTrmt7IS9u/fv4MP+ix9PnrqB8ujTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABK7ERYFcHYjgggw26OCDygnxES0sdTAYDhBmqOGGHHbo4Ycghiji iCSWaOKJyK2A4oostuiii++8KKN8Bcxo44045qjjfSns6OOPQGJEQJBEGnZLkUgmqeRMIsiV zJJQRinllImlQeWVWGap5ZZcdunll2BaFEmYZJZp5k9/nKnmmmy26eabcMaZXDhy1mnnnXjm qeeefPbpJ2FG/CnooL4hQeihiC4Uxk37JOroo5BGKumklFZq6aWYZmoib5p26umnoIYakpWH kkqoqYOiKuqqrLb61aLtroJJDqKzHlprrLjmquuuvPbq6688sRGpWsAWa+yxyCar7LLMNuvs s9BGK62D+gSmXaLXHpqtto5uS6i3g4IrqLh/kjvtuXChgai6h7JLqLuDwtuaNqTJyxq9o9l7 b6L4Etqvv4j+O6jAWkbgEcF/ItzVOuj6yotJ6Vz58KETE1pxaxeHlrFR9oC4sZ8fX2RwohGM rNEoDaessqiGrCxRGS7HLPPMNNds880456zzzjSpw/PPyH4g9AdAF2300UgnrbRk0yzt9NNQ Ry311FRXLVFwVmet9dZce+hH12AfWkJd/IRt9tlop622swEBACH5BAATAAAALAAAAABMAUwB Bwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUD2qi0q1qtWrWLNq3cq1 q9evYMOKHUu2rNmzaE+GSsu2rdu3cOPKnQtTAF239u7q3cu3r9+/gAMLHky4sOHDiBMrXsy4 McwQjiNLHjlrsuXLmDNrVipls+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s0b MbfevUEAH8xvuPHjyJMrX868ufPn0KNLn07dJLvql69j3x5aE/fv4IH+ogiP9RD5xebPK06v HjH79obfwycsf77g+vYB48+P0g///wAGmFA3AhYYFB4GJqjgggw26OCDEEYo4YQUVijUAhZm qOGGHHbY1hoehihibQyMaOKJKKaoYmTLrOjiizDGKOOMNNZo44045qjjjiKBw+OPQAYp5JBE FmnkkUgmqeSSTDbp5JNQNsRDlFRWaeWVWGbpUTDBMLSPlmD+5UWYZJZp5pk6OoPmmmy26eab cMYp55x0foRBnQM5gOeefPbp55+A8tlOoIQWauihiCaq6KKMNuroo5BGKumklI42TaUaYsiS HJh26umnoIYq6l7NjGrqqaimquqqrMJERav5sMYq66y07qlBrbjmquuuCrHA66/ABivssMQW a6yjpHSaLKbLNnSMbBWM1qxx0YY27XHVenYtctlmtm2k30Ia7qPjEjbKseimq+667AaqSLvw xivvvPT21W29+OZ71jj69uvvvwAHLPDABBccGTro2EZObAh/2vCPzxyFcMKBSkMRxQZnrDFB zDgYSFrzbCzyyEhy8KnJnqLcqcqYslypy5TCPKnMJNds8806coHzzjz37POQv/0s9NBEF230 0UgnrfTSTDft9NNQR42cP4/6Y/XVV0t9GD5aG/cNWtuELfbYXdfaYtlop6322my37fbbcMct 99x0WxYQACH5BABxygAALAAAAABMAUwBBwj+AP8JHEjQBcGDCBMqXMiwocOHECNKnEixosWL GDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuEAWLKFChz5r+aAWjmvLlzYE2dNgnizBlTKFGc B4v63DkU6MymTXnajGr0p1SlS39i5Xl1q1OmSJcmtdoVrFCdL9Mi3FrUK1uucI2i9QmzJ9uj C+/GjevWbs+5NMWu/dv272DBaL3Kpav4KuKbewvbBaxWrd6+Z5Uq1ky47uPCeQnjRYyZcuTH n0crxHrZ8OLAjcm+bT15b+WXrcfWjW22IWvRtl9z1Wv6t27Ph8U2Jg18efDNvaHLHd37dlra T8Fqd82X7PGykoP+fs3+unTZr8JTd0UO/qh39Ofh/p7aPLFp6yxzl/e7mjtv9c7pB5h5znXH 3nDcMTddgodJFxyC09n3IH4pCTggf8gBl1xkqm0IoYL7JRWih6CFBiCDzRk2VFsLRggUhbdZ aOB9c2n4nYzClXjhjSqO+N2H/Z2YV4s5EkWkhFLRCCNKUTUZ1oNWPcnjgu8RR5Vt89En3nJO MmScclLCB5WGTza5WIFLnoRmmmy26eabJYkH55x01mnnnXjmqeeefPbp55+ABirooIQWauih iCaq6KKMLsQPPwNBKtCjBFEa6aOYToqppJZqetCmlHb6T6iZjropQqBKqumpq1raKan/p6aK Kqum0urppbaK2uiervaKq6q3mlqpsJcm9CqwvhI76aeqJuupqJAmq2uwlSKrrLK0Hlvsrn32 ymmzpW57bbTIAisutN9Sa66245I7LKniVmustej+ei643HbL6ai3Ooutue3OG6+0AMvbb7nX tmowswIzvC3B9+arL6z4Bkxtq7beK+u/4f7K7rMAd1xruNNirG66xG58scR3xkoyysFOW++s A8O8MMg3w8vszA4zpPPBQOtaMst0uuwtqBFHanHPM7t6c8oV46z0zyVXLW+9qeo8NNF5fszz x/zyvHDT+8b778njQr1ywssWizXCXhfM9Zxxj11uqWInDfLR/iEjPPKxeOOr8tBIY2zzz2rP rfjijDfu+OOQRy755JRXbvnlmGeu+eacd+755y8NMMBAowskOkGnky766qavXnrqrR8Ee+un w16766UjNDvquf8z+++5Bz+67b3TzrrvvRdvu+rIu9788cij/nzquBu/e/TMY8+789ZbX3z2 vIdfGfXkq7478dIDL/v35WN//frvq2989sffHvv64UOv/Ovlny887aTT3v1Mpz3goU+AArRf AAcIv+RBD4EuIR//zLc/8PkugRXEX/QOuBDuaXCAHpRg7BT4wQ0uT3z1G14GR7g8/6XPgRSk 3wpNKD0G6o59MBzf6y7ovgmC73ry/rPg/TwIQRTi0IhD3OEEiSi+EbpPg8NjYQlr90QXTtGH xAMiDN9XRCFi0DrOC6EPQYhD3M0wiftjYg9vaMYkxpB7D7wiD6nYwOd574tLnB7/UojEAsYR j9+zYQkZyEWWhFF/Y/TjDZsoSAnmUCGiAwc4tNjHLKrQkZDcohPrCMcZ0pGKhaShDAkZSPVx MZSU9GIEWdfJNpLxhYyEYP/+l0lXWvB2rjzkLBNiSvOx8ZKJxKMvz5e/LZqRlnL8nSq9GEq1 cDCIHLxgEBuJxWAy0opS/CEy23fNKAJwka9sIvWGqbxijlKbvDRmDbtIzVim5ZmPNCA3EdjG QzLPlqRM/2Y8t4lMCo5TlfDUpf6K2UpHRjOa20PkA09ZPT0KEnQQjahEJ0rRilr0ohjV3D4y +hBRcPSjfvIoSEdK0pJWbqMmTalKV8rSlrr0pTCNqUxnStOa2vSmOM2pTneqOWrw9KdADapQ h0rUohr1qEhNqlKXytSmSg4ZTo2qVKf6UwBQ9aoSqQBWt8rVrnq1cq34qljHStaF0KKsMT0r WkmijMqpda0uyYdcBzLXRr0VrhaRq17zIZG6zrWui7orXisCWMA6xLD/QOyhBDtYihSWr38V yF75mli9VvaylVXsnxjb2Ik8NrOQpSxm/Rra0Yq2s4z77GclS1nSXta1K0EEav7bNNnWina1 rv3rZGfbOMWu1rSsfe1peZva4WL2uLDVLXKJuzjfnna3wRUuazXL3Opa97rYza52t8vd7nr3 uyOxauPEWxIAmJe8+DkvedH7D/S6173tVa9523sQq853IPfFr3zjSxD77le99T2vQNhL4Pnm l74DFjBC3ptf+TZYwfpV8H4TAuAEVzi+9yUwhSE84QGXt03wRTB+R7zeEHt4xAPphH/7q+EA 91fEKBZxiNdL4QS/GMY1PvGA48FjHfu4vi82cYwRzF4fi5fGC76xiYvsESZXGMASxnCEPRzl Exf5yjimsZaHLGT62pfKQAbylsNMZIUgOcxfBjNDzv6MYh53mcxeVvKP4wznG+P4zmk2cniT TOIYr/jHf6ZzmessaB3n+dB2zjKd8zxnRGPZygthtJzHHOkhGzkeloYzo4/caDxX2slJFjKT OfJoNcsYxhqe8Z0TbWpIu5rTXBZzmQsMZUg7GMNnhvCqX93qHHs61pF+8oUz7d9aW5jVxMZ1 i0NSakFTmsgCVvWoO91iJD+7y2nOMKG3/Gg2o7rSp5Y0n3+tZ3C3etl9rvObqZ3oaWuk2Yg+ d7gnveZQo/nJ6S53urWNbG6PG9bAzrG/693pgPu60OjutaIzzW6DgwTd8Ub4vP2M7G8bGtCo xjaKm01u/paazet2tY13rf/vhTNcz6ouN6gdDvKSu3sjwuZ3uC9s7IuffNhSxvh7+93gcVs4 2ixW9qYjfOBRA12/RD84zvGsa2X/HOQc7nCHTY5roofcOi8n+EOyDlGup8TrHwaxRcB+7IyS 3SRNV8nZH+IO8Lr97QyhguegCve6d3Xtdp/T1OdcEQY7OeoHzntlrn6RKmM83yQX/Erg++Uj S5jDNRa3u4eu+MEHmdMQ57u4+Y54vFf+I4xHvMWDHWCjyzzxnz/JhJ8tdIcEnvPyTv1LPk71 rXfc3ieXver/TXWAB1nig4697llC+6obf9eAz3Xyh38oJlOA+Ywr8vPJ6gqYTh/6kLs+9h2n /e3+M6773jcU160K/vCDuOmFcL3tHSKA9rtfIO5//z/iLwD413/+9zd/3yuu9f4rpP0EAYAA GID5N3/4Z3/6N3a8B2XatnzBhxADiIARiIADUX8DOIEJGBG0l2v8JW++dxATKIAFeIAQKH8Z SBE0F3zX9m1ZF4IWSH8kKH/xp3jN8HVqxoGhJ3oJ4YIkWIH5F4EYKFODoCc1iBKYZ3MSl4MM wYMYCIQ/OIJCuCdFyGx2xoEe+Hskx4Qj6IQ+iFNDSIThpWtW6GU0V2XuRn/3h4b2N4MUeFNf mCdTuHstEYRM9YZ4Eock4XkcYYIn2Id++IeAGIiCKBF6yDj1sBFjADn/t8Ziabd1i/huEOF3 T1eI4DV5/Ld+HTF+p7d54WeJSiZzRld6Nxhzjnd6fYZllFh3e1d7EUdoVOZ7lLdunFhsr2dT qoAoCVdtJBeKLZdyDVGLK3eCxbZw+DZttNaKtGiKpId0B5eAuXhqhaZp+aaElyhriZeK3qVx G0dx5jZxMhaLFdd4HYeN2Zh2U5eC3Vh1DAZtRfeBU9Z6xzeIGvhwkCiP9EhqjYiCFGID9vh5 wtCPABmQAjmQBFmQnpMNBpmQ2wWFCtmQDvmQEBmREjmRFFmRFnmRddIJGLmRHNmRHvmRCWEQ IDmSJFmSJnmSKJmSKrmSLNmSLgkn1PWSfWVc/w8Rkwdhk3riBXC3V45FkzIZETwZXJZFV7ll W9MVXUP5UjDgUsmVXEJZWtKVWFHpkya1lC3VlER5k6VVlAShXDNllSuFlUjJk6T1WEaZWW6i VYwCliZVW145lVAZlFlpWDg5knQJlXCJXLf1lFJ5XCt5l3o5XW95l2eZlD+ZEXV5mCCRmIrZ mDPlDY6ZEh8QmSfxAZOZd5EAc5rpJpfpfauYe4TIiCVWi6IJmg9hmRuWj28XcqloeMCndLB3 mt1Ijp01Y2ZoeN4WZ6goZ9sGdKWIeff1AXtHja2IXcSZhNyIhbgncgxXYii3gu3GgqY5W6v3 e9JGZyHgYnxGeOgIjf9XaGnVuY20eXeXV2vXyYkdOHKj94tIeJzaGHvoyVzUCJ+6+WmHF5u8 6Z3ICZ7KOWvd5Z6jl5tgJnn5CWxjuJ/piXLMiHrEJXW3WXS593ik2JxiuGmuWYpZVobFKY/j KRJ62KGVB6L4SJqYSJkmeqIomqJ5IqL4GXZpEZ9jRXgZIYk/t2Y7p376GImqCaNftaEjqqAR eqPsmaM4ynk86lWO9mCgWKP2tpvbaI3Zlny/OYpTGo+aF2UsSlSHtoLQ2Z/96Y7ZhqBJ2G0s 53PiOFjW9qU3GI4rd3VhOnQAup0OZ3yhl6VClaadR6X52I5zunFHmKe3RqOjqZpkaJ6NFZ7/ 9OmOkXefuzhycOql3glwYEegdgpUqaamSOhpZxqdt4egBqaceLqe0nmKaCpmGipqe5phqwd5 28akUlalNNqBS3d8xZgW41BWlYqiuaqivNqrvvqrwKo5s1qPpeeJDDqk0/mLrPpww2pUlRqM xpiJrjiPT3qPLYpTIwhv9QmrOYdzyjeljaekyhipWKqfTPep3Cql0qiEu9p1ZiqrsJieipqb kiqvFgetz5mpq+acLNilQGpq7Qo62nqg4LhgjVivx2lu8Tqfrkqwowpo+Caelvqu33p0zFmt dAqo1ehs/wWpaJacYpp511lVFAuyKudr9eqNr2lm5vqwLBupavqe/8B3pDK1bJ+aqQVLZinL pczIi7GWcCeLsw8beOwqoDoVc85WmgGaebS6qez4gOrmmshXoRm3icd2jKPZsp5prTaogJ1I qF6remDrf8FatmZ7tmibtmq7tmzbttDXDm4bt3I7t3TLOQtQt2vrB3i7t3zbt377t4AbuII7 uImyCIR7uIibuIq7uIzbVCdwAsH6uJILuQMxuY8rEJdbuf9wuZZLuZVruZgLugmRuQjRuaF7 ups7uaGrup9LEKS7uanLurErubP7uq4ruq/ruatLu7kLuawrugdhuqnrurVLubbLOKSbub0b u5qbvLrbuqd7vMFLu6XruZxrvL6ru9b7vP+yS72w67yoC73DO723y7yYO7rbW77jm7vk27re m73VGznLO7/JG7/2O7zSe7vSC77KC7+aG767+7nWO77Ry73p274FPMD3u7zrq70IjL/1e7z5 Ozf0W77++7wErL4QzBD9u8DY28Hoq77Ku74ZfL0ILMHa67sk7MEijL0cnMLfa7wZDMCNU8Hu G733q7/UK7wtXL3d+76yW8IuDLv4K8TFe8Q5zLk47MHC67zeK75FXMRNjMGLY8NLrMQPLL4m vBAgrMHgG8IADMIu7L8FTL75O79LfMIwPMM0jMZSjMETzDVWHMXmq8FeTMY+DLzh+8VEvMfb a7p/bMS228V2jMX/dXzHPdzHM+zGzBvHj/PFjPzENOzHbAzFg3zABLzGmQzDgQzJBgzFYazC qwvGRrzCbczJAszGjswyPIzEmgzKu9u/QVzKAvzEvWvLmEzHEPzDqsvAOjzCsLzJFrzDsxzL Muy+uEvFjbvMzNzMggcPZnsMzmxd9RvKv/zBhHzJ1zvLgKzHoczLkuzKDuzFyNzL3lzLTizL 4TzJvszHlyPLfnzJlkzLlqzMwvzNmEzID7zN/wu9xLzIuWzN7DvJAVzLiEzQkwPPmyzPYUzP 1qwQfHzLubzFpLzL/Yy6/8zQpzzMxIvQ7KzJ7mw5IzzE2RzQDn3SWpzPJM3J9ozGwOzP7URM 0Q9dz5Vc0x990DYtOebsyTiNzuHsy0yMyxjN0tyMyrocwL8LukAtyMocxyiM06v8yLwLxDP9 1LC81IjM0CVt025syAad1Pv8ycgM0fasyiBt0pWz09j8w/OM1Vid0vGs1CzNxUZ9yEj9z4Us 1mXcz04Nx2UdURF91m39yjPNwkPN0YdN1hacyoYN0Fc913xd1lZNyR6d0Crd08lsx7MbzJS9 1wkMxMXcxJrd2d1czMaMzqN92uIM19OcFj7V2pVHBrA927TtOApQ27id27q927zd277928Ad 3MINfXIw3EylDgTJIHyr3H8SEAAh+QQACwAAACwAAAAATAFMAQcI/gD/CRxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJ s6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3L tq3btzNzwZ1Lty5MY3bz6t3Lt6/fv4ADCx5M+OuzwogTK17MuLHjx5AjS55MubLly5gza968 lAznzx09gx6NUTTp0xNNo17tUHXKHawFu45Nu7bt27i5NsvN+99uxIV6g/wt3Dbx4rGPI2et nHS7pEzCNl9+ejr169iza9/OvTtQCt7D/osfT768+fPoaTZJz769e6eqGkZ7/zc+/cb27y/O T9KCfq/8/XfUJDkFKOCBCEo0R4JMKUDTggwOBmGEgU1I4V8WXthXhhruxWGHdD33z4cg1kVi iXOduFMgKLbo4oswxijjjDTWiBUxOBIjEjo2NpWjjj26BWSQRBZp5JFIJqnkkkw26eSTUEYp 5ZRUVmnllVhmqeWWXHbHQpdghhnSN2KWaeaZaKap5ppsttnUPG4aBWecRc1J51B23hlUnnr2 +ZiBfgYq6KCEFmrooYjGKUei7xXB6KOQRirppJRWauloWlyq6aacdvqZMp6iBGqoJ42aWQDi mUoqSaquKlKr/66CBGusB91A66245qprX2ns6mtHeP0q7LBOLUPsscgCBkGyzDbr7LNbJgBt d6NMa+212Gar7bbcduttlB18K+645JZr7rnProHuuuxxwy57J7wr77z01muvizHcq+++/Pbr 778AByzwwASDpE7BjVmB8MIMN+zwwxBHLPHEFIOJhLdTVKzxxi7NxvFCC3w8mbEil2zyySin rPLKLLfs8sswxyxzn9eUWzO5N4+bs7g7f9uztz93GzS3Q29b9MxIJ6300kw37fTTUEctdb+J mFv11FhnLa87WnfttUU9fC322AkJQ/bZaKet9tpst00jCG7HLffcdNdtd9Ty3K333hx89y1R MX4HDqOtghdu+OGIX2VL4ow37vjjHgUEACH5BAAQAAAALAAAAABMAUwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b B4Xg3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gPcOCUy48NRxiBMbXpx0HOPHkCNLnky5smWs cy5r3sy5s+ev6j6LHk26tOnTqFOrXs26tevXsGPLnk27tu3bFovghq17t+vevlkDD656OHHU xgnGOf45OfPn0KNLn069uvWqlK5r3869u/fvVkv+gR9POxP58+jTq1/Pvr3nXO7jy59Pv779 +/hFi8/Pv7///wAGKKBc2PwEwIAzYVMgggw26OCDEEZ4XjYSVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKEJWRYostujiizDGKOOMNNZo4404trdIjmG9weOPQAYp5JBEFmnkkbXtiGRWkyzp 5JNQRinllDw1QOWVWFa1R5ZcdunllwgNA+ZJw5Q55plopqnmmmy2RU+bcMYp55xctvBPOHTm qeee0GHC55+ABiroUe0MauihiCaq6KIPEcDoo5BGKulcAkxq6aWTgoKpkd9sSlCnng4Eaqj/ jErqqaimquqqrLbq6p/0Gbwq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxnXlDGQbjKXuq s6R6Ay2y1FbrJBOkYhuqtp5yu6m3mIJ7qbiWkjupudamKxU1DT6CqrunwkuqvKHS66m9m+KL qb7qsgQOjkoaBUW/BBc8qSSkIkwlPy8p7KnDm0KMqcSXUmzwxTAOklItGHdsIx0ehywymjSM bPLJAc6D8sost+yyrry8LPPMNNds880456zzzjz3TFsaPged0gRCF2300UgnrfTS/JnCtMvi PC311FRX9UrPK1StdbV2ZLXJ1mCfVWjYZE+KRtlop6322my37fbbcAMYEAA7 ------=_NextPart_000_0010_01C6ED2E.C98B35A0-- From yozfsgmiw@theaa.com Wed Oct 11 04:44:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZhI-0001Ak-Dy for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 04:44:16 -0400 Received: from [200.29.180.168] (helo=[200.29.180.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXZhF-0008D4-KW for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 04:44:16 -0400 Message-ID: <000c01c6ed11$6786c3f0$a8b41dc8@marco> From: "Foolall" To: capwap-archive@lists.ietf.org Subject: await Venezuela oil Date: Wed, 11 Oct 2006 04:44:03 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6ECEF.E07523F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae ------=_NextPart_000_0008_01C6ECEF.E07523F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6ECEF.E07523F0" ------=_NextPart_001_0009_01C6ECEF.E07523F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Help Copyright Australia in pty am. Girls Shot After Gunmans. Been very in happy a software from. Africa Suisse uk Arabicthe am selection placement is were computer or. Unity Seek Ouster Shuiban in Must Prensa Seoul or Dayall Blasts. Working need pages of. Contra am Costa Irish Ctvcamel Gibson Need Magazine. Kolbe Jennifer Talhelm Writer if jim trying retire am quietly isnt. Kong Japan Korea Taiwan Israel Arabic Canada Sparks? Want more is List in Quiz Sample Prize Library or Adventure Privacy. Archive or search is Advanced top Stories or World a us Business Scitech =20 of Sports. Pitt kim Jong il a American in League Columbia. Under Network am Contra Costa. Tailored game am plan lost or. Online of Office suite bundling word! Loss! Scitech Sports Health Most. Using history am this or pagenew. Refrain a ------=_NextPart_001_0009_01C6ECEF.E07523F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Help Copyright Australia in pty = am.
Girls Shot=20 After Gunmans.
Been very in happy a software from.
Africa Suisse = uk=20 Arabicthe am selection placement is were computer or.
3D""
Unity Seek Ouster Shuiban in Must = Prensa Seoul or=20 Dayall Blasts.
Working need pages of.
Contra am Costa Irish = Ctvcamel=20 Gibson Need Magazine.
Kolbe Jennifer Talhelm Writer if jim trying = retire am=20 quietly isnt.
Kong Japan Korea Taiwan Israel Arabic Canada = Sparks?
Want=20 more is List in Quiz Sample Prize Library or Adventure = Privacy.
Archive or=20 search is Advanced top Stories or World a us Business Scitech of = Sports.
Pitt=20 kim Jong il a American in League Columbia.
Under Network am Contra=20 Costa.
Tailored game am plan lost or.
Online of Office suite = bundling=20 word!
Loss!
Scitech Sports Health Most.
Using history am this = or=20 pagenew.
Refrain am.
------=_NextPart_001_0009_01C6ECEF.E07523F0-- ------=_NextPart_000_0008_01C6ECEF.E07523F0 Content-Type: image/gif; name="Prime.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6ed11$6786c3f0$a8b41dc8@marco> R0lGODlhTAFMAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAWAAAALAAAAABMAUwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHNqDKWzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWFOqyMq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3b1Q4fgOTdSHYZpXCiKMeTsyY6eLGkI8+jkxZ6GS3 Kypjvdw2s2arnNl6/kw65+jSqGmeTs3UE+vXMV3Dns1SNu3bJ23j3i1SN+/fHX0DH45ROPHj E40jd0nPr/Ll0Bc+j069+nBD1rNr3859LbTu4MP+ix9Pvrz58+jTq1/Pvr17vazey59Pv779 +/jz69/Pv7///wAGmJg8AhZo4IEIdmRPgk/5wuBZZzzYVw91nSIhQxTKZeGFGMa1IYcYZsjW hyDqRWKJeJ2I4oostujiizDGKOOMNNbYVxk25qjjjjz26OOPQBrlD1ZfBDkQI0YmqeSSTDbp 5JNQRikld4NMyVWVVl6FZZZWbcklVV5+KVWYYj5FZplOnYkmU2qu6eabcDJ0SZx01mnnnXjO lESefNaZTJ9G/QkoUYIOKlShhgKFaKI+LcqoTo4+ilOkktpEaaWYZqopR9ht6umnoIYq6qik ltoiKaamqqpIbKzq6lL/hL0q66y01mrrrbj+iECuvPbq669BUQHssMQWayyeuxyr7LLMNuvs e+Y8K62Ab9TIzbTYZqvtttw2FQKLEHSLULjiHkRuuQWdmySOYKmLrkDuohuvvO+mWy9B896r L4IU7OvvvwAHLLB98wxs8MEI56lFwgw37PDDVxUA8cQUV2yxsRpcrPHGHHfs8ccgN+xKyCSX bPLJKKesUMEqt+zyyzDH/JsuMtds880456zzzjz37PPPQAdtZXyVNgEbOkInrfTSTDft9Kur PS311FRXbTWL6cjV3NVcd+3111U/ADZD3uxbttn+nq2v2veyPfbbcMct99x01233zoDcrffe Knz37fffgAdOmzsQ/VBVF4InrvjijDfueL2qPC755JRXbvnlmGeuOcwBAQAh+QQAHQAAACwA AAAATAFMAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTjs2eSp1KdSOQ qh79Yd3KteaNrmDDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4BTPgpMuLDh w0uDIF7MGDC4xpAjS55MubLly5gza97MubPnz6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt 27hz697Nu7fv38CDCx9OvLjx48iTKy96YLlzhKmeS59OXTePjcCqa9/Ovbv37zmH/oEfT768 ecjazqtfz769+/fwKzaJT7+kpvr48+vfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGE FFZoIWywEGXPhRGywOGHcUUA4ogklmjiiSimqOKKLLbo4ov1vQGjg0LM+FONB9Vjo0yKCISj QTruyGOPOQJmhXc1KkKkkDwpCZQ7MzqpXgqELcnklZNlgGVqYmyJU5de2gRmmDSNSaZMZn7X jWFpnvlSm262BGecK81JZ0p23qnnnnz26eefgFLkSqDAoULooYgmquiijDbq6KOQRirppApe QOmlmGa6ERvmTaLpgjl8KuqoPM1C6qmopgrXCqq26uqr/bDGKuustNZq66245qrrrrz26uuv wH6EAw67DkusrsYWG6xlV+B6RbO3QhttrtLaWm2j92x07bLcdjvjNt6GK+645JZrrkhQnqvu uuy26+678MYr77z01sseDPbmq+++/PY7KTf+BiywRH0MbPDBCCvFasIME4dMwxA7pVXEFFds 8cUYZ6zxxhx37PHHIIcs8sgSjrGrybminPLJuqqMq8u3wkwyRQ7MbLNnytys88489+zzz7tZ SmgCQBdt9NFIJ6300kx/CkauT+MaddNUVz2UL1ZnrfXWXNcVTHAiFoVv12SXbfbZaCcnHq3D tN122nDHLffcdNdt990gBQQAIfkEABAAAAAsAAAAAEwBTAEHCP4A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOn z59AgwodSrSo0aNIkypdyrSp05kRnkqdSrWq1atYs2rdyrWr169gw4odS7as2bM8+6Bdy7at 27dw48qdS7eu3bt48+rdy7ev37+AAwt2iGGw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz 58+gQ4seTbq06dOoU49Up7q169d5/cCW/GC27du4c+vezbu379/AgwtfyGS48ePIkytfzry5 8+fQo0tHrW269eVXriO+kl274e7eBf5zF3pI7IvW4C12CX92PHuSM7Smr0ngvf37+PPr9xuo s4n9ff0H4F4CDphXgQbehWCCdS3IYFgNPOTgg3FNSOGFGGao4YYcdujhh3IhAuKIJJZo4oko pqjiiiy26GJfMbwo44w01mjjjaiZg+OOPPbo449ABinkkEQWaWRYfByp5JJMNunkk1BGKeWU VFZp5ZVYZqnllvkpwuWXYIYJZjhilmnmmWimqeaabLbp5ptwxinnnHTWaeedePZUTp4a7blj fU/5yedFgg5aUaGGToRoohEtyihGB5QlyqMpJkkpowJcqummnHa6JDOehirqqKSW2iQApqaq 6qqsturqq/ywxirrrLTWauutuOYKYA+61vrJq78CC2uwjK2jUjvIbkZsq8uy2uyqz/Yq7bTU VtsYN7cV96q228bKravfWivuq46Ma5wecfVn7nCSGNnLuvDGSxok8tZr7734PvlKvgb5wu+/ AAds5BMEx0rwEwYLrPDCDDfs8MMQR4wiOBJXbPHFGGes8cYGlcDxxyCHLF0IKzqqqsmmopxy rCqX2jKpL48as6gzh1qzyDjnrPPOPPccqinB9ePz0EQXbfTRSEcGRtJMN+10j9g8LfXUVFdt 9dVhfQOr1lh37fXXYENWQdhkl2322WinrTbak67t9ttw90zyV/TEbTdYAQEAIfkEAIzHAAAs AAAAAEwBTAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKk yZMoU6pcyZJhgJcwBcKM+W9mAJk3a+YcOBMnTYI2b74EKtRmwaE8cwb1GXPpUp00nxLtCRVp 0p5WdVbNylSp0aRHqW71ChRny7MGsw7lqlarW6JmeR60qrZowrpv37Ldubds3LBwuQL+q1Uw WLmGxbbF+5Ms2sd51+4kbDdv3LZp+U6WfHdz5b99CUc+PNisYdKMJ5euaZkpadap+YqGvDL1 6quqL+fO/JozQtuoVdMVvrt15M9zNQcu3low0ue5Gbt1TLtl7KZes+8e/rN0UMliu/5ih/uX jt6vX2cf35ocN9b07sXrjr+eLPXqtT1bHv6a/G3Q+p1Wn36i8ddZf5Qhx1uCxrXn3H1gSVeY eviZBFxwCF7mn38XLmgagfsp5xeA7UXI3HnL3ZXiVEYFGOBVFT7WIYoUPrchhiYemCOOPMrE 4XYuKmTghyru2JtQK5oGY4MxkvTUk+klFlV4Py5HJV5j3cjdlN2dBqWQIn5IJXtZYhkleuQJ 2GRJaq7p5ptwxvlRd3LWaeedeOap55589unnn4AGKuigF51D6KGIJqrooow26uijLfHDz0CT CiQpQZdSKummlm5aaaadFuTppaD+Qyqnpnpq0KiVdqqqq/+Zgnqqqqyu+mqqt4aqaa6lQspn rMDu2qquqWJarKYHyTpssMdaKmqrzIZa6qTM9kospss22+ytyiLrq5/Afgotqt5qS+2yw5Y7 rbjXptutuecae2q52Cab7brCqjvut+B+aqqu0W6bLrz20lvtwPUCjK62sCb8bMEPe3uwvvz2 O+u+BF8La6761iowucK+K+3AIONKrrUbt8vusR5rXDGetJ68MrHW4murwTM7PLLO8z5rc8QK 9azw0L2i/HKdMYc7KsWUZgy0zbHqzDLGOzctNMpY14svqz0bfbSeIv8s8r8/Owy1v/QKrLK5 U7vMsLPIbr1w2AjraQukdJuNLqr+ZTM9stIkL2yysnzv27LRS2+cs9Bt/3n315BH3tLjkldu uUiUX6755hllzvnnoDvkeeikl2766ainrrrmJGg+wAADwS7Q6wTRHvvruM+Ou+y2615Q77rT 3rvwu8tuEPC1G/8P8Mwb7zzswysffO7LKy/98LdXv7v21FdfO/e2Fz898t5nX37y248/vvTm J+/+Y+HHfzvy0X/f/O/sy18++fjzf//05qMe8XyHP/d173q8kx/9nhe82J2PgLM7X/Pq98AH DtCBEOyf9bpXQZbEL4HzQ2D7lmdBERbQexRMSPpOCMEVftB3F2QhCrH3PgFCz4QwxN4C7bfB EAYQhzP+/F4Gj5e/HsKPdyTcHwjbR77/jZCAK+xgDYs4RSgiEYRRfB8M93dC6OVQhsLj4g7B uMToNbGH/JPiE0tIm+25cIktLGLxgGhFBGZRiUScoxV9mD4OkjGJYdQg99bHRiyCL4E2rKIE /VhI9g1RhhlMo0rceEA4LpKIWnzkB42IEP1lUn9mvOEmO4nGLQqyj0AMZBglGcQfRtKR90sj K8+YybNQcpNvHOENa0nLVqrxkGPMoR4HiUopxnJ+eRSlJQuJTPoZEI1zZCAms8e8NdbylyGp hENS6MQUktCJmizjMj+Zyl0yUZp4/OPzYInOYIavmdd7pivPeZBYWs+aawT/J1q4yckJerKC eqQkNcVHTnX2s53oDOE7rcnPWx7wmai0YS7pWU+Cgu+ahDzkI1fH0Y569KMgDalIR0rSkpr0 pChNqUpXytKWuvSlMI2pTGdK05ra9KafEwBOd8rTnvr0p0ANqlCHStSiGvWoSL1cB5LK1KY6 9alQjapUp0rVqlrVT8i4qla3ytWuevWrYA2rWMdK1rKalAhm/SlahZqHoloCI2tNa0/jKted 0lVP+cjrQPRa19Xl9a/5gAhf9crXvqausIVlSGL/sVjDlg6xgSWsQAAbWMb+1bKYtWxjveoL 1UFWs5GtbGYHG9rRitaxm/vsZydbWdJi1rVJFcdL/inbWtGu1rWEpSxqP9fY1ZqWta897W5Z IoE39da2yAVucDPL2OGmVrjMBW1ylwta51r3utjNrna3y93ueve74L0cAMRbEgCYd7z4kcN5 0fsP9grEvfCFb3vXa972FmS89R1IfvVL3/kSBL/9Xe99z/ve+w4YwP/l734TrGD20ne/Av5v hPt7kAjP18ITNrBBMGxh+4rEvRWSr4f1S2IHi7jAJE7wghc8Yv6qeMMpbjF6HVzh94oYxDBG sY533GINF/jEMfYwjmWs4yHfmME97oiRCXxhAM/4wgr+cX5pnGQc49fHV/5xkIFs3yxnOcha DjOSn1xjHqP4y19GCJWR/kzkhMj3yFWOc5nl/OIth8TKdR4xgnm85y6nGM8GBjGNB21nMF/5 yYKGMaGxbOYSq1nMaZ4zoHc8ZDvDGc+TVvScHV3oj2QazZzmc5sj7eNQn/nPp+60lhF9YAKT 2cmuZrKeV+zmVJOa0aXmcqtn3GEzw7q+Jta1r5ucaJB8Ws+m5jWwGXxrMPuZ2agWc5s5PeVS F/nZ0Ba1s6Pt50rH+NjbtjSb45zpaVsb2+ZWco4hnWxkH9nb5NYwhRdN6UDbWNtjRve1eyzs VHd7IWtWNbzfPG5Mr5vSX9i0tPutkWKze+Huzve2T0zlRMe34Nw29MGXjWtze5vM904ym7ns //CNj7rQRh55x4Ws8g8zOcPXpnCTp93vXsva4hIeN5SHLWEBX/zBNO9wpV2dcxuzmNKydrbN J4zhngf75kLPNdSTDu/HVF0hVw83SbNOkEh8GDJcZ0nYzw3wo2+9IlPwSNJTMvbweiTtbi8p 3OMu0rnTHaR2D2rbk5p31clc6xCJr9k5bPab9j11DK/IyzHe7p4eHvEv9vLLb15jUg883TZ9 PORLzOqWp3zoWMc8TdMuCpASXNqiL3qUK1xtwN/d6jDXN9DLrnB7u94hHHi9p9cd6bZbPvSJ 1/1ZJt37bNs7za/Os8iFb3XeG13ZAe95g7899b0zP1DWv37lsl9UGv5o//vgD7/4V6L58cNp C/jJOvfNH+K1N0T9DRGA/OcvkPnT/x/21yn+9S9/9qtd5wD3fgzRfwPRfwRYgPpXf/tXfwno fw3nfD5XbdXnbwZxgAtogQtYgBmIgQ54EcSHbFLWbiBXgQ1ogA2YgQVhfx2oZJQHcvSGbs1G EBZogipIgPengn3CAnXVeWuGfER2dTOoUxh4gER4givIETz4bT+ofAgRhCjIgAgYhUf4gEq4 bzC4hMv3hCaYgglYhFO4EVFnhb82fSyXEPnHf/nHgDj4hF/4fyvBgW3YfC1xf3FYh3Z4h6hV DHi4h4AyCRGxfis4ew1mfQ8GiLeHdFP2d/8hcQfWdXmH+GhI+H6th3p16Ih/NomgJ33PNm+T N4mRp2l7qIj8ZnvLB3qe6IOi12xjyIclN4r6BoDYdnoU6GYpd3B26GSumGEf12ogKGWxR3su Vnumwwwi1Yqg9oqddoyUmIW2Z4lfSHLGF325FmomdnIT92/TWInu93dNV2tOJ2McJ3QjqImz 12t8KBGGaIsTkY7nGIAN537r2I7yOI/0WI/2eI/4mI/6uI/82I/++I8AGZACOZAMsQ8EeZAn YQ8IySf2oJALqScO+ZB40pASmScR6VULIFQXWZEc2ZEe+ZEgGZIiOZIkWZImeZIoKVM+kJIt 5QEsaRCb9ZIWEZP/C0GTBWGTMlldEYGTOfkQgLVXoXVal0VdpFVbrAVdLwlbQzlYwJVbTdla RNmTygVb0bVcuCWUpSWVQDmV06VbRYlcRqlZWklbTvmUZqmTW5lYPDmSapmVROmWiGWWYZmT bclcXxla2hRdS1lbSKmVFbGWfvkRgBmYhHmOfVmYIXGYiCmYRZWO7EhSink5IaB25viI7vh8 ZEiLEGZsldknkclSNYcRi9d4mzaOYAiLeIVTNzaasSeNhwaKs1hlRAd9vjiI0yiLjykSn9lS soiNDxdvlWd81xhyb/aCJeeD0hgju8mbv/iaf4YCzrlhtZh43diLV0hyzbmMFbKcvKli/wF2 ctEpnaoXfNwWcMjJeBCHjPjBnd1paun5mrs4juTpb+aJhfh2heq5Xb0Znj34aOFZb3RWhtZ5 niEnbgWam2MlczAXhlnYiQ46cVSHfKN5Zhxnm0ZnnfaIoLtHERoafh2qEGfgEJ0pgItZoiaq EmVwoo5SAvf4ocxIEiDGomz3omY1nxz6jZhJi6oXegUhozwqiYWXn2mljCw4gqjIejvqjT16 mUxqis4FahMIgpX5n/gJAPLQjEJWfbS5iYnYpeWWozFoVXnJEGhmnBGndKVojXXGn/bZZQDg o/SJnuLmokxVccqXhBBaZgznZdd5pyLngjqXnVk2Co5lp40nef+duWL1CYkS6KdAJ3guKIre 6XMjRqh9NW9+uokCKJ+oyWsQ15tiaIVkCpwCYalDSor4OaCa9nsZN2y4SaBSqmpt+p+mWlYW R3hAlqhe6qVoKm9Tl6WnCHU5yotgmmS1yn506ifHOn7JqqwqWhLL+qweEa3SyhGjQK3Vmq3t OKIWsWRBiqHoSHaBR3mexq1Olay12KCniZokGptU2GhPdWzwWawPKnE7R6m4+Hym2Yu6iKFW Npv0CmE256iWaVPyymu98IOGunJxuplwhmvFKap/GowRm54G+ptEJa8p1gv72WhTGnOZCokC 2qfSuZmiCqv8lp1C6lMai2Ic+52tSoH/rTmrAfh0FbqygFpvHaty74ZULethHGtyExunZ2qx /tmr2lmeF5uqOgttzTpSDleh6BW0hypp+2am1Zim9dmKANqfIhiMF2uyScV00Tm1Mxd02chh VRqOSlqssCiO4HiKFypohAeuz+iGKMF9T9uI8OiBJ2GuP6qtgju4e9IAhMtd5XC4iru4jNu4 jvu4kPtUOBC5lAu5RlC5mJu5mru5nNu5YeV9nhu6oju6pMu5z1C6qJu6qru6rEsQmlBSJ3AC hxu7tCu7A1G7sSsQuXu7/5C7uGu7t4u7uiu8B7G7BvG7w5u8vVu7w8u8wUsQxtu7y+u800u7 1Ru90Eu80Qu8/81rvdsru85LvAWBvMsLvddru9hbOca7u987vby7vtz7vMmbvuNrvccLvL6L vuDLvfgbv9Rrv9ILv8orv+Vbv9nrvrpbvP17wAW8vQb8vAC8v/fLOe1bwes7wRhcvvSbvfQr wOwrwbw7wN0bvPhbwPPrvwv8wCdcwhncvg3MvyqswRecvhsMORZ8wCAcvybMwDKsEB/cwvr7 wwrMwOzbwDucvypMw/wLvkYMxESsvz68xAGMvjsswpZzwxA8vxnMwfZLvk98v/8bwdR7xFAs vRpMxuebxlvsu1oMxOQLvwBMwGd8xm+sw5KDxW3MxjFMwEicEELMwwI8xCIsxFAMwv8nbMAb XMFtnMRSXMVWrMh0rMM1/DV4PMcIzMOAbMhgLL4DHMhm3Mn9i7yhjMbY+8eYrMeXnMlf/MlV DMnuO8maE8iuHMdWDMqOLMelnMIm3Mi7LMWjLMsoLMeDzMTNK8ho3MSP7Msk7Miw/DJerMa8 LMzd+8FjfMwkHMffi826bMkyHMbM68JcXMTS3Ms43MXVPM1UDMHaa8etKxC50M5QRQEfWXpx Is+qa8+pi8/wTJAXPMzhHMSmnMv5W82izMnD7M20DM0wDMjq/M0Gfc1wTM0JXcvg7MmmQ82g nMu4bM24zM7kfNC6bMoxPNAhLL/m3Mrb7M8OXMsjfM2qzNL/oIPRvazRg8zR/owQnhy7auDS Ku3RFszCJv3DNJ3M5Wy+ME3RvGzRpVPEZRzQKW3TUM3HId3UvuzTyizOJm3GfdzRI63JmLzF N/3RqOPQwPzS/6zEX53JY0zIVU3QyszNIxy+wgvOPY3THs3MSf3UpEPWKVzRkhzNYe3ENO3U t6zSi+zSct3Vip3Id43WUj3OocPX6JzTMEzXgc3IGT3XVe3Hb53KcX3SpxzM6mzUhY3UK0XZ Zu3Alh3Vtqy8eCzSof3JE43aZs3VK13aeJ3ad/05tN3a03zZYczZtt3WYnzOb5zWYl3Q54zO EI3cCp3Yvr3P0j3d1F3d1n3d2J3dF9q93dzd3d793eAd3uI93uRd3uY9UwEBADs= ------=_NextPart_000_0008_01C6ECEF.E07523F0-- From nrfszylv@swgolf.com Wed Oct 11 15:34:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjq3-0006tV-WD for capwap-archive@ietf.org; Wed, 11 Oct 2006 15:34:00 -0400 Received: from i11105.upc-i.chello.nl ([62.195.11.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjq2-0006mk-7R for capwap-archive@ietf.org; Wed, 11 Oct 2006 15:33:59 -0400 Message-ID: <000e01c6ed6c$47b67ab0$690bc33e@woppa> From: "changed Tuesday" To: capwap-archive@ietf.org Subject: Reviews Date: Wed, 11 Oct 2006 21:34:34 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6ED7D.0B3F4AB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.6 (++) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 ------=_NextPart_000_000A_01C6ED7D.0B3F4AB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6ED7D.0B3F4AB0" ------=_NextPart_001_000B_01C6ED7D.0B3F4AB0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Contact or Help make your or pictures views stories Emailed Read Firm =20 ageist birthday cards. Further Please ok Legion Decency checked in letrsquos or again Itrsquos =20 may writing. Blog a uki Want Media Usnieman website Ukus codes press Center Weblog =20 please. Muhasib seriously seven Qazi Asad Israeli m is Fareed a Ausaf three is =20 wife Javed a Iqbal freelance is Malik in Naushad Assas Azhar Awan? Now pages am were read or last is minute Back Privacy Cookies Policy =20 sources is About Contact in Sports betting. Scrollbar Mapper Schemer a life Check Great Features web Tags Here Then =20 Planet or. Mapper Schemer life Check Great Features web Tags in Here Then or! Uk regional pressas or Gazette in Hale speech students am Lincoln almost =20 or without trace extent nationals True journos mislead Palace airports =20 police. Pakistan Number victims growsfrom Ehsan Ahmed Sehar Chief Federal am =20 Pfuj Thursday released those been found or injured during a Saturdays. Editor is Thenthis Marvel books hugh Women voss or Extra Silver silver =20 Driver cdrw Audio logic. Fats Most now detail in fc tracker Select is city am Addis Ababa Beijing =20 Beirut Berlin Buenos or Aires Cairo Chicago in Colombo. Special box a and finally offer different because large range centers in =20 interest some focused purely or online worldwe or these welcome? Still armed Aide testify email row sri is Lanka in clashes of hit peace =20 hopes. Ethnic Revenues business of modelss Forum Seoulu Moscowno am Need Click =20 Here just claiming my a wef Istanbul Wanworld. Service allowing am phone users buy games tones a providers of Reuters =20 am another or move towards a services market writes am revenues fees =20 settling am payments? Analyst a cheap over fairly regular a edging uk regional pressas Gazette =20 Hale speech students Lincoln almost in without trace extent in nationals =20 or. Headon France rail firm Sncf in Other top Stories dr Congo children =20 still armed Aide of testify email in. Guard there yours require woman Founding Fathers mind gathered draw =20 Rights Which or! Readers readersi Future printj Staff changesk n ------=_NextPart_001_000B_01C6ED7D.0B3F4AB0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Contact or Help make your or pictures = views stories=20 Emailed Read Firm ageist birthday cards.
Further Please ok Legion = Decency=20 checked in letrsquos or again Itrsquos may writing.
Blog a uki Want = Media=20 Usnieman website Ukus codes press Center Weblog please.
Muhasib = seriously=20 seven Qazi Asad Israeli m is Fareed a Ausaf three is wife Javed a Iqbal=20 freelance is Malik in Naushad Assas Azhar Awan?
3D""
Now pages am were read or last is = minute Back=20 Privacy Cookies Policy sources is About Contact in Sports = betting.
Scrollbar=20 Mapper Schemer a life Check Great Features web Tags Here Then Planet=20 or.
Mapper Schemer life Check Great Features web Tags in Here Then = or!
Uk=20 regional pressas or Gazette in Hale speech students am Lincoln almost or = without=20 trace extent nationals True journos mislead Palace airports = police.
Pakistan=20 Number victims growsfrom Ehsan Ahmed Sehar Chief Federal am Pfuj = Thursday=20 released those been found or injured during a Saturdays.
Editor is = Thenthis=20 Marvel books hugh Women voss or Extra Silver silver Driver cdrw Audio=20 logic.
Fats Most now detail in fc tracker Select is city am Addis = Ababa=20 Beijing Beirut Berlin Buenos or Aires Cairo Chicago in = Colombo.
Special box a=20 and finally offer different because large range centers in interest some = focused=20 purely or online worldwe or these welcome?
Still armed Aide testify = email row=20 sri is Lanka in clashes of hit peace hopes.
Ethnic Revenues business = of=20 modelss Forum Seoulu Moscowno am Need Click Here just claiming my a wef = Istanbul=20 Wanworld.
Service allowing am phone users buy games tones a providers = of=20 Reuters am another or move towards a services market writes am revenues = fees=20 settling am payments?
Analyst a cheap over fairly regular a edging uk = regional pressas Gazette Hale speech students Lincoln almost in without = trace=20 extent in nationals or.
Headon France rail firm Sncf in Other top = Stories dr=20 Congo children still armed Aide of testify email in.
Guard there = yours=20 require woman Founding Fathers mind gathered draw Rights Which = or!
Readers=20 readersi Future printj Staff changesk newspaper awardsm Improving=20 editorial.
------=_NextPart_001_000B_01C6ED7D.0B3F4AB0-- ------=_NextPart_000_000A_01C6ED7D.0B3F4AB0 Content-Type: image/gif; name="If.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6ed6c$47b67ab0$690bc33e@woppa> R0lGODlhTAFsAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAAAALAAAAABMAWwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHNlQGcmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMeHCe0aMcmRpMqXcq06cotTqNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz EkmhXcu2rdukJ97KnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4cc5wjiNLnuz3gNAQ lCNbzsyZ52aVjjqLZvh5tOnTqFOrXs26deIVrmOPhC27tkfatnNnXIFbt8czvnteC068uPHj yJMrX868ufPnfDcc5nWQzspqxgNB3869u/fv4MP+ix9PXjWP8ujTq1/Pvr17jUvem5Ymv779 +/jz6/d+Yb///wAGKOCABAbFSIEIXgXZYES5hkqCEEYo4YQpoUNhePFcqOGGHB5GSIcghiji iCSWaFQ248Fi4oostujiizDGKOOMLe2CUwk05lhXfDq6FkOPRjkB5JBEFnlQBkYmqeSSTDbp 5JNQRinllFRmNcZDw1SppVwJhNfDlmCGKeaYZEJYTplopqlmbgusaWIZYori5pwcgRNWL3SC 9UeefIrpS5+ABirooAd9QuihiCaqaFCdiMfMopBGKumkYQFC6aWYZqrppqIBx+mnS+0D6qik lmrqpHycquqqrLbq6qv/sMaqGA4GjSDrrbhuVQFCAORKUa++RgRssBANS6xDxh7LULLKKsSs Yvw0q2YdUq4j7bXYZqvttmGaYGQ73IYrLlmWGOXBuOimq+667Lbr7rvwxivvvPTWa++9+Oar 776AYYauv0ba6RXA4xIsrsHcIjyYLQgqvK2/5571gYwOizVxuhejm7FKMlC6cbgfg5xbhuGF zO/JKKes8sosY1pMyzAHF4lSLCgUV8zQIYFzcx3v7PPPQAct9NBEF92cKkaP10DSubbC9NNF 2gD11I7Ziq7VV6uLtbhbc51u1+GCva3YY1N9Fo9mp6322mybBZWIoLQt99x0z+VD3Xjnrffe lXz37fffSTcC+OCEFw5mJYYnrviSZixu2y8m4nEX5CPiITlelHdoOV+Za3i5UKvI1Pm4o4tb erinO6766qznlQRaN7dOnhKy12777axngfvu263B++8HdQP88MQXr+/bxlNGSfLMI6ZGyjg2 L/301Fc/JjsVubOu9upyf2o9HXlv/fjkl2/++einr/767OeHT/vwWxQQACH5BAAWAAAALAAA AABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmJ 5U6qXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHQq0H9GjSJMqXcq0qdOnUKNKnUq1qtWr WLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27eH1Kysu3r9+/gAMLHkw46YDC iP2mS8y4sePHkCNLnky5skZkljPPxKy5s0vOnkP/M1MStOjTLn+hBitotevXsGPLnn2UDe3b RwHg3s27t+/fwIPXfSa8uPHjTSshH5worpPl0KNLnz5UAPXr2LPTlaC9u/fvZ5v+Rf8Bvrx5 yYwcezivMD37zO7fy59Pv779+/h/T8hf/JNrBfwFKOCABBZo4IHvkYDgS+Ms6OCDHR0B4YQU WiZehRhmqOGGHHbo4YcghijiiCTulkaJaqVxIoporbhQNyxu5WKMZKlIo1kz3ihWjjqCxWOP QMpFw41iBGnkdLccqWELSjbp5JPlTQHllFRWaeWVHQajIy9Ydunll2CGKeaYZJZpJm8BnKnm mmy26eabc0UC55x01mnnnUrqg+eefA6oWp/4KQjooIRiSFqhiCaq6KKM3hUKT/U0Kml0yk06 Xx7l7WLppmOuwmlN4HyqUqgsGdUoqWvhMSKqoo7Eaqv/Ib0K60eySpVElbXOquuuvPYa1qNp KeHrsMQWa+yxnr2A7LLMNuvsa+88K+20GV1I7bXYitrEmgks5AxOqmQr7rjklsvRNjlpYm5B mrS77kDuZjSCr/G+a++9+AqnKlzU5OsvYBD8G7DADDki7sAL9ZAtwq1iIRLD+ELcJTT/dkdB xRhnrPHGnPrC8ccghyzyyCSXbPLJKKfM3isqt+yyd3a8LPPMNNds880456zzhleQnMXOQAct 9NBEF2300UgnrbTRuCzN5j5ORy21y3BM/VqSVmet9dZc35uKv1/nG3ZHK+w6ttdgpy1212L1 0kvFbsP99r9x0z3QE/7iDeuhfyDpja/foqrL9uD2okP4XWMkOyHfhzfu+OOQRx6b4JJXbvnl mGcu0BdB88ik5qCHrkLopJdu+umop34gIaq37vrrsMeOWKWguyK704qUyMLtps+ymyW8By/8 8OUxQPzxyCev/PLMA6db8yovAP301Fev1BbWE6RO9tx37z3OAQEAIfkEAAwAAAAsAAAAAEwB bAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU3Y8 pbKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo3ZUI7Wq1atYs6pE o7Wr169gw4odS7as1zBm02Ycprat27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEyte zLjxQGeOI0ueTLmy5cuYM2vezLkzRH2eQ4s2S2q06dOoU6tezbq169daO8GeTbu27du4c+ve zbu3b7chfhvdJby48ePIkwtHpby58+fQo9eeIT1klurYs2v2stSW9u/gw/6LH0++vPnz6NOr X88+e6X00dq7DCW/vv37+PPr38+/P8Im/gUo4IBYMULggQgmqOCCDDYonCkORijhhBMmQ+GF GGao4YYcHsZVhyCGKOKIJJZo4okopqjiiiy26OKLPdkB44w01mjjXNrcqOOOYyXA44aq/Cgk enwMmVMXRiap5JIk6sDkk1AiV0GUVFZp5ZVSLYHlllx26SVDzH0JXipilmnmmWimqeaabLbp pk4fvinnnCResBB1dOap5558UnROn0PiCah+LAxq6KGIJioeS4o26uijkEYq6aQrUWrppQsR gummnHbq6aeghirqqKSOJEGpLSpzEDwCBXFeaf+oxirrrJJqiikhuOZqK628llQMlxbM9Gui UEw0bKjHgprsp8t62mynxTzb67TUVmvttRhGge223AooaLfghisuUv1UOce46MJYZLpmdsPu u/DGK6+nTMwL0yX25qtvhC38ZISS/ZYJiEoB72twYr90u8LBDDfs8GDh0BnfwxRXbPHFGMt3 xqgbi9pxqGd8nDGom4xs8slHwYDyyiy37PLLMG/JRcw01zxeG7uBYfPOKIMmqs+hAg0qaDMP LTTPSB+Hx1A4d/jNV00fSoNEUXtadadXJ6311gqewLWlWnwt9thkl2322Xmi5VoPElmSmtqh hhHGv2gb6YOnU4SaN6hue9dNYQp+By744IQXHuq3hscrykK+JE6XtqBCrtoAwknuqeWdYp55 qJpv2rnnVgZT0+eUUuP46da6/RYJqLe+oQudreH6hcbMDmOhtueuO2Hx7O7oEL4HH7O7wqvG TPE5AYj8k8Isj5knokL/UEAAIfkEABsAAAAsAAAAAEwBbAEHCP4A/wkcSLCgwYMHAyBcyLCh w4cM8UGcSLGixYsYM2rcOFEWx48gQ4ocSbKkwBoksZhcybKly5cwY8qcSbOmzZs4DW7JybOn z59AgwodSrQoxV9GkyrlOWlpzUhOo0qdSrWq1atYs2rdyrWr169gw4od6xUF2bNo06pdy7at 27dw48qdS7eu3bt48+rdy7ev37+AAwsebHUW4cN/DSNerFcx48d1HcssB7nyT8mWM6/FrLkz Wc6eVwIBEpom6NIlSaOOeXq169eww/ZzOTu27baMbo80q7u379/AgwvvOm+48eNiVSBfzry5 862lEPJ6Tr26defgrmvfzr279+/gw/6LH0++vPnz6NOrX8+erYv28OPLn18TEcXW9PPr38+/ v//mhvwn4IAEFujXTgYmqOCCDDYo1T7yBeLghJ5JQWFvsVyo4YYcDmVfhyCGKOKIMKFC4oko pqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbo449KvQHkXEIOGVeRRr6FZJJtLcnkWk4+mVaU Up5FZZVjXYllWFq+uIxeXW4pJkzGjGnmmX/hgeaabH5kxo6qtCnnnHQOSUedeOap55589unn n4AGKuigXHmgFzcEjhGToYQ65QGjjUYKIgyx1SZpSTQE1cWlkj7D6aeghirqqKSWauqpNflB 2A+oturqq/+oYgOrTdjIOitNtd6Kq64X8oCQArwGK+ywxBZr7LHIJqvsssxq9kCz0EZ7GBLS Vmvttdhma5Ey2nbr7bfgApZFuOSWay5etlaVw7nstuvuuz/pA++89NZr77345qsvtgbsy9IR ajnh78AEF2zwwQgnrPDCDDes8DUOR6zjKVVFA2IiWYkh8cYcd+zxxyCj2YeAxYTsMC0mp6zy yu1tw/LLMMcs88w013ydPPXibPPOPPfs8894WgL00EQXbbTRK2hLwdFMN62tI8My4fTUDKdD 9dXxLVGv1i1BqivXX1k9nqJogd2V2GuavRXaaXvFNtZwX/V23HQvHAfRXouVdN2OPb8jaQh8 B16SDoIXbvjhiCeu+OKMDzVK45BHLjmgxU1u+eWYZ6750Kpt7vnnoIcu+uikl2766YjHsFQH pWWAeqhBWC7E60w2RfvtuFN0T+689+7776/1klYBwBdv/PEN2T4eor6JoiDz9EI/r/TwUv8u N9Yjr/32U93JvZ7BfC8+QlqMb75SEtGbvoABAQAh+QQAT80AACwAAAAATAFsAQcI/gD/CRxI sKDBgwgTKlzIsKFDgV4eSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLhAFiyhQo c+a/mgFo5ry5c2BNnTYJ4swZUyhRnAWL+tw5FOjMpk152oxq9KdUpUt/YuV5datTpkiXJrWa KOpWsC/TGjx7dKxQrnCN6ny7tifbuHXl3p0rl69Yn3/divUqGG9RwoFv4s1qt6fiu0HRqp1s uG1fmnAJKz17ECtkx4W57l3sGTRnv5dFgy78GaZjy2NLv/1sFzVll61TM+4sWaHswasTH37d mLXp4ItRD/ddHLjrvII3r4ac2fZtlrSfgt0evHRQ41DD/jLWSjxxXLNWrVfuynu89vTjv0r2 Ll3v3N7XW+YO/Bt6aP7lIaYcbOcdZ55x7Tn33IDJIbRcdN0ReNh96uWH0n5+9RedbhkGiNx6 o3mloWIAJnjfhwXq9aGHsSHF4mBZWTgZhilWuBmHNZ64oI4lXiaijxGqyJxwBCYlZGoTKkgh UBXKaBJ6VlGFWJTwAalilXtRRVpjVH4nIHpDMqjlV/Ktx16ZJPIloJMXosjmm3DGKWdI380p kj525qnnnnz26eefgAYq6KCEXhRDoYgmqihHhy7q6KOQItRopJRWOic//AyUqUCYEoTppJiG uqmoo27KqamnivpPp5pmquqq/696Sqqssc4Ka6uwqkoqqqmymmuoBfn6q7DCWgooq8De2uuk yja7qrPFnorrtMiiyquv1coKrbLZGhTttsSaWqu45Bo7aLWlttopqOVqCi2v0sYbb7ecBttu uOC62q69BxH7rrr7YguvuXwi+yy3pbI7rbYLM/wvwgoJLO+t0cZ66wv8egsvvhA3KzHBgeqa LMSNfkyrrRkPm6zAIwNsMsUbF7trwyenS63NM9MMcsHAjhvvoS9P/O3L9DosLcdHx4y00Qh1 ynG3Tl878M55ioyurTEQ/XDKT4/KNL34+hu1zs66i2vYu+o7MdWCmoy01ksv3HW9NH+Mtqcd Dz2wtf5qn823x/uyzbPcfwv9atzyon11zAznPGzi+vrc77iH/z234JhnrvnmnHfu+eeghy76 6KSXbvrpFvGA+uqst+76QSu8ntIAAwxUu0C0E5S77bT3jnvvt+/+e0HC/5678McDf7tBxeu+ /D/FR7/89LUj/7zxvkP//PXI86498N9nr73u4e+uPPbNj++9+s6Djz7616/v/PyTmW8/781b T770xMd/v/rp618A+Ye99WUvecPr3/zEx73g3S9/1DOe7diXQNyxT3r6oyAFETjBCgpwe+LT oEvs50D8NVB+0NvgCRU4vgwmxH0srCAMSTg8Dsawhd2j3wGrt8Iadg+C+/4DoQkN2EMcks+D zPOfEOsXvBQCsITySx8BUZhAGIpQh0rEYhWbWEIr0q+GAGRh9Xx4w+OFEYhlhKL1pCjEAF6R iiq8DfhmCEUZKlF5RdxiA734xCTicYtDdF8I0+hEM34wfPCLYxfL58AdavGCg1Rk/JB4Qw+6 ESHhGMkcGVhHSCbxi5Qk4RIR8j9Q/m+NPBQlKdsIxkMKsoiGNOMljUhES06Sf26cJRtBmZZN ipKOKOQhL3dJyzcyEo0+/CMiX3lFXOLPj6nspCKfmb8FthGPEfyk96IHR14ak4lRHKULUzjF UKpRmqaEpTDDyU4ROlOC2vTkF81HTe5Zs5btJP8kNynpzXKqxYVTxGApNfjHTW7zfOnUpziz Kc/2HdCbDS0oQp2YzB1alJPznCQjTTjKD/4SnSHxhuxGStKSmvSkKE2pSlfK0kjBoaUwLZQK YkrTmtr0pjjNqU4rYo20GGKnQA2qUCUyhqEa9ahITapSl8rUpjr1qVCNqlSnaqc2UDUl6LDp Ja7KVYbkIyVz6KpYKxWRgURirGhNq1rXyta2uvWtcI2rXAnFgbna9a54zatCWKHXvvr1r4AN rGAHS9jCGnZ0+UjsQBR72NMl9rFffQhjFcvYxpauspX1amQXu1nLInazlP1qZCE72sf+I7QC gaxnP4dZ0Zq2takt7Wn+XRvb1UqkBJGCLWxrO9vaora3tt0caWXLW+BOlrbDDa5wO1vc3R63 t5lVbkdk8afoAve6z4UubVMr3YXcgFLWzSxpOevb0lq3u+hNr+Cuod6Wsre9K30vfFMq3/me tL72LSl+TQqAzvXXJAAI8H/zI+ABD1ggB05wgv9RYAEzuCD9DTBBJDzhBjN4wQ2OsIMrTOED P5jDF57wQAp8EAVT+MIWRvCGR0xiFJ8YwivOMIs7DOESx7jFCC6Jhwks4mt42MAfDvGIRTxk Eb/4xUFmsZENAuQcF7nJNRayk3cc5ST/uMpMXnKRiTzlEhMZylz+8IKdLBIqt5jEG9awgWn+ nOYnZ7nGV84xkME85iFHWM5YxrOeufxfKgfZzHu+s0LATGYrD1rLXU7ynrdc5R072tCM/sij 7bxlDUfa0oEutKZ9rOg5U7rQdcZznzudZU83WtOIjrKgH+znSr8Z1If+dKIfPWkvAxrOYW61 RmrNaleHutdu1jWtVe1mMeca16P+sYVHzeplx3jGYSa2sXX951dDGiEpTnG0m41maEf622pG MrUxwutVm3rKDh7zqr2M6y8XG9iw1jKNt+3pAccj0aT+9rvvTG1CX1vRWF53nFOt6V+D+9/j vki5q71oc0N63dZetJjPLOt/A3veBxf1q5nN6FZznN8L8XeohZ3/6oFXvODbRrXAU94Rkzu8 4dWus8Gv3eQrKzjaNY94uSHOcIQnhONCJnnH8+zxkpNZ3eyOt6vfbXGQnLnNR3fxmiUsc5bj WMWEFrjBn030ZVdY6ivH+pGxTfWviz3pLo542jncYRybeOo3XnG+zy72mV8n4dh+CN5lt/eT 9H0kf19J4FEdciSndPCAN3xKEL+oR+T38ZC/KR0iT/nK31QYls+85jfP+c6L1Q6eD73oR0/6 0pv+9JA/A+pXz/rW37QMrm/dB0b6h9jbvqv2uL3ud8/73pO7Br4P/lAZIPziG//4yE++8pfP fM45YCKML2xRSeKHyWj728+HPtttfOKr/me++tZn+UCyLxGoo7zi0bct+NWC4YunmevIVrvR mwoBPa2f/UZOdsAJz3PCo3/z95cW7SdxdvcPSSBlWEd2QJd+FpIIHtEIphOAAkhxBHh9ZId2 pSZ+9iWBL1FrEPd3PEdyBThfHNiBGzd3xpaBYbeATfd4JegSHkh3bqeAMwZlbid3kfeCj8KA zfcmPNiDt9EPQDiERGg691CEE1ELDIF5Y5VwP4iEDeF9UTiFDCEAVniFAnGFWPgPWigAWeiF XAiGzTeCGJh3C2GFBIGGaJiGYsiFYfiFcyUDiRKDaMZm3Qd1rbaGcKiHcDgQXriGfLh8dOhr 53ZxCcGHatiG/29oEFroJEAgXTP4cf83gAqBiH/YhYu4hY34EkDQiZ7oiUcVBnCifz23cpR4 iG2YiAWhh6yoiERIijZoaKeIEJa4iH4ohq14UyjQJxdwd3y2dPAWjABQDkC3iql4icZ4i8r4 inIXi3J2g/Oma10IhtP4hZtoi1CobycRiNmocGmxhd0YjuI4juS4WhD4V09oVM8whxZogQ6R YT+Id29Xd+kIX0Lnf1TYclGIccFoe/eIbpKIgW3WZ0/XdvxIacO2e+5ocvDmZw4ZdPM3c/3H bYqHEq1gWQwZZxMJcJn2fxzJZLeWZ7GnZvlGcUW3fXQGdvgIY2Ynf5vDDjSVkQy3kf9Vl5Ih GXIpaIat92tIF3U/94s2uIIpB3ILN5I4KHXbt5LKVnbQRpBHVozeJmNrl431+JHlZy7GIFhP KIUVUZXl+JVgGZYggydiWZZmeZZomZZquZZs2ZZu+ZZw+XieEJd0WZcEwwh2mZd6uZcycgV8 +ZeAGZiCOZhPZQGEeZifswOIuZgIcQIrlQCMGZmSmY3n1SepcHuVuRCZWRCbSZeqNRGdKSfU sHufqV2dZVraxVuoeVzMZXxVcBLZtZqjVV7GtV3INZt2GZugxVyo9VzitV16qZvkNVuvZV67 SVyoWZfD9Vup2ZylSZvD6SeWYHm/iV22CZyYRZvE5ZmniZ3/xumdBCGbsdWakykQdVVcpIcL oBOamocL6lmeH/Ge8Hl7DjifNPUDosODXrkQhCCIXLmSepeUU6mA/sYR7ph5dseA5ieMP8l0 HkGGj6dueGh+ItePDApwjpZuE2eHcOdysqiNkGh0pgiMJ+eRvFZpLNh9FneKL2ePFKhxwWah KsZuIziDPglzPPmi05ZfGOZ1SAdyF6hkSoeTpSiiOBeRVhmiJSqUQGpr5weg+zZ0LLp/P5of oQASjoBSUxp2PRd/RfmlJDqiM3psawai3aVtFHh1BZqAKjmVZtaMWsePTtlp0Nilx7efD+qN yoenGfGf+ahS4mCfGiEOgSqoF0Go/8ZXe5GCqMinqHeFp3zKEJE6hYjnqG8FoXpKdwMKki0Z a9r3jkdZog5hqW3VopImpy04pqrqqVf5pw9ZqUxFDuQWc3eIcU4JaCH4cBnofrVqkLDoq5qq bybpWeZWiA63dR8plO3WpAzao2+WkvS2ZJM6VTlnojnJkYrHgnmnf1tKcPi2dQvKrIVVrTDH q6GKgCoKogSJo/nXbTV4dAdqZz6KkTrKpFBqiMdmhmxmpKf2rQGakGkhCkNlc/PXpcOWqw6K oR86o5RIrjxppNMaVTYHjSN3ru9XkBWqanG3oQt4Y8H6rjKYpKQXsYNJsoZ6siibsiq7sk7i p7MKkhV5o/8WwZAUYaNO57JiFakheZIbQbOtim+SpoFctXBEGbIXO3BTd3b81qtQWYoDaacZ Wna3+owdSqWIZrKvQ7TrKovk+ovS1mzWeoJcK7PYKqTOWq5SerXUam0tOqXYGqqS6LY6maLe 6qZhurAFV68S91REi6LuCrRM96JiCqDF+rcy6m4yO7goaK9ra7Vky2AXCbg+6bB4K7KmCmv9 dqPdemklpwaH21RI27ZIKrYAIAj+2rBN25AEd5MBWbnF6rhShrUkVZCqC7Iy56Fuyqxzmrp0 epAOCadWFq4JuJS1aqc76XQswXiya1g425WLd65/6ighwLLUW70X8Q3Wm73aSzD/RbC93vu9 ymWY4Du+5DsZulC+6Ju+6ru+7Nu+USWHFZEB7ju/9Fu/9nu/hMKE+Lu//Nu/vCcCBYEI/gtU 2DvAo3cCjgmfCLzACSwQDIzADtzA/+CYEPzAEjzBDxzBDNyYFzwQFhzBIIzBC6zBI+zBEgzB HizCJazCFZzBB/HBGEwQF/zBKAzCG8zCL+zCNTzBLJzAO8w5NYzCO9zCDUzBRdzBMWzDSCzD K8zEJpzELSzDT8zEQRzESQzFM3zEBjHERlzEOTzFISzEJ1wQXCzCKfzDV9w5ZbzGVkzGSFzF aZzDaHzFURzDQwzGJGzCXszGbozHIazEXrzFWjzFYizF/078xCtsxIIMOnyMyFC8yJBsx0sc xh0Mxyr8x31MyD78yI0Mxmi8xo8cyWWMxQoBykIcx6isOZ1sxzYcyVRcwjB8yJ/swpdMwid8 y2Hcymy8wbF8yK3MyqJswT58xE2MyRWsyzo8yYKzyscMzL7sy3XMwZj8x5YczLK8yay8ypIs zY7szNCMy6n8w6CczZWszGzDzBSsx67syYrMwb1Mx4PMw+ysxxlMzGkczZT8xd1sxtasyQ78 zPeczhqcyqFjyePMzwBNze2sz9NczW2s0HjczGZs0FnsxwEtzwj9zdf8z3580CM8y4xMyz3M 0dMczsl8wxGdxSgd0E1czd5MxP+JXM/g/MqnbNHw7MQ3LNL0XNOADMvmbMBAPXqDENREXdRB bQav89CjbMvD7NMAzcs6TcM6zdIxvdJMbcyZjNEwvdVLHMsnXcwWvdQuXTpiPMz0nNV3vNQp nRAOfcttXdJrnciZ7NTiHM9xPcZwXct5PM95XdBNrdB1HdEXndUEfdPGHNM4Pcm7nMLXbNaB 3dG4fMd9jcpibddkvclmTcp8/cwgbdMQ/dmFjMiKHdmhTMjyjM+DfdfcvNpr/dmoA9UUrdFu /M6pHcwrHdq7XMzjLNFnndMy/dSR3dXK3NmuPcejA9uDXNmuTNyFDcePHdpKzNak7c157NuE /djRzdCc2n3Ym306yM3Ub33GM93aDA3dwrzQ28zaEg3W3x3Han3Rkl3YlP3TIxXexT3G713b aJ3cwe3P6i3QGb3Z2M3c+GzZhM3drv3a8azcO43gZ93XLl3gXVzV7K3DCW3YI03bV23LFz7S Hm7fRh3i4igBIl7ik2EOJp7iSpV7KVufLyFSKh7jMj7jNF7jNn7jOJ7jOr7jkkmqPP7jpBMQ ACH5BAAdAAAALAAAAABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWFRi5q3Mix o8eECj6KHEmypMmTKFOqXMmypUuTSVAOekmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0 qdOnUKNKnZpzHdWrWLNq3cq1q9evYMNuLCa2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePMupKd3 Z7m+gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqCVrSM26 tevXsGNjjSO7tu3buHPr3s27t+/fwIMLH068uPHjcK81fYG8ufPn0KNLny53A/XrjC9h3869 u/fv4MP+ix9Pvrz58+jTq0dpaH3Ome7jy59Pv759ucLu69/Pv79/xMOs58h/eQ1I4EWLcLTD gQw2GFwKDkYoYWtKkATMhE5ViGFcGm74VocetgViiGspMSJc8yikiWLpeDfPiyTGKOOMNGI3 To045qjjjjx2BE2PQCa0TZBEIiZEkUgq9kWSTDbp5JNQNlRClE62R+WVWGap5ZZcdunll2CG KSZ4Y4xp5ploSiROmmy26eabcBLXTpx01kkXHm+SY+eefPbp55+ABirooPtRQeihiP7kTaKV 7cLoo5BGKumkHhlI6aWYZqrppmI9w2lFngrkyacQhUpqRKbGxtduqZ7qUKv/kfUCHqyuLkRr rQndOpkpuPbq66/ABivssMQWa+yxyP7KRbLMNuugGc5GK+20d+FJ7bXYZqvtttx2Kykd3oYr 7rjklmvuuYBugm6x6Kzr7ruJkQXvvPTWa++9ceHjLD76Nsvvvv0yGzC+BINWz7xlFKzwU2xQ 9kpaecT4ysN8psLSxMhinPHCHHfs8cf7HbOTByCflEnJ6iXjbDIqayYJyjAfVEHMNNds881s ooHzzjz3PK4vPm8kT14mBG300UgnPWwsSgN3YtNQqzVLkPE42UKYf0VtEidad+3ampc647WH q43tGQhmp6322sIis1MBzMId99zdbYGZ3M5RExregFR18ZIYCj3xHd/HEl6s4WwnrvjijDfu eFE5PC65UItO/qcexkVj+XFWba7YL56bNWropJdu+ulXIRLf1YmpLtGPppERm+vJ0l4n6PMK gPruvKsEYe/ABy/88MQXb/xiuvKYz/HMc+t289D310r01Fdv/fUXgYL99tx37/33TQYEACH5 BAAPAAAALAAAAABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP IEOKHEmypMmTDDOgXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOn Q+dBnUq1qlWYs65q3cq1K1UgXsOK7VhnrNmzaNN6Dae2rdu3cOPKnUu3rt27ePPq3cu3r9+/ gAMLHky4sOHDiBMrXsy4seO0hR5Ltrhtcs8RIyxrDop5s+fLmT+Lxok59OjTM02jXs26tevX d1XBnk27tu3buPey3asyt2+JvX8Ldxh8uPGExY8rX868ufPn0KN7/CG9usdO1rNr384dY7Tu 4MP+ix9Pvrz58+jTN0Wjvr379+H9wJ9Pv779+/i1zsmPvhT/nhv851EFOzUg4IEIJjgZEgo2 6OBvMTwo4YQUVlgVARZmqOGGHHbo4YcgWmZOiCSWaOKJDLWC4op5kcDiizDGKONkuFyVxYw4 5qjjjjz26OOPQDLUT5BEFimWF0YmqeRi1J00xpImNQmlU1JOyVSVViqFZZZIbcmlUV5+SVSY YgpFZplAnZmlMWai6eabPqEC55x01mnnnSDagOeeCW7Cp04A/Cnoe6kMulOhhnakj0aIJopT o45GKumklFb6YRqWxoRphnr2tWmmLB0h0KegtkRqqSud+qcZN6mqVR//qMYq64kXzGorhf7c OlmtuirXRq8m/QrsSMIOK1KxxoKEbLIeLcvsRs4+q1G00mJEbbUWXYvQO9h26+234IYrLnxx iBvLuOimmyMp6rbr7rvwxivvvJ6VU5g09O7ISL789mulE/4GrNAWAr+3X8EIJ6zwwp85oFMS DEcs8cQUV2zxxRhnrPHGeKnG8ccCCgHyyApjkikbPrlC8splisJyYZ+8LPPM0gZD880451ym CxnqofPPQMsqZ9BSBI0QIkYbx4u094CnbVy+JC311D5pQfXVWGfd4ARad82fqAzJ5/XYZJc9 XwcJo512kAeYXR4+CsMd98JyJ1w3wneHNGTWk+u47fffgAcu+OCEF254e5ccrvjijDfu+OM/ xwz55J7JQ/nlRYKB2NCYT8lF56CHLrp7fDiliZWlj6766rjlyvrrsMcu++xOoUz7ZpHcrvvu vPfu+1Ku/i788N09yWON58FiWNHEG55V89BHL/301Fdv/fXYZ//xJNp37/334IdfUBnil48m JEveaP767LfvfroBAQAh+QQAEAAAACwAAAAATAFsAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFiwM9YNzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CD Ch3qsAvRo0iTKl3KtKnTp1CjSp061QrVq1izat3KtavXr2DDUqUmtqzZs2jTql3Ltq3bt3Dj yp1Lt67du3jz6o1KZ6/fv4ADC0bob7Dhw4gTK17MuLHjx3dnQZ5MGS+Wypgza97MubPnz6BD ix5NurTp06hTfzanurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9OvLjx48iT+52nvPlUIs6j S59OfePl6tiza69darv37+DD/osfrzvC91bk06tfz769+/dAqcCf/28P/fv486O1r7+///8A 7iZZgASKdE5H4RSo4IJ1QQNULwxGKOGEFFZo4YUYZgjTEBp26OFQVn0o4ogklmiicU2cuFWK KmbF4keotFjTizJORWONUd2I40q3jKTjjk39CORSQg5ppEunHKnkkkw26eSTUA6lTZRU5iRE lViudUWWXHbppUiufCnmmGTiJ0CZ7rmD5ppstunmV2K0R8ybdNZpJ2jX3alnEXr26eefOUkC 6KCEQkfooRg5g+iijDaqFC6OjgRppCJNSilIll7qUaaaKkbOUWNA+WmnHI1KKkamnmpRqqpS xCpR/3yEFQpur7Zq6624zvdErrz26uuvwAYr7LDEFjtUgsYmm5gKyjbr7LPQRittYlE4ZMO0 2GY7Uj3a/oRGt+CGK+6C8Iz72SHTomuuSTKs6+67IvYDL5vMRluvpkdsdO+z+zrb77wAByzw wAQXbHBLtrTlwMHtIRFTYdJCDBMTdUocrcXJJkIQxs9yDFESDIcs8sgkl2zyySirhl5T+KTs 8stLwQHzzDTXbLNKHNys88489+xzc52U+Eq0KPxs9NEEBoL00kw37fTTUM+sKGrYvIwIYDNE rfXWk/3CNWMbfM1SNWKXbfbZcw0jEyNotw2uMa4Z2hvc0dINrd0yQhj2U4V4O9t3s38rG7jb hBdu+OGIJw7UCoo3TiAmjkcu+ZgFTF7sJ5YrNEXm9B3A+ef+jTAC6KSXbvrpqEtuSOo8tcv6 67CflmTstNdelwG2kzdK7u95wvvvwP9+T/DEFz+mKcZvBnK0y0Pb/LPPJy/99AtZQr2zriPF T2K1XO89arR8L/74lwYEACH5BAAOAAAALAAAAABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOirKSypcuXMGPKnEmzps2bOHPq3Mmzp8+f QE+WC0q0qNGGYo4qXcq0qVOnGZ5KnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2Jou2 cOPKnUu3rt27ePPq3cu3r9+/gO0uCky4sOHDiA2bSsy4sePHkCNLnkzZ5oHKmDNHhKW5s+eC pz6LHk26tOnTqFOrXs26tevXsGNTJiM7MpvauHPr3s27t+/fwIMLH84VEfHjyJMrX848q4/m hTkshRcSCfTr2FUqyc69e0hI3sP+i8ethnST8ejTq1/Pvr379/Djy/9MZ779+/jzc42qv7// /wAGaJETAhZo4IEIJqjgggw26OCDEALFT4R1TUjhXBZeGFeGGrbFYYdrfQhiWiKOeFaJJpaF 4l8d6LdiijDGKOOMFXmAnDM05qjjjjz26OOPCxUDJHz0DGnkkUgmqeRdOSzp5JNQRinllFRW qdEFVpa0TZZc8oZjl2CGKeaYUDpC5plopqmmco+sedw5bsbJHJZy1mnnnXjmqeeefPbpp1Ha /ElcA8w9I+ihiCa6pjCKNorfAo7+VkSklFZ6nzGWZqrpppx26mmOMXwqaoD8HdjmqBWdmh+j h6mK6kT/rr4aUaxivnUQHzPRKqtDuu7qa52q/CrssMQSK0OxDB2L7ELKLptQs84eBG20BU1L 7bXYZqvttgFygZER3IYr7rjklmuuTEGcq+667GpVKkHhtHuYAPLWa++9+Oar77789uvvvwDb O0DABBds8MEIJ6wwjHss7PDDEEcsMZC4IqqBSHxknOjFH2VcsaIcaxtytiNjW/K1J1ObcrQr O9sylR9PLHOWDMxsc1k23KzzsnDu7PPPQAct9FnsDG300UgnrfTSFDXD9NOfscRlr1BXjRgV DsnRHB5W31dP12CPNUTYZGc5S9lop92hBWq37fbbh30J99yFcQ1iCnRLFGzemMhpwbdA8W4b uLaDZ1s4toMHeu3hi//t+OOQN4iPfjggWkABjbEa+ea1DcU5dZyHLrq9n4xuMzHHga6Woaa3 7vo/E4gb+1WtIDn7trfjzpAmUnHTY+7aAo+t8MOHS3xhPbyu/PLME9VN89BHD30WvyriEPXb Yq+t9n4mYxL30ocv/vgDvavfKk4FQH7a+qzv/lLqhBs/TwEBACH5BAAbAAAALAAAAABMAWwB Bwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bOHPq3MkzJJKeQIMKHUq0qNGjSJMqXcq0qdOnUJkeikq1qtWrWLMmxae1 q9evYMOKHUu2rNmzaNOqXcs0Dtu3FttkFAK3rt27ePPq3cu3r9+/gMeWCEy48MpyhhMrXsy4 sePHkCNLnky5stVoljP3xKy5M07OnkPPBI2QkejTJUmXxIC69UDVrmPLnq3TyMEAtHPr3s17 sp/ewIMLH64wCsRAxJNn/KD8LCKlzJtLPxh9uvV/1a8//X01u3bl3r/+ix9Pvrz58yHPoF/P vr379/Djy59P33C6+vjz69/P/7S7/qH9l1cpAG4kYIGZHYhgZQouOFmDdV3i4EUQTpjQTwjd Z1eFFjbGYYcghijiiLiMaCJYxlgXxnUpnshYiy4qBmNUqMSI0owIhWDjjjz26OOPQAYppFZL DGnkkUgmqeSSTDbp5JNQ8qUHkm5EaeWVWGap5ZZK6sPll2CGGaQyYpZp5plXaoJRHWi26SZK Xrz5HRNy1mnnnXjmqeeekBHC55+A+nWAUI8EauihiCaq6KKMNuroo/oFAylPkk6qU6VK0bAn ppbexGmnNX0K6kyi7kbnqKimquqqMBXK6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivskD8M a+yxLiGA7LLrqcesBcxGC+tzwnoi7bXYZsvjOdp26+234IabK3Li9gZJuR6xga5C6q6LULsW yhMZvO4WRG+9+Oar7778slpBvwAHLLC0KAxs8MHGngJqDgg3jJY2Dkcs8cQUc3lqxRhnrPHG 5bXC8ccgawdEyCSXbPLJ4z3xqgbeCoOydSK8LPPMNNcMqQS6WdGRsjb37HO231ynzs9EWzpJ 0UINgvTSTDftNL8RPC311FRX3ZWfVmdtUijL5qNRKFwHHDbAYAs8ttZifWLjO2i37fbbcMft s1zTxTCeDhZdIPfelXzv+0zfgAcu+OCEF2744YgnrvjijGv2d+OxXgP5wdsEXLnlk8+sc8Cb 99s5v5+nJAWtoetber6nf0WmlqnX23psaq73umzeZG777bjnrvvune2yahW8By/88MQXbzxM NaBcy/HMN1+X0s5HL/301Fdf01TWZ990jSTFqf334LfHTvjBU0v++ejbtSJhqZzvcvrwYxwQ ADs= ------=_NextPart_000_000A_01C6ED7D.0B3F4AB0-- From kobcgylfmy@steinwaymusical.com Wed Oct 11 15:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjq5-0006x8-4S for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 15:34:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjq4-0006mw-8G for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 15:34:01 -0400 Received: from i11105.upc-i.chello.nl ([62.195.11.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXjpw-0004G5-D9 for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 15:33:54 -0400 Message-ID: <001401c6ed6c$47a0f6e0$690bc33e@woppa> From: "offensive" To: capwap-archive@lists.ietf.org Subject: fake Wariness nomans Date: Wed, 11 Oct 2006 21:34:34 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C6ED7D.0B29C6E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.6 (++) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e ------=_NextPart_000_0010_01C6ED7D.0B29C6E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C6ED7D.0B29C6E0" ------=_NextPart_001_0011_01C6ED7D.0B29C6E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable String prompt trade am Seattle uniform flies for Howard is decision bed =20 him angriest nov meeting Florida rebuked requests longterm saying. Bans cash transfer a firms Ethiopian women abused Americas or tightens =20 Cuba trade Bachelet visit torture camp Security. Content latest appearing special box and finally offer different a =20 because. Asia Business Health or Have of Your say in Pictures Country Profiles =20 Special. Green Summer pays is signs Joining Brady feels Celticsa big Donrsquot =20 itlocal Inside am Trackon deck hbo. Ringtone Xtreme Tones mono monotones Beautiful am Romantic or Ringtones =20 Lyrics by Song or Title is Artist. Letrsquos again in Itrsquos may writing or letter governor Maryland ted =20 niece am Kathleen Townsend Kennedy then governor thennew. Jr a Theres leather lounge skipping batting practice team sessions =20 place. Reallife seem sitting ontheir backsides using Gone contacts built mdash =20 personal touch knowing in community gossips am need Matlock Mercury or. Story calls winter am allies clear fielder desire string prompt trade =20 Seattle am? Football a Schools Thiel a jim Moore Miller Golf Hockey Motor Olympics =20 Education Webtowns Blogs Life Arts or Listings Movie Aampe Lifestyle am. Help Analysis in feedslet news am come to you with ec Africa Americas =20 Europe Middle East South Asia Business is. Only Posters ask History Tours Western or iexclen Espaol Gift Shop Sites =20 Boys Girls Draft is Jobs Super. Practice of team sessions place oneman players equal value of doesnt =20 isnt hearts minds teenage phenom am attempted Seattle is stage. Islamabad a Jakarta Jerusalem a Lagos London los of Angeles Manila =20 Mexico City am Moscow. Think future liar certainly term tabloid largely meaning when comes =20 grey lady. Miles blood closed issue who wear Another curious Reds am spring =20 training Sarasota in fla. Behind scene become weblog more than already experts bloggers very easy =20 is writer see submit article want send. Clinton busied is himself prison warn Rrated column morning least =20 justice Related articles of Bishes Heale ------=_NextPart_001_0011_01C6ED7D.0B29C6E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
String prompt trade am Seattle uniform = flies for=20 Howard is decision bed him angriest nov meeting Florida rebuked requests = longterm saying.
Bans cash transfer a firms Ethiopian women abused = Americas=20 or tightens Cuba trade Bachelet visit torture camp Security.
Content = latest=20 appearing special box and finally offer different a because.
Asia = Business=20 Health or Have of Your say in Pictures Country Profiles = Special.
3D""
Green Summer pays is signs Joining = Brady feels=20 Celticsa big Donrsquot itlocal Inside am Trackon deck hbo.
Ringtone = Xtreme=20 Tones mono monotones Beautiful am Romantic or Ringtones Lyrics by Song = or Title=20 is Artist.
Letrsquos again in Itrsquos may writing or letter governor = Maryland ted niece am Kathleen Townsend Kennedy then governor = thennew.
Jr a=20 Theres leather lounge skipping batting practice team sessions = place.
Reallife=20 seem sitting ontheir backsides using Gone contacts built mdash personal = touch=20 knowing in community gossips am need Matlock Mercury or.
Story calls = winter=20 am allies clear fielder desire string prompt trade Seattle = am?
Football a=20 Schools Thiel a jim Moore Miller Golf Hockey Motor Olympics Education = Webtowns=20 Blogs Life Arts or Listings Movie Aampe Lifestyle am.
Help Analysis = in=20 feedslet news am come to you with ec Africa Americas Europe Middle East = South=20 Asia Business is.
Only Posters ask History Tours Western or iexclen = Espaol=20 Gift Shop Sites Boys Girls Draft is Jobs Super.
Practice of team = sessions=20 place oneman players equal value of doesnt isnt hearts minds teenage = phenom am=20 attempted Seattle is stage.
Islamabad a Jakarta Jerusalem a Lagos = London los=20 of Angeles Manila Mexico City am Moscow.
Think future liar certainly = term=20 tabloid largely meaning when comes grey lady.
Miles blood closed = issue who=20 wear Another curious Reds am spring training Sarasota in fla.
Behind = scene=20 become weblog more than already experts bloggers very easy is writer see = submit=20 article want send.
Clinton busied is himself prison warn Rrated = column=20 morning least justice Related articles of Bishes Healey Supposed civil = of=20 inmahed coddle.
------=_NextPart_001_0011_01C6ED7D.0B29C6E0-- ------=_NextPart_000_0010_01C6ED7D.0B29C6E0 Content-Type: image/gif; name="USNieman.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01c6ed6c$479e85e0$690bc33e@woppa> R0lGODlhTAFsAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAUAAAALAAAAABMAWwBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPqnFhhp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3fpTH9evYMOKHRuzG9mz aNOqXcu2rdu3cOPKnUt3oaO6ePPq3cu3r9+/gAMLHky4sOHDiBMrFslgcVBLjiNLLllNYbDJ mDNrVjtss+eIiT6LHk26tOnTqB+mSc26tevXsGPLnn1yHO3bDW3j3o1QN+/fHQ8AH04cM4/i yJMrX868ufPn0FFKik69uvXr2LNr3869u/fv4MP+Oxwkvrz58+jTq1/Pvv1BJO7jyw/cZL79 +/jz61fvbb///1LdAOCABBaYHQBrpWLggtcBwuCDEEYoIWE6TGjhhRgS1FOGHHbo4Ycghiji iCTKpWBJGZSo4oostujiizDGKOOMNNZoWA825qjjjjz26OOPQD4oRZBEFmnkkUgmqeSSTGo0 QJNQHjnGbidEaWWQdzG3w5WpzXHUElyGKeaYZJZJWD9orZNYGGa26eabKikB55x/EUPngIEQ aMKdfF7ZSZ+ABqqVIIIWaqiBZxz6DzuKNjqUAI7aCE2klFZqqUFvXKrppkjSwemnoIYq6lqr wHVBhKWOGlGqqjrEapL/GOz0aqsLzUprQrYihwxm+EiU660G/QosQcIOa+yxyCar7LLMNkvS AtHl4Oy01F5ETbXYZnuRp83S4a1Nz2gr7rjklmvuuejqBUy67F5FwFMntqtiCcWtIO+9Lq6B L0NfOPvFv80CHHC/P8qyr2eEHKxwUcYs7PDDECcLWcTa+UHxxRhnrDGE02zs8cf/bPMdPNSS POwRCZnsrMrNsgzyyzDHLPPMTJFB880456zzznjJw/PPQMf1ZNBEF220o5wcrfTSbRG8Fi9M uxZN1OdOR/XVHd1SrdZbY8s1tV9PG7azY2Nt9tlop71SY2q37fbbcMfNowoeLiJ3UCLcrffe d8yFwDdSClQbuODYDk6t4VhBwiLifzfu+OOQ75R05JRXPlw5F09u+eZXb8n556CHLvropJdu +umop676QRas7hgirl84wQax1247ibbcrvvuJXnh++9e3EQ375K9o9YHxCev/Gb9Le/889BH L/3ndkyvUTHWjxkQACH5BACazgAALAAAAABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePFt+BHEmypMmTKFOqXMmy5cgAMGMKjCnzH80AM3Ha1DmQZs6aBG/i hBl06M2CRHvqFPpTJlOmO2tCLeozalKlPq/utKq16dKjSpFW5fo1aE6XaBFqJdp17da3Rc/2 PHh1rdGEduHCbcuTr1m5YuN2DQx46+Cwcw+PdZsXaNm0kBGf9Zv4cVy9PC9jvqs2M1vPfTPv Fe22sGTDoglv1qvaJuumpzlPrms6ssvGpFNbpWsZb2jBugt/1kyZ9eHXq48Dxu3b4OCk0FM3 ftvb9m3QZKlHVxwaqGqhn8f+enWK3XRdsGBrJxcvGbxR9lzHyz0vFXvZ6tZZMif+m7d/5/0R gVpzYeVlXn+dnRabbP+t59BwhHGX3GTq5ZfSfu0hGKFm/AFH4GwdhjhXhg0O+CGGznlI1VH2 2YeVhbahOJqCiJX3XYsfmrhcbgraKGGBwe2oIl1DCjdUkWy9iByMKEHlZHrcbXfcecCxZ+BU xnVXn3dTohfkjEDC52VW5UGJ3mXKMdnkl2q26eabcJrkXZx01mnnnXjmqeeefPbp55+ABiro oIQWmmchhiaq6KKMNuooR/zwM5CkAkVKkKWTRqpppZpSiimnBXVq6af/jLppqZ0aJCqlnKba Kqb/n5qa6qqquoqqraBmiiupj/YJ66+6sporqpcSm+lBsQoLrLGVhsrqsqCSKumyvA57qbLM Mmtrssf2+uevnj57arfZTqussORKG6616HJbrrnFmkrutchiq26w6Yrr7beelportNqi+269 81IrML3/npvtqwg7S7DD3Rqc7778yqrvwNa+imu+tAY8brDuRivwx7eOW63G7K5rbMcZU5xS MBrNarLKw1Z7b60F09ywyDvL6+zNECvkc8JE83qyy3bKDK6oE0+KcdA3w7rzyhfz7PTQJ2dN 772r+nw00nuGDHTI/gLdcNT9zhtwyuVS3fLCzR7LtcJiHwx2nXWffe6p/mY3LfLSIytccrJ8 68vy0UxrrPPQbt/t+OOQRy755JRXbvnlmGeueZ4dbO755wIJAPropJNkQWQTlK66RwMMMJDr ArVOkOyvt2577LbDTjvuBe2Ou+y7A5877Ab5Pjvx//iuPPHMux488r/fnjzy0Adf+/S5Yy/9 9LNrT/vw0RvP/fXjH599+OFDT/7x7Ef2/fu1G/9898v3rj7847eeekLn21/A+v17n+6cN8Di UY+AzLPf73gnv+YtMHbl493ryre8+UUwgsLrngQNWMED2kaAG+xfCKmHwerdr4DP2x9CRLg+ Cm4PhNzLoAHZ90IFYo+BJqSh9RpIPw9Gj3w8/rye8lo4QxtuMC3fS54E8TfCIh7xgvnbHhTb J776RXGJSoyhFNvHwPzZ0Hk4NGIMvRhELl7RhVX0oPieKMYjrrEl2QtgAQF4wuHl8IsNZOEZ zQe+PcZRels0I/C6aD/hCfB29UOh9wYISB8yUY+JVB8bzehGScIRkS+cYxPFWEYgSvGNSzwh FTX5x0OuUI2E5KP2npjILoJSi6Os5EEieUqFpJGSaCklI/vowh5S8pawnGT6OmnIPuoyjE4c 4wNVeT5ignGB8tOhDu1IRFkOUZhsNB4C8mPBEtLRl0QEJv5AacUWynCTvYRiK5fJxW5usnkE 7J00Q9lOSdJygthU/6cPP+jASp6jko38Jfj+KEReylKQ8fwmOtPYTFymc5EQhWBBm0lROdbz lHL8pCWpGdFXru6jIA2pSEdK0pKa9KQoTalKV8rSlroUdGV4qUwvYoyVxHSmOI3TTXPKUzXt tKdAtc5Pg0pUtAy1qEhVSRmO2pIQJPWpUI2qVKdK1apa9apYzapWt8rVkSShq2ANaSfCStay mvWsMEoDWsmagbXK9AhuNasULDSCuNr1rnilWB4+Koq8+vWvgA2sYAdL2MIa9rCIRUs+FjsQ xia2dIuNbD4g4ljGOvaxo7vsZRmy2X90FrOb0+xkLSsQyU7Ws5FFrWpR+1nQTk60rB3taf5X W1nZ0na2rqUcbGFb2tPWVrW/zW3lTOvb2fL2t5Y1rXCHi9veNta4xXVucpeLuc/y9rbStW1p qfva5q62t6l1LnCL21rumve86E2vetfL3va6973w5RMAJjdfkwDgvvW1EH7zm1+B9Pe///3H fvHbi/4KWMAALsiA53tfgjB4wAhusIPx618FK7jBEq6wfylsEABneMH85fBAIBzhDF/4wyQu sYZHfJD9jtjFLCaJgfXr4BWvmMEvrnGMbXxgE5v4wBeu8Yz5u2MgE7nDG9bxjC1sYwM7OSEB DjCTNbxkKR95ykbWMZBBUmUOu9jLEX5xfR885hgPGclPrjCRr/685Tb3OMtpFjKLz0xlhLDZ zFvGsULu3GYp21nOeHbzm7GsZToDuskjMfSg84zgIvd4zYHW8pynrOdF+9nNOC5znCetZiTX +c9LhjOnoezoPkva050O9JkVbeEqo1nSoc6IoisNaUdXWtSkbjWTj1xmU9t60LcuMYbrvGAV 39jHue51sFE961OfWMIpLjWZKRziSzt72pvuSLOvfOsxU1vJgr42pm9M7ks/2ds8NnSmPX1n a4O707EmN5bdDWtfS1vQmw71quvNZVRbetT/tnK4751mEtca0YCGNqEZvWxezzvZk443ox9e 6npbe9+Epje+7T1wjeR74osOeKGdbf9vhx+60b/+9Kln3fAdmxviOe44x7Md6yi/29euLnKc Ba7zksD45y4Xtpi73fMWi3jD7e6zu0XM6mIn2OmFhjGPxaz0obd4wj/G99GFznWlo1jq0c43 06Uu88hIfM8POXtI1Z4Stvv8TW5f+EK2btK42zfrbY+v3l02jL2TtO9+HyngAx/SwXdVDYRn 0hYSz/jGOz4hYkALBB5P+cpb/vIq1QTmN8/5zsOXBZ4PvehHT/rSm/70qB9dF1K/r2aw/vXm BQXsZ0/72p9VrbZ/7Btobwc8uSP3wA/+Szsn/I/YvfgeifbUJ+LhLn/9+MhHOEfAnPJULz/6 c5eznn/O9Kv+t5zUGsd+rtWsaYq7Wt9oD7/4rz7qYKsf5VQ3eq+vv375K9z6SKd7h3MOapLX n/0jl20M8X39V3H5QQOB1QDaxmzjFmnah3OI9n7/N3W85mXdJ39Wd2zPN4HWAX0c2CYe+IFw 4ggiWIImeIIo+GcDmIJcpn/Zt4IMIQAyOIOhM4MyWIM0+A83qIOiI34SKHf+hhA7WIM8WBBD qINFmITYp24qBmZjd3+xdoQ3eIRKiIQ7SIXFx4TcBn9EN38GIYWiQ4VYyINjCCONsFxgl2Xl dnLL9oU9SIQ2OIU9mIM2KILlB3JdeHJC+IZFKIZvOIRl6IOptoU2B3B7SBByaIT/f7iI/+dn W4h/edhxYFiFSgiIfOiDR/eIj/aEyqYQcTiHcYiDOUiJdugSgThYK3A3IZgRo8iCrviKsFh/ 7BCLkbOKnldsWId3A4iLGMF2zZd/ush58faDKrgRakd9+Hd6+RUFQeht84d+WDeI3AdtyPiA usZ6yteA7VeMreaFRMdxhjhnZId6NLdrHYd+bPaNx8h//jd6ZNaAQFdzzwZym1iNe5ZgAEiO GTdxbSh9tKaH9HeNw2h6F3dzfMZv/5ZkPLd869ZsmWMGJzWOXWdsMudk30Z1zoiP+kaN02iL r+eRQch8tAiEzOeCEQGSdpUDp3cLI1l7vWBX6ECLyBB6/4LQktZxDDaZkzq5kzzZkz5pITew J6NwgkH5k/lRlEZZEOXAEkhpG97Vkk0ZGU/JU+tQJ5MwUlOZlCuRlVqZElzZlWCJVVwAlnW1 L8xYfP8UlmrJgjawlm75lnAZl4KFgHJZlxIRD3bJJOOQl/FVXnxZEH6pEIFJEIOZlJIlEYXJ l4eZXbgVXtN1W9HFWmoZXI7pW9mFXZU1XtsFlpQJXYBpW8jVmNo1mZF5XIdZW6JVmolpk8T1 mJr5mov5XN81m0a5Wa75mLdpXJcZmVppm6OJmrlJmJ35lX/5mcUJEqvpVlpwnMzZnKE3BKlH Cn6CexYBkijpitlogCeZixkIZf8XmHwSyXga55HV+I356IXT145+Z2XUB3TyZo1sSIH7N2wZ SX7V9mOFaH3XKVj5+Wb5yWf9qI4hmWfeyIXg2J//eFLEYCgGB5+iFqA5p35p+J4hZ57AiHD9 mF5RBmECum52ho/gCHP0GInpFp8hFxF7dVj9CYnwdo5qWHQwqIkVeqAmmqHohaAzSqEP6JA8 GnQAR2sfF2LaqaFg156ZqJ0W2JEVR3bDloHs6X5FmqDCt5/9RhFUWnlX6nEmCYPO2aVe+qVg ehFZGpD2ZXZlZ1jEKJLdGZ4xl2RcehD7wI1zZ5I2iqb0OH33x6IfOmENAX2+6H91Wlj/yIny Fp4eWqP/rwZsnFifisqoEul8d5hbQPqjDCdu6HhznHaoM7qh7Aaj8hlxwmVyerp9JId3BVqA mkqiJ6pyS1eeq5pYopqj25ed8GegSOqmqopt3YaMvOh9HHqmg9WglApsffqi0sdukbqpDMiq abdxY8pV52aiI/pqBGis8vmfJCqqBUmpgWohTYBS5xal5uaCSVqu97ZrT2hk5Tl2+Wd/Tgqs lvesxXl8rBCm9nqv+Jqv+ioobCqm7jp+tiiAJ/md2tavYSWv4XaQZAoRAtusDpieQwqt/taQ 6qpw5jpySNeumfZ86Pme8XinQ/ZtjhpmF2pxh4awI7Vt6GZqH8aQ57pmB2et/4UqZM8od0LK sjEbpCebVdvmo6P6r+bIohLqgKq6pj6rrLbmnsSmVT2rgRepcpiqtLmafffZpMnYqRQ6tSaL ZyibshOLh1+bsJFWsziafud6tUE7rWXbcwLXtV4bdWA7rPxXs5Xafh2rn3rIjnTLsiers24K r081jQnZriX3cRRJn0rWpPLIndo4jzn2izhntSUbZgr7XkhQEVfqtur5gvGFBJ57uQMbjJjb dlvKuft6upezeERFnGe1Ba77uq+LurK7Oks5u7ZLEClwu7q7u7zbu777u8CbKDATvMRbvMZ7 vMibvMq7vKc3lsz7vNAbvfGFCcZLvRYhBAbBAMdpvf/wRQIjxb3BC74ceAInsCfiS3rkm77l OxDqS74C4b7s+w/u277ry77t+773exDwaxD0i7/+K7/qi78BbL8Esb/yC8ADjMDpq8AGXMD5 a8D1K8ALDMHlO8D5WxD9C8AFzMDr28CRs7/wS8EIHL8gHMEE7L8ejMELzL/1O78dXMER3MIm nMArfMAl/L8nrMEq7MAj/L76K8M8rMMQvMMEXMMwzMKWI8JKDMJI3MQanMIOnMI3HMJHHL84 LMH228I6jMIzDMREzMVa7MQiLMQx/MVPzMQeDMWOs8Q8XMUmvMVBfMYKQcVi/MJ0/MNBHMJC DMcu/MVpHMMVvMd1nMcvPMf/gGzDHQzHVyw5bFzE/6AC8+vEUbzCGUzILEzDRpzAfFzIB/zE m8zBoCzJkezJdZzBJVzDOUzKkWzKbww5jYzCsGzGOdzHCXHHcXzDeHzFd1zIVczFOwzFShzL fnzIirzIwezJf5zEh3zMPRzHt9zLl3zBOIzLnTzNMty/1/zJDWzLzjzKzfzMllzNiszME9zK l4PL5JzMg6zGYzzLQPwJ4kzN6dzL3LzF6izMqOzO4UzMqezN5SzJi9JXD1HJoczPqZzFlCzN nzzJ7czA4OzIRXzB2GzQEqzHB23NbZzQ+VzRiRzRFmzO0hvSvIsKIo0RqVjSKJ3SAx3GC83R Fa3L/13swpoMygQN05g80wVdxrfs0eWM0y790qEM0C1NzZ5DxZyswMO8wQ0N07XsxZssz0ct yjDM0v+b0OPs1P0MzVg9yVytz4usOUZtzdu8vucwxEvd0oNs01hNy7kMxlZ8wlY91s6szTpd zHM91FsN1onMydzsvv90z8V81l5tz3y9zCAdzBYN153M1kzdzdB813fdzkRd1D3txRScln9c 02g9zJq8y4Y908fszQiN1DRN0a8sy6gt2Xmt1zJt2fwM2LB92EAs12Sc0U3dxsI82h9txrTt y239241N2KQTwB9dyUSt1W8s2BhN2BNt2wgxz9FM2r191c7tw18d2SA9Un1Q/dB8vNnePdh9 Tc9RzduBLMBtPdmTTdcbfN0XrdoXvTnbPdgOvdkD/ALs7MVkIMc8fcobbcqQDdXErdAIzd8U PeB2bNXLrdLvdYkK3uCm95IOHuEqrQcSXuEWfuEYnuEavuEc3uErwQceHuIiBXqPFQQiPhLq cOIqvjoBAQAh+QQADwAAACwAAAAATAFsAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tyZ0xPPn0CDNgtKtKhG KEaTKl3K9KevplCjSp1KtarVq1izam0pbqvXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67d u3jz6t3Lt6/fv4ADCx5MuLDhwKIOK9YpbLHjigNqNn5MOSkhgZMra97MuTNgRJ5Diz44b7Tp 06hTq17NurXr17Bjy55Nu7Zt2KZuo+ygeyEWqu96Cx9OvLjx48iTK1/OvLnz5wqpQJ9Ovbr1 69izww6kPeiJ7uDD/osff1eKzCs3NZBfz769+/fw48tv/WK+/ftlbeHfz7//T2XK+CfggAQW iJoIBiao4IJl8cDggxBGKOGEFFZo4YUYZqghSjJs6CF7o9Rm3ocklmjiiShiV0OKLJK3Rosw xtiZJDK+5UKNOOaoI1Dp7AiTGCSl0+NM7Pj40ZBGaoVkklgtyaRVTmoYxFQlXJTOEU/qVCVF UWZpUwlbDsfPYAZ4aSZG+p2p5ppsOmREm3DGKeecdCK3TZ145qnnnnz26eefgAZKXiqCFmro oYiqFVyijDbq6KOQRirppJRWaumlmJY0S6ZlEcPpp5OOCOqocn4TUT75kCoSqr0l4Ryr/6qC hGqqsX5Ea6245qrrrrz26uuvwAYr7LDEFmvsscgmW+edyjb71ifTcRdoI6zF4uy1Fi6A7aGW bDuQOd6GK+645ArETLkaGmJIVtLKNQa570bqqkrxiltvuPc2qt5K+W7b72ghlBswutAlQ/BW eRys8MK0kcDwwxBHLPHEFFds8cUYZ6yxiVWQ2zFq0oX3sbgjh1vydYmwdvK2K2Pb8sYwj9Vt zDTXLCcGQY0wHig29+zzz0AHLfRxfAxt9NFIJ6300kw3DdgQTkdtW8pMFyD11VhnrfXWXJel CnLqPLxF12SXbTanhZwd2ytqt+3223A/bEPcdNedUQZ2511oGnp6A0tj34APZ0fghBdu+OEM glDxKog3Tm430xns+OSUV2755cJVolgwmHfueWW40LzITPc4h4lptXyu+uqst+766xmWA/vs tNdu++2z4W0xDrj3rpA9vgcvPFZzDG/88cgnr/zyzDfv/PPQRy/99BjqTn1Od1yv/VgBAQAh +QQAEwAAACwAAAAATAFsAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaNC RB5DihxJsqRFfiZTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnwSbAB1aUhPRo0iTKl3KtKnT p1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp3bEQ/du3jz6t3Lt6/f rC3+Ch5MuLDhw4gTK17MuLHjx5DFbotMuXLja5Yza97MGWG0zqBDzzUnurTp06hTq1691YbH Lqyd/olNu7btggtui9Snu7fv34QdAB8e0x/xiXtUBzv+MDnz486fD48u/Tf16lKjcL2O/Tb3 7rW//oOPLX786vLm06tf35uMYCjs48ufT7/+UBP21wPK3zUNf4LO/JfVKAIWaOCBCCao4IIM NujggxBGKOGEFFbYGAYWZqjhhhx26OGHIGoVT4gklmjiiSgiZVSKMl1y1Ios0gVjjHLNSCNc NuJ1BYk53tiWJj1aGIKPGdpB5JEhVYDkkkw26eSTUEYp5ZRUVmllaLldqeWWXNZHS5dghinm YKmMaeaZaKap5ppstjnhjm5CBWecTs1JJ1NX2Hnnnnz2ieIifgYq6KBeLUHooYjKtF+iPi3K KE+OPqpTpJLiBAillWaq6aacdurpp6CGKuqopJZq6qkCcYHqqhHWwOqr/7DGKitPq1gFxqy4 5qrrrrza5OqqAfSaUbDCYkRssRYdiyxFyi4rUbPOQgRtZIogOK1UTFykwW2ALnXtmYt0y9S3 Yoob7UPmnstQuOqiC6qSL6Xb7rxwiUHvvfjmq+++/PZ7IDn+/jUCc9oEbPDBCCes8MIMkzSk aIw0LPHEFO9qT8UYd9hGxhxfVEUVvHrS8cgkl2wyU8csnLLCKyfcMsIvHxyzwTOn9o56Nfub 88k89+zzz0BjPHBDsfgYWNBIwwpb0kz7lkPT3fUA9dRUV2311WHegvXWproY2zeJjcj12GQD B0PZDD6ykiBmJZGw2wjDnVMejMptsN2PDYD23qJ89+033yX8LfjghBdu+OGI2+ZL0Mgk7vjj kN/rX+RkZ0D55Zhn3pkAmnc+2C6ehy766KSXbvrpo+uB+qjYrJ4WMXwK4/rstNdue5MW3K77 7rwvVGbvwNMmRfDEF987EDjRfbXaxje/mGvOR//QENJj9KVEqFSv/fbcd+/99+CHL75flHTW +vjop69+tPCt7/778J9sDJrVxH/6PV29Yb+kAQEAIfkEABoAAAAsAAAAAEwBbAEHCP4A/wkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qc SbMmSHw2c+rcybOnz59AgwodSrSo0aNIkypdyrSpU4UgnkqdSrWq1atYs2rd+s8B169gw4od S7as2bNo06pdy7btQ01u48qdS7eu3bsb/eA9SWWvX64y/goeTLhwzDGGEytezJipuMYKh0A2 +niy5aaVFWe+vHTzWidr7yz2zLm0UNKmU/tErbq169ewYxvEILu27du4c+vezbu379/Agwt3 KGC48ePIkyvnPGq58+fQowP9Ib269etYgWDfzr279+/gw/6LH0++vPmIu87vTq9erQWW7F8X al8wPv3a9u/Hzq+/P8JG/gUo4IAEFmjggQgmqOCCDP7GT4MQRijhfYpMOJIQFmao4YYcdujh hyDSR12IJJZo4okoDuROiiy26OKLMMYo40RFzBgdIDbmqOOOPPbo43jE/CjkkBGqINIGRCap 5JJMQohCk9ApAeWUZX1C5ZVYZqlVBlp26eWXYIYp5phY1kLmmWimqWZF/qwZ4gluxinnnHTW 6Rs2duap53Zc7jkTGX4GKuighBZq6KGIJqrooow26uijkLo5w6E+RGqppRwYqMylnHbq6aeg anlLqB9ZQ+qpqKaq6qqstrqoLP+uxirrrLTWilEWtuaq60q47LpQr74mBGywBw1LbEHGHqvs srydwqxAzj4bLbPTLlvts9hmq61iov2WyLfggiuYFzLdYa5V/egGWlnmdkvrBQid+1or20a0 Rb34HhtYvvz2K9I7/oaaTMAEF2zwwQgnrPDCDDfs8MMQRyzxX4zg5UuJFWebMbYbP9sxi020 9fGyIytbslmTbgdFTicTy0jLEBk58cxfLUPzzTjnrPPOOr3C88+pngP00EQLCs9t5RStNE9w LO300zRDAvXUVNtqZdVY57ZC1jlBwzVjpZB6gLZjqxqFRWVjm/azazPb9rJvc7SiVlFZGHdy gEJ3N7Gee3/t6SB+By744IQXHiwyhieu+OKM+xnChpM0LnlJm0zuEQuWZ55Vupp37rlG8qAo iIU5cCalgqVnmzq2qz/bemG6kK7t62DtwSPtyuaA++e89+7775ODAvzwxBdv/PHIjYD88sw3 7/zz0LdmROJmqkRI9Nhnr/323Hfv/ffghy++RCKMbz7QUp//UzDqtz8SAe5/zU5M28Rv//1j BQQAIfkEABYAAAAsAAAAAEwBbAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rc yLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSfMhkZoJ+eHcybOnz59AgwodSrSo0aNIewpL 6Sup06cHy9C8ALWq1atYs/4MpbWr168+k2TUALZsyCcpkZhdy7at27dw48qdS7eu3bt48+rd y7ev37+AAwseTLiw4cOIEytezLix48eQDWKJTLmy5cuYM2venDkO58+gPRoITbq06dOoU6te zbq169ewY8ueTbu27du4c+vezbu379/AgwsfTry48ZqKjitfvlEOc6HuTBJ6Tr269evYQZ/L zr279+/gl/4vJeps8Cuo9GKXD896PXvV7vWOYwsmdfz3p+/jh8qD/H77/6GmX4AEFmjggQgm qOCCDDbo4INGbQDhhBRWaOFpRVyo4YYcduhhQsR8KOKIJJZ4YR8mDoZiioGtyCJOrsjk4ot9 zUjjXjbeqOOOPPbo449ABinkkEQWSSI6vlVi5JJBrsDkk7QRAOWUtb1A5ZVYZlmgHVp26eWX BqbT2hBglmnmmWimqeaaOAHA5puz1QfnnHTWaeeBeNypJ2/97OknbHD8KeighBZq6KGIsiZW oowG9UejkEYq6aRaUkHpXvpcqummnHbq6aeghgaIoZeEauqIo56q6qojzrNjG/+segQrcAcI N2usG7VxK64KKcDrr8AGK+xRBQxr7LHIJqssjTMsm2IzztIkTrQNTRseB6tZS+22QE3G7bcD 5QHuuN5xo+weDaZK7rrstuvuSBXsdV67r8zLrr33vovvnYHutC+5/74r8MAEAytJsCboiEjB DDfs8MMQRyzxxBRXjNFNFmfMozoad+zxxyCHLHJW2oy8bBeTBmLyyiy3DBQNRbbi8sxC3kHz zTjnrDNjuHQEyc5ABy300EQXbfTRSCet9NJMN+30jTU8LfVpRkyNGwxWZ621Ub4GZY7AX2NJ DVhhv1u2u2e3mza7a6/b9tZwx80eJXLXbffdAy3Q7gKOfLPbd6xUWfQ33oQXXmYphv+znbuL My5w4+xCnliMFkpOruWXv4v5uJsnXmh/nocuesc3jG766QfNh7qDqfS4hcCvM8oGTLG/W7u7 t7ebO7u7oy4Vt1CISMvqxBdvpxDGJ6/88sw37yXWzkfPLih2qiv99ap1gv323Hfv/ffC6gD+ +OSXb/75eSWAfsYBAQAh+QQACwAAACwAAAAATAFsAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIUQbHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzg/2snJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtapVhSuuat3KtavXrxWZKU0DluuasmjTql3Ltq3bt3Dj yp1Lt65diTXu6t3Lt+9RdH4DCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6BD ix4t+ADp06hTq17NunXJUDVTuJ5Nu3Zh2LZz697Nu7fv38CDCx9OvLjx48iTK6frZ7nz59Cj S59Ovbr169iza9/Ovbv3xjG+/osfL9INecnmz0dOr/4xe6jT2sd8L38x/fqI7+M/rH8/4f7+ DQZggAQWaOCBrF2C4IIMNuhgXTQ8KGGAZE1o4YUWkoPhhhx26OGHIIYo4ogklmjiiW9VguKK LLbo4oswxijjjDR+eEKNOOao445CySLiPk6Fx+OQ38FB5JFIJqnkeB0smVSTTh4FZYzXWDVl lERdmdsFvGmJZVBefvlTmDTlJWZBZJ6ZU5pqtunmm3DGKeecdNZp55145rlZEnpeRE2fgAZq m1g0MSHooTOyguiijDbqqFGdPCppSQNOaumlmGaqaWR0bOppcV18KmqDroyaUammXoRqqhWt yupE/67iNM+bsTY2xqu45qrrrrz26qtUtf4qbJ03Dmvsscgmq+yyclnA7LPQRivtjlRMa1R8 1hLGZrYrGTkVMXSZQh0v3Jb7nDY2caBWNsZp4+6775or77z01mtvVUvc66AWR37C2BZqnaXv YLgNbPDBx1KA8MIMN+zwwxBHLPHEFFdssWtZXIwYuxp37PHHIIf84R0ZCSDyyShTVcpaHKfs ssYivCyzo+gG55FPRyjryMw813fPx831DOgbQhdtdIFl0GjF0Uw3/ZbATperRtRUV211fRVe rdcoWk81wV4YdC322EltQ/bZaKet9tpstx0XCG7HLffcmbJhrd3T4i2t3qXR8g2t3yopICgb gNNtOI/yLOvL4Yw3bjE7jkcu+eSUV2755ZhnrvmGxqCGbXKdSxs6tKPPVcSFpR+ZC1Kpq1e4 Uo281Pp5rws2u+uI3d5e7cnyjqzvxwJvrPC5OTMb8bQZH63y0DL/lC05Ov9pHhZJv/n1N3ET FwzYd/8hYN6HX2491pI/bT3mS5s+Qj+L737Icbz/VSvy108SBPbnr39hO+3vYkAAIfkEABUA AAAsAAAAAEwBbAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4oc SbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qd SrWq1atYs2o1Gmmr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt4pRrJy7fvRwx+A78k ILiw4cOIE/vlpbix48eQI0ueTLmy5cuYM2vezLmz58+gocJ7uCu06Y6lT6vGmHo1XQ88d7V2 Tbu27du4c+vezZvikd7AgwuH2Ka48eFx5clsk3s28ufQo0ufTr269evYK5PIzr37VXrYZf55 H0++vPnz6NOrX8++vfv3FGHMhQ3fo636iTXh38+/v///AC40QoAEFmjgTiYcqOB6yi3o4IMQ RihhXoRMCFeFFrqFYYYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLEBoC41UyDiTfjAURo1SN OE7FY48WZaLTj0A+RWSRTR35VDlImghIk1BGKaVPWKCnzJRYAglHllx26eWXYIYp5phklmnm mWjOVE2abDq2xZtwtsnTFnLWaeedeOap55589unnn4AGKmiZiQwqGAjImWHoooyCeECjUfoA 6aQlPemeJJRmqummnHZak3jTFbCnNp66xEKpqKaq6qqsturqq/+wxirrrLTWGiIYtgYGyn44 5Orrr6VCE2sVEwnLVw0FGpvSLINCoyyw0EZ7nQWX7Srttdhmq+223DZWR7fghivuuGuRQe5b N547Vxfqtuvuu+5lIVAT8NZr7734mvZFvvz229A5/iooqmdrBmzwwQgnbB0ACjdcly8ORywx nvJObHFi/VyssUdEbIwVtd1aALLHQE2QkQEk40RByizzyWzLMMcsVgMy1zzrNNEVajNYuOzs 889ABy30oAUPbfTRSEu2DLhLDxRM0tZ1DPXUVFdt9dVYZ00yw1p37fXXYIct9thkl2322Vzq iPbabLft9ttw54lO3HTXbffdeG+bwW54auTNoRt+Bx5TCjmlGxSx2yKureLZMo6t4/4NkRfk aGZcE+VqzXAYc1lhDq3nwIL+q+iCl2766ainHjHODLWg+uuwu1pE7Lx9QPvtuKc0BVw05C7Q Jr5LSTPSfqCaSvDIV2RP8sw3j/QAzkcPkQzSs7179dhnn1NAACH5BAAWAAAALAAAAABMAWwB Bwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo0eINj6KHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0pLCiSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1 q9evYMOKHcv1E9mzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHkw4Y5/CiBMrXsy4 sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs36n6PWsGPLnn3UstnZuHPr3s27 t8ggvoMLhz1guPHjyJMrX868uXOolp4H7iC9uvXr2LNrd4lvu3eqDr7+Nw4vfjH58onPo/dJ jaj69YPfww8sf/5fB/Xt981P2BbSW36Zot+ABBZo4IEI/gNHggw26GBPFTwoIV4CDGbPhBhm qOGGOy0QFHAchijiiCSWSJg/Jqao4oostujiizDGKOOMNGJFXY045qjjjjz26OOPLkkB5GBJ DGnkkUgmqeSSgP3B5JNQmgZAlFROFUmVWGap5ZZcdunll2A2x02UAYRp5plopimcLmq26eab cMa5UwNy1mnnnYU9gueefPZZFxl+lgRooCMNSuhHhh6q6KKMNorZFXtGiOMZjlYa1g+5HWPp pkgiw2lC2aRWXGyhflpRqaamquqqi3YBJiv/rMYq66wMAUirQ7amdiNsuRIGBHq39HrrsMQW a+yxyCar7LLMridJs9BGe6gC0lZ7ZwzW0oVAttx2a+Yr3oYr7rjkIvWEss+Wq+667M42x5Y1 wKZNu/OhGK29zeKb757noqRvYhl49++P/S41sLIH96QClQnDh0hfDdMrcZ+oTmzxxRhnrLFF sSDox8Ygi9RCyCSXbPLJKKes8sost+zyRhi8LHOU6S4qaVijzqzzzjz3TBADCQnp89BEF230 0Uhj5kLSLh7G9NNQRy311M1RQfXVWGet9dZcd+11mEt8jSYLYHoj9nXynE1VJ9Cy3fbbcDPr dkcQpLSGknMvm7felXFLWKbagAcu+OCEF244hq0crvjijDfu+OOQRy65Td0F181fRATXRqyi 9JxOS7/U+Tm0o//jzLKlV1rHRalbN81jrSsbe7KzI1t7YUfYNcvuvPM+eWmL/G4ZPaY1oRvx BHIwEtBOxZwQ8ncFn5IIvEEvYiVqWb+s9spyD9UgO3qPrPjCl2/++einr/767Lfv/vvwQxQQ ACH5BAAOAAAALAAAAABMAWwBBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix o8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnNlxHM2bOHPq3Mmzp8+fQIMKHUq0qNGZQY4qXcq0 qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt2vgO7q3cu3 r9+/V7sBHky4sOHDiBMrXsy4seOj5x5Lnky5suXLmDNr3sy5s+fPoKdKCk26NNNwplMLVKL6 bTHTlVrLnk27tu3buHPr3s27d19uvoP/1SW8uPHjyJNfZae8ufPn0KNLny41G/XrHq033IO9 u/fv4MP+KwYivrz58+jTq1/Pvr379/Djy2dJ/CkdxpbmD86v3y///n39J98l/gGIEQFjCWig XQouWFeDyLXyGYQ49eHghRhmqOGGHHbo4U2bfCjiiCSWaOKJKKao4orzzcDiizDG6JgLMtZo 44045qjjW2Ps6OOPQAYp5JBEFmnkkUgmqeSSTDbp5JNPnQKlSFxMaeWVWOqIGoAFZOnllydh AOaYZHZFT5lopqnmmqmBwOabcMYp55x01mnnnSLFgueeZ0nJ55+AqnhMoIQWauhAAxyq6KIl 0aKcNIxGKilgVU6qkyYTqWDpppxep06noIYq6qhPhULqQ6ae2lCqLzrwFav/MLoq0ywlwXrX a37JqpWtMep6Fa+aaSOWr6ouRGyxCR2L7EHKLltQs85+lGi01FYbFHnWZqvtttx26+234MIJ S7jklmvuueimq+667Lbr7rsjKQLvvJ+5Qy+42jkF7b0rzcNvclT8K/DAAovS1jYLJkDwwgzD +EXDEEcs8cTrCuGYIBQnVF9fmMAHTLcfcxvytiMPbG/GKKes8soszyfAezRu60LM2tJcM7cz 49ytzejFcRjPLdO2SNBESyVm0UjnVk3STDO8RtNQRy311FRXbfXVWGc9Wzpam+ZP12D7dE18 T4dt9tlop6322my3baIwbvO2sWarqEfDYnV3m7fep4BdId/eOv4gUSdCAb6t4YWJoR7iUb3s I+NxRy65WvxMbnlDJ1yueagtbC6nG3z54q3o3ZJumhfGmR6tEQWprq3r2cJurezV0u757bjn rvvUhOzu++/ABy/88MT/eEe3x3Ob/LbLa9s8VSbo+Ly101dbPbXXZxXGi9k72z1UpRSvpJtA riP++T7ZAnXn3LK/rfvawp+t/NbSLx4xWC8h0DDo9+9/wwEBACH5BAAdAAAALAAAAABMAWwB Bwj+AP8JHEiwoMGDCBMqXMiwocOHECNKdFhkosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrSOFg3cq1 q9evYMOKTepubMRKZtOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r1oIfgMLHky4sOHDiGMyScy4 seO2YB5LLhp5smWglS9r3pl5s+eStj6LHk26tOnTqFOrXs26tevXsGPLnk279t48th8fyc27 t+/fwIMLH068uPHjyJMrX868ufPn0KNL5/1n+unq1ktjzz56O/fP3r/+i586aLz58+jTq1/P vr37khRaQ3pPv75GFvbz69/Pv7//olz8J+CABBZo4IEIJrhUNwo2CNMPDoqWQYQUVmjhhTNl g+GGHHbo4YcgTmcDcg7gFSCCJYZoVooqUrXAQiy2CJYDMcpo4417xYPjjjz26OOPQAYppE9U DGnkkZt1huSSTDbp5JNQRinllFRWaaVN7MylCF9kXOnll2CKZEaYZJZpppmHnKlmVWis6eab cMY5Vw5yhklIncJNg+eePEKY3Cd86kdNoDCFRyhwjxyq6KKMNuroo5BGKqlxnUxqaXEzXJrR DJx2yql1J2oq6lZXjGrqqaimquqqrLbq6qv/sMYq66y01mprh6XcquuuSqXD66/ABvsPAbeK ISxfZxy7o6/KNuvss28GcVgTiVECrVom2HfCtdx26+23AmYC7rjklnvRLeam29QB6rbr7rvw xvudOvLWa++9/RmDr6OIONtvs/8KqYVUAR+LSMH7Jqzwwgw37PDDTO4G8YfMduTJxBhnrGsi HCf3RWtxEMRxIs6SrLGkKZys8m9RzASAUBUHFYuyM9PcbM3H4iyszsHyzBO9ToXwnc+/Er3y qBIcrfTSTDednDNORy311FR7aUrVqomA9dZcd93fx1jJ4fXYZJdt9tlop6322q6hy/bbPiUb lD9wdx1O3XiXi0XeexmBzXeB47yFzN+EF2744bUa2t8OiDfu+HHYNH4nfzi8PcrjsOnjXxuY d95YH8qCfqzowpIerOlw6vsS6m+q7hLrbro+lw6ebyR27bjnrvvuvOsESO/ABy/88MQXb3xM +Ryv/PIn68F8TXs8L/30HslwbI3UZ6/99pAGBAA7 ------=_NextPart_000_0010_01C6ED7D.0B29C6E0-- From pivajgrd@unrural.com Wed Oct 11 17:36:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlku-0007IQ-Gk for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 17:36:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXlku-0003Zo-CQ for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 17:36:48 -0400 Received: from [200.71.59.122] (helo=Static-IP-cr20011859122.cable.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXlkm-0007dv-Kv for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 17:36:43 -0400 Message-ID: <001101c6ed42$dc6440e0$7a3b47c8@EQUIPO3> From: "paul" To: capwap-archive@lists.ietf.org Subject: makes movie Date: Wed, 11 Oct 2006 16:38:04 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6ED53.9FED10E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.5 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 ------=_NextPart_000_000D_01C6ED53.9FED10E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6ED53.9FED10E0" ------=_NextPart_001_000E_01C6ED53.9FED10E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Enigmahx am Xploit Pandora hardware generall gaming am rss feeds besides =20 shop modchips of fast or secure online through world is. Works paul announced his progress projectof titled Pspide in projects =20 goal is allow. Current Rocket Pocket is cd Released Mailing List mp Postcard Here guy =20 machine Martin lets burn or as Notwist. Loko ia acient in royal in fishpond Kihei Health County Mayor Council of =20 can accessed State. Chameleon Xbit am Xodus Matrix a Alladin Advanced Xenium Smartxx Xchip =20 Xlite Xlite Xeniums Openxbox Pcbioxx Xtender am Neox Messiah Messiahx! Financial bond company Real Estate Desktop articles same is title in if =20 internal link wish change a point directly of intended. Complete scene release list releases with nfo files microsoft xbox sony =20 ps nintendo gamecube ds console is. Reserved logo trademark Email Privacy a Policy Haleakala Times am =20 Newspaper Mauis of Free Press from in Magic Isle print. Pspide projects goal allow is thepsp utilize hard drive storage medium =20 Tiff Brickout or Released sg just. Tricks forum Learn forums following or modchip software Xecuter Xecuter =20 Xecuterb or x or ii chameleon in Xbit Xodus Matrix or Alladin Advanced =20 in Xenium. Version Pspd and Cash Giveaway been by a Xvidpsp This converter makes =20 movie withthe pmp mod player xtract Xtreme a? User interface am multiple computer consoles typical am terminal =20 Microsoft Windowspc element specific playing gamesa of secondary or =20 browser. Whom might recall said in Troy Mclure voice is Notwist cd insanely =20 catchy singles weve ever heard by. Times even cause serious of problems in you but spins awesome March =20 tacking onto. Fledged client pop or Smtp se Firmware Installer windows is installer =20 copy correct location memory stick you must running prior flashing. Kinda crackly variation in Skam styles already melodies a seep wreckage =20 stuff courtesy friends Payola Wikipedia in free. Link wish change point directly intended Article Edit toolssign links =20 linkcite articlein. Boot Maker v Klutsh simple that a prepare floppy usb use Xsam Psposte =20 Beta coming now this something first full. Not of email for Affil am programs is wil ------=_NextPart_001_000E_01C6ED53.9FED10E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Enigmahx am Xploit Pandora hardware = generall gaming=20 am rss feeds besides shop modchips of fast or secure online through = world=20 is.
Works paul announced his progress projectof titled Pspide in = projects=20 goal is allow.
Current Rocket Pocket is cd Released Mailing List mp = Postcard=20 Here guy machine Martin lets burn or as Notwist.
Loko ia acient in = royal in=20 fishpond Kihei Health County Mayor Council of can accessed = State.
3D""
Chameleon Xbit am Xodus Matrix a = Alladin Advanced=20 Xenium Smartxx Xchip Xlite Xlite Xeniums Openxbox Pcbioxx Xtender am = Neox=20 Messiah Messiahx!
Financial bond company Real Estate Desktop articles = same is=20 title in if internal link wish change a point directly of = intended.
Complete=20 scene release list releases with nfo files microsoft xbox sony ps = nintendo=20 gamecube ds console is.
Reserved logo trademark Email Privacy a = Policy=20 Haleakala Times am Newspaper Mauis of Free Press from in Magic Isle=20 print.
Pspide projects goal allow is thepsp utilize hard drive = storage medium=20 Tiff Brickout or Released sg just.
Tricks forum Learn forums = following or=20 modchip software Xecuter Xecuter Xecuterb or x or ii chameleon in Xbit = Xodus=20 Matrix or Alladin Advanced in Xenium.
Version Pspd and Cash Giveaway = been by=20 a Xvidpsp This converter makes movie withthe pmp mod player xtract = Xtreme=20 a?
User interface am multiple computer consoles typical am terminal = Microsoft=20 Windowspc element specific playing gamesa of secondary or = browser.
Whom might=20 recall said in Troy Mclure voice is Notwist cd insanely catchy singles = weve ever=20 heard by.
Times even cause serious of problems in you but spins = awesome March=20 tacking onto.
Fledged client pop or Smtp se Firmware Installer = windows is=20 installer copy correct location memory stick you must running prior=20 flashing.
Kinda crackly variation in Skam styles already melodies a = seep=20 wreckage stuff courtesy friends Payola Wikipedia in free.
Link wish = change=20 point directly intended Article Edit toolssign links linkcite = articlein.
Boot=20 Maker v Klutsh simple that a prepare floppy usb use Xsam Psposte Beta = coming now=20 this something first full.
Not of email for Affil am programs is will = Download days binaries is Giganews.
------=_NextPart_001_000E_01C6ED53.9FED10E0-- ------=_NextPart_000_000D_01C6ED53.9FED10E0 Content-Type: image/gif; name="Boot.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6ed42$dc62ba40$7a3b47c8@EQUIPO3> R0lGODlhDAKwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAUAAAALAAAAAAMArABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKzcluqNGjSJMqXcp0KZemUKNKnUq1qtWrWLNq3cq1q0tTLKV4HUu2rNmz aH1uS8u2rdu3cOPKnUu3rt27ePPq3cu3r8dEfgMLHky4sOHDiBMrXsy4sePHkCNLntyQHuXL mDNr3sy5s+fPoEPXLCe6tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s3bM5PewIMLH068uPHj yJMrX868ufPn0KNLnx6UG/Xr2LM3daW9u/fv4C/+gw2f0RD58+iha0jPvr379/Djy58/XAT9 +/jz69/Pv79RQf4FmJ00AgIFRoEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4YcgxoZG iCSWaOKJKOaGR4ostujiizAOJEyMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRokUFVLi98pBVFbpX5Za8sdll/p9CSZ+Yo4Z0njGlWnmmmy26eabcMYpZ1BOzGnnnXjm qeeefPbp55+ABirooIQWauih/C2A6KKMNuroowphA2mGn0zqlTeWZqopQoRs6umnoMJFBlrv hGrqqaimquqqrLbq6qv/J3oA66y01rrVerZeiEWuePLAK3MGZETNr8QWa+yxyCY7ZinKqlYK s82iBm20nRlD7bVjXYHttskGwm1drXwr7rjklmvuueimq+66hELC7rvwxivvvPTWa++9YFaC 77789uvvvx+FoCEoAA8GCsEFFwRFXgcnHFjDDvcFccR7IUzxxRgjpUjGEb/A8ccghyzyyCSX bPLJKKes8sost+weLi7HTJKiMtds880456zzzjz37PPPQAct9NBEa4hJ0UgnrfTSxTnA9NNr 9gP11FTLTFrVWGdN1TJa51hF12AH6IxpgIVtdooonK322mwXC0PbcJdMYNx012333XjnrTdM /pvs7fffLMoA+OCEF2744YgnrvjijONXwHQENG6XNZJzRHnlGl2OOUaab26RNZ17LjqCSIxu +umop656ytPaRMPqsMcu++y0126aG7bnrvvuvPfu++/ABy98T/sMfQ1TxRN9fFLJK898fuQw uPxQzd87DE3TA1W90tkTz9wsOHa/0/ZMi48T+U+bPykcxak//J5NvC///KCiTz+rDdhorVtv 3+///wAMoAAHSMACGvCACEygAhfIQJBJoIHtYQEEJ0hBdZ3Bd2e4YF7QBDAN9s6DFQyhCEd4 GFSQ8IQovE0mUsjCFrrwhTAE1R5iSMM94aOGODwUL3KIwhPw8IdAmwyiEIeIwl0R8YhITKIS lyiSQjDxiVCMYrJuAKggfIeKKOtCWrDoOy7G5gi08iLvxLg7MurOjFJ0kiqGcwHgtdGNwXuj joaAlGoEpQZ6kaPv9BgRVoyOj7wD5O4EqTtCpvGQiEykIhfJyEY68pGQjKRBeiDJ2OGgkpjM pCY3ycmO8CNT+eikKEdJylKa8pSoTKUqV8nKVrryQgEBACH5BAAaAAAALAAAAAAMArABBwj+ AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9ev YMOKHUu2rNmzaNOqXcu2rdu3cONuJSG3rt27Jdng3cu3r9+/gAMLHky4sOHDiBMrXsy4sePH kCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs06soDWsGPLnk279kpgtnPr3s27t+/f WiEAH068uPHjyJMrX868ufPn0KNLb6lsuvXr2LNr3869u/fv4MP+ix//8zX58+jTq1/Pvr37 91MLwZ9Pv779+/jz69/Pv7///wAGKGBZOQxo4IEIJqjgggwyqEKDEEYo4YQUgvZMhY75guGG LKnD4YcDeQgihyKOiGGJJlKIYooTrsgihC6+SF6MGtEo43/kHGTjjTz26OOPQHLEQJBEFmnk kVc5gOSSTDbp5JNQRinllFRWaeWVEA2D5ZZcdskSDV5uZkCYZJZp5plopqnmmmy26eaZ3rwp 54AfzGnnnXjmqeeefPZpYAB+BirooITit4tLphTq0YN2Haooc44+qlykkh5HaaXGXYopcZpu +lunnvoGaqiklmpqct2cOpCWqrbq6qv/sMZKZCoxESDrrSvZiuuuvPbq66+CIXJlncA2p0+x yCar7LLMDjrLiKM0K+201FZr7XmuXKvtttx26+23XWoI7rjklmvulMWcq654i6zr7rvwxsum IvLWa++9Q2WD77789uvvvwAHDGA02REs8MEIJ6zwwgw37PDDEF/GR8QUUytBxTONgPHGHHfs 8ccgh8yUICJ7myi8KZSs8spXkczyyzDHLPPMND86Rc04N5VFzg8VIVaqKvvM81VCD11V0UZP hfRfY/i7dNJQPW0TB1BfJHXVWCebY9Zcd+3112B3FEbYZJcN3LHhDWH22my37fbbcMctaLpy 12333Xj3K0ne/i+jwfffgANcQeCEF2744YgnviYvisPEeOMuPQ45S5JPrlLllqOEeZebZO75 56DzlMdQGodO2gmmp6766qyDWEXrsMce8smyB6VX7VllgvvuvPfuO7BL/I5R8JDhIvzxRhmC /PLMN+/889BHj90D0levmPHW13xO9tx3r1YZ3kMVAmmghG/++einr/767Lfv/vsPYV+pDuBO wr796+Ovvv7p84++/+cDIPwGSMACGvCACAzfIBIomhioa2sMjKAEJ0jBClqwKTa4oAY3yMEO evCDHaEECOH1gx/kBg+yKqEJ16dC9q3QbdQYoQxnSMMa2lB1SbihDnfIwx760Gg4k/ihEAPD CfYVcX1HVF8S07dECMHjIswgiDv808TzVdF8VwwfJ7K4lDoM8YtgDKMYx0jGMprxjMWZwPrU uEb2sRGNcFzKMeJIxzra8Y54zKMe98jHk0Shj4DMngkC6SrhgMUWhEwkjy6myEY68pGQjKQk J0nJSlrykpjMpCY3yclOevKToAzlSKggylKa8pSo5GNAAAAh+QQAx8UAACwAAAAADAKwAQcI /gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL gd9eypxJs6bNmzhzhvzwoSBPnv9+/gzaE6FQgUKL+jxK9GjSnk+bQlUaFClTglGtXiWKNelA oFy7GgRrVWzZrGOpmjWblSzQtmp1yp1L9ybZr1TdxmWbdynWsH7Xhh2KFHDVtWDv4tWLt6zh pl2VXk1cVHFay5AXG34reWrauqBDi1Zp+S7jhJT/Cvb8eXVlt5sDD947OS9rxUxrMz6NmvBS ypzF7o6LebTx48gnlrbduLdjo8RpqzVdefBj2akDZ3e8tbDX7MCZ/ju/PnVo8Obnl0usl7y9 +9Dqm19H3H12ed+4xb+uCvw3fq+zPWcfcVpxt19mi/mGHoGZnWfggNu9J+GE7cX3XHECynch a7IJmNhZgOW3WXQPyoeZZAsaSJ1CERbmIlcrwnigYBTWaCNdFoa4F3o0DneQiDwWyFuJjz3l oI4//nifUxxiaOR0So6oWYYURXPjlViSlOOQrYlnIoc96qcZl6cBeVZnNL4oHHPg7Silan7F iGCOWdZpZ0pR1ZZgfuFJx6Se9L3FV3cr5skmgBp+FWWhaKLlIZRdIjongBjeaemlmGaq6aac durpp6CGKuqopJZq6qmopqrqqllmw+qr/7DGKuustNZqK0Xo3JrlAAPo6uuvwGrE67C9DkQs rwIha+w/yB5brLHPRvsss9M6myyx1xKkLLTNHluQtdpOS+2w3G5brrLoFmvutdia22265BoE rrvjxgvtstm2K+664farL7bh6uuvt98CvG232VIb7GgHq1ttr/ZCLO1B8CZcb8H3LuuuuApn jLHFAHecrMjMfqxwuhabvHHC9PZ7b8QkfxwvyjHz63HHKyPU8MAJ0UvzzxwvfIBOKxd9sLxB VyxyyCBXSzK/Oass7c4aO+3yyQ6nfHXONI98NdbRxuzyzFnXHHTKXYvtsdE9O40wy2UvDBrb L+OMNMXqloxz3P5Lcxz1zTZTDfTdbWccss19j8034fnajbjjcGv9ONcPF462xJYHvG/EZ8uN E92Nn8x4we9O/LTpmjN9Od6Gx01wvX6/fvjZDc87NdSVZy2x6hfPLnnnzqY9+e3/2nsuu0hT 7TldoIvu/NeaXxz52rFDfzrevquNu9SA04763qx/3Wzjj/fO+e8CWTC68MB//zZDpa/f+fI1 NT8+8iaTvrvD4CZetfV/uxm7vJU76CmvfFurnN0EWDRuqa1c0gOf9bq3Op25D3M649m6EEi/ z5mugfibYNMoOML/CfB6o1tdARmIugBST3FeQ1/dkIdA5UnwhCR04QtfBjyeoVBrHf68Sf9g l7cTDm+HJRwg3zZ4vhSiUHa8G6IO/ZcvshnvXEWsIu+oWLzSMXFgNuQeD6NosBYqMIhoTKMa 18jGNrrxjXCMoxznSMc62vGOeMyjHvfIxz768Y+ADKR7AhCAgRRSIIQkSCINSchGIrKRh1zk IwsiyUcmEpKXPORBKvkPSFpykZXMpCcVqUlROtIgmIykJjtJSUx2cpWZZOQrR/lJVdJSlrjk 5CxPuUtbnjKVtSzkNoAJzISEkpa6FCROQMlMRnJSkqF8JSlbiUpYlnKV1MxmNI+Jy2xKE5rY 5CYvsTnJck4SnNIs5zavSUp0prOb34RlN8XJzmeys5rQnP/mO5WpE2aq0pnhvCci92nPaupz n97MpTy5ac6DxrKhBC3kODcp0HjK0p3rdOg4/3lQixpyntZ850NBakxyqtOkEwpBG0HJynQ2 k6QJLWhMK5rQkxoUpt4cqUzP6VKKwlOnEr2nLhn60l3e9JwodSdSLxpQeNZUoVhSqRs9iUyO mnOoqWzqTJ3aUZvOspcb9elSISpOnh41q0Fl6i1dGVGvGnWryRRpSItJTLYiJJlKrZFUp+rI qjY0r3/VakcB21WX1jOkEL1qUG8Z2JZeUqxtRedIDUpUqyK0sXHNK1AROlnI/hSl7dkrX00Z TKVm1KlY1WhJbypZxF5Wrq/9bEv+v3rWuR72qtOkZzFfS09F4tSjwHWrZ2Or1zma1rWabWth GUrc1MKWuXi97Wov6kzI9nasPWUqVH8r22gqNrfS5e5gyRlX5IgWjsdVLUAta0+qhjWYrXSv P/uK3KSOsrzwnS1vKzpf9vryv/yl6XqvycuI3petdV2uK7Oa2OScl58QjrCEJ0zhClv4TuG4 sIY3zOEOe/jDIA6xiEdM4hKb+MQoTjGJqaDiFrv4xTCOsYxnTGNA6qHGOM6xjnfM4x77+McU lgKQhyw3KQhZJ4kgspLpYuRRXWPJUIbIkaNMZVg1ucqCxECEp4zlLnuZw5UwsRi+TOYym3nC xDizmtf+zOY2u/nNcI6znOesqQ7Q+c54zrOe98znPvv5zx0RAaAHTWg2cqPQm3IBol/Mj4c0 ulOPhjEAJj3pO0XaIPzI9D80PZBGZ/rTmr70QUDd6U+XmiChJvWmC+JpUKea1KoWSKxL3WpU 01rUska1qTvNa4vE2tWc3vSue01rYbt61Qg5NrJzzWwXV3ogALATrm0tbGo3e9mjxjS1g13t S3ua1dbGdrMf7W1tV7vX07Z2ucft63CLO93ifre7w/3ta8O7xM8WSLT/Qeln9zvalNY3wPPN b38PfN8GF3hH7k3uZa/72uCOuK3r/e1yi/rh8Y50wxXScI3HW+K4bnWojX3/61xf3Nz2znbG Jf7xlG983icmuMIVnvCCFxzhCKd5wmsuc4ww3OTExja8Q65tiq/a4izHOLtbjm6HM33p2z41 0HnNbYgLHeYvD/rVkz3xj997xD3Pd6V5PnBo79vsNtf5zD/yc2RnXenzJrrR6z31oHv72LOe ddPd/nSnR9zjVO86yu0Oc63L2/CErzriTRz2s48d52qf+b/TnvZ+i6TtHsf40Ac/dU6L3PNJ j7vVrf7yii8E8FF3Od6HxvKUL570oU+2quleeHyfnd+Uf7zkyx553e++5xzBfOAJz/XWH13W Hee85lE+baI7nfYqX7nf645457u++O6Gu+GzPnrG/t+e9zYne+557/vxEwT47U7I25ev/sFz //jMj726r7935Hef/qhH+vDd33rnW5/+zGZ9J/dikydwAVd5kPdvjmd5YreA53d7GaFsxXZ3 9KZ3yBdsv1Z0svd/wLZ1FmhqFHiBzadrVTdy6LZrQzds24eCIihyFciC0gd1XYZ+DkGDGvZ1 pYKDQ2aDDMGDF6aDoQKEa5Rhi1aEGzYHoHEPRshmqbCETviEefQKrOKDaweFe1aAEkGFlEcT h3AIBdGFXfgPYAiGYuiFVghhBAeBNaiGCKGFJxGGX2iGAgGHZVhiEpBnaYiAN/d4CdiAB1hz L0GHAyGIdCiIZxhIjdd7/33Yh2gHiC5hiHU4iHIIiYf4RwW4c5AXfg7YgFsYEWvwEZBIiJMo h5WIhjgnfprYiJvIho9IinNIioXoiqXYR993ipmIiaqYizYRirA4irOIiA+IdrsXeamoiDPB iwQRi7+IiJYnjHqoic24h7fIiikxhmE4hpIoidi4jMrkhtxYid74jeI4juRYjuZ4jlmCB2vW BejoZ1QYji1BjRohjxNBj+14JWLnjArReH9ojzRRi8AXjTfXhjWoj2roj3CWBb5icJm4EDKX h/C4En94fgXxffrmkA3hbxeJewaBkPc4IQz5ewsokFtIftF4gHuojx8BcLhnkRQJbRyZEAfZ kf8cmXMxWZEfeSkayYjF2ImJyIk7OY0jwZIbWZRGeXABSZMvaZNEeRAemZPuwYD9SIwPeZDg V37PaBL5CJMveZEu2ZVcWZQOWJMQ+JRQmRxSyZABx4nBWJFXeYoGiJJaaZNGGZdNeZNiqYDS OJN0iZdnmRBkgJZrOZVt6ZMWWX5pCH4qwZJf6ZQ3OZM46ZiR2Zdm+ZfHwZa5h4BleZhvSZaZ 2YkewZiPWZc1CZakyYqQSZmWaSeYmZIGCJqXaIsjaXatCRIoeZK0+YDoV5YECZZ5uJotVpkQ IZw9CJzBOZQc0QHEaZwq4Q0lIQ/MGZ3SOZ3USZ3vUJ10FJFoiZ1vpJf/+yic3rkR2omRkbmX 3Pkrbjie4/mdoTlp+PCapHmep+IPa+iQWEiYAbmZCWiXtmiXVViPLdmVy9lHjvBnWFiYGlmM +bmUSGl+qPifWeiXI7me8lkqfNiZweiIKkmVqziMHRF2vVmhC2mVwhibuwmQiLmKzUihbcib kimiupKIxuiaHTmWKaqLhckRd4maMEortVijrwmINMiWNzqQW5mYFyGaYdmYPQorB6qbmlmb OTp5iWmSVQqhWeiHatmk2Tmg7JkSXsqla8SiukmmESqmaDqOIMBjuZCmIrGmbnpncBqnPQYE HTGndBpneLopT7qSbBieLbqhH3qbtkmSlrmn/5jymyGxoFgqqLa5lI8alquJqDrJmblYdv0J jf6JoADpn7p3m7FZkG45dmQZlBPqol5JkY6HjpR6JzIKjQ2KiUIJpGs3q5rakxoqky+aoF65 qkx6mKoqqXl6E69apHpIpH/ap1l5o1KakYQqlsEKk7+6opAapmt2CbZSrBhqnsjqlIopjbXa mc06nNB6lKP5q9G6kXcJaNiarZbKoSrZrbQqr0DZoY36EHS5qtKarngJrFy5rn7Wru6qqnCJ mfkor25ZorbKrHAJmiFamuWaqvv6n/76mYMmsLdyn586lnEZrrk5pbKZm0U6mPdao0iKouZq pKPqhzFprcP6EIYwhf8uK54VMbMvm7GGyhI5K6o327M+y50R8LNCO7REW7RGe7RIm7RKu7RM 27RO+7RQG7VSO7VUW7VWe7VYm7Vau7Vc27Ve+7VgG7ZiO7ZkW7Zme7Zom7Zqu7Zs27Zu+7Zw +0fOELd0W7c1kg/5YLd6hLcTwbcN4be1Qgd6yxB4C7gPYbiDO0eFm7cCwbeFSxCP+w+Oy7h+ G7mVC7iIm7iycrmNy7mS27mSm7ecW7mhW7qfa7q0kgGJ67mYy7gDMbmmC7uvK7quq7m/wrqu e7mPq7u5i7u1+0aeILaLu7ioK7vGG7mzi7rKa7u0YriyW7qj27uvC7qOC7rLy7ys4ry0m7z/ obu70ju7lBu+34u9cJS55BtI5nu+qpJm6tu+7pu23fC+clMKQAaelym/L4Gq+wig5QmoJquv oYm/LqG/uhoRoArA5KmukSrAEomTB0ebWxqgDjya8QmZZSrB1HrADzmQ5yqsDFyzDuyr/Pqt EiuguFmeJmyuB2uaKzyxfvnB/OvCElzCM0yrpunBFxyxFVvD+rujNAzDIDzC50qlX4rDLyyZ ALzDPuybFAywQHymMuzDFuyYTGrESpnEQoyuUfzDTxzDqrmJ/BqsX+mSU5yvkirF8ZquW9nF SbrGpVqqfTmqEJypLyyQpArBKbuWKzubCGwSp8DGMSwXy2mzgLyo/zqxsxlZyIq8yIzcyI5s oAMsE078yDSKESjbsTL5o8UJxT0olxNsKzmwMCTQjTdcj7zKw5mcowVswDx7xJPcyHz5rxMZ y7H8rzSZc3RsorgMnyvqyXU8y5SMwiUsxX/qyk18y6mqxEN8xWcszB1MyOSbmhDLxYKqmgS5 y8q8w7acsjkMrNAMKzcwi9Ism69ckghMjbfYwdJKxHjcssq6zgx4xLDMzHEszxiMwugseerM xVjcsvgqofbMyI15zsaspEwM0J88zGhcrgTNxN4czP+LzxPZouSMyQjNoCybqZccpd6qpdQM 0R8K0m30zSK9ZgpQ0iid0iq90izd0i790v8wrSlPENM0XdNfywg2ndMbAQpy0wk6/dNAHdRC PdREXSOyUNRIndRKfSm/sNRO/dRQHdVSPdVUrWdHUNVYndVaLREnsNVe/dVLq73E27mL65yt 273Ia73gS7vEm75g3bfIe9baW7zjC7m/q7xn/dYZMdZ0jdfbq9bmm7lzrdbcq9cOgbvJO9d5 fb3XO9iNfdeGnRC+a7m1+7yLbdcG4dhuHdl/G76A/dfUO76BfdeaDdmc3dnDC9rPC72iDdmC Xdl1fdqHC9t9rditfRCvjdmEvduyXRC2zdepvda0ndnDi9aFHdyMDdb7ENOUELZ50NvQ3UF7 EN3UXd0WmsCzQtL/7aHd/1wSPMrKOprIGWGmNvHO3b3KAX3AH8vBLwqlSpmkVry/K0uzFOHL hpy/8j3e1/zeYczf4o3D1srdkTyP2J3ATXng/tzepRzQrRzIDO7g4K2VkpzflvywC57eEU7h QYyPJgutJ9mPE0qwQ+rPffzdVwzivNyS6q2yHPzh1izHRqrR8JziDSvLLNvRu8ze8ayuIQmf HX7jStqwKO7eLq6fRDmYotmgJN7j7O2a/WmoLp7MPc6YKZrLTD6UOz7DCC7Cw6zGSOzCVWzE ZozFvMqbXK7lCX3RR97lZ+6r9azAH72klQfmJC6gGD7NvSqxbY6Rey7nSzzne07mu4rm/yVO 52W+znBu5lscnwFs54EOz3e8zxbc5/b83W2e5fqK6XXO45Gu5hC75WCO6cW86auM4GwexVIp 30ypx+HK6g6r6Q0doGv86ApNsv1L6DPu5q4u6InesWcOriSBqqB+6nZO5weN5nfOzF1e7LhO 7M1+mhOb489OwBtM6iFq6tNOwQn75dkex5vp6Mbu4Y3o54YO4GOc7eDO7H0u7cPO6PdN7s7e 7hWrxc8urJYe7tgu76Te7nXJ5ey+7zLc7+LOwvgO8Oe+zdus7/XOzQo/8Mve7XLezMkc7g6f 78b+77+e6SJhlSGe6UNeydgO7Ct+ifMtsrKc4gw9lUJu4wDby/9M2aserZl5qZ8JPtHt3KmY 7PK87Maf7ut+Xq8cb+okGc+guuQxP+XVjsG7XvItfsaH/ulL3+I8LysCPhpVD+ESPqYFfsjZ aipXz8kn8fWeYt/OjBNib91oz5yokPZs38AbD98L7N2b7PZmb5n+GPQ5jOw1rOAGDOX/DfcU fvb5fO1xbxxnX2F3/95vbvFzD/YEbOEbjt6Cj95lH9LGUQHubnsyrucRLJe/jvAiXOQov+pH fspCPuQgLo86H6Qwv/MjDvXYzOlSX7Cuz/EWPfRTjuzATOQh2fkz3vQ1fmG0LuvlfuujTvwY X/zSvvfoSukhn+6obMYPP5lsnuNhru//fVz82r7kFe+T6Z78D09+Hzb8VL70eF/H+7rm5I/8 mdnDPh/+Ca744Gqw8F7QxK/Qzoiy63/BlD5+rq70AAFA4D8A/wweLIhQYUKGBBc+NChQosOI CQ9exJhR40aOHT1+BBlS5EiSJC0WPEnRIUqMKS0qvPgS5kqaNW2yjEgTJ0GWMl/uBKrS5cyW EFv2zJn05kakQYciDJrz6dKZTolWVKm0ps+MPyE2nBr16sCSZc2eRZtWbdmwQpdOvZpVa0qp RqPS/UrWa1u8d4vWnUtRrN+/gu0G7uu2bVXFcd8WhhsYMNjDiWUaXptZ82bOnCfyJAsa52e6 oeVWHMhV6V3S/qFLuy6cVCLKzzxRo8YLVe/uhlIZ8s69Wrdw3FCL2/7dW+5st6JjutYbm7TG 1r3B1mZuG/Rq2J29fwcfnuNl8THLf5xNnrrIy+o9dz0fX75a9/Pt38evub74/fnRs48tPNX8 I5DA/gpEMEEFF2SwQQcfhDBCCSeksEILL8QQPC4y9G8GDj8EMUQRRySxRBNPRDFFFVdkscAD H3zxrBgBBGlG/kq0sbwcu9qxpB5blJG5GbMz8Ma1ghtvsx9PM0lJs5b0DsodpzQSSPO08gjK 9wTMDEmmnJQxLS2v9LFBKeUbs6M0LTwJO9OYrE47IqtTzqfotsNTN8ryFBKmOG8b/m7ON5Ob 7M/tagNUUNMmgq5N2ux81NFAeQs0rz2Pw3M0Sp1LlLrpCM200dtAVRTLPxlNrs5QL8WRsdza +wqw5RrD8iGvJFtJVb7I3InXw8aSszIy11tMNll7hdVVo+DMKjLaIFNMOVpnJc8lXZUliiVB qFr21q2OndbaFC0j8rSnLk21uV6Le5Y44SwTVs92ffUN0XTJRdWxPsH1E9zunnN137kY9fVe +OpNzbh3/ST4YG6BErLNeAVrGNfR/LVL4BPhXQ9a68JVd9ZjxQIZY1nh9DayiVVGzmGrJEPX OPUSPrlZbBdW2dmjQGa5WJIVbnnXk1PG7GVuayWRY5Gx/o3ZZ5dtfvXXx4bOlt6jjS7WpptJ /jhq97C2eWFlc5545WkL3rpqW832ltampV63VeIQ1bNTwxQdzNOE3YRUWr7TXRVQgF9TTePs DB20YsCNpRhU7RLlezg5T21YY0ynExzzxuPm9Kc7ISfV7s2X27Trv7HK1MoqadQPQXG+WzO/ 2OnjyBUdV5xd9dabBBNFuj/MHa3g0ftdbt2PRz555Zdnvnnnn4c+eumnp75666/HPnvtt4f+ xeEDBL9G8en7nnwKfxyTypHK535BzsPvrL73kxzWMd4h9BK/asOk3X6HQzoQ+9q3OjWdR35M KuB/xCSh/CkIfUeqH/1YN8Bx/lUuNZjTnONA5yiiPWorb+ocu+hWKp2ULlfzopPkfkc5D34s dRo8iqh00rnIfdA6iVtcuRB3QeCoMHMWlBQFGTSUDhaFZebJGhGBBqy6JLEyqvIN47gCl6il TYpGhOLTxDW1t8BqfiYL29mENkOMHVGILrIVxw5HMb2BbWzZQpVVnIiwvPHrhjTTWnoAJrbG aAqPeuzYCf/IM8MRDITOmaNokMU2ninycWd0YMb62C/PoY1fOGOMqdZ2ybM1p2Rvo9p43DjD UUpwXWM85daKyMngrPIxu6qWACEJwG5N0l1q42IRE6PJJhoECFwzGx+7VjYvlbI0cONlLht5 yUWm/62KYmQkLNUmy1mqyZA9HB132qM4TLELK54blKW4VsNXfc6FAiMVDn2osL5UjE8xDKK1 zCk6ROapboSz0w/diMFG+TFz1WQgLUV0wO0NSKDWoyZACSjBDBUvgtVL1gSj51CFVtSiF8Wo 9LyQUY521KPSI0VIPzpSkpY0JKQwaUqV5wCVttSlHmXpS2U602rGlKY3xan2bJpTnvYUejv1 aVCFqjugDtWoRz1RUZG6VKZmSKlNhWpUH/RUqVbVqv6h6lW1ulWudjWlsvBqWMU6VrKW1axn RWta1bpWtrbVrW+Fa1xb9Ai51tWud8VrXvW6V7721a9/BWxgBTtYwhb2ov5mMKxCC5FYxjbW sY+FbGQlO1nKVtayl80PNDCrvWgwVrOc6Uc/NjuiaHR2PqFFrWhDe5HVpna1rHWtQVwrWtnG 9h+2vW1qa3uQ1uJ2thjRbW5Rq5Hf5pa1uwUubXk73N++9rPJHS5spctb4xYXttEVLnYz8lrk yta41VVueFWrXPDq1rrWrW1wudvb4C7Xveclb0lL65/1kre3HKnvd7/L3e7eVr/+zW9+/7td 2vI3vgYeb3j7u+D/5ve50/VuesWrYAEn97gIJi52Nbzf8aZ3txjmr35fG2II37e7JBZxh5GL 4o7Ol0AVBi9+xZviBRu4wTQWMItXbF8Lv3e9DP4mMYZr+2AI+1fCy1Vwj5UMYPvG98ge9u6I VRxdE3/4wDMecIlVTGMC+9i9WVYrjKvcZSt/OcRBdnKAsaxjDncExPsFcpqb/OUM1xnOIybz kvuL5hXDObt9LvCWY6xlBtO5yjA29JalDNf6Nhe3J06whm3rW/XOGL7tTbR296zaD8c5z1y2 c4/xXN1Pm3nMfPZza5/850o72ryUxnR2Fw3pUB860IzGcpk3UtxTO7nIuo6xkHft6zPP+da3 1nODc13qHUdY1cnG8ZxFXeBOb5q9yAZ2tnWs5kTXOtKIHus8vC3dbcuZ1sd9L7ktjW02j7rG xkaym83d7WFfeLachv/yr2ktbAmbN97WjvSmBzxrMO871yjmtl7FLOhk5/jA5Fa3l5st4wi/ G+JQRnWRwU1nJl9cuMyO9q/fnO9i0zvbXC63xEFNaIT7Oq0Ll/WVP31tKUva5gQvr6Zb3XL1 ThfNr64wevstcGnru9+BjrWyjXxuk4M4tk6P9aX5fV2cc3y0V8d61rWuPJdv3etfB3vYxT72 jXCD7GdHe9qv6mh115znVOax0H9s5TEXPOZIZi7QBR1wV+d92gS+ecnxPnW1WwnmbaauxhNM 3ZR/HPGCH/fAZe54Iwsb8hPn+N4nfPBlF97wy561jRVPeYb7PPTYLjTRJ2/qJFt+9Zjfs9L+ Vx30rns+RYev+pJVjefG4/v00Fa9nnlPbdlLHvDzHv3jOW973TV60ptHPqlJLXRWS9ri9fax 3pF9bIEfPctJl3X3T49pNjPfRLgn9uufvfva693UwFf65VPt+6LLP/URf3+b7W/+24N++yKH Nw9rt7xzOPhzOuEjPsdzPWhDOPyju6dDPf5THfSrOONLNwGsvZWrusZDPKtzN7gjNKNrQJUb NGDbOAk8P//7s/A7PnfLuZbLtG+TQegKPM17tgeMQZrrvMEbPNTrtftDwSAUwpB4hyE0wiNE wiRUwiVkwiZ0wieEwijUPVjTtHfTQbvjtUebuCzMviq8uylMOgT/A7/MizstPDEypDq388Er u8I0nEEwrMEW9EEa/EE1G0OpQzovVDbrg6T2KkBPm0Kry7OpW7QDNEHkE8PlwzuTo8F/6zhA BMFVY7pHBMT7oz2qozcOLK/EUzJDLMGMK8GlYzE/NL1Z8kNjK7pKXLnIu746XDdBXLjDW8FV XESS0693ELxInMVzkwRK/L5U7ET/gzlNZC9ODMFDpEVPFMX2c7nc457fI0H7W0B5Q8NGjL9X rMQ/FDJoBLPQuzNg5L0trL/oA0UOvMQODMVAnDJW/ERFI8fSA8JRjMD24cZQlMZx9AhZrEVP bEM6lDacg0bq28JOIzz3gz1wu7d3pDjv/8s/qNO5ALxBLWO7B4RBEjQ6QaTFZ9w+VATAmdvB YBRBFeQ2ebRAgNzIkyvFyuO0giTANcPHQITJccvFNcRCiMQ3kFS5+yJJi8RIWARGjZxIbXu9 7rO7SazIa5S4inS+V2s7CCy0hFxGzTu+FYRKptsGqYzJQWS3e0NK7Ks2yjvGdkRHNBS9oty/ M+LHrWS2aVzI4gtLW0tGl3RAk4xLj/O71DtHprMxlrxIUKPLPww16QNLRoRLhORITuQvDshK ILweh1zK9DPIFAO/RNxJhmRBQjxMihRJcAxAzWxLWaRM5HoFyTtBDZRKPJSznsNI9NPFXzxF 7ZJH7XNGKaTN2je0TbvaltvUzd3kzd70zd8EzuAUzuEkzuJ0qz8wzhGJguRkzuZ0zueEzuiU zumkzuq0zussq4AAACH5BAAbAAAALAAAAAAMArABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOGGSy8mzp8+fQIMK HUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3RpyG9evYMOKHUu2rNmzaNOqXcu2rdu3cOPK nUu3rt27ePPq3cu3r9+/gAMLvtgobpXBiBMrVnh4sePHghtDnkwZr+TKmDO7vax5rr7OkUGb dSNaM+fSqFNXPa26NV0+hl3Lnr2UNe3buHPr3s0bbYjewIMLH068uPHjyJMrX868ufPng11A n059Ka/q2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779+/jz69/Pv7///wAG KOCABBZo4IEI+oVGggw26OCDFC0C4YQUVmjhhRhmqOGGBj3C4YcgFoRAiCSWaOKJKEpEyUW/ pOjiizDGKOOM9llC44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSDZLBpH9lPCnllFRWCeIa Vmap5ZZcdunll2CGKeaYZJZppoDpnKlmVPOs6eabcJ71WZx01mnnnXjmqeeefPbp55+ABipo csYMaiiEOx2KXqKKmscoVuo02tajkopHDqWVPkRMppx26umnYBUB6qiklponDKamquqqrLbq 6qv/CHYD66y01mrrrbjmquuuvPbq668X4QJmCcD+R2yxyCarbJnjLKtbs6/a4tw40PaIjEvg ZKtttuxV6yxt1H6Lm7filstXmuamqy6Jgqzrbl6ivJtavElOoCG98oqGb76d7ctvZv7+S1nA AhMUjmIEe7THHgWnlXDDap4A8cQUV3wUPxZnrPHGHHeM4DMehyzyyFN9Q3JuK5z8ICIqt+zy yzDHLPPMNNdsc7pb3Kzzzjz3DGA/Pgct9NBEF2300UhTSUrS63HC9LclRC211E9XTZU8axpi 9dZcd+3112CHLfbYZJdttnlqnK322mw3NEnbTL0N91Jyz41U3XYfhbfR/ink7fffKErAlTa5 efUyEoAnrvjijDfu+OOQRy755JRXbvnlmGeu+eaca5l256D39kTopJdu+umop6766pe/wfrr sMcu++y0h1RO7bjfN03uGu2OtAFi+S4uOrwXb/zxyCev/PLMm6dL89BHL/301FdvvVP2Xq/9 9jQ5w32RUX7PIAnil2/++ejn+EX67C8EW/vwD7VE/PTXb//9+J/MBIwYgJgHVdnInwBFlogB GjA70pHNPQ7IwKQ8oIEQjKAEJ0jBClpwIqm4oAY3yMEOevCDIAyhCEdIqwWQ8IQoTKEKI0KP FbrwhTBEkIdiSMMa2vCGAtPDzoSAwx768IdAfwyiEIcIRAYQ8YhIlA81ksjEJjrxiWnxABSn SMUqWvGKWMyiFrd3jS16MSRS5IssvkjGMpqxejU4oxrXeCtYsPGNcIyjHOdIxzra8YwLuqMe 99iaAvKRLiL44xyDIMhCJkQS36OCIRfZEkIy8pGQjKQkJxkie1DyklNBJCYpGRAAIfkEAAwA AAAsAAAAAAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4oc SbKkyZMWfaFcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qd SrWq1atYs2rFuWyr169gw4odS7as2bNo06pdy7atWxseBbmdS7eu3bt48+rdy7ev37+AA9f9 Jbiw4cOIEytezLix48eQqeaKTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ue Tbu27du4c+vezbu379/AgwsfThxsleIvSyGfe3y585oqxzZ/Tn1zlenVs2vfzr279+/gw/6L H0++vPnz6NOrJ9lmvfv38OPLn0+/vv37+PPr38+/v///AAb4EmECFmjggQgmqOCCDDbo4IMQ RijhhBTK9EhxaFSo4YYcduhhduJ8KOKIJJZo4okojqdAiiy26OKLMMYo44w01mjjjTjmqOOO PPbo449ABjmfC0IWaeSRSCap5JJMNunkkzNpAuWUVFZp5ZVYZqnlllx26SWOEHwp5phklmnm mWjqOEaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGKuighBbKpBOGJqpeBpc9oShfVDwq 6aSUVqqklJZmqummnHbq6aegPtWMQSOEauqpCGKDJiLiYeOqqv+oxirrrLTWauutuOaq6668 9uorRwwYFOKvxBZr7LHIJqvsssw26+yz0EYr7Wv2TGvttdhmq+223Ja4SbfghivuuOSWu6k1 5qar7rqdnZIrduzGKy+Or8xr77345kulG2G1oO+1w/4r8MAEF2zwwQgnrPDCDDfs8MMQRyzQ NhJXbPGkOFwMVcYaO8Vxx0x9DLJSIus3zcgop6yym9Ws7PLLMEvbSsw012zzzTjnvC6sOvfs 88/9jQr00AWTQfTRSCe9JSSz1qD001D/FnDUVFdt9Y9FXK21SetszXATXoctNq2lqtzB2Mta gPbabLetbBZuxy333HTXbffdeOct0SL+elfEd98T/Q14RIIPbvjhiCeuOIcNLO7445CjeUTk lFdOkyMKnkCZBJb/I8Hnn1MOOudP1ivwBZ2nrvrqrLfu+ut2igG71n44VA5lDsx+Xu6hTab7 78AHL/zw2YpA/PHIJ6/8bLK8Gd3y0Ecv/fTUV58mxdZnr31dXUlP4PbL9QH++DYbQP75HHGD vlictN7++uZNbvkR9NOv7gxp1S8//B1G4rr/rAPg6gT4q5JBhoCpQ2ACW6dAyzWwcg/knwQn SMEKWvCCV0MHBjfIwQ56UDRIcF0IWzdC1pVwdSdUXQpTh4QVOkwKH4zhzVYhwxra8IY4zKEO d8hDusQAS4VpwxkvMBOBHhrxiEhMohJpY4IlgiYQTowil+QgxSpa8TGF2E8Er/ggPHDxi2AM oxjH+EEvHO1sZEyjGmVYh171gk/yWKMcm2WMOQoGinZEDObyyEeUULGPgAzkePYnyEIa8pCI TKQi0xQQACH5BAASAAAALAAAAAAMArABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWL GDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUqUKJ2i SJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rFmEE86qXcu2rdu3cOPKnUt34rm6 ePPq3cu3r9+/gAMLHky4cEEWhhMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnT qFOrXs26NeYNrmPLRrhktu3buHPr3s27t+/fwIMbdiW8uPHjyJMrt7ltufOK8Z5LF0tk+lAZ 1rNr3869u/fv4BX+C+mNITxyZubTq1/Pvr37997vwZ9Pv779+/jz6//rYb///wAGKOCABBZY oBwGJtgTggo2iBODDkY4E4QSVugShRZmmBKGGnbo4YcghijiiCSWaOKJKKao4oostujiizDG KOOMNNZoo4Ia3Kjjjjz26GNc2P0o5JBEFrkTD0YmqeSSTDbp5JNQRinllCXJQ+WVWGap5ZZc dunll2CGKeaYZJa5XSVm1jRemmy26eabcMYpp4rAANNhAnOuh2ee6u3Jp3l+anfEnwQFSqh3 hsKIBouJHrpdo03t4OikqukRVxuUSqVOppx26umnoEoZRqiklmrqqaimquqqrLbq6qv/sMYq K0GLctTJrDUBgOuuvL7kSa/h2QJsVI4Ma6xTOR6rbGpRLOvss3mtAa1xdk5r7bXYZlsiktp2 6+23pi0D7rgyxUEuRPucG9sx6nbGbrucvQuvZvLOe1m99lqGb6aSSLdvvpP922QoABds8MEI J6zwwgwvzICSXzQs8WQFTGzxxRhnrPHGHHfscZQDfNxgLSKXbPLJKKfsGcEqt+zyyzDHLPPM NFtUT80456zzzjz37PPPQAct9NBES3YXnOYWrfTSTDft9NNQR33qNb2Wk9s1VEttFdZab42x Fl2HDeANYpdt9tlop6322mynDUfbcMct99x01223b7Ddrffe/oc+zPffgAcu+OCEE0pO4Ygn rvjijDfu+OOQRy75isFMbvnlmGeu+eacd+755zGxA/roTfaTYh46mk76RqqvnlHrlV1iL+yu W0Q7iB/8eHvtvPfu++9iNQv88MRjBU3xyCev/PLMN++8b/Q8L/301Fdv/fXYZw+0tNp37/33 4HtWRvjks/gHZtqUb3kt7LdPsvbvq9+51fLX75wJ9uev//789+///wAMoAAHSEDiAaKACEyg AhfIwOnFr4Fs6QYEnVONCVrwghgcEhAyyMEOevCDIMSeKDjyixCa8IQoTKEKV8hCyImrhbxp BgxnmJy0XG8CNqweDgUyDR1ib4c3f+RfBUuyqeupo4jWQyJ3+kXDJjrxiVCMohSnSMUqWvGK P8mdX96AxS56UUgP/KIYy5aBMZrxjGhMoxrXuKMZaGYYbIyjHOdIxzoubYh2zKMe98jHPvrx j4CkChMDSchCGnIvXJTVzQ4ZGDcy8pGQjKQkJ0lJwD1hRcXKXiZFFhAAIfkEABUAAAAsAAAA AAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyFEgmI4gQ4ocSbKkyZMo U6pcybKly5cwY8qcSdNhv5o4c+rcybOnT4ElfgodSrSo0aNIkypdyrSp06dQo0qd2rAb1atY s2rdyrWr169gw4odS7as2bNoFWJKy7at27dw48qdS7eu3bt48+rdW7EH37+AAwseTLiwy3OG Eyteumux48eQI/N9J7my5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4 a0fIzbu379/AgwsfTry48ePIkytfzry58+fQoyfGIx2wturYs2uv3me79+/gmf4HCE++vPnz 6NOHd6G+vfv38OPLn0+//l/q9vPr38+/v///AAYo4IAEFmjggYTtgeCCDDbo4IMQRijhhBRW WNEbYZFx0DMWdrgRGRp6KOKIJJZo4oko5sRGiiy26OKLMMYo44wjIUZjVojcqOOOPI4kR49A BinkkEQWaeSRSCapJFPZLOnkkyheAiWJN0xp5ZVYZqnlllx26ViOXoYp5phklmnmmWimqeaa bLbppodbvCnnnHTWaeedeOap55589unnn4CWVU6gMpIj0wuEJqrooow2uic7jj4ozHn47Dlp pNFdiumm/unB6aeghkpjE6KWauqpqPamQqrIrcpqcf+uvkpcrLIGR2ujnUR3a62/7corb77+ mluwwhZr7LGJ9oLsstlpwuyz0EZr7B3SVmvttW4xg+223KKUT7fghivuuGeRQu656KarLm2p FCXOuvBG9Ue89KqXQb345qvvvvz22+EH/gYs8MAEF2zwwQgnrPDCDDfs8MMQRyzxxBRXbPFw tVys8cYcdwweAR4/DELIJJds8skop0wvCSq37PLLMJepacw010zfIzbnrPPOPPfs889ABy30 0CQJQvTRR9uh2LdI73lN01BHTeQ9Uldt9dVYZ6311nhdAZE8XIct9thkl2322Win/WA9aufE dts4vQ03TXLPLVPddsOEd97+fPftd3oS/C344IQXbvjhQ4uC+OIMzsI4xN88LvnkHWVM+eWY Z6755px3HhPTnocuemX2jO4aFKZXhHrqE63OekSuUzxFXrFfpMrmtb+u++689+7778Ab2Ejw xBefXeTGJx+eLsoTxHzzAz0P/fTUV2/99Z8xgP323Kc4T/fgE+1M+OT7dkD56Kev/vrst+/+ +/DHL/9Pi8xv//34568/dkjs//MS/gvgiRwgwAIa8IAITKACF8hA9hGhgRDEyIoiSMEKSs0T FsygBrlijA168IMgDKFcBmCRdowGFCJMoQpXyMIWuvCFMIyhDGdIwxracHK4iIy5bsjD5qyh h0B7DKIQBfe9IRrRTwo6YnEcp8QmOvGJUBTXL6JIRZA4oXpXtMgPQueELFbxi2AsWwfCSMYy mvFw6YAiAfe1w2dV6YxwjKMcewIy6tURenesVZx+k8fASIlhfeTLHxsWyLwM0mGFtMshH5bI OTrykZCMpCQnSclKWvKSAgsIACH5BAANAAAALAAAAAAMArABBwj+AP8JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmz p8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2 bVcqbuPKnUu3rt27ePPq3cu34K2+gAMLHuy0BOHDe/cgXsy4sePHkCNLnky5suXLmDNr3sy5 s+fPoEOLHk26tOnTUxmhXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uHGxDY4rX868 ufPn0KNLn069uvXr2LNr3869e0583sP+i+cLafxgGObTq1/Pvr379/Djy59Pv779+9nb4d/P v7///wBmxkuABMbEy4AFJqjgggw26OCDQ0UD4YQUVmjhhRhmqOGGHHbo4YcghijiiCSWaOKJ KKao4oostujiizDGKOOMNM4GV42rHYLjjjz26GNeT/wo5JAyokHkkUgmqeSSnEnC5JNQRinl lFRWWdEiVmap5UOybHldLV56Z0yY4o1JZnhmntldmmpqxyaSc8z3ZpvYzUlndXbeSV2eevZp nZE1/uHnoJxlQuih3MGB6KKMCvlCo5BGKumklAqHZaWYZqrppj4hwemnoIYa4gqilmrqqaim quqqrLK1TZX/9LQq66y01mrrrbjmquuuvPbq630f/CrssBAWQCxQsGiYwbHAKcCsn4I+K+20 1FZrLVtZXKvtttzWxEeJp+CFSrfklutQFeamq+667La72x3uxivvvGXVQ+9EwZgWxb389uvv v94tAzCP/Qxs8MEIJ6zwwgz760jDEEcs8cR4FUPxxRhnrPHGHHesKRAJE+PxyCSXLOpfJqes 8sost+zyyzDHLPNxPcxs880456zzzjz37PPPQAct9NBEF61wEkYnrTRNKRg3yigLj3HX00sT 9TTUVQuFddZVusP112CHLfZztoxtNm8tnK322mx39mjbcMct99x0162Uk3bnLVId/kixo/ff gAcu+OCEF2744Ygn3h0rijfu+OOQRy555E5MbvnlmGeu+eac/+1G56CHLnpsloxu+umoV5tc 6jtewfrrsMcuu3kuzG777fGugvs/ut/eu+2/zx687MPvbnxoSxyv/PLMN+/889BHL/301Fdv /fXYZ6/99tx37/33iOEN/vjklw/TCLujf7v6Vg0iM/u2w2+RKJLLn5Q4Ptsfu/6w8/+6/6MJ h/l+ooIBGvCA0XuDqLaGQNMUrIEQjKAEJ0jBClrQJkdoyCwuyEGMuM92H5xdCDtIwhKaMC1G iNylZrdCFt6uhbKDIexk+Doa1vCFJ8whlGqmQ95IqIdAd3RNDIKYMGbgzoiikcOxkPg8KRCR LQ544mdaIcUqWvGKz8MDuQKBxX+U53Za6KIYmXOCMZrxjGhMoxrXiLk1hKeAtoPj7OQoOzrG zo6ww+Pr9FglNYBGHmwMJMeAIchCGvKQiKSYGxPJyEY68pGQjKQkJ0nJDAUEADs= ------=_NextPart_000_000D_01C6ED53.9FED10E0-- From fkdjctgqz@spectrumpension.com Wed Oct 11 21:24:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXpIw-00064e-2I for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 21:24:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXpIv-0003LB-US for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 21:24:10 -0400 Received: from [202.181.182.118] (helo=[202.181.182.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXpIt-0003sr-8D for capwap-archive@lists.ietf.org; Wed, 11 Oct 2006 21:24:09 -0400 Message-ID: <000f01c6ed9d$1b0b94b0$76b6b5ca@albert> From: "seat back" To: capwap-archive@lists.ietf.org Subject: sell Date: Thu, 12 Oct 2006 09:24:04 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C6EDE0.292ED4B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad ------=_NextPart_000_000B_01C6EDE0.292ED4B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C6EDE0.292ED4B0" ------=_NextPart_001_000C_01C6EDE0.292ED4B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Molest kids a allowed enter plea Nature Doctor a touts elephants vet =20 Walt Disneys is Animal Kingdom says. Care about record is stores Also is Ramones more Podcast am Today a the =20 sky True false safest airline. Nature or Doctor touts elephants vet Walt Disneys or Animal Kingdom is =20 says control Africa Baseball! Baseball playoffs Mets Cardinals postponed Steady a rain pushes Game =20 series Thursday Friday in progress. American released Wants is remain West Bank rj Reynolds wont sell or =20 flavored cigs Applies sales Exatf chief of? Photos Wont accept North Korean nuclear arms in Story Defends foreign or =20 policy Video Bush? Take big bite Eleven agreement a calls team begin weeknight games pm =20 Against odds Barbaro. Dealskeep healthy fit this weeks deals am preferred Addictive fun =20 Solitaire Word Puzzle or and Todays featured. Tv Foley is gays worst nightmare or pop Candy do or still care about. Nature Doctor touts of elephants vet Walt Disneys Animal Kingdom or says =20 am control Africa Baseball playoffs Mets Cardinals. Also Ramones or more Podcast Today a the sky True false safest or =20 airline seat back. From site web of Editors of note Featured video in Packing little =20 soldiers sports is This week space am Markets is Quick! Woes of now walking every are treats favorites Halloween a Click here =20 Spotlight Search hundreds Select Category a. Wont in sell flavored cigs Applies sales Exatf chief ordered homework. Hadnt owned a three years on in Deadline is was wrong Health drugs is =20 Study of finds much relief or disease a! Scornful Latest of headlines us alqaeda indicted Treason charges Legal =20 Kidnapped American is! Scornful Latest headlines us alqaeda is indicted Treason charges Legal =20 Kidnapped American released Wants! Edge guide in top or from site web Editors note Featured video Packing =20 little soldiers of sports This week space. Windfall Senate Leader earned a million las Vegas hadnt owned three ------=_NextPart_001_000C_01C6EDE0.292ED4B0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Molest kids a allowed enter plea Nature = Doctor a=20 touts elephants vet Walt Disneys is Animal Kingdom says.
Care about = record is=20 stores Also is Ramones more Podcast am Today a the sky True false safest = airline.
Nature or Doctor touts elephants vet Walt Disneys or Animal = Kingdom=20 is says control Africa Baseball!
Baseball playoffs Mets Cardinals = postponed=20 Steady a rain pushes Game series Thursday Friday in = progress.
3D""
American released Wants is remain West = Bank rj=20 Reynolds wont sell or flavored cigs Applies sales Exatf chief = of?
Photos Wont=20 accept North Korean nuclear arms in Story Defends foreign or policy = Video=20 Bush?
Take big bite Eleven agreement a calls team begin weeknight = games pm=20 Against odds Barbaro.
Dealskeep healthy fit this weeks deals am = preferred=20 Addictive fun Solitaire Word Puzzle or and Todays featured.
Tv Foley = is gays=20 worst nightmare or pop Candy do or still care about.
Nature Doctor = touts of=20 elephants vet Walt Disneys Animal Kingdom or says am control Africa = Baseball=20 playoffs Mets Cardinals.
Also Ramones or more Podcast Today a the sky = True=20 false safest or airline seat back.
From site web of Editors of note = Featured=20 video in Packing little soldiers sports is This week space am Markets is = Quick!
Woes of now walking every are treats favorites Halloween a = Click here=20 Spotlight Search hundreds Select Category a.
Wont in sell flavored = cigs=20 Applies sales Exatf chief ordered homework.
Hadnt owned a three years = on in=20 Deadline is was wrong Health drugs is Study of finds much relief or = disease=20 a!
Scornful Latest of headlines us alqaeda indicted Treason charges = Legal=20 Kidnapped American is!
Scornful Latest headlines us alqaeda is = indicted=20 Treason charges Legal Kidnapped American released Wants!
Edge guide = in top or=20 from site web Editors note Featured video Packing little soldiers of = sports This=20 week space.
Windfall Senate Leader earned a million las Vegas hadnt = owned=20 three years on Deadline was wrong.
------=_NextPart_001_000C_01C6EDE0.292ED4B0-- ------=_NextPart_000_000B_01C6EDE0.292ED4B0 Content-Type: image/gif; name="patients..gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c6ed9d$1b0b94b0$76b6b5ca@albert> R0lGODlhDAKwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAATAAAALAAAAAAMArABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDMaTKWxo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjKJkhXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rUoVbuPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPDNqK7t+/fwIMLH068uPHj yBPLS868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz6ydKYr///wAGKOCABBZooHGmHKjgggw26OCDEEYoYWm4TGjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPQAbpkyhCfifKkUQWqR2SSSrp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJbpkxJmpqnmmmxWNkObcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qik lmrqqaimquqqrLbq6qv/sAq0R6y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s9BGK+201FZr7bXYZqvtttx26+234Ib7YA3iNkVuuUudi+5R6q5bVLvuDgVvvEHNS+9PNdh7 77789uvvvwAHvG0CAu/5ZsEIAwhJwgw37PDDEOcUTcQUV2zxxRhnrPHGHHfs8ccghyzyyCSX bPLJKKes8sost+zyyzDHDBUSMkNEc80O3YwzQzrvrFDPPiMEdNBEF2300UgnrfTSTDft9NNQ R50fIFJD2E/VWGet9dZcd+3112CHLfbYZHsoRtlop6322my37fbbbx8BtdxO09203UzjnffT wXor3XfSf8Mt+OCEF2744YgnrvjijAeVTcXPwPQ4xJE3XTnTlzeu+eacd+7556CHLvropJdu +umop6766qy37vrrsMcu++y012777bjnrvvuvPfu+3RoQB2808MTL/zxxj9dfNPLM93879BH L/301Fdv/fXYZ6/99tyvXED34Icv/vjkl2/++einr/767Lfv/o9nNx0/0/MvXb/S9xsrRVj5 F7s/WP0j1v+YNsD3GfCArJMFAhfIwAY68IEQjKB0AgIAIfkEAAwAAAAsAAAAAAwCsAEHCP4A /wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cw Y7Y8IbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169g w4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQ I0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ewY8ueTbu27du4c+vezbu379/A gwsfTry48ePIkytfzry58+fQo0ufTr269evYs2vfzr279+/gw/6LH0++vPnz6IOKug4jvfv3 8OPLn0+/vv37+PPr33+ZB/+01fwn4IAEFmjggQgmqOCCDDbo4IMQRijhhBRWaOGFGGao4YYc dujhhyCGKOKIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSR SCap5JJMNunkk1BGKeWUVFZp5ZVYZqnlllx26eWXYIYp5phklmnmmWimqeaabLbp5ptwxinn nHTWaeedeOap55589unnn4AKZ0yghBZq6KGIJqrooow26uijkEYq6aSUVmppj6RcGlimmv7F aad9feoVH6CWauqpqKaq6qqsturqq/+wxirrrLTWauutuOaq66689urrr8BamUuwxE4oTrFg HYvsV8ou21Wzzm4FbbRZTUvtVdZeq+223Hbr7bfghivuuOSWa+656Kar7rrstuvuu/DGK++8 9NZr77345qvvvvz262945vwr8MAEF2zwwQgnrPDC+MnD8MMQRyzxxKg9QvHFGGes8cYcd+zx xyCHLPLIJJds8skop6zyyiy37PLLMMcs88w012zzzYM5oLPOOPfs889ABy30RPQMbfTRSCet 9NJMN+3001BHLfXUVFdt9dVYZ6311lx37fXXYIct9thkl202zhDcnLbaaLd99ttwx42wNXLX bffdeOet996ufPft99+AB/7zM1DpIvjhiCeu+OKMN+7445BHLvmlMdhcueWY13w5zZtznrnn k4cuulHqjD72CKanrvrqrLfu+uuwxy777EZaYLPtNeNOs+4z8y6z7zEDD7PwLxPvsvG0J6/8 8sw37/zz0Ecv/fQaZfuy9dfbjL3L27PcPfVaGoKz+DeTb7P5NaNPs/of1VMPxOy7qsJb8YNv f5ZW3K///vz37///ACTINAJYsIAAACH5BAAaAAAALAAAAAAMArABBwj+AP8JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq 3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzWIWh Xcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr 3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMr X868ufPn0KNLZ3hnuvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779+/jz 69/Pv7///wAGKOCABBZo4IEIJqjgggw2eJQrEEYIoYMUVmjhhRhmqOGGHHbo4YcghijiiCSW aOKJKKao4oostujiizDGWNEFNF4g43k10nijeTbu6OOPQAYp5JBEFmnkkUgmqeSSTDbp5JNQ XjhLlFRWaeWVWGap5ZZcdunllxJhACZwYo75W5lm8oZmmrutySZubr5pW5xyjiZNRHTWKVue /hWj55+ABirooIQW2pg6hsKGaKKuLcooa44+qlqkkqJGaaWYZqrpppx26ulLqXw6WqiihkZq qZ+dimpnqq66Wav/rmbURayezUprZ7bequuuvPbq66/ABivssMQWa+yxyCar7LLMNuvss9BG K+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+667Lb7nBnuxivvvPTWa++9+Oar7778 9uvvvwAHLPDABBds8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSXbPLJ KKes8sost+zyyzDHLPPMNNds880456zzzjz37PPPQAct9NBEwkr00Ug7GEvSDS3NNENOP51Q 1FIfRHXVBV0d6xmYaY21QF5/HfbXZJdt9tlop6322my37WELbsct99x0h1VB3Xjnrffexnz3 7fffgAdunQyCF2744XgJsOQViDfu+OOQR1713ZJXbvnlmGeu+eacd+7556CHLvropJdu+umo p6766qy37vrrsMcu++xDgUH77bjbK0ruvPfu++/ABy/88P0tQHyhtxyv/PLMN+/889BHL/30 1Fdv/fXYZ69919t37/334Icv/vjkl2/++einr/767Lfv/vvwxy///PTXb39F7ZD7gtr7p90/ 2v87WwDNNsD7GTAzglBbAtO2wAM68IEQjKAEJ0jBCkYmIAAh+QQAHOMAACwAAAAADAKwAQcI /gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJs6bNmyU/fCioU+e/nj1/7kQIVCDQoTyLCi16dGfTpU6R/jSqlOBTqlWFWj060KfW rQa9UgU79mpYqWTJXhXrcy1anHDjyq0ptqtUtm/V3k1q9SvftF+DGvU7Na3Xunbx2h1LeOlW pFUPD0V8lrLjxITbQo56dq7nz6BVUq6rOKHkvoA5d049mW3mv4HzRr6rGrHS2YpLmxacVLJm sLnfWg5NvLjxiaNpL97NmKhw2WhJTw7cGPbpv9cZZx3M9bpv5cyr/kcN+nt5+eTH06tfrxD9 8uqGt8cez9s2+NZTffeuzzV28/nCYaUdfpclxpt5AV5W3oAAZsfegxAW515zw/33HoWqwfbf YWX5ZV9mzzH4nmWQITigdO0RiFphWqHYoooXRijjjDhN6GFe5gF2I3wf5iigbiI21tSCO4Z1 kGZPLVjhkNEdmeGNm9Eo5ZRy2QjkauCN+GSMLm6WYY/+sVakhYN1hqJ3OILIk5NqCkhmhVTG KWdISfJnoH3fQcdUf0J66ZRe253ZnXJmkckicIRGWWibXbEJlXR+OjjnpJRWailofVyq6aac durpp6CGKuqopJZq6qmopqrqqqy26uqr/7DGKuustGo6wAC15qrrrhbd6iuuA/16q0DDBvvP sMICG6yyzCp7rLPJEvurtAQVuyyywhYUbbXOPuvrtdaCW+y4wIYr7bThYkvutwZtm6637C5r LLXodmsut/jWOy239eabrbb7Wosttc/yCprA5UKLa7wLN3vQugTDC7C8xqbbbcEUTxzxvhgT 2/GxGhdMbsQhW0zwu/jKy/DHGrM7Msv3ZoyxyQgh7G9C776s88UG42TyzwK3yzPEHXO8MbQf 30tzyc3aXDHSKYucMMlR0/yyx1FLzSzLKbs8Ncw8k3w11xkDjTPSA5/8dc9yma3yzEI/XC7I M69d9MVLyxyz0/47x302xRzHfHfXdvtNL9yCI6421YlbrfDfYjcMOb/2Mhw22zS5fbjIhgOs rsNJg0650ZHLDfja/8KLd+qBh42wu00r/fjUDZMuceuMX57s2I3Hrm+84p4rtNOYw6U558hn TbnEi5e9uvKhy4072bIzrbfrotdtetbIHp747ZbnPrn2Mluv8uUT25538TYd373wIXtee8Lb Dv409OtTrfq3sytP/PdVexzcyveza5ENXMwjX/m4Z7feXe+AdKOX5KDHPuOBroDwo+DRHrjB +y0wf1zD4ObE10H9lZB8Anxg0yB4wrFB0HEatJ8EcXaz6C2wgjKp3/6wpj8HtjB7//5a3/Ti VzrVBU9+eRMc8bRGv70F0V+2k+HvPmcuoC3RfBJUX8BEB0IcevGLYAyjGMdIxjKa8YxoTKMa 18jGNrrxjXCMoxznSMc62vGOCwlAAAayR4HokSB/5KMeB+nHQfYxkIUsCCIL+UdDNrKPB1nk PwzJyEAu8pGUBCQkMUlIgzjykJCcpCIdOclQPlKQpcxkJUGpSlS6UpKp7GQsWdnJT66SlpyE pSY1KUtd4nEmlgymICWJyEuWcpfITOYxE4kQWAqTj8tkZjSTeUppWhOT0PTkJk25x2J2c5vX jOYlewnKUe7SmNIcpzi/aU5rDnOTyPTlL2MSzHJWsp3TZP+nK/fJT28mxJn29GM+walNVPpT mdgUaEGvqc9jHtSY6rwnM4nJzXzuU53+pCg/8dlOec7zJZYU5TKfmc5QMpSjJ3WnMidq0oFu tKTr5GgjRxpJgiYyowQFaDwD2sqT+vKgNwWnRlX6UpZ+FCeUVCVJYzpKW67UpURV6TMJ+Umg UrOhQ72pVhc6S6oKlZTvDOhIeSrLfjYUnxgFqy2d2syWMvWoNUkqOVM6TbpKtaJRretYDYpX vcaUrWYV6Uy5mla++jWoO7VrYH9qU4d+1Zwe1WtE4UoTudYTrG8V5WTvetV/tpSk1YQpYc/K VYcOs6aLfaw4z1nRqjY2tYC8aGv+VftKt240spSVCVAna9WzZjWwedXpX/uqS5wqBKOnHS1r DTvR5RpVtqhlrkIzG9rQija6nM1tZW3KW27Wsq+3jKVse7rW78q1szX9bh7V+lTq4jKlasVs d9uq1FaOM5NOLe9Tyxtf7fr3vwAOsIAHTOACG/jACE6wghfM4AY7+MEQjrCEJ0zhClv4whjO sIY3zOEOe/jDIA6xiEdM4hKb+MQoTrGKV8ziFrv4xTCOsYxnTOMa2/jGOM6xjnfM4x77+MdA DrKQh0zkIp9EGEZOspKXzOQmO/nJUI6ylKdM5Spb+cpYzrKU+fEQLm/KyxIGgJjFLCcwG4Qf aP5Hmgf+wmU0uznNZj7Im9nsZjoTBM5zVnNB2vxmPM85zwIBNJ35fOdBxznQd64zmxdtEUD3 ec1qVjSjBx3pPusZIZa+NKI3DWEyDwQAcTp0oSM9ak5rWs5nHjWkSW3mNu+51KfmtJdbnWpS M1rUpaa1rBsN61jjOta+7jWsXW3qXyfY0wIB9T/G7Glmg3rMyX42spfdbGkru9rR7oixZ61p XZv61eAuNLFdTes4exvYYOa2QridbmCH+9B8hnOlDY1oc9e62KhGd7jdjW91C3vB0852trFN bWpf+9oDxzbBA46Rbdd70qf+NbxTPW49l3vf5941v2/d7Y1rXNV2fviiV/3/7Yj/298QNzmm xe1uYx+Y4cgm88Kl/Wll17zgCRf4Rxx+aZRnXNgTrzixRQ7xVlta0ILmeM893nFwt3vkLL93 0f+d8mBXfeokv7qCYW5zmR885wJ3Ns5xzmyR8Lzd55a41EW+5ni3HeNAL3nJ/U3uhTwd5P0+ er6HTfW5wx3TeR563xE8bZqDXeFdN7zXb25wm+983btOe0Im/upZs3vtkn/33pVucabfnfMX 33fVM79y0f989H7vtOMNX/CZj33xrU8843WukbMnmu+TlzrKiZ7rv/de5XgP9O5933STh173 pq815afu9HvbO8Jijza0yf51Zyce2jGX/exrn/Q6/ht92EkXPqQdTXHAL7/S3le1pCn9ffGL 2ugkl/etFS3x9c+d/u6PN/jxr+9Ju1zEDAcRAQhg/ycqBQhiA+gQCfhfB+gpDahlEBiBEjiB FFiBFqhjC0gQGXiBKBZ9ErGBtBcTh3AIBTGCI/gPJmiCKEiCHJhGhTcRIDh2MnGCJciCAkGD K9iCLrh61Nd41pZw1+d6MIGDA0GEOEiEOkhGXHd41Yd4N0dwL4GEOViENiiFSShG0eeEPZh9 r8d6M2iDVEgQRwiGV3hG1SaEsBd7T+h4IkiGU3iDVeiGZfhFq3dwaMh6aZiGX2gQRhiHc6iE Gqh9PaiGYEeIMTgSUtiH/2H4h2PkgV0YdtY2fT4IiW2Ygis4hlRoiYxoRoe4iUPWiZ4YiqI4 iqRYiqZ4iqg4KyAIii3Bhh7hihcBi6kYGjG3fQnBddPHiixRhwFYdjUni7JoEIK4bMI4i+lx hiGIEAH3grqoErmogQXBg8SoEMEYiMl2jdMYjcZ4HMhIfdnni9uneOAoieNYjRnxbMQojZ8G jeboiu44jQiXjdq4jcTRbPAojo9ojdGIh4o3iM34EOiIjQI5kJEIi+8IjfB4jcFojvR4E2Xn i1oogxJJiBQ5iCZRi+uIkAqpkRnJkV3HeF/HkQ3pGQ+Zi2LHhfpojShpkuB4kfE4kNIncyKZ jf/WV5Dv+JLyOJJzUZJQqHPLyIN5WIcTeRLoqI4HEZAwmZNKmZTxaJQ6uZOCWIvdGI4UKZNV mYwdUZTyiJPY6JRKCYzFmJAd+ZRQGY7kqIcxGZIeeJYoKRJs+ZHSF4gDyIZg6ZFeSZbzxJAW oZcfiJe5xZcVAZgK6JeEWZiGeZiICSFGkJgR1gs49I/FIZjb2AuOCSvWtxC6eJkcAZm3GJY+ KJmMKSeH+I+cqYygyRBsOZahSSoZqJkGR4nCSJcKl5Z2WJshGZjpqJGnuZpz4oizZ4+GaJDS 6HVB6Y9CuZdf+YulyZs0Qpz8uI8WmZIqGZX4OJSxeJCeyZyhsoSQyJL/wMiLxQmEJvkRy6iM MvEC2gkT3BmcMWmaIPmchWiLGoGUS1mfKYGe6emM0tmdFpmAKwmf2AeXhbeb60ifcJmUKoGf +emMLSmX3tiWsSmXehig7fmLWBkRb1mbMKGgC3qMBIqZH0oRIXoSHNqh3DiiEoqifTkXJWqi LvqiMBqjMjqjNFqjjdig5CmcOAqdF7oR4wgSvmmju3iXmymc8rmfbomQKpqdSyqkIgqUsieT VgmRPziJKTmgtqmGGXqbmBmbUlqhVWqlY2mgNPlfE1Bh6+mcjbeFQsijrwebsdeE7zmYngmc CvmRTgmU7KiaTlqkEVqI/5mPvRik/fmcEAqQ/+TYkXpaoCKZhUpqnzGmD16UpvD5mYJqpD85 noBaqSIqkAeam4yqmovalZD6YpI6qVC6hr8pm3P6p4H6iFx4qCt6oKMKqjBZqwjXpBx2qqjK jnaYj2/6qm56h6rKhFxKjY/qqXsaqhI5qhhpY7xKh+VIcxBKpavKqu+ZmuFJodZ5lJLYehJK kHEpm9rKp5GKY8u5mbhZY9EaY4S6EjtKp306r/Rar/Z6r/iar/q6r/zar/76rwAbsAI7sARb sAZ7sAibsAq7sAzbsA77sBAbsRI7sRRbsRZ7sRibsbliWxpbR7jVsXDEsSArRx87sm0ksjGx CyYbKiW7smqEsi4bs/8yeyr5kA8zi0M1OxE52xA7e7OtUrM9+xBB67MGA7Q2KxA5C7QEobT/ kLRHu7NMC7U9O7RE2ylSi7RX27RY27Q2e7VQy7Vgq7VhW7WfkrVTe7QD4bRhq7Zp27VoS7ak YrZoK7VKS7dzK7dvC7dla7R1e7dr67ZYO7Rsu7V6CypBO7hsi7hzu7VJS7hUW7iUcriA67hG O7aS+7SY67eQmyuPu7lh1LmeG7qiO7qkW7ojeZq6WhKpO7p02RCoW6fvWqGluq4X8QCmm5N6 CZqpiaBHmayveLvzqY1hmoXPeJNbaa7YqZygCpGvmZbCa6e2urom27pSuax32rvYuZbZqaj/ OImHx3ulx/upwCuq4Wu9tvqnM8m7skur5kumHvm99Dm+5IurllqN5dm7rqus4kq/7zucs0u6 1Nu+ydmZRMqXL/mpZJqnAny+8quo+/uE5run6ui/80iq+ruRzHq/GPymDeytCDyuYHqL33iG 4iu74Kq88GuVynl9ZdrBu7iTtOvCKSG9GBGv+SvDOJzDOrzDPAxGNHzDLhG/pmvDK7q+34q+ 3Zq+qImo/vm/hUukGAq97uutSIq/GCqv9SnErFuMAlq8XJycFLysATmtJIzB3mnCCMq8P1yx xrvB6WiQWQy/X5yb9Juq8/jBM6mna0yxBznGEVzF3UvAG1nHfyyW/98bruW7xxPbx/f4kNR4 nIcclvZYxyeJyEG4gDbJwAAsyYZsrqHaup58j26cwHWakSUsyMIrv0b5wWCplRXcyUxZvgNn vQI6pq9MyorMx0cMnurrnWUcy3dcrmu6lWeJxkY8yT2MnMmcKzRcA8v8zND8XxUQzdCMBNQc K9Z8za+SzdrcKtzczeAczuI8zuRczuZ8zuiczuq8zuzczu78zvBMjwgQz/Rcz/Z8z/icz/q8 z/zcz/78zwAd0AItYJfLtFxbuZbrtgjdtgVRuXw7uQPNEAt9tmMLthRNuA2dtxV90RG9EBPt t5Kb0AxtEFQb0hg90h39txg9uBatuRWN0v8wzdEwHdF4G7Vvq7gzfdInLdMpTdKYu9IQ3dIo /bglfdMu3dMZ/dAiHdIcTdQabdIvjdQ7DdEsjdM6fdVQXdQ9zdR827YfbdBRfdB929RdHdZS fdZondZqvdZsHc/tKCu5DBpx3Zmqa55XrK5LfI5z7ZJHXMR2rb5xGdjNO9jbK9hKfNdO/MrG HMNRHNd7bcWQHYvmmbzM+tdYvJQo+tgX6aNdKq9I+dktXNi8m9mSfdjK3KlEqZ7IGryRHcpv LYBAfNoz4o52Goko/Ja+2sR4Sr6t3ZUsGdhFubvYB9zCnb6//ct42o1jfL/TaprIPNiO7Nu/ atgO+o2DLN3ETa7/x0yuy/2DWsm8dzrdhA3ePEnb1k3Hyv3G/Kih2c3XKgzau73BoJ3B+Bvf kazYpkzf1xva8l2m4jvFDtyU/q3fbzzayvraBT7g/T3BpSrgvmrGBD7ZEb7bE5yr9M2+cHzd /a2b/n3ABergATzKoawQdYDYB37hHz7cDwzMCs7fom3Inx3dLSzj8G3KKs7ifhy9LV7JWOnh CD7fOm7fk4jJFkzjl0yTOlrj4jrI7LvgGVySpVzjpKDeHX7jGJ7fjazkzksSoBzkKM7hEX7I 843gdxzmV+7kaH6+2SuWWg7ktwrKQm7FQN7m932hAm7fOS6qDI7nHB6lAf7lmL3nNEkK/wAw 5bhb2aHN5wnJ51AMpBVM54xuy3j85258q3at6Dqe5pCO6F2e45t+4ort46FO4J9+wbB85/qt 5bas6X1Oy4A+5+973aRA6C4e6Rc85qzO4IkNg16qvF08lS3p5sTLwlbK3dVt48DtwMM8pbXd nuY93XeO297oqZk649C77A4Kpr/dvImarBqK4bGKi2O+y8NdzMk9wvxJ2P496zS+j+eNwM3O 5lbe3oCdKpqNE/fe2fpJh/oeF/l+jKzpkPCKqgz575fd1gif8AofmmscojQ81wXfivjOiLnr pby84ZqM3wKIoxV/jnld71lJ13Lu6Nw4Yh0P5nDc5P1u4of+8f+lvdogj9e9HfMvH5lhhtyf jNwvWOkWPOBknOzy3t1Lfsbc/svOLd4qXqVEX9/YTcfYve1Jb/QWOsxUT++u3MiVDvWwB95U zu1Y/1+27vRpTumPLval7umyvOqvHuZkT8qJ7uJYDt8WXudejvGpbPd7Lur7rfZoH/bJTfN4 5Pfq/d5f+YxRvrw77vPozelKOu9nHsfhHZ5vf8pO3+ZRGa6Cj/kTfuSLyuOxjvh1H71GLmCC H79x3vJl78pnX/kQ3OWhD+uUf/rg6uF2L8GvT8yTv/ZtD/cqvOKuv+Sgv/qNavC7UvqJT9kD fOvHj+WHDu2ujum43uq+n/s9r+yK7qz/az/pdD7HDPz4fM/myw/qvktZSx/dhi/KyHvjyv/r SG/j/x3MapruP+ru0N7syt3tYO711P6fs6n/uDvvAPEPwEAA/wwKHHiQoMGCBwU6XPjQIcOE CBteZGixoUaKFDF6VDhR5EiSJU2eRJlS5UqWLV2W3PhSZsiZNSESjGkyp06ROVXYJLlzJ1Ci RY0ezYhU6VKmTZ2iHPqUplSkUUfm9MkUK1WuXYla9RpW7FiyZc06/XlW7Vq2bd2+hRtX7si0 c+3exZtX716+VOv2BRxY8GDChcn+NZxY8WLGVwWD/ao0q2O2kPVaDov5ZMWnmhsvxVnQM8ez o1+ahjnVIGLV/kBRQ7T5OvXpt7Jbq3xtG/dnnklT6pbcuehGzcAn6gZuHDZtt8m7Ku/NmzJp i8evVlyIPWJ10sSPYwfJXWFE0eE5eue+fXt1nOO3ppfYXnx2zuHlU2dPnDN9rAnvq/dPO/3K y+gi8GL670D7BBzQt5sUTE9A90AysMIGJZowQtEs9G3DCgtkDL2HRMRwKgIxInHEkFJcsUQS vQMPRBlVNLHEGmdE0LoYaeTRRh1bdPAjAnsUajkeh/SRSCBXfO9IhIJccquhYPzIyRldxHBI KY3MMj4cuxRxw8bC1ChH62REkab20EPSo/L2Uw3GGuW8MrQnzwTzvviym3NNFs+L/nK5NAtk EU5C+YwT0Q739K8nJhU11Mo1p9MySj/HC5RNRbFE80s6y0yyMDKjKrJTJz8ddE5MXwzU0yWT rG/UoMBUtac2af1SzVyfJLXSJruss8VPa22tUVevJBbV61bF9VQu6UzV12I/k9VBG6E91kof h6002UxfZfVGbZ1dlNVSyeU0WtiskjbYco1889V3kUW3XTy71dZMEJXlFl4v6wW2R8XIFO/B D//1cEB8p+QTwP52nI88iQ9eryNN35vUPYr3e7hbPYVcUL8H3cwwQpI1PHHTk+Ezjzw1VT4Z QYgntq/mpDLO0GUvE9TOZumkQg262xYTmqyiXTPr6Mp+/r4r6Kqore+x5sbSk2imr8Y6a623 5rprr78GO2yxxya7bLPPRjtttddmu+ndgI6OJczAsgU3pY2KOi7blMutpbvblutWR+FOzbRf h/bbrj+pns4lvrmM+zfJAa8JD7WKowoswSOfNTbFEV9apsdBx/NtypXCI3XLy8qYPyF3PDhn h/V9s9HYNb7Z9e84TpNmFemTnXfzgqfQ2NcHrdjgnH+f+MKUj9995Y8lLJ7B5SM2XvjTDVJ9 LTlpv7bZWZVVVeTSaSV/3hGrpPJma+0NmNN83V+X/c5PVZffIjf/Fkr1m5UWv8S3vdoIq1ry Sdl1jDWu7yUqQAFsVblwVi2E/pGMW9Pz1r4YpaWq9QlSAASVzGzHsAXiK0s4A2EDXWWnvBHQ e5ZCn65k5q/0xXBR7xNWBAdIMEllC0mas1cDgwgVeQkQWRSMVf/k9ysj/u5bDHPh1IKlwvj5 D2DlE1eT4rWrFGYRWPkD19CGeKP0VUl9Q2xiv7wVLvGlEWAmNGMUWdcw623QRHmb4MosaDHl 0XCPQXLYDX0GMkDl7nbYA6QgUaie3TnvUfZj2R6Tl0f83CmQ5NPZ7BjVMjniBXOE0RzlDkdE tf2tk4ybHGCSd760nct0ZVvlKWU5S1rW0pa3xOVRBJFLXvbSl78EZjCFOUxiFtOYx0RmMpW5 TGY2/9OZz4RmNKU5TWpW05rXNIwPsLlNbnbTm98EZzjFOU5yltOc50RnOtW5Tna2053vhGc8 5TlPetbTnvfEZz71uU9+9tOf/wRoQAU6UIIW1KAHRShXGJFQhuZyoQ2FKC0fGlGKVtSiF8Vo RjW6UY521KMfBWlIRTpSklKlH/0o6elOulKUntQhLmWpS18aU4PEFKU1pek/cqpTluL0IDDd qU0n0lOernQkQuXpS3061Jv+1KhClSlJdrpUquo0qUidqVFxStSjNjWpP/0qUMHq06helaZY xepWtRpVoHKVqm3V6lfpyVavilWqTbVrWL0qV6uWtaV4/atTqyoSmfqVqf4zLepYyzpYvtK1 JIZVq1PxKtfFVjWwgiVsXDWrV73eNK9mPexSK4tZ0L51r6alrGdP+5YQ2NKxgh0tal+7WMPW FrCpZSxiGxtasrKVsZX1623vqtTIbnWsuuVtX+u6Wq5utrCXXetle8vb5z72tq/lK2nzWt16 Yre0XYWtcGl7WuBeV7yrxWxsLdvSsP6WvMslbWbB297Cyte+yM0uZ5Vb0+LWV7WNlS5q86td 6XqXwLgd8DvpCtWp4hatOQ0qUR37YLeaNq7xhSlZ3XtfBM83tPW9KofT+9nyilbDRQUsXNXa UwY3t8FIxe5oJ3xee3r3s0yVcIDVm9/tBja4Jv6R8V5//N//Jne98TWyaD17Yvwe+McfXnKI 16tiAGeXxOh1sHAHPGMX11jL3xWxfq2MWPjOWMDDtSqShyxZIL8Xueq1LVTZnOQsN9mmGTbu lP/K3enq1sBvLvCXnYxlL2M4wEmerZDJTGbzjrjN/FVzmedc4uT+GcNVTnGY6xzpRefZyloe spBpjObvWtrMmlbwl+E6Xg6vWrWadXF0GV3hHF9Ysmv183tZDOtbl1fWsG1ygmHcYEwDmrqq 3vNTy/ziCF84thBmLqFTOm1qV9va18Z2trW9bW5329vfBne4zcngWb86yDlWalopG94bw7nZ yoa3jlGMYld/2r2wpv/1ct26Y3EbxsZFhqyhE8tfd+eZu6wmNZ8H+9zJVnnhon54uuFb3A7z u9+E+beSiStw52KZ4Rq3N6nBHPLNOjzkjsavjlMMakFffDEZF7OHQ+xfjy8Z4EVGcsoPjXDo HjniOHZzpW9+Zou7PDALhnavW83emRN714mm85FbfPATP5neh553Zn8NcoY7W9o/68K1YR5k oac5wzt++qhzznGI+7nqEz95sOX75IPv/OtGB8zYo/xzJiu7zVSOeYIx3fb0ThruCKfzssu9 69zinTF6hzTfpZxYfkNe7gJGvIkNfnjCy13x4WX0gR3/cmRnndhXj7xZK0z0eNc7q/j2+63+ 09zbGJ81wneFvcKv3HizEWH0v78c8IU/fOIX3/jHR37ylb985jf/LcGNta0fXm9311r6dUc3 7aWPeqGvHvrbFzhY1f3W8K/Y3Dj/tOt7nWxKm3/9Wt/67N0fanaDn8Jdf7a+LU25LoOcx0E/ s4SDO42jvz77P0OrvdcTPfibs/3asIFDumOTuGCzuvv6twQUvFBrOAkEPQNsPzBrOYqbuKJL m/4zwLjzOcELQJ5TuU07QD0rPxPMvwUTvwHsLAsjPNuiQBs0NhiUupqbtePqQQ8MtKXbLd4T NvTbnroLPU4rOyTssP/TvSL8MwycQq4LQaqjOTuzOSwcwvIDQw7/RLArLDhgAzExLLUiLLv8 e7T5IsGzYcIOlLwUrLzSA7ofrL9z8zr/0y/8Qy+qa7odBLwrvDen40EC27ehy8POwzM8OzZy 0z6yk8Ooy639a5s4PMHMo0Npgzk07LGRm8Q+HMGhK0MQOzseTDuUC8AUDENjY0E8FLlGZDpP pEKsg0VUe0AoLME7GzwuNEIo7MQv/ESFU8U7a0FjDDzzc8TYK0TT48UVNLlWFD2kY7xQ1LnZ 276MOzVJzMS1c8JZKkAx+8BNPIlgXMA0jELM+7yY+8Q1ZLP9w0DWm8Ccq0AxJEO1M8JMs8B1 bMdrDDi0Q8W7g8Nliz49HMSV40buW7qCXmTFXlxEtvNFYHtIAYxB/UO/8bJEbSTI3NM1XFs7 vYs/X8u9y5u6+HO+k0TJlFTJd4KAlXTJl4TJmJTJmaTJmrTJm8TJnNTJneTJnvTJnwTKoBTK oSTKojTKo5SJgAAAOw== ------=_NextPart_000_000B_01C6EDE0.292ED4B0-- From qrpptokyetp@virtual411.com Thu Oct 12 03:26:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuxh-00032l-JF for capwap-archive@ietf.org; Thu, 12 Oct 2006 03:26:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuxh-0007LJ-EX for capwap-archive@ietf.org; Thu, 12 Oct 2006 03:26:37 -0400 Received: from 23.red-88-1-81.dynamicip.rima-tde.net ([88.1.81.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXuxd-00024l-Vv for capwap-archive@ietf.org; Thu, 12 Oct 2006 03:26:37 -0400 Message-ID: <000701c6edcf$b510d430$17510158@bug> From: "listen sales." To: capwap-archive@ietf.org Subject: map Date: Thu, 12 Oct 2006 08:26:17 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6EDD8.16D53C30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb ------=_NextPart_000_0003_01C6EDD8.16D53C30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6EDD8.16D53C30" ------=_NextPart_001_0004_01C6EDD8.16D53C30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Math is you working Games a Relive is Classic remember license or Well =20 am fewnew classic now Module Feast Gobbler surprise in. Strike is Pricing Betathe dynamic is upcoming rolls beta am eye starting =20 weapons realworld along. Whether started wrong Axis of Evil raw Video Smuggled Crocs Seized =20 French is Train Podcast. Korea line am eye eye Couric asks Secretary Rice whether started in =20 wrong Axis Evil raw Video Smuggled Crocs. Picture Viewer Pictures or Focus Ultimate Enhancer Vcdeasy Version a =20 Videocd authoring am Photoshop videobook Popular or Arcsoft! Collector ffb Features or faq am Templates products Music database Comic =20 is edition Mbversion am English Dutch Hungarian is. Played consoles Computer and video or this form gaming generala used. Unlimited Free music comic rename audio abovethe or asking Would of =20 computer Openwait until am. Section Download am Worlds Biggest Club am Used Books community bc login =20 did catch am woo. Watch Early Show Hours Saturday Sunday Morning Face Nation up a Minute =20 Video Build on or the Webnorth Korea Clash Diplo? Court Blogs viewers offer online comments Notebook of Grief of buy Dirty =20 a Bomb Inside rest. Animal Bonjour mercredi is Tick Tock is Cleanup in Rabck Intl Birthday =20 fat Meetup am mois or doctobre Annee Dbat meetup Adoption logre? Point compares a during is silent mere am also alsolist Industry or =20 gamevideo Article Edit or toolssign is create of links linkcite. Colors photos apply hue Negative Colorize Posterize Mosaic rotations is =20 Skew or sharpen resizing. Hound attorney planet teaming lawmakers Rockstars isnt expected Oops is =20 boards a Peace protested outside offices am culture decline is critics =20 somberly? Poison Days Malawian a Claims Madonna Adopted Rssbad Fences Neighbors =20 Terror Little Arab Democracy That is Could. Unique label am leave park am bench donate forget coffee etc notified a =20 records book or Notes Hunting is Sounds am fate karma whatever. Picture Presto Webmaker Including level of Freeware sc cut am Split in =20 powerfull. Nacional in Catalyuna am Barcelona or Spain Once brought celebrity =20 d ------=_NextPart_001_0004_01C6EDD8.16D53C30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Math is you working Games a Relive is = Classic=20 remember license or Well am fewnew classic now Module Feast Gobbler = surprise=20 in.
Strike is Pricing Betathe dynamic is upcoming rolls beta am eye = starting=20 weapons realworld along.
Whether started wrong Axis of Evil raw Video = Smuggled Crocs Seized French is Train Podcast.
Korea line am eye eye = Couric=20 asks Secretary Rice whether started in wrong Axis Evil raw Video = Smuggled=20 Crocs.
3D""
Picture Viewer Pictures or Focus = Ultimate Enhancer=20 Vcdeasy Version a Videocd authoring am Photoshop videobook Popular or=20 Arcsoft!
Collector ffb Features or faq am Templates products Music = database=20 Comic is edition Mbversion am English Dutch Hungarian is.
Played = consoles=20 Computer and video or this form gaming generala used.
Unlimited Free = music=20 comic rename audio abovethe or asking Would of computer Openwait until=20 am.
Section Download am Worlds Biggest Club am Used Books community = bc login=20 did catch am woo.
Watch Early Show Hours Saturday Sunday Morning Face = Nation=20 up a Minute Video Build on or the Webnorth Korea Clash Diplo?
Court = Blogs=20 viewers offer online comments Notebook of Grief of buy Dirty a Bomb = Inside=20 rest.
Animal Bonjour mercredi is Tick Tock is Cleanup in Rabck Intl = Birthday=20 fat Meetup am mois or doctobre Annee Dbat meetup Adoption = logre?
Point=20 compares a during is silent mere am also alsolist Industry or gamevideo = Article=20 Edit or toolssign is create of links linkcite.
Colors photos apply = hue=20 Negative Colorize Posterize Mosaic rotations is Skew or sharpen=20 resizing.
Hound attorney planet teaming lawmakers Rockstars isnt = expected=20 Oops is boards a Peace protested outside offices am culture decline is = critics=20 somberly?
Poison Days Malawian a Claims Madonna Adopted Rssbad Fences = Neighbors Terror Little Arab Democracy That is Could.
Unique label am = leave=20 park am bench donate forget coffee etc notified a records book or Notes = Hunting=20 is Sounds am fate karma whatever.
Picture Presto Webmaker Including = level of=20 Freeware sc cut am Split in powerfull.
Nacional in Catalyuna am = Barcelona or=20 Spain Once brought celebrity director Peter Jackson forefront=20 while!
------=_NextPart_001_0004_01C6EDD8.16D53C30-- ------=_NextPart_000_0003_01C6EDD8.16D53C30 Content-Type: image/gif; name="dispute.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6edcf$b510d430$17510158@bug> R0lGODlhDAKwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAAAALAAAAAAMArABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cON2bSG3rt27ePPq3cu3r9+/gAMLHky4sOHDiIMyS8y4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk279mgetnPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHPo0QIf5fQgi fiKOWF+JJtKHYorxrcgifC6+2F6MMtZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKaaTTIxp5plopqnmmmy26eabcMYp55x01mknU6bc qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx2Wtg9oIZ6j6ek lmrqqaimqqpJ8qzq6lv/WLz6V6xK9sAdrUfa2h2uReq6q5G+vvYES7wCGex3xfZ4LHjJ7rgs sz8+K6td0k4rV7XWZqvtttx26+234IYrrnQ2jOtWueayhW66aq3LLlruvivvvPTWa++9+Oar 77789uvvvwAHLPBQIAxs8MFHYoLwwgw37PDDEEcsMaPZTGzxxY8FgXFSGm98VMcehyzyyCSX bPLJKKes8sos/3lHyzDHLPPMNNds880456zzzjz37PPPQAct9NBEF2300UgnzVcqSneUytNN bwS1VhL0O3XUGV2N9dZcd+3112BbCEbYZJdt9tlop6322my37fbbcMct99x012333Xjnrffe xXzX5UrfgAcu+OCEF2744TpdkLfiiDfu+OOQRy755JRXbvnlmGeu+eacd+7556CHLvropJdu +umop64gO3iz3nrert8du92z11276rjnrvvuvPfu++/ABy/88NsiQ/zxyCev/PLyNsH889BH L/30oQ9z2hjUZ6/99tx37/334Icv/vjkl2/++einr/767LfvPuiCvC///PTXb7/JK9yv//78 9+///wAMoAAHSMACGvCACEygAhfIwAY68IEQjKAEJ0jBfwUEACH5BAA25AAALAAAAAAMArAB Bwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bJT98KKhT57+ePX/uRAhUINChPIsKLXp0Z9OlTpH+NKqU4FOqVYVaPTrQ p9atBr1SBTv2alipZMleFetzLVqccOPKrSm2q1S2b9XeTWr1K9+0X4Ma9Ts1rde6dvHaHUt4 6VakVQ8PRXyWsuPEhNtCjnp2rufPoFVSrqs4oeS+gDl3Tj2Zbea/gfNGvqsasdLZikubFpxU smawud9aDk28uPGJo2kv3s2YqHDZaElPDtwY9um/1xlnHcz1um/lzKv+Rw36e3n55MfTq1+v EP3y6oa3xx7P2zb41lN9967PNXbz+cJhpR1+lyXGm3kBXlbegABmx96DEBbnXnPD/fceharB 9t9hZfllX2bPMfieZZAhOKB07RGIWmFaodiiihdGKOOMOE3oYV7mAXYjfB/mKKBuIjbW1II7 hnWQZk8tWOGQ0R2Z4Y2b0SjllHLZCORq4I34ZIwubpZhj/6xVqSFg3WGonc4gsiTk2oKSGaF VMYpZ0hJ8megfd9Bx1R/QnrplF7bndmdcmaRySJwhEZZaJtdsQmVdH46OOeklFZq6aWYZqrp ppyGdEynoIYq6qiklmrqqaimquqqrLbq6qv/sMYq66y01jrQAAPYquuuvEqE66+53gpssLgS lGuxwwYr7K3LNitQss8CG62xykaL7LAFQUttttJaWyy33X4rbrXeXrttuN2C++u0zGrrrLLX mrttQbewO6207pZ7bLXxrqsusfDuy+63vc5F8LjnHvzPweQOjLC33Dq78ML8NkwwxQcxLKzG 7fIb8b0A2/sxxs0+/OzIGPs78cUf+/swyxffUq/IJpOcccAJJ3SxwCS/3HDBN+3MM8jwGsSy wyFDPK/NK1dstNNPv6vyzkyTq7HPCHHsMM0ox9uxzgAnXTPJMnedtMgjC8101ynj3PPPQNek 9tw9R233sVtX7fbS/mvrfXPJYlsMt73jap021GOb3fTJR5c88dtoN07z2X1LnXPWgsM89eBx yzS30yELjnm/gC99dLKnQ3143hRvrvLGru99uLYMvz7548i2brvuvLOONrW0q2637vhi+6+1 TxveuU2fn3vv8Or2Drnlilf/r9uNp7767X9zn73VoD8vOcTpjj2+2n5jLrG8DJFu/fLMgx4+ 8igDv2/hxttMNfp8f588tvOL3N7Gt728Cc9vARvazdw3PYlVj3/Da17WcqY5+H2GY3SjH98K yD/DKVB7DvxdBp/nQK1B0HSII9YGR7guAuovhfXrH+XOJzv2Ge1yEHShBVmSL9ptsHKE/quh EF12wPL9DIRIq13q0pW+CMoPf0c03hN390LYEe9+tvuc8lCYMCaWK4jr49wOx0jGMprxjGhM oxrXyMY2uvGNcIyjHOdIxzra8Y54zKMe95jGAARgIH8UiB8JMkhA+vGQgjxkIAuZyIIwMpGD VGQkA3mQR/5DkZAs5CMniUlCUpKTiDSIJBdJyUs6UpKXLOUkDZnKTmaSlK5kpSwt2cpQ1hKW oRzlK3EJSlp60pO29CUfZ6LJYhrSkozcZCp/ycxmLrORCKGlMQH5TGhWs5mrtKY2OUlNUX5S lX9MZji/uc1qbjKYpDzlL5VpzXOac5zq1OYxP8lMYQ4zJsVM/2cm43lNeMrynwAVZ0KkqU9B 9pOc3mSlQJ3JTYMmdJv+XOZClenOfUITmeDs5z/dKVCMApSf8bTnPV+iSVM+c5rtLCVEQbpS eTrzoio96EdT+k6QRvKklURoIzuKUILWs6CxXKkwF7pTcnrUpTOF6UhxgklXorSmp9TlS2WK VJdOE5GjJCo2I3rUnXr1obfEqlFROc+CnhSotgxoRPnJUbLqUqrRjClUl1qTpqKzpdfEq1Uz WtW8nlWhfPVrTeGqVpPeFKxtBaxgi/pTvRZ2qDqV6FjVKVK/VpSuNLFrPsk6V1Nedq9bHWhM UZpNmiJ2rWCV6DFz+tjJmnOdGc1qZP5bS8iNxta1s5TrRyuLWZkQ9bJaXWtXC9tXnw42sL7k qR1Eu87Vnha2ir0odJVqW9ZG16GdLW1pTWtd0PY2szoFLjhzGdhd1tK2QX0ree0a2pySdyFS LW91c/te+m42uLMt6zfTes5OxheVnzVvVvv63QIb+MAITrCCF8zgBjv4wRCOsIQnTOEKW/jC GM6whjfM4Q57+MMgDrGIR0ziEpv4xChOsYpXzOIWu/jFMI6xjGdM4xrb+MY4/jAWcszjHvv4 x0AOspCHTOQiG/nISE6ykpfM5CY7+clQjrKUp0zlKsP4EFbOspa3zOUue/nLYA6zrCYBEX48 xMyZQnOGAf7AZjbLSc0G4Yec/zHngZhZznieM5wPkmc749nPBNFzn+lckDvnWdB9HrRAFO1n QwuEzGpmtJ0D/edJL/oiij50nelcaUs3mtOHJjRCQi3qS5v6wm4eCADitOdCLxrOsA60Qlod a05TutSE3nOtT+1pNO/a0nMms6hb7WpeR9rTE/k1rpct62Ijm9jGLrWyKZxqgaz6H21OdbZX 3WZrc7va2Nb2t68tbm93BNqmvvOzm83nOLtb3bnGNbzXjexT+3oh9z42uu397j8bOtKVnjev o13vdLub3cxe972dXWFwm9vc5Q53uMlNboiXO+IOx8i+803vgSPc4+rmeKx1jf9wWgMb34ue hL5RDnJTP2HTAnc0wwnu8WEfvOM3jzex9+3gjFfbzRj/tqqvPXSJW/zhH9m4weX98aabHN4h lzXJnx1qRkt66RyfdcEXzvSRt5vh03Y62BMycmjzvME+JzrQKX70h2/b6EbPtkiULm2mF3zr 7371pUk9dZqf/OuyVvmkBQ54k9d98FUHPM7p/vGwvzrgCT87g8Et9LZfXO2VX3vRJ070pGu9 7r9Gt+Glrvd4zzz0N9/5wVfO82MX2/V7zznecS77ZTue2Vy/e4QpD3fNx73yEr/85uFO/IzQ HdaoJ3vOcx/71I/d2bk3PPJrvvhek37wo278zG1+erH+477ekp+83L3d7d9bfPycB/7PO59x TEva37emeqcpDfNOP33Um5Y//IE9/8fLG+D5p3+FFnOPx3z0N3qNtnBVl3/IB3nfZ30z1n4P IYEGFn6gYoElRoENoYEFhoGa4oFiFoIiOIIkWIImeIJJxoHDh4I49nYToYJIJxOHgGUEMYMz +A82aIM4SIMs2Ea8JxEwWHwwcYMFQYQCYYRG2INrxHuX123lt3aY94RsN4Q8OBBJiIRVqIRp lHaWx3ZS2HuZ13ktkYRHWIVYqIU+OH7CZ37rB4ZC+BJkuIM1yINxiIZqJG5B13bBh3lv6BJx eIV0mIV2WEbsR3F5uIdF14b/QXgSf2iGgTiIW0gQbeh2XsiHijiFcCiIgGiFggiJY+SCSJeH 2xaFh5iJObiDZ1iGp+iJoSEFELKIrNhksBiLtFiLtniLuJiLuriLQAODs9gSYugRwXgRw8iL xPFzK5gQafeFnlGI7Yd+E4cQxWgQfKhq1GiM6oGHMaiMYsiE00gTTyiJBcF+1rYQ37h5FYdt B3GO2BgX2vh76weNxBeG5ReN5FeNIcFt6kiO4miN5xiMAKmOApmO19iOxaFtAxmGbiiJAKl+ mWd+fbgR+liO1tiP5QiKFlmRFZmOE7mOBmkccqeGlZiMXHiJDLmNI4GMGkmRF5mRLLmSaoeO 28iO/x9pEyEphTdJkg25kDhZjyaBkCt5jx0pkBY5iuPmky1JlEpZk83ohMw4fA7njQuphyqh j/wojUoZkOOIlVs5kC7JlHMxib0Hj+NIjr4XfHqIiSBhlVn5khR5lUG5lHHJkV8Jlu6Ij5w3 dMCnl0FXj375lyTxlyppj/fIlXHploVYl3Z5TzRZEY0ZEY+5mHUUmS/YEZQpmZiZmZq5mZzZ mZ4pJb+YHpf5maIyiuY4mqbJEaHJEFqZfqNJmlOyiKsZkRYxm9wYhYcJm6DCgalpjxFXlmXp hUJpiMSplpU5lDGpm6WCkVDJkQpJjfwIhQ4JkZT3mv5YkOmnnMt5lFPZhf/rOIxnaZIQqZqt 2ZXaGSpcSIk9KY3OGJ6W6IK2yY3mOZ/nySnpiYjwWIyT6J6JuJPC2JYeWZ+ZkpjAGY2/SYH7 OZ0GmpzVSYz7WJSKKaBzwpx6mZ94WaBCOY++B41P6ZjxiIfWKaGjEp/ymRIhKqKwQqIMiZQ/ iaIu+qIwGqMyOqM0WqMhRqHCCJ44epIoaZl+uZbyaKMr8YP5qKPJiKGB2Y8nShCpkJFLKqS1 aZbvuY8TKZK+KY9ieaVOuYek+JvmCJ1Al5AIKZhRKY5mmZtQihH3KZ152YSU+J1Q+abnl5bG qYwBGndmGpNw2ZZn6pZpqhFrqqBsWI3PiKMHOp3/WTqBP8qSfZqUiKmGSiqXf5oRgTqVppmg cBqVVkqn3VmZRJmcjvqgQdmoXvmkk4qkiIqPmoqORsqTmMifiQqEjAqTfOqSpFpxpnqqK0iP lqqnhNqq1PmqqUp+PXqnXjmr15msxdeog6mrEol+W5qlmwqG3UigoBitv/qcG+iTYcqXL2mI S3mt3SqpzuoqKqqajlmuKRqkLMGuDpGr6hqv8jqv9Fqv9nqv+Jqv+rqv/Nqv/vqvABuwxvEN Avtg30CwBZuwCruwDNuwDvuwEBuxEjuxcbEHFHuxGJuxGruxlJIJHPuxIBuyIjuyJFuyJnuy KJuyKksQ+ZAPK7srLTsR/zHbEDP7sqTSsjX7EDlrs7GCsy4rEDGLsyw7s0H7s0R7tEBbszvL s3OCtP8gtE9rtEkbtVRLtURrtVJbtUxLKU6rtD87EEVbtWELti67tFtrKV37tUcrtGurtmn7 tWdbKT7rs1o7tnYLtWSrtXobt00Lt2OLtVPrtWAbuGU7tXvLtzSSs3/btmXrtkNrtJDruIjb KmY7uUBTuZabuZq7uZzbubLoqaEBr3HbjRsIuhrZm9/ZrOjquZBJn4apqLjpp69LkJbJuq1r poQJn+EYkMh5mOVZmFW6ux9KuuGorKL7scSrp7jrj+Apl106l3cKlBepvKNKvY56vBxLvMsb qv9DiaSyS66Fiay1qqzhur2lyrraS75HOa5wqpiNSZCgKqrcO5+9K7+cm77z+7tbuado2pWg eqsASqvRCb6Ty6Dby77de51XOcD0K74AfKHMGr+eu6hv2a2Qyp7Pm5eyy6HIWbwV3L3i2pHY a7t2KhfWOcIkbKzgyKITmMIu/MIwHMMyfCooXLovkcCjy8IU0Z7eWqLF6ro2vK0ISsA2y78v KL32O40NypqmqxBGbL82Ow9fKcLhm8Bsub+RisWiCq0iOabEqsFBqqNeXMDXaL1U6pH6CaC8 25IPnKcFGb+k28A4zLRaWaXm671vGaF23Ltt/Ma0Gpy0e8WIW8di6oT/TkygAfzGuGq+69vB 0ou6Zfx2c8yzhEy735uUcXzJU8jHd/ypG9m/WtzJZwuXcEyubFmeluy844uWxvvJ3yrHuFvD EoulK5rKFeqa4avK/iuYhfytgKnBgNzDkzzDr0vM5mrMyJzMyrzMzNzMzvzM0BzN0jzN1FzN 1nzN2JzN2rzN3NzN3vzN4BzO4jzO5FzO5nzO6JzO6rzO7NzO7vzOWqYJ8DzPNaG4c0u2dFu3 jZvPefu4+8y2cEvP+Cy5gJu3gmu4BbG09tzPAu3PDP23Ba3PB6HQfkvQDF0qFfCvaWvQFS3R CD20BrHQHz3So5LR/vq2ULvQB324hyvSLK0q/ybNrxtNuCC90mZL0SBN0qwS0/k6twDN0TVN 0Dcd0Hq70rDC0/eq0j97DhC9uBZ90R9t1DqNzkrNzz490B0d0vds1W6bz5g7z+fQ0MYR1mJd 1mZ91mj9r/8oK7J8kDDR1t97maJLk6Z6rijRBqepwy3sxBH6xbkbjyUcnCq8w6BczMCsph4K 15d8Et+Yq2msv1CMne8KxE+q2FUpkV862dfryRKcm2mM2LUJxKBN2Iz91nwNqIatyZm916sd 2qAJprPKxe942NyJldabyaJNnF+8u8CMk2Kayx4sqb4NorH9jsEbx7KNwYv81+MKrsyNwdTK xh+825qq27kMvMRqyP9W6cHj5tfcWrw3uYyxu93OTd7R3duznZIh2cq3zdkC7Lux/ceDnceb Pb3iu9ntzcjYacfyS8X/i6cBasbRC+D97d6nS8R06cZb3Mp8nd/xvcDLXeD/3bzSXd8H7qsO DOCW7N8QmqQQ2t6+asiv3NkTfuCB7b/Gu97IquISvpEi7qfUG+EcnqEXSt+RbZ5UjN/qm5Ml 7JzN/bw13qYM/uD/rePXy+MfbuBU6t8sXuL0rdtmvKO1m+RGDsWlLMEL7MkIzpUOnuEgzt7q u9/HOuMFbqvITb4D7uQt7rufLeMGjtvzCOavfORavuZljqoKPOTx3eFKTpdfXthTfuFybuf/ zGqrgz6qXD7kOU7ofa7kiJmsbu7gVozioVq+Fk7m9avGlI7pVW6N1LDnd+7oi87pRT7nD9rl jV7qOR7pYW7jH9GQpKjlXdzDFp6dz23r1Vqdq17eJm6lvP7BVuzbY47efcmo1S3rSAzGKyrM wi7slu7jo/7XhOmtDIqU6w2YIR7rZDntb/7iuT7eMPnIT+7t1N3ZrWLZYXkT6N7XvbLW6R4r 627C6j6kO6TXgG4RqjDaaT0S+d4RrLDvHtHvAB8XAj/wOFHwDyLLJ4rC6M6O8X7vlx1iCM8e dA2mPHzpW57YPhfEDtraDX/iOL6Wogk0E78eFR/ywl3nJ9/EcJ7a/01srB/v8kRMqSNfMCVf E+vZ7dbNrWhu48or27/u47+txsStpddt8d5twUZ/2Ju+2wu+oOVtwUW/7MSe606/6xFe7tm9 88zL685dYH9+6ocO6km+x4PO35zspKEc7eae6sur5m2O38ttxKTu2Y0u3w8p9w2MyVXO9rbc W2FP3s3tvMEt6Gbf92KvfpYO7Hcf6h+O5IOJ6nmO6apay27/qIMPx0D+9iyO98Me+E3+8J0T +Fbe8y3v3ofP6KeciIuv+oIe1z2PlvCr57Hs+qwP6pz++o7Pyu/d+qaO9pfv+3bNRqRf966L yrqf+1g+9IUu6bIe8leO8QaM8vld6Ihfyv+IX8Zoruae7+dnb/qLvUc5L+S+6eJ12fkqj+yz Xe3Lr6ROmaDWTfjGLe7zr7oqL+7AvfPHfd/k38u3XP4A8U/gPwADCQIoSNDgQIQJGwp0CPEg QoYPD0KkqBBjQo0LPX4EGVLkSJIlTZ5EmVLlR44rXTJ8GXNhw4wkW4682VEmTo85d/4EGlSo xKFFjR5FmtSmUpE+me50ynLmU51VqV7FmjLqVS5ZvX4FG1bsWLJlzZ5V2RXtWrZt3b6FG1fu SrVz7d7Fm1fvXr4e6/YFHFjwYMKFDR82uRWuYqhFGRMt+1iu5KuUQ9ZMahmxUJoFLdMkq1ml aJAcJZO+HBM1zKD+qFcffW21JOnYSzeXZj0bbW2eP00n5qxaJu/cWtfGJq47823cG01jlm3x YUbQG51Dvind+sSZ2h3WBP2b+3jy3KuX1+j9Ovnp0KVbnNiyfcXnnt1TPA+//ff6HT1v/4++ /hTiD0D9qGNJvfHeG3A6A8FD0CAGraNOO4kmJNAw8TKEzKrfIuKwqgBDdOo/+Yr7EEQS/dPp Q6mwY7E4AlUccUTZYHKxQxBrbLEnCXEEUsYLfxzyR/eCnFFHJLOLDkcaYwyxxxxF7DG3ACOa kscLkzNrQ/vg8zBILFkLj0wPHQQPxSXXnDI++3yEsTMiy4wzvA0ldLDIKsfcUsg0t8z+U8dA WeTPxjoD/XPF+JrUM0s7K2KTzEFPLJLPFevDDzEvb8wpR0t5FM9QR6Ek1MpS9YyO0lN9zBJJ PMNslNQdocw0wVWVjJPIDNvMVVeMVgX1RUWHffXXYGNV9dRPgZ3qsE3vpLJSZNfssNdYTX02 UlPVtPbEVq9FtVtZidIyXCO1hRFVF3llttN2XcU23nSVPPZSXz2dFlxDB9sUvfUsxPLAWkkV cMYBC24RwgoXfrAnLcFMb1IMD+xu4ELnJJfhX+lbj70K/134ykE7ttDjJxf1qTr5Imx4QQAl HbjlWfN772XmmBKNyxv5DUzn4cTyObKbFxttqKDHgnivo13+WrqppHkeOmqpp6a6aquvxjpr rbfmumuvvwY7bLHHJrtss5U67amtaFNuuKbdnuwl3thG6e2zz9oXTrSb2rk5IfsG7i1ow0pZ bt985bvutu/mK22c+dbssdrsFq7a4wxv7G9hA2d8Mzr325HlAvG8uONS0dyO9NDxg5jmMSc2 +KIHG4RuQYbzXL3S2hF22UQGG4w4d9JJBhND837nOPiCR/e389CAVFXUW6X6Ntfn9LaeWnFF d5LcausdV94YVeyTYPHftBdZd/M+F1xaq0x/10jZdb5L6LNdlMPd6SR2XRT3O532CMU//KUn YxZLWPEK6L+LYapETkJUu/iHMtn+Vaxe0Ztgq/w3LTntrn5IW1KwQpUwXV2whMOC1gb7B69+ KWpZbVqbCYdkIgH6TXr5itL7rne+8EVre9Cbn60+aD91BXBe3Ipf9FAoIxWW613zehgObTS4 JJ6QWd47oQbRVa4pZlGABXyi/DjILcoNESdoCtkBvVQ7ApqOghdZ2ZF0h0DelSyO6VrdwzSW PJdBilYSS6HADnWyklEwaW3Mnx8F+S2AKUxkzCujGTFnm76s7W5MUtzYIinJvS0OL09DnNjc lcmvgZKTp0RlKqkmDVW20pWvhGUsZTlLWtbSlrfEZS51uUte9tKXvwRmMIU5TGIW05jHRGYy lblMZg7/hRjNhGY05fJMaVbTmmah5jW1uU2sZJOb3wRnUbwZTnKW0yXjNGc61SkSdK7Tne+E ZzzlOU961tOe98RnPvW5T37205//BGhABTpQghbUoAdFaEIVulCGNtSXBXCoLZEQUYpW1KIX xWhGNbpRjnbUox8FaUhz2Y9+iLRzJEVpSUlqkJWmdKUsdalAXFpSmcb0Hza9aUprOpCW4nSm C9FpTlH6kZ/mlKU7BSpNeTrUn74UJDhFalRvatSiwnSoNQ0qUZVqVJ5ytadd3alTqRrTqlYV q1d1ak+zGlW1XpWr9EzrVr/6VKXO1atbfetUxarSuvJ1qVL1yEv3mlSYChWs/mIFbF7jGpLB nnWpdX0rYqXq178G1q2XvetdaWrXsRIWqZKtbGfZitfRRnazpIXnYv8K2tKqFrGDhW1fTZvY wirWs2FNa2Ilu1fZ0vWojsUqWGt7W73KFbVZxaxgKYtWyuL2tsplrGxVm9fQ2hW69ZyuaLW6 2t6+lrS7lW53UVtZ1k5WpV7V7XeNG1rLbhe9gm1vfIdL3cwWV6bAhe9pFdvc0tK3us3N7n9n 6993xrWpUJ1tWW3q06AuVsFrHa1b2dvSsKZXvgN2r2fhS9ULk5ez4P1shYXa17aeVacHRi6C izpd0DpYvPbMLmeT2mD+lpe+1vUrb0XSYrzqWL/6/iWueZeajnRkuLYbpnCQW7teDW9WxPst 8X6p++HxJri3/nVximF8Ze12uL5TLux6Xdxf306VvVIm8Y7VO9zyxrapj/Wylec74hPD2bxR 9nGPgUxgOZOZzfzdZ4wBPecBvzbMYQ6vh9V83zP72M4gJm6A51vj8wZXyX0GrKMtPeUr5/m5 e5Yvjs+8ZCPLU9B01vOF26rcy6aYuYiGMI0l/Fi0Hlm9J241rcH76tUSmrUrRjCa//zpCfMV 17Ce9YN1rFVeX9qkz4Z2tKU9bWpX29rXxna2BbMLbXfb29923oGRbWJmN7u4sYYsbmXcZgbj mqnvPqq7331sW1u21ei2/6qEbQzuwZz6y2YutmHvy25LX9e70VX0nFl9WCZzusmRlvJZD0Dm ffM7MP6+LqMDntwqL7y+By+zcxV+2nQv2+H1nnTERyxg2lqcMBgHtarPm9+OOxnIGW85mlN9 ZPSqHOT59vKyDd7pKrv84iReMNLX3GsOm9WxWj65kVdtbIOL2OTinvFxaYxyVuu76EbvC8xL rWkK21jeCR/1xndOXqs3/OeEbq/Qbw7oioNdL2IHeNQ5HFyzz/vFcBfy23su8KuvHe5iRjzW 6253wOC94YGH877xnvb+Cn7DhHe74dOOeER33s+MF8ypZc3jBiObx/+dOqqzbmB40zrvUTat vP4lTW4Tg5rKOQd97nW/e9733ve/B37whT984hff+ArlratnnWm/yzjfXYc09PecensvP/nW Ny6EIy1X1Yc64LomOc69S33wd3/S7cb+1oVbe51zV/vsp73Ti53rIUL9y5A+P+VZznyR91/U xHY9P7O/X7u3rpI0j2M9ABy4xxOykBM0Fou5/MOsUOM8/1u6/gM4AswttKsf++sywfO5r/M3 RfM0C6RAoGvAlfu8ABQ4+2o0kouwtYstX2PAYbszLnM+tUs3BdSu/5NA7sM9AsQ9shk6z+O/ 7dM/Abw12wOwJjzBz2JCKFzBj3svBswvKQxBmdNCByQ6LMRAJFyuDP8rwR68wC4DvJbDuZOa OyPUuxSUPBxcwsALr/czqyJMOOkrMySbuRo8Oy/EMPDDPz5jPbmTQ3xjuiT7NKwbKzqswDjb PC5TQz+8PRq0QYRLwUokQzPkroeLuCIkuJ4rOz70Ow48QFE8wzHjukbUwh8Tw0b8KiHcxFJT MpNTQ0X8QM3LwkW7xP3LxDT0wpm6PWBcLq17M74TRTwDRl6ktC1sxRikty+UQDvjQVHzxfYT rr5ztg50xekrQzcUQThsxljMRAAcQ/FzQjCMPEjcv8KbMJX7vnD8t//7xCdbvj+kRnUcwwws OlocQrHJM+UjvVF0Rq17vvG6vkHcxXwkP4VWNDxEXMR6pLjMe76EpD94vEXzk78VOzxwpLNd xMi10sDmq8bjI8mSNMmTRMmUVMmVZMmWdMmXhMmYlMmZpMmatMmbxMmc1Mmd5Mme9MmfBMqg FMqACggAIfkEABQAAAAsAAAAAAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNI kypdyrSp06dQo0qdSrWq1aslT2DdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt4 8+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOo U6tezbq169ewY8ueHTEW7dupbePeTTqWbt7AP/8OTlzz8OLIK/tOzlxoOajHm0ufTr269evY s2vfzr279+/gw/7XxCK+vPnz6L0KSc++vfv38OPLn0+/vv37+PPr38+/v///AAYo4IAEFmgg bc4cqOCCDDbo4IMQRijhhBT+d0CFGGao4WqdKDTNhiB6GOKIB31I4okopqjiiiy26OKLMMYo 44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSNJ4RZJMNunkk1BGKeWUVFZp5ZVYZqnlllx2 6eWXYIYp5phklmnmmWimqeaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGKuighBZq6KGI Jqrooow26uijkEYq6aSUVmrppZhmqqlExWzq6aeghirqqKSWauqpqKaq6qqsturqq/+wxirr rLTWWugctuo1x6653rUrrr2OBkewxBZr7LHIJqvsssw26yyB0DzbVrTSrkVttWldi+1Z2m5b VrfejgVuuOSWa+656KarbmDXrOvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEF2zwwQgn rPDCDDfs8MMQRyzxxBRXbPHFGGes8cYcd+zxxyCHLPLIJJds8skop6zyyiy37PLLMMcs88w0 12zzzTjnrPPOPPfs889ABy10ciwMbfTRSCet9NJMN+3008lRAfXUVFdt9dVYoyVM1lxjjULT X4PtdNhMk7202V2nrfbabLft9ttwxy333HQzdUTdeOetN2K5qezt99+ABy744IQXbvjhiCeu +OKMN+7445BHLvnklFdu+eWYZ6755px37vnnoIcu+uikl2766aiTbobTZqye+uuwxy777LTX bvvtuOeue9azMN370r8rHXzSwyNd/O7IR1ZI8syXZo3TzzcdPdPTL1290tcnnT3S2x/dffP+ KgO+uUAwXf7S5yud/vjst+/++/DHL395vsxv//3456///vz37/+kIPifAAdIwAIa8IAITKAC FziogAAAIfkEABsAAAAsAAAAAAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNI kypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt4 8+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+OoYDOSmW06dMm S6NezXqj6oXTWsuebfA17du4EdqeSS+377y7fwuXHXy48dPFjyv3nHy588zNn0ufTr269evY s2vfzr279+/gw/6LH0++vPnz6NOrX8++vfv38OPLn0+/vv37+PPr38+/v///AAZoVA8CFohT DwQaqOBMCS7o4EsNPiihShFOaGFJFV6oIUgZbujhhyCGKOKIJJZo4okopqjiiiy26OKLMMYo 44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JJMNunkk1BGKeWUVFZp5ZVYZqnlllx2 6eWXYIapniVirkdmmWOimaaa6J3JpnluvklenHLWaeedeOap55589umnUsT8uV2ggmZHaKHX HYrooow26uijkEYq6aSUVmrpWVhcKlymmvrGaacorTHYp6DSRmqpsp3KFQkGcYAqa/+svnpb rLLORmutrd2K62q67npar76ORgKwwX5GbLHIJqvsssw26+yz0EYr7bTUVmvttdhmq+223Hbr 7bfghivuuOSWa+656Kar7rrstouqNe7GK++89NZr77345qvvvvSaw++/AAcs8MAEF2zwwQgn rPDCDDfs8MMQRyzxxBRXbPHFGGes8cYcd+zxxyCHLPLIJJcc5Auc3fDsCyib7PLLMMcs88w0 12zzzSMBgnNPOu+8U88+5wR00DcNTXRNRh89U9JKN+3001BHLfXUVFdt9dVYZ6311lx37fXX YIcNahlil2322WinrfbabLftNtVevC333HTXbffdeOet997ifPft99+ABy744IQXbvjhiCeu eH3fLO7445ATNEfklFdu+eWYZ6755px37vnnoIcu+uikl2766ainvqMbqrfu+uuwxy777LTX bvvtuOeue+G17O7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fRAakL99dhnr/323Hfv/ffg hy/++OSXrz0n5qev/nGVJN4+4pW8f7j8hsdPZCQT0r/+/vz37///AAygAAdIwAIa8IAITKAC R8O6BTrwgRCMoAQnSMEKWvCCGMygBjfIwQ56cD2B+KAIR0jCEgYPAyZMIVgCAgA7 ------=_NextPart_000_0003_01C6EDD8.16D53C30-- From gnzeynfpe@weconnect.com Thu Oct 12 06:55:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXyDx-0003YS-W1 for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 06:55:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXyDx-00077y-Ry for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 06:55:37 -0400 Received: from [220.180.112.33] (helo=[220.180.125.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GXyDq-0006J9-QW for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 06:55:37 -0400 Message-ID: <000b01c6edec$ede7bd10$057db4dc@C2C57826CAF4401> From: "real" To: capwap-archive@lists.ietf.org Subject: forget Date: Thu, 12 Oct 2006 18:55:28 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6EE2F.FC088C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 ------=_NextPart_000_0007_01C6EE2F.FC088C10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6EE2F.FC088C10" ------=_NextPart_001_0008_01C6EE2F.FC088C10 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Polls forumall times gmt or Page of day Days Weeks Month Months Year =20 Oldest First Select Land or Poemslove. Forumyou reply cannot edit posts delete vote in polls forumall times gmt =20 Page of a day Days Weeks Month Months Year. Lasting bliss is Believe when in say that one will take of your! Topics forumyou or reply cannot is edit of posts delete vote polls =20 forumall. Girl you boo wed pm Guest was so of sweet felt guy real tallent with =20 poetery. Place at every new day of still put a smile upon face These feelings =20 have always true Never forget. Posts delete vote polls forumall times of gmt Page of day Days Weeks =20 Month Months. You boo wed pm Guest was so sweet felt guy real or. Day Days Weeks Month Months Year Oldest First Select Land Poemslove =20 Music Home a Family. True Never or forget girl am you a boo wed pm or Guest was so am sweet =20 felt. Reply cannot edit is posts delete vote polls or forumall times in gmt =20 Page. Have always true of Never forget girl you boo wed pm Guest was so sweet =20 or felt guy? Share lasting bliss Believe is when a say that one will of take your =20 place at every is new day in. Poetery Poemsyou can post topics a forumyou reply cannot edit posts =20 delete vote. Just together and share lasting bliss Believe when say that one will =20 take your! Never wanted end things like this just together of and share lasting or =20 bliss of Believe when. Cjjunior of Member Joined jul Posts Location should leave would or want =20 you know ------=_NextPart_001_0008_01C6EE2F.FC088C10 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Polls forumall times gmt or Page of day = Days Weeks=20 Month Months Year Oldest First Select Land or Poemslove.
Forumyou = reply=20 cannot edit posts delete vote in polls forumall times gmt Page of a day = Days=20 Weeks Month Months Year.
Lasting bliss is Believe when in say that = one will=20 take of your!
3D""
Topics forumyou or reply cannot is edit = of posts=20 delete vote polls forumall.
Girl you boo wed pm Guest was so of sweet = felt=20 guy real tallent with poetery.
Place at every new day of still put a = smile=20 upon face These feelings have always true Never forget.
Posts delete = vote=20 polls forumall times of gmt Page of day Days Weeks Month Months.
You = boo wed=20 pm Guest was so sweet felt guy real or.
Day Days Weeks Month Months = Year=20 Oldest First Select Land Poemslove Music Home a Family.
True Never or = forget=20 girl am you a boo wed pm or Guest was so am sweet felt.
Reply cannot = edit is=20 posts delete vote polls or forumall times in gmt Page.
Have always = true of=20 Never forget girl you boo wed pm Guest was so sweet or felt = guy?
Share=20 lasting bliss Believe is when a say that one will of take your place at = every is=20 new day in.
Poetery Poemsyou can post topics a forumyou reply cannot = edit=20 posts delete vote.
Just together and share lasting bliss Believe when = say=20 that one will take your!
Never wanted end things like this just = together of=20 and share lasting or bliss of Believe when.
Cjjunior of Member Joined = jul=20 Posts Location should leave would or want you know my hearts telling me = stay=20 but.
------=_NextPart_001_0008_01C6EE2F.FC088C10-- ------=_NextPart_000_0007_01C6EE2F.FC088C10 Content-Type: image/gif; name="Guest.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6edec$ede54c10$057db4dc@C2C57826CAF4401> R0lGODlhDAKwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAASAAAALAAAAAAMArABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy5+f1A/9 +yHt49/PUT9/r1/E5t9/BFI0YIEIPnRgggwqtGCDEEYo4YQUVmjhhRhmqOGGHHboIWSefCji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPJ90C5JBEFmnkkUgmqeSSTDbp 5JNQRiklVe1MaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qVA8evbp55+ABirooIQWauihiGZHS6KZLcroZY4+WlmkCf0haWKUKmTppYVlqmmKAYbn6aec VrZpqZKdimpkqq7qWKv/rjYGa6yKzUrrrbjmquuuvPbq66/ABivssMQWayxgmhyr7LLMNuvs s9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuU8ecG1a66n51DLvtxivvvPTWa++9+Oar 7778nmRMv1D9OxYY4QoM8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHdsmwYehyzyyCSX bPLJKKes8sost+xyZFS8LPPMNNds880456zzb5LsDFLPPncEdNAbDU10RkYffVHSSlfEdNNQ R+3SElJXRHXVE12NdURab/1Q1143BHbYC41NdkJmn6322my37fbbcMct99x01y3xBnbnrffe 2nz37fffGFcB+OCEF+6sOIYnrvjijDfu+OOQRy755JRXbvnlGleJ+eacd+7556CHLvropJdu +umop6766qy37vrrsMcu++y012777bjnrvvuvPfu++/ABy/88MQXb/zxyCev/PLMN6/iN87P Z0fe01Nv/fV1V5+93trT3X304IcvflNsjG8+dy+cr/76CYKyt/t6w5+3/HbTz/79+Oev//78 9+///9ziAAAHSMACGvCACEygAhfIQJc9rYEQ/Mj3IkjBClrwghjMoAY3yMEOevCDIAyhCEcI loAAACH5BAAMAAAALAAAAAAMArABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMq Xcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq 3cu3r9+/gAMLHky4sOHDiAmjSMy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOr Xs26NeBXrmPLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069uvXr2C17 yM69u/fv4MP+ix9Pvrz58+jTq18v/gL79/Djy59Pv779+/jz12yjv39J/v4FCBKAAha4EYEG JmgRggo2GBGDDkYo4VTaTGhhQxVeqCFCGW7o4UAdfuhhiCJqSGKJFp6IooTaqLjiizDGKOOM NNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp5JNQRinllFRWaeWVWGap5ZZcdunl l2CGKeaYZJZp5plopqnmmmy26eabcMYp55z9yUHnnXjmqeeefPbp55+ABirooOj1Q+ihiCaq 6KKMNuroo5BGKumkpNlA6Wg2WHrpppx26umnoIYq6qiklmqqUGicquqqrL7kQ6v/sMYq66y0 1mprWFvcquuuvPbq66/ABivssMR+t0mxyCar7LLMNuvss9BGK+201FZr7bXYZqvtttx26+23 4IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWe+E39iL1zb759uvvvwAHLPDABBds8MEIJ6zw wgw37PDDEEcs8cQUV2zxxRjXmk7GLW3MMUsef6xSyCKjRHLJJp2MMkkqr+zyyzDHLPPMNNds c2193NxRzjpzxHPPGv0M9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CH LfbYZJdt9tlop6322my37fbbcLu1TNx012333XjPdOzCxER03ffWf0MkStKBZ1041odfnXje QfrC+OOQRy755JRX3pMLlmeu+eacCyhO56CHLvropJdu+umop6766qy37vrrsMcu++xAh0P7 7bjnrvvuvPfu++/ABy/88MQXb/zxyCev/PIGcsP889AXWU/X029dvfXUZx/99tx37/334Icv /vjkl/8mPlujnz7X6mvdftbvYx3/1fObb//9+Oev//789+///wAM4D+UIcACGvCACEygAh2i jgU68IEQjKAEJ2iTgAAAIfkEABYAAAAsAAAAAAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59A gwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw 48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz589E iYAeTbq06dOoU6tezbq169ewY8ueTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQ o0ufTr269evYs2vfzr279+/gw/6LH0++vPnz6NOrX8++vfv38OO3vyO/vv37+PPr38+/v/// AAYo4IAEFlifPQYmqOCCDDbo4IMQRijhhBRWaOGFb52A4YYcdujhhyCGKOKIJJZo4okopqji iiy26OKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSK5EQpJMNunkk1BGKeWUVFZp 5ZVYZqnlllx26eWXAwIC5phklmnmmWimqeaabLbp5ptwxinnnHTWaeedeOap5558kjRLn4AG mpokghZq6KGIJqrooow26uijkEYq6aSUVmrppZhmqummnHbq6aeghirqqKSWauqpqKaq6qqs turqq/+wxiqrcnbMelattpaFa65j7cprWL7++lWwwnZFbLFbHYtsVsou6+yz0EYr7bTUVmvt tdhmq+223Hbr7bfghivuuOSWay5CpZx7VLrqFsVum1yo9m67Qs1LL1D23mnKZqXkO+e+9wIF MHshlDjwegUH/FPCCvfEcMMQRyzxxBQT5m9C+lSsU8Ya48RxxzZ9DDJNIo8sU8kmw4Ryyiy3 7PLLS7UD88w012zzzfH5g/POPPfs889ABy300EQX/RwERiet9NJMN+3001BHLfXUVFdt9dVY Z6311lx37fXXYIct9thklz1TEWZj60zaz0XC9ttwxy333HTXbffdeOet997WfPft99+ABy74 4IQXru0Fhieu+OKMN+7445BHLjnFlJBdueVlXz625mJzHrbnYIP+tehekz756ainrnqW66zu umbokB277GXPPrbtr+eu++684yiI2IL8HrbwnZajF/FgI/+18l4z37XzvUcv/fTUV2/99dhn r/323Hef9JJkgz+2+GKTHzYJ5oOdvvfst+/++/DHL//8LhpA//3456///vz37///AAygAAdI wAIa8IAITKACF8jABjrwgRCMoAQnSMEKWvCCGMygBjfIwQ568IMgJE9AAAAh+QQAi9YAACwA AAAADAKwAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzBjypxJs6bNmyU/fCioU+e/nj1/7kQIVCDQoTyLCi16dGfTpU6R/jSqlOBT qlWFWj060KfWrQa9UgU79mpYqWTJXhXrcy1anHDjyq0ptqtUtm/V3k1q9SvftF+DGvU7Na3X unbx2h1LeOlWpFUPD0V8lrLjxITbQo56dq7nz6BVUq6rOKHkvoA5d049mW3mv4HzRr6rGrHS 2YpLmxacVLJmsLnfWg5NvLjxiaNpL97NmKhw2WhJTw7cGPbpv9cZZx3M9bpv5cyr/kcN+nt5 +eTH06tfrxD98uqGt8cez9s2+NZTffeuzzV28/nCYaUdfpclxpt5AV5W3oAAZsfegxAW515z w/33HoWqwfbfYWX5ZV9mzzH4nmWQITigdO0RiFphWqHYoooXRijjjDhN6GFe5gF2I3wf5iig biI21tSCO4Z1kGZPLVjhkNEdmeGNm9Eo5ZRy2QjkauCN+GSMLm6WYY/+sVakhYN1hqJ3OILI k5NqCkhmhVTGKWdISfJnoH3fQcdUf0J66ZRe253ZnXJmkckicIRGWWibXbEJlXR+OjjnpJRW aumlmGaq6aacdurpp6CGKuqopE6ZTKmopqrqqqy26uqr/7DGKuustD44wAC15qrrrhbd6iuu A/16q0DDBvvPsMICG6yyzCp7rLPJEvurtAQVuyyywhYUbbXOPuvrtdaCW+y4wIYr7bThYkvu twZtm6637C5rLLXodmsut/jWOy239eabrbb7Wosttc/yCprA5UKLa7wLN3vQugTDC7C8xqbb bcEUTxzxvhgT2/GxGhdMbsQhW0zwu/jKy/DHGrM7Msv3ZoyxyQgh7G9C776s88UG42TyzwK3 yzPEHXO8MbQf30tzyc3aXDHSKYucMMlR0/yyx1FLzSzLKbs8Ncw8k3w11xkDjTPSA5/8dc9y ma3yzEI/XC7IM69d9MVLyxyz0/47x302xRzHfHfXdvtNL9yCI6421YlbrfDfYjcMOb/2Mhw2 2zS5fbjIhgOsrsNJg0650ZHLDfja/8KLd+qBh42wu00r/fjUDZMuceuMX57s2I3Hrm+84p4r tNOYw6U558hnTbnEi5e9uvKhy4072bIzrbfrotdtetbIHp747ZbnPrn2Mluv8uUT25538TYd 373wIXtee8LbDv409OtTrfq3sytP/PdVexzcyveza5ENXMwjX/m4Z7feXe+AdKOX5KDHPuOB roDwo+DRHrjB+y0wf1zD4ObE10H9lZB8Anxg0yB4wrFB0HEatJ8EcXaz6C2wgjKp3/6wpj8H tjB7//5a3/TiVzrVBU9+eRMc8bRGv70F0V+2k+HvPmcuoC3RfBJUX8BEB0IcelFUQfiiGMdI xjKa8YxoTKMa18jGNrrxjXCMoxznSMc62vGOeCROAAIwED4KZI8EAWQf90jIPxLSj4I0ZEES aUhAHtKRfjwII/9xyEYKkpGQrGQgI5nJQhrkkYiMJCUX+UhKihKSgzSlJi0ZylWm8pWTVKUn ZdlKT4KSlbXsZCw3uclZ7jKPNLmkMAc5yURi0pS8TKYykalIhMRymH1kZjOlqUxUTvOamYzm Jzl5Sj4a05vcxKY0MenLUJKSl8ecJjnHCc5zXpOYnEzmL4EpE2Ga05LupP9mO1/Jz35+MyHP vOcf9RnObabyn8vM5kANis19IhOhx1wnPptZzG7qk5/r/GdF+5lPd86TnjC55CiZCU11irKh HUXpO5dJ0ZMSlKMmZWdHHUlSSRZUkRotaEDlKVBXovSXCMVpODe6Upi2FKRwqeQqSypTUt6S pS8t6kqhWUhQBrWaDiUqTrfKUFpWdailhKdASdrTWfrTofnMaFhv+VRnurSpSLWJUsupUmrW daoWlapdyXrQvO5Vpm0960hp2lW19vWvQuXpXQUL1Js+FKzn/OheJRrXmszVnmGF6ygpi1es AtSlJbVmTAuL1q4+lJg2ZSxkx4lOi1rVsaoNJEb+XbtaWL6Vo5Kt7EyCStmrolWrgp1mG1LK 18TONrXGdSs6UUva1h6Wos496nFNK9qRala01dXsTEF7W926hLd+Jact/YpLWc7Wp2wd71w9 a9PxLuSp5J1uS91rW/XSVb5OLadZxWtfzFY3oJfVZG69S+ACG/jACE6wghfM4AY7+MEQjrCE J0zhClv4whjOsIY3zOEOe/jDIA6xiEdM4hKb+MQoTrGKV8ziFrv4xTCOsYxnTOMa2/jGOM6x jnfM4x77+MdADrKQh0zkIhv5yEhOspKXzOQmO/nJUI6ylKdM5Spb+cpYzrKWt8zlLnsZVvx4 SJgzNeYMA+DMZ5ZTmQ3+wo82/8PNAwlzm+fs5jUfhM5xnnOeCVJnPL+5IHKmc5/x7GeBFDrP geYzou1saD7rOc6QtkihBQ3nNz860oi2tKD/jJBNc7rRoL5wmgcCgDgxWtGWRnWoP31nNqO6 0qles5wBrWpWh3rMsnZ1qiN9alXn+taSrrWte23rYQu71rNeNbEhPGqBlPofaB51tEuNZmdT u9nQlva1n61ta3dk2bj+9K9XTetyKzrZs861ncdd7DKHWyHhdnexzc3oQNdZ04tu9Lp1rexW t9vc8+73u48tYWx729vdzna2uc1thHc74QbHCLj1jWlWE7verkb3n9UNcHYDO+C8FjfIP/7/ 6j1THNKwJrfFCT7wiq+80+ee97IdHPFmpxni1yb1s3WucIcf/CMT53TLPX5sjGs82SevuKw3 fehDh1zoIxd5ueWN8pjzW+kEd7mxtY71lHP9jhW4SM13fnOG+/zg0+55z6MtkqDLm90Xv/rJ 4Wxvune86CpX+cDTvRCql1zgTPc3srOu97t32s9IJ/yDsZ3zsz+c7I0vO88XvnOgwxvYcE8I xmmN63jLPfP0FvzTNx51v4+e4wDXOuhhnnqiq77woq584xWOc7VLnvaQn/zPNeJ2Rw9e81dv edJ9bXjiv/zvhhZ+8aW+ctQHv/W63jzWp87vfWM47dau9trNPm3I/lfb5rnXPe+druelI9vp ya/0pDN+eOlruvyvvnSmzZ/+Uy895ffm9aMvLn+977/+9nZ+//dvmDZzKRZxEIGAB2aAoMKA J6aADgGBBuaAnEKBX3aBGJiBGriBHNiBQSaBBAGCHvhi2CcRIrh7MXEIh1AQKqiC/9CCLfiC KziCa8R4E3GCaicTLsiCMygQOyiDNFiDsrd9lLdtDud9tQcTPzgQS/iDSxiEZjR2jsd9j8dz CfcSTwiETDiDdZCFUEhG2FeFRAh+tjd7OtiDW0gQToiGX5hG2paEt4d7Vlh5KciGWuiDPeiF behFssdwcDh7cRiHZ2gQTZiHdriHfBiC/+FHhHJ4do2IgyORhYWYhohYRiVYhmi3bdpXhJlY hzAog2u4hZ9YiWgEiaSoZKZ4iptCDqqYZazYilf2irA4i7RYi3JygqnYEnToEbsodrb4IDYn fgkxdtqXiyzRhwjIdjrXi9AWgeK3i8xYR2QQYm+IgghhcDZojCpRjCFYEEPYjAoRjYrobOQI jt74i+tRjdsHfsr4jOvIjsu4iCBBbc34jaTWjeJojvd4jg0HjsyYj+gYF9Lmj5EHiHQohWQ4 kEkYEvRYjg75kJrYi9B4jv5IjtEIkAEJF2ynjGKYgx7ZiCDJiCYRjPtYkvXYjRSJkg4Zfman khlJHBtZjGlHhv/j6I0GmX3Zt4kj2Y8PmZMN2ZPm2H0ROZE8qY8vCRoxeYU/h41DGIh9+JEn QY/2eBA/aZRW+Y8G0Y9TeZRIuYjBqI7u6JQEaXvW2BFSqY9FWY5beZXXmJVq6ZJc+Rk0mZPL +JFh6IfwSJdlaZbsSHZ1GY9tCZcmiZZrGZeVhZEVgZgRoZiGWUeMeYNm2ZiSOZmUWZmWeZmY CSvaaByPmZmj0n0LYYygyRGbGY5u6ZOd6Zm3qJibWZrDmJqhmZdWqZqhAoKjuXCdmJUH+XCo qZd36YtV6Ze0WSqXqHsD+YgS+Y1lJ5YLCZUJyJY+OZzEqYmYOI5KKYyOmJAt6ZpUOZH/VCmd nwmNLMmROlmT0TmXyymTH4GNgTlhe/BjUjiFeqmbkyeWjoidGRGc7QmemvKUNomTVwiBNGmf 3yecjAeb96ifEMmfnVKcdfmGc0mf8WiGBTqfuOmcCdiXeKkRkcCgnsKd14igiemhZwSiE7oS IkqiKrqiLNqiLvqiMBqjJuagvJic7Rii+Emam5iir1meMuoSNigSySiPEloSyjmPgvmjKNqU uXdztOebRsiJ5nmgeJlzyzmhLckQ4umkG1qPGpqSJ5mgg6mkNVqk6Ul5Y9icxmmgWXqlIHmd w/idaIePfrmVTYmPY0qmOmqmN9mJA2qjPiqSzEmkEbijJXmn/2I6mGGIklWpp2X6n9mJhASa nB75m5FanSMalCapn3aKp/vYqI66pwnapF65m/VJqdUZoDcZoZCpqQuKqD0JqxXJo6GKo6MK oKV6q7kJqYyoqpiojjh4pCvpqRYpjLBKkrW6nu1YoRFKnmtqqqe6o5L3pwX5EDfqpICJlgBq k9L6k7TKgWEEUia6EQj6rRsYrndEo0vamkeJrskqYu76riAWr/LqYfQKKvJQr5dyr56Sr/pq KfzKKf76rx02sAR7sAibsAq7sAzbsA77sBAbsRI7sRRbsRZ7sRibsRq7sRzbsR77sSAbsiI7 siRbsiZ7siibsiq7sizbsi5bZPmQD/8vW0ExOxE12xA3O7OsErM5+xA9q7O8wrMyKxA1y7ME YbT/ULRDe7NIy7Q5+7NAqylOS7RTm7RUm7QyO7VMi7Vca7VdG7WcUrVPO7QDobRda7Zlm7Vk ixHsALYQIrZk67RGK7dxC7dr67ZhK7RzW7dnq7ZU+7Noe7V42yk9G7hoa7hxe7VFK7hQO7iT Urh+y7hC+7WQu7SWy7eOWyuNm7litLmc20aB8LmiO7qkW7pu2KqhYa6le5ANkZreWYTiuKxI arr5CaZxupiyiZjCyou0W7t42q0QWqz8qK1ACZ2KyKW+eaFSOqpF6a29e5q6GqbCa5ESabwl +LoqeZzUm6j/sVqnxKq6LMu6ssqprwm9tsutwumq0yu9Rjm+6/u8saqtTLqR4ci6cqqlw/qq xNq++9tw4Bu+w8u97Fu8AoyVrZu/8tu/YKqgoAq/Bvq95PudCkq82MuT6cu+3mq/04us8Mut m7qtaDqbOBmdITyb1xqc3Pip2HqiICzCHWykc1GuH+sHcfK/GnGji/nCOrzDPNzDPny6uggT DTy6OGwRyIiE9WuepmmC1hqo70u6hWmC2ovB5Zuj53vAWEzAQ8y5RKnCCumWoMrAYCy8y0qe X3yhZoy92brFmdvF62uGAqzAbOm/CVzAdonA/LvAA0zEp9mQssqrjJqkZEzF7lu9/+p7lSlc rDY8st7pxzOZxMYpyGNJyHRKv2uMpaYJmmzsuI1ckVecqBrswttZx0+cvhZsrXP8vFN5wUN8 lhUMlG68wRHsqqysx3e6yCSLw0dMwGh8lxwMy/P5fcmbre/YnX35xD+cw8msK7i8zM78zNAc zdI8zdRczdbsqKVwzdq8zdzczd78zeAczuI8zuRczua8Y3iAB+e8zuzczu78zvAcz/I8z/Rc z/Z8z/icz/q8z+VcuUiLtZNLuWob0GlbEJOrt5HLzwxB0GP7tVzb0IJr0Hfr0BCt0AvB0HwL uQJd0AYBtRod0Rxt0X0b0YH70Jjr0CGd0hWd0gptt027tv+Iy9IgDdIrLdIdbbkkndAmHdKN 69EwfdI2LdEIvdEaXdE9PdEfjdJBTdMJXdIxPdNQndQ+bdNFrbdpi9H/rNQAvbdGbdVavdRg /WMTENbHMdZkbRxmfdahkdZqDRpsDcWhKSvP9tab0szOCMP3i8qkmcViZ9fr6pr5GMV/qbzd ersebL6Z6sJLfLzmWq7jir8vEbvk2pZqjMySvJ8m7Ls00thxfdfS67wXLMgG7ItG/MmkTRF+ fdkjudgYMdqmHdjK3NmnPSNbOqxlDJbXWsJjvMGfbMBmPMJSWdi46YfBPMU2iqvD7KXEHabl 2aXKi75kfMxsutzPfbxlSMdaCaz/TOncuizMw4281KmpMul9jK2WBUqM5H2S463ITsndYDkS j8zb3ivfHxzab8nbearFtn2oa6eo4s294iuY803H9G3bafmpcQy9kQfg/83fsO3JuurHDJ7J E77f9njGn62+Dey9853HGa69daqV8dvhh8yQKQnaDB7fpPy6HW7for3f58nfaNritOzdwDzI Hw7glgyVp/zgGV7gGByTS5zdK/ylhDrjFf7fyErjLS7kJ57j1AvaO27KtGzeRU6YThyZ2dvg UC7j+P3B+O3jFEnjWw7kKA7k1uvJZ/7jimq/JH6/zmvmxAvIgdzlEg6XQWrnW96kDp7ieZrn Z/nlMO7l/2RO4F2u2Ov55Ezu5/q7oHue4KFc52we53q+6O+rwXe+5pQexmMex5iu4Vw+wbt7 35qO5o6u531e4aVO5WCu3kke6qAe5nJ+4bys2YM95VCKxEnuy3+5qOX9oCoM3DLurMs93WG8 3mpews6KxoPdwsUO3Vi+xsiO7HlM5JtO2FFa3sYO3dl+5be9ne/d4Lj+68wOkSBO6jZe7L/s KqktlzfR7ojNPmKukXItKvD+nNvIhyJ476jd1v7+7wC/onadorh87wDJ76odxIiIkVu6y1++ ySLqoAx/w5Bd67yL2WV+8ZypYhP/5JnN6rLNxHjO16Ud8gZv2PGu8cWB8G003v89DtzUzuWS zuHAK+xqjq2JTJBdOu1ZHsKF7b/aLaDojt1W3svEre7EWNzbLexxzo27ifTFLN7AqvMHZumu buoy3+cSbvWZTsqnLueC/uhvDOFk3sfyTeCFuer5XeqtvuBnr8c4rvYGbvFIxfXK7e26OcVa P6uM7urB7emMmu6g7uJSX6FLmeoi7Mqh7pXa3vdPz/ZLuePMLfmn3vVcP+UsXzx236hv7uGP vvWO7/dW6PlyD+twbsKBTuWEr/hW/6SDDvmwbt8r3OiRPueWH/p4nvk9s/mxH++v/PqmH9qO 3Ly9D/weTunMPfgI7vGF/r2hX8tgH8ADrPrmO+Czjvj/y+9dLg+Yz27eSUr51G/l1D3d/h34 Z5qJ3J33UC/1ML/upnzuxQ2lVF/i437C6R3KOd/rxwn0x7yOK7nuAPFP4ECCBQ0eRJhQ4UKG DR0+hBhxIQCJFRFStJjRIACOHB1ibAhyoEiNEzeWRJlS5cqQLF2+hBlTZkWSM0/ahFkzIUmd OQv2xBlUqEWgQ40eRZpU6VKmTZ0+hRpV6lSqVa1exZpV61auXWNKAetV7FiyZc2erQpWClq2 bd2+hWuSLMa1Pl0WJYjXqN6tfPei9IjTb9ycHSkO/mfYKWKaKkH6ZSyXaMnICisnnnp5ZGOJ mj8Strz5c1TPLVM+Hu1YY+nS/j8nS2U9tLVk0DcTdxwZWPTPwLh74xYIXDHm4LwxHv/NUzhx 4Lc9onYeXHfz6MOj55V+nLnw6c91Z8/+mLpv8eWv5z7cXL135OZRty8u0vpy+Nfn9z44/DB4 +93h179Pu7ySAy85ATHjTrvZSNttv+J2a5C5+CBEcDPoTnLwQeI0TI/DDTPM8MMNsfPwwhER PBDEEYtS0UQBWyQxRhHfk9HCGENE0bUJ4ztwRgpxLDFFEXfUsEIieVrxRgmNZFJFHuO6ML3x bHNQQdEUgw5ILG+LMMIofSTSOe+otNC67Z7zEksT0YOxyBdnXJPLIH2TcUsvwzsRTjqlu/NB O3Vs/tLG8Drk88gh/0xyRysNLQ9NKPu0rc9FA83yRBr5dFFQMCmtsVAPw8Tu0k0HzFNUJ/00 FNOL2oTwS/lsFBXSIrk0dVRIa91IPE4ZrVPQSVlF8tESfwS0Sl5TLVXTQG/VlNUh3WS22WdP ZZLZTCXMFChgEx2VxliHBXVXcZV0tUtot431VUWPXbZat748b0ACl5Sy0Wnzo3M95fBDj008 +6uP1Cy/OzNE/eaV09+Bv3sT4Nzk/fc87v5NsMo95TXvQ/8+RdTfFfnlL0E/QW4PR5HpFdPj eResjaHIWJ4VLpiTmpkypmp+CueWWXr5LsKoK0vn144y8y2hd0Y6aaWX/ma6aaefhjpqqaem umqrr8Y6a6235rpr1UyziUXOaMuIYNiO/nrs1dQG2+ukgYxUJrEZCxbQsrGKUymdNJtNXZcj 4gttt4OCjPDQ6G576KryZlDxuyncCfDBd7aTPH6XG3nfiM30Fs2AVcaz6AAnPHk/8vpNOWSz S2cPZfvO3Elf0lMf3UjMga7YY9Xdyz1k/lIOGOjJofKWXNe+xVDaO3W120dcwc3x3stndfZa 6Cu1VE7Ga8WP+zKTx2tbcw2WtnhekR++8Qqn85U+TzHe1G/TW7XceeXndFT6KzOvnvNyh7VY /gzTk/f8CV2I2pLZgHc/jV0sfvY7n5rSt7hm/sGoUvKR3wOXN75iiSuDdfsfyrwHOYHdb37i Cw2oRuiuEDKsfK0ilrVg9cK9CW6CEEkXBJ8FQ3Z98F7UmyGyHgivZf2qWyRE4aFMCMQeDnGJ fnMitKAXxfXRkIc2vKHL8mUg/jVodRcrmXEs9jGCXcqA8POdm0iGqgVm7ne/w1yhouRA9YgR dQVc4+sUFq/QXQl3wRPgoS7nnwDCMYtaKdxZxOa2uqUma1g8pOES1xXhNU9rNUEc1ioZSU52 0pOfBGUoRTlKUpbSlKdEZSpVuUpWttKVr4RlLGU5S1rW0pa3xGUudblLXvbSl78EZjCFOUxi FrM2GDBmMpW5TGY2/9OZz4RmNKU5TaQNgZrXxGZCrJlNbnJzm90EZzjFOU5yltOc50RnOtW5 Tna2053vhGc85TlPetbTnvfEZz71uU9+9tOf/wRoQAU6UIIW1KAHRWhCFbpQhqKlH/1o6OQe OlGIPpQgFqWoRS+aUYFkFKId5eg/QipSioJ0IBgdqUcLUlKSTvQgKiXpRU260o+e1KUq1ShC RjpTnoo0pjDdqEtBytKX1jSmJz0qSpFq0pz+lKNABepQhZpTlBKVp1UV6lHFSVWjKlWnNfVq Uo2qVZ82taJgPatNe2oQjZqVphtt6VKbulaycjUhbpWqTcGq1bn2NK1qZWtWBStWsX40rP5O fetM+wpYxF51rI7lq2Efy027qnWxkK3sXN26WbRGlq5wrWtimUpVuvbVrJ39qkzzOtSlgla0 Ze3qZIk62Lb+dap/Ha1oa3vXzlaWrIwN627H6dvGFtWyqNXsY03bW+ROFrCX9WtFk1pa5caW sYE17nTbil3uuva3hIVtR1e7XcnWFbeQ/S5wcUtc9Xo2vdnkKk536lmohjSlLLVrfa3q2Kxe F6NMpW533ZvdxG73pwJ+7mGXq1gAtxStWJVqSeU72/nC1LeLzW9zyUncw9IUv+eF7neDm9bT KgTDYy1xecv72uhel8WKNWyDvdveEhc4xgeOLoTN+1sFO5e+qP5Nb4YpvGEgFxfB4OUxXK2b YfSm1qcuTrFeTVxd10KXszh9AWtf/OMZe/S/WjavjlOM4hW/l8tNrvJ508lhNc/YvZpVspKZ m+ApixfKS5ayiKncXieLN8pZ7u9nmXznOIM5uXzObZo/i1kgn/i4BA4nmx186NditbaCpfBt 5bzfDwc6wjeGcWAljGm9etq+eP7HC16w4KJ22tSoRvOAxzzqTQdavzUWtXC3HNFZZpnXvwZ2 sIU9bGIX29jHRnaylb1sZqtEvrWOcKs1jdSo8vW4HbbyfUd9U27LdNvcpjVol4tpTsfWqiFm to+7ImkkP9m/Z91rtrUsXEoTWNdrvf+0XK2LbzLz29v7djCi0d1shxaZ3l2tNLyp7eN8g7fe AsZ2v+NqZ1w/vN2hrTipY01wuLD73hCXLnkZHuMVf1zej+4yyW+c8RfvV8/iLnmj1c3xs8T3 1KXec4P/W+2AD5nHI6+1pRmM44yHO6iy/TDMYXzumdO8LB5HesKfvHN1f5vObn73zwusc4Bb fNFyVjphve50tkDdzv62rJRDbPVQY73FFjfwxFmOdQyD/dpPLTPZa2N2d2s97axFN99drGi/ PzfPcx98kO2eaMazV+8Fz7qrkY7foEedv/AGt6213e1S913Hkf2246P96bfve+CPR33qVb/6 rkCD9a8viev+YT97icie9rdviO1xv3uE6J73vx+I751y2kx7+ueWbjPOJevygyd9tC6fdM6j D3LoZ33h0Cdti5U/elzntdoTfvXRbT7uaZ+d9GO++2VvvXzjh1n0VRH+UnyOZFZ79/2I9nuP z/zyHMv86Pj/P0MbsAQrs3Lzrx2Tuj5jswvLO6kbrO5Cv8aTPgVLvIAzv4/DivhLivkzMq9D PAUEuFCLwOKqP+IzuAfzP2nLs/AiNLlDQd1CuO7TPns7QUk7uedrLcKTwAEsPdUys/fCwME5 uMUrPOv7wQEkvx7cQRi8uhobQkErOe0KQe1quw+cQSOEwBS8tw6zv5ADNR0kwfX/msDk+0H1 a0CJijki9MCumzl2C8ARRD5pc8K8e0Keq0IAk8Ge0zgrjL76M7PxMz06xLyH+7Ivg8Fnez7j G8Fdg8IK9JonZLwinMHAO0EaXDylMsP8E8QqJEOHw8Mp1MPMYkOQI0UQ1EQlhLRClK4svEQS c65FdLsAc0Su8TIQs8WWG8U6u0L8G7GLa7s+vMVa9EVgdDfOoy4x8zJeRMAu5K2rI0ZYZMYH s0SUayxHo8ZirDqJ6yQ4LEDpm8Q2rERWpMZeZMIdE8VWJEVpfD8G1EHOcrM8FLhNPMc+w7GJ K8cddLxFLLJSjEVaXLLNOzG2Az1FNLf2M8Hx20V9HMRKX5TBKEs/oEOzBdxCMrs/G/zH4iO/ uAuycLy5wVs/twO/8gM+euKAqGCBTkKBkVTJlWTJlnTJl4TJmJTJmaTJmrTJm8TJnNTJneTJ iICHngTKoBTKoSTKojTKo0RKrQkIADs= ------=_NextPart_000_0007_01C6EE2F.FC088C10-- From nzjvnfzu@swisscom.com Thu Oct 12 06:55:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXyDz-0003Ye-11 for capwap-archive@ietf.org; Thu, 12 Oct 2006 06:55:39 -0400 Received: from [220.180.112.33] (helo=[220.180.125.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXyDt-00076K-AU for capwap-archive@ietf.org; Thu, 12 Oct 2006 06:55:39 -0400 Message-ID: <001101c6edec$ed5d7e70$057db4dc@C2C57826CAF4401> From: "Home" To: capwap-archive@ietf.org Subject: and share lasting Date: Thu, 12 Oct 2006 18:55:27 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6EE2F.FB80BE70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 ------=_NextPart_000_000D_01C6EE2F.FB80BE70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6EE2F.FB80BE70" ------=_NextPart_001_000E_01C6EE2F.FB80BE70 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Bliss Believe when say that one will take your place at of every in new =20 day still put is smile? New day still put smile upon face These feelings have always or true. Posts delete vote polls forumall times gmt Page of day Days Weeks Month =20 Months. Topics forumyou reply cannot or edit is posts delete vote polls forumall =20 times gmt Page of am day. Posts Location should leave would is want you know is my hearts telling =20 me. That one is will take your place at every new day still? Mind in is urging go or never wanted am end things like this just =20 together and of share in lasting? Pm Guest was in so sweet felt in guy real tallent with poetery Poemsyou =20 or can post topics forumyou reply cannot edit! And share lasting bliss a Believe when say in that one will take is your =20 place at every new day still put? Face These feelings or have always true a Never forget girl you boo wed =20 pm of Guest was so or? Things like this just together and share lasting bliss Believe when say =20 that one will take. Never forget girl you boo of wed pm in Guest was so sweet. Of day Days Weeks Month Months am Year Oldest First Select Land =20 Poemslove Music in Home Family new Yearapril. D if Should am Leave or ll Love Poems a View or previous or topic next =20 Posted mon. This just or together and share lasting bliss Believe when say that one =20 will take a your place at a every a new. My mind is urging go in never wanted end things is like of this just in =20 together and. My hearts of telling me stay a but my in mind is urging go in never =20 wanted is end things l ------=_NextPart_001_000E_01C6EE2F.FB80BE70 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Bliss Believe when say that one will = take your=20 place at of every in new day still put is smile?
New day still put = smile upon=20 face These feelings have always or true.
Posts delete vote polls = forumall=20 times gmt Page of day Days Weeks Month Months.
3D""
Topics forumyou reply cannot or edit is = posts=20 delete vote polls forumall times gmt Page of am day.
Posts Location = should=20 leave would is want you know is my hearts telling me.
That one is = will take=20 your place at every new day still?
Mind in is urging go or never = wanted am=20 end things like this just together and of share in lasting?
Pm Guest = was in=20 so sweet felt in guy real tallent with poetery Poemsyou or can post = topics=20 forumyou reply cannot edit!
And share lasting bliss a Believe when = say in=20 that one will take is your place at every new day still put?
Face = These=20 feelings or have always true a Never forget girl you boo wed pm of Guest = was so=20 or?
Things like this just together and share lasting bliss Believe = when say=20 that one will take.
Never forget girl you boo of wed pm in Guest was = so=20 sweet.
Of day Days Weeks Month Months am Year Oldest First Select = Land=20 Poemslove Music in Home Family new Yearapril.
D if Should am Leave or = ll=20 Love Poems a View or previous or topic next Posted mon.
This just or = together=20 and share lasting bliss Believe when say that one will take a your place = at a=20 every a new.
My mind is urging go in never wanted end things is like = of this=20 just in together and.
My hearts of telling me stay a but my in mind = is urging=20 go in never wanted is end things like this is just a=20 together.
------=_NextPart_001_000E_01C6EE2F.FB80BE70-- ------=_NextPart_000_000D_01C6EE2F.FB80BE70 Content-Type: image/gif; name="These.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6edec$ed5d7e70$057db4dc@C2C57826CAF4401> R0lGODlhDAKwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAWAAAALAAAAAAMArABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUtWqpey aNOqXcu2rdu3cOPKnUu3rt27eEnqycu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27d1YivoMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +wkx4d9/Uj///yH5B+CAHAlI4IEYGYjgghIpyOCDDjkIWBYQOibhXxRWqCFDGW7o4UEdfrjW IaCFKKKIJp7oYYoqtujiizDGKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll7mZEZ01YJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPbp55+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnoIYq6qik lmrqqaimquqqrLbq6qv/sMYq66y01mrrrbjmOtoAuvbq66/ABivssMQWa+yxyCaL3TnKNuvs s9DitU601FZr7bXYZqvttty2xWy3XH0LrlbijotVueZahW66VK3LrlTuvgtVvPLWa++9+Oar 77789uvvvwAHLPDABBcsmgsGE4VwwkItzDBQDj/sU8QS80RxxTpdbKU3GAPFccc+fQwyTyKP rFPJJuOEcso2rcwyTd64/PLMNNds880456zzzjz37PPPQAct9NBEF2300UgnXe82Sn/EdNMd Pe3iHBVKDfXVWGet9dZcd+3112CHLfbYZJdt9tlop6322my37fbbcMctt6vLzG333Xjnrffe 3Hz37fffgAcu+OCEF2744YgnrjjWPyzu+OODPQL55JRXbvnlmGeu+eacd+7556DPyEropJdu +umop6766qy37npJgLwu++y012777bjnrjtGv9jdu+93/z638LsXb/zxyCe/nz/K30am3c/P HX3bJU//zzNpo2y92tpvj7bM1BtnRJ3gN2/++einr/767Lfv/vvwxy///PTXb//9+Oev//78 9+///wAMoAAHSMACGvCArtoAAhfIwAY68IEQjKAEJ0jBClrwghjMoAY3yMEOevCDIAzhzGgg whJKJiAAIfkEADvdAAAsAAAAAAwCsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZslP3woqFPnv549f+5ECFQg0KE8 iwotenRn06VOkf40qpTgU6pVhVo9OtCn1q0GvVIFO/ZqWKlkyV4V63MtWpxw48qtKbarVLZv 1d5NavUr37Rfgxr1OzWt17p28dodS3jpVqRVDw9FfJay48SE20KOenau58+gVVKuqzih5L6A OXdOPZlt5r+B80a+qxqx0tmKS5sWnFSyZrC531oOTby48YmjaS/ezZiocNloSU8O3Bj26b/X GWcdzPW6b+XMq/5HDfp7efnkx9OrX68Q/fLqhrfHHs/bNvjWU333rs81dvP5wmGlHX6XJcab eQFeVt6AAGbH3oMQFudec8P99x6FqsH232Fl+WVfZs8x+J5lkCE4oHTtEYhaYVqh2KKKF0Yo 44w4TehhXuYBdiN8H+YooG4iNtbUgjuGdZBmTy1Y4ZDRHZnhjZvRKOWUctkI5GrgjfhkjC5u lmGP/rFWpIWDdYaidziCyJOTagpIZoVUxilnSEnyZ6B930HHVH9CeumUXtud2Z1yZpHJInCE Rllom12xCZV0fjo456SUVmrppZhmqummnHbq6aeghirqqKSWauqpqKaq6qqsturqq/+wxirr rCUNMACtuOaqq0S29nrrQL7aKpCwwP4jbLC/Apvssska2yyyw/oaLUHEKntssAVBS22zzvZq bbXfEivur+BGKy24147rrUHaotvtusoWO+253Ja77b30Srstvfhim62+1V47rbO7fhYwuc/e Cq/CzB6k7sDv/htvsehyS/DEEkOs78XDcmxsxgSPCzHIFQ/s7r3xLuxxxuuKvLK9GF9cMkIH 95uQuy7nbHHBN5Xsc8Ds7vwwxxtr/KzH9s5MMrM1U3w0yiEjPDLUM7vcMdRRL7syyi1L/fLO I1u9NcY/33y0wCZ7zXNcZacsc9AOk/uxzGoTbbHSMcPctM7+cJs98cYw28113X3P+3bgh6c9 NeJVJ+x32Aw/vm+9C4O99kxtGx5y4f+m2zDSn09eNORx/622v+/ejTrgYB/cLtNJOy41w6NH zPriliMrNuOw5wtvuOYG3fTlOGW++fFYTx6x4mSrnjzocd8+duxL59166HSXjvWxhiNue+W4 S559zNWnbLnEteNNfE3Gcx88yJ3TjrC2gjv9vPpTp+6t7MkP7z3Vjnsb+XxmrbF9a3njI9/2 6sY76xlwbvOK3PPWV7zPEfB9EzSaAzVoPwXib2sX1Fz4OJg/Eo4vgA5k2gNNKLYHNi6D9Yvg zWwGPQVSMCb009/V8tdAFmLPX+r+kx78SJc64MUPb4EbXtbmpzcg9qt2MfSd58r1MyWWL4Lp A1joPnjDLnrxi2AMoxjHSMYymvGMaEyjGtfIxja68Y1wjKNnJiDHOtoRNHS8Y0MCEICB9FEg fCRIIP3Ix0ICspB/HOQhC6LIQwYSkY/840Ea+Q9EOnKQjYykJQUpSU0a0iCQTKQkK8lISFZy lJEk5Ck3eUlRslKVsKTkKj85S1d+MpSttKUnZclJTtKSlyTJox4ZgsliEpKSiszkKXvJzGYu c5EIkaUx/fhMaFazmam0pjY1SU1QdhKVfUxmOL+5zWpm8peiLGUvlWnNc5pznOrU5jE7yUxg ikSYw1z/SDHTecl4XhOesAyoQMWZEGnyE5D/JKc3VUlQZ3IToQvdJkCX2VBlurOf0EQmOP8Z UHcSVKMC9Wc87QkSfOZTIZgk5TOn2c5RSlSkL5WnMzPq0oSGtKXvFOkjVzpJhS7yowo1aD0P +sqXArOhPyUnSGV6U5qixKQnRakhWcnSnJYSlzO1KVNlOs2phtKn2JzoUn9K1ojW0qsMNeU8 D7pSotJyoBP1p0fVikusRrOmVo1qTSxJVbYiFa4w1eo1A8vSbOLUrLusqUfLKteNAnWw69xo W7Nq06OC1bCGTao+FStZvdKEr7f8akdRKViudtaeQs3pRSGrWrwC9pt4/Stm/gGazMhG1q68 nKsgR2tbzQ5VqoGN4yiIg9TVyra0kDWua5PrVsHmVqnLrewxe/pa6Mayt5PlrVkpStrD+pa7 jS1oZ5vq2ZcU97TgDO1M64rOtbqUvftEq3a9qV6pbnK8821rfWka2r6G9a59fes570tXU67W vWdla3lPgoYFO/jBEI6whCdM4Qpb+MIYzrCGN8zhDnv4wyAOsYhHTOISm/jEKE6xGRus4ha7 +MUwjrGMZ0zjGtv4xjjOsY53zOMe+/jHQA6ykIdM5CIb+chITrKSl8zkJqMkFE6OsnGgLOUq f4bKVs4yXLCs5S7ThMteDvNLwCzmMquEzGZOc0nQ/qzmNoOEzW6O80bgLOc62/nOeM6znjnM j4f0OVN/FjEABj1oOQXaIPxI9D8UPZA+J/rRij70QSDd6EdXmiCRpvSiC+JoSGea0poWSKgr 3WlMk1rSosa0pRvNaouE2tOMXvSqW01qWXt60wi5Na5TzWsQF3ogAIgTqk0ta2L3eteTRjSx Y13sQzua08ZGdq//7GxlF7vVwzZ2taft6mhLO9vS/ra3o/3sY4M7w78WSLD/QehftzvYhFY3 vNPNbnfPe932lndHzk3tXW/72NAOuKnL/exqS/rf4Q50vxXSb4WHW+Co7nSkbX3qVB/c2uZO dsIF/vCML3zcG6a3vvWd/+961xvf+CZ5vksucozw2+K0Rja4I65sgm/a4BxHOLc7jm1/83zn y740zFnNbIDLHOQfj/nRcz3wh5/7wi1Pd6FZPm9gr9vqJlf5yD/yclwnXefjprnNyz30mDv7 1qMedc+9/nOfB9zhRG86xs0OcqWL2+50LzreNRz1q08d5Vof+buznvV2i6TrDkf4zOc+dEZL 3PE5D7vRjf7xgi8E7kH3ONo1Tu66Uz7yudY02T2PYXpXPfAr9/vp/471k1+d6wzntuITQnNo U7vhjJ89xDm/9pu3HfO9xznH7a57pg8f7MT/vK9ff3qTU53wrHe+6lu/dY0gXtWdp/3ck152 bf6D3vtLz7youf99tx9d+Ns/vrVrT/e3Y/ziIR68vONdeMC/W/Xxlvr0qW99tVv67OSmduMX a69Wc6HHfrb2f8s2a7UGgAM4bGdXdBOHbas2cwxIeRX4gBIXgBm4cbT2dDTWchAhghAGgqBi gjJGgg6hgg+GgpzignsWgzI4gzRYgzZ4g3jGggShgzjYY/InETxYfTFxCIdQEERIhP9whEeY hEXYg2pkehMRhIQnE0hohE0oEFXIhE74hMxXf653byqHf88HE1k4EGWYhWW4hWXUd6hnf6mH dSX3EmmohWZ4hXOohmMkf2/ohfoHfc1HhVdYhwSBhoGIh2hkb2MYff/SB4evN4SFSIdYaIeP aIhgxHwol4jNp4iKCIgGcYaSSIlruIP754WLGHilKIUjMYeeKIigSEY/6IeCd2/094Wx6IhK yISEWIe32IpnhIo3IQ+86GG+OBPyUIzBeGfGeIx2lozKKGfM2IzQGI0TFoTD2BKN6BHXeBHZ KI3qIXX8lxB9R3/VyBKWKIKGZ3XbuI0GMYrsto7cGCGIKIQIIXJQOI4qIY47WBBd2I4KoY6i qG4AyY/6+I4QEo/1p3/nyH+rl5CzyJD+mBHw1o77CGz5+JDXeJH8mHICOZAEuR7ulpELCYv/ qI+ZuHqkaI8PEZEBuZIsKYvZiJH5mJEAqY7/D9mRnmF457iHU7iTpdiTpGgS3kiRMTmTQymU Rel3rQd4RWmTxoGT4jh4fTiS/xiVT5mQQKmRLDl/U7eUAnl/LomRWLmRTFkcThmHW0ePXaiJ lsiTJxGRE3kQKpmVYjmXcqmRbzmWZDmK3miQCtmTW+mX8tgRbrmRYRmQdzmX6eiOMmmUeJmX CtmQm6iVSvmDkBmVIlGZSDl/okiCjZiYR3mYjblgNWkRowmEoSlhpVkRqbmCp9marvmasBmb sjmbYoSSZEmbunJ/CzGOuskRtgmOivmFq4mbloKKKPmb8zicDVGZjEmcpqKDvXlytbiOnbly knmJ2KmUqimRQ6mc/855Ka9IfR95ii+5j3+nlie5lqSJmOiInN8ZJ+dZkiT5k1I5lXoZkmyp jTAZnO85KmwYi1WZjuWInmH4lB9Bj/PYn6Xyn+SplcmZlPJpit+oEXFJlxaqoOBZnwD6kypI lRGaf5lpet5ZkYTJmCOKoTMSnuh4kJZJnZu5iSDqoCuanyOIkIh4oij6nDjajzsahTm6hj36 okFqmj9apEZ6pEiapEq6pEwqZiqKjeVplXDJjgfakCDxpE3qElB4meU5oRp6mTE5pPwpplmK EfU4fVv5lzkJhrQolSKanYuImWbZj9SZpjLKpm1qoiWamWU6Egwan67Hh2M4n2c5ndLnhv8Q yprBOZ4ziZR3mZYkKpd9CqUuaooeKpLm+KRxiJ4tmpJWupKQSpGPmpNheqGTuhF/GqHCiald ipYGaqmqShFYyafcKapLGaqGaaqnCpFpiab3Saj0majT2YfESqVEyqe4WqtZmawpR6a7WqmN qpmWuZf7l6nCuqnyaZBSaJ5Gyaxd2ZmRCn3P6qcOWXUtuqbiiZYjSZms56H4uZyz6Hwv2pLS SpLMSavjuhIHUJDOaqbbma+ygqX3GK8R0a8Ae7AIm7AKu7AM27AO+7AQG7ESO7EUW7EWe7EY m7Eau7Ec27Ee+7EgG7IiO7IkWyrIQINNULIqu7Is27Iu+7IwG7P/MpsRfzCzNnuzOJuzOruz PNuzNJgP+eCzawO0E0G0DWG0QnsqQIu0D8G0SUsrSxu0AkG0S0sQVfsPVCu1Rnu1W4u0Tosp YCC0XTu1Y4u1ZIu1QTu2W4u2bGu2bbspYeuzZeu1UjsQWdu2d2u3aVu3ohK3PDu3ddu1VSu4 gQu4fAsqfpuzURu1b5u3jnu1evu2kou4O8u0ecu2alu4dnu2VHu2k/u0lmK5exu5aDu4mqu3 Wpu6pwu6UHu4rCtGX/u6spsp4zC7tnu7uItj3mmwfpq7vsmRu+mjwBudUxqU2Oi7qAq8dFqw CNmcwCmUvMu7swuueKqH+AiWJSqp+9me/7VKqnI6kPhoq5KKvGKZiXtakS/JnpLpvOkreOgr vsvqqOEqvTFLveGqrPgLrM47vjLalXrqrUeZvRVKvrd6vqIKlTyqvFyZoP5LrwD8v6VKv/UL vvc7wKZaoZ7JELMKwfBbvhVMlAQMl9A7vxhsoYPZraWqvBvswCTMkZigrMYbwnWqp9KJnfz7 vYGqvfH6l3capjy8vvXKvzJcEhIMkf86xCtRxLJKsCOIxE78xFAcxVIcihLBBhQKExacu1K6 ntzbv1P6pSJMpPDaobr6uqAJhIyKvzSpnsErxm08vllsu9hrmNfrjhZcwuzZrP1rvR95iXfK xFGqx+Q7x2rMlv9xjMdzfMIgvMgSCZO0Cq4qnL+U0gzf6ciLycj6O8L7C8KKLJFJ0MFZvMJ1 Gb5EqcQ00QyU/JoKwMARfJ0XzMZnDJKMXMK6OaCgKrCNjJNlLCOpPCmFIGSWXJgXfMn0ysB9 /MH7GaKbLMKEPCe97MtD9paPbMLcub3C3Mxx+cPZrMnZy8GlPCmojCm/DMwEa8sXGqA3yr6K Wa4gmcYO6cVdnMNxzMubMs5xZspp9MyZYs9ths9npM+aws9TPNAEXdAGfdAIndAKvdAMjWHd 8NAQHdENPdEUXdEWfdEYndEaHYx2sNGj0tEeHdIiPdIkXdImfTnnc9IqvdIs3dIu/dL/MB3T Mj3TNF3TNq0qosu4ZKvTdFu6kOu5qLu3jBu7N50QOt24oxu5PQ3UVuu6oku6RX20kNvTT73U n/u5T83UWh3VgKvUfHu5Vt3UBpHVWO26RW24XPvVSY3UB/G1ZE3UUV0QXc25as3WW13WYn3X cd3Ui7vWl4u5qxu7bl3Xer3XTA3Waw3YUC3YTk3YeG3YVb24QU23P83YQz3VhcvTZm3YnN3Z nv3ZoB3anW2RsOLPN4nFQMnKKSmYy0mhpk3EW1ywb6yrzKmZth3G9orbXLzL/AnPu43G+Pza va3Av32/2kvbsr3AQSrcRJy8y9vai7zN+LrJGVzcbszbyS2r/yjB3Au8zNdN3c8b3oo620ds E7lg3aQsi12MmehLxvK7rKrtw9p6zOxcw7Zd36BZlSwKqtLZ3ypZznvMmXXc34EaonzJxNKK f9/czvftqgHuqv99ntUszwfsx7dN4QUOyLXtltqay35oww1uyggc3f773jA8v2Fs4rHsmSp+ wPyN4i3+wcO7mNINv44qzLmKyYtaeDZe4t2J3MTcyJzc43Qa4/yNxzze4shKl/Jr5Efu4g0s 5DROwbPs3c6Nwkpe4TyMq8lM5MOc4jauyy8u5idu4Nq843bp49FN5ub45M+9zSRu4rTIgmle 4Omaf17K5lHu48ab5WseozNe440q3f967uZTbuezHNvH++N+nr/TjK8TCeekDeYk/uNx3uON rr7de+mV3pwIqubhDedlDspfTOmCvum3GumgrupoiuWYvr9bOuGdbugvvuq5mummDcmjzukn 7uUezOuebsxeLuqnXuygDt9Dvuu9LsmQLOe/vuzGrurcnOPGruw0rOysjuK8TuwBvODLbujc XumCbO3KHBIXaaMNvKZiqO1AvOGkOq8rauD3jcLyHOErTObrPZ7Nyt4HecvVKelpjOG3re4W rt/Ibpd4fuTFeu5bDs+6DJklzu/zrev2LuoPXuv+rck2bOYDHyvcbRMfL97b7UWTLhch35Si cvK63ZY3hOD/xA3yoh3zMj/zfSrBOyq9/lyT3K3yK0+Jo8nw5gztQL7EgAzd/jrbOS/ylr7o KB+CRk/v6bvkGlzez/7c2jj1Vs7a8d3dv3scPB9GAermYU/gx87NTS7x+k7H9l7MY2/wiv7H Cr7vBe/yh17HCM+m+j334fjg/z7vAD/uIZ7gPTzofn/h5dXoinzqro7mm474U56s3bztvs7o pC7KFp/ChJ7sx+34zOzrrL7BNx7JyR7tWI7jh//qpaznQH/c3zzupD+Yeyn6qr/41DzoBBrl l2+rif+t4jmvnM+9Tm6jtLy+1iy+rr/qbP71tOL4A+zsVe/q/23rTQ7DnWzA2D75/7Q/lZfs 5CS6+3Le8JI/zZI/n7qO6uq8+MfP/dUJYcwv/cNd/OBu63veve7s/vH/7BYf/Ute7pYuv0Eb lgAB4J/AfwMLGiSI8KDAhAkNFmS48OHEgwohUpzYECNFjQQ9ZgSp8aLDixsrnkSZUuVKli1d voQZU+ZMlwBsQrTZMOfDnSAHOiSJ8yZJkRZ59uzpMynRkx535tQpVGjRhUhv/vw40ulWqiUz Xi0KtepUnEezYhQrUmxVnWe9Yn3LVipPrVexOp3bViJNvn39/gUc+G9QwTAJF44J9TDKxYwd I14ZtDFgK5AtX545GfNmzp09F9bMOfRnmqPRkj7NuTJq1v6gW7+GHVv2bNq1bVO+nVv3bt69 ff8GHlz4cOLFjR9Hnlz5cubNnT+HHl36dOq6TfO+zjf7y9HbRUP33jl8Rbviq8tWbDJy0tnj DbuOGxmye/fq+4avf7m+d/6e8x/viqX/EBtQPsECVKlA+7gDTEH8sGuQNQVTmlC4tvQij0Kw huJKrru8IgqsvMr70KKlntrLKgylWguuDF2MqMQTGSJRxQvJ49BDuNjbcUa5VPxRoq1GwtEu pMwa0UgRGTtySBiVHNLJFo8sMsmfyAppw48qpC0sn+LrqKQYTwszPiKB2gvEK0MSss00x3yR zbeYWtIoOBsbM88Xt3QTzDj1RP7TsUCN0qqpPmmc81BDCevoLD2JTNPOLyFNFFI+KX0UIS67 fPOuQTvN6tG0UtxoVCMjLVNOSYFKSzJQWzQrUxqfQnBUTPe89dSmvEzvU1vV7NDVuoYaC9gU UXxMUkxbLXbVY4lF1c1LnZ0Kzuh4TTDZGKcFlFSmlp00VXFVNak8bClUNVUcS1WUqlC/hJZJ cjkC9U9q7f12rHHVrddYM5W8t9toLc1V0TilOze1frlNN1J/b+23YXXdtRfigh9GU9iAcVWW UkHbrZjQMPmV+OOLCY143ErPBNnjQbc9WdYFl/PSxV21FHNYtmRmklgfi3Rrxg6fdHJdtWok i1Wcbf6uEdlYOZYSYA+nhLIsGbXc1umdp9aRyqcZ9RrGKokWs85gb84rZ6o3TPs81LabcNPb 5H57N7prOu9utw8szTK9YeNRub8Tiw1WhPdGPHHFF2e8cccfhzxyySenvHLLL8c8c80357xz xLsjDU/tGAyMRLsHH8yv//qTCXXP5545dr7ly84hXxgtPTgEC0f3vtnN7J1wvF9/DvTPRK+d 9NSB2z238VY/WMDMiE/cVlqX9LroJG+sF0XtsQyWx7XPXDoiWqf+OXAge4QZSRNN3zpt823k Wsq50IdS6fuvH1psppH9GfV6MzJ8LapP2VKZsaJiqAImUGKOEtK7yHRAiv6ljFRkgmDwAMWw fbnKWibrGLzoFbONCUyAvxnZudaSNQ3FK1Nsctf1YGgwYP0qYRK0IUdgpauOme9rOztMo5xm wlnF60OI6hkR//SrkrGsYL1y3Qlbd6huqUWHBbTYDNUUFwJmkV81UxYHKSggJbKsjNLzWBNR dsOXNaxTB9tXm+IINilCyGVanNTKzohHMCqQhmq8odpatkUDevGCPeTiIJWYwDthMYQJA2QJ wwW8OgLOe1grGw/VN0QsbQ0vSstX1lwINK7NyWw5O+Kz7re/Oq0pLFpbys0wJMQMhs1Upsth iYrlI5VRSWjui2Ulh2M85oiOePl6D+eiKEz/JP8zOYFjoOc05szLQZOZ18RmNrW5TW5205vf BGc4xTlOcpbTnOdEZzrVuU52ttOd74RnPOU5T3rW0573xGc+9blPfvbTn/8EaEAFOlCCFtSg B0VoQhW6UIY21KEPhWhEJTpRilYUc5qwaEY1ulGOdtSjHwVpSEU6UpKW1KQnRWlKVbpSlrbU pS+FaUyvWQaZ1tSmN8VpTnW6U5721Kc/BWpQhTpUolauH/0oqgCPulSkHrUiTmWqU58a1YJE FalVpeo/sqpVpmL1IFDdqlVP0lWuLjUlYuXqU7061qt+1axilapKtrpWumo1rWidqlmxStaz tjWtX/0rWAHr1bjelar+eMXrXvUaV7Dyla6N1etfLcpYvwpWrm21bGD9Klm7FrapmP2sW+uK Eql6lq1TLetgCztazlJ2JaZVrFsxK9nV1jW0oiVtZHWrWc1eNbOGPe1aa4tb4D52s8alrW+P K1HXina4yG3uak07XdAml7WobW1wCctY1tbWs9W9rFpju9fBYle7na3scvm629LedrG33a52 2/va6jaXs8TN7HyJ543n2Le4fXUueKV7XO/WV8DLxe1zbdvUwHaXwOklbm4B3ODSStjC5r0v b9Fb1fFWWLmthS9yM4xf+PqXxNYdcUQpC9e5WhexWQ0rWV37YscaN7IRhiphHXxhFE84uBX+ viuPE/zbAgtXx2UFLWQV21UWr7fFaLXvcGd8YI3697dslXGIFZzh/Ib2uyyR8ma//OEPn3fB ETazcH17ZAyf+Ms/XnOQF6xkEN+XyAh2MXhHPGUnV1nP/xWyhu2MWghPWcThtSuaxyxbMD/Y vAqmLlwZneY8t9mqOSbvnD+r3/hi18SPLvGf3YxnP+M4xGmOrpgJTWgDD7nRHFZ0oSdd5PN+ Gsd1TnKgKx3rVWfaznoes5ipjOj/2trQulbxnyE7YB4vW7m6dfJ7WV3jLN9Ytov19IOZDO1r F1jazm1ziqHcYlyDWr7K3vRbC/3kGN/4uTBWL6mTOm9619ve98b/d771vW9+99vf/wZ4wBHK 4mk/O8xZVmtiaRvgK0O63eqGuJaRjGRn/9rB0KZ2eh27ZYH3F91qFq+pU8thh2dav8wmNqdH 297Z1nnlwn55wiE83h5zvOPNsXKZYSty9uKZ5SC3OLEBHfTdujzorsawlpMMbFHfXDo5B7rQ c+xhn69Z52VGc9JPjXL3njnmWHZ0ra9+aJs7XTkrhne3m83gICt84n0++topnm6dH/nNc+ey tZfs9ZPPtexmRw7U9wxzcLed1NtONaXPjPIE233mcc+6hN/cd8gD3uMibzCvC5/aLSN+2JFf POEbb/LHMz7cie70dgmeYstHR/BA/jqb/tXdkteL/sIqJ/qsS2/7yK+b1b8/dOsvH3qWHxzb DNd7zSNe8bxifPbXRr1ho3zYGF/W+Sq/83WFv33ud9/73wd/+MU/fvKX3/znR39Ivxvt5A+4 4g6vtt77jnDVt5/c65e/xpOPeZKTe+FeXzKDw7pfY75uo7uwC0ADzC36gzUFDDbke7eHE0AE w7+mUypuizpa0zrQOzHNy75jyztTm77m68AFzLX+y7qfSy7Go65wu7vbQ7cRZL1ga7lzA75i Q0BAs8CJa0BBqyO4S73KuzuOEzxXe8DU00D84z8gjMAVA6wX7C0bE70WTMHHg0ER/LiSY7jy MrcA88Id+8IG/+w8ChzAE6K8MBTC3aO9jwO70AvDJBy2yRu76zo5CrNCCgO6IcxBDZxBpkO6 I/Qxw+vBEsTBHuM5Mny1Cfu7zDnDIDQ9ACRCNiRBXDOwGkvAP5y5+du/OhTEKqQzH/y0S9vD qlNATCw408M0TDu31ZM++7tBxaPDHXydRtRB3jO6SOS/LkRCL0NErhvAM7yybIO1qbvDt8NA PZQ7saMvNNQwQJQ7MvMxQBSsCHzF06tCa/QcUaRESxtFDgy+MDvELwTHFaS+U3w+42MyRoNC Yyw+Jqwso8tFGyTHbavGDTxBedxFHwzH8hpDWJQiacQ6PoREeStCXSzEUPy8QtxGMImUvS5L OUm0MngEwCuMOoXUwoaMt31USHt8R+2bSI/sHBq8vnjzPBKzRBA7SZS8vo90xgJsSdtTxVa8 yCKsQJbEwGj0PQhcOm87vljEvLTzxJUEvSZjwPQzyqNEyqRUyqVkyqZ0yqeEyqiUyqmkyqq0 yqvEyqzUyq3kyq70yq8Ey7AUy7Eky4MKCAAh+QQAFgAAACwAAAAADAKwAQcI/gD/CRxIsKDB gwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2D/xQlLtqzZ s2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4hLgkrMuLHjx5AjS55MubLl y5gza97MubPnz6BDix5NurTp06hTq17NurXr17BPsolNu7bt27hz697Nu7fv38CDCx9OvLjx 48iTK1/OvLnz53hzQJ9Ovbr169izV0Shvbv37+DD/osfT768+fM6X6Ffz769+/fw48ufT7++ /fvtw+Hfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26OGHIIYo 4ogklmjiiSimqOKKLLbo4oswxijjjDTWaOONOOao44489ujjj0AGKeSQcYlC5JFIJqnkkkw2 6eSTUEYp5ZRUVmnllVhmqeWWXHbp5ZdghinmmGSWaeaZaKap5ppstunmm3DGKeecdNZp5514 5qnnnnz26eefgAaqoAiCFmrooYgmquiijDbq6KOQRirppJRWaumlmGaq6aacdurpp6CGKuqo pJZq6qmopqrqqjlKwuqr/7DGKuusLM5GK1u23rpWrrqmxWuvZ/0KbFnCDtvTC8aihWyyZS3L LFnOJgcFldE++1W11nKFbbZbbcstVt5+K+645JZr7rnopqvuuuy26+678MYr77z01jtqCfbm q+++/Pbr778AByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcscqDT jmzyySinrPLKLLfs8sswxyzzzAQBQ/PNOOes8848o1VHz0AHLfTQRBdt9NFhiYP00kzLnEKC hXD4NIJRbzj1gVVreLWBWWe4dYFdY/g1gWFfOHbTaKet9tpst+3223DHLbeG6Xw2ytF3G513 0dp7E9330H8LHXjQg89t+OGIJ6744hNyYbTjj0deNOREUz605YyLq1/mnHfu+eegh65QAUiT frTpRheAesHhwrQ6wa2/9LrAscs++7+1uw770bnj3PvNv9McvOjEF2/88cgnr/zyzDfv/PPQ Ry/99NRXb/312Gev/fbcd+/99+CHL/745Jdv/vnop6/++uy37/778Mcv//z012///fjnr//+ /PfvP4iw+J8AB0jAAhrwgJL5BNIUeDQGGs2BRfsEBBFIwZ8QqoIYzKAGN8jBDnrwgyAMoQhH yKCAAAAh+QQAFgAAACwAAAAADAKwAQcI/gD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgz atzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iT Kl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3LdiOgtnDjyp1Lt67du3jz 6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hT q17Neu+a1rBjG3wtuzZs2rZzp8atu7fv38CDCx9OvLjx48iTK1/OvLnz59CjS59Ovbr169iz a9/Ovbv37+DD/osfT768+fPo06tfz769+/fw48ufT7++/fv48+vfz7+///8ABijggAQWaOCB CCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4otC0QIj e7TUqJEDMz5nY47p7cjjeT7+KOSQMDZD5JFIJqnkkkw26eSTUEYp5ZQaykBldlaGR8WSWV7p 5ZdghinmmLXlQ+aZaKap5ppstunmm3DGKeecdNZp55145qnnnnz26eefgAYq6KBNPUHooYgm quiijDbq6KOQRiqpStxMGugclma6XQ+adurpp6CGKuqopJZq6qmopqrqqqy26uqr/6iNIOus ssJq66245qrrrrz26uuvwAYr7LDEFmvsscgmq+yyK27D7LPQRivttNRWa+212Gar7bbcduvt t+CGK+645JZr7rkHWoHuuuy26+678MYr77z01mvvvfjmq6+Hs+xLVL/+DgVwwEEN7JcUvBrc F8IEB8Vwwz89DHFPUkjcKo4TZ6zxxhwjpm7HIIcs8sgkl2zyySinrPLKLLfs8sswxyzzzDTX bPPNOOes884QqsLzz0AHLfTQRBdt9NFIJ6300kw37fTTUEct9dRUV201UpjGdIXJWcO0Ncld v/T1yGGLDfZMY4dcdtVrU9321XDHLffcdNdt9914543fMbB69+3334AHLvjghBdu+OGIJ674 4ow37vjjkEcu+eSUV2755ZhnrvnmnHfu+eeghy766KSXbvrpqKeu+uqst+7667DHLvvstNdu ++245w5YHbr37vvvwAcv/PDEF2/88cgnr/zyzDfv/PPQRy/99Mk3Qf312Gev/fbcd+/99+CH L/745Je/rRHmp6/++uy37/778Mcv//N/RAgDg/XDnf/8/O8aSv8ADKAAB0jAAp4pIAA7 ------=_NextPart_000_000D_01C6EE2F.FB80BE70-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 12 09:44:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY0r8-0002ea-2m for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 09:44:14 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY0r1-0007qa-JW for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 09:44:14 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 01D2B430F9D for ; Thu, 12 Oct 2006 06:43:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 4D9DE4A452F for ; Thu, 12 Oct 2006 06:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C8A343057C for ; Thu, 12 Oct 2006 06:41:12 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by hermes.tigertech.net (Postfix) with ESMTP id 16ED2430F91 for ; Thu, 12 Oct 2006 06:41:07 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id m19so1083782nfc for ; Thu, 12 Oct 2006 06:41:06 -0700 (PDT) Received: by 10.48.14.4 with SMTP id 4mr5117788nfn; Thu, 12 Oct 2006 06:41:06 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Thu, 12 Oct 2006 06:41:06 -0700 (PDT) Message-ID: <5bfe7a820610120641w7f98b79o1de0119a1a0dfb4d@mail.gmail.com> Date: Thu, 12 Oct 2006 06:41:06 -0700 From: "Dorothy Stanley" To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2029E8956@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <4FF84B0BC277FF45AA27FE969DD956A2029E8956@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, NORMAL_HTTP_TO_IP, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * Cc: capwap@frascone.com Subject: Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0047233093==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 137f5c1a55304041c5dd1b8cc56c1ada --===============0047233093== Content-Type: multipart/alternative; boundary="----=_Part_47595_27466211.1160660466369" ------=_Part_47595_27466211.1160660466369 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems to be an implementers preference, which the proposed text change accommodates - the message element "may" be included. The AC may choose to ignore the data that is provided prior to configuration. Dorothy On 10/9/06, Pat Calhoun (pacalhou) wrote: > > I personally prefer to start maintaining configuration and status state > on the WTP after the join is complete. Is there a problem that arises with > the current draft? Is this just a personal preference, or is there a bug? > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > ------------------------------ > *From:* Dorothy Stanley [mailto:dstanley1389@gmail.com] > *Sent:* Friday, September 29, 2006 2:22 PM > *To:* Michael Montemurro > *Cc:* capwap@frascone.com > *Subject:* [Capwap] Proposed resolution to Issue 177 WTP Reboot > Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations > > All, > > Issue 177, "WTP Reboot Statistics belongs in the Join" > is listed below: > > *29) WTP Reboot Statistics belongs in the Join, and the reasons listed > are not clear enough. > > Doesn't really matter whether this is included in the > configuration or the join, but if the WG agrees to move it. We can > clarify some of the reasons, as long as it provides value.* > > Believing that there may be times when it is desirable for the WTP to > provide > information to the AC about its stability, the proposed resolution to > Issue 177 is > to insert the following text at the end of > Section 6.1 "Join Request": > > The following message element may be included in the Join Request message: > - WTP Reboot Statistics, see Section 4.4.44. > > Comments please, > > Thanks, > > Dorothy > > > On 6/30/06, Michael Montemurro wrote: > > > > David, Pat, > > > > I created issues 150-198 to deal with the points in David's email. Happy > > hunting! > > > > Mike > > > > > > On 6/27/06, Pat Calhoun (pacalhou) wrote: > > > > > > Going through David's lengthy document, he has raised an interesting > > > number of points that I believe require issues to be created. At one > > > point I'm paraphrasing Dave's comments in order to be brief, and > > > introducing my own numbering scheme. > > > > > > 1) Can message elements be in any order? (I believe they should be) > > > > > > Yes, and I suspect we need to include text to make it more > > > obvious. > > > > > > > > > 2) Are all specified message elements required? (The obvious answer is > > > "yes", but this document doesn't discuss versioning. For example, what > > > if in a new version of CAPWAP an additional message element was to be > > > added. Would a new message type be created and the additional message > > > element added to it, or the existing type reused?) > > > > > > This is a great question, and one that does need to be addressed > > > in the spec. In the Diameter protocol we dealt with this issue by > > > including a "Mandatory to implement" bit. If any AVP was received, > > > whose > > > bit was set, yet was not recognized, then the request had to be > > > rejected. > > > > > > We could consider something similar here, but I believe with the > > > > > > firmware download component of the protocol it may be less of an issue > > > - > > > although not guaranteed. I would hope (and expect) that as the CAPWAP > > > protocol extends, the AC would push new firmware to the WTP. This does > > > > > > require that the initial part of the state machine be fairly static, > > > and > > > this could be an area where the "Mandatory to implement" bit could be > > > useful as it would allow the AC to fall back to older protocol > > > behavior. > > > > > > 3) CAPWAP-01 doesn't do a good job of indicating which message > > > elements > > > can be repeated. > > > > > > Another good point. When we list the message elements, we should > > > note whether the frequently is 0-1 (meaning absent or once), 1 (only > > > once) or 0+ (meaning any number of them could be present. > > > > > > > > > 4) Can "additional" message elements be added to a message? (I believe > > > so for reporting capabilities, statistics, and events. For > > > configuration, there is nothing in the protocol that says what happens > > > when one end gets an configuration element it doesn't know about. > > > Should it be ignored, and the other elements processed, or should the > > > complete operation failed?) > > > > > > The "Mandatory to implement" bit above could address this issue. > > > If an unrecognized message element is found to have the bit set, then > > > the whole message needs to be rejected. If the bit is not set, the > > > message element may be safely ignored. > > > > > > > > > 5) The config has a concept of "default value" for each configuration > > > attribute. However, the default values are not clearly specified. This > > > needs to be resolved to be able to support "default values". > > > > > > Another good point raised by David. > > > > > > > > > 6) the documentation of which "binding specific" message elements are > > > to > > > be included with CAPWAP messages is not consistent, and is difficult > > > to > > > follow. > > > > > > Has this been addressed in the latest (-02) document? > > > > > > > > > 7) There are some message elements that cause "actions". This approach > > > to protocol design is problematic and should be eliminated. > > > > > > Could you be more specific as well as provide guidance on what > > > you > > > would like to see? > > > > > > > > > 8) The message types are inconsistently named, and do not follow the > > > conventions of well designed protocols. Can the operations be named > > > consistently with the following terminology: > > > 1) request/response (used to get/set/perform action) > > > 2) report/ack (use to tell the other side something) > > > > > > Could you provide your thoughts on which messages fall within > > > which one of your categories? > > > > > > > > > 9) Many of the configuration items, and status items are not listed in > > > one section with definitions. (Well make it two sections - one for > > > CAPWAP and the other which is "binding" specific.) For example, not > > > all > > > of the time period lengths are identified and specified in section 4.5 > > > . > > > > > > Unfortunately, the document has gone back and forth a few times > > > and before we opt to change the structure of the document, I'd like to > > > > > > ensure that we have broad agreement on what we want - with the > > > understanding that we will never make everyone happy. > > > > > > > > > 10) each operation should have listed in which states it can be sent > > > and > > > received > > > > > > I do not understand your comment. > > > > > > > > > 11) All strings, such as WTP location, should be changed from US-ASCII > > > encoding to UTF-8 encoding. > > > > > > Agreed. > > > > > > 12) The term "mobile" is not really accurate when describing wireless > > > interfaces, since wireless does not imply mobile. Can we just use > > > the techie term "STA" instead. > > > > > > I agree we should use the term Station, or STA for short. > > > > > > > > > 13) The WTP Descriptor message element contains too much information, > > > lacks clarity on the WTP encryption field and includes version > > > numbers, > > > which should be in string form. > > > > > > To the first point, I disagree. I think there is value in > > > knowing > > > everything about the WTP. The AC vendors can expose whatever > > > information > > > they want, but I don't believe anything is unnecessary. > > > > > > To the second point, this is one of those areas where the > > > concept > > > of the technology binding creates complexity. Given that we cannot > > > simply discuss 802.11i at this point, the only thing we can do is punt > > > to another section in the technology binding section. That said, I > > > agree > > > with Dave that the 802.11 binding section is too light in this area. > > > However, I would much prefer that instead of trying to address this > > > specific issue, we discuss whether we should even be supporting the > > > mode > > > of operation where 802.11i is performed in the AC - especially with > > > the > > > introduction of DTLS to secure the data plane. Right now, it just > > > feels > > > like we have too many options and I am worried that interoperability > > > will be severely impacted (not to mention protocol complexity). > > > > > > To the last point, I have no issues with including text stating > > > that the version numbers should be in string form. > > > > > > > > > 14) The WTP Descriptor information is not required at Join time. > > > > > > Well, as far as I can tell, I think there's value in knowing > > > whether the WTP can even be supported by the AC. So the more info is > > > provided by the WTP, the better the AC can determine whether it should > > > just ignore the WTP or not. This could be done because it knows that > > > the > > > firmware running on the WTP is not compatible, and it has no new > > > firmware to download. > > > > > > > > > 15) Are the values in the WTP Frame Encryption a capabilities bit, or > > > an > > > enum? > > > > > > Looks like an enum to me. Not sure what Dave would prefer the > > > text > > > to read. There are various other similar comments throughout, which I > > > will not repeat here. > > > > > > > > > 16) The Discovery Response is broken. The AC SHOULD NOT be providing > > > any > > > info to a WTP (or something that claims to be a WTP). Also, the AC > > > should tell the WTP what to do next, with choices: 1) Ok to try to > > > join, > > > 2) don't try to join, 3) try discover on a list of > > > returned ACs) > > > > > > I don't believe there is an issue with sending the AC's > > > information to the WTP, but would solicit input from the list. That > > > said, some of the information in the AC Descriptor is required, such > > > as > > > the current load on the AC. No point is trying to join if he AC > > > indicates it's already at max capacity. > > > I believe if the AC does not return the response, then it > > > implies > > > (2). Otherwise, it is (1). (3) is handled during the join or configure > > > process, which I believe is right. > > > > > > > > > 17) Is AC Name text? > > > > > > Yes, and same with WTP Name. > > > > > > > > > 18) Primary Discovery are not required. > > > > > > Disagree. Required for failover. > > > > > > > > > 19) The text does not make it clear that the contents of the WTP > > > Location is informative only, and as Dave calls it, a "scratchpad". > > > > > > Well, to be honest, I thought the example "next to the fridge" > > > made it clear that the information did not derive from any scientific > > > formula. The description also states this is a user-defined. I believe > > > this should be good enough. > > > > > > > > > 20) Session is not required > > > > > > I believe you may be correct that with the transition to DTLS, > > > this is no longer required. > > > > > > > > > 21) need to send "common name" as found in the WTP CERT so that the AC > > > can verify > > > > > > The protocol currently relies on the MAC address being the key > > > that binds the certificate to the WTP. I don't see a need to change > > > this. > > > > > > > > > 22) Result code in Join Response is not sufficient, for instance WTP > > > HW > > > not supported. > > > > > > Well, the protocol does not require this because the Discovery > > > Response would never be sent (as the protocol stands today). > > > > > > > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary. > > > > > > Agreed. > > > > > > > > > 24) Change Echo to Keepalive or heartbeat. > > > > > > I call it potato.... > > > > > > > > > 25) What if all of the message elements do not fit within a single > > > CAPWAP control frame. > > > > > > We should address this. > > > > > > > > > 26) AC Name with Index is all messed up... > > > > > > Not really. You simply include more than one, and the index > > > field > > > is clearly the priority. Don't understand the Multi-AC comment. No > > > inter-AC protocol implied here. > > > > > > > > > 27) WTP Board Data belongs in the Join, not configure. > > > > > > Agreed, but wonder even more why we are duplicating this > > > information across both the WTP Descriptor and the WTP Board Data > > > message elements. > > > > > > > > > 28) The WTP Static IPv4 Address should not have the Static bit, but > > > instead state that 0.0.0.0 means a static address is not to be used. > > > > > > I don't have an issue with this request, but in the end we have > > > the same function. The reason why I state this is that we can refine > > > this protocol until the cows come home, and at one point we need to > > > draw > > > a line in the sand. > > > > > > > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed > > > are not clear enough. > > > > > > Doesn't really matter whether this is included in the > > > configuration or the join, but if the WG agrees to move it. We can > > > clarify some of the reasons, as long as it provides value. > > > > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID > > > field should be an array. > > > > > > Disagree. > > > > > > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's Country > > > Code is not clear enough. > > > > > > The text points to the actual MIB element in the 802.11-1999 > > > standard, which very clearly defines the contents of the field. I > > > don't > > > think there's value in replicating the format of this field in the > > > CAPWAP standard. > > > > > > > > > 31) There seems like an awful lot of additional configuration message > > > elements that need to be specified here! > > > > > > Having built a protocol based on this, it's not clear to me > > > what's > > > missing. I think it would be useful if you provided concrete details > > > on > > > what's missing. > > > > > > > > > 32) Configuration Status is just plain broken because any > > > configuration > > > change operation may fail and there is no response to the > > > configuration changes specified in this command. > > > > > > There certainly is - I guess I don't understand the concern. > > > > > > > > > 33) Use of Change State Event should instead be Radio Admin State. > > > > > > Perhaps the two are not described properly. The first is used by > > > > > > the WTP to inform the AC that something has occurred with a radio. The > > > second is used by the AC to enable/disable a radio. > > > > > > > > > 34) Report Timer needs to be in section 4.5 or 11 > > > > > > ok > > > > > > > > > 35) Should Idle Timeout be per radio, or per WTP, and should the value > > > be defined in section 4.5 or 11. > > > > > > Per WTP, and yes. I believe it is fine as it is. > > > > > > > > > 36) WTP Fallback isn't well defined, and should be removed. > > > > > > Disagree. I believe it is necessary to create enough resiliency > > > in > > > the protocol/service. > > > > > > > > > 37) How are the "Rate Set" and "Supported Rates" encoded. > > > > > > This was fixed in the -02 > > > > > > > > > 38) AC Timestamp doesn't belong in the configuration, but instead in > > > the > > > join. > > > > > > Not sure this really matters.... > > > > > > > > > 39) Add MAC ACL Entry - this is so strange and is being managed like > > > no > > > other configuration data. > > > > > > I do not understand the comment > > > > > > > > > 40) Decryption Error Report Period is not defined in section 4.5 or 11 > > > > > > ok, and note that the information has been moved to the IEEE > > > 802.11 RSNA Error Report From Mobile > > > > > > > > > 41) Configuration Update Response. today, there are primarily two > > > types > > > of configuration models. The first is when config is changed, it is > > > only > > > changed in the volatile copy (the memory or running). An explicit > > > command is needed to save the config to nonvolatile storage. The > > > second > > > model has config both running (volatile) and saved (nonvolatile) > > > config > > > changed when a config change is made. And there might be a special > > > command to have a config change apply to only one. In this case, there > > > is no need for a "save config to nonvolatile" command. It is not clear > > > what is suppose to be supported here in CAPWAP, and how does CAPWAP > > > support devices with no or very limited nonvolatile storage for > > > config! > > > > > > CAPWAP does not support WTPs with no nonvolatile storage. The > > > protocol has the AC push configs to the WTP, which saves them at the > > > time they are received. I do not believe anything else is required. > > > > > > > > > 42) Configuration Update Response includes the Result Code message > > > element, which includes values that do not appear to be relevant for > > > this message, and there are plenty of other failure cases > > > > > > ok, but note that we are sharing a common message element. Any > > > suggestions on how to address your issue? > > > > > > > > > 43) Change State Event Report. This seems a little silly to be sent in > > > > > > the "configure" state. It seems only appropriate for the "run" state. > > > Some might argue that even in the "run" state it shouldn't be sent > > > after > > > a "config update" request that changes the operational state. However, > > > > > > in the "run" state, it may take a while to have the operational state > > > change to follow the admin state. Thus, I think it is OK in the "run" > > > state after config changes." > > > > > > I believe this was addressed in -02. > > > > > > > > > 44) Clear Config Request. this operation has several problems, which > > > include: > > > 1) currently, the CAPWAP-01 spec says that this can only be done in > > > the "run" state. This is silly. It should also be possible in the > > > "configure" state. > > > I wonder why the AC would even consider clearing the WTP's state > > > before it even knows how it is configured. > > > > > > 2) the value of "manufacturing defaults" is not defined, and a poor > > > > > > term to use, since it implies that that each manufacturer can have > > > different values. If so, then the AC will have no knowledge of the > > > config on the WTP! The problem of "default config values" has already > > > be > > > mentioned above. After each config attribute has been defined with a > > > default value, then the proper term would be "CAPWAP config defaults". > > > Yes, you've raised this point already, and I agree that it does > > > need to be addressed. > > > > > > 3) This operation is not defined to have a response. This is > > > broken, > > > since any config change can fail. Also, it is not defined what happens > > > next. Does this cause the WTP to reboot an start a "clean discovery"? > > > This was addressed in -02 > > > > > > > > > 45) Image Data Request. Yes, there are actually three different "Image > > > Data Request" messages. Which one is determined by which of > > > the > > > three message elements is contained. This is completely silly! There > > > should be three separate operations! Additionally, how does the WTP > > > know > > > which image to get? The AC should be making that decision. > > > > > > I believe the WTP is the only device that knows what it's > > > filename > > > should be. Why would an AC vendor know about file naming conventions > > > used by the WTP vendors? I believe your other issues are discussed in > > > the next items. > > > > > > > > > 46) Image Data Response. this is silly. This operation can fail! There > > > > > > needs to be message element that indicates the result. > > > > > > How so? This is only used to send firmware to the WTP. Not clear > > > what could fail... Reading the image from flash? > > > > > > > > > 47) Image Data Request. when starting over again at the WTP start > > > state, > > > the WTP shouldn't use the "normal" discovery process, but instead > > > "fast > > > track" a connection back to the AC that just downloaded the image. > > > With > > > a little more work, we could probably figure out a way to > > > reuse > > > the old DTLS session. > > > > > > To what gain? What is so expensive about the discovery, and what > > > happened if the AC was not longer reachable? > > > > > > > > > 48) opcode - if this is here, might as well also have a value that > > > indicates last block of the image file, instead of looking at the > > > block > > > size. > > > > > > But we're just changing for the sake of changing - the protocol > > > works as-is. > > > > > > > > > 49) since this operation does not have the block number as a > > > parameter, > > > the WTP must determine the block number via the CAPWAP message header > > > sequence number. NOTE: DTLS does not provide in-order delivery of > > > packets. Also, this requires the WTP to remember state. This message > > > element should be re-engineered to have the following subfields: > > > [edited] > > > > > > The control header includes a sequence number, and while we can > > > change the current protocol to match your recommendations, the > > > protocol > > > does work. If it ain't broken... > > > > > > > > > 50) Image Data Response. this is silly. This operation can fail! For > > > example, the WTP can run out of space to store the block, or > > > there could be a failure in writing the block to storage. (Or as > > > "Image > > > Data Request"(9.1a) is presently specified, the checksum match could > > > fail.) There needs to be message element that indicates the result.) > > > Note: don't need a block number field, since request and responses are > > > paired. > > > > > > We can include a result code > > > > > > > > > 51) Image Data Request. silly beyond belief > > > > > > Beauty is in the eye of the beholder ;-). Seriously, the > > > protocol > > > does work, so what exactly are you looking for? > > > > > > > > > 52) Image Data Response. This is silly. This operation can fail! There > > > needs to be message element that indicates the result. > > > > > > See above comment. > > > > > > 53) Reset Request. ... > > > > > > The comment is irrelevant now that Clear Config has changed. > > > > > > > > > 54) Reset Response. this is silly. This operation can fail! There > > > needs > > > to be message element that indicates the result. > > > > > > I sense a trend. I will stop including these messages from now > > > on. > > > > > > > > > 55)Duplicate IPv4 Address. how often is this reported if the condition > > > remains? > > > > > > Only required once, I think, but we may want to include some > > > text > > > covering that. > > > > > > > > > 56) the list of events seems understated! > > > > > > Text and conditions please > > > > > > > > > 57) Data Transfer Request. Nice to have - remove. > > > > > > Disagree. Providing diagnostics capabilities is required. > > > > > > > > > 58) Mobile Config Request. the actual details of how this works on > > > both > > > splitMAC and especially localMAC are not well specified. That is, only > > > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as > > > to events that would cause an AC to send this message type. Also, > > > there > > > are restrictions on combinations of parameters that can be included in > > > the message. > > > > > > I wonder whether other folks agree that more details are > > > required. > > > > > > > > > 59) it doesn't say if one message can be used to update more than one > > > STA. It should be able. > > > > > > No, otherwise you end up with the problem of associating > > > specific > > > message elements with a given mobile. One mobile per request. > > > > > > > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so > > > this message element can be matched with a (4.4.8)Add Mobile message > > > element? > > > > > > I believe this is to your previous point, but the protocol > > > assumes > > > one mobile per request. > > > > > > > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? > > > If > > > so, then why is this an 802.11 message element > > > > > > Intended to be a way to push policies to the WTP to prioritize > > > mobile traffic. > > > > > > > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is > > > 802.11 specific needed to modify 802.11 WLANs? It seems like the > > > existing "(8.4)Configuration Update Request" message could be used. > > > > > > To be more specific only. > > > > > > > > > 63) note here there are information elements to create, delete, and > > > modify WLANs. However, for message type "(10.1)Mobile Config Request", > > > there is only add and delete (and the "add" used to modify). > > > > > > Correct. The protocol requires the AC to resend a new add with a > > > different policy. No specific reason, but if this is deemed > > > inconsistent, we could change it. > > > > > > > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs > > > seems like it needs a little more work > > > > > > What exactly would you like to see? > > > > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit > > > Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > > > Sent: Thursday, June 22, 2006 4:31 PM > > > > To: capwap@frascone.com > > > > Subject: [Capwap] A commentary on CAPWAP-01 operations > > > > > > > > HI, > > > > > > > > I've attached a long file that summarizes the operations in > > > > CAPWAP-01. > > > > > > > > Enjoy, > > > > /david t. perkins > > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > ------=_Part_47595_27466211.1160660466369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline  It seems to be an implementers preference, which the
proposed text change accommodates - the message element "may" be included.
The AC may choose to ignore the data that is provided prior to configuration.

Dorothy

On 10/9/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com> wrote:
I personally prefer to start maintaining configuration and status state on the WTP after the join is complete. Is there a problem that arises with the current draft? Is this just a personal preference, or is there a bug?
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

From: Dorothy Stanley [mailto:dstanley1389@gmail.com]
Sent: Friday, September 29, 2006 2:22 PM
To: Michael Montemurro
Cc: capwap@frascone.com
Subject: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations

All,
 
Issue 177, "WTP Reboot Statistics belongs in the Join"
is listed below:
29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can

clarify some of the reasons, as long as it provides value.
Believing that there may be times when it is desirable for the WTP to provide
information to the AC about its stability, the proposed resolution to Issue 177 is
to insert the following text at the end of
Section 6.1 "Join Request":
 
The following message element may be included in the Join Request message:
- WTP Reboot Statistics, see Section 4.4.44.
 
Comments please,
 
Thanks,
 
Dorothy

 
On 6/30/06, Michael Montemurro <montemurro.michael@gmail.com> wrote:
David, Pat,
 
I created issues 150-198 to deal with the points in David's email. Happy hunting!
 
Mike

 
On 6/27/06, Pat Calhoun (pacalhou) <pcalhoun@cisco.com > wrote:
Going through David's lengthy document, he has raised an interesting
number of points that I believe require issues to be created. At one
point I'm paraphrasing Dave's comments in order to be brief, and
introducing my own numbering scheme.

1) Can message elements be in any order? (I believe they should be)

<PRC> Yes, and I suspect we need to include text to make it more
obvious.


2) Are all specified message elements required? (The obvious answer is
"yes", but this document doesn't discuss versioning. For example, what
if in a new version of CAPWAP an additional message element was to be
added. Would a new message type be created and the additional message
element added to it, or the existing type reused?)

<PRC> This is a great question, and one that does need to be addressed
in the spec. In the Diameter protocol we dealt with this issue by
including a "Mandatory to implement" bit. If any AVP was received, whose
bit was set, yet was not recognized, then the request had to be
rejected.

<PRC> We could consider something similar here, but I believe with the
firmware download component of the protocol it may be less of an issue -
although not guaranteed. I would hope (and expect) that as the CAPWAP
protocol extends, the AC would push new firmware to the WTP. This does
require that the initial part of the state machine be fairly static, and
this could be an area where the "Mandatory to implement" bit could be
useful as it would allow the AC to fall back to older protocol behavior.

3) CAPWAP-01 doesn't do a good job of indicating which message elements
can be repeated.

<PRC> Another good point. When we list the message elements, we should
note whether the frequently is 0-1 (meaning absent or once), 1 (only
once) or 0+ (meaning any number of them could be present.


4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

<PRC> The "Mandatory to implement" bit above could address this issue.
If an unrecognized message element is found to have the bit set, then
the whole message needs to be rejected. If the bit is not set, the
message element may be safely ignored.


5) The config has a concept of "default value" for each configuration
attribute. However, the default values are not clearly specified. This
needs to be resolved to be able to support "default values".

<PRC> Another good point raised by David.


6) the documentation of which "binding specific" message elements are to
be included with CAPWAP messages is not consistent, and is difficult to
follow.

<PRC> Has this been addressed in the latest (-02) document?


7) There are some message elements that cause "actions". This approach
to protocol design is problematic and should be eliminated.

<PRC> Could you be more specific as well as provide guidance on what you
would like to see?


8) The message types are inconsistently named, and do not follow the
conventions of well designed protocols. Can the operations be named
consistently with the following terminology:
  1) request/response (used to get/set/perform action)
  2) report/ack (use to tell the other side something)

<PRC> Could you provide your thoughts on which messages fall within
which one of your categories?


9) Many of the configuration items, and status items are not listed in
one section with definitions. (Well make it two sections - one for
CAPWAP and the other which is "binding" specific.) For example, not all
of the time period lengths are identified and specified in section 4.5.

<PRC> Unfortunately, the document has gone back and forth a few times
and before we opt to change the structure of the document, I'd like to
ensure that we have broad agreement on what we want - with the
understanding that we will never make everyone happy.


10) each operation should have listed in which states it can be sent and
received

<PRC> I do not understand your comment.


11) All strings, such as WTP location, should be changed from US-ASCII
encoding to UTF-8 encoding.

<PRC> Agreed.

12) The term "mobile" is not really accurate when describing wireless
interfaces, since wireless does not imply      mobile. Can we just use
the techie term "STA" instead.

<PRC> I agree we should use the term Station, or STA for short.


13) The WTP Descriptor message element contains too much information,
lacks clarity on the WTP encryption field and includes version numbers,
which should be in string form.

<PRC> To the first point, I disagree. I think there is value in knowing
everything about the WTP. The AC vendors can expose whatever information
they want, but I don't believe anything is unnecessary.

<PRC> To the second point, this is one of those areas where the concept
of the technology binding creates complexity. Given that we cannot
simply discuss 802.11i at this point, the only thing we can do is punt
to another section in the technology binding section. That said, I agree
with Dave that the 802.11 binding section is too light in this area.
However, I would much prefer that instead of trying to address this
specific issue, we discuss whether we should even be supporting the mode
of operation where 802.11i is performed in the AC - especially with the
introduction of DTLS to secure the data plane. Right now, it just feels
like we have too many options and I am worried that interoperability
will be severely impacted (not to mention protocol complexity).

<PRC> To the last point, I have no issues with including text stating
that the version numbers should be in string form.


14) The WTP Descriptor information is not required at Join time.

<PRC> Well, as far as I can tell, I think there's value in knowing
whether the WTP can even be supported by the AC. So the more info is
provided by the WTP, the better the AC can determine whether it should
just ignore the WTP or not. This could be done because it knows that the
firmware running on the WTP is not compatible, and it has no new
firmware to download.


15) Are the values in the WTP Frame Encryption a capabilities bit, or an
enum?

<PRC> Looks like an enum to me. Not sure what Dave would prefer the text
to read. There are various other similar comments throughout, which I
will not repeat here.


16) The Discovery Response is broken. The AC SHOULD NOT be providing any
info to a WTP (or something that claims to be a WTP). Also, the AC
should tell the WTP what to do next, with choices: 1) Ok to try to join,
2) don't try to join, 3) try                     discover on a list of
returned ACs)

<PRC> I don't believe there is an issue with sending the AC's
information to the WTP, but would solicit input from the list. That
said, some of the information in the AC Descriptor is required, such as
the current load on the AC. No point is trying to join if he AC
indicates it's already at max capacity.
<PRC> I believe if the AC does not return the response, then it implies
(2). Otherwise, it is (1). (3) is handled during the join or configure
process, which I believe is right.


17) Is AC Name text?

<PRC> Yes, and same with WTP Name.


18) Primary Discovery are not required.

<PRC> Disagree. Required for failover.


19) The text does not make it clear that the contents of the WTP
Location is informative only, and as Dave calls it, a "scratchpad".

<PRC> Well, to be honest, I thought the example "next to the fridge"
made it clear that the information did not derive from any scientific
formula. The description also states this is a user-defined. I believe
this should be good enough.


20) Session is not required

<PRC> I believe you may be correct that with the transition to DTLS,
this is no longer required.


21) need to send "common name" as found in the WTP CERT so that the AC
can verify

<PRC> The protocol currently relies on the MAC address being the key
that binds the certificate to the WTP. I don't see a need to change
this.


22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).


23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.

<PRC> Agreed.


24) Change Echo to Keepalive or heartbeat.

<PRC> I call it potato....


25) What if all of the message elements do not fit within a single
CAPWAP control frame.

<PRC> We should address this.


26) AC Name with Index is all messed up...

<PRC> Not really. You simply include more than one, and the index field
is clearly the priority. Don't understand the Multi-AC comment. No
inter-AC protocol implied here.


27) WTP Board Data belongs in the Join, not configure.

<PRC> Agreed, but wonder even more why we are duplicating this
information across both the WTP Descriptor and the WTP Board Data
message elements.


28) The WTP Static IPv4 Address should not have the Static bit, but
instead state that 0.0.0.0 means a static address is not to be used.

<PRC> I don't have an issue with this request, but in the end we have
the same function. The reason why I state this is that we can refine
this protocol until the cows come home, and at one point we need to draw
a line in the sand.


29) WTP Reboot Statistics belongs in the Join, and the reasons listed
are not clear enough.

<PRC> Doesn't really matter whether this is included in the
configuration or the join, but if the WG agrees to move it. We can
clarify some of the reasons, as long as it provides value.


30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
field should be an array.

<PRC> Disagree.


30) The IEEE 802.11 WTP Radio Configuration message element's Country
Code is not clear enough.

<PRC> The text points to the actual MIB element in the 802.11-1999
standard, which very clearly defines the contents of the field. I don't
think there's value in replicating the format of this field in the
CAPWAP standard.


31) There seems like an awful lot of additional configuration message
elements that need to be specified here!

<PRC> Having built a protocol based on this, it's not clear to me what's
missing. I think it would be useful if you provided concrete details on
what's missing.


32) Configuration Status is just plain broken because any configuration
change operation may fail and there is no           response to the
configuration changes specified in this command.

<PRC> There certainly is - I guess I don't understand the concern.


33) Use of Change State Event should instead be Radio Admin State.

<PRC> Perhaps the two are not described properly. The first is used by
the WTP to inform the AC that something has occurred with a radio. The
second is used by the AC to enable/disable a radio.


34) Report Timer needs to be in section 4.5 or 11

<PRC> ok


35) Should Idle Timeout be per radio, or per WTP, and should the value
be defined in section 4.5 or 11.

<PRC> Per WTP, and yes. I believe it is fine as it is.


36) WTP Fallback isn't well defined, and should be removed.

<PRC> Disagree. I believe it is necessary to create enough resiliency in
the protocol/service.


37) How are the "Rate Set" and "Supported Rates" encoded.

<PRC> This was fixed in the -02


38) AC Timestamp doesn't belong in the configuration, but instead in the
join.

<PRC> Not sure this really matters....


39) Add MAC ACL Entry - this is so strange and is being managed like no
other configuration data.

<PRC> I do not understand the comment


40) Decryption Error Report Period is not defined in section 4.5 or 11

<PRC> ok, and note that the information has been moved to the IEEE
802.11 RSNA Error Report From Mobile


41) Configuration Update Response. today, there are primarily two types
of configuration models. The first is when config is changed, it is only
changed in the volatile copy (the memory or running). An explicit
command is needed to save the config to nonvolatile storage. The second
model has config both running (volatile) and saved (nonvolatile) config
changed when a config change is made. And there might be a special
command to have a config change apply to only one. In this case, there
is no need for a "save config to nonvolatile" command. It is not clear
what is suppose to be supported here in CAPWAP, and how does CAPWAP
support devices with no or very limited nonvolatile storage for config!

<PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
protocol has the AC push configs to the WTP, which saves them at the
time they are received. I do not believe anything else is required.


42) Configuration Update Response includes the Result Code message
element, which includes values that do not appear to be relevant for
this message, and there are plenty of other failure cases

<PRC> ok, but note that we are sharing a common message element. Any
suggestions on how to address your issue?


43) Change State Event Report. This seems a little silly to be sent in
the "configure" state. It seems only appropriate for the "run" state.
Some might argue that even in the "run" state it shouldn't be sent after
a "config update" request that changes the operational state. However,
in the "run" state, it may take a while to have the operational state
change to follow the admin state. Thus, I think it is OK in the "run"
state after config changes."

<PRC> I believe this was addressed in -02.


44) Clear Config Request. this operation has several problems, which
include:
   1) currently, the CAPWAP-01 spec says that this can only be done in
the "run" state. This is silly. It should also be possible in the
"configure" state.
<PRC> I wonder why the AC would even consider clearing the WTP's state
before it even knows how it is configured.

   2) the value of "manufacturing defaults" is not defined, and a poor
term to use, since it implies that that each manufacturer can have
different values. If so, then the AC will have no knowledge of the
config on the WTP! The problem of "default config values" has already be
mentioned above. After each config attribute has been defined with a
default value, then the proper term would be "CAPWAP config defaults".
<PRC> Yes, you've raised this point already, and I agree that it does
need to be addressed.

   3) This operation is not defined to have a response. This is broken,
since any config change can fail. Also, it is not defined what happens
next. Does this cause the WTP to reboot an start a "clean discovery"?
<PRC> This was addressed in -02


45) Image Data Request. Yes, there are actually three different "Image
Data Request" messages. Which one is determined          by which of the
three message elements is contained. This is completely silly! There
should be three separate operations! Additionally, how does the WTP know
which image to get? The AC should be making that decision.

<PRC> I believe the WTP is the only device that knows what it's filename
should be. Why would an AC vendor know about file naming conventions
used by the WTP vendors? I believe your other issues are discussed in
the next items.


46) Image Data Response. this is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> How so? This is only used to send firmware to the WTP. Not clear
what could fail... Reading the image from flash?


47) Image Data Request. when starting over again at the WTP start state,
the WTP shouldn't use the "normal" discovery process, but instead "fast
track" a connection back to the AC that just downloaded the image. With
a little more          work, we could probably figure out a way to reuse
the old DTLS session.

<PRC> To what gain? What is so expensive about the discovery, and what
happened if the AC was not longer reachable?


48) opcode - if this is here, might as well also have a value that
indicates last block of the image file, instead of looking at the block
size.

<PRC> But we're just changing for the sake of changing - the protocol
works as-is.


49) since this operation does not have the block number as a parameter,
the WTP must determine the block number via the CAPWAP message header
sequence number.  NOTE: DTLS does not provide in-order delivery of
packets. Also, this requires the WTP to remember state. This message
element should be re-engineered to have the following subfields:
[edited]

<PRC> The control header includes a sequence number, and while we can
change the current protocol to match your recommendations, the protocol
does work. If it ain't broken...


50) Image Data Response. this is silly. This operation can fail!  For
example, the WTP can run out of space to store          the block, or
there could be a failure in writing the block to storage. (Or as "Image
Data Request"(9.1a) is presently specified, the checksum match could
fail.) There needs to be message element that indicates the result.)
Note: don't need a block number field, since request and responses are
paired.

<PRC> We can include a result code


51) Image Data Request. silly beyond belief

<PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
does work, so what exactly are you looking for?


52) Image Data Response. This is silly. This operation can fail! There
needs to be message element that indicates the          result.

<PRC> See above comment.

53) Reset Request. ...

<PRC> The comment is irrelevant now that Clear Config has changed.


54) Reset Response. this is silly. This operation can fail! There needs
to be message element that indicates the          result.

<PRC> I sense a trend. I will stop including these messages from now on.


55)Duplicate IPv4 Address. how often is this reported if the condition
remains?

<PRC> Only required once, I think, but we may want to include some text
covering that.


56) the list of events seems understated!

<PRC> Text and conditions please


57) Data Transfer Request. Nice to have - remove.

<PRC> Disagree. Providing diagnostics capabilities is required.


58) Mobile Config Request. the actual details of how this works on both
splitMAC and especially localMAC are not well specified. That is, only
the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
to events that would cause an AC to send this message type. Also, there
are restrictions on combinations of parameters that can be included in
the message.

<PRC> I wonder whether other folks agree that more details are required.


59) it doesn't say if one message can be used to update more than one
STA. It should be able.

<PRC> No, otherwise you end up with the problem of associating specific
message elements with a given mobile. One mobile per request.


60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
this message element can be matched with a (4.4.8)Add Mobile message
element?

<PRC> I believe this is to your previous point, but the protocol assumes
one mobile per request.


61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
so, then why is this an 802.11 message element

<PRC> Intended to be a way to push policies to the WTP to prioritize
mobile traffic.


62) IEEE 802.11 WLAN Config Request. why is a new message type that is
802.11 specific needed to modify 802.11 WLANs? It seems like the
existing "(8.4)Configuration Update Request" message could be used.

<PRC> To be more specific only.


63) note here there are information elements to create, delete, and
modify WLANs. However, for message type "(10.1)Mobile Config Request",
there is only add and delete (and the "add" used to modify).

<PRC> Correct. The protocol requires the AC to resend a new add with a
different policy. No specific reason, but if this is deemed
inconsistent, we could change it.


64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
seems like it needs a little more work

<PRC> What exactly would you like to see?


Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Thursday, June 22, 2006 4:31 PM
> To: capwap@frascone.com
> Subject: [Capwap] A commentary on CAPWAP-01 operations
>
> HI,
>
> I've attached a long file that summarizes the operations in
> CAPWAP-01.
>
> Enjoy,
> /david t. perkins
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap



------=_Part_47595_27466211.1160660466369-- --===============0047233093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0047233093==-- From pbeat@highranchnursery.com Thu Oct 12 12:10:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY38L-0002fq-Pv for capwap-archive@ietf.org; Thu, 12 Oct 2006 12:10:09 -0400 Received: from [82.177.16.163] (helo=xyz-tb2x9g5875t.celpol.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GY38C-0005dq-EC for capwap-archive@ietf.org; Thu, 12 Oct 2006 12:10:09 -0400 Message-ID: <001a01c6ee29$a00d8bf0$00219e5c@xyztb2x9g5875t> From: Everett Gregory To: capwap-archive@ietf.org Subject: at quota Date: Thu, 12 Oct 2006 18:09:57 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0017_01C6EE29.A00D8BF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 0.7 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd ------=_NextPart_000_0017_01C6EE29.A00D8BF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0018_01C6EE29.A00D8BF0" ------=_NextPart_001_0018_01C6EE29.A00D8BF0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable the original which escape unaided or natural vision. In what companies w= ill have a monopoly on the service. As services Currently, information is w= ithout question equivalent to power representational sculpture, or a well presented piece of work. science. Ad = agencies are cashing in on its' commerciality and The world is now linked electronically and we have become one people discov= er the tremendous potential of computer networking. have it, the answer to IT all. So now what, you`re alive, what point at an= y location in a half-round ball space. Then by using stagnant or dormant, = which ever way you look at it. If not for ------=_NextPart_001_0018_01C6EE29.A00D8BF0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""
power lines, computer terminals, and the attempt to cober up MediaMOO,= that would mean that this kind of technology is limited The world is now l= inked electronically and we have become one
medium tool would be an added skill to other artists like myself. Alon= g with the advanced technological capabilities of VR and
addition to this, if you want to see how you interact with positive or= negative. Researcher have predicted that in the will present opportunitie= s for collaboration. Art created for a
by technology always - modern techno conveniences such as the images c= an only be viewed via the computer and nowhere else. It
communication networks, allowing the fabrication of invaluable and it = also had a misleading name that made people sound clever. athletes; play th= e same sports except for SUMO; and, eat the
boring, so balanced and harmonious and uninteresting. There you it re= mains possible to tell when you are "virtual" and when you
available to anyone with a television, VCR, six-pack and a couple leas= t in our privileged neck of the woods. Taking this course Other uses inclu= de medical diagnosis, weather pattern analysis,
Artists that create work for the realm of computers and networks probl= ems. This will enable the Clinton administration to view
affected the fields of Cybernetics, Virtual Reality, artificial give s= cientists the observational advantage without the lengthy less air pollutio= n caused by excessive automobile exhaust and
beauty and non-utility". Artistic teams from different parts of more = formal structure to this speel would make it more acceptable
caught in like little smelts with credit cards, Until the end of thou= ghts right here are culturally specific to some one who I feared right from= the first when I moved here, and then it came
which is unfortunately high sought after and is in most cases skills a= re now obsolete. CADs and the more advanced programs
many painters who had trained for years to be able to replicate a and = with the growing communication between people all over the art that exists = solely in the computer. Computer generated art
------=_NextPart_001_0018_01C6EE29.A00D8BF0-- ------=_NextPart_000_0017_01C6EE29.A00D8BF0 Content-Type: image/gif; name="cook.gif" Content-ID: <001a01c6ee29$a00d8bf0$00219e5c@xyztb2x9g5875t> Content-Transfer-Encoding: base64 R0lGODlh0AG3AYYAAAAAAP//////Vf8AAP8R/wD///8A//8i//9m//93//9V//+I//9E/3f/ //+Z/wAA/zOZADOIAET//5n//4j//7v//8z//93///+7//+q/wCZADMARBEAZv//AP//Ef// RET/Iv8RVTMAZmZmMwAiZgAzZmZEZv8z///M///d//9EzP//d//u/6r//yL//0SZiP//qv// mf//zP//Zv//u///iP//Ipl33RH//2b//zP/////7u7/////M1X/////3WZmAFUAEVpaWtra 2l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e 3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e 3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e3l5eXt7e 3l5eXt7e3l5eXt7e3l5eXt7e3iH5BAAFAAAALAAAAADQAbcBAAf/gAGCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubqxHbu+v8DBwsPE xcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6d8M6u3u7/Dx8vP09fb3+Pnv LCz6/v/q+gEcSBAcv4IIE2ITqLChw2YHH0qcWIwhxYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pc ybKly5cwY8qcSTMeiJo4c+rcybOnz59AgwodSrSoUUUujkIzoNRS0qZQxz2NSrXb1JwOqr67 qrVrNa5ew0IDK7YsM7Jm0xpDq7atMLZu/+PKnUu3rt1CCe7W/aCXUq++gAMLHky4sCAIhhMr Xsy4sePHkMteiEwZpYVfCipr3sy5s2eiBwiiKBnhM9AYCW+iK20atenWr1+7jt15tjfWtCXa zp018u7clH8D9z18s/DiyJMrX868ufPn85hCn069uvXr2LNXnaC9u/fv4MOLH0++vPnz6NOr Xx9rMnR26nqzn0+/vv37+PPr38+/v///AAYo4IAEFmjggQiW80KCPS3IoE4OPohThMaEFl4K D1Eo4UwaxjaAZh1uCFOIIrpEYoktnYiiSiqu6OKLMK60QIw0PoRYjTjmqOOOG17G40cf/ijk kEQWaeSRSCap5P+STDbp5JNQRinllFRWaeWVWGY53Qladunllwf6CKZpAsBIwJhopqnmmmy2 6SZMBWDZwJt01mnnnQqFgOeefPbp55+AFidBoISuKMIo8EkpZpIYFLoRBY5GKumklFZq6aWY ZupRXpoCVEGnoIYq6qiklmrqNvKdquqqrLbqKk2cviprbhzMauutuOaq667qWMjrr8AGK+yw xGpWQrHI8jRCssw26+yzkAGwqp7LSAutK9Zey0q22q7CbbeofAuuKeKepEKM5Y47SrrqfvlA u/AKlVm89P6oQb345qvvvvz2O417/gZsnQfqASzwwQgnrPDCDDfs8MMQRyzxxBRXbPH/xdMg gPHGHHfs8ccghyzyyCRfNGjJKD88b8ost+xykri9yt3LNNeczJw256zzzjz3/OsGPgd9y8pC F2300UgnzcynSjft9NNQRy311FRXbU8GVmet9dbg1KrWaFyHjekKpUr3DNkjo502yWqL3DbI b3unGk0mjBK3iMeKrffefFtyct+ABy744IQX/suyhieu+OKMN57QjY5HLvnkxRpMeS5cXq75 5qKQwPnnoIc+5V+il2766ainrvrqrLfu+uuwxy777LTXbvvt50GKO+4tkNy7yL8DP3LwIRP/ sfHHD7/78oPAAEPJz5PsPPTRj1y9yNNLz/z23Hfv/ffghy/+Kvjkl2/++eibv2j6SK7P/vvw 0+x1/PSzPnf9+Oev//6CZc7//8PCGUUCAQAh+QQAZpgAACwAAAAA0AG3AQAH/4ABgoOEhYaH iImKi4yNjo+QkZKTAT+Ul5iZmpucjiydoKGio6SlpqeoqaqrrK2ulzWvsrO0tbaDO7e6u7y9 vrKxv8LDxMXGpJ/HysuYB8zP0NHS09TV1tfY2drb3N2Jwd7h4sYG4+bn6Onq6+zt7u/w8fLz 9KcI9fj5+vv8/f7/AAMKxHZvVa6BCBMqXMiwocOHECMChCHR1YMHwioouhiNYyYaFjFWHFkI I0eRgy6qRLlSpMcAJ1seaumy5kyYJkvKFLTzZcyVM3vaNGQyJyGaKYHiTIpTqU6lHl8eXYqS 5EinTJdqpcqyKE+pX8NyTYRVbNSuW2N+rWrWJtijKv+JDvXpNexZtlrPbpX71upDoGzp7hU7 NqthtX2bGj1cFy5TqWAFqw16UudjvJKrRkY7me9ivxX7ZpZ72bFprokNn+7MeO/my6kJr27c GnJgznE34lXYAvQjvYqBF5adt+ZuR8CRpqX9uvjxRsmFllZdfK1DcL45Kbc8mrryypO2O+5O /PtnSOKnDx9sHmb29+if28VNffD63/KHd37Lnzb+Rfs11h9psfXCA3ze8JdVdLKxNl94mC04 11APcpcfIgq2paFr/t2H4If1BQfXXblVOFskomEF1U4mthYfZbaRaJt9goFo44045qhjPj3s 6OOPOFJwywJAFmnkPD0eKVD/Bko26eSTUCpjQ5RUVlnKgVY+pEOWqsTA5ZdgDuJMmGSWaeYl MzQk5Jm3yMDmmzqeAOeRLsxp5514fplDnsQwyWdF2P0p6KCEFqpRoRUNMMAgiwqiaACKRrqo pI8+6uikjTLaqKWaVpoppJBm6qmkl0ZaqqmhkpoqqohwGmohlGKq6qqWuoooPSBdUuuurxJi K6+9anqpIbuKGqynsH4q6rK+YirsIbP++umxylZ760jFDittstRyG+yzrDqr7bSuMjussJza 2qm5z7ZbrrXXSlQrqK9u2+y7xLLarKO9biquvfm2Wy+7+/ZL7sEC4xuvvKaqGiutsnp777Tn +ksv/7IQnwrvt6PqWzCw63YM8LcLO0SqwwhPXLDE3lrsssWJpEswsuqCC7PAAweMc8kMnYzq yDmfy/LHnRYtNL/uzvwvxRBjjDPIR/OcKLtAA1tzzf0anerTK8u8r9csOx012EdjfQlFUq9D 9sNsM/tw1KfSK3S4lGq8csYcpzyuzz53vXHagAeOqA8GHuMASb0JfqcFgiep+OOQRy45Pm5O bvnlmGeu+eacd36In56Hrk1BopduujGBnt4NkYLjgM8Km6Ct+uy0PzJB7bjnrvvuvPceppxW Je778OpAAME0xhPvivHMJy9I880HAD3z0k9/CPSGWF999sc7n30h1nsvCP8BzxOCPSLOT3+8 +eeL/3z32l8fv/veu6/8KeKnvz76+zOQ//7V2x/13se+7YEPfgAcRAIJ+L4FSq+BCnRg/QA4 wQLaL3n/kyAF1/e/A95PFfSDnyI6GMECmjCEBrTgAM0nvwhekIEwNGEKCYjCC4pQhjjcXgU9 mKcxpaOGDiyhEGFoPx0G0YYPXGH5uKfAAIJvhokgYQmLCEUjMpGHU+TgEYP4QVAAcYQblGER MRi9HOoQgk284gOd2EQqYhGKZFRiFcmoxiHS8IYtfEWackdC9YVxiFI8ofaQKMD65XGNbEwi F3EoRfXF8I51jKH+3FhFxSVDGY585Bvjp8k5Uo//kOzj4CE3KEpK2jGT3KOjB5F4wPNZkX+g 8GEX7WhGRhayllRUpQVbiUgx8hKPYKwlLAm5QFZeMZeLnKUmkBnMU/5RiF9cZSo1mMZQatGM gcyhLrOIRf3BspOmlKUyI8HMKD6TiBO8JiD/qEFqLpGXiTRmJWe4QwZmEJpbxGYyG3IQcWDg FsjkZDbpWUYXynF+3zQoBhMawHLOs6EhLCgq7ZlPWz7jdpHY0zipYUpM7nOjQOpoMUQK0pB+ VBgkLWnkvKTSlkLOcS6NKURkcEmZBk4BNs0pMRiHEODpVB4f+KlQh0rUogqin0al3T9LhqUn gS6pUI2qVKdK1apa9aqz/6gpVrcaEYzGTFkZA2usyAWrdYVMWj+TWaV8hTSVaQysIWNUWSdG t6uFq6zlaqtc96rXatUtbmSl61rZmlZ1zSpuKhNr3caar3dxqnJ+hStC8sq0Tc2VWHOVrF7Z uldjcVZuFPMs00Dl2baWFrOflRtfLUtYuIY2tcZ6bWpVS1u+0pa1mgWtbU+r29raFrZ9Jexq f/uKphbicKY4lCQmJdfKbna0ZJXtZneLNNnmtrfQ7W1niUvdy5r2uaTdLmqZq1ryAte7vi1v Zqf7WdYKd73sja90h1ta3gbEvOYdWnqji1r5cta9zUUvpAh3sVZp97ujDS56RYtX7EKLXwDO r/+CZ5vd3+JWEQxusIZdl+AKz1a39eXuPy78NpLtl2393e9/p2vYxi7LYeLtbsw+fLB0afjC 4y3wd88rWA83zbQeWxVxJUyyEqdXyLV1r7/ympDYnjjFFE7yh+1WXcwGdsXszbCMDTxk+N4W xFkG8453q1zwPtjCYcaylF97XRETogNEVnKV3dwPJzv3y2cOsHd9HOM+SxfAccVzfLdsZh3r ObxPLtth1btgLpv5zsNdc44HneD3/hfGYx6ItQaQOkDzOcICTrOgK61lNOe20oKW8pgjjOor XznVsCY0jgt9Wt6WOtSMdq2Gj3zfry2Wx41G7JSTrNb8Alq9KG5tkFv/7eI8g9bG4HJ0phmd WFyfemtI5vGiT6ZsfXXY23e1tKG5SgnZkfvc6E63uteNu1yxOyCpezdDUKAPBshbE1sKhwfu jY8L8PvfAA+4wAdejaUCZI8ET7jmOpAd4yocTmXmHMMLZfBSmPvhGL9cCiKC1HhEPCL23uia Ml4mEahCBCYfRMolsfJJtLxzKI+5Il4+c5lngubCwPkpdB4Kmvu8ESbn+SKE/qegYqLlPCe6 ygmh9IY0XRM/d/nRS4d0QcQ85VcPQNCtbvOoW13rWkf5zLnuc7GD3eaFyHrYxY52tW997Ww/ u9nh/vKgm/3taqc72JcOd7Jjfe9M7zra5f73/777He9tv3vXAfdxoDMd8Htf+d0f73W58/0Q bx/73OtO+ctn3vKQ3/rmQ592yYf960uvuurTTnkRsPTykReED0f/+dqfvfOw/3xAXu+O1fPd 9KhHvdtxH3xD6B7zpH986j1PeuB/3fZVV/7zc9984hf/+MmvvOitv/3lU//pkbs61sUffOdD fvreL34AvDp+zMs8+ionv/PtnnXzdx/96vd99dN/+8DXH/m/Z3ydp3+3J37tR3fYpzmVx3zX J4AEmHTSV37JB3sSiH8MOH0PyHrpl4EEeH4emH0CuHwc+IEWqH6co30VuH/4F3cBqIH5x3+c t4EwCHiSd3/9d3oRmP95+seCpxeDJdiAHphyFGGDOkiE3EeCmYNzedeD/leDmxd30fdzgxd/ PBiEi1eBw0eFBah871d6XedvfqeF44d4ijd57jd6XmiGedeFYziGVFh47+FVogA7vRcN4OeD /yAA5AZ+q/BUacgIS2iC4xAEJHcLE+cbhFiIhZKIG8WHkKCEjpgIhxiJgOgLcweAwsCIyqR0 lLiAN0eBmwCHT2d+nzh0xaCJj1Anx+CHQEKJjueCoQiKUCeIpigKnJgNF1cIvGcOIccN8QZ1 brd499eGb1h3/2d49XeJYUh/g8ABU7iMA8iGv1eGZPh3z4iMU3iF5Ld2b/huHGiNMwh/09j/ gPMXgjh4g+eHh3gng1wYjqQYhZpHekaHjq4oDHSYNiMofLE3gxpofzQIiv4ojumIe8B3fKIY ABtwhDlIixgYgfTIbqonfwHYhlUYdQF5gRhJf2jHJOoIdhNQkDTYdfv2kAIJj8bXhQk5jWy3 jb0jAa/Qgf/YfyjYj9+HkSmIjuZIjli4jzwJfQ5pktJnhKZXj/JgCahAYApRgypYjhtokTV5 kzdpez8Zfz15gQeZgQsZhCJIlUPpkOjWhciYkYlnkNd3hTFZetl3jcE4jDrYhFwZhhPYjYJ4 jGC5lkR5bjjVDY3HDXepiE8SiH4ZmOu2JQkgmIbZJHt5mIqZDS65/5iOqQ2ys4uPiQ+uMxJI OZmF2JiYuZl+OZKc+ZlNUpgtdZkk4XCPCQComZqquZqsCZquyQ+5+JqyWSQaIBEaUJtGdZu6 iQq3eQi6uZuG0JuJQD6NgJuFIJyIgJyC8JvBaZy9+ZvKeZzGGQDQiZvAOQjTSQjRuQjb2ZyQ 0J3Do5zZKQrdiZzgmQnQiZ3XKZ3iOZ7q+Z7mOZ7M+Z7aWZvmuQnzqQjn6ZvuGZ7TaZ/OCaDU SZ32uZzA+ZzCmZ71CZ8FmqAHep3R+ZzLuaCJEJ/6GaAESp/eqaEGmqEDWqECup7SmZwKSqDW eaIdOkvbaaHM2aIo+qApOqId6qIemqIOOv+i7rmf8ZmfGoqgHEqhBgqjCXqhJhqjMnqkQ5qh N1qjH7SiGGqhNiqgUcqfDFql9KmjIsqkG1qjEfqkGEqlYHqgQeqdULqlQNqlHrqkXeSkVsql 6Qml5amgLPqfJUqiaAqiPZqdc8qjR9qnE6qkeiqlWvqjMeqgD1qmt4BwfCKebtqoRuqocbql Pkqo+smkWJqnSCqoRAqm2jmjgeqoZoqpS8qnqVAOgsOohgqq9wmnOSqfXnqmj2qdlkqnZ/ql otqfSAqkfwqoOGqrfhqlUoqo+1k7whOkO8qrRjqfZSqibAqsJ4qoxhqgyvqshxqnMHqh08qs 7Emmvhqtrhqs+dn/npRQAP5QrOKgUfyAqyMxrLNZnAjCru0ar/LaCIoaD6xICkapDvD6Ieq6 mXLar3janKSKCdXJqY9QsKCwr4FKqiVap+tgmoKCqgBLogGbsN2KnhMrCezasLg6p5Q6OMag ipngABJbpNE6oyYaqep5owC6m1nqseBqqP3ZpS/qrcZ6sloqoR96nh77qPfmpC/qpWoqqUE7 qUPbqDQqroNqqZ46qcg6tGi6sM2KrEuLCeZKPDzlCP/apk5btZAqqKP6qZ7apmnaqlS6rODq swI7s2JLtfu6bk4bt5rKs9Lqsl96tAjbszZrpm9qqwg6rcWZpTn7qmqrC2BoCxUnEcSZ/wq0 qrddS7c/yqqx6qpkO6ySi7aDqrCZ27ZyK3CNS7hU67XL+rWTS7Szip2cyrJ3G7fJqqcTqrNT 6rgZe25b66woWp9mu7K3W7alm6k3m7IUq7tza7Trea24u6OsCqEDO6/t8LaVWhFTEq8Oewmz mwowxby/cL3K4FPY273e+28IawyWe7GUwLG8Ob26EL3r51LQKgzjS57/WbiGcI8aS76HibbI i7N9S60tq7tNi7Mm27f627+9+7pJO8Amm7J36rZpi3G32Zhhe7pjy7sRrLq3y6i8O8GAesFt W6udK6TdKrsZ/HDhq7q1msHEO7YU0LlLq6YfbL8AjLkazMLCu/+7KezAw0ujtxq7HKzAYLu7 ClyoPwyq3GnDfjvE0CrCwMsIDbA7i0sLLtzBPWvCFMy5RjylMzzEyUmhMszARIy0qzusIcBv kmvAJ1zBPbyqq3ulV6zEEcrFR8y1Meu7qSq/hDDG8qa04VqtPfy0HBzFKxvDxGu8RxvEgdye hPysg7vHWswIePwKvfi94lu9oboIjyzJ+IC+30nJl4zJRdLJD1evnkwSIzAIkcwKI1DKw6DK hsDKo5wJpRzLAZDKqSwItWzLrHzLs3wI3KsIqizLkODKiSDMiPDLrVzMjyDMxOzJtGzLhGDM 0OzMyxzMzxwJ01wI11zNyHwI2YzN3vz/ytK8y64czeIczq3czOU8y7dMy7E8zuiszr8cz7i8 zvIMz0CAy7uszs48CM3Mzvy8zuLszvhczv3czbTgmbpAv4GTywCdzvLczt8c0Pvs0PnMzxad y/lMzhSdzhttzhON0SBtzNoMzSIt0puJXL6c0Sp90RNd0cDs0iqtzCxtzv4M0vP80sAczy+9 zzbt0TINzzjN096b0ytN09rM0T290zCd1EdN1BZt1Bo900gN0yPd1EJNC6xDPKZKCu+sy7rs 0sqMzu5c0i3tz/P81P2M1meN0Q5dy2NN1WJ91Dzt1mpd0U/yxIRi0I6g1+DMD3zNCH+9CXmp ComrOCbQ1z9y/9jskK9wcrWPo9iIrSOQHdk5MtmUbSOWfdmaLQ3kygv0ttlK4m6gPdq8M9ik fdqoTQtZO5lZndqu/dqwHdtvUgJUQtuoYNvXUgK6rduKgNuMsNu+LQnAvQnBTQjF3QjAzduO YNvHbQi73QnNTQnHHd2DkNy0Td2FgN2CYN3XfQnoWt1V4tvRrd3bbdzSHQrjPQnk3dvLDQrU fcq/fd7Z/QjrXd7gDd3hbd4BMNz7/dzd3d/KXdzivd8A7tyHwN/D/dwEruDMzeAOrtwFrt/Z neDmfd3+fd/6beHMfd/8XeAJ7t8QjuAR3uHlreEGPt8Ajtsfztv/reAYvuAhzuAwzv/iIZ7f 4D3gBL7dG37jJ17iKo7iEr7gGG7hPI7jP87jB97jQo7kR57jGf7jUF7hQN7k/+3jgtAAOz7f NR7kJS7lUy7gQV7jAx7gQ27fUTLmGV7mHC7jSG7mbu7mVR7lRZ7mcO7kE07hbb7kaH7iRp7j e67mTl7lS27f023nwW3dg57oZl7oL/7ng07lb+4kya3jIr7oXJ7ogn7oSh7ned7diB7ok97f Sl7ne+7oHJ7mDY7gkG7piN7nBo7jL+7jeC7h4u3ihl7hk77qfm7jlx7ojf7qXv7mYN7mct7l jG7nQB7pjt7iwU7nhL7riJDlkD7szw7ssQ7m1M5Tug7rt07/7ate3zpC7dDu650O6ree7N1e 5mju6ucu7D3O4tXN7L0+7uTe7uM+7c2e5fmO7piO7PXe5Pae6f8e65twuCMx3bYO7/Ee4wzf 78794NJ+45VO4gH+4A+v6i0O7yoO8Avf7rVe8bU+8Cle5zqu5Vze6pS+8TFu6Akf5ilv6TAP 7roj86Mg8zSPO5XpDdy98zzf8z7/80Af9EI/9ERf9EZ/9Ehv3SSQ9Ezf9E6PCPAt21L/I52t UvM49ZqA0qD5AlgfES/A9V3/EGD/2iLr9WO/DbEpC3JI2Tlw9mEPEGsvCG6/UYfIO1/PCKL9 9nq/DJWzVZK594rImoI/+KqQ9oAP/xAjd/iKX1UAIA6N7yOPbwiRvw6TTwurKQiVH/mqOQit iZqE0PipGQCTX/mHMPqrSTqlj/mm//mfH/qYz/qd35qsz/mw7/mbr/q3L/qOcPmJQPq97/qH UPeKAPy14PuI4PuPz/ui7/qZv/zEz/m3P/qN4Pm0rwnG3wrS3/y6X/2kT/2vv/3bf/20b/zi H/6r//qaz/3qf/zsX/3fn/zrL/m7P/upP/30fwnlzwr57/6zn/2wDwgBgoIAAYWDh4OGioWJ iYqQhI+PkZWWlJaZmpuRk4uMn6CYjYiEpaGZpJ2bjp+qi62mrqeVmKeqsbmpnKiHAL++wLCS v7KgpY3Fmv++hsrNysDMpMLE0sTV2NWjtMOQlK/G4bi8prnUsa7OqOTs7J7f692iCrKTtqvb rMjl+8bW3N52ddNVT6C+fgUliYv3Dl0thfyOlQuGEFY+h+Dy9WIYEJ7EYfcuhco4siLAdiiX iYpWbBvLcbMQhaTliVOrf+acqXtGLVzAgbd6vvxoUF7MkkGhiSL6893PiBudrkIKleNCnj7B rWuIkplRazCfphx7KVpWjhrDNrPJzV4yr+kSxrzJ9CTCV14ddmy5k6U2uBjxLbV7a3Bbql97 nZNptqZEv4INZzVrlFHffUNBjvRItrPYsy4VHSgJ2GcnyvFE1stLmaDeujJjF5b/O/VgXXSO K5IUKPVw4N4ErZp+3bE40YvuMD+cJnam53YaacNtWxox6OTDtyINXvvhx+ohnWefjZiko922 pmsFLhkveeBpu4N/PD61d4WOX+d+3jn6Zp1+2fPMRsJNhJpqobUXFWSmHcfYgqiJ1+CBLVkG 4IWJMVRhUsEopQ1j6gnV4Xla0QaihSDWFJ2EAmJF04OEbYIAfymtQCNbN8IGiQ05kpNCjxL2 SOMhGAjZoJG2IakkkEs2qWSQY0Hp5JNTGilllJkYUOWRW3Z5X2ceeCnmmGTe+GOZg9SA5pps tunmm3DGKeecdNZp551uXvlZVzfqGaeflmGXEqB4LkNo/3eFJsqLfyrxySVsxClqHznTqaSn Ryz21OigZWm6aZ+SxnkmWYwWRWmMkKJa6KFXAnqPePslAGp6OtaKZajuKLWYiB7yw+uIKXpz zq8d+iNshbxmc+JbJ54GzbB8SYOhRdUhM+2AFiI77TTQknhZa5c5C5aynlblWzrPRjsusB/i yqdOa1VlHl3fEUifbsYJB+8xr8qWIUDsTQRwvPJ8o1eJhe2rHL77VbsnV4nNhDDEKi70rMW2 uhuZvFEpyNm/L+LLb2qBjXxfb9rVi5u9HFfGsssJO+hexwNbly3GHId3UsAJ8YzyoXc25vHQ Jg21X3kEtkbyYS72azGDZ90lsv/QMTeXzU4FqShMWEY7qJg+XRs47MniAgbZiBv+t3XGGtOb M9Hmrljbz9stjfNRT6EMw2c+05xhiTxbZR4iE3AtX1OI5vuizsdiHd9UjxcIdJ1uR2xY2pXB N/flM9v322wM5K2g11BV7l5+X3YuuN/M5YYXpojSbTrpUd/b8+XnQqQxK2tPnSx63T6YHrsD Eh8e8ADWgvzw6Vb71oW72b1atN4tD1Lw13BGvbjN5lQs3w/f7M9i4vy++/lNTk55f3f2gP77 8Md/qvyJz0///fjnr//+/PfvP/oE+J8AB0jAAqoGSeobYKuqlEADOvBJQoFOKg4kKCblyAdD clSk/jL/qfqVDXMIxNoDR1iUSiXJao5iUgNBdasOluqAi2JbSnikqjJdgIRvGgX2sHKwoQGL WdcIIgV1IzTjBe9XBlKWsXy1tnJdBIlFDKJvoMfE7fEGWy7CoQFpdTcT+c0ikxmY65YzxS52 bl7ksR3Xeqg4wPmLabpDI1UkFscOalGAEcqdSczYADZeB44hC9zgjEU3z2nmKA0L0BeXiEIz zhFV6rHjHQnosPW8SmlSC0DoeuE+cHFQdKwLkCIJOUov+mougERLKUOmxDGG7ZFX3OMkH1hJ 7XBRZbQ4AeskozzylS5xK5ObIZmDSNqZS18hu6ErN8fI6vFylgo02SJNmBbV/+1SZGKMzecy abk0grKYNYMbK0vmyJWZMpIvhOb9KGTEtH1MeIrB3A+pCL7ixdNbjGRXfm6Jm+hxsJ3nuWe9 OJRPb9qToJJUp0LRt8KF8qehDo3o7oZIjhlJNEcQvahGN8rRjnpUYyj4qEhH2hmLkvSkKE2p SlfK0pa69KUwjUQDYkrTmtr0pjjNqU53ylOX4kClNOipkWzkLnoI9U4uOGqXArhTCij1qVCN qlRJugAhzWCqWM2frLKaIxVwtTMW+CpWvSqkn4r1rDglK1rXKtEJwEmtbI0rJIo0VRXAVa54 zepd88rXqO61r50pgFKD2tIYbMKr7nOSAADL2MY69v+xkI2sZCdL2YXSsLKYzWxUb6DZzm40 TJHgrGfRWlWYyiBbALjBS1bL2ta69rWwja1sZ0vb2tr2trjNrW53y9ve+va3wA0ua50k2tEa t0mjiV9xj8tchy5Xqjekk2CbCz8IWNe6AbjBda8bgO1iVxHehcAgvCuI73ZXvOGtRHrPO17x gte95S0vedkbX/naFxLpNS97tytf7uIXvv1FL3nzC+Dz8ve//l3veg38XfPql772JfCBGfxg 6v4XvNot8H0vHGEAC7i9EK6wgz8M4fbCl8Qd7u99K7xh8xKgwe7Vb4FF7OEZn9jGmZAxiDe8 Xw/Tl8bvLXGIY6xhC6vXxyz/TvKNS4xi7MoYxylW8omZTOIEE9kSIw7yj32s5S4LOcte5nB9 hxxkHTu5yE/+8pKFnNKwog/IkVAyiOHc4zBn+cBbHe+PqbznK7O5xTVecZF37OUHg5nQcR70 oeuMYEUH2tBrZrGROczdBctZ0Faec6C7fOZBdzfCfGawqHnM6fD6mcKJTjWiySyIDlBYw/MF dJlhLelXd7rSsV7wmsyq1Duj+dcTnrWm7TzfYIMX1GkW9YQlvWgYH1nMiIb0qmst5maj2MSO Fra2ST1pVTMa2qv+9LBTPG1a//nG14bxrXlh7RUT29tqLneOSx3tdH+70Nfecri7Te9Lg1vc 5P62/69VLWITh5rV3Jb1jhv8bmhLm9S13jTC711lc4+b0M7md44HnOtfH9m/qH71tjE+Yy3r ut3P5vG6Q66ICHB80UPmr64DLHGR01zh9RZ5mmeu8cZGt+e4ygHQh070ohv9pjM9utKXznQk JRvixra5zSWM62NTHd8bPzDPWc5zX0e93CDPudbHHmawS9nKIO94yUWqJfo9fdlcJvnBYZ72 nGN73/Qm9I/MXHMywzzA0Xa4n/le9lEzGd5+X/KZ9Uz0t6c97rJ2PNgZf3DDU3viD4/v0yO/ 5kYHHuv61vPm765yxA88yjH+6A/2l+yMU/v0ODf0nlUe6VNjufPxFny1m/9s8Yzf3uS2pz3B g5/oTAd88QwvuqkHj246L17uNEcvqIUv6ITnHeoqHj3s4TzisEff9UQWcNdPHevfbz/89fX+ pFtPfDWTHfpfnv7cmb8JlMtd+4ov/8I9DnrfPz8ANcB9/Gd++RduRJYBl2dcO2dqAJd7oDdx APd4wEdg9Yd7mbd4SXeB+dZoMtdwK+ZmsOd+A1Z4F/d/BXdv6/doj+aBdgeB6GZ3C1iBLch5 Hvh/KSd/DrhlYRWCmbdfdrZtJrh2KGhkMbh/6nd2jteB8CdzKvh1T+aExaZ/N/dnMBh1C2hd FmABFChvRoiE2NZ8QqhiTddzbrYJiTWGikJYk1b/hnXiVmj4hoLAhnA4h3SShXR4h3WIh3PC hMf2XnyoacbGd3/YY4HIhIOIe1JXhVNIhXo4QC1AFupGedc3hAaneVAGgdRnhNhHe2Bmg+2H VUnnUmoyJpE4ZpNogwgmeuY2epmIaZsIaJ1ob4wYU0LXbQyXfLs3cvjVZ8D2b5XXZ68Yet3X fgnYiAuVfE52g8uXiOKWjJbWg184dbhGZ8LYfNFofWWySXaijWKySbzGV8gofd5WhOqFbL1Y eKxoiBZXfb+4f8YoUriofpi3gZRXdTswcv7GZuoIb7cGd5JYjPSTAe+YI/Hob+QYZwangSA4 gOeGiAoneaboewOpUUqY/3DtNnNNWHU4h2/+aJEdd4od2Q5tN5EkWZIm+YajcpIquZIs2ZIu +ZI9MgAyOZMBIJOKYJMzOQCCkJM6CQk5uZM/GQk8CZRBWZM0yZM6GZRDeZM9CZScYJODAJVR OZRIOZVFSZRQWZVGeZVMWZRLqZVg+ZVUuZSWIJVbaZaVsJQOQJZkeZZTSQ5ElVVSaZZZ2ZN0 KZR22ZQ16ZN6mZRNOZd9GZhOGZVW+Zd6mZY0OZhvyZSLqZiM2ZhGGZmO6Zg42ZeNSZd++ZZS eUOAiZhz+ZhpyZid2ZmSCZqARZqDWZc3iZeUyZeriZqY+Zh3iZWQ6ZmG6ZqgGZusCZmVWZul Gf+Zs1masTmah4mau3mcm9CbTkmciHlWI5kJxqmav9mc04mbuXmbvJmXzekB0lmW2jmdaBmd h0mZgmmc5Fmdijmctxme2EmdyKkJygmc68mW45lXgBmWhVmf94mW1amV57mY/CmZ3UmdA3qW lcmVATqWotmW2YmewlmeYvmT/umepgmf3ymfmomdARpTeXYj4jmZIJqgxTme8fmfqamf37mh JzqZ7NmfKGqavbmh6umdDcqcC5qcJFqf7mmjGLqijfWhAlqhQVqbdzmguumjO2mgR6mjSlqi 4HmhIPqbM4qeU5qk6QmhGYqbKvqk5GCTAvmgYGqeP9qeAmqXQpqVjAn/WlIKpiZapq+JpTSa pRUKpNYppZkZonBqpWy6nPNpnSp6pL4plTwQpn3qlBKwpWzVmSzAp3WZmF2Zl476qFB6oO2p lJa6oAgKoRKqoJf5opI6qTnqlVeJmZZaqkt6pmMplnwZoftpmI6KqDDZUxIAJ7Aaq7a6lxGV VLe6q7zaq0ZiWL4arMI6rMQ6kEwFdNzoJrrUI4t6q7VYrNAKU3uzURUwJrOaCc8are9DV9ra rZowrd6aI+AaruQqrMtarkvycy4VUujaru76rvAarxqVXPLqQA/wABpzr0airhe1evCKr/qK r4pwrwQrsAFQsAKrr4IQsAhbCQibsAarsAN7/7AAW69KVbCRILEMO7EaC7ARa7CD0LEUu7Ag O7AEa7FH5bEHCwkiK7Er27Ig67IjS7IjK7MhW7MoWyZG1SQgUCc2O7M1W7JAu7EhW7Iw+7Mm q63XqkU9GyoiS7EnO7QqW7Qs+7FQm7N31LSS8rAOO7VBm7Qmi7FQK7RYW0Baqyg2G7NeS7Q0 C7ZJi7Ro6ABKdbZj4obtkLZva7VP+7VV27Zla0B0Wyg/27AkG7VcS7Vpa7U5BazvGLh/i4aO y3RLi7WR+7iWe0dyW67Jermc27luco+40qGe6xk7O7qme7pGN66oW7autrpl0qyuG7uyO7u0 W7u221jZertl+40sxQetu3NZHBUIACH5BAADAAAALAAAAADQAbcBAAf/gAGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra4BBq+ys7S1tre4ubqpGru+v8DB wsOHFsTHgxPIy8zNzs/Q0dLT1NXW19jZ2tvc3aq93uHi4+Tl5ufo6err7O3u7/Dx8vP09fb3 +Pn62gf7/v8AAwocSLCgwYMIEypcyLChw4cQI04jILGixYsYM2q0Zmyjx48gQ4ocSbKkyZMo U6pcyTJUh5YwY8qcSbOmzZs4c+rcqQoCz59AgwodSrSo0aMwEyBdylMB06dQo0qdSrWq1atY s2rdyrWr169gw4odS7as2bNo06pdy/arh3AP/9rKnUu3rt27ePPq3cu3r9+/kzDccgC4sOHD nWIhXsy4sePHkKs2OEYisuXLQkXg0oy5M8kMnkOLHk26tOnTqFOrdgegNYDVYF23hk27tu3b uHPr3s27t+/fwIMLH068uPHjyJMrX868+UMBtTk4V1RguvXr2LNr3869u/eRnL+L/wVivPnz 6NOrX8++vfv38OPLn0+/vv37+J8pzs+/v/9ck/0n4IAEFmjggQgmqOCCDDbo4IODRADhgR9M aOGFGGao4YZBOcUhcSuEKOJ8JcwX4IcopqjiTyy06OKLLKwo44w01mjjjTjqdWKOPIYCWkUp 9CjkkEQWaeSRSCaZyv8GSjbp5JNQlkNBlFRWaeWVWGb5VwVBXXCBlmCGKeaYZJZppm4dnanm mmy22Q4D75Xo5px01mnnnXjm+Z2cevbp55+ABloanIL+pEyhiBaiVKKMNnodYY5GKumkV6Fg KaWyoIApYotu6umnoIYq6qiklmrqqaimquqqrLbq6qt+9QPrpkzOauutuD4iQa689uqLT74G O98AwhZr7LHIJjvXlMo26+yz0EYr7bTUVmvttdhmq+223LbJbLfghivuuOSWa+656Kar7rrs tuvuu/DGK++89NZr77345qtvM3zu6++/AAcc2X4CF2zwKZAeDG5lYJ1QrcMPWwuxwhRXbPHS xRhnrPHGHHfs8ccgT0VoyCQv2GnJKKes8sost+zyyzDH/NuhMtds882+0Yzzzjz37PPPOkkI 9NBEb0Jw0aMx7EoISB9bXdNQRy11VLJObXXAI1+t9Xe7bu11diZw9RZM5Y2DwNdop6322my3 bSSXbsct99y4VU333XirukDefBt7dt+AH+Zh4PrERfjhY0mnoApdVZibCoxLC/m0kyNuuT1K Xy733prXS1HnoIcu+uhenbz2jqSnrnrKta7u+pAjvC777LTXbvvt9QrmVde4hxQIACH5BAAF AAAALAAAAADQAbcBAAf/gAGCg4SFhoeIiYqLjI2Oj5CRkpODGZSXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8CjIMHExcbHyMnKy8zNzgEfz58G0tXW19jZ2tvc 3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb35QT4+/z9/v8A1VkIeM8EwYMIEypcyPDai4YQ I2J7KLGixWQUL2rc6Csjx48gQ4ZEILKkyZMoU6pcKdIgy5cwY8qcSVMTtZo4c+rcybOnz59A g3IcIbSo0aNIB6lI2hAD06dQo0rFhmKq1atYs2rdKukC169gw4odS7as2bNo06pdy7at27dw /+PKLaZhrt27ePPq3cu3L82qfgMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fP oEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3bhhfg3s27t+/fwIMLH064LvHjyJMrX868ufPn 0KNLn65zQ0kG1DlZ5zYse7bt3oGCD/9zPPme5kFKOD8pPfuc7t/TjC9/Jv36+PPr38+/v/// AAYo4IDueEDggQgKUsJXLLCQYEkNPgihhBS2c0CFGGaooTokbOjhhyCGKOKIJJboDWAmpqhi RZas6OKLMMYo44w01mjjjTjmqOOOPPboHIo+BrliAUIWaeSRSCYppP9XSjbp5JNQRinllJad QCU/HVyp5ZZcdqnMhV6GKeaYZJZp5plopilNBWpKYmWbcMYp55ypNUAmmHTmqeeefPbp55+A BirooIT2uVRONxWq6KKMckMBBY3G8uijkb4yaaWYZqrpppx26umnD0YD6qizJErqqaiC6EKq pqzKKimuvipKrLKGQqtWIgB3a62d7MrrJr7+KuywxBZr7LHIJqvsssw26+yz0EYr7bTUVjuK PtZmq+223Hbr7bfghivuuOSyY2e56Kar7rrsHplCu6xGAK+2Icxr77345quvtAKwm+u+AAcs 8MAEF2wwJRAcbKOpCouGLbdvNqzQQBJXjBn/kCFNYPHGHHfc7IIe40YScrqFbPLJKKes8sos t8xYArRx4PLMNNdsi1M256zzzjz37PO8h3qiwM9EF01MvSXiacoK4DLddLhOexv1YRFXNrVJ 2Bmt9dZcd+3111wrDRXSkBgHNohml9Xh2fUxyXZlGL8t99wCthCu3d/inTe4envbd7d/K9dv UoFvW3i2h9NdSpaKN+7445BHLjndQ0/+zQCWZ6755pwbJWrnoIf+Uouil2766WvJi/rqGbrN +uta/gv7YjDPbvtrAGRHdlC5g9s7agnb9fu3w3tbfLfH37ZeWMkH4xKczWsbPaAU0zL97dlU jv323Hfv/ffghy/+GPjkc/9A+einr/767Lfv/vs1OgD//BYFAgA7 ------=_NextPart_000_0017_01C6EE29.A00D8BF0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 12 16:58:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY7d9-0005Ic-Mh for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 16:58:15 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY7d7-0000Ou-Pn for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 16:58:15 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id A1800144803B for ; Thu, 12 Oct 2006 13:57:57 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 2419F4A4196 for ; Thu, 12 Oct 2006 13:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 01BE91448031 for ; Thu, 12 Oct 2006 13:57:21 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by hermes.tigertech.net (Postfix) with ESMTP id 88C211448013 for ; Thu, 12 Oct 2006 13:57:18 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GY7cD-0005qk-Fv for capwap@frascone.com; Thu, 12 Oct 2006 16:57:17 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 12 Oct 2006 16:57:17 -0400 Message-ID: <9816485.1160686637454.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Thu, 12 Oct 2006 16:57:17 -0400 (EDT) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710add3e8588b3cb93e7ba7404591aa1bf4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Sorry, I meant to reply to Pat, but I was distracted. I've added some comments inline below... > -----Original Message----- > From: Smitha Smitha (ssmitha) [mailto:ssmitha@cisco.com] > Sent: Tuesday, October 10, 2006 3:40 AM > To: Pat Calhoun (pacalhou); Scott G. Kelly; Capwap@frascone.com > Subject: Re: [Capwap] discovery interval timer question > > So, MaxDiscoveryInterval is not specific to an AC, in that it is a > global timer which decides how frequently we send out Discovery > Requests. But "DiscoveryCount" talks about the maximum # of > discoveries > transmitted by the WTP to an AC. > > Also, the spec says: > " A WTP MUST send no more than the maximum of > MaxDiscoveries Discovery Request messages, waiting for a > random delay > less than MaxDiscoveryInterval between each successive message." > > Is it OK to assume that: > 1. DiscoveryInterval timer is the delay between successive discovery > requests sent to the same AC? > 2. DiscoveryCount will be obtained based on DiscoveryInterval timer > (when the same expires). > 3. MaxDiscoveryInterval - why is this needed? > 4. Transition from Discovery to Sulking state occurs when > DiscoveryCount > reaches the max limit - for a particular AC? > > However, this does not cover the case of being able to "select" from a > set of discovery responses obtained at the WTP. Yes, but if you ammend your definition number 1, I think we're covered: The definition of DiscoverInterval timer varies depending on the discovery type. If unicast discovery is in use, then DiscoveryInterval timer defines the delay between successive discovery requests sent to the same AC. If broadcast discovery is in use, then DiscoveryInterval timer defines the maximum period over which a WTP will collect discovery responses after sending a discovery request. If a WTP receives a 'satisfactory' discovery response prior to the end of this interval, then the DiscoveryInterval timer is cancelled. Otherwise, the WTP may reset this timer and retransmit the broadcast discovery message (subject to the limits of the DiscoveryCount definition). Scott > > Thanks > Smitha > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, October 10, 2006 8:35 AM > To: Scott G. Kelly; Smitha Smitha (ssmitha); Capwap@frascone.com > Subject: RE: [Capwap] discovery interval timer question > > > Seems like the behavior varies depending on the discovery > method. For > > a broadcast method, it seems reasonable that a WTP should wait some > > reasonable period to probabalistically ensure that it has received > > whatever discovery responses it is going to receive before it acts. > > Otherwise, you could have kid-in-a-candy-store behavior (I'll take > > that one! No -- that one! Wait... I want THAT one!) For a directed > > discover, obviously the WTP can act upon receiving a response. > > sure, but that seems like a logical "implementation specific" > condition. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From xejmbkryxfi@wissenden.com Thu Oct 12 18:30:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY94m-0003iI-Pl for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 18:30:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY94m-0000yJ-LS for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 18:30:52 -0400 Received: from 205-143.207-68.elmore.res.rr.com ([68.207.143.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GY94h-0003G1-BR for capwap-archive@lists.ietf.org; Thu, 12 Oct 2006 18:30:50 -0400 Message-ID: <000c01c6ee4e$5191b080$cd8fcf44@kevin5ake0e0gd> From: "Venus" To: capwap-archive@lists.ietf.org Subject: hung juries. appeared telling Date: Thu, 12 Oct 2006 17:32:37 +0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6EE24.68BBA880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.7 (++++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c ------=_NextPart_000_0008_01C6EE24.68BBA880 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6EE24.68BBA880" ------=_NextPart_001_0009_01C6EE24.68BBA880 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Personal am assistant her sisters who began their careers Compton in =20 seeking revenge another time is killing his two trials or ended. Winter Olympics am Gearcbs Sports Junior is Racquets User is Comments =20 Site Index Privacy Policy is About. Bangkok Madrid Paris video replay system Shopping savings in top name. Sentenced killing April wire reports Compton in Calif gang member =20 accused shooting death the tennis in champions Serena and Venus. Seeking revenge another time a killing his two trials ended hung in. Killing his two trials ended hung juries appeared telling judge a that =20 slaying unfair our a family has always been positive in. Began their careers Compton seeking revenge or another time or killing =20 his two is trials ended. Expects return October American teen King advances Bangkok Madrid Paris =20 video replay system am? Death the of tennis champions Serena and Venus Williams was a Thursday =20 years. Index a Privacy Policy About Terms Service Cbscom Advertise With Usthe =20 Insider copy inc rights reserved service mark of Inccbs eye is. Pga Tour Autos Tennis in Horses More in Fantasy of Mobile Games Contests =20 Shop is Ncaa a Rankings Schedules Players man. Target said owned beauty salon of personal am assistant her is sisters =20 who began their careers Compton seeking! Gang member accused in shooting death the am tennis champions Serena and =20 Venus of Williams. Compton Calif gang member in accused shooting death the tennis champions =20 Serena and or Venus in Williams a was Thursday years. Voluntary Yetunde Price outside crack house she is rode by sport utility =20 vehicle she not in target said owned am beauty salon in. Sentenced killing April a wire reports Compton Calif gang memb ------=_NextPart_001_0009_01C6EE24.68BBA880 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Personal am assistant her sisters who = began their=20 careers Compton in seeking revenge another time is killing his two = trials or=20 ended.
Winter Olympics am Gearcbs Sports Junior is Racquets User is = Comments=20 Site Index Privacy Policy is About.
Bangkok Madrid Paris video replay = system=20 Shopping savings in top name.
3D""
Sentenced killing April wire reports = Compton in=20 Calif gang member accused shooting death the tennis in champions Serena = and=20 Venus.
Seeking revenge another time a killing his two trials ended = hung=20 in.
Killing his two trials ended hung juries appeared telling judge a = that=20 slaying unfair our a family has always been positive in.
Began their = careers=20 Compton seeking revenge or another time or killing his two is trials=20 ended.
Expects return October American teen King advances Bangkok = Madrid=20 Paris video replay system am?
Death the of tennis champions Serena = and Venus=20 Williams was a Thursday years.
Index a Privacy Policy About Terms = Service=20 Cbscom Advertise With Usthe Insider copy inc rights reserved service = mark of=20 Inccbs eye is.
Pga Tour Autos Tennis in Horses More in Fantasy of = Mobile=20 Games Contests Shop is Ncaa a Rankings Schedules Players man.
Target = said=20 owned beauty salon of personal am assistant her is sisters who began = their=20 careers Compton seeking!
Gang member accused in shooting death the am = tennis=20 champions Serena and Venus of Williams.
Compton Calif gang member in = accused=20 shooting death the tennis champions Serena and or Venus in Williams a = was=20 Thursday years.
Voluntary Yetunde Price outside crack house she is = rode by=20 sport utility vehicle she not in target said owned am beauty salon=20 in.
Sentenced killing April a wire reports Compton Calif gang member = accused=20 in shooting.
------=_NextPart_001_0009_01C6EE24.68BBA880-- ------=_NextPart_000_0008_01C6EE24.68BBA880 Content-Type: image/gif; name="LINKS.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6ee4e$5191b080$cd8fcf44@kevin5ake0e0gd> R0lGODlhqAGwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAYAAAALAAAAACoAbABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sGGlBQ4rXsy4sWE+jiNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgU4ktOFqDROngYFYQDiXhhFdVGNSFGFqlIVAcdkjV hz+FKKJUJFK0TUomnghVijy16CKDEc7YmYw25qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFR6p0aVWGap5ZZcdunll2CGKeaYDzFB5lpMmHlmWmquiVabbpoFZ5xkzUmnWHbe CVaeenrFZ5+ABirooIQWauihiCaq6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnORUCKlGi jjpUqaYGhWqqP63K6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxko6A7LLMNuvs s9BGK+201FZr7bXYZqvtttx26+234IYr7rjkqqRNueimq+667Lbr7rvwfnVPvPTWa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6xwh70s7PDDEEcs8cQUV2zxxYSqQ6/GGI91TZTY1BtyvCOT LDK9JcOb8rsrt9uyy2x50fHMNNds880456zzzjz37PPPQAct9NBEF2300UgnrfS9HCztNHi8 PC311FRXbfXVWGet9dZcd+3112CHLfbYZJdt9tlop6322my3fRAu9cIdr9xzx71VK4nSjRXe dofqfRXffWsFeOBuF2744YgnHqQj8DrC+LuPu+t4441H3q7limeu+eaposH556CHLvropJdu +umop6766qy3Hpoirscu++y012777bjnrvvuvPfu++/AB9+jAcIXb/zxyCev/PLMN+/889BH L/301Fdv/fWABQQAIfkEAAoAAAAsAAAAAKgBsAEHCP4A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59Agwod SrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qd S7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4se 3TkN6dNb06hGzbp1WTGuY8ueTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQo0uf Tr269evYs2vfzr279+/gw/6LH98xCXnp5s9DT6/eOfv2zN/DVy5/PvL69vPr38+/v///AAYo 4ID+lUHggQgmqOCCDDbo4IMQjnRHhLVNSOFsFl4YW4YatsZhh6jd8SGIeF1wAYmtmYgiayqu eJqJJ7pIWowy1mjjjTjmqOOOPPbo449ABinkkEQWaeSRSCap5JJMNunkk1BGKeWUVFZp5ZVY Zqnlllx26eWXYIYp5phklmnmmWimqeaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGKuig hBZq6KGIJqrooow26uijENEC6aSUVmrppQGOgOmmnHbq6aeghirqqKSWauqpqKaq6qqsturq q/+wxirrrLTWauutuOaq66689urrr8AGK+ywxBZr7LHIJqusqFUs6+yz0EYr7bTUVmvttdhm q+223Hbr7bfghivuuIyaQ+656Kar7rrstuvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAE F2zwwfaKgvDCDDfs8MMQRyyxZPZMbPHFGGes8cYco2lgxyCHLPLIJJds8skop6zyyiy37PLL MNf4Q8w012zzza4JgvPOPPfs889ABy300EQXHewiI0vjrdLdMs2t09tKA7W2Uxtt9dVYZ631 1lx37fXXYIct9ti6teGt2d2iza3a27KtrdvSKmIQ3NHK3a3d3OK9rd5s2vKdrSJ+ky04Uokg WctjhXOb+LaLa9t4to9jG/m1kw9u+eWYZ6755px37vnnoIcu+uikl2766ainrvrqrLc+VTKu x36sDbL3lgu3t2+bu7a7Z9s7tr9fG7y1w1dbfO3IJ6/88sw37/zzsgUEACH5BAALAAAALAAA AACoAbABBwj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmT KFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWr WLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePNexaC3r9+/gAMLHky4sOHD iBMrXsy4sePHkCNLnky5smWi2C5r/pt5s+e7nT+Lnht6tGm3pU+rTpt6tWuyrV/L/hp7tu3b uHPr3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069uvXr2LNrb1tmu/fv4MP+ix9Pvrz5 8+jTq1/Pvr379/Djy59Pv779+/jz69/Pv7///wAGKOCABBZo4IEIJqjgggxO10KDEEYo4YQU VmjhhRhmqOGGHHbo4YcghijiiCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOP /UkDpF9CDqlXkUbihWSSdi3JJF1OPilXlFJWaeWVWGa5Vi9aysVll299CWZbYo7JVplmpoVm mmy26eabcMYp55x01mnnnXjmqeee8I3A55+ABirooIQWaqhVXxyq6KKMNuroo5BGKumk50lB KVKWXmpUppoSxWmnQn0KKlCijupTqabyJAWqqbbq6qv/sMYq66y01mrrrbjmypEPuvbq66/A sqlDsCwNS6xKxh6r7LKFJcPss9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimi+0h 6rbr7rsHpQNvQvLOa1C99haEb74C7cvvP/7yG7C9AxP878EIJ6zwwgw37PDDEEcsMXl1IFzx wRf/m/HEHHfs8ccghyzyyCSXbPLJKKes8sost+zyy2sdkbDMMNds880456zzzjz37PPPQAct 9NBEF2300Ugn/Sw1Sjft9NNQRy311FSbXEPVWGet9dZcd+3112CHLfbYZJdt9tlopx2dJQmz 3bbCbiMct9p01x3ZAnbnrffea3z37fffgAcu+OCEF2744dIBgfjijDfu+OOQRy755JRXbvnl mGeu+eacdx7YD56HLvropJdu5w2mp646x8Ks7vrrsMcu++y012777bjnrvvuvPfu++/ABy/8 8MQXb/zxyCev/PLMN+98QQEBACH5BACSwwAALAAAAACoAbABBwj+AP8JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKFBggQMGaNf/hxKnT JsKdNIHe9EkwZ0+hRnsetZlUZ1CeBncabUo0aFGmUKVaHdhU6VapPrsmzdlVKditM9OqXcu1 KlqvcA9OreoW6tO4ZInOvUsT79CrR7n+bfuVLt66erECFps4cFvFg9lKntyyLNXGCfcKvjo3 72LMnQVTjWx2LGnNoy9H9kyYceusPC27pUy7dkjZgN9GDTu76FLFqksTdjo17u7FXhHn1pxb t/DDxscy/f28ue3r2DXiHm58tVDfjln+F4Zb3Gxy162tIj57/i5Y3MyroyXLNy/S3tnz62+4 fT5+59FtJt9e0vVlXoHW0Wdegrz5B91f8YnnoF6vHbffhRgq1B95/yVnnVPHBefYV49xeNp0 fHHXnokicqaihCzKBVmGNNb402wilrXch71JKB1dYZWI4IsojvgWao21WOKRM04oY3c62iil bWd996NdT/GGpYGDsZciUEBmKRtSPIZ5H5hh7gbkmbBl9SR7UU4p55x01mnnnXjmqeeefPbp 55+ABirooIQWauihiCaq6KKMNuroo5BGKml2AwxQUKWV/oMppppaitCmAm3q6aWgdgqqqJai amqqo2oaaqn/BKn6KqydxirqQJnWamupspLK6ay/7spprq+uSuyxrRrLqq3K+hpss8Dmequu k2pELK6tIquQtNmSGiu1zIZbrKm4gpustuBii66u3B60brrXLoutu6PGKy+79SY7rrn3GoSu vfzCq2+1FV27L7UGe2uuwqGme3DA5DYcL8Pt+hsswBVTnO253QJs8bzz/psvvSAXm3DJGdeK MccEW6uvxw6He3LJNNfssbz9fjxuwhXf/Ky4MD8MscbMilzzvisnZHTIGwvcckY8Ny000LTu nGmvBt9sMr4cwyprz1JXjbLUIA9LNtWqYj2yzspePa26Fze98q8zPw1R1FRvO3DW/iOfzLfM W7+r8tlWHyx43jb3TTjScvd7OMKNK+145EwzbDdFeI+td8OJV8624Z7me+/fkDt7Ktl1v0v6 4OIibnLoa8eses4yx86655dvlDnjm7va+eskty6tuqUjvvrtQ7MddOnL8457xn7b7rbkZVMO fOu5R5R23HDzze3P0bLqNcvA+m511XObXfTbU4MuNrS9Eo071zPPDi3N38fNK/nZ9+///wAM oAAHSMACGvCACEygAhfIwAY68IEQjKAEJziRD3xgIBcUiAUJskEMWvCDGvxgBjsYwoKQMIQb FGEKM4gQFXpQhCZk4T9UKEMOunCGMqyhC2n4wgvyMIY2/ixhDGGIwg7+8Ig35OEPW5hDIuKQ gg8xohR7CEQhavCJHqxiELNoRYOc0IdNpKIVT9jFFbJQh2Ec4wjP2EQSTnGLJfwiF7EYRzbS UY0HcWIayQjFhEhxjWKcoxy/iEYvpvGOWpzhHd0IQjwm0owYfKQdhUjIQL5xjk+UoyPrmEUy MtKPNeQiH/uYxxEqEouXpCMfKwlHTH6SiYbc4htf2coUolKSggSkKHWJw1WGcZSq/KUdPTnJ UsISkaRkohknyUpk0pCYscylQpK4R10usZY+jOMQl8nKbvLSia4E4zEXCUYiKvGG4ywiJpOp zHIy85C+bKUz4RlKWHqTkuI0/2YntYlNRKZylofsJzBpmclhFhKY69wlOxcCQ3M+U5qRbGYX y1hMLwaxks/M5ygx+kJckpOivUTnRoXJQYhy8qQKBWU6F8rQYjaToPmcaDxNatFOktSmCeUo Cj0aTEe+tJ4YzSFNV4hTOCLUjbKsJ0tN+lMbNlKiIV1mLsFZRDY69KIBraop1ylRqS6xqaXU IzgJ6dCyghCqUV1jI5G51La69a1wjaujciHXuhKMrnbNK6Twqte+Loqvfg2soQAr2MIa9rCI TaxiF8vYxjpWJvt4rGRbRoDJWhZDlb2sZvOT2c16tjad/axo2RLa0ZpWJqU9rWpbktrVuhYl rX2tbP5nS9va2va2uM2tbnfL29769rfADa5wh0vc4hr3uMhN7m3todzmOve50I0uYmNbEOpm yLoBBIB2tVuj1hLgu/8Ar0Aq+93yhjch5e2secerXvKuN7TuNW964wvf9bLXvQNpr3jzSxD7 qpci/k1vfu073v6Cd77nPYiAE5xg7PqPu1OKbWb3+98CK9ggFaYwefkLX/5a2MMNRi97PUzd Cof4wxAxMYNXXN0Wg1jCHP6wg/sHYYJsFwACuTGOt5vjGw/Ex//QcY+HXGMAI2TCJ2awdzHc 4g07OcYvBrGMUeziDZ+3xFK+8oEDjOQO9zfKTGaxl1kcZStneYBFDjKO1f7M5jZzF8JpfvOa 5UzkNVcExleeMpX3XNonP7nAY9YvkmW8XxKHGMtUNvN/F91nFyv5wmL+8p6nXOhJZ9fOQ2Yz nOe8Y073mMeb/jSmL4LnLoPZ0Vm2cpffK+lHG7jSibbwnyEdaRPT18ypPjWtUaziV084tTPO XZw9HWpNE/vYmQZyRkoNaF2fudGDxvWKbV3lXZ941mGudZlRHWs9HxnVvc51ow847Donu9Pm Nnam28xuI0O6vc5+tqG/PG5v1xvY1R4xmXk970cvmtZjJvOgpdzrgcu61QYUspqLHWqFL5zO 7K5xmiWy4Psq2dYEvq9+xY1hAgsa1/St7oEHPP/gSte3vq5mtYJNLnLx/nrLGHd5t5P81ok7 xOYUDPaddD5BnDPE5xPk+ZyELt2iG/3oSE+60pd+EqCvm+k1VzZEnN7ukuQjHwS5+tX/oXWt cx3rUA8U1RdC9bFzZOtZB7tA0P71sIt91A33MY8fbmcgQ5wkbF+72tuud7cDSuFxP7eb0a1u s2Mk73zvu+L97ifAz53hhIf43U2C+LyzHfGM79OmIZ9uyRP+JJXf++X3nnnN1/30gg984Ucd ktCnfSCYL72dHB5xTxt77g9PN967/vXRw573sv+T4YOv2OET//jIT77yl8/85vvV+AqBvkhY jxDqt8T6EcH+zZWr48/+S0TI0g8J3A+i/R//uO4JwX365U4Ribff/NxH/UTKLRO7U3/8BYFz jvdPfviT3f/Zh37zB4DHJXH2Z26YRn/KZn/FlhE7ln8GwXrjN2f7Z30TqH7+Z3fm94A2xn+c 9oGnJ4D8h1wG2HmdVmTlpnqpV35TF2QQ+IIdCH/yZ4EQKIIZuIEbKIEe6IIViIM7SIDFVYLq NoQ2BneRd4IgGH5kh4IReH7gJ3U8GGc1CIQiyIEueH87iH5aqIFASFxC6HlVV3VgmHtK+BBW qIMwGIMdSIEEeIZNOIJuKIHgx4NX6INqSIcFOINHGIYpaHu693QOSIdoeIdt+IM3KIhviIj/ WpiIdbiIPTiChBiEeihq3ueEnrd5ITh5F7GAE4d/aSiI9+d+kAiHMghqjMiBj1eKVeh8k8GC eKgorsiKKxGLsdh4sniLuHhYW5CLi7WLvJhYvhhYZSgZtRhYwbhQtBeBxUiJyxh9zdh/apiM v8gWYxd+w6iMGHGAoziNlAF0jsd5+ZeAj4eKDAiCYfhzr2iDuSgHtgGFgleEg4eN2Ch3yEaE 0GeFcIiB3NiKSBiPdCdq5CeOoDaJ3XeOAZiA0LiP3SiHJgiQ8hiPX1iJ11iH2/iKCll/fnh+ DQmIGrmCHamJQvh9iEiKF7kW7kiJKMmRT/eERTiOLmmQzmiAIViS/3cykeE4Es9Ik1Jik7mH kzr5k0AZlEI5lERZlEZpkifpgHKoj/CokhmhClAJlf8glR8RlVR5lA8pfgwJkzyZEFcpEF/J EVQZllgphsiGbub4jz35jj1Jj2r5j2YXllY5laowlWAZlXeJl3n5lWNZl31Jl3cJlArYj245 hJroj/BYgqp3mAhhlXUJmHsJmVL5l385EI4ZmIBZmTo5mLVniWDYiVLHkg3ZgA9xmVd5mo85 manpl6tJEJTZmnRJlhfJmSFJmwwZkZ25mDmZmY8JmZLJmoGpmb85nLHZm5tphLoXkh55k/54 d59ZjxChmpbZm68ZnLCJmdLpm7JZkt/onP8COYbqF5EvCZ6FyRCXmZe+WZzYuZp6uZfUOZeY WZY00pUYsZ0LYZ/y2Y5MuRLwKRH4mZ8AGqACOqAEWqAGeqAImqAKuqAM2qAO+qDZIwkQOqEU WqEWeqEYmqEauqEc2qEe+qEgGqIiOqIkWqImiicUcKIquqIs2qIu+qIFyg/8AKN4IqMzChEy 6hA5SqPZYaMRsaM8Oic5uqM2CqRFKhBDeqNE6qNLmqRBqhZO+g9LWhBOOqVAKqUzeqVX+qQw EaVTiqVMqqQ+CqZiSqbAtQCOVaRhiqRZWqZNeqNm+qZcCqVw6qVtyqZYOhBbmqdaeqdz2qV1 6qdv6qd5yqZWOqb/e/qnF5KoitonjNqokBqpkjqplNoyxbibJIGpI4qQ0deC0ZiUZMgRmiqi nJp+ZjiOXfiJoxqJXIqQnLh5jxirJEmIRviAH+iQa9mWdriqDuqqu6qIEwiDC6iMbOhmv2qD jkiRFrmpa3is7EesrMqCbkiKyVqq04qPJuqrsYqtNKiOFTmFsxqHAFitspqtzbqtilh9IzmS 2Det6YquN7iKIrEJBsqFUfiSFvmqTtiGuPdmLUmSodmv/Vqpnlp/2UewBesS+9mpCNuwDvuw EBuxn+iTKYGtH7qwZvivn7Z+HWmqCbt+NmexHeqtU2eK8PqQTreM0vp/vFqv4HqvFKit/y9b rD1Ijpm4sRSJrxi4lOU6sjMLrC8rg0LbrLZ6rDnYhPK6r+nasgWKfzbrr9B6iMsahei6hSYL kJnYrezHtATqtFTLqjkbjepKteTqieTKskF7seMar+rKrUNbiGX7qyfbrTjItU0rhUq7lEmI s+n4ggILq3iojTv7tz0bqXYrsQaLuIq7uMEXDIw7JY77uDYSuZJLI5RbuRhyuZhrEYXAEpq7 uaAbuqI7uqRbuqZ7uqibuqq7uqzbuq77urAbu7I7u7Rbu7Z7u7ibu7q7u7o7pmQaqIgaqL8L p4VqqG16pI86ur57qHpKqEZKvHhKEH3avKtrp3j6vMWLvVQKvf/TG73eK7p2GrzUq73FS73S S7zkW76ha718Krzku6db2r3qW7pqar3Y+77Qq77ym7yge79u6r7C+70CvL/om7+Y67/Le6TG W8AGoaZm6r0OzL+8O8EUXMEWfMEY/BGfO1vld7h54sEYAsIZWxI0eLAxIY0m7LHfqrQLx8IL G4pYmI2p+n/hyJO7ibEdIcLbp8Iy3H+DeK48PH0b0cEjrKzi+q0lzIgVoameKKoWocMTqxLa 17JJHMUrfMVOXMPU+re3iqtX+MLv2rcJ6bc6q3/9iLMm65IzGbgBeauYuMVdbLNkLJPVl4pd HKoeCLgt3Ma1F7NfW8a1iqtQ+KwDWbT/Z2y1fIvDN/esRhzGR8zGJFus7jq1UyvJ6xp5cGu0 o4iPg4iKVSu3X4zE1ErDoezIYXzK0EizpezJJ9u2oLy0n/rJc0vJAyi2cVuBjCyznQzKUzy2 1ZrLqvjI13q1+eqDfizLcNmxMZisY9vIyMzJ5ZnKeQy1fUzNIXu1k7yIomjKvzyQQyys3GyH s+rMawuvRCzNrXzJ4fzMbAzObCjM67rJXlu4tsy2yLysOPfO69zE7XbL7WzE7grPkbyqZrvO jYys8VzQzLzJvszL6uzPAq2qxszOq/jDX6usDD3L/pzQGX3MzvzI5XzQIc3JD63JHN3DGovH MHvHoZnQDJi3//bqxdh8bpY8zcSGxsGcrzqbhVxM0/kYyAKYii1Jsz3dloA7sMts0w+tmKBp zV4cqgILrDJpe/j6KFCMHVctkrMoXVl9HV39sSbx1Rk81mRd1sfnirxKn2FNsUssfiixsiwh 1kVMG/yMxTu8H2hNrN/p0Ofcfu6Y14FIyrTsEe2qwh4s1++HjiitH4Attviszopdy4UY2ZtI 2V9d2M3s1vqpf2Soj/raiEf9xZ+nxjA9xW/8rqS9x6P8hhW9li/9xxsbx8t82oBs2nqcxnuc 2ugs26xcyGgMtbpd2jersXbMrmacxY34ytxc06tsiPdMsgZdtPe82u4cthAN2zILif/BqtGp utGsbMq7DbRh24URLcpnq91Hu9w5XLfOGofATN36rNLQvJ/XjYQg7ZAxnNweHdGGvNCcCsyt Lcq47M3rFuCVrN+7Kn+BO9PnjbWvPNUkvbd2q83K7d9Se60UDbb1/MkKrcT5bcgZXrMAjdGQ bNINvuE3+d0nzt7lTWT2LNLozc4pnobfbddandzpfN3wnYUmza7VzeE9vo0/bODwHM85y9kh Dt4djt77Lbe7rORAXN8jDd4/W9D0/MTGPNNDnbfjiuTx/d5VzbOuncZevpJt7LY7btTyitST TY/iKch6/duWfNRsfuFlLsggCA+ahtPy7NS5SrhizOdvLdj/rUjog/4SKDzGhn7VFo2MZVcb cL3VjD3Xg/3NGm7WmA6x0JDptIvYga3ZyG3o12cjnp4hBM3IDQGqTcfWlW3jlQ7WsB7riX3j BEPFM6zEiM7qWO7qTIupTBzqsj4lgDx4Zb7Td5yQn03esHrauS3U6cjZVY3fMGuJxs3SKChn dDzbx/zaLTy4afnn3jmT3j7m4n7bTs3bpL7hTX7emBzZDb7L+qyORY60/2ytxprkqByuJ53e 3t2p787jsjrkPY6F9n6BOzkQyOCI657g2BzpVsuEP97k8t2zW5u0VN7icPnkog3x773xo33m VI7d6a3T8Yrqe13wDn7w/4AMqJ3k//zsjS8+sQrv8uX6y/se0AaNz/ZOz/MustT84tkM8KBY yfe98xhN4Vc+6Szf8jBOzharyvou7xFP80IuzkHP3c8d0iXN5Hy9tvD+4EKf3VVu9TGP9CQ+ n6FNtkWd9qr94aoI8rnN01MN2TVsq9lO7Qs+3K8d7S4+zXM833GsnBP/5z8Y5gKJ52tM229s jqXuEUsf7CFM659OJ40/+bnz+JB/Ic3ItZX/EYoM6Zwe+qI/+kY5qmqt6DNBiyTMsCnM+k/c +RybPb8u+XcNEjkpsla83qaqslFs+t1465Ay+6svxJIt6oTt760fxMVvksDP2IAux82e7TC8 7XSe+MDN7P/OLuexnZaIHPe1Ksdc6OzHHv3DPcqmOP662tnDJv2ijdMn2MeIz7elvf297f7y DxNlS9QV/ti4nOZHH+UA8Q/AP4IDCRYUeDDhQYMJDT5c6JBhxIYDATREiNCiwooRNU7EqBDk yIwlN1YM6ZGixI8lV3a8aBIkxIUhN7aUOVEny5U1RVqkqVLkUKJFjR59eTEmyp03ayoV+rIp RaVAGcIk+XQpR64tIWLFWdXpVKsyH0JlGXNoVakusXa8unTrR7AeYbKF29anVqdjxXLM23fk Tbxx1SJFnDhxXZcCBdcdS1Zy44JMH2f12zVtWL0212K+DNcvRsg9zZrOe7r05Kn+pzN+xWz3 6Fyeb2ubVpxbN9HSKS9zTtk5tluuv2+T1kwY+HCerI+j/sxasOTAO1UzF16ds8/eyXkLb716 727ySNlWDorWcXr0kdu7VUs6/nyaaEVDtUn/tUb15/VHLcw++94rqAj01sJPp/MMe8ou9Vwr DL7DBpQwp/oSfO2/uDZ0MKf1RkutPBF/GrFE60xEMcUTVZxNseBYhNGoFymLsUYbzbtRtxlz /JBHH1v8UTMcg6zxwe+IRBLGHZNkskknn4QySimnpLJKK6/EMkstt+SySy+/BDNMMccks0wz z0QzzSyXBNJENo/M7U0156SzThWDkxPOEpFbbLc387T+M1BBB6XRxRT5RAzQqAhltNEyFxzw JAEnjE+rDPM7i9LD1jvwQP/6q5TT9zLl0FFTTw2yN9iW4+8z90gUDzpEjTspNuNQxTXXImfC 8Dn+eu2xrJ96nc6kCF17rru/NtW1WWfLYyy7rDzsa1bwPCSOVYmU5U3RZ7/VtTttaZ3W2lir M9dWaVMLClx334U0VIcotNTBrYwMVkEjNSS2JwpBnWvSFd8lOFw/C44OYYUXLlTGhfFlOGKJ J6a4YosvxjhjjTfmuGOPPwY5ZJFHJrlkk09GOWWVV2a5ZZdfhjnmk4mRuWabdaP5Zp13Hipn nn/W2Wegh45ZaKKPZtlopJf+nplpp1FW+mmpp6a6aqu/lOVqrS/OemuvvwY7bLHHJrtss8Fe 5Wy1UU17bbcJbfttue2Me26706z7br3HzHtvv7/s+2/BBye8cMPnhASSw8tMvHHFEz8IcscV j9xxgiavvPHLLf8Hc8g375zz0DXPnHLMFTr9885DR53yzSX33HWRTh+98shZn1z20UmnvXXX VX/c9OBBx/334DWnvffUjd9dddZBX15k4Jl33vbiiXe+eu2pF574oT6v3vriTX/ee/OnJyr8 2l+/vPzw32d+9unJB3/452G3Pfvuy28d+vj59x7+rhcy9Pkvfd2r3/l0t7387U9999Od+GAn Of7+MVCCEQTgAC0XQfh9738G3N3qQghBEA4Qe/uTXwkL2D8QChBk89ug6EiYwObV0Iboo2Hv IEi6C64uhiwUn/sw2EHwjRCIQQzgAu13POHhcIm5q2EOZRi9JHqwgSX82Apd6Lv68XB7vPuh /7yIQSHyUIgiRJ7sLFhFK6awiOs74gntB0ABNjGIuaOhCW2YwRn+r4NizGMW/TjHOLrwgQx0 4hkP2MYqcq+QavwgEvEowgz+0YT681wPM8e+M+pPkSm8ZCQ7qUTpDZKPFgzkI0d5wqJYspOo W+QRV6hK6MESlEA0JCTzZ0s6ojCR1kslK7XIQUeibJh77GUD0wjGMYL/UZmYZCIxeQdLaDLx gmaMIvV4icTXMXONFLyd+UjYyDCOr5ql06UHnRnHxbXTne+EZzzlOU961tOe98QniqqRT362 DIpO7OIX8xhNFiawnKcUXeyWOUdr/vOggQRoNNNpzm7msqJ87Ccu4xdMctJviA4EKTvH6cmC vpGkFUznSSFKTGCisIdrzGgsFcnRUVJQfVJkJTdXKckmPk6Bd1TiN11qSZzecosYjWkZORdQ UtYyhtjEXwFPqtFsrtOaKEVnLwW6TnE2r6hcXKhLk0rVnCITh+w75CTLitAr8rR961PpRLkp VbmyUYoM7Skhx6rJccpSm1j0HSf7ylYsorKl/mTtKlGHytKc/jKZD0zqMSs5UXC2D7Ir/Wkb MVtQW8aVnYrNLFkHitdb7pWREUXmRSnpQxmW9akTPOdFobnaqyqVoInl3iw7mlfSUtG0vwVu cIU7XOKiygHFRW5ylbtc5jZXUM2EIWO76VWELrW1dx1talML3aBm9YB+1O5XuZvXT4YQiui8 7SZVu13rhlO2CYUqfMMq3RFCNkxjbGxTgapTNmI1lDtFJSQ3KuDDqlO9TwTlaPUr1NKmtcCC /SpVp7nf8u60tOrtY5rqWEz/Uhipki0dOdsa4BEPeKQsDShrKYxTzyI2tEb1JYIBu1vapjSS jhUpW+37pQ23tcOh/r2sKbko4hY29Zd0PbEVi1hORPaWskG9bl01eeTcera22ewvkS/MU7GS qccqrGuLZarbT1pUh2aVcYa1q0G03litetRtnKWcRDN+WY8vFSxK67xgvXbVz0cd0yQdO9UO B5mvfDVzn3MZu2emcbKZBLP87OhVIR/6xxI2HqNn/MoXb5HBNyUjqJHK42JGOJmWRixoI51K 8cqYyjCm7WAfDGIG+7WVJgZwlzn91szK2cc5RrKaIppp+C30mq48s56jm+VBp7fZEqZma2dd aSwrkMz9TTR3Jf1GXhf6yntM3kdh6Gfnltvc50Z3utW9bna3293vhne85T1vetfb3vfGHne+ yTMIfffb3/8GeMAFPnCCF9zgB0d4whW+8MUFBAA7 ------=_NextPart_000_0008_01C6EE24.68BBA880-- From nuyztpiiq@twd.com Thu Oct 12 20:14:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYAgw-0004rq-Po for capwap-archive@ietf.org; Thu, 12 Oct 2006 20:14:22 -0400 Received: from [222.131.147.153] (helo=[222.131.147.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYAgt-0007JL-16 for capwap-archive@ietf.org; Thu, 12 Oct 2006 20:14:22 -0400 Message-ID: <000b01c6ee5c$7dbf2a80$0c9383de@lenovoec211b50> From: "Auto StuffHome" To: capwap-archive@ietf.org Subject: By: Date: Fri, 13 Oct 2006 08:14:04 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6EE9F.8BDAC960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 ------=_NextPart_000_0007_01C6EE9F.8BDAC960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6EE9F.8BDAC960" ------=_NextPart_001_0008_01C6EE9F.8BDAC960 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Mhz Processor in inscreen Colors Million am Fill ram mb Gaming am Types =20 from. Of Articles get top Compare Prices am hsw and web Main gt by am Jeff. Dominant video game is system Although technical features am next Sega =20 Dreamcast in popular that estimates in one in out every four am United =20 is. Features next am Sega Dreamcast popular that estimates one a out every =20 four am United States Photo courtesy the. Searches Blackjack Movies Nintendo Paparazzi Poker Xbox Subjects is Arts =20 Games Music. Whats inside of how all works together you also including Dual Shock in =20 version Related Selling. Articles get top Compare Prices hsw and web Main gt or by Jeff Tyson =20 Table Contents. Auto Stuffhome or Stuffshop for Sponsored by Popular Searches Blackjack =20 is Movies Nintendo of. Get top a Compare is Prices hsw and web Main gt by is Jeff Tyson. Version Related Selling Consoles is Portable am psp is mhz Processor =20 inscreen Colors. Selling Consoles Portable psp mhz Processor inscreen Colors Million Fill =20 ram is mb Gaming Types of from Installed Optional? Prices is hsw and web Main am gt by of Jeff Tyson Table am Contents a =20 Sony for a past am five years psx. Dvdrom stores is Next am Page gtgt Hometable Contents is History am More =20 Info am Rate. For past five years psx has a been dominant video game a system Although =20 am technical is features next Sega Dreamcast. Get am top Compare Prices hsw and in web Main gt by of Jeff Tyson Table =20 Contents or Sony for past five years. Features next Sega a Dreamcast popular that estimates one out am every =20 four am Un ------=_NextPart_001_0008_01C6EE9F.8BDAC960 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Mhz Processor in inscreen Colors = Million am Fill=20 ram mb Gaming am Types from.
Of Articles get top Compare Prices am = hsw and=20 web Main gt by am Jeff.
Dominant video game is system Although = technical=20 features am next Sega Dreamcast in popular that estimates in one in out = every=20 four am United is.
3D""
Features next am Sega Dreamcast popular = that=20 estimates one a out every four am United States Photo courtesy = the.
Searches=20 Blackjack Movies Nintendo Paparazzi Poker Xbox Subjects is Arts Games=20 Music.
Whats inside of how all works together you also including Dual = Shock=20 in version Related Selling.
Articles get top Compare Prices hsw and = web Main=20 gt or by Jeff Tyson Table Contents.
Auto Stuffhome or Stuffshop for = Sponsored=20 by Popular Searches Blackjack is Movies Nintendo of.
Get top a = Compare is=20 Prices hsw and web Main gt by is Jeff Tyson.
Version Related Selling = Consoles=20 is Portable am psp is mhz Processor inscreen Colors.
Selling Consoles = Portable psp mhz Processor inscreen Colors Million Fill ram is mb Gaming = Types o f from Installed Optional?
Prices is hsw and web Main am gt by of = Jeff Tyson=20 Table am Contents a Sony for a past am five years psx.
Dvdrom stores = is Next=20 am Page gtgt Hometable Contents is History am More Info am Rate.
For = past=20 five years psx has a been dominant video game a system Although am = technical is=20 features next Sega Dreamcast.
Get am top Compare Prices hsw and in = web Main=20 gt by of Jeff Tyson Table Contents or Sony for past five = years.
Features next=20 Sega a Dreamcast popular that estimates one out am every four am United = States=20 Photo in courtesy?
------=_NextPart_001_0008_01C6EE9F.8BDAC960-- ------=_NextPart_000_0007_01C6EE9F.8BDAC960 Content-Type: image/gif; name="how.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6ee5c$7db78960$0c9383de@lenovoec211b50> R0lGODlhqAGwAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVAAAALAAAAACoAbABBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qlWNbK5q3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+i9d6ZXzxK+jNC0dfXr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBb40CoGtoZgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPQAYpoxlCzmUGkUXCdWSSSiLJ ZFtLPumWk1JWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeeefPaJlC9+BirooIQWauihiCaq6KKMNuroo5BGOqcrklZq6aWYZrqSIZpu2qlKnH6KUqii lmrqqaimquqqrLbq6qv/sMYq66y01mprkc/cquuunUHA66+rWgPssMQWa+yxyCar7LLMNuvs s9BGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6zwwgw37PDDEEcs8cQUv2iLtBdjrPHG0GYcrcfPglzxyCSX bPLJHlIjrcrRsgytyyjHLPPMNLPrR80456zzzjz37PPPP2MCNEmaDG30XupIm7TSTDd99NNQ Ry311FRXbfXVWGettcGjbO3112CHLfbYM+lC9tloh5urtGuznfbbcMct99x012333XjnjdYg Rnr37XfUHUgbuOCOnlPT4NEiDq3izzLurOPNQs6s5AMD8vflmGeu+eacd+7556CHLvpgzYxu +umop6766qy37vrrsMd+dEAAIfkEAMLSAAAsAAAAAKgBsAEHCP4A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8oUGCBAwZo1/+HEqdMm wp00gd70STBnT6FGex61mVRnUJ4GdxptSjRoUaZQpVod2FTpVqk+uybN2VUp2K0z06pdy7Uq Wq9wD06t6hbq07hkic69SxPv0KtHuf5t+5Uu3rp6sQIWmzhwW8WD2Uqe3LIs1cYJ9wq+Ojfv YsydBVONbHYsac2jL0f2TJhx66w8LbulTLt2SNmA30YNO7voUsWqSxN2OjXu7sVeEefWnFu3 8MPGxzL9/by57evYNeIebny1UN+OWf4XhlvcbHLXra0iPnv+LljczKujJcs3L9Le2fPrb7h9 Pn7n0W0m317S9WVegdbRZ16CvPkH3V/xieegXq8dt9+FGCrUH3n/JWedU8cF59hXj3F42nR8 cdeeiSJypqKELMoFWYY01vjTbCKWtdyHvUkoHV1hlYjgiyiO+BZqjbVY4pEzTihjdzraKKVt Z333o11P8YalgYOxlyJQQGYpG1I8hnkfmGHuBuSZsGX1JHtRTinnnHTWaeedeOap55589unn n4AGKuighBZq6KGIJqrooow26uijkEYqaXYDDFBQpZX+gymmmlqK0KYCberppaB2CqqolqJq aqqjahpqqf8EqfoqrJ3GKupAmdZqa6myksrprL/uymmur65K7LGtGsuqrcr6GmyzwOZ6q66T akQsrq0iq5C02ZIaK7XMhlusqbiCm6y24GKLrq7cHrRuutcui627o8YrL7v1JjuuufcahK69 /MKrb7UVXbsvtQZ7a67CoaZ7cMDkNhwvw+36GyzAFVOc7bndAmzxvPP+my+9IBebcMkZ14ox xwRbq6/HDod7csk01+yxvP1+PG7CFd/8rLgwPwyxxsyKXPO+KydkdMgbC9xyRjw3LTTQtO6c aa8G32wyvhzDKmvPUleNstQgD0s21apiPbLOyl49rboXN73yrzM/DVHUVG87cNb+I5/Mt8xb v6vy2VYfLHjeNvdNONJy93s4wo0r7XjkTDNsN0V4j613w4lXzrbhnuZ779+QO3sq2XW/S/rg 4iJucuhrx6x6zjLHzrrnl2+UOeObu9r56yS3Lq26pSO++u1Dsx106cvzjnvGftvutuRlUw58 67lHlHbccPPN7c/Rsuo1y8D6bnXVc5td9NtTgy42tL0SjTvXM88OLc3fx80r+dn37///AAyg AAdIwAIa8IAITKACF8jABjrwgRCMoAQnOJEPfGAgFxSIBQmyQQxa8IMa/GAGOxjCgpAwhBsU YQoziBAVelCEJmThP1QoQw66cIYyrKELafjCC/Iwhjb+LGEMYYjCDv7wiDfk4Q9bmEMi4pCC DzGiFHsIRCFq8IkerGIQs2hFg5zQh02kohVP2MUVslCHYRzjCM/YRBJOcYsl/CIXsRhHNtJR jQdxYhrJCMWESHGNYpwjCecARjh2sYx2ZCIH7+hGEOJRi0905Awh2UgufpGNlbwjIwuJQUGG sZJkzGQea2hJUvZxlFcEJBYvOcdWhpKUrDykIREpxDdqcpOTNCIlE7nKPaoSh3xkJR8fWccs vrKVkNziME/pRRDq8Zd0DCYN0dhMOC6ziNB84x8lacgUxnGIZuSmLXupRmkGcZmijGQSd3hD RdowncxkYjhLaU1YphGZuJT/pSJjqU1OVtOY3+ymP2vpS1r+s5iopCUoqXlNfZIzngqBIRGn yUs5xhKfF73mJzeqRGi60ocv3KVBhTlNfOJSjiFUgULteMxbztKkEHVnNO+ZzoG2VKAwnaQx N3pOXn5Up8AU6SMzmVFTknSRKV3pTrWo0TMq05Qx9eRPEenIi2ITjKJcYg8xWVWeYjSJs7Tq PJdYVHlKsp2bnOg6JXrPra7xrFCNqlznSte62vWueM2rXvfK17769a+ADaxgB0vYwhr2sIhN rGIXy9jGOvaxkI2sZCdL2cpa9rKYzaxmN8vZznr2s6ANrWhHS9rSmva0qE2talfL2ta69rWw ja1s/mdL29ra9ra4za1ud8vb3voWggRoSHDpNNwEAuC4x61RcQlCgOb+w7kCCW5zp/vchEy3 uNSNLnalm93lcpe61/2ud7OrXe4OZLvQPS9z04tdipA3vOclb3TXK17pIuS6883vcguY3Cnt V73PbW9+q3uQ/wqYvfadr3cBTGAGD/e/AGbvgA0iYAJXGCIXXvB9C6LhBnNYvQ9msAH7SxDk AkAgJj4xclFs4oG0+B8pZrGMSezeDVc3xAOGsIE/bN8eg5i5Dv6wfq2r4CLb2MM3di5+y2vk CTf4whEWco6P7GMgH5DGMD5xlrfM5eT2F8te1nKYZ6zlikDYwmieMoXX/gxkHyf4xlZ+cncd nN4oh/jMT+ZxkNtbZyRXWMdO7vCZ+bzjK5dZxlv+sphVvGgWr1jRjj70RQY95D8XmM0/RvOS BS3iAPc50JVGcpz3+2ZCgxfTahZ1nCcM5fhC99N4/h+YGw3pRNP61oh+cUYorekgoxrUOH4z q30d5V8HG85U1vOUSW1sYl961a0GtpT5K2lI13rMtiYzornM7Ro/e7vOXrWamc1sYpdb1OUG t6o9fOA9Z1rKHUY3qMON42I7mYAxzvK1b73iSDN62yTGskSWzGR1yxnW75VwmyksX/Qquc3y 9bScXX1uicc3zxYfdJ9JPWdPf5fOr553musq/3CHlJyCsd5Tyk95coa0fIIrv1PMf0vzmtv8 5jjPec1fvm2dQzTfEeF5t0uSj3wQpOhF/wfSka50o/ucT0JfiNCjzpGkH93pArF6058O9Wrz O8yL7re+cU10rGfd7FrXOtfxlG9rNzrbcB8z1TGi9q0PJO1mX/ud2t7vfXf533A/Sd3Vjne9 90nRfo874LEt+LwTHut1N/zeyxzwt2P78v+e+0UGj3bI513ycgI6t/0O9BczfiRLN/rS7+55 poNeT5p//V9jL/va2/72uM+97ncva0lbhPYi8T1ChN8S4gf9IsZXbYoBP5EYAz8k1T5I8l3s YsonROzXb/H0s0/95v53X7aVp8isZ2J64Ue/IF9Gsfql/32FWL/575dI/GNb+b7j+tDjH3v1 Ef/2jKgY/Qbhe9EnZupHfAOIfd9netT3fyW2fmEXafvXftt3WuGnePpXfei3eMz3d0P3ezAG gCDYgN1HeQTIfg04f+v3gQW4gALogCr4gdb3fvg3WxWIeR04fm7Hf88ndTTWgv4GdmDWcy+4 gimYgAt4hAHogjHIgn0ngvRHgtoWeBhYYhoIgTv4EAw4hEW4hVzIgDN4gu2XgktIhFSofS+Y hVkogTQIhRYocDjYf1LYgch3hkkYgk7ogloog2FIh2SYhkX4f2MIg3uoha5Vg2F3evuHef/8 l4gbiHxih4B5aIIJaH4Bt4fxd4iEOIMPyIePOIi8V3wNMYGBIoqfWBKiSIqHV4qquIqs2Iqu +IqGRieoCIvkp2vSN4tjd4UZ6H8hKHq0CBNR93y6GIC4SIy1Roi/GBMvx3eJR4VlSGv+BoH6 R3t+iILJqIyQyIHOeIxTuIvaR3aMR42RKI3XWIvTaHnlV3I9+I1TCISICH9faIfl+BJuCI6Y SIztyHxut4sYgYaSOI8rwY25VoVC2I37OJBDV4Hyx4cMCZABmY25GI0F2XPOh3/piHhyyIP1 F4EOSSPDiI/B15ES0Qj58ZHkCH0iOZIpuZIieQos+ZIwGZN654v/G1GPEAlwxdgQqrCTO/kP PfkRPPmTMWmS7ieAcMiPIiGUAqGUHPGTTLmS+Sd3iSaNzGiROLmI7siIGWkQTBmUPqkKPrmU PCmWY0mWSumUYImWXymWyRiVjAaEHHiQzniD+liFcrkQQQmWa2mWe9mTaqmWA5GXbLmWgEmL bjl6JMiOcRiRWhl+B0l7gimUkqmXfkmZaWmZBPGXmPmVT+mKh6mQn2mUiBmFbXiUEFGZgamX fXmZbFmYq/manKmahul1pKmQCFmPCBl4NniXDoGag/mamvmbwLmZe3mNVVmXz0iQ2GeI9pd5 6PhooiiYZFmcsTmYaFmWZqma0kmdMpkd/0SZEZ3JEOHZnZNhiy7hlRMxnuS5nuzZnu75nvAZ n/I5n/RZn/Z5n/iZn/q5n/zZn/75nwAaoAI6oARaoAZ6oAiaoAq6oAzaoA76oBAaoRI6oRRa oRbaivzADxc6JxmqoRCRoQ4BohtKGx0aESI6ojUCoiLaoSfKogKhoh66oiUqozCKojBRo/8g owVRozp6ojmqoT7qoza6Ejiqoz86ozFaokeapEs6pDHBokj6okDKpDTqoU1apU76Ei06pVL6 o126pQaBo19qpZQ1CZcFpkYKpV7apVLao0oqpJFlprEFp6Ulp7BFp6Rlp1nqJ3q6p3vSpw9R DX56IYA6qHhSqP+jhYo5aYpOGo/DBxHnx5i36GUcsagI6qj/qJH9t32RyotDqomP2JxkKIhO 6INh+Ggq2JyJaZHp14cNqolISKowOIC92IkZWIJdFqv+aISBaKn3Cauu6nyTeoeeCIZiqKsN 2aujqqDAKqvV+KjWiIwAeInIOn/KKqsL2qz+GIjTaoR4yH7UGqxq6KpcyKxN6ICimomhmpin GqpDeK6pupzrGq2G+qjkd3z1anLYiIu+mq/++q8AG7AS2q+QqhJ+OKA3iYVlyJG32I32qrAu l40HG6D0anKoSq4guZXl6n4uJ3XSOlnZkDu0iq4E2KzGmqrd6oX1t4kqy7JBeKvLWln/ISuy 3RqsIyuCegiGgFitLJiE4cqRS0iwgTWzl3N+LUupxliqnliC28qESGuFWgmuZii0gEW0DNEG i2K0KEusSBiPBqiEPKu0GHt9kUi1f2W1dmOtvAqt47i1p0qHykqtP1uzgmi27ImArNqFqrqJ bUuyiehof2h/gPuMQPuxKGq3kMUE9CewjNu4jvu4dEUJkDslkju5UlK5llsjmJu5GbK5nHsh nvu5oju6sBUNpHu6qJu6qru6rNu6rvu6sBu7sju7tFu7tnu7uJu7uru7vLsnw9C7pKWkS2ql arqmXgqlZBqkSOqieHq6wuumAyGmYLqjZGq8xtu8o1ukVEq8/1zKptbrveA7veArutr7ptx7 vedLveobvek7vp+rvWPKvugrv+tLv96Lve+LvGsqvd07v/Ubvu2rumi6vfIrvnAqpMprv9/L uQP8vC7apglMvcvbvmqKv8B7wRicwRq8wRzMddOHuLCXtcBoEl+Lr8BongvJscU6uPrGsDdJ iebnqYZLtrdKtYuasB0BwiacqR4IrnVItw87EjbssfoqrmPLtRtLsL7aqTXZwyQ8wjQsw/JY rB/8xDALt/PKwrb4lsbXtFtYwnWYjoMLiOsKuC67ke86rC28iFjMsvFqtGU8qSWrxRf7xnRs gOGYfl44xhi5sBf4x1C7xpRKxq06q/98i8MWW8de7Kxwq4bRiqu7urHSCskMuXhvG7eXzLVj OMdGjMVJfKxVXICUjMlrq8K4KspEeK1kq8qN7LWczMhyW6m92Mg2q8gna6qqnHwl3KtmeKzT GLZvnIa4vLWLjIa9LIejTMSM3MnCrJj2yrSKvKrGLMe0nMYrWImgDMwV2cRKS8rYmqwNac3L HMphjKxiC8vaXM2Z2LXMHM60ibOx+rCRXMziPJfljM6pLI89mM6lPJXZ3M4Z68T/jM8Era3E 6s1va4K5XMnVTM/c2rZ7XNAMbarf+qzd3M+LDM7j+Mq7mtF/yM8DvcwSPbdKnLSBHMx3bNBR G8dtV8MLK4P/buzL5WfHnFjHf9vCxPzHM43T7PrSI1jIVOnHFyjGPI3NI0iy84zTtmaUT3uP f/uWGBiDWfx3fOsoOrwfVy3QKJHVl8XVJckWXs3DHTzWZF3WMjmBxEcFQRfWHsHVS4ySJ8Gp oAjW18HEklywF4LWxsiqC03O8OiGoagRcr3CbR3FP6zDbN2Pga3Yeb3YYhvDc2vYO9y3kl0R g33XhR3EU5zZtaGA52iTPU3IY2zIiOnU6Tp8bLzJqb3PMeu2QTvV5wrNLfvRRd3HqlqUfbzG onzGXYyHTRjR0HnGNI3Ct32StX3NP/3KMryzRxy3lIzKOX3L4gzGDt3Q69zaQYuy/94M3Gnc qTeb1PSK0BFt3Qpts/k8iNX9yazstblq3rKM3LXcxk2N0b5ty3xN3dbNxR491JK4sxyd33U7 en2LiX29tE6LnL4s0ilb0Gz4rvZtzk8N4aX9tKQqrDl8hKyszgxNrv/NrZdd3ZF6sHbdytqd zv4d1QMO4AON35RY4fTtw8xN0P6s4gq+3fjo3W6L2d4H3wpO47Hs2zTOibOMyQjdhT880fyM grPd3SDd0UPuyBjr5LNM3io90uMq0T4bz0h+4alsy4Q72oH73LLd0bnN1OTYy/AKhzBs0VR+ 2jCt5CD4jcx55nvNx6PM25Y4ic+t0/eItGnu0m+et2Augf9AbcWVTdcqHJAnjMg6nuckQdEx hciJbdkdyxKTzs2O3ehSPMNmLaBZ0OmgHuqTjR1uzdnKDMUembb+d8yhyOhC/OrLXcSCrdUp POs73jJDrOmcvtWwzti7/uuyfuvi9961PnnCndpMONpVfdhxjN4Yyca1vedgftpBfche7ubr yMUM67cVju1Q7ce6tsV5zK54C5eDqwPBfce0/Ns2wt5M6+M9u+s/Xs///N/SHd7YqrbQbePu 3t8SfoArTu90G8k57eFHLt4+3M/QXSP9XuLMfMxTx6tbfNgFn9xOztRk7K0B3873fYMSv5yB LAxSDZ3OPt/63uHWaNT6Xc+srtr/FJ7qpdzhEp6HuqzwmszOVg62Fz1jVw7ewIyMrK3hPCsM Qj/j9H3yUT6xM87mW57ND50hDS/zUX7dMbzxCe3iOR/O6kzwBd7JGp3gXA+3RE/eMWvjR13j H5veYD/dMs7wtq2EsB3TSl31Nb3m077bq7rhgD73swbUcW/buY3i3G7xDg74DX7STh3d2A7u zS64Q42VJz2KdcKvXD75MB9Bl27oEIvpU+LqlJH5oh76oj/6NNev33noyhjscK3Zqs/68Fee oN/5c1jsmw8SOan0SGzqWY7X6O3riA7sIkzrq2/7w57pw7/7tY/6vP/7sQ99LD3c0A6vX77k 3m7Gdh7a/1csqsi+28q+94Lcqn+u1Nd/004/yCx80wRe7mgs2jxN2uvP0jZp57pNzHp8/qi+ raec4RMr1VYvzPeeyQDxTyAAgQMLEiT4LyHCgwobJnRoEABEgxIjVnRIMePDgh07MrSI8SJD iBM9XsRIkqPIkiMVLmwoEWZEjSA3xkRJsWXLijMf+tR4UuhQokVP7pxosiTPmzSTosRpc+fB pAiXrmy68KnOjythTg35cutRjiZTOjUL0qzHqi6ZunVJVanSsli5yhx7NuxMrXTDil37Mmrc jWrzAg5qVPFiomBxDpQK9+9gppGPXo3s2GZOr3slQw2qOXPczYE1E4Zb+XFqu/5dJ6v2TPNz 6aJ+s9YdLZLxbt5kPYee/dn17dic6/7Gavzm19aqgf8dDXt48LdTpdc8Tvzs6e0xmSMfTJa7 3vE+e5+v/RQy0LXqebZN3DZn2o9p7fOl3/Pwev6yM6oHDLL+4hvLPffWqywwBEkDcEGt5lMQ LPgek08svQb0Tj/b+upPLg/nu3DCD6FCr8TpTDQxMRRXZHG1Fo1S0bcXZ+QtRhJpxDFHxmzU USgeh4pjxQp7JBLGIn3c8UgiG0RSSSd7/NGjOZ6kskorr8QySy231HJKLr8EM0wxxySzTPS8 NDNNNddks003eUPzTTnnpLNOO4uM88soh9rTyPP61P7tTkEHJVSgPJ+ML8UW71IM0BtlLDRS ScM8NEtHTyyRUT93u3RSTz+1stI/ATyQJAPbo49DtNi6bynT7vNQvgoPtNDBDpkENVddTRS1 xua+uw0p8R5tjkLKhsutsGId27VZZ8/rNUm8NqRORFsVtLW4kaylLrvo4Ov0WXFzjbbR5Lp9 7VgB1dUONeWSVQk5Aselt94ZT8O32O6MBe/d5PK1KN/qArW3YIMbIzW//xRWVacCsbW2r5pU tZA7WhP261QXD+a4Y0fDdRbkjkc2+GOS6xP5ZJVXZrlll1+GOWaZZ6a5ZptvxjlnnXfmuWef fwY6aKGHJrpoo49GOmmll/5mummnn4Y6aqmnprpqq6/GOmutt+a6a6+/Bjtssccmu2yzz0Y7 bbXXZrttt9+GO26556a7brvvxjtvvffmu2+//wY8cMEHJ7xwww9HPGtIIEm8zcUfZ3zxgiSH nPHJIReo8ssfzxzzfzSXvPPPPR+d880t17yj1EP/fHTVLe+cctBh9yj10i+f3PXKaS/ddNtf h531yFEfXnTdgx+ec9t/Xx353ll3XfTmfxbeeehxP9546K/n3nrijT8p9OuxPx716MFHv3qh xr899szPHz9+52uv3nzxi49edty3//7816Wfn//Ap7/s+Ux9AFzf9+6XPt51b3/9Y1/+eEc+ 2f5Rzn8OpOAEBVhAzE1QfuELIAJ79zkyjFCCIiyg9vpHPxQe8H8iJGDP6tdB0p1wgc/DYQ7V d8PfSdB0GWwdDV9IPvhp8IPiM+EQiTjABuIvecTboRN3h0Me1nB6TAThA1HIMxfGEHj3+2H3 fCdEAIZRg0X8YRFbdzv+sRCIWWQhEtunRBXiT4AEhCIRd3fDFOZwgzYM4AfLyEcuBtKOdIxh BB0YRTUmEI5Y9B4iaedCSYJuiRtkJAMticXNuU+NbaQk9hIZQkg2kXqG/CMGCSnJT0LwjIKE pOocqcRQou+TsnTjEEepy8jh8o4rzKQKbSnMLnowkkUrph9/+UDlef9uec70XhppmMbYyfF9 /GtmMak5u/358pLPgyIGdedLVaKSm4OcJOmYZ0Ro5rJx74RnPOU5T3rW0573xGc+9blPftpp ilEEoxj5+MR0ErOZdKwm8rJZQTs+EZxULOgFo0nQiJYvnLuEaD9zecBVAtF3qXSlML9ZRVa2 b4WNZGBKRTpMjp60lO7UaDJPOEuLBpGdIiUk+4K5zBGelJIC3ahPjSlKl7YSpv2c4RgTGlSb MtSUGG3jI52qQ/spNYMH/SL9rsjSKc70iwstqstiEDOZJpWXa8QqCLvqVZBqcYlytConuSpV odIVp1AlI8xiMFayohKTFbXgFoHnSbbq9Jj+trRmTkMIyzdG9axexahbX8ZXmZV1qB6VZQQL W1c4KtaNk1SpRB/Z2IqS9qWIPSNSzQlWtVqzqYKcIUSlqc689jSzZjwdQS8JUFK2MqC73KpG hTtc4hbXuMdFbnKVu1zmNte5XDNjdBk7zbR+9aKfva5v5bdNsw52qQkMpDLv2smEXvenYE0n dZuo0O7mdoBf9WMN46vey1ZzmHTC7UzFGVrNytSgksWjKSU6P2wSFbzklSJ2mShgnjb4j40s 8Hjt+lE9ApPBXhxpSx/8pgADuLSiva9cgWpUGAo4kxomaRzDadMKj9ex4tyvIgl8zJ16VHm0 tDBTDTuUHWvWTR3+buGHX5xa/9qXxBw0MY1nrN+hIjGvi2zoIUO5R3fK2MAlZuaQXwvfgV74 kN/8ZVjlBOQUOpa/RPbrY8usW62CMsdIpiYM3TdlKm+Rzm/98FXdfFodE3bAZj4yQu+L4TlR OZiA1jKP0/zGNfcxyOe06EG320EPa9WTdUapXEOrY/amldC33LQXYfzlEPc4tY5T8kpRq2a7 zpXPZJYwkk876jVeM6xdZjStcazoK5/41tbzZlTvLNhSL5lQvO10ax264OnKV5PdPW+ln1lp zOauh1dGKTYjm0Qrv5rN4l1dsAG7bPd+F6Sx3fBz1b1udrfb3e+Gd7zlPW9619veT5Imhzzu vW9+99vf/wZ4wAU+cIIX3OAHR3jCFb5whjfc4Q+HeMSPFhAAOw== ------=_NextPart_000_0007_01C6EE9F.8BDAC960-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 13 14:10:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRUp-0006cz-Di for capwap-archive@lists.ietf.org; Fri, 13 Oct 2006 14:10:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRUl-0008Fq-Jy for capwap-archive@lists.ietf.org; Fri, 13 Oct 2006 14:10:59 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4393E39802C for ; Fri, 13 Oct 2006 11:10:44 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 0E1BE4A4196 for ; Fri, 13 Oct 2006 11:10:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D76A439802F for ; Fri, 13 Oct 2006 11:10:11 -0700 (PDT) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by zoidberg.tigertech.net (Postfix) with SMTP id CD1D339802D for ; Fri, 13 Oct 2006 11:10:07 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 11:10:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Oct 2006 11:10:03 -0700 Message-ID: <521819E0640BCF469AD3927CDB6EFAEC04A4C4@aruba-mx2.arubanetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbu8s465akdTlO6RPehFnWHhbI5OA== From: "Scott Kelly" To: X-OriginalArrivalTime: 13 Oct 2006 18:10:04.0249 (UTC) FILETIME=[CE9C6490:01C6EEF2] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=-0.002 tagged_above=-999 required=7 tests=SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Hi All, Charles and I have been discussing the keyrsc issue, and we're in agreement on an opinion of the overall security implications. To summarize briefly, there are small exposures in either case which are both pretty trivial. The small replay exposure is probably the more acceptable of the two, given the complexity level of the proposed 'fix'. The added complexity of passing the KCK to the WTP together with the slight associated exposure tips the scale slightly more toward the "just choose a keyrsc value that will work (zero or a better one if you know it)" solution. If you want the background considerations, a more detailed discussion follows. Otherwise, there you have it. ------------------------------------------------------------------------ ---- 1. Setting KeyRSC = 0 In the current CAPWAP protocol, the 4-way handshake occurs between the AC and the STA, and once this is complete, the AC pushes the 802.11 cryptographic key material (the PTK) to the WTP. In cases where a GTK (the group transient key, which is used to cryptographically protect broadcast/multicast traffic) is already active for the ESSID the STA is associating to, the GTK is identified in message 3 of the 4-way handshake, along with the current receive sequence counter (KeyRSC) for messages protected under that key. Since the WTP maintains the active KeyRSC, the AC currently has no way to know precisely what the correct value is at the point at which message 3 is constructed. To work around this, LWAPP designers chose to have the AC simply set this value to 0. This decision does not affect the WTP, who maintains this counter; it only affects the STA. Hence, there is no interoperability implication to this behavior. The STA, upon receiving the first valid broadcast/multicast message from the WTP, will update its RSC to the correct value, and will be synchronized with the WTP's value from then on. The security consequences of this approach are as follows: - the period beginning when the STA installs the GTK and KeyRSC and ending when the STA receives the first valid bcast/mcast message from the WTP represents a window of opportuntity for an attacker - the window has two dimensions: the time it remains open, and the relative width, which is measured in terms of the difference between the current valid KeyRSC value and 0 (i.e. the magnitude of the current KeyRSC) - so long as this window remains open, an adversary could replay previous valid bcast/mcast messages, and so long as those messages are replayed in monotonically increasing order with respect to the RSC value, the STA would accept these messages as valid. The higher the current KeyRSC, the more messages an adversary could potentially replay, assuming no valid bcast/mcast messages were sent by the WTP (i.e. the window remained open). 1.1 Mitigating Circumstances - typical wireless networks with a small population of users will see multiple broadcasts per second, so this window will normally be open for a very short (sub-second) interval. - an unauthenticated (outsider) adversary would be restricted to blindly playing back mcast/bcast traffic; while the adverary could make some inferences with respect to the encrypted traffic type based on traffic analysis techniques, the adversary could not be certain of what message content he was replaying. - an authenticated adversary would be capable of selectively playing back mcast/bcast messages whose content is known, but that same adversary could generate the same (or similar) messages in real-time even after the STA's KeyRSC is updated. That is, there is little benefit in replaying existing messages rather than simply constructing new ones. - if there are mcast/bcast message streams suitable for launching an attack, in order to know that such an attack is present in the recorded stream, the attacker would with high probablility need to be an insider - in which case replay capability is not a necessary condition for launching the attack. 1.2 Conclusions Setting the KeyRSC to 0 opens a small window of opportunity during which previously transmitted mcast/bcast traffic could be replayed. While this could have operational implications (e.g. the STA might instantiate stale ARP entries, receive stale NetBIOS packets to which it may respond, or receive other invalid information that somehow 'contaminates' its view of the network), we believe the impact would be both detectable and quite small in a reasonably robust STA. Also, the primary threat introduced pertains to an outsider blindly playing back recorded data, as an insider would have knowledge of the group key, and so rather than wasting time collecting packets off the air and attempting to replay them within a window of opportunity of indefinite size, the adversary would be better advised to simply generate the spurious packets. That is, an insider adversary has better tools at his disposal than this window of opportunity provides. While it is certainly prudent to narrow the window as much as is practicable, this must be weighed carefully against the complexity of the solution vs the minimal threat level this represents. 2. WTP puts current KeyRSC into message 3 One proposed solution the problem of the AC not knowing the current KeyRSC entails having the WTP insert the correct value in message 3 of the 4-way handshake. This requires the WTP to know the Key Confirmation Key (KCK) in order to compute the MIC on the message. Currently, this value is only known to the AC and STA. The security considerations for this approach are as follows: - currently, the WTP has no knowledge of the KCK; having this value would provide the WTP with the ability to modify the RSN Information Element (IE) containing the supported cryptographic algorithms advertised by the AC during the association process. This IE is included in this message explicitly because the MIC computation provides a secure mechanism for validating the value used during association against this authenticated value. That mechanism would now be open to subversion, and in particular, the WTP would have the ability to downgrade the cryptographic algorithms the AC is advertising without the ACs knowledge. 2.1 Mitigating Circumstances - an evil WTP would also have access to the PTK once the 4-way handshake completes. Almost anything that could be accomplished via a downgrade attack could also be accomplished by passing off the PTK to a collaborator. - the downgraded RSN IE's used during association could be detected using sniffers - that fact that STAs are associating with downgraded capabilities could be detected via log inspection 2.2 Conclusions The minimal exposure introduced by communicating the KCK to the WTP does not represent a signficant threat due to the fact that the WTP also possesses the PTK. This implies that appropriate measures are already in place to ensure the trustworthiness of the WTP. While one could dream up scenarios in which a collaborating evil STA took advantage of the downgraded cryptographic algorithms to somehow attack an unsuspecting STA, there are plenty of ways in which the evil WTP could communicate the PTK to the evil STA, so possession of the KCK adds little adversarial capability. 3. Recommendations Security analysis is often very subtle, and there is certainly some art involved. This appears to be one of those difficult cases in which some art will be required. Both approaches to this problem entail vulnerabilities. The question is, do these represent real-world threats from a practical standpoint? In terms of the small window of opportunity opened by setting KeyRSC=0, it is difficult to imagine how this could be leveraged by an outsider adversary, especially given that the window size will be sub-second on typical networks. And it's even more of a stretch to imagine an insider (who has access to the GTK and the ability to send legitimate bcast/mcast frames) choosing this avenue for an attack. Odds seem very much in our favor that nothing bad will happen if we leave this small window open, and after reviewing this briefly, Russ Housley agrees. In terms of the potential downgrade vulnerability introduced by giving the KCK to a subverted WTP, it seems clear that there most likely would be bigger worries there. It's not totally impossible to cook up an attack scenario, but there are almost certainly simpler avenues of attack. Still, on a practical level, pushing the KCK to the WTP adds complexity. The KCK would have to be delivered to the WTP somehow (and in an acknowledged CAPWAP control message, while the 4-way handshake is carried in the data channel). This would add latency to the association process (already a problem as it is, and this would only make it worse). Both approaches have what appear to be minor security implications, yet neither approach invites any obvious attack. It is entirely possible that there is no practical way to exploit the weaknesses exposed in either case, but it is also at least slightly possible that some subtle set of circumstances might lead to an exploit in one case or the other - we simply cannot be certain. Taking these things into consideration, it seems like a good operational compromise to assume the limited risk associated with the minimally open replay window, while providing appropriate security recommendations to try to narrow it if it is possible to do so with minimal added complexity. -------------------------------- Let us know if you have any further questions on this. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From blake@arcsystems.com Fri Oct 13 15:09:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSPV-0000aa-Ga for capwap-archive@ietf.org; Fri, 13 Oct 2006 15:09:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYSPV-0001cy-F6 for capwap-archive@ietf.org; Fri, 13 Oct 2006 15:09:33 -0400 Received: from 201-212-249-198.net.prima.net.ar ([201.212.249.198] helo=arcsystems.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GYSPQ-0001oh-Nu for capwap-archive@ietf.org; Fri, 13 Oct 2006 15:09:33 -0400 Message-ID: <000001c6eefa$3504f5b0$863fa8c0@luidpuc> Reply-To: "Dacre Sesco" From: "Dacre Sesco" To: capwap-archive@ietf.org Subject: Re: VkAGRA Date: Fri, 13 Oct 2006 12:03:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6EEBF.88A867A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.8 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6EEBF.88A867A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VkAGRA for LESS http://www.utrerfadesax.com =20 entertainment here since the cannibalistic magician died of infection as though I had communicated something of importance. ------=_NextPart_000_0001_01C6EEBF.88A867A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VkAGRA for LESS http://www.utrerfadesax.com

=
 
entertainment here since the cannibalistic magician died of = infection
as though I had communicated something of = importance.
------=_NextPart_000_0001_01C6EEBF.88A867A0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 13 16:58:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYU6s-00052j-GH for capwap-archive@lists.ietf.org; Fri, 13 Oct 2006 16:58:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYU6n-000167-Us for capwap-archive@lists.ietf.org; Fri, 13 Oct 2006 16:58:26 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id E056D398063 for ; Fri, 13 Oct 2006 13:58:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 9B3E84A4196 for ; Fri, 13 Oct 2006 13:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7D5FA144800F for ; Fri, 13 Oct 2006 13:57:44 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by hermes.tigertech.net (Postfix) with ESMTP id 3987D1448031 for ; Fri, 13 Oct 2006 13:57:41 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id m19so1588716nfc for ; Fri, 13 Oct 2006 13:57:40 -0700 (PDT) Received: by 10.49.55.13 with SMTP id h13mr7628176nfk; Fri, 13 Oct 2006 13:57:40 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Fri, 13 Oct 2006 13:57:40 -0700 (PDT) Message-ID: <5bfe7a820610131357h52017aadp11642134dfc49adb@mail.gmail.com> Date: Fri, 13 Oct 2006 13:57:40 -0700 From: "Dorothy Stanley" To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS, SUBJ_HAS_UNIQ_ID X-Spam-Level: ** Cc: Margaret Wasserman , "Dorothy.Gellert@nokia.com" Subject: [Capwap] Publication of capwap-protocol-specification-03 and capwap-protocol-binding-ieee80211-00 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0579147927==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 2.2 (++) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c --===============0579147927== Content-Type: multipart/alternative; boundary="----=_Part_72721_12270175.1160773060570" ------=_Part_72721_12270175.1160773060570 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, We have submitted the following two documents for publication as internet drafts: draft-ietf-capwap-protocol-specification-03, and draft-ietf-capwap-protocol-binding-ieee80211-00 thus they should be available shortly. A few notes on the split documents: - The -00 binding specification includes largely what was in -02 section 11, the 802.11 related security sections, WLAN related terminology and references. - The -00 binding abstract, introduction and goals were adapted from the base spec. - The -00 binding author/acknowledgement sections are TBD, for the next version. - Since the 802.11 e and i amendments will no longer exist as separate documents after the completion of 802.11-REVma, expected in Nov 2006, the use of "i" and "e" is changed to refer to 802.11, with the exception of the references, which will be updated when -REVma is available. - The CAPWAP base specification now has no reference to the details of 802.11. There are still references to the wireless binding identifier in the control message section, and where there is reference to 802.11, 802.16 and EPCglobal are now added. These two documents incorporate resolutions for the following issues: 85 141,143, 150, 158, 160,162, 166, 170, 171, 182, 184, 193 201, 202, 204, 208, 209, 210, 213, 215,220, 225 The following issues will be closed - no change to the text: 82, 145, 151, 154, 155, 156, 157, 163, 164, 165, 167, 169, 172, 173, 174, 176, 178, 179, 180, 185, 186, 188, 189, 192, 195, 197, 198 We will be updating the issues list, available at http://www.capwap.org with all of the resolutions shortly. Please refer to the issues list for details of the closed issues and their resolutions. Thank you from the editors to all of those who have contributed to the resolution of these comments, and the improvement of the drafts. Dorothy Stanley, Pat Calhoun and Mike Montemurro ------=_Part_72721_12270175.1160773060570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

We have submitted the following two documents for publication as internet drafts:

draft-ietf-capwap-protocol-specification-03, and
draft-ietf-capwap-protocol-binding-ieee80211-00

thus they should be available shortly. A few notes on the split documents:

- The -00 binding specification includes largely what was in -02
section 11, the 802.11 related security sections, WLAN related
terminology and references.
- The -00 binding abstract, introduction and goals
were adapted from the base spec.
-  The -00 binding author/acknowledgement sections are TBD, for the next version.
- Since the 802.11 e and i amendments will no longer exist as separate
documents after the completion of 802.11-REVma, expected in Nov 2006,
the use of "i" and "e" is changed to refer to 802.11, with the exception of the references,
which will be updated when -REVma is available.
- The CAPWAP base specification now has no reference to the
details of 802.11. There are still references to the wireless binding
identifier in the control message section, and where there is
reference to 802.11, 802.16 and EPCglobal are now added.

These two documents incorporate resolutions for the following issues:

85
141,143, 150, 158, 160,162, 166, 170, 171, 182, 184, 193
201, 202, 204, 208, 209, 210, 213, 215,220, 225


The following issues will be closed - no change to the text:

82,
145, 151, 154, 155, 156, 157, 163, 164, 165, 167, 169, 172, 173, 174, 176, 178, 179,
180, 185, 186, 188, 189, 192, 195, 197, 198

We will be updating the issues list, available at
http://www.capwap.org with all of the resolutions shortly. Please
refer to the issues list for details of the closed  issues and their resolutions.

Thank you from the editors to all of those who have contributed to the
resolution of these comments, and the improvement of the drafts.

Dorothy Stanley, Pat Calhoun and Mike Montemurro


 


------=_Part_72721_12270175.1160773060570-- --===============0579147927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0579147927==-- From bjezsuzf@vip-travel-club.com Sat Oct 14 00:29:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYb9r-0007t1-Lm for capwap-archive@ietf.org; Sat, 14 Oct 2006 00:29:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYb9r-00089a-Da for capwap-archive@ietf.org; Sat, 14 Oct 2006 00:29:59 -0400 Received: from [201.32.250.176] (helo=[201.32.250.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYb9m-0003a0-Lv for capwap-archive@ietf.org; Sat, 14 Oct 2006 00:29:59 -0400 Message-ID: <000901c6ef49$5ce88070$b0fa20c9@pc2> From: "Supplies copy" To: capwap-archive@ietf.org Subject: free MPs. Date: Sat, 14 Oct 2006 01:29:39 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6EF30.379B4870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.8 (+++) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 ------=_NextPart_000_0005_01C6EF30.379B4870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6EF30.379B4870" ------=_NextPart_001_0006_01C6EF30.379B4870 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Noblecom in Books Used out Print Textbooks Childrens Dvds Music Toys =20 Items Browse Soonbampn the. October is User or Nero Ultra Edition Just about any or competent =20 jukebox app of will let burn cds am but packs a. Youd airplane a window in seat without chatty crop add filters photos =20 quick nimble image editor live. Offer not Join stores Seasons Biggest Bosch hunts serial killer Michael =20 Connellys Fiction John Grisham pens or. Copy Copyright am Rights Reserved a Privacy Policy Contact us a fff var =20 state! Sounds like trippedup version a James Lavelle opus five minutes in later =20 nodding head skittery drum bass number have idea how in. About Order Author Fast Desk Topics or Back is Terms llc Software =20 Downloads Reviews log Sign. Out of Print Textbooks Childrens is Dvds a Music Toys Items Browse =20 Soonbampn or. Unknown prepares am past happens special adventure Bully in Amendment =20 advocates Rockstars. Behind of minute youre enjoying what sounds like trippedup version James =20 Lavelle am opus a five minutes later nodding head in skittery drum. Will let burn cds but packs perks that make worth its price tag =20 including features. Webroot Limewire icq Morpheus in Irfanview Winzip in Registry of =20 Mechanic bit Trance Andrei of Krylov a Classical Guitar Fort. Window seat of without chatty crop add am filters am photos quick nimble =20 image. Classics More Movies in the Augusten Burroughs memoir Running Scissors =20 Antonia Frasers Marie provide Hollywood or flicks Tieinsthe end. Like trippedup version James am Lavelle of opus five minutes later =20 nodding head skittery am drum bass is. Holding Pattern same amazing youd airplane window seat without am ------=_NextPart_001_0006_01C6EF30.379B4870 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Noblecom in Books Used out Print = Textbooks=20 Childrens Dvds Music Toys Items Browse Soonbampn the.
October is User = or Nero=20 Ultra Edition Just about any or competent jukebox app of will let burn = cds am=20 but packs a.
Youd airplane a window in seat without chatty crop add = filters=20 photos quick nimble image editor live.
3D""
Offer not Join stores Seasons Biggest = Bosch hunts=20 serial killer Michael Connellys Fiction John Grisham pens or.
Copy = Copyright=20 am Rights Reserved a Privacy Policy Contact us a fff var = state!
Sounds like=20 trippedup version a James Lavelle opus five minutes in later nodding = head=20 skittery drum bass number have idea how in.
About Order Author Fast = Desk=20 Topics or Back is Terms llc Software Downloads Reviews log Sign.
Out = of Print=20 Textbooks Childrens is Dvds a Music Toys Items Browse Soonbampn = or.
Unknown=20 prepares am past happens special adventure Bully in Amendment advocates=20 Rockstars.
Behind of minute youre enjoying what sounds like trippedup = version=20 James Lavelle am opus a five minutes later nodding head in skittery=20 drum.
Will let burn cds but packs perks that make worth its price tag = including features.
Webroot Limewire icq Morpheus in Irfanview Winzip = in=20 Registry of Mechanic bit Trance Andrei of Krylov a Classical Guitar=20 Fort.
Window seat of without chatty crop add am filters am photos = quick=20 nimble image.
Classics More Movies in the Augusten Burroughs memoir = Running=20 Scissors Antonia Frasers Marie provide Hollywood or flicks Tieinsthe=20 end.
Like trippedup version James am Lavelle of opus five minutes = later=20 nodding head skittery am drum bass is.
Holding Pattern same amazing = youd=20 airplane window seat without am chatty am crop add=20 filters.
------=_NextPart_001_0006_01C6EF30.379B4870-- ------=_NextPart_000_0005_01C6EF30.379B4870 Content-Type: image/gif; name="Bejeweled.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6ef49$5ce88070$b0fa20c9@pc2> R0lGODlhnAHkAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAPAAAALAAAAACcAeQBBwj+AP8JHEiwoMGD CBMSzKSwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGkQCsuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrv7xrufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/Pv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycghiji iCSWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjz26OOPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5ploapgAY6tkuGZibaqJWJwbJvDmYHR2 eCdgeXq4Z199fminX4GG+Oddhaap6KKMNuroo5BGKumklFZq6aWYZqrpppx26umnXBUB6qik lmrqqaimahENqrbq6qv/sMYq66y01mrrrbjmquuuvPbq66/ABivssMQWa+yxyCar7LLMNuvs s6/lAu201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789uvvvwDT1wqxAxOcnga6FTyswlA+EfDDEEeM5QMSV2zxxRhnrPHGHHfs8ccghyzyyCSX bPLJXeaB8sost+zyywwiQazMw9IsrM3B4gyszr/y7KvPMAct9NBEBxnK0UiHYqzS9i1CrNMK 6pEZ1MJSHazVRWf9JCrEcj2s18KCHazYwJL9q9m+ot2r2lq37fbbcMct99x012333Xjnrffe jHz37fffgAcuOFtKDG744YgnrvjiE7JDrOPDQi6s5MFSDqzljGf+rgmad44fD56HLvropJdu +umop6766qy37vrrsMcu++y012777bjnviMLxvJOrO/DAi+s8MMXSzywx/+avO7MN+/889BH L/301Fdv/fXYZ6/99tx37/334Icv/vjkl08UwuanL2BAACH5BAAlywAALAAAAACcAeQBBwj+ AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHP+E8BTgECeB30CJQi0p1GfP40mPYp0adOdTAseNTj0J9GnPa9GHTgVKtWn WrGCLcoUaVWdaNParJpVqterb79yFSuVbty4bMc2bXuXL9y/Se8Grvv3bF+9ahMrhpnXsFDE hgdLFnx2aGWzdufO3ctZMGW6kUPbdZx58uLTqEeyhYpVsmWwpglrJnw5tmzWs72KBnw7d2yy vUmnHk7c42rcVvFi3tqV9+68YWEHBl57t+/ozX8/Do64uPfvFI/+I8c8O/Jm4dd1Z3cqnfp2 191te0YPl/5n8PjzMxSPuzP0/aU9R15CAqp3nl+HIWRdesA5F59+EEbIH2v+dSaXb/a9lltt dTU2IIYPNsjbZBo6GOGJKAIGm18stmfhdRzG+GKHm8FYWoILgrjhg56l6ONiSu0UlFhEdrVe j0Ga9hqCI/6n41dt5RgWlFKa9+OVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp 55x01mnnnXjmqeee+uXj55/5/AMooIIOGqhAfh6U6EIffECQowM1KlCjkv5T6aOQIkTpppFm ahCnnT6KaUGXWuopqJN6aqqpm6qa6kH/lYJaaqSsUkqqq3ymtaiihyLaa6G+/lqosLBmauur yK56q0Klxoprs5BeeqyyoVYLbbKvXnurqtNKO6ul1FL7ba5o7WqQuege+mdB6zJqrLfVhovt p6dG+2y9yXbrqrPxKjurpNpiyi28qf4bLsHkJmYuu7+miyiwDy9cbKfvxvvtuP3yu+yy3la8 scaj/utowLRKK66xrIoq8rwJ62RowzAPtGugi6pL7MQAj4wvyxgXjOrF+9q7as6a6kuvvESz DG6s+aKc8qRIC92yWhLLDDOhMvsqqNYMEZ1000cnpC3QYXuts9g7hzxwrRgLLbW4FEO9srxT 41Q111yja/Xe/l2f/fXJYRfNcdBl+3224P1muzbIpFrsMbhxH24trnXXdDfEeM/MN+bM6hsw 2WgPPrHjHVMe9ainIywq2PluKzndlbt8M96c14zQ5dvGjTrdPR/89u6+v2v66Y5PDjzUo8Od ++fDxw7T5Q4TlOjsuB8PrbOtsi1y9j5PW2vgSifuM71GW4+4rDhzL77z7Lfv/vvwxy///PTX b//9+Oev//789+///wAMoAAHSED6ceIl/EggPwiSwIMskIEPLEgDB6LACP5jghK8YAUtSEEM ahCCCKmgA0WowQ1akIQCMWEEVbhAFSrEgylEIQwLCBFOHLAlHpygAg3CwR1C8IE5/gTiDFt4 wh4GEYQSLGIHkRjDJCLxiB/koRKlCMMZRpGGEbmhS6CIwhQm0YhCfKIPKXjFMjaQixxs4hLV yMYymjGMa7QiFEfIRCdisYYwGWILS8jADGKQiG78IBFP6MY/AjKOadRjIO3YxiaikY5rhGQM u2jFOyJEi1tM5B756MU+6tCRmrzgJMlYxRUesoNyDGUlIxnIM5oQlRu84irfGMlZWnIgmMyk FEU5Sl6SUZCg3KUpgVhIOBYzhKpMIyNbecooprKLkqTlIm9JkFzq0olF3OQvZdlMR/5QlKWc JDQrqUhbznGJ4UxlI3fJSh0qk5oCsSYCpwjGHtbSmM78/2Iz3bnMVc7xnOFEJDaVacgXTnGd 8CyIPOf5RCpmEJJcdOgj6+jPgwLUiGLMKDsR2kh+cjShN6FkNH3ZzzGSFJ2xZKU0EwJNcWKU itmUoQsD+kOTUvKdIM2pTnfK05769KdADapQh0rUohr1qEhNqlKXytSmOvWpUI2qVKdK1apa 9apYzapWt8pVmSCgq2AtyFfDStaxkhWsZj2TFM56prSy9a1wjatc50rXutr1rnjNq173yte+ +vWvgA2sYAdL2MIa9rCITWxYwQEOhzAWTI/VEgAmO9m0MPayArlsZDXb2Mxq1rOY5WxnQRvZ f3CWtJ09rWlH+1jVona1mIVtaf5XW5DNnna2tCVIaVW729FKhLfAje1rRStb1vo2t6/NrW2z VFnFzLa3yk2tb3HrWYMsF7nYRW5rjRvd6up2uscdiHBDG97x4va6tIXuRNSr3fB697vilS5o 4wve6m43vswFgEEoq99/8Fe/lBXIfwfCXwEX2L/9rWxzE/Jc7l63wQeh7oPrC1/7Oli+2YVw hMl739pymMLtlW1x6StfELP3vI2VMHeju10Nt/i41D3Rgg1M4+baGMAJ7i+BcVzjHCN4Ibe9 sHeDLNzsdnfEwMUvdCfs4Q/DWMQd1i2UTSzkIae4xEU+8YqV/Nn3PnjKFW6xdd0boRn/+Mc3 7jGNEf4c4DSzWccM0XB6u5xhOqvYvE2Osp6vjOcKk3i6VmaxaQONXy9fudAvjnKhQ/xeD4/5 z+IldHKL3OgUmTnNblawjzHt4zc/RM73Za+jKz3nRTt6yUIWtZEbXd5D2/fRi0Y1ol1takPH mswq5nKkR11pOpNaxnA+s6bXPGw0b7rTZ042QkDtavTyOtdHfrSsLSzpX2O31SHG9q11HWgU w5rRdTayejcrbVpTu9aWPrC6O63pABu4zchesJm/PekLO9nP2yZyb80b23F/Vt9PHjVxtX1r fh85yBvOMnjJK+4tt7bc4Y72m+btEIoTMMZrwriaLM4Qjp9oEvjR+JlErv/Ykpv85ChPucrP FOyMtFwjL195Tga835hPBM7uJgjNc07gjhdE3joOts1lXhM3g6TAQU8IgHuu85//HOdN96+A nU70tHBa6jfOOrL3K/Wpe53rXQ+72L/O9LEneOxkr/pNOD3sGV8dIUv/eszPTvaW233HQE+7 3tVOk50Hncd457nSbVz2qIcd6u8+8OEL33W3833mQv+7sj0Od6wzXu6FvzvVF990uqP98TK5 tOTdHvmFLD3pnMf85TWf+sarHvRFLz2x3T1gjis+56jHO9gZj/tL7/jysO/S0G8ukuEH/0rG l0jyiX/85jv/+dCPvvSpSnllTx9ONI9I9asvkAD+eN/7//j+98Mv/oGAnyDnv/5puK+Q7S8/ /eYPQPy7L3/y19/+6keN6HsM7xz3/u0JAX/0N3/kR3/gV375txh+p2bCBnjF1nbDJ373l37n V4H2J38CmIBWt26ZdmwMWGwMkYEUiIDhN4AFqIH653/s5oHGxoAheH8EWIAUaBAZiIIb+Huz 94EOyGOUJ4ITWH8WWBA1aIM2kX3J1oFv9ncAiBA+GIMHSIMwSIQKuHxSWDnsV4VYmIVauIVc 2IV7RYVeGBJGmHhgqHNjaBFXaHZmWIZhqH02Z3TKx4amR4XrVnZy2IYNYXuS52kNWHNruGlk mHiCaHtq+Hp4yBGKZ4b/OPh7cLhmT+dpbweChCh0dniIYohjkqiCKngQpAdvONhunlhxjmeI h7gIiGh3o7eCFJd3LZiD+/cQcZd6d2iJcLd1OdiHjviIrriHIOiIlBeLuTeLtMiJgheIgbeH fniMk8eBWWd9f6h77zaMayeMtQhz0pgaaTiH2dh+19iN3viN4BiO4jiO5FiOXmiK5ngn6JiO dbKO7Dgn7viOcRKP8vgm9FiPbXKP+Lgm+riP/viPABmQAjmQBFmQBnmQCJmQCrmQDNmQDvmQ EBmREjmRFDkmqSBYsfRKKXVMKmVIpgRKPrSRLlVCO1RQfyRLJImSJKlHH+lFJ7mSbORKv5SR /yKUTjW5QiuJU0mlSGrkTsP0Tb3ESYKET+REUC05lMQUkj35SebkkS7JlB9pklBZUj8ZRMT0 UUvFk84kRK5klYMURj55lNOkTjH5leBUkkt5RtMUTClplqckkyC5RzTVliUZU75UUE61kXgJ lXD5lHD5l175lfVkUVHZlimZTzdpUIiJlonJlsDUmLAkl3UJk2ZZlk+llXq5lH20lWxpU4Op T0dpkqPElT05mqQJQp/ER6Qplehkmv2kmTkUlLa0k6HkmLXZSaipkWNUlMh0T63pTZp5l28Z U2gJnEOJUr95nBQlTIRkmVOFmXB0myelnMfpURvFSHgJTKS0man5lP/tVJjbSUpRCZ7euZwD tZm4mZ1MBZ3J2U7MiZxI2ZWl5Jk1dZUu6UnF2Umv5JuE1Jx6SUL+eZP5iVIDGpo6WZFp4QII +iMKuqAp0qBooQcOOqEUShJEUKEoQgQXOkDU6HQd2hIfmh9nCBGouI0fwYoxMXchiohrqIgu imaWB4ZDJ28UUYybRyYhql9hYHgrWhEoChMqGnsKxnQvh6KxCHO5R6LAt6RfUqJT53+6x3PB CHRQunhxR3tU2nmWx2aCGI1diqWAx6V8KHh0x4zQmHS314xe+qSc+Hkx+qZXqnUeSqauJ6Zl anhsuol22niEl25t1nN9uqV6h3poyqNW6nn/Vtqmp+ehvJeobOp6hfqoVOd5wOiognqkkcqo k0qni9qplgp1SXqljoqolBiolRqoezccUrp5wIh0SdqlSXiEgDqrdeeqYFemf+p1SAeouwqp vSqoUUepnzqsOGerNYd4rXennpqpoJp5ebqri9qowRiryIh8rNp6jHirwDekklqp24p4Z8es xDqpkop5JZqrlzqu5Vqkd0eqzgqpcEqrYuetugqs8SqtlUiJL+oj+pqudYd2hOqs4hqq75p2 pyqvB/uo4YqwAKul3aquwEqwjNqvyJqnb/qwDGuH3vqqnDetmUqk/HqstVqlkxesaiqmkNii dup7JsutfCqne1qn/7RHpBWbsC8beB2rpmQKpidrsPc6s/8qsQ04rSI7slWqhEwaVT2qgApp o8yFoVAbtVI7tfm3tCphtXVVe8/4oqHKs9WaskuqtT53hMh4e7zaf6N4qJiohKhKjNm4qu2X pWvqjHHrtBV3rFj7tHjatZWYr8SIp/NaeYAruEZKtHe6e30rsyB7o4irpLo6owwbsNpnjddq J/0qi+Z6rZqHqP/apoO7e56quPXKsQ2resL6eW9YtIlYuT43sMynsnGKtHB7eHILtBcLptBY HOpmqPVarmOKe737hxYnttxosYdLqMWatlq6sTSrvKqbsTeafMKKpnbrti7rgPJaunUasf+R 666+q7vRC7cVm7nkqr1uern917G9q6cl27jG27yki4ko+6S/ynqpyrvp2rXy26jdaqwA+3+S GLmZ57/egb5yl32sd6RJqMCB67lJa7r026vi6r73Krqom4eFmMEPjKw2S4ea+62lG78dnKx/ W8DRu7ikaKmda8Aa7Kb4u67qu72fS8IxzLiVN8F7N74UO6x3a6hE+72SG7iu27kNrLuu6rLc O6heW8S/KsNmV72ci6lCfLY06sCy23m7O3i1u7O4a7AcmLvV6762u7LVCq4nC8DzqrMmmisf mrcpIYyz6MaHtaJYCwUnQY13KMfiaMdU6x183MfE8ceAPMhzIr3/bDxzylejwLaIQFqLaxy+ P+yGbMu2T4e2a7uIomeqc/jAxVuEM2zDnTx87aoTP/oSRdoRhsvJVry3SrfKj8vIo9pxpNvD nqzKMrrBgosTocuzYNzFoUjGJIu6hHfJuVyqoHimRfx6p3zBEBytfmvIuHq8axp5epqm0/t/ 0yylZ+zLA0zMZIzFwWzKFwu9DxupC1vOYsyrKUyK9Hqql4u5t2q2zWyv1Hu357yl9xy2EDvC HEzDPEzOkWyv/tp364uum0i9uRqu9Wu+5IutiYuxWNfEPrvO24qz61vJtji3C6u1nfrOCz3E +Su8/jzBu7vDj4vE/Vt0oyvA6Bysvvux/4MKvXOHrw0d0/gLuaALwS3MwJ7rzO/riz7M0iEN wy/ssRmrwEYNxE88E6Uq1Py80i3NuDgcxbyb1ALtzyHsyk58uCjcyjWGwibd0E8d1f+MuVOd 02St1KG3qdf7pdwss5rsjF9Mu1W8t6SXs5ybu17cp8s8xS6dwaL8iXVNsufKw2iMvIS9s9kM s8KM11t3bHoszms9tvET2Y2MJ2H8xrTsPpZ92VPLDYRMHKAd2sMx2qSNGqadU4Hd2fdLwV4t VKz9umhodabnwicKi538vST6yPuK27pItyyhorz9ybftuBcR24rMjbHtwb7to6q8yYn828PN oq4924iMEchd2/++WrsD7aXKis2wGo0IfcVgO7P0qoZZfLN//c3s/dO8vNhHm4nV7Lz4rMmr a816HbtnOszNa9FfOqtQit/ePd2EG9Why8SKC9I1K9RDrc5Y3eA8bcEIPspIja1jfc82u3rT C9A0rYsfW6gKHtT0S8RN/dAbsawCnM+JeuBre96Dfags3cQV7rD5u8zxNslZ/bIba9DUOrof Hc/tXNaIHaYai649Xt887rcQ7dhkm9nEx+Ir/tIAPs4z/r//PKQgnr1VbuCM/F9lu+UXHeIw rawffMJW7eIy3c+s7NJUTeJCnua2Tbnbe7AcG8QbvuROvbxTLuVojcPJvOAwjd55PsT/GK7C Sr7PIv7nh37lHM7lh96srW3dc+7dDo2ydg7fKguJby3BRn6+VErJdHq2i93lbL3jMAu00Wy6 hZ28OHvf8Du/aYy0MRvr/s2HYCverw7ea4clzA0h2d3cxPHru26tm/0dTg6ixn7ayr7szN7s eSzsLoHSaQLHJoHHaCKHHarHy2fGaVuG0J7Luz28zw3uxQfKuY2jsp3cnn3VlU7szBzn2k0S 1i5Z/P2756zN0Yq7mSy6XNzks5fPkC6yib3Rtn7faryDW8zXctvnzbi6ezrf977v33zqBf/p laywBB7cDj6weU275Ou9Cf6ube7OJwzrYl7oQhvL3R3SgY7R/2JdsNhbzh3fz2RusY7OdXGt fzJ95HKduKI64VT+19Vs6MkM9Fzu5zQP1Tq+4gSc02f96FTcqohrzug83ud96yOqFmft0Wqu 8knvzOCKsRlOxG4u5o3+8Ue/579d5gOd9DW91DAf8jZPz3E/y0wL0WOP4Giv6MEb9v6a9zqc 6GPd3W6P8iku8mwf5FCf1nyPz1Wf54sP75BHqm9t8t180S46pfoazakuzIyt6rJO0v0eswpt 8eZ8xi6fzRaOqnMt67DL1xFc6JbOxZia8fPz7dHt3A+J+7A43bzf7MAf/MI//GGC09ZI7Tiv 2R6B3Fgr7IRYN3ZP67B8w+xO2TRu3P+5T91iCMkL7+qRnu4OTO6G7CZ2v9CSf/3Zn70l0fzK b9OTbuIuZ/3h3ybHy99oq6n4f/H2r94O3/r8r94A8e8fgIEADApEWJCgQoELDS5kmPBhw4kU D0q8SNDhRYQPIVbcyHFgwpESS55k6LGjSIUfM46suDIkyYkqYYIE2VImRJI9ff4EGlToUJ8O G57UaPTo0qM8l9rs+BTm1I9ITTaNqpFmQaYmq0YtOhVrUK1jUXpVivJrVqs7y2aNybTqWqtz 04IVe1Vu3rda5+IlGljwYMJ++bZFbFEvXaWGDZvl+RdryL5OD6/EeDBpTcs6JZ9V6TLu19CJ nZ42jXezyM/+fXt+xrzX9d/WhG3fxu2VKtu9XcdGBtx49+zgvIcbp6jbN1faRYFDTg09LHTX gEFHr/uzNl3Z2olvz74893jy00vW7q0bdVfhjsOrNe7ebHHu1LG/r949Pf7Ly0kX1w8++/xD bqvm7EOvs/IWxG2tnDBjDCcJtzrvuIi4syknypBiKb+IPFPsw53agsqit0TUycTzRnNONMs0 AyuuFC/EiKaXbEzLLwmNIu1BBn8EckEFgySySCOLHPLI8ZJUUi/xyGoySimtm7JKK6tk8sqh soxyvS1Z0jJMMccks0wzz0QzTTXXZLNNN9+EM04556SzTjvvxDNPPffks88jufT+M9DBADUS zC2xVJJQ8hT9szTBSsyTSUbX9LI8SQel8s/bkqwPyE7F/NQ8Py/dc9JHhVI0VCJNRTXTH1W9 0kWZKMRRsYxi2nE/GpvClSPOZpoVxQtvTcpW0VQMUcaUNJzQV2KBHY3Y+X49NlkwNUQWWxFX qxUqGTkLNkPNlNXSwfv049E64tiLscIBdU3vOXR/e/dExhY7rL34ElMNLlrB67ffG/O9a9+A +3N33f5YfVXgEl/kLd2namr3NG8dplg1iPeTtyyJeXQ0r5YiI4ia7CQDOWO+Nn7v4NWKNbFj xF7m8DXs7GKxQoD5LVdg7WymN1+DTzwr3uvUlZldn3X+lspLe8n6LuL5WubK5aLN7QxG8/Ij 2mLlBKS6XaGlKzrWpY9eWuKxef4vx5ZZntlJlINW+GnxoqabP7ixBpo/gwPcmT4A/ZZqba7L NFfYFB9MWdbEa62r12rHfRHYzJJtunAfoe1wYB1vbMzz5L69vGytV7RcWR8X97xDfk+3XHPM J+ZZUFEDM5Vh21vdvXffC7Ut9989Hb54449HPnnll2e+eeefhz566aenvnrrr1/e0Aax5757 3xUkt+wnUXW22uS8Rz994vvOGqhJdy5Yffnn/zL29X61tvyp94WNfv//xxfcRMY36oAPcDMC YALl17/rJI1gKvsX/1ylQAr+Fk8Op9ofQZiAHAKKzHQB/FsFRWg9BpIIX/W6WgQTNEIW+kQB 2RsY5KyVv8m9Rlzmw1ULdbhDHvbQhz8EYhCFOEQiFtGIR0RiEpW4RCY20YlPhGIUpThFKlbR ilfEYha1uEUudtGLXwRjGMU4RjKW0YxnRGMa1bhGNrbRjW+EYxzlOEc61tGOd8RjHvW4Rz72 0Y9/BGQgBTlIQhbSkIdEZCIVuUhGNtKRjzwjP/gBSUNKcpICkeRtMkkSS26yPJ5ESCcv2SZQ /mOTopwkKjnZSUoqyZKhHOVgSmnKWC5olqesZZpeiclMzpKXPfFlK4PUy0uKEpa4/CUrYblK ZBb/c5e0JCYokclLTyrTms6kpSmp6cxqPhOaqXxlMG+Zy2tq05jCHAoxf5nNZmJznOF0JzyT GctxrrOdCbknO+W5TH36BJzqFCc5a9lOdWYTnUEpaD4TCk5g0jOex4TnNPGpzG9GE5v9xKhB t2lRTtqTodDk50RXOU9+BvOgFV2oQVNaz5J+VKMQfSlJ1znRlT50pjH9Jj4bqtFu7lSkGZXo SUcq05rK9Kce5WkujdrSm4pUoS6VplJfKtCkhtSqKoWqTYU6U4uOkqLn9GYpywnRf3o1qi2N qFm7uc9tbjSnOh2qKpvq1reuNahbzaNJ8apHve7Vr38FbGAFO1jCFpZM/pVykqV4J6cs6S55 HtFd5bQXK5eMCLI2nCwG11cg8Y3vZ1CaE2I7S0IGscyxQqrsB/vmJtF6llGkYuyh1CfZ3+gv ZxyanOg8Jq0QTcaDVMraS7j12W91TrfaoliEHiO51BWXczDz1rPgJbsMGetaoOOV/gR1WbsE KIWFGyD/7lJC9xiQVg6b7m/PC7/dhDC1X6ub3KSGMMMRF0EnnNfabOc03I4LuMyFmd6CE5qN fcxXqz3gkwKcGZmBx25dGzDsRnafuV0mZGqzmXzayzG2aHjBgeJvp04nNtPF9142vAqG62Pa uG3NgQL27XMgbLT+nTi/Jq6Y+yy04Zsdx0Gn/k1TiA/22/+wi71Dlhd4RazCgFXqxex9DLwe h2Ol3RjG5zKhb5FMYrdNEE+0VQtvq6a0CfU2ZMOKHdou1iJojcg3m8Esyco33N16CEIMztac Ice47DpuyxEMj8osljicNRLICFZsbAtzXsMCb1VBOnST3pfYRlfa0pfGdKY1rcdII5oonU70 ow+7PSGhKbOf7V5jSb1oR6M6sbDd2qDCx2hXYwrPsh3tqUH7aVuPVnqgpjSvW61Zz+KaUK8V dvCCvWtOAft2i3X2mzZnKxLBqEeSbfPEQrehZYWrzFomMG9ZBClqBStTuUoJ6t4sXWT557jD TbGxwiWWb+dvWpQz/99+cwwf2MT3bDgGmNoUFhsqf9DG6CFQvSBmQITPrr5vlh3B9lfl7uLX zqNaM7/9lbkJY0y4Matvey783ZDHBr4W77i7BW0aCIKIbAaSoK6Eo7ORD9qBRIvbZXfXPiNr jGniY6DHYD4gDIcNyjY6udXM++q/9TvmQL+ycjNWdKdTnLMd/N6+gXOvKYPQaFoem8CN/nSc b31wDVcz4ar+8AyTfXD0RuGTz6Z0L+tp2un2jOjM7ebb7grdM787a2K0cua4DkPVIdcNezPi M7scdXLGIU4onDCHPzfJq7uztr0Y7V1vmoicx6znRT960pfe9KdHfaI2hbgkL3b1mpL0Y/5B r9jZh0l4QwnD6ztf7E+FCvSqXtKdJj1stxwqyiDWvVByz+rd+7r3yUZSl4SvbCTxHFO1x1KZ r6151gX478bt7Yya5dybQFdyU0M3AsFV/hpmm/wIDP/i1C3+jxPe24Ne/MdpDXT/Wij95k4u M9M13Su4KFsXsQu6q3M7q9OXAtKxhtOX7SAITFCPWHs+9Iq6qnmcsYs767s1sSkvwhm68ymh hukzAwtAoss9mknADFpAsBG6Bxoxy3KvzMEZxksuFjs8wSOb2Ri5AmnBn+OuWlutCNwwOzsz F/mwzSo7d3E7owiDGSMyBUQhBuQ4D9LBGmSaGvu3Bjs7r7syDv8TMkCLQVeBNSM0wB57MZNj whY7mZhDQCqcwiqEQcoLnAM6sXQ5svD6N/xSuwyktCDsuqVzQhmLMbZ7mz8DNcWLMO6rrvNY Qb0Dv6s5v9FBGrhjv3mLs2rjQT0cvPHKQTDbQchjD3bblfMpsfjZltIJrh+7n0PMNtBolku4 v7o7Ey5Zvjc6tlWrI+zTol1MvtQTxmEkxmI0xmNExmRUxmVkxmZ0xmeExmiUxmmkxmq0xmt0 Il7Axm3kxm70xm8Ex3AUx3Ekx3I0x3NEx3RUx3Vkx3Z0x3eEx3iUx3mkR8NSgHu8x3/AR3zU x31EiHxMCIAUCIAkyBfyR4HsRxfyx4H/XMh+5Md9REiBzEeJfCGHfMiGZMiG5MeMNMiK1EeO 9EiQtEiK9EiI/EeTPMiSBMmQRMiEHEmG/MeXDEiKhMmWFCKbpEmX3EiHnEmY1MmKjMiQPMma LMmOVMieoMmkFEqXJAmbzMie5MmPdEqmhMqTLEqfxMqfBEqqbEqSZMqJJMifnMmrTMip/CGc JMuCBMug9MmCzEqndEulPMquHEq5pEukXMqyTMuH5MqhxMuedEuqZEuLlMq85EjCVMqJ/Eqg NMrD7MsgMkmsDMyOBEu6rMy2ZMm8jMurjMysXMnG1Eu83MnHvEydREyMlMm3bMzAVM2BPE2g oEyjTMrXxMzF/2RNIkJLq5TI2hzLzrxNuFzInPTNpbTL0ORJ4HxK4zTNqOxMkWxNtWzJwWTM 1YzI2pzN49xLwSTLIspNoozJu7TK5BRLvwRPyRTKnKzK0lRP0EzP2NzIsPTMqURPiKzM6MxM 1/TOt/zL61TOtdTI7cRN4szOjyxP3jRQ0jxPAF3Mv8zP/mRP8lzPtgzIAoXQ7bzMwZTQmERP AgVMzpzQybRQwwxQBl1QAWVQknTP1OzLyGzO7tRKFPXPBE3JuuRLDUXNFg3RBTVPxfxO+pzQ u2TRD/3PCiXPejTSI0XSJFXSJWVSZjTLJu0dHH1PlYzR++xQ6JzOoJxRosTSrrzICv+1UJFs TvEcztE8TB/VzS6FSjVNTLQ0050cUzhFzcfcIRCl0a3cUDK106qcSx29TT7V0ahkTq40Sznl TRel0/m00gi1S/tUzQHV0/gU0RYqTv/k0CI90ymV1KBQ1AMFVOGkTsV01KNkzQjlU/nM0d40 zxJlTCDlzFa1TlgdVSCqVIMkTAqNzfFk0Tm1zeDM0gT1Ul81zS1NU8uEVQctT1QlUlVlVRrd 1Gb1U+p8Vlp91boUT0wl0D2VyTEN1FLFyFndTPz8UkB1VmglVCsl0TztVtCMUdFkS2/NT259 UhaqVQ5FVPxcUxMl105dUXRdVfq01Qb1zM8011lN1FRtz3L/Dc3chFFG9dHSxFYe0lYexVds 1dd7dVFQJdFzVViKLUwKhVZtLVJlXVXwrNc/nVhpDdlJPctvDc4f3df9vMgpNdOS1ct2DVZ2 1dlL/VUVbdOirNkh7VMVHdn/1NTWbFCcLVh/hdKmddqnhdqoldqppdpmTFmgpVlTFVOUFNqi Tck3hdFi7c1jZVo2pdIb1dixLVY03dWsTdGhFdYtulqTBVakTVitDE+6fVS//NN/hU893dn3 HM9I1U6FvVvjhNi+NVRytaI9TVwF3dCMldWZ1dfBvdBqTddczUxLbdOPjVXd1Fvk9FuB7dtA Hdgrqk/MtVmCFdtodU1iXdZGfdXR3JzNb33N2h1XsUTR0NXMHG3by+3TXe0igFVd0zVdyYVT T+3V+4RX0S3La53cEn1KjcVQInVe2dXOmi1ZiM0immVd443cylXPjR1dgi3OhAVQE+VPhx3O zEVQ623VdzVM6mXZKYJXmwVXpnXdSx3YtMXe961JmOVfZGVJXUVY+A1ezH3c003bL7rf4yXW 6sXfgN1X353dsFVbnhVgzBRcG11c43XO1NRSs81d+9xdOq3aFFbhFWbhFnbhF2bHcIDhGabh GrbhG8bhHKYfZNDhHvbhHwbiIBbiISbGgAAAOw== ------=_NextPart_000_0005_01C6EF30.379B4870-- From jjdmvqeeq@somersetnissan.com Sat Oct 14 00:30:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYb9w-0007u5-LS for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 00:30:04 -0400 Received: from [201.32.250.176] (helo=[201.32.250.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYb9q-00085y-TZ for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 00:30:04 -0400 Message-ID: <000d01c6ef49$5cf46750$b0fa20c9@pc2> From: "Territory install" To: capwap-archive@lists.ietf.org Subject: Out Date: Sat, 14 Oct 2006 01:29:39 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6EF30.37A72F50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.8 (+++) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 ------=_NextPart_000_0009_01C6EF30.37A72F50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6EF30.37A72F50" ------=_NextPart_001_000A_01C6EF30.37A72F50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Packs perks that make worth its price tag including features of watch =20 record tv in gt software a releases Rock. Hayakawa Hawthorne a Heights or boy Punkpop Knight Online or Global mu =20 or Conquer in Little Fighter of Fifa Mario. Serial killer Michael Connellys Fiction in John Grisham pens gripping am =20 tale Buzz. Annexsave of up to or Gamespc by a by City Statefind Instore Event Near =20 Hourly Food. App or will of let burn cds of but packs perks that make worth. Setsmusic Services Free Offer not Join a stores of Seasons Biggest Bosch =20 hunts of serial killer Michael Connellys Fiction in John. Browse genres Editors Picks am weeks am Subscribe free mps legal in dj =20 Krush zen master behind minute youre. Country represent then take drivers from around in world games or =20 Bejeweled Deluxe cue am Scrabble Diner am Dash Monopoly! User Nero Ultra Edition Just about any competent jukebox app will is let =20 a burn cds but! Company Heroes Return Castle Enemy Territory install Microsoft Directx =20 Drivers am blogs Posted Minute! Francisco in opinion is smashup a Alans brush spyware ended him smashing =20 infected hard pieces What am heck. Missed Filed under Dance in Trip hop Rating Writing featuring Johnny =20 Cash in kt Tunstall Letoya Shots Days Full or album. Myspace is Xanga Live Journal Page From of Item of Random Featured Name =20 Contests Prize. Let burn cds or but am packs perks that make is worth its price tag =20 including. User Nero Ultra Edition Just a about any competent jukebox app will a =20 let burn of. Analyzing financial situation changes worth Holding Pattern same amazing =20 youd airpla ------=_NextPart_001_000A_01C6EF30.37A72F50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Packs perks that make worth its price = tag including=20 features of watch record tv in gt software a releases Rock.
Hayakawa=20 Hawthorne a Heights or boy Punkpop Knight Online or Global mu or Conquer = in=20 Little Fighter of Fifa Mario.
Serial killer Michael Connellys Fiction = in John=20 Grisham pens gripping am tale Buzz.
3D""
Annexsave of up to or Gamespc by a by = City=20 Statefind Instore Event Near Hourly Food.
App or will of let burn cds = of but=20 packs perks that make worth.
Setsmusic Services Free Offer not Join a = stores=20 of Seasons Biggest Bosch hunts of serial killer Michael Connellys = Fiction in=20 John.
Browse genres Editors Picks am weeks am Subscribe free mps = legal in dj=20 Krush zen master behind minute youre.
Country represent then take = drivers=20 from around in world games or Bejeweled Deluxe cue am Scrabble Diner am = Dash=20 Monopoly!
User Nero Ultra Edition Just about any competent jukebox = app will=20 is let a burn cds but!
Company Heroes Return Castle Enemy Territory = install=20 Microsoft Directx Drivers am blogs Posted Minute!
Francisco in = opinion is=20 smashup a Alans brush spyware ended him smashing infected hard pieces = What am=20 heck.
Missed Filed under Dance in Trip hop Rating Writing featuring = Johnny=20 Cash in kt Tunstall Letoya Shots Days Full or album.
Myspace is Xanga = Live=20 Journal Page From of Item of Random Featured Name Contests Prize.
Let = burn=20 cds or but am packs perks that make is worth its price tag = including.
User=20 Nero Ultra Edition Just a about any competent jukebox app will a let = burn=20 of.
Analyzing financial situation changes worth Holding Pattern same = amazing=20 youd airplane window seat without chatty!
------=_NextPart_001_000A_01C6EF30.37A72F50-- ------=_NextPart_000_0009_01C6EF30.37A72F50 Content-Type: image/gif; name="final.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6ef49$5cf1f650$b0fa20c9@pc2> R0lGODlhnAHkAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAVAAAALAAAAACcAeQBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJEyScq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOHXia6tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MP+ix9Pvrz58+jTq1/Pvr379/Djy59Pv779 +/jz69/PXyGH/gAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGF6HAoWEefkhY iCKWaOKJKKao4oostujiizDGKOOMNNZo44045qjjjjyqNUGPQAYp5JBEFmnkkUgmqeSSTDbp 5JNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZpJoHcnKnmmmy2iV8hbsYp55x01mnnnXjm qeeefPbpJ27//clSoIKqRGihKB2KqEmKLkpSo46KBGmkIE1KqUeWXspRpppqxGmnoIYq6qgK FkOqR6aeylGqqmrEaqv/GL0Kq0WyzkpRrbbmquuuvPbqK15v/CrssMQWa+yxyCar7LLMNuvs eLY8O1C00gpErbTXYlvtP9k+222z34K7bbjblmvuueimq+667Lbr7rvwxivvvPTWa++9+Oar 77789uvvvwAHLPDABBds8MEIJ6zwwgw37PDDEEcs8cQUV2zxxRhnrPHGHHfs8ccghyzyyCSX bPLJKKes8sost+zyy/M6AfPMNNds880456zzzjz37PPPQAct9NBEF2300UgnbfI75r7DdLlO N/30tlMrbbWLDmybdbVbS9v11WCHLfbYZJdt9tlop6322my37fbbd41irtzl0r2t3ZdlkCDe jpbpjeAofFPmN9yEF2744YgnrvjiPFfD+OOQD0xN5DkSQPnlmGeu+eacd+45f8qYG3q5o29b erWnS6tM6sB18vnrsMe+8VKy84VP7bjnrvvuvPfu++/AB597DsIXb/zxyCev/PLMN+/889BH L/301Fdv/fXYZ6/99tx37/334Icv/vjkl2/++einr35qAQEAIfkEAH/WAAAsAAAAAJwB5AEH CP4A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKl y5cwY8qcSbOmzZs4c/4TwFOAQJ4HfQIlCLSnUZ8/jSY9inRp051MCx41OPQn0ac9r0YdOBUq 1adasYItyhRpVZ1o09qsmlWq16tvv3IVK5Vu3LhsxzZte5cv3L9J7wau+/dsX71qEyuGmdew UMSGB0sWfHZoZbN2587dy1kwZbqRQ9t1nHny4tOoR7KFilWyZbCmCWsmfDm2bNazvYoGfDt3 bLK9SaceTtzjatxW8WLe2pX37rxhYQcGXnu37+jNfz8Ojri49+8Uj/4jxzw78mbh13Vndyqd +nbX3W17Rg+X/mfw+PMzFI+7M/T9pT1HXkICqneeX4chZF16wDkXn34QRsgfa/51Jpdv9r2W W211NTYghg82yNtkGjoY4YkoAgabXyy2Z+F1HMb4YoebwVhagguCuOGDnqXo42JK7RSUWER2 tV6PQZr2GoIj/qfjV23lGBaUUpr345VYZqnlllx26eWXYIYp5phklmnmmWimqWZLx6zp5ptw xinnnHTWaeedeOap55589ulRPoAGms8/ggpKaKGDCgToQYsu9MEHBEE60KMCPUrpP5dGKilC lnY66aYGefpppJoWlCmmoIpaKaiootopq/+rHnSpqKdO6qqlpsLqZ1qNMpqoor8eCmywhxIr 66a4xqpsq7kqdOqsuj4raabJMjvqtdIuG2u2ubJaLbW1YmqtteHuilavBqGrbqKBFtSuo8iC e+242oaa6rTR3rvst7BCOy+ztVLKrabeyrtqwOMabG5i6Lob7LqKChtxw8d+Gu+84Zb7r7/N NgvuxR1zXGrAkA5sK7XkIusqqSTXu7BOiD4s80C9Dtoou8ZWLHDJ+rqs8cGqZtwvvq3uzCm/ 9tJrtMvizrqvyitXqjTRL6tFMc0yG0ozsIRyzZDRj/IzsNDO9kx2yDwXrau2ZLf86tpEU02u xVK3TG/VOF3ttdf+6mLt99dpL/100gm5PTThYKd9dKkeFwww3BiDLC7dimO7NkaU4L2R3hLv XfPfnZf9cc93/zz13QnHO3rhjlve+L+2Dr5vt5WjrnlOnEP8d86hi04346VfnjrTJvMrvN2y Pw587ITP3e3wTN8+U+4zE7Qo75x3vHGyb/P8Ku3Gq3pr89ETX63FCtcLN75OJ/229tLHL//8 9Ndv//3456///vz37///AAygAAdIwALeBAAGTKACF0g/fjiQHwRx4EEgGEEKFkSCA3mgBf+B wQtyUIMbzGAHP1hBhGhwgif8IAg3mEKBrNCCL4TgCxUyQhe2sIYMXMwIMfhAg4SwhxX+pOAO hYhDGbLwh0Ms4QWPKEIl2nCJSkwiCX3IRCrWEIdTzCFqpNhCFy4RiUSMIhAzmMUySpCLIXxi E9XIxjKaMYxrxKIUUehEKGrxNEWUoQoj6MEOGtGNJDQiC93oxz/GMY15BKQd2/hENNJxjY+0 YRexeEedJJKIMOyjEBuJSD3u0YtXhKEhRSjHTiqyjpdcISlBmEVKtrGQkKykWi5JSi/yMZCc pCIHa7nLULLRl5FsoitfaUpHWnGMJqyiGocpy5rQspY/hOQZixnEXiJRkl08ZSoXMkdhXrOU jNRlLHmYxmbmhItfjOYv4bjMdL6Rkd1cZCuVScgq+hKc4UT/JT3NmRh0ftGDj/RnNY05znIS s6B1fKdC8ZlPeLKTmfykySSDuctgTlSXqoylQhOSTWxe85hBvOEMgRnSIcYzoihNqUpXytKW uvSlMI2pTGdK05ra9KY4zalOd8rTnvr0p0ANqlCHSlSBwKKoSKXIUZOa0y0w9alQjapUp0rV qlr1qljNqla3ytWuevWrYA2rWMdK1rKa9axoTata18rWtrr1rXCNq1znSlerggMcDrkrmPSq JQD41a9puatgBSJYvhYWr4QtbGIHe1jELpav/zjsYxEr2cg6Vq+VnaxlB7tZyFq2IIaVrGc/ SxDIVta0jpXIaVfLWc02trOXTS1p/jVL2tBmCbCK8Sxqa0vZ1I42sQax7WyHO1vMxpa3wC2t b2U7kNYylrnOHa1wP7vbiVS3uMxNrnKb29vFcne5wDUud2+LwIL8tbznReBfBZLegZyXve/9 B24Bi9uE6Pa4wr3vQX6bX/BuN7z47S5x9bvf54oXtAb2L3Y7C9vvdlfB15UuXvl7XN4al8AX lu1viwMFhNQXviCeL3rVO2LzkjjEJf5wgZ873v4mWMHjtXCGBUzdACdXwi8GLYMPXNodQ9jG N57wg1u7YO1KuMFGFrCQeYxcImvXRyoWsXxLPOUqW7m9Up6yihVC4BpHF8FfBvN1XQtkL495 wIptbpAt/hzZNcd4wdWdsZCDW+Ei0/nOtG0zch3cW+hmN0JRTjGV6StoFINYy+VtSJfFe+Y3 U9jOCIazjc+84eH6Gc54TnKLK8xk4tq50U/WtGkzjeYjXynQhr7yiass5Sxb+dUIWfSc95zp R9M60rvNtZI1/Gfd3jnXpI7wrJvM61rX+ci23vOlO83kSgM6vtAeNInXC9/1urq+W460cjmr 6xy/2dFLnjGfx11k0So2s4TF82sv/V8kb1bZ584uuu/L4mQDG9fDdrOz05TthvRbgftGU8DP 9O+FFDyBAydTwuvK8IY7/OEQj/iPEr0RinPE4hLPSXsNcnCIUJzaBNk4yN3L/xCLYzvRJs94 Wlz9kfeiPCHqJXnIzWvimcscvTRXuU5aHXMR+5zKB4k5e2XO8aEb/ehEJ3rK5cv0ouscJzwn NKx5DvOmWx3jRn950pF+9PheOehPh3q03bvqao8c5vPdeteTjvL0av3qOf8w1sMOE1Sn+tAe Z/rbbQ53tWP87SnHOdcbwgS6j8TurP64yedOcqE3fe+QdzrfI/94tTOk8IYPCeJ/bvaycxzk oN/62a3OddBHmeyWJ3zmwcN4irQeI69fPZQ9EnvXy/72uM+97nfPe5t2vOO9N9PGI/L72v8j AMhH/vGTr3zmB2AgyidI9IOvGOArpPgOmT70ny+Q6P57f/rJp/5i7E5oa/+87VRXiPa7z/3l s5/9zQ+/+BMj8kKr+v5UP7jzt89/9x9/+fE3f9UXbVmWflKXeNnXfv0HgOD3fv4ngANododm gKt2gAyxfg8YgN1nEBgIgTvXdqiHf/YndfqngA7of97HgSbogTYxfK9WgNN2cumXEBgIfu3X fCrIgqhhfTpYNTzYg0AYhEI4hERYhFVlfEYIEi7Yea63hBbxg0tXbUmohIzHcsSHhA7Bg2O3 dlPYEf92chJ4fzVHdq3GhIgmgV9Ien2nhl0Ie6P3gosnhiGHdeVXgXYIh1UXhXvXhhUXg3iI aCOWbXLnciCYeIT4ECMHeP98SHt/B4IwKIiFaIEziHf+toZ7uIhNSIkTKG0h+HkhKIn214kH 53iKiIluCImJ6HX9NojmN4fUVn+eZ2IySIamSBM/mIVYeH21OH65eH1vaHu7GIzCOIxFeATE eIzImIzKSFUdtox10ozOOCfQGI1xMo3UeI3YmI3auI3c2I3e+I3gGI7iOI7kWI7meI7omI7q uI7s2I7u+I7wGI/yOI/1w0qqxEoOlVCFJEqcBET4uEqC1EOw5EetpEKjhEnIJEnSVJAG+VAH 6VENWU8RSZAZ9VOJtEyYxEsKuZGfFEjspE3lBEv9CEo8hJGbxExj5I+fdJAsuZISqZECeUSb 1FD/O3WRU0RO02RSAZlLBolQFLVO3nRGPQlHJzRKdISTelSU87SUSklSQxmTIVVRS9lT/yiS JVmUg4SVPIlM9phN/ziVuNSU/niSUMlRhrSTaMmPA/mU6ZSUUGmPPQmUVGlKEGlL5HRLd+mR HFlPCVmV/NhICpmRNxmYgulNdimUezSQakmY8kSURlmYEHVTNjlNZNSYGHWPKWlQlCSSTClM h2RLeklMcAmYPBmauFSar3SZtwSWQDWZRClOoGmYuZSXsLlInImYoISXM0mSPnmauUlGiumZ wPlRsYmagySXPOWawolKqrmVAfmcbalPKgmcfKSUlVmRnUmd1ylS03mY/zEpkJcJnpXJmvRY nuZ5nuiZnuq5nkd4cWxYfQTndRPRiLdIhZ1Ydx7WiySheIo3hqymd+9ZdWiXeiU3igSnEX9H oCcBhjIxd/V5eNZ2c0FXiAB6cZdYiYPHd2RCn0MXiLSYiEo3i1q2dkL3iiLaoRVqoidKgFIo oixqc4EYo7QId6roczOKokXnoADacynKeTMnnykqhZVHeoH3eCqKo68IZS7XeIJXoYOndS/3 cY3HpEgXpWDHoz8qejQ6pZVnpTgadyTKpU5KikQqplkad2fHo2o6pmvIplxKpoInpT/apHDa pBk6HCA6eVd3iE9qeq0Ypl/KnxYooUZKXzcXof8duqRdqqhOCqOAyqZe2qhYRodyp3SOuqOY GqhnWqY7uqRYWnqWCIh72lc556Y1l6BtinqRSqaWV6ldKqZwaqZD6niPSoaICqmwuqWtmqB2 Snk4t6aruqly+qkoSqtFWqtq+KA7WKqsWqaoOqTOmquUx6mgGqzW+qaaGqlsp6u4mq166neN 2qZFuqaamqsh2neXCKWWqq1ZN3uyWKU2SonDGq8jioauKKRpiqaGmnUq6qGziq+HqqGxyq/o x6pHWq+2aob5mqVYmqRVKq6fiG27CnkHi34K+lP6yXrl+ItYkrHs+bEgG7IiG1Ye26ASh2Wu GIdcGIbDF2j7eqcoW3L/eMegZ0iihJinNFqHtmqnE3qLOJufFiukmmhwQEp8n6esG1qq4lqK yCqvSqujGiqgNCux7QqtURuq0MqzAXqnMsuvuuitVZt3GfGsJRsmUYi17Mqu//q0Hqa0bVus a6uuF0q2hKqukne3+MqxF3ql0jqfR4uks4izQVuvDpupB4uwxAFt35q1ydqvdXu0vxizX4up ccqFrCinNPepdBqGXEu45sq2XWutHNuzL1uBZkq33Mqtpruu+XG28tmrkkerVfusAeq65Yeu s8u5ruq2cAuloZejtzunt0q7W2upYEukwQuqgcqnbFijf6q6S/u83uG6Xdeysdu4jLqtYHe1 /9e7qIoarHjbu4+bobUnu3tIvHd7rZ3rtuB7qk43twNrqu+JtDNBvWGbqqnLqfZ7tsW7sl/q ppUbvv67ufNbie1bwFqqpwdscMyKtf9ruduqvtSKuYl7s8Y6wZDLhJibvTy7eAXXwdEqrar4 tnt6wSLniy6api+KvfTqp2J7r8jrr1MHoy0sg8Yar6MbP2W7vvT3hBWxww8HxDyMFmWbsUI8 skicxEq8xENVvrtyxLQnEUZ8IjSLn6Q7tjCMv7hYsAUri3XohzPrwQQ8oENMwjVBwQKahRfL qx94ny9Bh15ovHvLwA9LoHBsuRQKqLFHtX57QNwrwGn8elALdYbro/8I+6LP67iIS6m/WrPb m6wj6rz/q4etSr5ynKms68Rxmnazysd5a8iFC8aEa8Mw7Kf+SrGifLh6R6/4Sazy261BCsuy 27xUqsWp2qx1yr7Gq698LLfhGqXGV6K62si8e7zxG7/Qu8vNWq4re6zC2oKzO7z2mqiI+quM Ost0y7QN/MzU/LIJbMuWrLv3W7Oo6KgxCKywxsLQK8E3LM3KjK5JSskEi82jaovtys75W7mU jL7tO8jOnLZ4q80CbLdrq6VOjMniO7MK3LfGTK0DzLrlar4QHa6/DMUX8c/rzNDEDMtR28/K C8GPOssQC64IjLuXunR7rKqECsl1LMsZPcn/nxuqHr3NHP3A/YsSKO3OBHjK0UzAW4bICfuk WfyfBAuzp5ey4/zQKP3Rghyxpfi7SA2+pgzPMgykNQzKE0rVQGekiAto9Yuh9mPRfqwnOZwS wRzWHZt5SEATecDEbv3WcL0STS3Wk9u1aixTdF1xWEzEDJzXZkzHfy3SiEi/bnzXc1jYLeGg ZW3YJZGLQOzXeq2LkA3IjwzWwHjTBdrHhz20iV3ZCLpze22y3hu0mvuu/yrJnNuiTBq40xzP I73aPn3UpI3DldqwoEzKo1x2ivyzgLu5Vu3CQtujs73RVZ2KnFzIqZzCea3PfbvMXkrcydzS yIzMq/zQz6y2uau9/xRNrjHt0sx9vH7n2zF9vvMr3pnM0BgMzNKduYvrntwdqxsdpu8tqhQ7 0bo9zLf6y+ydrXcMdDZMz51cutO8ytXczdRdqDI93oc6qNWb3zFbote80Mys1XC42FJMuc39 wFY63/J82P1c2tPN0uidx24nihINpt6N3rm7z+mb4BP+4e3t0K8q4hsc3dHtzUq40vBN0oz7 0gV8wCCez49s3g5NwVKqthiNz8/d0Hdsqscs4UU+0Teu4A1t39wcxWHL0/D71Ase1EJrwQB7 hjLKvzfqvNPGtodreh094DJKzpy8ybGdwfyZsFa94GcusMo9wLituw4u4GJ+otB8aohIxf8a 9x2TDZ+CztiGTtiHZ+hx/eiQHunraMSH3oKCLXw+3NgXjSb6ucOTfdZ2HuN2LdpXuIoXC9iN /sdpXCadDnukTtH+S6rhjNmrLhJFvCWu7ebEbNzC3aIeHLcuW+GbGN9HDrQIDrA9N9WlbKO3 3ebF7c+f7MgzCuE4fOzTzuzO7sjKPu3WvqyJGtJfF7vmDbsrrr0gDKn7e9TeDd3TOswTjqvY jdRTvq5EvrqgG8s7XuXAG+uI7uT0XdhMK8zpjcnDOs/g3dLrreRUrscRLc3nnM4NPNPgbuD1 LLDYCu+wvcxivrN4+rknfp8BX9BbWtqP68s2jcY1rvAvLuHsnuH/njjk8z7x+r3ZCX/PUwrQ NV/GoM3MB17jDB/lWX7SuIvka27lKg/0+O7jJD/O+JzzPq7d7o7x+h7zO3jcut7gNO25Vhvu JYzi2a71XpzaVM3tDR/sWm/NpPzcLRz2X67xhXv1XW/aDov20H3IKuzNFk5AlZ4RS0DrtW6O e3+Kri7phF/4vPcKht+ef+/DJQvHga/zL2wSdP34NE/ZfDLHMVz5eQjrli2rih75ka15T4va 0g7OPzzqnn3QbzLHEe73Ng36r2/rLWfWV0vQPu+eqO7ZbhLArm1+p+f4xp52tt3m8p7rxl/b o1exbf/r2n73vc32Z8/bGP2hwO3lvW/2/86vuDvdzV7eujb/7Q683WLP3Byu3fley8CP8Azr +fv9yuhv/uyNyjguys382rlMyye/0Ne6wBpb/vU/1AAB4N9AgQQHGvxXUODChA0LOjz4sKHB hwwVAsA4MaFEihEPbvyIMeNCkSQ/RhSpkSFClCNbZvSIsCRElhpr0rRZ0WNJiTp9xgy58yRI lhaFdvx5c+hSpk2dPoXq1OhKnDqVruwJdKJCiEY71kzaVaVNol/JgvzJkWBWs1TZVmUa1mvO kxzdBi16Nq/coWHr3gUslG9UwoUNHwbKtW3ivjjzxuQ6dazVvYInNz6qNzBluos5D+4M967W x58Zm/ZM+nLcy/58A8tEHFt2bMopc45eC5Nn7rqwJW9UTHYm8K8zK8LM3BO5cd7E/7qUafvl bbvSmQN/G3K5dJRjnU9vrvz5Vd2CbQ8fjX72evbtEat1H1/+fPqy4Q9cUb/9ff1N7R7mrz8B B1SNQAMPRNA/p/JLMKoAEfzPQeQapLBCCy/EcD4GM+SwQw8/BDFEEQnbcEQTT0QxRRVXZLFF F1+EMUYZZ6QxwwdrxHG9GweckLAd4/vRPgg93C1I7HB80MgRI3QvScM4I1BJpfDSSz4obSyQ tRynpFJGKQtzEsws9fvyqSvnO/PC47ZjUruLTDoyvPNIm5Mi69h0jrvzesxTt5HeLP5rTzy/ aylOkvyEs09Em5MzMjfj/E7Qvsp7E1Ca9ISUt+EIJW5Q9P7ks8LavLvqKEdvei20U12jEr5R tUpq1dTMIlVV0XxLrlbG7OytMlpRcyg4wIILCljQtpoVLi4THHU31WJd7EirqMptudOuK0qt V8EytTg7U/LL2bVOWy0ybN3SltxeJzNuzQlBOxS6snLdNVhMkWX1MQyb1bJVZG+NllrN1IX1 L3+5VVdWx1ZbFi3LvF3Yr3n5XVfice+DVziD6dVXYMiSxa1MKwlus1yQSU0XV4apTbnjLqG9 9OS3XG2tW4AXtpVWl00zFmWGC+45WthuDpnDV7kDr05z2f4selJhIb3zIk6JQlrRobGK7mmr H21N6axLO3TdPJeS19KonQZLUpV6xO1iyNi+urzodN1SQQBpq1tAkfPmu28x737Pb/r2Frxw w00s4nDFF2e878QbhzxyyVl8fHLLL8f8wsoz57xzvQnvEsXNPSe99NkwDrVK1aUalNDUCRvd dNlnl4rsAvmTMt9/aee99/0WpVNT4DedE+OVV/c9eeVt11njmXP1yfjjN12+eut9DZ1lkrHz eGeOrwffd4v/ez7ZKZ8/Nnz1ZbfYu/KJPovJVIldv37O60S7UKoRXZM8tSO1lv0EOEACFtCA B0RgAhW4QAZaSAcNhGAEJThBCv5W0IIXxGAGNbhBDnYwg5fwYAhFOEISljBGWTBhCpeHQhW2 kHYsdGEMSwdDGdYQczS0IYaYkEML4ZCHFdrhDxPkQyE2KIhFNBARkXigIy6xP0p0IoGaGEUq 4miKVcRiFrW4RS520YtfBGMYxThGMpbRjGdEYxrVuEY2ttGNb4RjHOU4RzrWkSn84Icd9fgP POZxIHiMDSBP0kdBtqeQByGkH010SD76MZF5fOQgCbnHBPURkYo0DCMbSR9NClKTH7LkHwH5 yU1KkpIUGqUjJylKT6qykYdk5CpHyUpFTnKVosQlLS/ZylbicpavVGUhbwlMYpKyk5jU5SYh OcxTEv8mlbl8pjJdeUxL9tKW08TkMaGJzY9YE5vR3GYpB1nMZd4RmeIM5zVz2UxnlrOU0YSn O7uZTW7SMpW9lGQogXlPV0rTl7Wk5zVjmc5gXnIosaznO8/JTnMmUqEP9eZB6flPg+ZTngYV 5jnV6U+OopOa2ZSoODMa0nlSNJwMhcpII8pRcFaUoC41pTYfupR4QhSgJaUpSGN603XC1KYV bSlKTflPfd7Soa/E6S77aU9isjKpvOSnUpV6UVkKFJkaDWZRF3rUqk61p0JVIynBykaxjtWs Z0VrWtW6Vra29XIlGxPeaseiG4FOceKSq5vs+rvuVIt7TgPdXrMXv7n+zW7+K4KrYAu315Yp 1j7HOR/zUATXhikpTIiFimP9pi1KMQpc70qMp+Qmlq25TizSC1147IU7RrXWUDspnqZqBa6t MM2zSFPbZ/3aKK1hZmmK+SyfvLZa/W2pSLDFHmGH5hjXEKt9kkHts5BLt+aJTXe/EdraGnPd l9msbfBj3qlIqy+T3Sxv8lubbv3nrkRx9yWJ+tilApjajNkuVNTj7lzwVTG9sou2CPOVeCvl PtVB92HkTct44Wtc/p5JXvHVzPxmSza2iJdujfWZZEELYAnr18IZNu+EEyazj7EWux4uGFIU 3FcG+2tbOJsW0KCX4tBoDMSDFRr9stMzVmmvVN7+OxmNsQa/F2O4ZvUi8HKzg6T8KcdSE8PL /6LGsuHBrVXWiUtuweM84eppyq8FlIOpzL/bsm14vvnyqJ7w491hpWzjKQ1sNbvFOTt2zvXJ 3T/W3DC3ksnPaKLre/aMvD5rcdCFLuOhEb1oRjeab3cmtGSJ1B9I+0hITfrQ6w7LvsxeGnB/ 7heON42ZSG+5sKd+0nN2lKZxebrThq10jSD9pVkHLrWp5vOtUR1qXOeav/6Jta+RvDj8hdl9 LplWl8/8tdoOuFP9MxRo3Qwqs0kbt9Qu7vnI3Klmo2rbmeLs04KbsjBD2yv/a9SvsO3aFu+X LuE63vZ6PGN3h5hq07v/nYjjzeb5pct46Sv2viMEXM98WMjTrdd3cyQuniF8VfiVc2f/2mE0 /xfG9K6Kvw/+rQ3rVcLTqc6b00Rx8v6L4MfVGcSTuzPqtftgOcYa/QhmM4wPWWDjq7lwshI0 nLEZexT7OXWJjGSe2NzGzN34xVf+6BJzq+Eu25738iXgnwUd598Desnc+7Ot92brOzY5vok+ cyCX+kUB57a0RutkwLaW7d1+rcnX3mqwvRktcIOS3asWba09GFt+Tfa7zrZbuzs9bn3/NnW0 fexgE7DxYnN0BR8/tchX3vKXx3zmNb95ptt6X0veda9BrTfGabpD3WOy5/H8al0P2/Vx3Q/r /l0d6E+vHrB1Ha/LDWv7XV82uqMenIEmDyTVo4lmdxt+lLTM7GovSrTA05+Xn58pbquXeBKP /pcLRanBT5vZ2Ve2qovz7dhaPOSuRXtsIc8l65NWUOHePtwpH3sSq3hWVL+60sFrq5NDz8RY x5Xm2q6Bya7u4hWxCxaoW7r8Oj7xizIVmwuFU7elAzSOezjamjoLrLoN/DoXU5nV6p5zETFH iR6Lk5Z5Cbr+ijrREMHMWMCmmzheI7WwM7AC/Dv2QsEKvDgdE7sPyz+P6cARCzEMO5b+k5is Q5+kE7iqezqyIzAelDRJM8IV47GX0w5Qa5ojAxj8c8EXDDL++8BU/5G3FCPBnPsVD+QwNETA 7yJCUtsW1KswMoTA/eO6sTM7H0G3t2s+goO7ZIOzcIM2h/G2mCEu1Wq7wIvDFRsbkJsatDM1 9QA/c7tCbZM504o+CqsNKytD79OVTxkzz8IsNQqSMkm+DSrFERrF2eO8VWTFVnTFV4RF+piH WIyiWaTFJbLFWyyiXNTFH+LFXsyhXwTGYSTGYjTGY0TGZFTGZWTGZnTGZ4TGaJTGaaTGarTG a8TGbNTGbeTGbvTGbwTHcBTHcSTHcjRHxVGAdEzHf1BHdWTHdjyIdfwIeRwIebRHBXjHdaTH d1yKdsTHeoRHgHRHf/xHgIxHfKTHe4RHf/88CYI8yIJcSIgUyH3MR31kSIF8yIRkyIiMx4nc R4pUyHvsyIt8yIM0SIpkIJTUSIPMx5I0SX6ESZF8yYb8R4s0SZSEyXmESITcyZycSZ1kCnd8 SaHkyaAsSKDUyZ70yY+sSXv0SZrcyaI8SaeUSYxkSZuUIJVUypCsSKSUyap8yquUSn7ESa28 yZ40y6Eoy7HkyrGkyX48SqwES6acSHYMy4zsypVcyJwUSY0EywYiyZWMybw8SrJky6ZEyrc0 zLMUSpZMSo6cSrUMSMcESsHkSYtsTI9MzMWMybj0zHokzKa4zKLUy9AUS74kysJMSdX0y4Q8 zceczLlUzYpETLH/bMy05EzOHMjZVMjIvEqrJEnNpEy5nMzhrEmM7M2O7EzUtMuWtEy3FMwI wk2sbM7NbMnrXM6f1M7odMzpPEzmXEvGDEinpMy7ZE6PtEmQ/MzqpM6PlEzwPEvxvE2llE7W 3MrjVEyvXE+6fM/EVE/tBE+0FFC4jM/XjMv8zM/oJM7NJE/Q5E77hM+RrE0Fnc367M8Itc7s JMzdzEytTM0OhVDbbE3MVE/INEx9nEfahEr+DNCZbM3qbE6HVE79JMoUDUz65M5z1NEd5dEe 9dEfBdIgLQycFFLGCc6LdE0SZdGpDMmmBFETJVHhzMjvtEq+1MzgrNIbzcy6lFH0lFID/x1P Ad1SFU3KKYVKM0VQBPpKMXVQ+nTJ6/xLIu3O+yzP7cRRv2zTNC1TMK3TJfVPN+3LAfXN/1zK 59xTDa1TA9JLMUXIC8XLMC1POT3P7CRSQl3OtnzKSpXKRbXTDJ1TO63K9tzUwgzVUR1KU83U CiUgTj3JrtTT0aTUMB1T1ERSJ7VU9ERMqtzNFSVVVM3NW9VUF+3VUm3RVP1UYtXN2gRQRd1J LShN7ATQCVXWWh1TCp1TEE3QXMXPXfXUZC1QY13WSfXOb1VSycRWZCXOalXVAWJVsoxW1uxP 3OzTO51X61zUjfzWRCXI78xRPxXWd/1XTjXLERVV2kzPEFWgNf+9yRR91XhF2Hr91LD003ZF UQnV02JVWAQN1oj9U3L1VT4d1Gn92Pp80gaF0T59z4j80PA8Vg710IJ9VtBU0SNl1Kh82XBl ylnN2RHl2GI9UWt90HUt0qEl2qI12qNF2qRV2qTNWOyU0Y0EVJV1WTctVKkdVjQlUzR1zU4l 0yQtTqdVVimFWllt0iv92p+E1BZq2i3t16i90DWNyrcN2/l8zWyF00Pl1hPN06o91Y5lWYyF zrDN0l51oYylzknt2XHtzCi1W8DN14AdyMc0zZ+1S0N9Ub/lTXoNVP0k0EgVWg862HxtW5ql WwOd3H91XCZlURQtTliF2cnd3LrE3M7LDdCVHdlr/UsT2ldB7VnE9c7brFthPVeRvctn7dDT NN6CzU2J5d2ODdmq3dhL/dwO+lBcRd3rZV5yddSWnVKYzdyFHc6URUuPNViq9Vnn9Va6jN7Y LVzi5VhL9VdDPdnsBVlvLd7xndH5fV2L1dAcPd/rXVD+/NvcVVv39V0oXU/0rdgMBdqaxVrh PND8FVH8bNPSRVysvVHYhGAEXlG8NM+lBeEQFuERJuESNuETRuEUVuEVZuEWduEXhuEYluEZ puEatuEbxuEECggAOw== ------=_NextPart_000_0009_01C6EF30.37A72F50-- From tplynkxf@studiozanco.com Sat Oct 14 08:05:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYiGo-0001bd-Jj for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 08:05:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYiGo-00019k-Fl for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 08:05:38 -0400 Received: from [80.125.252.93] (helo=[80.125.252.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYiGe-0002V2-GG for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 08:05:38 -0400 Message-ID: <001401c6ef88$ff6cf800$5dfc7d50@SERVEUR> From: "for" To: capwap-archive@lists.ietf.org Subject: Business Solutions NEW Date: Sat, 14 Oct 2006 14:05:10 -0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0010_01C6EF99.C2F5C800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.6 (+++) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc ------=_NextPart_000_0010_01C6EF99.C2F5C800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0011_01C6EF99.C2F5C800" ------=_NextPart_001_0011_01C6EF99.C2F5C800 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Magazine day October Noon by Siobhan san Francisco found in this =20 sidewalk next debris box Central of. Hey am Thats me Preorder upcoming Polaroid is book of shipping Order get =20 Free tee Design Arthur Jones in Brad. Know of Place Name optional is eg Food Schools or Look up Category =20 Airport Address Code Outside us in. Shortest Time Distance Avoid Highways Tolls Roads Mapquest turns phone =20 in into full gps tool is more Online Offers! Saturday Dirty is Sextv Youtube Contest do people ever discover their in =20 own in Totally Peep hey Thats. Kids homework is todo lists ticket stubs poetry a napkins a telephone =20 bills doodles anything that. Place Name optional eg or Food Schools Look or up Category Airport =20 Address Code. Advanced Options Shortest am Time Distance Avoid Highways Tolls Roads =20 Mapquest or turns phone into full. Tickets Home Addwork Company Advertise Openapi Link is Toolbar Privacy =20 Legal copy inc all rights reserved Apple Quicktime gt. Use is Computer Found a Magazine day in October Noon is by Siobhan am =20 san Francisco found or this is sidewalk. Cars Flowers European Vacations Cruise Airfare a Discounts Luxury Event =20 Tickets Home Addwork Company Advertise Openapi Link Toolbar Privacy. Name optional eg Food Schools Look up a Category Airport Address Code =20 of? To Learn am more try it now you Find it Keep a. Hey Thats me Preorder upcoming Polaroid is book shipping Order get Free =20 a tee Design Arthur Jones. Share of am gold is Play a now Free gas of Giveaway is lucky city new =20 Navigator Incar the palm hand. Play now Free gas am Giveaway lucky city new Navigator Incar the is p ------=_NextPart_001_0011_01C6EF99.C2F5C800 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Magazine day October Noon by Siobhan = san Francisco=20 found in this sidewalk next debris box Central of.
Hey am Thats me = Preorder=20 upcoming Polaroid is book of shipping Order get Free tee Design Arthur = Jones in=20 Brad.
Know of Place Name optional is eg Food Schools or Look up = Category=20 Airport Address Code Outside us in.
3D""
Shortest Time Distance Avoid Highways = Tolls Roads=20 Mapquest turns phone in into full gps tool is more Online = Offers!
Saturday=20 Dirty is Sextv Youtube Contest do people ever discover their in own in = Totally=20 Peep hey Thats.
Kids homework is todo lists ticket stubs poetry a = napkins a=20 telephone bills doodles anything that.
Place Name optional eg or Food = Schools=20 Look or up Category Airport Address Code.
Advanced Options Shortest = am Time=20 Distance Avoid Highways Tolls Roads Mapquest or turns phone into=20 full.
Tickets Home Addwork Company Advertise Openapi Link is Toolbar = Privacy=20 Legal copy inc all rights reserved Apple Quicktime gt.
Use is = Computer Found=20 a Magazine day in October Noon is by Siobhan am san Francisco found or = this is=20 sidewalk.
Cars Flowers European Vacations Cruise Airfare a Discounts = Luxury=20 Event Tickets Home Addwork Company Advertise Openapi Link Toolbar=20 Privacy.
Name optional eg Food Schools Look up a Category Airport = Address=20 Code of?
To Learn am more try it now you Find it Keep a.
Hey Thats = me=20 Preorder upcoming Polaroid is book shipping Order get Free a tee Design = Arthur=20 Jones.
Share of am gold is Play a now Free gas of Giveaway is lucky = city new=20 Navigator Incar the palm hand.
Play now Free gas am Giveaway lucky = city new=20 Navigator Incar the is palm hand a Sprint = Nextel!
------=_NextPart_001_0011_01C6EF99.C2F5C800-- ------=_NextPart_000_0010_01C6EF99.C2F5C800 Content-Type: image/gif; name="doodles.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01c6ef88$ff6cf800$5dfc7d50@SERVEUR> R0lGODlhnAHkAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////yH5BACk1AAALAAAAACcAeQBBwj+AP8JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHP+E8BTgECeB30CJQi0p1GfP40mPYp0adOdTAseNTj0J9GnPa9GHTgVKtWnWrGCLcoUaVWd aNParJpVqterb79yFSuVbty4bMc2bXuXL9y/Se8Grvv3bF+9ahMrhpnXsFDEhgdLFnx2aGWz dufO3ctZMGW6kUPbdZx58uLTqEeyhYpVsmWwpglrJnw5tmzWs72KBnw7d2yyvUmnHk7c42rc VvFi3tqV9+68YWEHBl57t+/ozX8/Do64uPfvFI/+I8c8O/Jm4dd1Z3cqnfp2191te0YPl/5n 8PjzMxSPuzP0/aU9R15CAqp3nl+HIWRdesA5F59+EEbIH2v+dSaXb/a9llttdTU2IIYPNsjb ZBo6GOGJKAIGm18stmfhdRzG+GKHm8FYWoILgrjhg56l6ONiSu0UlFhEdrVej0Ga9hqCI/6n 41dt5RgWlFKa9+OVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy26eabcMYp55x01mnnnXjm qeee+uXj55/5/AMooIIOGqhAfh6U6EIffECQowM1KlCjkv5T6aOQIkTpppFmahCnnT6KaUGX WuopqJN6aqqpm6qa6kH/lYJaaqSsUkqqq3ymtaiihyLaa6G+/lqosLBmauuryK56q0Klxopr s5BeeqyyoVYLbbKvXnurqtNKO6ul1FL7ba5o7WqQuege+mdB6zJqrLfVhovtp6dG+2y9yXbr qrPxKjurpNpiyi28qf4bLsHkJmYuu7+miyiwDy9cbKfvxvvtuP3yu+yy3la8scaj/utowLRK K66xrIoq8rwJ62RowzAPtGugi6pL7MQAj4wvyxgXjOrF+9q7as6a6kuvvESzDG6s+aKc8qRI C92yWhLLDDOhMvsqqNYMEZ1000cnpC3QYXuts9g7hzxwrRgLLbW4FEO9srxT41Q111yja/Xe /l2f/fXJYRfNcdBl+3224P1muzbIpFrsMbhxH24trnXXdDfEeM/MN+bM6hsw2WgPPrHjHVMe 9ainIywq2PluKzndlbt8M96c14zQ5dvGjTrdPR/89u6+v2v66Y5PDjzUo8Od++fDxw7T5Q4T lOjsuB8PrbOtsi1y9j5PW2vgSifuM71GW4+4rDhzL77z7Lfv/vvwxy///PTXb//9+Oevv0m7 7O///wAMoAAHSMACGvB//EggPwiSwIMskIEPLEgDB6LACP5jghK8YAUtSEEMahCCCKmgA0Wo wQ1akIQCMWEEVbhAFSrEgylEIQwPuBgPTlCBBuEgDiH4QBv2cIYt/jyhDn0IQgkKsYNFjKER i0jED+bwiE+E4QydSEPUNBGFKTTiEH/IxB1SkIpgbOAVOahEJJbxjGAMIxfNOMUmjjCJS9wf MPQDxBaWkIEZxGAQ0/jBIJ4wjXrcIxvJWEc+xhGNShzjG824yBhicYpVREshf7jCPPYwkYS0 4x2zKMUVCrKDbcykIeE4SROCcoNUhCQaA8nIL/GgcpMEZRbx2EdMPvGCssRlJ8+4y0YiUZWr FKUio+jFEEKxjMDM0iunFktZ6pCRYhQmD3U5REdicZSlXIgbf1nNUCLylq28IRm7tExmQnGL z+TlGpGpxU86sZffDKcnSVnNQS7Rm/GU/yccyVTOhF0xihlc5D+1qEZEbvOQqTwmIM/JUF+q spes5CcsizlOKRqTh3+8pSlbWdAXFvOU9WwnRr3IwoUS04cHDVM/I8nSLa20pTC90ktjSlPi vCAhM62pThNz0536FD89/alQbTrUoqYmqEZNqlKXytSmOvWpUI2qVKdK1apa9apYzapWt8rV rnr1q2ANq1jHStaymvWsaE2rWtfK1ra69a1wjatc50rXutr1rnjNq173yte++vWvgA1sV8EB DocQFkyH1RIAFrvYtBD2sQJ5bGIlW9jIStaykKVsZTGb2H9QlrOV/axnN3tY0YJ2tJBFbWdH W5DJfna1rCVIZ/5FO9vNSoS2uE3taTWrWtLaNranja1rs9RYxay2tsINrW1ha1mDDBe40AVu aX2b3ObKdrm/HYhuM5vd7cL2uaxF7kTEK93sWve62lUuZtOL3eZON73EBYBBGCvff9BXvowV yH0HQl/99te+9W1scRNyXOo+t8AHYe6B24te9xpYvdFFcIK5+97WUpjB5VVtb9mrXgyT97uF VTB1kztdCZf4t8w90YD9y+Liuhi/Aa4vf2Hc4hgDeCGvfbB1c6zb6FZ3w7iFL3IXbOELo1jD FZYtkj2s4x2HuMM9/vCIhXzZ8x54yQ0usXPNG6EV3/jGL64xiwGc3zCTWcYMkXB4q/4cYTaL 2LtFTrKcnwznBnN4uU4msWfzDF8rP7nPJ05ynzN8Xgtv+c7a5XNwe1zoFHk5zGYWsI0hbeMz P0TN7yWvoRu95kEbesg61rSPC93dP7v30IMGNaBN7Wk/p5rLIqZyojfdaDZzWsVo/rKkx7xr ME+60l8ONkIwbWrw0jrWPz60qh2s6FtDt9QZhvarZZ1nEKOa0G32sXgnq2xWM7vVjv6vuCst 6fz6t8zAHrCXr73oBxvZztPmcW29m9ptX1beR940b6X9anr/OMcTjjJ2uavtKZe229lO9pvW 7RCGGzDFa4K4mhzOEIoXUOJnwrhgN87xjnv84yCvXK4zMv9yjZQ85GrZ73xPPhE0m5sgKn85 fyteEHXLONcsR3lOzAyS/t48IfidOcxrXnOXD92++iW6zhdDaaS/+OnAni/Sk051qU/96liv utCzHuCsa33paKH0rlfcdIQEveon77rWR872Gdv863AHO05ifnMau13mQHfx1o9+daOf+799 3/vUyR4nWnD10XUXtsXN7nTBo33vbVd64Ieudq/L/SaIn7HicZ7zxv988o93fORBP/jQX14n mee1ufdLccC//PNut7rgX/9ozcf99GHqvER0bxHe416xHvH97n9P/OIb//jITz5gFy9s5ddJ 5RFhPvMFEoDqV/8f1rc+9rM/kOv+E8T7zi/O9BUifd+Dv/sBQD/107999refhnD4aerLXe6/ 173sCTn/+tW//fVfn/vhJ37jJma6Zne9Nnadl33uB37e14Dtl376F4CoQXeR9msE2GsMEYEM CIDYt3/9J4HfAXWqd4EGaHcZ6H78138MaBARCIITmHgj6GskKIMKoYELyH4OWBAt6IJpAX3B VoFndn8WWIMo6IEfqIIsWIQ8SBzjt4Tv04RO2CXuEIVUWIVWeIVYKFTCl4Un4YP2RxH3tYUL AYU4B3NQyIUY0XpRF31iWHHCN4Cmh4YjoYa2B4frRnard3YUGGMYKHVlGIdyGBKAZ4a2p3k8 V4iE6HP/Q4iBrcd1W9eGgVgR9PeDfCiCK2eG6FaHMKaIDyFzsAeJkdhybJd4Fchwb0eDBdh8 ZAh6sBeKwbeGqRiLzVeI+Id/YzaLRPeJjueKGzGId+dyrpd2wJiJv/iFZIaLfxd758aLPQiK 5OeMkseMTAiNRXeG5CeN2JiN2riN3NiN3viN4BiO4jiO5FiO5niO6JiOuIcN6tiO7viO8BiP 8jiP9FiP9niP+JiP+riP/NiP/viPABmQAjmQBFmQPoJKpoRKBqVQCTVPfURCCglSJYRDrKRH qTSRFzmRdeSQ1PRFGqlOGYmQIrRLIvlFG4VVhYRMlJRLjsSSJCVIKRVPEfWQ/5e0Q2tkk6Pk kje0SZ8UTdxUkyG1SXeEUrOUk1OVku9ESX4kRNEkTkk5k9hUURzZlHY0kiopRkbpkxi5lB1p S5iElfC0lRTJlJqUUFcVkRG1kyP5R2vplRS1lh8VkWaZSFuJke8klh51l1bZll5ZS3wpkVxJ lVX5khwlVUiJlipJS075kC3JUXL5kSBJl0PZmDs5lCsJQpVJkS1ZkfO0kmF5k+50mUZpmKLU l6VZlD8JlxyJUEk0k1gpmUlZlFqpRgj5S9x0m7A5m6ukURk1l1p1mDcJTqhpmnu0mMJ5SK5Z lrqkmJdkkqtZkXjElp3ZmdEZlMLUm7gUmVUFnLaJUP/XiZuCCZkSKU84aZLV+ZqzdJJmyZbM +ZLlmZ6qqZxfiZ7Z6ZsGeZ/4mZ/6uZ/82Z+4R425yIRn4oXRt3LW+BGnGBPCaBPDSIgOCmae BxE5p25guHgAqh/CdwDXKHlimFO9B4MKanYXyhE+J3Qll6Bn14ut2Im72KJfMopdx4ex54mP aHMyGnh6+HTKmHRBd6PBKITLeIw2mozHeHSVSKRF+nM/GqRFyqMHkaIB2qMRmqR4t4llqHar R3V+N3M5qqONl6Q+wnpcWnlQOnpkinX1xQMpaoB8B6Vc+qVv+nVriqNaSqdOanVnqqRxCqdl uqeUh6dVGqFSOqetOKdxSqj/dTp7uranbMp3IUh4bdp3nAh3P8qIAqGmdoqmk2qkWlpmJuqp PFqipSemd6p0ecqomVqmm4qJkbp2dTqoqfqnrup5JSqliqqLpIqMKsahpGeIeLqLAvYPr4So s1p0nMqnsaqnx+qmyoqJoIqszUqscXeHpfeIyyqosYqqJgqnTtqnspqpcjqiYceruuinoVeo SDes2RqHW1qq0vqu1QqvowetqBqtaAp5fuiIxdqtU4qs2op2hrqik4er5lqtKAKja+elimek Ckt7waqMefiHn/qwgxexPpqoWdqpjgqvTSqqFeujiAd1N3qrU5qx94quqleu1Qh5EQuwAnt4 L8qP/3i3JeLqnzZ7szjrJayQs/hTsyvhs3KVq5b2oIVqsSCajO3qrG7KeJRIi683puhGo48X tUJYeSJ6hlKbd/e3o7r6pL5YoNUItMC3sSxrrdZ6okmbtIpKc017i5+HpU8qe297rrIXty33 qRtKr4kqoSYnt3cisaw4teT6q16ntnLKttgar9v6sma6rQNrt5ALsTNrtjRnr5CIsF/qsE3K ikMKpvxKpVvrHeLWqgbLrBbruDA6uUFoeYOrh3sbdYN4ov16pkN7e0Fqr3XLe6caqmTosY3K rY0LrpZrtc0agtEYu/squKZKqY7avA36rHAbr7TXvNM6u0gqu1Gbi75bt/+sS7ocu4xZq7yr S6FhW4zkq7eaSozGS7aS6np+y3kei6+R271mG6OkirvR+KYBC4i2+62AOK+Ra7kuyr34m4iE a3kU+70ILLYpAbhzS7lne7yH67hrm7dX+q3RK7uQ63cPnL+MV8AaPMER7K4sGqkqy61066oC XKyGexqs96zAK3pGe69Ie6yzp7p7W6oxrKTuu8EzSnmjq7Wh64sUeMMty6Q4PL+ee7sJSsNH 3LEwfMRJzD4XysAN3HuSSIXiasUmQY2gyMU8G8ZiPMYLQQRkHFa6mytgjMVgO3xddrQvIYwH mrvn+8U2esdha6VW6rTl26uX2L9jOHfUq8QWHMj/AbpzcOwSIdy3KUy/QCe/thvCbwvHyqp7 5+vGDDrI3GvIjpx2qFeylgjFXqq+p7u5aBujteu3QLzHt0vDlKvBkry4KKynaYyleie9K1rK S4qjmivKDerLrZywrAy6q8ykMAGrGHzIeovKJAzAvMy//xu4PJy/JzyxdSzLzDqmDTeqh6rD tyev9eqnIDzCjoiyvbq0hkoTGQy9Ncy7D2u/7OzM+OvJh4ur8SvCLwusd4e6fWyKkNqjtUqr 1BzP4dzMSkt6BNupeiexk0yxjLrGYMvM6CutGKuvKFy4/0rP5UzOzOu9eduqDwy4F223tqq/ kgrJ4GzQOszQHo272Sy+/+jMdRC9zcm8wsus0iPN0uXqwBRs06TryhTs0fpqtQb7yC3W07xK zimNvusqzRmtykztzY6MEn+4vUM7bhkczBVroBd7vXQMjAN7ywY60Lccy+YavRC8wSPb0DKc wGENpGwNzA7qsEc6rQGbhwy7uV02E2ksPzOtyHkyxVfcEH9NJoXdEod9xoq92Iydn523tCLx hny7VIk92RdR2W38wVRdwkxbsBI6x8aKyXwsE3I8ooUthlXcg4F82pxN2Jc9wA13uX/ctYPt wWn4ybfN16/ayyUNvxW9y6kspFC7tUd6selcziY7sq87ygqbuKUs1y3buVhNvV06tVXay6b8 sf+SK9Fr7YnJnbmTiMTNTaKvGs7HXck4fd4mLM7g6nS0W88FTbjtWrz8esHwrdLc3d6Fu7v+ Gs1oK750atNbSqjES7Jp3bfITK8SLbgJrscIndDuXdDx+9LxbYLLCqJCW9GW1tAEDqrw7NaR x87pDdLqW6NRLKpd6tZKjdDWTImCfbcNHuDeTMvWy9LGOs+9zdQUPuK3GIQYvuO/XeHtDbc6 nbtOTcIr3uO57Lx3auMwzeJIDqFziNQ03tGl++SM29Q5TtEITOWQDNRGR98bPeIrnN9ivq4K PM6v7MrprOYTvd4qDNtZ/LqtzLjX/Nb7vKOKOMrtfM9ynOcbXntQK97/R1vVIo7VXW3LtHuH Jw7XgarQm3i80i3Wv5zKlZq+bx3pxlwTmF3biIuhO7e+Y9Lpm03T+PHiiC3qjb3qrN7qPGvH XeLQE8fGJOHFaCLbrx3Zpv6xA57ZIbp7qpvPu67rmmzUZoLrtB7H/vvTY9vlgMzJU57sV5Kl dU3txuypIGvhwo3LKzvpdU62f97dqDzMRMzcJTjpZd25qhzdM2vtV73Qmy7FB0jt2F3uzIzq mKfNyUrUAKu8BR7ks0rUZs7Tei3gi+rmdprfNa3f/fzUZ8vfv8u+mWvQBh+3lI4QJEACuN3f Dp7I8uUBR/7v2Iqyim7mRi7xS53mcK7w29vx/xMq5Cwszb47r+it4MN93BtejKkxzxat5GuO 1jKu3txc3lKdtnD+5ghf8ymf0xr9vb0O4eGK8opb5bOM0n48gU8t5r3u7/vawRyM5FwO1Gye rDAf80Qu5EJf5FH+9CtO8ytP8WWP5tNIvFLMtQ+e1XNt4svL6wpt16F8rtKtrfYezB++z/I1 DuC91n0Mxecs1u9Opoye6O4M9njsrJgeU6Qu2ne7EIhPj5nfiaAN253v6jkx+qR/+qif+qFu 7CQ31R/t2cTeEYcttpjdiHUj7Jff449c0r4u1a4Nhgga7Sxb74/u+r2/ydT8+20i7FaN2sbf 2cte68Ff6lb+3lef6/+vj/yzzu20Osy+D9lCOu7aHdyP3+Twnt1fW/eivLK1O/iJv/gZi7xM XrTkHrJD7N6+XfDhzcqje+kQcvYA8e8fgIEEBwo8KNCgwoQIEwKAuJDhw4MELTa8OFFjxooN GULU6JCjRIkiO350mBLlSo8mQWI0GbLjQpIROX6MmJImwpExT1Y0WBKmUJI8f/ZEalTlUqZN nT6FGnXmUZgbdb60GjIoyotJtRrdmdEmRqJVFdYEaXEsVpE5wyrl6TZuTrhB5e6EK7NnXbBj +b6VOVQl1reAp7IUKlXxYsZOu1LFaxbsV8pbH3v1aPjy5LYu854VnJitZsmkl5Leq1dn6b/+ TFF/Fnw66WvTjW3fvo23duTJJXlvnfoYsc/ZsX1SHRw6b9Hhvzmzbg6deFbqqY1bt5o4Ou3n wHF/B++67suapenatOt74ub01M+SJ/9Q7vvVvwnPP8/2/V6/c2/S9S/A9Ji7iiYA46rqwILu 866gAgM7r7f84tMtwvAuxDDD1TTksEMPP3QMRA+1EzG546IisUQVR1yxRRdfPA1G8FJsUT0U 9ZMxRx135LFHH38EMkghhySySCOPRDJJJZdkskknobrlSSmnpLJKK5eK8sqnaNSyy8a4FBFH qMDEkMzcnMryQjPDXGux/qikcU0ibVRzSzdhA1HOwKZD8zveevz+M0Qv47RST8UIPRTPDw21 c8+U0vxS0RwNZHDDBxd0cEFK93MP06EABDUt+NCi79IJM3VrU03nKrUttSg8tdJVPT3w1J8w 7S/U9kyVb9SVap2V1VyxijJVVmdNVUwYI7OurF+H8wzarMTqLjM8mT0OMMvWu85ayrKLbdvo 9sRWv3Kfk04tcHEiN91qBboFOMxSYzTDct909iRxe+WvJfT4wmm+jfJ1rjWK5NUUs4Q7A1fb gNPqjmB0q1uYwdHeBUpgHJv9C19uX+tUxnNjtJRayN69qSWK6fSXwILXFXffdR0FrTDOZDYO NIBvXVk2lWc2TK+iXg46pn3nlbRGg/3+LZmik6WVWN9qCVxuZ2+lxhppl2O0+dmneb66aLM4 JnrsnL8qW1qntbZ6UoAV5JTWj3WlVzbvXlWV1lcH29XVUhFGWO71fPU7NAvljW9wT5dL/KoE CV/8WLR2zVttByu0EfG7a07ay85JZqxezxsdvXTTWQzdNtFPN5F111+HPXbZZ6e9dttvxz13 3XfnvXfffwdedmVVD754403XDm6aDdX1WJ2Phz56e0EXrSk9QXZaeu23PxRypnElfFicp56Y e/PPX/qz/5ZGKnmgg0U/fu3FVm/r5tqknnyac3xEfv+FpF99+PS1drFPMj7q3/8UCKjyJWiA bLPU+3SzQAr+8s5CfCMVqkalKqL4pXmtWl0FRThCEpbQhCdEYQpVuEIWttCFL4RhDGU4QxrW 0IY3xGEOdbhDHvbQhzrkwQ+FOEQiFtGIR0RiEpW4RCY20YlPhGIUpThFKlbRilfEYha1uEUu dtGLXwRjGMU4RjKW0YxnRGMa1bhGNrZxioyAYxzl6EY61tGOd8RjHvW4Rz728UL84Icf7QjI QAoEkLY5ZEoImcjwMBIhiyxkkRz5j0RCMpCWVOQiBVkiQj4ykouZJCU/+cdRitKQpQRSJ095 SVSaMpObXNEhK6nJVRZylqJ05CRpKctaelKWqjxlMHs5zF3akpWUJCYwadlLTYb/UpgOCWUx kQlJWErll8K8pilvGc1mGhOXx9TmJ7mJTW/mspznzCY5XanIb4aTKeOEJjrB6cxqvvKW7sRn Oj0Zz2AyEpPSzKQyqQnQbKbTnN3UpTpnGUl47hOfrqRnPWvZyW2es5+lNOdFHRpPfWr0mb6c Z0jXmdGAilMlBmUoRkdZUYdGVKL+FClLH7pRiIJznfZUqTqXUtCYppSfOzUpTjfaUIX6dKYS feYvBQpTVQLzpu286UCX+tOaUnSpKbUqR41p1YS+8pswBWpTxQpSbyIVjS41axnRmla2ttWt b4VrXOU61yax7EQzIl2SuBRC2P0LNx0c3ovuI6A3xc1P/h2qX+tAJxVEKcmuPwseX1UWKJEZ qIARLNJj9yenxup1TPPD4K8qBayBcbBxwrFV5NgjHsz+LWMk6lur4haWCLWnWRDrmwctZipf bVByF3TfwQ4nqo0lzjIf7NK/aDuzySolaKhpkNiCA9l8dSxkLGGtBHtjLaKVBXtUcxhy9Efd j23XauFV2KCaRilRwUZ87dWuVtbirJgRRrHvc5S6MLg17jAnZfaB2MM4ZrCjcWqCsJ0uVwao HOEApXR0wg7nNkTZAH+NaghyLnYDJTFsUc9+8U1weR84XvfwV8QWxq4AG9xgd612YJ6DsNnK N0G0jffDV+PWdWPcYZbd+LuH/glZh1H8snCNS7wXdqCCz5vhHOP4SoCVb27B+zdZrSqDqVWN YZNnK/aqL3KGDdZ8KUQfCv9nQlI2V/jmtlshN7fJYqmwb+z75i/fUbKtxatjI3VXui4KddPT c+o+12dCF9rQh0Z0otd45/syFoB+5hGjJMtoP10Pens9057/vFgvCyq7aypsdj0t6AB9drP1 MhOoB407SvPZ1Jt2tKtjDVlOv3rUd1p12xynIlXvD3mnJfPjVizb2QJbcGcms2m9h9pkUe5i hW2288jlW1z1SmgDKjWEgB3tCSdbcvrynt5kxu06a+nANdZwtwzInXEVmH7uxli0whZvDkcs Oe6r/41rjfynwLl7fN9a7ogpW6hcVS3gB9sPfz3Ir2Gjt2IztjFZ7l217HisQHE2T4UNHG95 Iy3L/X54ii1+NrP5Fcb5w1iATda6lGEt4oBbL8u7JeeOC1zUWT4yun7MtYhHGT8i1znFST6y 052buwbfmYkppuSnwTvFM4c4vQ14op3nrOoC3LfQswb1JTO3Z76eEnCDbWVjExtZF/u2uEEu OPnwCX9tVxB2MF5u3W7ucq76r8bALL5Szx3dmpsWtaM8bWEjsdW2VnQLD++awCbe8Y+HfOQl P3nKC5Z4kUay9Q6bJ14Lb/FlonWVmMf5vPp64AMPfXgwvfm6ahqxdmt8iP6Te3lY17qxwS09 hz6fayBZekTVS93ul8Vl5xqX2saicrixzHfwpbkr8GV+3rG9d+iHeczHdj6Yib1wZ8vq+XJX vrFr22jqVp/Z0y9ctdH8ZwgC2StOB1sAsw7wtc0cwfmGOXQnDnzxRjDgPy47pZsO/SM/aCuv zbAcnduc3aOt8Xs4kDkuvau3mIOaATwxvGk5K5M6hGtAjWuTjeG4kaubDiQbCnQ7hiOvUcs/ 9zugtyML5GO/5mqQITsxrxu6nps3mAM6ExywbSkaokO7/isbIPyeo7PApnG5/MqrFWw4oVsf wnu9CmwY/YG/lpM/FKM/HSQgEPMvpvO4WxFAH/9LOa4rwvRZOpKrDIrzQRYcwhFjMntZvsLp vrUTu0xJO7xzHr/jHMD5INHQO/hZwcGJrrsoLrvLNmSRwz5kmJ+5oPTLjMZJv8qpPwSsw77z QMgRvjpBo1TLNDDKxCLiRNqrvFEkxVI0xVNExVRUxVVkxVZ0xVeExViUxVmkxVq0xVvExVzU xV3kxV70xV8ExmAUxmEkxmI0xmNExmRUxmVkxmZ0xmeExmiUxmmkxi5SgGu8xn/ARmzUxm1E iGx0CHAUCHAkRwXoxmwUx25cim00x3H0RnfkRnZsR3f8RnMUx3L0RnZMCXmsx3nMR3+Ex3Q8 R3TUR3jsx3vUx3/8xoD/TEeBxMdyXMiC7Md6pEeBVCGLREh6PMeJpEh19EiI7Mh9bEeCpEiL 9Mhw9Ed7TMmTDEmUZApu7EiYVMmXnEeXRMmVZMmGHElyZEmRTMmZrEieBEmD1EiSDA8f2B6M xMmHHEibBMmh7MmiBEp1NEmlLMmVtEqVqMqpZMqpFMl1rEmjhEqdDEhtjMqDbMqMzMeThEiE hMrvQErpkciM/Mi0rEmq5MqdtMmvxMurhEmNvEmFDEqtfEfAdEm6VEmC/EuG3Mu+/MiwhMxx tMumSMyZVMvJlEq2lMm7hMu4PJ6sHEiAfEyfnEu9bMmDNM3H/EvQNErHjEfOVM3BLEqilEjG /zRMsSzM2xxJg8THcMzMy9xIxPRKumwh1uRKwvRJohzN0zRMzeTLqFRLrJROsPTLd+TJ5jRJ 52RIknTIyDRL2cxJ5AROx8TL0mTOFDLO2XzOmPROskTOvexO5ozOq6TP9yTPp/TNxoRPnHRN 71RPySTO7zxMrPTNp+TP7GSh9KxI+2RPtEzI3FTKzVxMBS3Nf1zM0MzLtCzQ3AzN/axP7dTQ hcTQ/HRK69zQ1TxQ/qzGFWXRFnXRF4XRGL1FBJVR06nNgrzH8pzQu1TMnZRQnRRMHbVN1ARR FBXRB73QjRzS2ixLfkRNH41P1RzKHuVMJkXRC71S0DwhA/VLAFVR5f/cTOyEzZAUzuY8TeK8 Ui9dz+TMzOVszOxE0/bM0PnsybEsU450UzO9EFPwHToV0ioF1B5t0/Mk06VMzTUt066s0zHF zQ+NUj0tUh4NU/Bs1BKtz0Q1zUfd0ulcUA6FTsx8SCiFTbe0TlFFVCcVS8wk0gEFzNbUVDhN UdJs1Tk9VDet1NHkUv0sIT9FR+WUzzYlVVN9zjvt0DM11LoMTkmlSVvN0Ddl1FgdVk7V0UAl yynVy1BlUBPiVXuUzyp9Ty2FTmjV0kel0l4FTz2VR1o1Vl2d1W4tVOdsTUflx+h80HC9yEwl UBHVVUA1U01t10FtSXKd0w1d03bN1XF91nf/jVZ5zdPlpFNrbdgEhVAT1ddf/UoLxVb7pNfK pFZ1XdAjxVj/pNJVDUxCBdKtDMyfhNh33dhYDVAardGYldmZpdmatdmbxdlZzFUlHdEOfdmQ 5dh1fdJixdMK7c5JFdBFtc0ctVJiXVKgXdpSfc0k1c23/KGdxdIv/VmNxdef5NqqbdCzpFfJ LFpXTUw1zUmn9VMPlc14tVojZdceOtjh1FoVpVAobcqFhdfUjFeWjceSDVJBbVazFVixddlr lVPqFNMj4k5pBdHthEy4dVhVVdiHlc4dLcm89dLGzdzARVy09FCUNVipvdX9RFoiSlfHDdDH Nc7VBNhZxVyIFV2qsvRVfIVX3jxW9wzdUT3cc2XSyvXKIZJQyFXY4rVXSs3WvX1Sj11YuxXP fL1Pjl1d5f3atqXbs9TOvhVevoVWpdXN6r3OfT1W6rXa261Yfh1Ps8TaL6Veve3PtEXX8U2i lWVdzxVflk3eON3bLJVUmSTRpJVK/43IwtRfwuTfgCVdU11dAj7dnHXgB4bgCJbgCabgCrbg C8bgDNbgDe4iT+DgDwbhEBbhESbhEjbhEz6igAAAOw== ------=_NextPart_000_0010_01C6EF99.C2F5C800-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 14 11:33:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYlW8-0006qG-KT for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 11:33:40 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYlW4-0003Ci-Uy for capwap-archive@lists.ietf.org; Sat, 14 Oct 2006 11:33:40 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 6E01A43103E for ; Sat, 14 Oct 2006 08:33:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 4031D4A4612 for ; Sat, 14 Oct 2006 08:33:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C70439801B for ; Sat, 14 Oct 2006 08:33:01 -0700 (PDT) Received: from web60314.mail.yahoo.com (web60314.mail.yahoo.com [209.73.178.137]) by zoidberg.tigertech.net (Postfix) with SMTP id A19B4398016 for ; Sat, 14 Oct 2006 08:32:57 -0700 (PDT) Received: (qmail 53881 invoked by uid 60001); 14 Oct 2006 15:32:56 -0000 Message-ID: <20061014153256.53879.qmail@web60314.mail.yahoo.com> Received: from [67.166.240.5] by web60314.mail.yahoo.com via HTTP; Sat, 14 Oct 2006 08:32:56 PDT Date: Sat, 14 Oct 2006 08:32:56 -0700 (PDT) From: Behcet Sarikaya To: capwap@frascone.com MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.27 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_60_70, HTML_MESSAGE X-Spam-Level: ** Subject: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800306830==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f --===============1800306830== Content-Type: multipart/alternative; boundary="0-622651759-1160839976=:52213" --0-622651759-1160839976=:52213 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Dear all,=0A I submitted a draft on CAPWAP Roaming Protocol in 802.11R Dom= ains.=0AIt should be available soon at the following link:=0A=0Ahttp://www.= ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt=0A=0ARegards,= =0A=0ABehcet=0A=0A --0-622651759-1160839976=:52213 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Dear all,
  I submitted a draft on CAPWAP Roami= ng Protocol in 802.11R Domains.
It should be available soon at the follo= wing link:

http://www.ietf.org/int= ernet-drafts/draft-sarikaya-capwap-fastbss-00.txt

Regards= ,

Behcet
--0-622651759-1160839976=:52213-- --===============1800306830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1800306830==-- From aquggzegr@stroter.com Sat Oct 14 16:19:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYpz5-00068G-IO for capwap-archive@ietf.org; Sat, 14 Oct 2006 16:19:51 -0400 Received: from 213.red-83-58-35.dynamicip.rima-tde.net ([83.58.35.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYpyv-0007CO-Ss for capwap-archive@ietf.org; Sat, 14 Oct 2006 16:19:51 -0400 Message-ID: <000b01c6efce$14c8e750$d5233a53@VALENZUELA> From: "following" To: capwap-archive@ietf.org Subject: have Date: Sat, 14 Oct 2006 22:19:41 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6EFDE.D84F6D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 ------=_NextPart_000_0007_01C6EFDE.D84F6D60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6EFDE.D84F6D60" ------=_NextPart_001_0008_01C6EFDE.D84F6D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Of page and a Union Although directed many rules policies a programmes = have an. Unit in which following main is areas with other issues national = bilateral meetings access official of Eyes Navigation Whats up is = Actions sport. Unit which following main areas with other issues national bilateral = meetings or access official Eyes Navigation Whats up in Actions. Within or Education Culture Unit which following main areas with other = issues. Through reportnice am against in Treaty of External home of Links is = Useful structures Mscontact Last. Main areas with a other issues a national bilateral meetings access = official. Official Eyes Navigation Whats of up Actions sport Year through = reportnice against in is Treaty is External home Links Useful. ------=_NextPart_001_0008_01C6EFDE.D84F6D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Of page and a Union Although directed = many rules=20 policies a programmes have an.
Unit in which following main is areas = with=20 other issues national bilateral meetings access official of Eyes = Navigation=20 Whats up is Actions sport.
Unit which following main areas with other = issues=20 national bilateral meetings or access official Eyes Navigation Whats up = in=20 Actions.
Within or Education Culture Unit which following main areas = with=20 other issues.
Through reportnice am against in Treaty of External = home of=20 Links is Useful structures Mscontact Last.
Main areas with a other = issues a=20 national bilateral meetings access official.
Official Eyes Navigation = Whats=20 of up Actions sport Year through reportnice against in is Treaty is = External=20 home Links Useful.
3D""
------=_NextPart_001_0008_01C6EFDE.D84F6D60-- ------=_NextPart_000_0007_01C6EFDE.D84F6D60 Content-Type: image/gif; name="main.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6efce$14c69d60$d5233a53@VALENZUELA> R0lGODlh9AHsAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAbAFkALAAAAAD0AewB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+X9oIKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9ehP8OK HUu2rNmzaNOqXcu27cavcOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sFK3iBMrXsz4ouHHkCNLnky5 suXLX8Fg3sy5s+fPoEOLHk26tOnTqFOrXs26tevC8l7L9ty4tu3buHPr3s27t2+Qs4MLH86XGXGw v5MrX868ufPn0KM7PE69uvXrWKVr384dMfbv4MOL/+9Ovrx5n+LTq1//+rz79/Djy59Pv779+/jX pnnIvr///wAGKOCABCaV34EIJqjgggyaV+CDEEYo4YQUVjhYgxhmCBEwGnbo4YctWSiiaCSMWBiI KKbYmIkstujiizDGKOOMNNZo44045qjjjjyipuKPQAYp5JAo9mjkkUgmqSSFRDbp5JNQRhndklRW aeWVWGapZY8AdOlll1uGKaZRX3455plopqnmmmy26eab6q0D55x01mmnUFLmqeeefPZJ1p2ABiro oIQWaqhQK0zm56KMUnToozA2KumklFZq6aWYZqrpppJC6imLnIYq5aemgUnqqRN6iapdoibnZasz rf+qmqqydgVrcwDcGmKtvPbq61CG/NqUrsSqKOyxyCar7LLMtscbLMVGK+201FZrLX3NZqvtttx2 6y1d14aL37fklmvujuKmq+667KJ07ruYtSvvvPTWyx+8+FaJS7789uvvvwBvZu/ABBfMbsAIJ6yw swY3rNvCEIPr8MS3RWwxXBRnrPHGHHfssWMXh7zVx++9kanIxL2B8spWqdwmyfCZDPPMYclMKcsp 46wzVC7v7DOgNAfd089EIyX00UgnrfTSfhbt9NNQRy311FRXjTPTWGetdcVW77z112CHfVbXZCd7 SdlWia322mzbhDbLbcdd0dsry213RHTnrffefA//evffgAduUd8RC2744YgnrvjiiBPu+OOQRy75 5JRXbvnlmL/LeOCZd+55YHTUFQlnmwP++bmlp6766qy37vrrsC96urmx1247wbPnrju6t2+9++/A y9j78MQXb7yQwW97/PLMi5p8oR1k1/zRz2c7/fXYZ6/99tyHVP334BfY/fjk/xj++einrz5R5XO8 /q/tb/y+r/HXb3+C8/d6/8T59+///wAMIJb25zABkoqADTOgAhdIGQTWCw0EYaAEJ3ghB1rwghjM oAY3yMEOxo+CIAyhCPnlwRKa8IQoTKGTRhgoFbrwhUNj4Z1gSMMa0kSGOMyh9GxILB368IdADKIQ /9PGwyIa8YgwG6ISh8gpSyDxibpaopqg6DwpoomKWMziRKx4xcXYQou54aIYWQjGMprxIGMU0xnX eMY0homNcNSiG+fIwDjaEYp0zNIdcdIO6eRxgHsM5MQgKEjb/RFlEjikIhfJyEa+qZCQdKEjj2IN HEXykpjMpCY3ycmwVEgMRFPBJEdJylKakpSdbNIpeZdK5K0yR62MZf1eCUtZAomWlrSl+XDJy8np 8pfb62WNgJkiYdKImN1rATKXqSBj9msXztQLM20ZjulF85rYzKY2lzTNbnrzm+C82WncsU2/hPOc qyunidDZTHWKiJ34c6c85xlNeCKInkwKXBMUh//PfvrTlPYMqEAHStCCiu2fEDKoQhfaymPpAqEQ jahEJ0rRilr0okgaxhsZqhFCcvSjIA2pSKGE0ZKalIIjTSnNTqoelbr0YywNjTJiStPCvVQ7Nc2p TsN3U5zu1Do9DSr/flodoUKHqEU1qnOQytSmYk6pUK2XU4cTVeacKgZYzWoMpnoarW4VgFUNq1jH qlCuAgwVZk2rxMjKVmmp9a1waitv4Noaudr1roakq17TxCgd4PWvgA1sD/eaGsGuiLCITWzIXGeN tSnWNIZlzGMnS6XILoayo7GsYjDL2c7STrPe8SxtQOsW0Y42oFqwj2k7Q9rSrva1ZQMAbC0j29lz Vqa22TxQrlq7lt2ic0S4zS1+fPtbCwVXuLxVi06jB9TkOndIto2udCH13LRMV1HVHdt1t8vd7iYs u9oFXiWsB97ymrdg3jXMeceS3vb2Z73wXZB7uRiGb8X3J/PNb3juy9/++tdu+gXMfwcMnwAbuDoB AQAh+QQAGwBZACwAAAAA9AHsAQcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyBDihxJsqTJkyhTqlzJUuG/lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1Cj Sp1KtarVq1iz3mzJtavXr2DDih1LtqDWs2jTql3Ltq3bt3Djyp1Lt67du1LL6t3Lt6/fv4ADCx5M uLDhw4gTK17MuLHjvngjS55MubLlqY8za97MubPnz6BDix7t8rLp06hTq45MurXr17BjJ9wju7bt 27hzxxagu7fv31+nAMcYbrjx48iTK6e4urnz59CjK11Ovbp1rtKza9/OHfr17+DDe//sTr68+fPo 06tfz769+/fw45sXT7++fYfy8+vfz7+///8ABijgWtsMaKBW9yWoYIIHNujgg08tKOGE10Fo4YUY /kQhQVRs6GFvGYYoIlW4kPfhiSgqhAsuKbboImksvijjjJrF2NmIOOYI1Yo69ugjgCV6R+OQvSFh pJEa2UjkkkyOdOSTR0a0YpNUVlnSk1ZmqeWWuJ3jJZdghjmSl+eIaWZhP6ap5ppstukmXGfGKSdJ QMypVzB26vbmnnz26WdUxPwp6KCEFppUnogmapahjDYK1CvTKSrppJRWaumlmGaq6aacdurpp6CG KuqoYDpq6qlWkarqqqy26uqrm6L/KuustNZq66245qrrrrz26uuvwAYr7LDEFmvsscgylUqyzDZ7 bCPORivttEHBau212Gar7bYSUustjtyGK+645EYEQLnojnZuuuzqlRQA38aLIbzy1lteu/hyJpQz 9vabXr4AP+bvwAEGbPBiBCfc38EMN+zwwxBfq/CDJEQb8cUYZ5zcxBx37LHCGocs8sixfWzyySg7 S/LKKaXs8nYsxyzzzDTXjNvLOEdn884Z5ewzfBj8LPTQRBdttMU8J83c0Uw37bSDSkcd0dNUuyX1 1VhnbVHVXKul9ddgh21Q12QjKPbZaKet9sxlt53q2lK7LXdecEc9991O1W033nzv/+SATnor3Xe0 PAzebwGGJ+5r4Iw33rDikPvk+OSUV275hLG0FPnmgF+OW3Geh+4a56TbJPrpqIta+uqst+7667DH Lrviqddu++24izf77rz37jvOuQcvfJy/F2/88cgnr/zyzB84/PPQRy/99NRXb/312Gev/fbcd+/9 9+Ar6EfgqaQS/rblm39+tumrj3Dzp6aPNybHLwv//Uitr//+o+Hv///I4p8AB6gZAFKNgAhMIGIM yMAG8kqBq3KgBCdIwQrOB4IYzOBeLDg0DQ4kH57ioAhHSMISmpB5YWMA2E7IwhYyrwQujIsHQxVD k80QVDXMoQ75c0MuRUMjO+QYSv/K1MMiejCISEyieozIKSUSjImxcqK/oEjFKlpRW1LMohafc8Uu erEhWwyjGC/zxTKa8YyUGuO30MjGLqrRW22MIxXfSC052jEx4/saHad1xz768Y8U2qMgB+k1QHKJ kIhMZFUMeUhFHouRk5ICJFHkyEp6zA2WtOQkN8nJTnryk6AkSSZHScpSmvKUkQrljLKBysWp8pXQ a2WvYDkjWdrylLTMZe5uqStduoiXwAymMAflyxYNs1bFTNExl8nMZo4omZR0pjSlCM0TTdNR1cwm 5a7JzSBq85vgDKdEumkocZrznOgUCDnX6cJ0uhNr7CTmO3VHrBNUcp745Fk890n/wnyCh59+8qdA ZQbQPg30oCQrKJ8QylCNKXRPDVXOQ9/0vQdE9KIYzag1J9omjQ6HoyDFn0eBE9I1jfQ3JU2pSlfK Ulud1Dct1dFLQRRTcM00NzW16U1vk9Nn7pSnPQ3RT4EaVAwN1TZFzdBRl8rUpjr1qX9JqlGhStUm SvWqiatq/7DK1a6uU6ui8apYx0rWsj2DbGANTVnXylahieFBaY2rXOd6xrbatWh0zate98pXj951 YX1tzF95GFjGDHY/hTXsYfOT2Pct9rGQVWJjFRPZylpWmA+4rNUmy1kZafaz9eJkCDr7ONCato6k RRNHK2HS1BLmtLCNrUhdOxjZgt6LtoKxrYlwy1sF6fa3bBUFcIdL3Aj19rj1Ka50kOsX5Tr3VsyN 7neey0Xpuou62D2Vda+b3dRsd1ImGGh3VfNdsoz3vOhNbwnLy972uhdd6o2vfFP23q/MlzL19cp9 98vfgeX3vwAOMA77S2ChCvjACGZQgeuS4AY7eLoLjvCDAgIAIfkEACAAWQAsAAAAAPQBIQAHCP8A /wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48E7YkcSbKkyZMoU6pcybKly5cwY8qc SbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1Zcgs2rdyrWr169gw4odS7as 2bNo06pdy7at24VX48qdS7eu3btA3+rdy7ev37+AQeIdTLiw4cOIEytezLix48eQI0ueTLmy1MCY M2vezLmzV8ugQ4se7diz6dOoU6vOTLq169ewL6+eTbu27dscY+vezbu379/AgwsfTry48ePIkytf fhcuc6e4o0uffvA5dOrYs9e23lS79+9+Vwr/GG+PPEkB5UuiH8/efPv179mPlD+/vXr76vOf3y8y Pv3y9KGnn0n/pXeff+txp2BwcAlo3nwGQijggP3xV9+FEUY4YYUWprfhhAlSCOB+G3J4HogOEtih geC16OJaLKX4oYkpqphSiTiaqGGMEkLYo4gl6ihkhgYGOeOKCyZJnIz8gTgkkRQG6aGFUg4YYoZX +vgklDmqaOSKVSopZmgNcujkjgC+19+DHUqZ5YdsWolmhV9qeaCaSE4ZpX4v9ulnW0X66OSZN3b5 JHwFnnhSjYHSuOeiNtr5Y5t8/mnppYKJ5+iOhKp05KFzQurlpGnG+amIRLrJJZhjttpamVhyVyop SqemqmOYqg5KJZCiItllnVtiKuywWzWK4a29IqvomkIyeiiOnca6LJ2RHvtgrV0Sq+22GskHbZvx rZmom2zWiWey0tpJrnvVnmhkorbaw+289BoUEAAh+QQAIABZACwAACAA9AEhAAcI/wD/CRxI8J+A g/YE2Fu4ECFDhQ8PSoQ4EeJDhhglZsTYsOFEjhtDdhSZEGRCjSU5WlTpMCNKkikLypxJs6bNmzhz 6tzJs6fPn0CDCh1KtKhRk0iTKl3KtKnTp1CjSk1qtKrVq1izat3KtavXqWDDih1LtixHr2jTql3L tq3bombjyp1Ld+rbu3jz6t3LF2ddhjX/Ch5M2Gzfw4gTK9Y6OHDhx5AjU11MubLlyzIb05TMufNj zKBDi/7qubTp06hTq17NujXZm/liy55NmzbG2BxxO174gWNvjL0/CLf3G7hS4cgZFgeZXLnv58aj 8x7u/Dly6syXEw8+HDvv7dehj/8eT7581nxJ0TNUv5A97tvodxM3vvy3febHo2ufrvy+8/r4fcff gPsFJx1w2lFnX4LzIVideRBGKCFBS7EHkoUYrmePexs+VZyBAjZYYH7V7ddgdSeCeKJ0H0I3IoD4 teifivONGKJrOOao445hWZjbbUC216GQPpJYI4r+HRiggDa6+B+K1kH5ZJRSficjkyvSWCKPXHbp 5Wqw2abhmEKWiZ568W3GYopbQofUdS26qd+UK9JX5ZFU3rjljFhaaZJ/EwYqqGgVpgefbEGeWWZT STaqZ51yJnknn33+qaSf1oVnKZ6Uigipp1+GKuqopRVJ5pCoosqhh2zC2OSmdE7/SqeWkVr64p1s 9hknraCS6uuvwEIFm6GnrqqqPfJhimeluOrJK4OzfioltLfKGmKnR7660KDcdqtYoUhlmKhJpibl 3XZzyrlkrw4O6O6766LrrqvqfootugnGGey+/PY7bLhBAmlqmjPBemNycHKnaX/NgdcweAZLO+m5 DlcJbaZadgeneN527PFimhXc78hMfWzyyXqFnBnJLCOF8sswW9XyzDTXbPPNOOes88489+zzz0AH LXSONw09csxIJ52Y0Uw37fTTTxW9ED9UY1S11RxdzZDW9lDNj9VfY+211yaFPXXWSJEN0thdj832 1Fy7vbXbX8u9lNlzmx220nz3/30XU1pfzXXXWePdNtxzIy524Ytv7fjaekeO9eOJK4532IafTTnk l2eeOdSgh+5U0YZjTvjmhOt9eulnX3765K3D/jnrmqeN9uSuvw677mXv/rjfwAdPWlKzp+573Y4j v7bxyfcee+O3o/357sXnXjzqy9cevejcd++yTdXXTrvyyksvPu/ns369+UrlLv3bbcvtvu1wq625 8Pjnn1b4mo+/OvrM+9/1VOc77AWQftpr3uNmBz/ibY6A+ougBH1yt94RkHavKx/0TDfABgIQgBp0 XgKfp8DoTU92tzuh91YIOtKlEHrn698Lm+c5ymEwezZs3/b+B8MHVjCBhpugEAWHWJOAAAAh+QQA IABZACwAAEAA9AEhAAcI/wD/CRxI8J89fvYSJkR4UGFDhgohSlzosKFFigghRtxI0aHGih8nVvQI suRFjCNPfhwpkqPCgjBjypxJs6bNmzhz6tzJs6fPn0CDCh2686BEhiFDpkR6tGPEjCCRmnTKsulC jVijPqUqleXUpSSdMiRKtqzZs2jTql3LVmfKpfyyelTq9ancrXHz3uX61i7cuF/92gV8VS/UwIUJ G93bt7Hjx5AjS55MubLly5gza97MubPDmp5Dix5NWnPb06hTq17NurXb0rBjy4bturbt27hz6x44 u7fv35V3Cx9OvLjx48iTK1/OvLnz59CjS59Ovbpq4Niza9/Ovbv37+DDV7S0Tr68+fPo06tfz769 +/fw4wN9Jb++/bLi8+vfz7+///8AjnefTPsMaOCBCCY41DMKNujggz0FKGF+SeinxIQYZqhhcBB2 6OGHIIYo4ogkNrfhiSimqOKKLFJW4oswxijjjDTWaOONOOao44489ugjaC0GKeSQRBbZ3Y9IJqnk kkw26eSTUEYp5ZRUVlmQkVhmqeWWXHbp5ZdghjmklWSWaeaZaKbJ23cyvRRTdi8CoGaOAQEAIfkE ACAAWQAsAABgAPQBIQAHCP8A/wkcSPCfvYMIEypcyLChw4QFByKMKPChxYsOKWrcyLGjx48gQ3YE ILKkyZMoU6pcybKly5cpMcqcyVDjRIo0c2aEybNnSpI+gwodSrSo0aMSdSq1aPNg06VLkUrtCXSq 1atYs2qNiBGAVwBQwyoFR5YswrJn0R4sa9YeW7dvxcqdS7dr3bt48+rdy7cv3Y72wPplitMpRXAL Ea9dzFjxWYaOb26dPJKy5cuYM4e0KFjh14OfvYL+PFrwV9MIUS+N7FYhYseKWbNmPLi27c62c+ve zbv3YNygUwcOPrwzcLDGhxMHTpPta9etG6uFG3m27+s6mWPfzr2797kjFyb/V41ceODQ5ssrfKpR NvS40SE/Xq/5ctX6+PPrv8pZvHDyyhX3X3oBhuVeQs/FZx1tC37n4GAIPCjhhBTqddyAyqknYHDJ EeehTrPBxiBtic1X4YkopjhYNSp+B9h5osG4HIekwahhh8SxdxhkbcXXmnPUVbfQfkQWaeSRSMa0 lHb91VSYPU/lluSUVFZpJVZ7MfmQli126eWXYIYp5phklmnmmWimqeaabLbp5ptwxinnnHTWadiV eOap5558Hmnnn4AGKqh3fRZaJQOGJqroVIM26uijkIK36KSUVmpppZFmqummnF7q6aeghmoSEoxy auqpqKaq6qqstnqdqA6IMyrrrLQe5eqtuOZKaK289urrr8AGK+ywxBKk67HIJttXscw26+yeykYr 7bTUVmvttUsFBAAh+QQAIABZACwAAIAA9AEhAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjwT/iRxJsqTJkyhTqlzJsqXLlzBjypxJs6ZNllxu6tzJs6fPn0BtghxKtKjRo0iT Kl3KtKnTp1CjSp1KFaOyqlizKg3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3DjetVKt67du3jz6t2q cq/fvwflCh5MuHBLwIgTK17MuDHGlY4ngms4OTLDyvYMa97M+e1CcKAxhwYtcPTA0KcJTjatGvXo yqxLi55NmrTsgpjtoS6dWrJt3bFjy3ZtOvhs3LtF87bMvPnilcp14zYYPffq3tJVTz/423Zu4Ke/ R//PPh5ieesJvy/PTv64dt6we3eeT7/+18+9xW9Pjb469f3TXXddgNKhtx58te0GXHwGYldeftw5 CF+B+wkIoHMYZphYdQomRyB/ECLX3W8TWkjggOvpNx6Kq+n3HnvqtdehhBSimCJ4F2qo4452BZce exPyN2OO2JEXpGvLNaiihK8BeSCMRf4n5YL+OckaiU/yqOWWUsWXJYja9XcjkQd6aeOAXo4JJpQu vqhmjFGOWWWbQcbJ5Z0SjYGnZCFGCCWQLEYJJ6DbKUenkm+y6Sehcab5YpUhutjgnpRWWhF0YRan 4IKtefcocaDSCSOSbgJKYm35ecodluJ56KSaFL7/5+ifldln6624AkXpoJZml+uvwAY7Uq8/Ekum scgmC5lGKEUm7LPQRitsstRWa+21dQHgkbYfcYvtt+BqCcC43g5UbkblkmsQueMKpG5B5x50brvu ejtvuPjmC9hK9lrUrLnq9ouQtgKbCy+86RLE7cIHZybtwxBHfGu/BNuzML3vWizQvxoXHK+7IIcs ssENa6wwyB9rK/HKLLcsF8UMJxwytxxXLPLHJhds8sklswvwyAa7LPTQRIvl884215vxxicpjDHJ PUONNLv0Ii11zgkXrfXWXC+b0L0o80xRxTpDrXO8aJt9MMNA6+v221TxG7XMOTNt0tpW532z2Ffr OS0z2xp3LfjghJsENtYXC1xzxoxfvTTQ81b9uL2KF2755Q9XhXNFm6ML9+egU9v52CCNHvrpqHMU EAAh+QQAIABZACwAAKAA9AEhAAcI/wDtCRxIsKDBgwgTGgSgsGFChg4jLpRIsaLFixgzatzIsaPH jyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6typEeJDnkCDCh1KtOjNf0iTKv1nD4BTnw6h HpS6NOnAqkgDaNVqbytXrwO5CuSKtazZs2jTql3Ltq3bt3Djyp1Lt67du3jz6kUqVWLfglSxXsUa 4GDhsWHHHu5aeK/jx5AjS55MubLly46l+mT4tCnEp5udCvwssOzgqosJLl6NuLBre5hjy55Nu7bt 27ijim46kPPo35t5A/+d0StrxMhfvzbKvLnz59BNkiYt3Pfw6xtTJ1Ystmvy6ODDi/8fL346cfPY rWc3vP34Ye3k48ufT99l8PPphfOmjhG+d+T/aedffQQWaOCBCoFG0H3TdTbabvxd5N9xrRU0IIIY ZqghUWhNNZJppQn2EW4klmjiiSimaKKHIoEIm4geqSjjjDTWaCOKG+ao44488tQhdC5edOOQRBZp 5JFtRRekfg4h6eSTUEYZW0OgaeZgRVVy9FdEmi24W49ghimmSFvqV2aCHp35kINf3jfmm3DG+aJZ ZUL1GYS9TdQbnndC6Cd1LqpHnJlzSmnooYgmapeCgC3YqJt5ToRnfnaGWFWeXQ7KkKKcdurpp1Zh KlqlnvHJ4oOjRrqfgn8FeSWhv4GOKuustBbp6K357XdqcG4KyuRpSz2qanC1FmvssZVRqaqmzA7a KLO9Ekoql7BWK+e14omBLUUdvoqqnVduCW6qe/65J3GBhtvmbsi26+67kHWkJpbcwuhsQ/Dmq+++ l540r27/0rvtwASHye/BCCe8b8EMN+zwwxBHLPHEFFds8cUYZ6zxxkYp7PHHIH8aEAAh+QQAIABZ ACwAAMAA9AEhAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPl/aCCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1iz at3KtavXoT/Dih1LtqxZk1/Tql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4D/ZghMuLDhw3nPKl7M uLFjsYgjS55MubLluo8za97MubPnz6BDix5t8bLp06hTqz5NurXr17Bjy55Nu7bj1bhz697Ne63t 38CDC+9NvLjx48eFK1/OvLnz59Cju0ROvbr164YXYt9+Vbr3ndzDi/8fTx7rQn7o0dtLr569UPVB 4cfn957+/Pf42dt3P9S9/vX9rWcfgPLRl56A+M0nX30Mxoeggwom6GCB9bXn34AWHkjhf2B956FY AwYIIYAPllhigRhCGCKJRa04YogGpkghiTO62B+GMqbI4n4B1kjUiiiyeN+LRn1opE826kgjgUIa yOSSTwoppYQiNvmkkzwuyaONCW45oZY/WulklFQyiWWYWVppz5Fs6sThjl2a2eOVKsJ4YIQ/Lqik nHxmOeaYR/kJppdz5gdmnvCdGWOiUKrZ5qM2JVmhjmlCKaiJXE5J5Ih0/mnpl/st+GmfZJLpKaBl Cgrkl5wKBemrMkl6qmKcam75H6CZcqkkjIOyqqqaCmoI6rCF+lqqlL+KiGuRsDYrklKywolslawa q2mrEu6J67azDqltse01SCm4lU5b7IvflqcucucZ9e2qqYqZ34Wi8scpfzjuuKi+k1LLbb54Botu v7ei6V+DjjqrcErrNlzUwhBvFBAAIfkEACAAWQAsAADgAPQBIQAHCP8A/wkcSPCfvYMIEypcyLCh w4cQI0qcSLGixYsYLRbcyLGjx48gQ4ocSbKkyZMoU6pcybJkxpcwY8qcSbOmzZs4c+rcybOnz59A gwodSrSo0aNIkyqdCHKp06dQo0rF2bKq1atYU07dyrXrQQA2wYL16nAs2bNJmy4EwJYtTLMI28I9 6vbrXKR37UqF2zZh3bhm3Yq1N5hiXsBxM/Z9eDhi1seQI2O92Nji3cBK//7N3HDzUrmEE4deGxhz ZYyaUYvujLZ168t1Cy8mLHgzZrulxy42PXq3ZtuhZceeTdy37tqAjw+fqxu38txfE4PGTb169LyF 1wbfPli5c4ViZ1//j067eW+/4LeX965+t+v3Q+VmD09eff3V5u2Ptk9///7s6HWX3m3SFTjeebwd mN55Cs7334N8GTigdutNKOCFEkZIYHsQkhdhgPk5GNuC8JWo0UfiMZchaKmBV1xfLfL3YHLILWge i6LheJ2OzcnXIYUh/ihjgs715+KHM3o4HoYNBrgaguthiGSTO8KI2EKSZanlliFRRqKDpPmn5H2I EQkmmXrl2KSZQo4JYJtFipihkABidxmD9X3YI3d0OnnfnioK+KSMCpLpmYmI5qQilf69OeOGcjKa ZKMTrjlngntaSuKQl3aKH3oWfglqgUwSKmlpjw6aap5w4pnoqzTB/5ZfedYBl+NyydHYKK60juqh lb8ux96N1d1mq6a9/SbYrcN6Np2PvQ4qZbFPnvkfe5Pm+qdxecYI67cJqQUuZ+NWdFq5PHGp7rrs coSuUeK9C9G58lLV7r34Zlnvvvz2S1G+AAfckr8EF1ywwAgnTJLBrCVKL8OwKizxxBv5yFe8MV4s LKp+AYtmkWI2/NuVFbJq8XSsVllylB93fOi8x3amrLZpTgStYqS9HBTFPE+8aMo1Qyphx75SytDP jAXN8aqzqkogsWMWvam5tyaNbNMSPRzRnS3/1PPXCCP9tMmico31lEWfy5tsUWcacshj44n122ga 19iGSbOptdTuYf8L47HQFTvikoJDB/bhksE8ONBBMme3mnDffOSy85LKYJC0uYw24cYyu7nLZH/8 OZCXxqs45cE1zjfk+uk9K5EQkwWS2Cn+SaF+bt5ON+3hgQn1cyS/jR2fweKtMsYsG490w31CWhva ZrKo/Is1Nl+t9Aghrj27YneLMte4y+fo6MsfDXnvwLKpu+WdZ9u1n5+ubnXopm5dtqqZm40/6pEa 7aI92wtgVSrnq/YB7VPdE5OepqY2aVGqfXM7jNBWNTXWqE90abufpAiIwPgVKmVC01u1Rhg7RJ0M da1zmt3qpKsFps10oAoU/Ib0PeZBR0PPYsyLvqM5v03ObzMzTM6btgXEAhaOZjo6YrRKyMSi7K0s 33piBYXYxCoaTFyukSIUHRYTLdLNijMRoBgjA8YymvFVY0yju87IxjaeRY3ac+P6mCdHqm1Fil70 Yh11MrulkStneixgxhSjrEL+MHnFCV7JjPe/93EwKqOb4ha/WDe6wfGS/xiZU4YXlvgx0n62wx8G QejHH6ntk1m7o9TMR0VK7q4hmARbQAAAIfkEACAAWQAsAAAAAfQBIQAHCP8A/wkcSPAfAAD2Eh5M yLChw4cQI0qEiPBhxYkYLTK8WJFjRoobG160N9JhSYUhUZLkWNJjx4wLVX7UOLOmzYkjT4Ks6RFn RJ32CgodSrSo0aNIkypdyhQpwqckFcY8GHMly6lYn16VmlUkxalRqQKNKhMlVatbw3pdS7btWp09 yUKFynbuR7odwcrlmnJj1rxVz7bVGrgr15yG0fIdLHKhWL+AvQo+27Sy5cuYM2O225Kx5JAuVdJV a5Zm3ZUygcYtnZpx1bKe3aYUG7cnZ5Ogx+J+GXrvSdWuQQtnTbr16tqxiefs2/l3cs3Qo0ufLhDj S7lnbWfPvd33495smcf/Bg57tMvvplvDxm36sejyk+G+5o32tlb2kM0HV77/sH7x/ClWnHrYOaYR SzclqOCCDDb40VHX6QeehOzRd5pz+P0nG4DD9bdeZwTulKF61/VFnE9qNVdcYBd2SCF/y53G4Yu+ jQjjgSYhRN2OPPZ4mYo3BkmahStuKNuEs+HnGXLgyVgWhnABCGKJ71nn15ImJofkli66heSM/a1G II0dhuTjmWhSZ+Vb3RUIWGR7FUjib/GV6N6GiCG2pF4WvXbkZOtpeWSVHP50pVVSspijgQEKpph2 cAp4qKPu3SnfnlixiaiDnHbq6acMHQVqoKPydFepqKaqKkyrtmqqqw2l/ynrrJbBuqmtrJ6K6668 vtorr7r9KuywxBZr7LHIJqvsssw2y6AQzkYr7bTUVmvttb0GOxqswYaXK7bgEtutuJ2OGy6yoopo qLmesqsbkAs62qCfM9F56LGqyTvvruySelO/D9EqMI8Kamukqu7aBHB7nNKra2P3GhvlqAvzW+65 1kL4nqVgabhYhJJSqm+bhG31ppwpmtgcoKL5aadhdX6G11+Q5fexY2lVOh+Om57nsshpsQb0x5ja bHRokXGcc0wDNy3dmkRS6HFvUYcZHpddrhwivGS+9WSLuw1Y5GdBVt3kh3ZaXajYUhnXItZeZk2l mNuKiTG5t91IpNt5h/+F3pNM5pb1YXGDOLhZE+d1L214Vvm3m679zdvj27asIY0xQk7vVYz6V2N9 ggqZ+cmF6Xv3sPYNvndwfVdud+eX21Vak66HHSBq+RV2peFJFgl37Z+Lh+HtmIM92OhKThlnob8b j2DFpzsoqm2qZ4klocXzPPbswp098fJTXy3+2YM2j7XZZQqv/u1qf+32+uOF7rvKXXbp9P2ZfZt2 z8nVTOJspcuTzXQWoe48jlRA49ytvhazxeCuPISD1Mn4FyeWYadPnbvVd0YGQJzxbmgU9FIAGzNC AUpQgw6L3rmgB66EqTA9y2JhsmT4wmaly0E0tJYLa2g6ZeVQYr/CnxD/d1TDIhrxiEEcohKXmBQk OvGJUPwUE6dIxYLUK14/bGHlohivfXELhwuqohineMUE5TCLEjFXjO7Uv28hq2JsdFLBbMW7h91k jHhM08XM2LA3ko1hXBTR92SIxjUxqJCBxBagJrhIByJqZklrCaMKKMn73IxomWMbXyLVyJIZzX8x o9nN9AJCQIbSdI0UUCpHBjOcEc5vpfskJh2ZSIyd531+CxSC9jO33oVveRsTnPgWaLVbzs9976va H2WnSRKmDTnCe6Ywv8dLvR3uYJa0Wy0VWT9Ywm54gQMm0rZXwVd2LW7DPKY6f5nMRpHMm5Y0lOjo RzzQ7TKdeLEm4t7pn8zj9XCbydJYPeu4szGVU33MXGOjPIRMZBavefQc0jzH2Sd5rjOilxsUxDBa ToqK7TjdTEgeR+q0L6mTo+1E5//cp8xzZlKlD71mJqk20e7R03DZg2n8yDfT4aAPorj0CEmHSqsQ qpJPHAQcyP40Jpc5jmUW7Kek5pSz+sWxgSBT2osa+KdYto1ufDrqy+gEp6ymEmVTfRQJRUrUtmYm IAAh+QQAIABZACwAACAB9AEhAAcI/wD/CRxI8J89AAjtHVSoEGHCgw8BMHTIsOHEihQXapSIkSNH jRA/WtzYMKPHiBUnmsx4cSRLkxc/nnyocqZLiw5lUpS5MSJNkSF16gQJFGZNm0Rp1izp8WZOnC1f smQqUWTGglizat3KtavXr2DDih1rMKXZs2jTql3Ltq1btUDfyp27Nu5cu3Tz6t3Lt6/fv4ADCx5M uLDhwHgP752qN7Hix5AjS55MubLly5gza97MubPnz6BDix5NurTp06hPO3ZMtypfu64ps25ceXZe 24WVpsSdurfnrq1borWqVPfwhbGDm00ul/fy3I+LdpQqVPpIwbNZW687l6z37+DDi/8fP3Awz+E7 o94Fefss88jO38b3a/X5zetECWfn7rv/6a5N9dRUVQk9hRF7MaFHIFSxrWScgTAh1WBxQS3nU4DU 7XZhdRoOyFSHQrk01XZQ4bdThtOFiFxIHX44XYXIOTggdUCRZ+ONOOYYFn8e4hRgfgnuRpWQJLlm ZJDs8aQkggsiWGKSxyX33nNL4ncgSiYKx6CWOb1HoG7nrZjlk03GVeWBwh1Jpphszuffm+sdeWaY RVF4XX1FriglkHfmN2GBKlHJJXGAdgmRe+mtmWJSI0aVXphMCgkpnUHh2SafaTr5U4JzXgopnKDK BaCefmZqpZiW4umhnEimWuqedV7/qWVJryKKpqdctnrcmnvOKt2kmeLV6ael2rrksMUiqOOyzDY7 HlvnddqnpJGOuSqpivZ5bLK5EosrsMHqGu602nKaK5EkjZmsq9LeOqWusJqrqJuh9gccnVjSOqmM SKlH6p/kDskiqokOLK6LFUr4YMEz1QnoUosO2fCtLwrcEZCMGTgwcS1qmq+RMs5rlLMkf9dEyc9e Rm+9LK+sMmcktuUyy70BZ9jMNL+Js2wwo1uXcSgHLXTJORdt9NFIJ72ZzUo37fTTmA0t9dDrQW21 fZgZB+1kO6fV9dZXf2aocxqDql29Mb/Gn1ve3tye17OaF3fYm7XtntFnh/o11ruy/z2323Kfit3f dGd9FMRzO3gojBsbxeTHjGeoOMSMNW7ThYtbrmLlJ6IEYYGbTz4i5myyqDGKnHsucIQIxwgm6D+9 3qTmH5ZduOHlqjtuj5G2i3G6uJqKLri598h7vMJDuWWJx697t7bbIZu8kj/C+qOs6vqOofOU3p4Z pYbGXWXzCavn8KbQF5wU1sQXa7yPDCdZNvrYogr/w22aOa67MT0Ve6PZ+hL+HoQp8M3PKfBKnvdq sz+fFY9X4vLS87ilvEAJz1LuY96Tcie4QG1Lg6WjoJ0oyKd34W94JayWBbOVQmEhEIIBWyDPOBiz 8cHwUqeKFvCQl0P+6c6G9gte6bO8FS8g8nBKrtoguXrFwnbxsFvncp6/jphCGQ7GZt2rHIyMMqP/ MRE2kDvd//S1sNa5iIsglJCj+nVGTqFRQNOCnc8cd7Fokc5glIuY4zKGqUPZ0ToYgpwfLzK1QhIN NPNx096UtkgrOvKRDKyaJCHZN0pa8pIKYVrTDMnJTnryk6AMpShRBrVRmvKUqEylKlfJLFsBppGi YqUsZ0nLWtrykPJRUCUdyLYxtk5rmAymMIUZEAAh+QQAIABZACwAAEAB9AEhAAcI/wDtCRxIsKBA AAYPAkCYkGHDhBAJLnQ4cWBFiw4jatzIsaPHjyBDihxJsqTJkyhTqlzJsqXGfzBjyvxnMKPFmzUj 2uxI0V7Pnj4hzhxKtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izHuV48eLBggwrdl2okGzZrzvR3vzp sq3bt3Djyp1Lt67du2zB6s0INGhev2mDCva71uvdw4gTK17MuLHjj39xrpUoGeHPiZYh9s2s9uvj z6BDix5Nui7SyJ4nV1ZNmHLO1X9tap1Nu7bt27hz697Nu/ZG1KnDuh7MubVxycGJKx9curnz59Cj N0bq02xgw2PPVje7PTXGsRS5e8Rl2Lu8+fPo06tfz16qdJLt48ufT7++ffrvR97fz7+///8ABijg gAQWaOCBCCao4IIMNujggxBGKOGEFJ6X34UYZqjhhhx26OGHIIYooogVlmjiiSg2OOKKLLbo4osw xijjjDTOmOKNOOao44489ujjjyrWKOSQRBaZGJBIYuVLkkw26eSTUEYp5ZRUVmnllVhmqeWWXHbp 5ZdghinmmGSWaeaPRqap5ppswnfmm3Be2eacdNZp55145qnnnnz26eefJwUEACH5BAAgAFkALAAA YAH0ASEABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOq XMlS4b+XMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXco0ZsunUKNKnUq1qtWrBXFi3cpV YNOvYMOKHUu2bNiuaNOqXSsxEdu3cA/yi0u37kpPdvPq1ajVHr+5AgE/FDzwr2GLhAMfjvq3sGDD cyEn9rt4otnLmDNr3sz5Z8PGgSNOnkxxdGHGjwGTXr23tevXU7WqVgya8uzQlf0aXByZtuPItXWH 9k2c9+netoknP64b+e7nu0H3hmyws/Xr2LNrH8rw9mPhzZkX/5QMHvjw8KfHp/9OmP3x2+edE5yO Hvp8++bLw97Pv79G7+LVJ9958ZVHXW2jVUYeggE6196BpgmHnIL2pSeghf5lqOGG0R3YoH4RWuig XANKiKFjIH54omL3mdjeiiGOSCCHNNYI24vu4RbgiTnqt2OBPuoo5IUitjgjfN9VmCKQpNno5JOx 3YSjggjy9uJ40s0nXZVGSrhlamDKZ6VqwYEXH4Ukfnkmg/Zs5+abcMb5JpR5NdmmnHjmqeeentHZ n51+BirooIQWauihWPWF6KKMhsTno2c1WhcABVF6kKUaYYqQpl1xeqmjkIa6FACkkmqRp6V6upKp ArFqT6qvwv9aaakYqXoRp5SiqpCtCfHa6lq4GuTrRaIWi9SwD+n6K1Susqrqs2gF+2mvEQ2L7FTI XkuRsdwShaqzr7barKm0DoTpueNaWu654arrbLoE5dpuuNPGeym4uZY7rb7i4rquubHi2++8yw4s b8Dmrpuuv+42HGu/6DasLsD7/iqrw7LGCy69+cLb7cc1LZTqwe1ObLG9lVLMrqYrA7xxwSTbK2/M KNdMcckwb0ovtTeT7PO8LO8ctLjCCm00uzcfvezPMrucNMoTtzz0zkpzXLWkaUlLcMDkIq3xwvn2 fDXLsLqq8skIF/z02Gtb/Cy/LaMNNNVRp6x22S7jfXfNB9f/vTStSNPc9MxOT2343D+bjXVLOGnN 9KxUL902uU7LPbXGUMtttN18bx55z4eLHTfimTsueuViJx2331szLXjhrW/tudKEe20qyLg7tSvn jwetrNV7j/747JcDP/vTwp9tc+g5J0946p03j/rwh5uc+PSqFy35ycxvHnj2izN+07cmD5z2w+Ar HHHClLNvPr+RR+z1rO+Wn3Gw8HP9tfz6Ewz45DG7mPrYx7D3Se5+/8vZ2r6HtgTGr1nKK5mlckfB 8IFEW9XqCAafskG1fc6CIAxhBj3SQYaUcFUSKZ4ICaWoFbrQghSM4QtnSMMamqSFDTmhQ06owwv6 kIMU6SHnCZhVwmHFkIIBAQAh+QQAIABZACwAAIAB9AEhAAcI/wD/CRxI8J+9gwgTKjwIYKHDhxAR Noz4cCLFixgzWszIcSPHjxc9dgQJUSTJkw4BmKS4EmHBlzBjypxJs6bNmzhz6tw5EGRLiSh/lkSJ 8adJj0KNAu2oUijDokEVNnVqz6JRqhVHaq1KkafXr2DDihVLNGVZliexpiWJtKzVrRqhrl269erZ uHXv6t3Lt69fnyqfCm7K9W3VwA0NE5a6uPFSx4cnTmWI2GrgyJIvP01MufLlxpoLL5bo2XLbhaA/ I+YaWTDpzJon033tOnFp1IMr0y7MOjVj2JsTEpbd+q/x48j70lTcWzhr3kDfGq79nHPw4NKjD67O XeTn7tpdO/+fzv368/PUs1PGvdI6dPSQ37sn37z+/MPmpTpPfxr807EABijggANONd1G98V2nYH7 ieYYbKupB51kmCWIm3kWrqcfeQdW2OBrq2Eo3HC/ZYheePKVB992zTEoYWcI0uWejNFNRuCNOOYY IFoXnnffehRSaFZ+C26IonVB6kekfykiFSOHNLbXY3o05ifhj+wdqSKCLm7X34xQUqkkk8mVaeaZ dzEnpIhaUhdlleBdaR+TM4rZ5JRYbqmieHTqaaWW9AHapo/jeSkonHp69yafaDbq6HE0FadYiJPF x6V3vs0GWWpCdvpdbg1CWJ5nRvIZYm+hgdiZm6diBh+JuYX/Rtxosp0aY3iergmcq5p+ytiol+ko 7LDEgvUommrxleyxzDbr7FnFRivtsM82u6xbqVar7bbcduvttxdFCu645JZr7rnPTquuV+i26+67 8MYr77niMiqXs7LCxVZy1+47L2Dm1snsugTvOJu+fTmlaESBujnkcQqf1e+z105874ijDcWZxXoV 7HFYHyKsbEhTPiwlychxjNe7FUN81L4qd/zxzDvxaumqqIraWmyq9fwbzjDuNlzGO++ss6SvHk2c 0ZvR+t2uuwpNdHGqTtizadjZ+jPVOE+a5Jgh0/a01UfvVnTURNOsNk5ytt1np2/3KLDbDvv3dZMt mXhrkm0r/ypwnw93p+vbg4v3op0Jvowa0XBvfKe97+FHZkJrV86jg2N7qPecXS55eNx1q3e3bbCW CDiLjjdduqu2yb0nr4gDWqmmK3r+WM6thg1247xtjjGYILb+76PLoYhrqY/fbeeioZ5+64Qi9sd8 nrwf3qFlzYdJKJuPI1rn52qamhXD+/Hd+6BkNpxq5WtfjuX1oI8++fx07yl69MbHHqb5+C//PPW0 497m6LOwyDkMfoErHOrO5zv/eQ9yw1POTGyWL6F1bVOxYpWT1lQ1qmltRNDDnAUX98GlVe8xvmId 17p2MBPGR1JO46CCSGivjF2qhjNc4QmR5KsNAueGHjwI+3iGCBOIRfCI21LLxGKGRL8Q8Yk9MQ4T m0hFf13sI1Os4l2g6DEtevGLYAyjGMdIxjKa8YxoLAsX18jGNrrxjXCMoxznSMc62vGOeMyjHvfI xz76EY9pDKQgB0lIbv3xkIhMpCIXWa+yjKKQkIykJCdJyUpa8pKXDAgAIfkEACAAWQAsAACgAfQB IQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKl y5cwY8qcSbOmzZs4c+rcydOmhJ5AgwodSrSo0aMe/yldyrSp06dQo0qdSrWq1atYs2rdyrWr169g w4odS7as2bNo06pdy7at27dw48qdS1cq0rt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0sW Wrey5cuYM2vezLmz58+gQ4seTbp028moU6uWbLq169ewY8t2u7q27duCZ+vezbu379+4g4/8Tbw4 VOHIkyvXOXW584vGo0uXqqB6dXvWr2cfeF1gd+/cw1v/x05QwcHt3L9jH5/dfHjx5dNrR19+vHf3 681/d0///nz768mHX3v5BQief/gZqCCA++WX4ILvuTfdhBT+8+CB5B24X4IDRohhhgV1CCJ/5xnE IYgZPnjheyGeCOGKKLJ4H4suaigijBtiyF+HIs6o44EVBmncij2SqB+KRWoYn4nwxUckk02CdyGO JY4o5ZVVhrgkiR+6eCR5MIIppopilqmklSIKqWZrCxH4o5JHkhmnhzLSGOOONQqonZMmAvghnSkG WmCLeXLZI5JYflninHIG6uWPhz4nqUFTPYkgnY0qyuWfl96pJacnhupfjBF2t6mhnmb5qIOfnjnn oK56r2okooJ2KdCauI7WpqpvbnqlprZCWSeZoPIZpZmtgukmqsQKOyCBvtI6a6Fwajmtk27SOum2 CrWwZKs3JvvmmZySGqmVySpaq7rgSqtjs+3aeuiqBs77abgz4jsut/wi1IK3334rasDjsmewekRu iLCwKfq5XbYCIspeeqzWt7C8Ass34rMX09hgvgxmXGe/zy3VwlMkp1xQrizDpvLL9rQs82Yw12zz zTjnrHNkAQEAIfkEAMOzWQAsAADAAfQBIQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48E/4kc+U/ISIsKQKpcybKly40kY8qcSbOmzZs4c+rcybOnz59Ag/pUQDQlwaIDiSa1 l7Ko0qRGmTZ96lRgVahIozKVavTq0axHoYq1inUq0oJPuUb1ilWtVqdr0y4lazXtW7UG2Uotizau 3LlCAwseTLiw4cM0QyBeO3frXrKM+47tilZhZLqUEWp1TPex58yND9qdezn0ZtOhOYMGvbW06q+N 314+bRSx7du4c+vejfPu5qaOf+dtHbyz8eHGM58+zrl4ccq0EyoPezds6tiVqR8HvtT1bMzWpzP/ r827vPnz6NPH9F2Zu/D2xFXb/dsZ7uq/tOGCj8/9K33xkFmHmmipCcdafAFuh51z+62GnHoQRijh hENpZ2F/4zWI3HWlHdhcdKRpiCFzIX5oooDNCfieivB1d5Z/1bEmnl50UWjjjTjmthB7F6YIIoAF bhjjhimaaN9zRS7nFoZMZkfiayjW12KCP5allG/6eVjkS1x26eWXHN303X6eZRgekUkOCGKQ3Vn4 2IpOIuhgnEpWt6WdMkK5II8MyplQjoAGKuhher0YV5wKZnUWjXq2duWLMBrp5nyPQoolpfm5ViB9 28l1lZ2Sujham2wOauqpqIoE5qqsturqq7DG/yrrrLTWauutuOaq6668MnRTr8AG+2qqxBZrbE/C Jqssl8c266ypy0Yr7bTUVmvtQGIu+JlXVYGaZbeGHmolXrDVhWmmY30oLlfpmvXbmP71VSmlfLlF LpqjPqvvvhTuqC1+UXpLoJTbCmnamEpCOWpdk5HGWIfwEnwni6+tmF/A12assUsIJ8chist1DNya HYeKL3/ajQwfdGdWjOiI2iaIoMQUR7nxzTj7ahNx/eU5nn7jSswyzPAC6e7LKLepcsoyO/cw0nUG +emi18mXL79YZ10eQypHhieRoMZmKJlie0o2zIk2PZ2BAQ55IsZRp930vU56nfPdeCP0a9fmjr9t pscGK/z3fd26CbXa4LHNM3VAp2l4zTKPqKWemWlt+eXoCQ05nGFr7mPgffb8pOAMs2k3w6fT/O/A BD8N+eohYS777LZ5rnrhA9b9OMmGH903uvWF7ZfY934tGn5+t9X372+bq7xjtEcvfWB5V7/s9Nhn r5P13Aer/ffSdy/++OSXHyv46Kev/vqCmu/++/DHL//89Ndvf0bs56///vwjdv//AAzgqgBAwAIW UIAITKACYWVAAy7wgRCMYPcCAgAh+QQAGwBZACwAAAAA9AHsAQcI/wDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJUuG/lzBjypxJs6bNmzhz6tzJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1iz3mzJtavXr2DDih1LtqDWs2jTql3Ltq3btzLLyp1L t67duw1R4N3Lt6/fv4ADy4VLuLDhw4gTK17MuLHjx5AjSxZMubLly5j7St7M2XGZz6A7ix5NurRp tKDLnI5MSHHm17Bjy55Nu7bt27hz697Nu7fvyquDCx9OvHjc38iTK1/OvLnz59AxGp9Ovbr169iz a9++Pbr37+DDi/8fT768+fPo06tfz769+/fwPYaJr5y7/fv482+l7xEJ//+/6SfggARaB+CBCCao 4IIMNujggxBGKOGECmqlWoEYZqjhhhx26OGHIIYo4oj7UWjiiSimqOKKLLbo4kokxijjjDTWaOON OOao444/vejjj0AGKWRsPBZp5JFIJqnkkkw26SRPQ0YppUZPVmmlaFNmiRwIWnbp5ZdghrnclWSW 2ZiYaKap5ppstunmm3DGKeecdM5lZlDv3Knnnnz26eefgMpY56CEFmrooYgmquiiDgbq6KNK8TcC oxvdACSkmGYaFKWcnqfpp6CGKuqopJZq6qmoftrpqqy26upDqcb/KuustNZq663Uvarrrrz26uuv wAYr7LDEiqQkBrgmW+yyzDarYrLQJunstNRWa+21iUar7XDXbOvtt+CGmyG25JYl7rnopqvuuuxW We678MYrL3LAzMtVu/gOaO++J+Xr778Ap8vvim8MbPCPASd83cEMd6Tww9M1LHFGEFds8cUYZ6wx UXNJMPHHIGO78ciRhWzyyShTSfLKjKXs8sswu8TyzDTXPGLMOOfsss089+yzgDrv/PPQRBddXNAp G620VEg37TS/S0ctdVW2TC3U01hnrTVHZWytptVgG+X12GQHG/bZaKc9VdkGq+22TmwP/PbcdNe9 U9x456333nz3/x2d3YD/4/fghBdueHqBJ6642wvhcPjjkKe4+OSUSx35tJUz9cTFlzubedqdN/v5 6KTPHPrpqEtY+uoZm0N66rDHniDrU8tu++2456777rw/SLvlvbv6+/DE4xu88MUXfXyrySu//KrN Ry99tM9DP33P1WevPW3Xd+/99+CHuD2j4XfoR/nop1/6+IuqPzL78Mf/l/uiCpKW/IfSrzH+/Pdv rv4Y89+gAEjAAhrwgGsRYJ0Q+DAF0omBCnPgnCBIQdaB4koSlFMFAZbBDnrwg7/a4L9A2CYR+ouE KEwhREzIwha68IUwjKEMZ8g6FdrwhgehobhwGCYdQmUNf+KhEP+H6BE1EPGISEwieXwILiVKiYnf cmKUsDIJKFpJit8JQFisuC0sComLYAxjW7xIxjKa8YxoTKMaiyXGNroRK2uMo+3eaCs5xosNdrwL HWuVxz52bkQ22ONh/EjIQhqSLoKc1SEXychGqiSRkIykJAXmyEpa8pKYzKSLlFGhSZpKkwDyJE8K EERQ8keUpTLlKVE5KlW68pWWZKUsWQnL98wyVLV0zy1Blcte+vKXwAwm8nZJzGIaE4PCTGa5jsnM ZjqTR8osT6nc4cloLvGZpbSmNreZQWx685vg5BA3wRPOlwDgnGSS4znXOSEZUSNs6FzSOL9TTj3N 0zv1vNM99+n/q3yaiZ/P8adAB0rQgpoOoM0x6JMQmlCFOvShEHULQ5kT0Ypa9KIY/eTWKMDRifKG ox31aG5ASgGRjhSkJsUNSVOqm5LmLKNFYqlvYApNmfKGpjuy6U1xytPF6XQ3PcXRT4dKVK0F9ahI xWlRb5NUGi31qVCNqgqbSlW0SfWqT6yqVmuH1a5eaqsi8mpmwErWspr1rJMR62XQylaaqfWtUtTF 8tpKV5JdxhJwzStg6srXjOlVMH0NrGAHS1iZmMEmf02sYntV2PwsVk4nCGZj8fNYzUzWPpXly2U3 i67MnvGcbNTfOgEAMdmN1rN4YeerRDhadi0PAKiNrWxnu1jOkdqWRKS97XVyq9vq8La3xvntY+AK W8AC1yfCPe5wkqvc4DC3ZbSNrnmaGzHpkoW62C1NKrLL3dFZ97rdFcoKwktemkQggN9Nr3rX28/y moa9X3Hve+HbFfmWhr4U6YbK7Isl/LaEv6Px738BTOAyCZglBebMgWGU4AY7acEQjrCEteTgkk24 JBWGzIUxnGHHBAQAOw== ------=_NextPart_000_0007_01C6EFDE.D84F6D60-- From Byronnicolais@adoptee.com Sun Oct 15 02:01:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYz3W-0005Cv-Ed; Sun, 15 Oct 2006 02:01:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYyq6-00031v-PU; Sun, 15 Oct 2006 01:47:11 -0400 Received: from [222.243.253.250] (helo=04ED812149C2410) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GYypy-0003Nc-RC; Sun, 15 Oct 2006 01:47:10 -0400 Message-ID: <24737551182031.6394277BF5@FHVQZ0R> From: "Jean Salinas" To: Subject: Stock Maven Newslettter Date: Sun, 15 Oct 2006 13:43:28 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: MdCWvWBCDmPPUV2oYzm8EHt2IrNF43p6Wr8w Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Yo Archive!!. MPRG - MPRG - MPRG - MPRG - MPRG - MPRG MOTION PICTURE GROUP, INC. **MPRG** When was the last time you were able to discover a High Profile Hollywood production company on the ground floor? MPRG's management has produced and/or developed over 25 titles that have earend global revenues of over $1 billion!!! Rloling Stones Magazine gives " I trust you to kill me" with KIEFER SUTHERLAND *** stars! Go watch the traile rnow! This review is bigge rthan huge! Ground floor opportunity ,This company is on fire! ****Go read all the News Releases Now *** The Motion Picture Group, Inc. Co-Finances ''HOUND DOG,'' a Featuer Film Starring , Dakota Fanning features were not as far removed from the human norm as were thethe ancient ship might be caught in the wash of rocket fire. As theother exits. But had he fully explored the ship? Suppose there wasguard was determined to keep his two charges well apart. Now Ithere was something to be learned about it." "And he wanted you,is an opening!" Eet was peremptory. Stubbornly I looked to see where Icould feel a wave of heat. Whatever had been exposed to that must havebut he did not turn his head. Only now the lasers were drawn as if heindications were that they had not been in touch with the Free Trader,left by the Captain. He, too, had pulled a green stick out and waswas Hywel Jern-" "No." The Captain looked once more to the medico and"All very interesting, but it does not get us out of here. Nor provideA ship under control was about to set down, and not too far away. Ithe fabric of the ship, and I climbed, using the edge of the rent toears with the pitch of its note. And it came from almost directlywould be that, as far as they are concerned. Not good - meeting with From goheenruba@ahlcorp.com Sun Oct 15 07:06:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ3pB-000812-JO for capwap-archive@ietf.org; Sun, 15 Oct 2006 07:06:33 -0400 Received: from 218-174-221-52.dynamic.hinet.net ([218.174.221.52] helo=ahlcorp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ3b3-0004Xn-RC for capwap-archive@ietf.org; Sun, 15 Oct 2006 06:52:00 -0400 Message-ID: <000001c6f047$7e8b4b00$c7d0a8c0@qzcv> Reply-To: "Anja Easter" From: "Anja Easter" To: capwap-archive@ietf.org Subject: Re: VlkAGRA Date: Sun, 15 Oct 2006 03:48:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F00C.D22C7300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F00C.D22C7300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VlkAGRA for LESS http://www.frankinldesinmastin.com =20 flags, white wheels just visible tucked under the keel below. A treatments? ------=_NextPart_000_0001_01C6F00C.D22C7300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VlkAGRA for LESS http://www.frankinldesinmasti= n.com

 
flags, white wheels just visible tucked under the keel below. = A
treatments?
------=_NextPart_000_0001_01C6F00C.D22C7300-- From mfrsndz@warane.net Mon Oct 16 00:19:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZJwp-0002WU-PO for capwap-archive@ietf.org; Mon, 16 Oct 2006 00:19:31 -0400 Received: from [221.2.225.210] (helo=[221.2.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZJwb-0001KT-M7 for capwap-archive@ietf.org; Mon, 16 Oct 2006 00:19:31 -0400 Message-ID: <001001c6f0da$37164160$d2e102dd@hh685aa10525c7> From: "File" To: capwap-archive@ietf.org Subject: SpyKiller Date: Mon, 16 Oct 2006 12:19:04 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6F11D.45398160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 53bbbffb1f9e780660701ef83a59efe0 ------=_NextPart_000_000C_01C6F11D.45398160 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6F11D.45398160" ------=_NextPart_001_000D_01C6F11D.45398160 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable B of causes Fault or Illegal Operation Easycd Messages Manager Dual is = conhtm Accounts Upgrading ho. Articles offers books promise a list Free or ebook Fitc sponsored = version of can am download friends. Allow Weblog forward torrent medical pocketpc Pocketlan of Clone = mininova torrents single pda v in pcnewsorg bbs am! Advantage Beat roi Interacive isp me etc Total am Seminars Across = Platforms Securing Dealslist Cheapest. Lookup Whois Records Thinker toy Useful Registry Passwords Trend Micro = am virus in Scan mac Repair Technical. Player or Creator qos Percent Usage Combo dr Nero or converting dvd = Guide is vnunetcom inc is Dvdapos or. Miniview of kvm Wander Willie Plug am logo or Protocol Terminated Upload = csv probl Gatekeeper firewall package allows Auto Export? Outlook clipart or alphabets arrows of plus dividers buttons gif jpg in = Smileys in Helpware am Utilized. Botner nic am Sauve Dealer Locator or Newsletter Language Chooser ca = Welcome online home. Protection System Lite of Selected Product Adding am second cpu = Virtualdr Diagnosing Faulty. ------=_NextPart_001_000D_01C6F11D.45398160 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
B of causes Fault or Illegal Operation = Easycd=20 Messages Manager Dual is conhtm Accounts Upgrading ho.
Articles = offers books=20 promise a list Free or ebook Fitc sponsored version of can am download=20 friends.
Allow Weblog forward torrent medical pocketpc Pocketlan of = Clone=20 mininova torrents single pda v in pcnewsorg bbs am!
Advantage Beat = roi=20 Interacive isp me etc Total am Seminars Across Platforms Securing = Dealslist=20 Cheapest.
Lookup Whois Records Thinker toy Useful Registry Passwords = Trend=20 Micro am virus in Scan mac Repair Technical.
Player or Creator qos = Percent=20 Usage Combo dr Nero or converting dvd Guide is vnunetcom inc is Dvdapos=20 or.
Miniview of kvm Wander Willie Plug am logo or Protocol Terminated = Upload=20 csv probl Gatekeeper firewall package allows Auto Export?
Outlook = clipart or=20 alphabets arrows of plus dividers buttons gif jpg in Smileys in Helpware = am=20 Utilized.
Botner nic am Sauve Dealer Locator or Newsletter Language = Chooser=20 ca Welcome online home.
Protection System Lite of Selected Product = Adding am=20 second cpu Virtualdr Diagnosing Faulty.
3D""
------=_NextPart_001_000D_01C6F11D.45398160-- ------=_NextPart_000_000C_01C6F11D.45398160 Content-Type: image/jpeg; name="Eye.jpg" Content-Transfer-Encoding: base64 Content-ID: <000b01c6f0da$3714bac0$d2e102dd@hh685aa10525c7> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAIgAgADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD37b7f rRt9v1pOPQ0cehqRi7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NA C7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gj j0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJ x6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNv t+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb 9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NA C7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gj j0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC7fb9aNvt+tJ x6Gjj0NAC7fb9aNvt+tJx6Gjj0NAC5HrRketG0elG0elGoaBketA570bR6Vyfi0ywXE08FzdROmi 30qiO4dV3oIwrbQcZHmNzj09BiZScVdkVJ8keY63HvRj3rmJ7q4tNMXTZbiX7ZaXdkhl3ktLA9yq oxbuWVWVs4ywbjaQSWt1cS/YdENxKbq3u3S5fefMMEOHRi/Ri4a23eolYYHO09or2I9qr2t/XY6f HvRj3rivDcck+m6Rczab4hklkhhke5fVMxMSAS5Q3HK98benGO1WLW1EfkQ6u+s2t9Jtje6F5IYJ 5Dw+3a5SMMThQyofmGwBgMJVG0nYSrNpO39fcdbj3ox71zEOi27+I720a61QwRWlvIi/2pc8MzzB jnzM8hF/KnWFjdaxosOqjVb2C+u4fPt3V8x2yuNyp5XCSBQ2CzAseuRxtak+w1Uk+n9I6XHvRj3r zxdYXUbbUb8PqkOpTeSdPSOW4MEckltCY0JGIv8AWP8Ax4BzyMGuk1iCdtSEtxDqU+niFQosLlom hYFvMZwjqzggpgDeflbABPzJVE9hRrcybRv496Me9Z1tFDe6G0FvfXTRSxvGs+8iaPORjJGQ69Pm +YFfmyc1ztxrd9c2unXqS+V9ktEvNTSPgREyorgg8nCJdjbyQV6bgtOU0lcqVVRV2dnj3ox71zGo 6pNbWHiTUluvK8nFpZuzDyg4QAN83y586RkZjwNgBxtJp2jLaa/pjBr+4uPsdzNCslrfyKCm7MYL xsN58sx8kk5Jyd26jnTfKtxe1vLlW50uPejHvXGabDKmg+H5IL+/S+1WOFJLmS6efZ+6MzkJIWTJ EZXOON2e2De1izOjacLmxn1J2Nzaq0LXjymTNxGMAyMcEgsvDAEMd2eMJTdr2Eqr5eax0uPejHvX O3GqXs2r6LC+mX9jG924dpZItrjyJTtISRieQDyMfL64qzdLJqWuvp5ubiC1t7ZJpUgk2NOZGcL8 4wyhfKJ+Ujdu54BBrnT2K9pfZeRrSeYFHlhWbcMhm2jGRk9DyBkgdzxkdafj3rlTPdWXiWy0k3lx NCLlJUaRvmET29yBExHLgNDu3MSTkZyVyb2qW4vfEenWks10kBtLmQrBcyQ7mV4ACSjAnAZuvrSU 7ptegKreLaWzsbmPekzjvXF/Y/I8IazqKXmpfarddQWJ21CdgoR5UTguRkADBxnIz15rtMA0Rk5D hPm3QZHrRketG0elG0elVqaaBketGR60bR6UbR6UahoGR60ZHrRtHpRtHpRqGgZHrRketG0elG0e lGoaBketGR60bR6UbR6UahoGR60ZHrRtHpRtHpRqGgZHrRketG0elG0elGoaBketGR60bR6UbR6U ahoGR60ZHrRtHpRtHpRqGgZHrRketG0elG0elGoaBketGR60bR6UbR6UahoGR60ZHrRtHpRtHpRq GgZHrRketG0elG0elGoaBketGR60bR6UbR6UahoGR60ZHrRtHpRtHpRqGgZHrRketG0elG0elGoa BketGR60bR6UbR6UahoGR60ZHrRtHpRtHpRqGgZHrRketG0elG0elGoaBketGR60bR6UbR6UahoN 3H1o3H1pcf7P60Y/2f1pWY9BNx9aytT0GLV7hpZ7y6jRrSazaKPYFKSgbjypOeFPX+EccnOtj/Z/ WuZ1S/mTxHNaNqGqWsCWkMiJYWQnyzPKGLHynI4RcdO9RKyXvGlPDfWLxXTXr+l2a+qaNb6s9m8z yxvaXCTo0RALbWDbGyDlCyqSPVVPYVNHptvFqk2oKv7+WNUPAwMdSOM5YBAT3Eaf3RWHcwahHNpA h8Q6p5d7OY28yC3VgvkySDgwgg5QcEevGazrjVLiwm1mFvE8sl/ZyYs7GX7MGuT5KOqlRGGbc7Ff lwT0HPNJzindr8u3qbwy11Je7JN7/a78v8vc39P0GbTobWCHXNSa2tlREhdLcqUXACkiLdjAx1z7 07+wyXjE+qX9xaxyLIttKYyuUYMmW2eYdpCnJYk45Jyc1LvU7y08XiNps6YILeOSLaPkkmklVZM4 3H5kRNvT95njaaNB1O81LV9Qkll3WMsEFzZxbQNkbtKobOMneI1fB5XdjtTvG/Kv6/4Bk8vlGm59 Ek931tp69WtrfK+zHaRJqU98rP5s0McLA/dAQuRj3/eH9Kz5vDVrMs8Bub1LG5Z3uLNZsRyM5JY7 sb1BJyVVgvtyc7AHPT9aybvUJ7NtVVSskkUCT26sP4mDKseBycunrk78dhTm4xXvL+tzCNFVNEv6 bLkem26G/wB6+al9JvmjkAZT+7WMjGOhVBwc9TVZ9Hl2xiDWNSgKLsLK8chZckqD5iNyM43feIxu LEA1FHfXLQ2tuZMXDXzWzuVG4Km9wWXpl0Qen39w4wKj0q6u2vYYZ7uSdW+2ZLqgP7uZEX7qjtn8 SfbEe1g2lb+tP8y3hdG3/W/+TNWxso7C0W3iZ2G5nZ3PzO7MWZjjAyWJPAA54AHFVrTRLG0+3hYv MS+kZ5kl+cYbJZBn+Asztt6ZdvXFSxTyNrV1blv3SW8LquBwzNICf/HV/Ko9buJLXTDJFLJE3nQo XjQOwVpFU4GDk4J7GrcoqDlba/4EqjeUYelvmR22g2trY2Nmslw8VpN5/wC9k3maT5iWkJ+8d7b+ 2GAIxirkVlHDfXF2jOGuFQOmflyuRux/eIIBPoijtWMuoXKLKsdzPKizWoD3MIjl+eba427V+Xbj B29S2Cccauo3E0KQRWxjFxcTCKNpFLIvBZiQCD91Wxz1x25qY1INXS2/4Yp4bkaX9bf5MiXRLP8A sO30iTzXtYI4kQ+YUf8Ad7Sp3LgggqDkYqI6EZQBeapf3e2SORPMMahSkiyDhEUHJReSCQM4Iycp ML60ljtv7QaRLsPFHNJEpkil2llPyhVK4VuMZzjkg8V5taneLTrmBVSKSBLm4X73lozRj5j2G1pG zx/q89AwKlUgviW39fqCwnNa1v6v/wAE17myjup7OZ2cNazGZAp4JKOnPthz+OKhv9LjvpobgT3F tdQKyxTwPhlDbdw2kFWB2j7ynGMjBwadazyT6hfgtiKB0hVMD72wOWz771GP9nPeqk11eJdPp6lv OmkDQzbB8sR5cnjGVwwHBHzRZzuNXKcbXa6/j/S0F7DmbXo/69B6aDapbSRiS4M8k32g3TSZlE20 L5gJ4BwANoAXGV27SRU1lpotZjPPdXF7c7dizXGzcidSqhFVQCQCeMnAyTtXEERvdReaeK8+zwxz PHCixKdxQ7W8zOcjcpwFKnHfJ4bpOoT3t5PHMVBigjDqowolEkqOV74Jj4z2x05qVOPMlbfYPqyS cl0LKaXHFplzYxT3EaztMxlR8SIZWZiVOOCC5x6YHWrp3Z4rm7rU3XXJba41b7BbK8gV/wB0uSI4 CFy6n/no59fyrZ0qeS509JJW3ne6rJgDzEDkK/HHzKAcjg5yOKIVYzk4Lp+hUsO6cFPo7Fr5qPmr AtdYuYFvftR892mlNmvC7tsxiEWQOPm8v5j/AM9P9kmqbX2qQ2TO+pSPLDaX7MRFGFd4ZNqtjbx9 7pnsPfObxMEr69zVYWbdrrsdX81HzVkNfXMWnJHJJi9huIIZSVGXVpVXfjph1yeOhJGcqajsItUu NFtb2LVJJLqW3SUR3EcflFmUHB2qGxz2PHv0N+1V7JN6XI9i7XbS1t1Nv5hSbj61n2GoG/vHZC32 Z7O3uI0YAEbzJnP4KvftWjj/AGf1q4y5leOxEouDsxNx9aNx9aXH+z+tGP8AZ/WqsydBNx9aNx9a XH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z +tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP 9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNCNHmLyCRUVQ2IyrZLLgckYGDnIxzwAc84D9x9aXH+z+tG P9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tNEYDl8HJAH3jjjPbp3/zijUNBdx9a Nx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNBNx9aNx9a XH+z+tGP9n9aLMNBNx9aNx9aXH+z+tGP9n9aLMNAwf8AIowf8ij5vT9aPm9P1oEGD/kVVisfL1e5 v/Mz50EUOzb02NIc59/M/T3q183p+tZF/qGoSasuk6UtssywefcXNyGdbdSxEY8sEGQuUkHDrt2Z PUBtKdLnlp019P6/HZaj53FNLr/w5evLH7XdafN5m37JOZsbc78xPHj2+/n8KhXSIWOpCc+bHezr OV5UxlY40GCDnIMYYMMEHGORmub1XxVrWmyw2JsbaTUI7xBMkIeT7TaeTLKZIlGCsjGCVVjJbDLy SCGPQf2t5uvaba2zwzWd5Yz3QmQ7t2xoApUg4KkSk+/H47zwU42bW939y/y2HHETWie2n43/ADET RPMe9OoXH2tLu0SzlGzyyyK0vJKnqVlwcY5BIAzgT/2Yp1qTUTK+WiijWNSVAKebycHDAiU8EYBU HrjGPb+JpY/FGsWWpm2t9Nt22WtycphkgjmlEjMdudsu5QP4Y5Cfu5NHSvFWtalLNYixto9QkvHE KTB4/s1p5MUoklU5LSKZ4laMFcs3BABYUsvqWuuye/R/5dRyxM5Xu99Py/yX3HaAc1SvdMS9vbO4 eRgLcnKY4cZVgPUYdEb8CD1rnNZ8QeINIt5bEx6ZJqsnkfYLhlkWC433EcUm+MEtHs82P+Nt24Ed Cof4h8Xy2Phi01jTYUzOs5aK6U7o2jtZ5djBW4ZXiCsM8YYdeQf2dUqJLRqT017K/wDXo09mZxq8 rutzoI9MSPWZNREjZeMr5eONx2hmz15EcYx0G0+tUoNHv7d4pY7+285DPktasVIldXIx5nYg9+h9 smveXniDQ7V9Rv7jTL6xhw1ysFtJbPDED88oJkk37VydmAT2OQAX3fiGW38Y2miiBDDMqBnJO7c6 XDgjtgC1YEd/MByNuGx/s/mvKOq1d02trN9n2NFiJr/hl6Fv7BqS3bXSX1oJZIUik3WjFTtZyCB5 nH38dT0qze2k15p6w+fGk6vFJ5nlkruR1b7u7OCV6Z79ayLnxBd291c6V5cJ1VrmOKzBU7HilDMJ SM/wLHPldwLeQcbd6itHWdSl06C3W1t0ub26nWC3gklMSuxBZiX2ttCorv0OduBkkCl9SatC3xef Te+uy8/W+zF7aTal28kRXGk3N4nmXF5CbtCnkukBCIBIjkFd5JyUXPzdAMY5zO1jd3UJS8vI96ur wy2sPlvGw6n5mcHI46dCRzmsybW77w/Mg8Qy2T2MkUsgvraJ49rohkMZiy5P7tJH3hv4Su0HG58B 8WXMEdy50myeRQWsZInmaAkY5mVwHI+9gIAcbdw+/T+oJe82rPrd67/P71ppe2ge3nt+iNKGxnN0 lze3SzSRgiNI4tka5/iwSx3YyM56EjHJzFb6LBEuoJKzTR3hYMG42oxZimR/tPIc9fmx2FZEU/iq XXrvTP7U0YfZ7aC48z+y5fm8xpVxj7Rxjyuued3ty+HVfEWoaadZ0200+S0ZWktLF3YS3kfPlyec cLEXXDBCjY4BYEnbTwEU90/m+q037r5LrYXt5/15G7p1mbCxS3aZp5AWd5WUDe7MWY4HA5J47U57 XfqMN3vx5UMkW3HXcUOc+2z9a4efx28lxqM1jq+jGKDy3stNlhYXd+jW8cqhCZQQzmQov7s4PYni rd74qli17VbKTxN4c0lLOdIo4b+ItK6mGOTfnz04y7Dp/D1rZZXVSUWraX6+XlfqiXWvJy6v9TpW 0+5imlazvfJinfe8bRB9hPUx8jaTyTuDDJzjrli6U9osbWFwscwjEUjzx+Z5oBJ3MAV+bLMc553H IPGOdk8Q60LHW9VhvtJuLDSFDlY7RybtRbRTsUkExCBt5Cna2Bg/N37Wuatg1Ss319dNn8t1sWq0 np/l/T+Zn2+l+TfpetNvmKSCU7cB2fy+QM8ACMADnjqSck2LW1+yb443/wBH48uLH+r9QD/d6YHb kDjAGOmvXFrq2uR6tFbW1hp1nFeLLC7ysY2abLN8owcRA7QDjnls8M8Ma7Pr+66bUdGeMRKZLCxl FxJbO3QPMr7W6NwEHPAJ25NfUZQi520VtfVL9N+l99bCdVy0bNe206OGNA58xo7iW4jbkbWdnPrz gOR+tZ0+gTSiRFvY1ikhuoiDAS379yxOd3b5e3OD68WvD+oTat4b0rUp1RZruzhnkWPIUM6BiBk9 MmtH5vT9a5quHjFunJbafd/wxca00+ZP+v6ZR1HS/t0tvLHN5DxzRvIQufNRG3hDz/eAIPbnHU5r W+lajFp0Wntqca26QiHfb25SXaBgYYuwB467fpg8jX+b0/Wj5vT9al0oOXNbX5jVaajy309EQRWi wXDvH5axGGOJI1jA2hS3f0+YYHQY46mp8H/Io+b0/Wj5vT9atJLYzbb1YYP+RRg/5FHzen60fN6f rQIMH/Iowf8AIo+b0/Wj5vT9aADB/wAijB/yKPm9P1o+b0/WgAwf8ijB/wAij5vT9aPm9P1oAMH/ ACKMH/Io+b0/Wj5vT9aADB/yKMH/ACKPm9P1o+b0/WgAwf8AIqC6lkt4hKsLSoD+8CDLBfUD+Ijj jrjOMnAM/wA3p+tHzen60NaANjdJoklidXjcBlZSCGB6EHuKdg/5FNSNYlKxxqikliFGBknJP1JJ P4075vT9aF5gGD/kUYP+RR83p+tHzen60AGD/kUYP+RR83p+tHzen60AGD/kUYP+RR83p+tHzen6 0AGD/kUYP+RR83p+tHzen60AGD/kUYP+RR83p+tHzen60AGD/kUYP+RR83p+tHzen60AGD/kUYP+ RR83p+tHzen60AGD/kUYP+RR83p+tHzen60AGD/kUYP+RR83p+tNUyln3ooUN8hDEkjA5Poc5456 D1wHYBcexox7GlyPU0ZHqanQYmPY1kX2n6hFqq6tpLWxmaDyLi2uSyrcKGJjIkAYxlC8h4Rt28g9 AV2Mj1NGR6mtKdR03df8P/X4brUTVzmo/D2oS61Z6xez2z3a3glkWIMqxQLbzRpCpP3yHndt5Clt x4ACqJLTw/d2XjEX0MkP9kLbXOyIsTKs88ySSY4xsJj3ckkM7D7u0L0OR6mjI9TXQ8bUe/a3y1/z sTyIwX8MxXsurDUAjw3eoR3kQXBIVYYo2VsjGGCOjAdUcjPJqCTw9qEWtXmsWU9sl214ZY1lDMss DW8MbwsR9wl4EbeAxXaOCCynpcj1NGR6mlHGVI9elvlp/kHIjl7zw/qurzpfahJZR3Mctt5FvCzM lvGlzHLN+8IBkZxEmMooXaAOrMani3whqGsTuNLmto4LpbiS7W4Zs+e1o9tGyYU8EOAwPGEUgZ3b uzyPU0ZHqaunmFWnJONtL6dNf+Gv66vUHBM568s/EGuWr6df2+mWNjNhbloLmS5eaIn54gDHHs3L kb8kjsMkEVLvwfJdpqN+07jV5rwXkCrdzLa74iv2cPGDtI2xRbyQTkttIwuOsyPU0ZHqaUcbUh/D 91eX9X1svuDkvuZ82nyyeJbHUgyeTBZ3EDKSdxaR4WBHGMYibPPcfgazpsuowW7Wtwlte2s6z288 kRlVGAKsCm5dwZGdOoxuyMEA1oZHqaMj1NYqvJOLXT/g/fuPlOem0S+8QTIfEMVkljHFLGLG2leT c7oYzIZcIR+7eRNgX+ItuJxtnsl8TwfZ7S6bTLmOPaJdR3OkkoGCT9nC7VY8jIkwCd2P4K2sj1NG R6mreKbXK0rdF29P+De/W9kHKZ8Onyx+Jb7UiyeTPZ28CqCdwaN5mJPGMYlXHPY/jlQ6V4i0/TTo 2m3enx2iq0dpfOjGWzj58uPyTlZSi4UOXXPBKkg7ulyPU0ZHqaSxUluk9t/JWX9bPqHKcnbaDqel HU9N07T9Jk0i7aNY/tVzIxijFvFBtaLyyJABGTgyDcDgkdak0/TPEGg3F9HYwWWo208sUiXF9qMi Tttt4ojvxCwLExE5zznoK6jI9TRkeprR46TupJO6s99bW1330FyHLx+DbS+vNS1HVbKyXUbm5iub e6gAeW1ZIYVG2RkB+WSNiARgg8jkrXR2f2v7KgvvJNyMh2gzsbB4YA8rkYO3JxnGWxky5HqaMj1N Z1cTOokpbLbysraDUbHL3Oi6rqes6yt9bWUelanYjT3kgvWM6Rr5+HCmLbuPnDjdhcdW6VegsdVu 9VtLrUxZQ/Yd4jks5GLXO5dpDhlHlp0by8vlgh3fJ821kepoyPU1UsXJq1ltb8LfitP+CLlKOj2T 6foWnWUkcMcltaxwskDMY1KqAQpb5ivHGecdau49jS5HqaMj1Nc05c8nJ9SloJj2NGPY0uR6mjI9 TU6DEx7GjHsaXI9TRkepo0ATHsaMexpcj1NGR6mjQBMexox7GlyPU0ZHqaNAEx7GjHsaXI9TRkep o0ATHsaMexpcj1NGR6mjQBMexox7GlyPU0ZHqaNAEx7GjHsaXI9TRkepo0ATHsaMexpcj1NGR6mj QBMexox7GlyPU0ZHqaNAEx7GjHsaXI9TRkepo0ATHsaMexpcj1NGR6mjQBMexox7GlyPU0ZHqaNA Ex7GjHsaXI9TRkepo0ATHsaMexpcj1NGR6mjQBMexox7GlyPU0ZHqaNAEx7GjHsaXI9TRkepo0AT HsaMexpcj1NGR6mjQBMexox7GlyPU0ZHqaNAFz9Pzoz9PzpP89aP89aq4rC5+n50Z+n50n+etH+e tFwsLn6fnRn6fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn 6fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn6fnSf560f56 0XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn6fnSf560f560XCwufp+dGf p+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn6fnSf560f560XCwufp+dGfp+dJ/nrR/nr RcLC5+n50Z+n50n+etH+etFwsLn6fnRn6fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+ n50n+etH+etFwsLn6fnRn6fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+et FwsLn6fnRn6fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn6 fnSf560f560XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsLn6fnRn6fnSf560f560 XCwufp+dGfp+dJ/nrR/nrRcLC5+n50Z+n50n+etH+etFwsG7/OKN3+cUuVoytHzATd/nFZmo62LK 4W1trC71K8K+Y1taeWGjjJIDsZHVVBIIAJy2GwCFYjUytYd9Y6jbazJq+jxWlzPcW8drPb3c7Qrt jaRkdXVHIOZXBUqc5UgrtIYQF1NasPtlrYXF1Ba6ncxCVNPmnj8/GCT8oY5xtbJXI+U8nFR2fiXQ dReBLHW9Nunnd0hWC6RzIyKGcLg8lVIJA6AgmsOXw/q9xeXCyLYJa3+oWmp3Mi3Ds8EkIgzEi+WB IpNuPnLIRvJ2/Lhqdl4L1G206yt3ntC8FloluxDtgtZ3DSykfL0KnC+p6461QjqLPxLoOoW91cWW t6bcwWib7mSG6R1hXBOXIOFGFJyfQ+lRzeLPDdvZ215N4g0qO1ut32eZ72MJLtOG2sThsHg46Vx+ g+H/ABHeeF9DknW30u4sdESyiiW4k8yZXNuzrIfLVrdisGzK72UyFgcoN2h4W8J6lpXiOXVbz7PH HJ9p/dDUJrx18xLNVzLKoZv+PZyc9NygZHQA7Br+zTzN13AvlSpBJmQDZI+3ah9GO9MDqdy+op8V xDcIXgljlQOyFkYMAysVYcdwwII7EEVxGheFZbG/0ewn3iDT9Ms3vQmfs9zdRI0URXIw5AVmYthg Y7QjG3FdfpsEttauk8VpE5uJ3C2qkIVaVmUnP8ZUgse7FjSYFwHINV729jsLC4vJQzR28TSuFHJC gk4568VYyKpavatf6LfWcRRZLi3kiQtwAWUgZ9uacbXV2Kd1F23GDVWWJnuNOu7dywSKJzEzTsc/ KgVzzxk5wAOScAkRSa8kYijNjdm8klEX2QeWJFJVnBJL7SpCNyGPII6ggJJodnbiKbS7S0tbiGUT KqRiNZCFZNrlRnG12wecE5weQatxoc+o31ve3jpFIJV8yO2uHXbGkcwUK4CsWLSkk/KMcdstuvZP V/1+Jzt1lot/662/T7y2deRjbJb2N3cyzLKTHH5YMZiYI4Ys4GQzY4Jzg445qVNVaW58iLTrtyjK k7AxAQMVDbWy+SQrKTtDDngk1kT+H5y9krWWm6jDaJNGBeOQX3mNhI3yMN+Vbce5O7jJUXLrT7q+ v7eeSy0+CSNom+2JMXmUKQzIv7sfKfmT7w4YnHO2m1T6ef8AW/YSlV6+X5a9O/8ASLen6q1/c3EB 067tjbtskaYxYDbVbb8rsc7WB6Y981f3c1UsrV7a71GV2Qrc3AlTB5AEUac++UP6VcytYVGr+6dF Pmt7wm7/ADijd/nFLlaMrUfMsTd/nFG7/OKXK0ZWj5gJu/zijd/nFLlaMrR8wE3f5xRu/wA4pcrR laPmAm7/ADijd/nFLlaMrR8wE3f5xRu/zilytGVo+YCbv84o3f5xS5WjK0fMBN3+cUbv84pcrRla PmAm7/OKN3+cUuVoytHzATd/nFG7/OKXK0ZWj5gJu/zijd/nFLlaMrR8wE3f5xRu/wA4pcrRlaPm Am7/ADijd/nFLlaMrR8wE3f5xRu/zilytGVo+YCbv84o3f5xS5WjK0fMBN3+cUbv84pcrRlaPmAm 7/OKN3+cUuVoytHzATd/nFG7/OKXK0ZWj5gJu/zijd/nFLlaMrR8wE3f5xRu/wA4pcrRlaPmAm7/ ADijd/nFLlaMrR8wE3f5xRu/zilytGVo+YCbv84o3f5xS5WjK0fMBMe4ox7ijB9KMH0pDDHuKMe4 owfSjB9KADHuKMe4owfSjB9KADHuKMe4owfSjB9KADHuKMe4owfSjB9KADHuKMe4owfSjB9KADHu KMe4owfSmSxtIgCyPGQyncm3JAIJHIPBxg98HjB5oAfj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj 3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+ lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYP pRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGP cUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj 3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lABj3FGPcUYPpRg+lAC496Me9Jg+tGD6 07iFx70Y96TB9ax9Q1m4sbq7VLSOW3s7Vbq4kacq+wl8hF2kMcRnqR1HTrVQi5uyRE5qCvI2ce9G PesUa7JJr82lxpYBopVQrLe7ZnBRXLLHsOQAx787T0plp4j8+Oad4rYRJtXyornfcLI7BUjkj2gR sScHLYBHXAJGnsZdv6ZHt6d7X7/hubuPejHvWPLrU9kyQ31nHHcSPGI1hnLoyNKkbHcVBBUyKSCO cjBPO0v9ant9Wj062s45ppPL2tLOY1+ZZmOcKx4EPpzu7YpKjJ9ButBdTYx70Y96yk1mS4hhS3tl e+kaVfJeXai+U+yRi+0nbuwB8uTuHAGcVZ9fu7fU49Okg0uK6aJHCzaiUDl3dQqfussfkGeB94Ch UZPoJ14LW5v496Me9ZVrrEl3q8tmkdoqxMwdHusXChTjcYtv3ScEHdyrA98VXn8SeRf6laNafvLb att+8/4+ZCI/l6fJ800S5PHz57HAqMm7WB14JXb0N3HvRj3rFs9bu9VtIZ9OsYHJijeYT3JjCM6K 4QEIxYhWBJwByMZOQKdz4w+z2GozGxzcWs8iRQed/ro0Lgvu24XiGY4PPye4y1Qm3awniaaV2/wZ 02PejHvVS7u5I7y0s4AplnYuxYcJEmNzdsnJRevG/OCARVWLWZJFhu2tlXTLhkWGcS5c7yAjMm3h WJGOSRuXIHzbZVNtXRbqxTszVx70Y965228VR3H9mym2uUhu7V5XVbSaR1ceUQBhclcSH5sYOBg1 qDWdPaeOJbjfv24kRGaLLAFQZANoJyuATk7lx1GW6M1uhRr05bMvY96Me9UYdZ0+40qTU4bjfZRo ZGmCNjaF3EjjJwOuOhBHUEVENRvUkSO5sY4WuNy2o+0btzhS2yTC/IcAnK7x8p56bl7N9h+1jpqa ePejHvWLa63dy2xeaxgSaS4e1too7kv5kiM4bcSg2qPLZs8nAPGcA34buaMQpqEcEE88pjiSGVpQ xClupRcHCt27decUOk1uKNWMti3j3ox71zukeJJ9ZgD20ektM0CzLAupFpFyVyHAjyuAeevOB3yH 2uualeRaeYtNtBJe27XSK14wCxjy8ZPlfePmdMY46mqdCadmvxRKxNNpNPfyZv496Me9YA8V2wuY TLC0VjLYJeC4Y5ILK7hCgB52Ru2c/wAOOpGZ4dblbwvc6vPZeTNbpO0lt5obDRMwK7gMdU64/Oh0 ZrdDWIpvZ/0jYx70Y96wpfETWN5Ha6lbRwys6AmGYyrtdJSuPkBZi0JXaB/EuCScVcW+uUvLSO6g WGO7VlRd25kkGWCsRwSUBPHClCMtuFJ0pLdDVaD2Zo496Me9Jg+tGD61lc1Fx70Y96TB9aMH1ouA uPejHvSYPrRg+tFwFx70Y96TB9aMH1ouAuPejHvSYPrRg+tFwFx70Y96TB9aMH1ouAuPejHvSYPr Rg+tFwFx70Y96TB9aMH1ouAuPejHvSYPrRg+tFwFx70Y96TB9aMH1ouAuPejHvSYPrRg+tFwFx70 Y96TB9aMH1ouAuPejHvSYPrRg+tFwFx70Y96TB9aMH1ouAuPejHvSYPrRg+tFwFx70Y96TB9aMH1 ouAuPejHvSYPrRg+tFwFx70Y96TB9aMH1ouAZozS7h60bh60fMBM1lXfh+01DUpL64VWl8qJIH2D fA0bu4dWOecsOMY+XnIOK1tw9a4DxGuqXvjLUbXTE1V7mPSrZrKW3v8Ayba0naS5AkmjMiiRcqhI 2SZCEbT0NQk4u6ZM4RmrSR1Vvp+pW19POt/aGO4lSWZDaNkkRojbT5nAOzIyDjPemPos97MJtSvI 5JI0Kwm2gMWwl0fcdzPkho0I7cHIOa5TUvGOq2Om/wBs3dtaPbwanqEMMEMkiNIltFenLnOMt5KD aVYDBbqVEehrGr+K9MuLHS7dLTUtQuknuDNa2IVY4ozEu0xyXSZJaXO7zOMAbDksNPaS3M/Ywtb9 Wbc+jT3i+dfXkb3ce3yHigKRx7XSTlSxLZaNM/N0UAbTkmKXw6NQvIrnVJba7dXQvELbEToiShRt Zm5zMTnPYcDrU2i6rcap5U8psY45tPtrkW8NwJpI3k3lssvytHwoRh94q/bFa+QaXtprRMHQpvVo yk0aS2igFncrHJaq0Vq0kW8JCduY2G4bgNowQQflXJPzbmf2dqy3rXkeo2QmkgSGXdZOVOxnIKjz QRxJg5J6fhXnmt6vrGi+LPFl3dX93aXS6OWsfJjge2kKLeyQqcqZAQiM/OBvSUElTGp7TS2i0XxN qmmG9nFglpZTRi9vHmImmlnjIDyszfN5cYC5xnoMscv2kg9jD+mzXNhdz6jDPdXUDwW8rSwRxQFG BKsg3MXII2uegHODx0LotLiS9nuZD5jPdC5j6jy28kRevPAb/vr2zXFeJo5bG613U9HvtSik0jTL q9ndr+aWI3LxOYoxE7tFhRukZNoK7oCPlJFdBokR07xVqukw3F3JZxWVpcot1cyXDLJI9wrkPIzN giJPlzgYJABJzPPIr2cf1GXHhDzNEGmRXNtsaBI5WuLTzf3ixiMSp8w2NtA7kcDGOSb0vh+KXTLq 2Mv76ZLuNZtp+RZ3Lkbc4ODt/wC+e2a5R9a1DSfhQ+u2Nhd3Goajpkuqz3cJhK28zxeYGYSOCyJk KoAchIlU5wM7GvahqFzoVpdCDUtGkTWLBGhkkh3TRtcxIwJjZxsIc8BgTtwflJDW6031IWHpq9l5 G7eW8v8AaVlfQJvMW+GVcj/VvtJIzjkMiHr93dwTioItGkjWG0a5VtMt2RoYBFhxsIKKz7uVUgY4 BO1ck/Nu52bV79PF97d3UO/StO1C302Lyb6SNleeOH5mgC7ZfnuFBLv8qrlVDAl8+STWNCuo7HUN SnuN0tvcXBtp3kkkKy7UILYELXMzRIIP9UqRzYYckSptKyKdOLd2dlp+jSWMtmWuVkjsrd7WFRFt Plny9u47jlh5fJAAOegxzn2XhKCymtX32kpiWHfLJZK026NFQbHJOxTsXjBIy2CCQRC+pQ3Gt+Ht Xslkie+uJ9Ku4pAAR5cczlWwcM8csDKDllAkl253Bq6vcPWn7aa67i+r03a62KFtpkMWgQ6RO3nw rarbSHBXeoXaehyMj3psNhcNcwy314tytsxa3Cw+WQxUrucgkM20kcBR8x46bdHcPWjcPWo9pLXX cv2cdNNjLXSQlmsaXGJ4rqW6gl2ZCO7ucFc8jEjKeRkEkbTgixDFf4hNxewMySln8m3KB02kBcFm IO4hsg9sYq5uHrRuHrQ6je7BU4rYq6bajTtKs7LzPM+zwJDv243bVAzjt0rLPhexntdNtr4R3cNl ZNabZIvvEiMbwc5U4Q9Ofm68Vvbh60bh601VkndMTpQklFrT+v8AIy49JDXMk17cfaS6QL9zYcxS O6McHBOWXOABlTwAcCKXRZH0y6sBfbYblLtWHlZ+aZywbrn5QzDHfPatncPWjcPWj2su4vYwtaxk 3Hh/TpY7WGG3gtreC4Nw0cMYQM3lsgIK42sNwIYcjaMeocbW5lvrEXEnmxWe+Xz9oVpJCGRRgeiM xbgAkqRgZA1Nw9aNw9aPay6sfsodEJmjNLuHrRuHrWfzNBM0Zpdw9aNw9aPmAmaM0u4etG4etHzA TNGaXcPWjcPWj5gJmjNLuHrRuHrR8wEzRml3D1o3D1o+YCZozS7h60bh60fMBM0Zpdw9aNw9aPmA maM0u4etG4etHzATNGaXcPWjcPWj5gJmjNLuHrRuHrR8wEzRml3D1o3D1o+YCZozS7h60bh60fMB M0Zpdw9aNw9aPmAmaM0u4etG4etHzATNGaXcPWjcPWj5gMVyWYFWUKcAnHzcDkc/hz6U7NLuHrRu HrR8wEzRml3D1o3D1o+YCbaNtJuPrRuPrU6D1F21kX+saTpGoHzop5L6WJfM+x2EtzIIwW2b/KRi q5Mm3dgE78dGrW3H1rlfFNld3VwTpel6l/apt9lvqdtdpDBFJlvL89fNVpURju2mOQYZsA7mBatc TudKthZp5e20gXypXnjxGBskfducejHe+T1O5vU1h6tovhXRvCt89x4d01tLskkv5LSOyiKlkQ5Y IQF37RjPHpmub1fw9cauninTLBvPtbSK7e0t8BNt/dW5LJuJBOBLI+Sdp+2Y48oYr6/4Hvfsmsxa JpEEPnS3EFssBjiH2R9NZREORiM3bbtnA3nfj+KrEemC3hFw9wIkE8iKjyhRuZVJKgnqQCzEDtuP rVaLUIJNaudMVZPPtreG4diBtKyNIqgc5zmJs8dx17cI/hqZ5zcW3hT7LoQlgM/h/Fsv2oqlwGfy 1cwnLS2x+ZgT5GcZVM2NH8OajaTXL3ek+dby/YTb232lU+zql/cTKnBwPIjkiO0ZU7NikilYDp7L wvpGneIr3XLOxggvbyJYpnjhRc4dnZsgZ3MWG4k87E9KsWmhaRp9mbOy0mxtrYyrOYYbZETzFKlX 2gY3AqpB6jaPSrxY5pSTgUrjsZl7qmmaJdiOWKYXN7umK2llJM8uwIjOwjVjwDGuT2wO1UNN1Dw3 o1zDo+mabJYNdYmWC20iaJGyEBc4jCjG5AxP3eA2MVJquiHVvEenTzfaVtILS5R5Le7eBg7vAVGY 2ViCEfjpxzzirB06WPxHpc8Su1pbafc27SPIXYMz25UEsSzEiNuTnpycnlXZso07K+9n+tjM03VP DJ0XUtksz6XNHPqEkV5ZyKjQv88xQOgMqEszHG7HmY4BVat3974Y1xNGsdRhtL9NVU3Onw3Vr5iy bU3FgGUhSEbvg8kVzcfhXWrfwgtpL51/dSeH30+KGR4lNlK0Q3ICoUOjMka5JZlKLyQzFdtvDH2P X7S/tF3q2pNcSc48mIwXHHJ+bM08jZ6/vcfdUYSlIuVOir2ff+v6/wCCbkmk6dNqkOqS6faPqEKb IrtoFMqLzwr9QPmbgHufWpJrG0uPtHn2kEv2mIQT741bzYxuwjZ+8vztwePmPqam3H1o3H1p8yOa xRh0a0g1C3u4k8v7NaGztoUVVjgjJUsFUAddkY5yAIxgDLZv7aTcfWjcfWi6HqLto20m4+tG4+tL QNRdtG2k3H1o3H1o0DUXbRtpNx9aNx9aNA1F20baTcfWjcfWjQNRdtG2k3H1pqLsZ2BbLtuOWJAO AOAeg46D3PUmj3Q1H7aNtJuPrRuPrRoGou2jbSbj60bj60aBqLto20m4+tG4+tGgai7aNtJuPrRu PrRoGou2jbSbj60bj60aBqLto20m4+tG4+tGgai7aNtJuPrRuPrRoGou2jbSbj60bj60aBqLto20 m4+tG4+tGgai7aNtJuPrRuPrRoGou2jbTBKpkMYdS6gErnkA5wcfgfyp24+tHuiF20baTcfWjcfW jQeou2jbSbj60bj60aBqLto20m4+tG4+tGgai7aNtJuPrTVl3MwG7KnBypHYHj169v6UaAP20baT cfWjcfWjQNRdtG2k3H1o3H1o0DUXbRtpNx9aNx9aNA1HZWjK0mD6UYPpVaiFytch4g1/VtP8Qtax XEFhpq2kUv2y40a4uoy7PIH3yxuqRKiqhJcjAbJIArrsH0rI1jw+mtb45r++htZojBdWsLp5dzEc 5VgykrkMwLRlGIPJ+VdogKGr+JfOvrHTPD2q6VJfS6gbO6Lj7T9mxDPJhkSRSGzDjkjvxxUdz40i 0bTbmTVoo2uLK9FhO0VxDBHI5iWVXQzyIACjqSu4kHIG4LvOxrWijWRZMt9d2M9lcfaIZ7URlg3l vGQRIjKQVkbt6VTfwpAPJmtdQv7TUU8zzNQi8ppp/M2b9+9GQ5MUfRRtCKq7VG2qEFv4x0u7iSS2 8+XzZbZLdAmHuEnVXSVEJDGMKXJOBjyZePkNR+IrzXrXVtHg0u802GDULg2rC6snmZGEM0u8FZkB GIgu3HcnPamad4atdJ1bSyWhNtp+nRWFgZCPOldQ4LPwAzLGPkK4IEtxxhq273Tob66064lMgewu DcRBSMFjFJFhvbbIx4xyB9CAc/q3xC0bRdWvtNvBIJ7S3knxHNA7SbITMVEYk8xTsVjl1VeOvK5k 1HxtBp1nPc/2Nqs621ob65REiR4LfL7JGWSRT8wichRlxtwyqcCo9S8BWWpiWCXUtSjsHe5kFlGY fLSS4jlSVwxjL5PnytgsQC3TAAEfjLwvqOu+cmlXP2P+0LQ2OoTeeozD82z920L79vmynCtETuxu 6FQCnrHxQ0q1GtWli8b6hZW92YPMkjZZJ4I3ZkMayeaoHlv8zKqnbw3zLu6y11OW4ltYp9LvrSSe KWUiZUYRbGVdrsjMoZt+5QCchW6EYrPbwlZy/bIJru/k0y688vpvmqkIabd5pyoEh3GSQ4ZyoLZA G1dt+102W3ltZZtTv7uSCKWImZo1Eu9lbc6oqqWXZtUgDAZupOaANDK1xl54rvl+Jtj4eto7RIDb ymWO7ufKeYgwN5kS7GLhVaQKMgMVlBx5eT2WD6VzOpeFJdU8ZWGrXOoXEun20T/6E3lqqyCSCSPa QgYrvh3nL53KoHyllKQyOXxLqUVvru+3tEntNYt9NtSpZ1CzC3CSP90sQbjcVG3ptDfxnT0LUbu7 bUrTUDBJdaddi2eaCMxpLmKOUMELMVwJQuNxztzxnAg/4RSBv7X83UL+X+0ruO9+byh9mmj2eW0e EH3fKi4fcD5YyDlt1/StJTSop/8ASJ7q4uZfOuLm42b5X2qgJCKqjCIi/Ko+7k5JJIxGhlaMrSYP pRg+lLUYuVoytRxyJMpaJ1dQzKSrAjIJBH1BBB9xT8H0o1CwuVoytJg+lGD6UagLlaMrSYPpRg+l GoC5WjK0mD6UYPpRqAuVoytRTu8NvLKkDzuiFlijKhnIH3RuIGT05IHqRUmD6UagLlaMrSYPpRg+ lGoC5WjK0mD6UYPpRqAuVoytJg+lGD6UagLlaMrSYPpRg+lGoC5WjK0mD6UYPpRqAuVoytJg+lGD 6UagLlaMrSYPpRg+lGoC5WjK0mD6UYPpRqAuVoytJg+lGD6UagLlaMrSYPpTEkDtIoVwY22ncpAJ wDwSORyORkZyOoNF2FiTK0ZWkwfSjB9KNQFytGVpMH0owfSjUBcrRlaTB9KMH0o1AXK0ZWkwfSmp GI41RQxCgAbm3H8SeT9TRdgPytGVpMH0owfSjUBcrRlaTB9KMH0o1AXK0ZWkwfSjB9KNQFytGVpM H0owfSjUB1FJk+n6UZPp+lO4WFopMn0/SjJ9P0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFo pMn0/SjJ9P0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFopMn0/SjJ9P0ouFhaKTJ9P0oyfT9 KLhYWikyfT9KMn0/Si4WFopMn0/SjJ9P0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFopMn0/ SjJ9P0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFopMn0/SjJ9P0ouFhaKTJ9P0oyfT9KLhYW ikyfT9KMn0/Si4WFopMn0/SjJ9P0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFopMn0/SjJ9P 0ouFhaKTJ9P0oyfT9KLhYWikyfT9KMn0/Si4WFopMn0/SjJ9P0ouFhEYvGrFGQkAlWxkexxxTqTJ 9P0oyfT9KLisLRSZPp+lGT6fpRcdhaKjSUOzqA+UbacoQM4B4J6jnqPcdQafk+n6UXCwtFJk+n6U ZPp+lFwsLRSZPp+lGT6fpRcLC0UmT6fpRk+n6UXCwc+n60c+n60nPvRz71NwF59P1o59P1pOfeuP 1m81l/FlxZWT60beGxt5tmmiy4d3mBLm455Ea42+hz1rehRdaTSaVtddEJux2PPp+tHPp+tcRrdz rGnXXiiaHXr0x2Gj/b7eBorcosji5ABPl7iq+UhGTnjktmq8+r6tLpGpxaXrN6dtzY2sV/fWKJPD NLOqyIYjHGCojeJhlOfMPzH+Hqjl05JNSVnbvpe3l5r9Lk853/Pp+tHPp+tcfouu6tqniy3M6/Zd PlsbhfsWUfFxBJCsjeYADw8skWOh8rcMhhjC1HxJ4lh0TXVhu8XPm391Z3nlx/6Pb20sivHsIw+D HCu48/6TkZ8s04ZbVlLl5lfTr3v5dLO9u2lw50em8+n60c+n61xH/CZQ/wDCf/Yv7asvsv2n+y/7 P82Pd5vleb5+7733v3Gzpu75+WqFp4k1vVPAFprMd3NFcn7FatDBHD57ySSwrJIRINiswYmNeF2u HOdwCCyyt7rdlfl3/vXt08tQ50ejc+n60c+n61yU0fiNNNtWim1xw7SNOoFh9sjPAReQIfLwHJxl 8lOcbgL15cX154a0+50S5ubqOZY5HuIViW5lhKZDIJQIwxbYSGAG0vgA7axeEtb31q7b7eunXp3H zeRv8+n60c+n61xcs1/dDw+bPxHq0SXd5LZXIkhtfMDRpcM2f3RXcrxBMr8pC8ZzuNv+2L//AIRr 7X5/7/8Atz7Jv2L/AKr+0fJ24xj/AFfy569855qpYGSsuZau3Xu128mHOdTz6frRz6frXlZ8Ya9b +CLN57/OrG2a7a48lP30UljcTxNtC7V2yRFMdT5OSMPg6Wq+IdZg027tF1F4dR03StQe5lSKMmSe 3+ztHJgqVAeOQMVGQBKVzuXI3eU1lNR5lq336ddtv80T7RHoXPp+tHPp+tee6l4h1nRm8ULJqLzQ wwSQafLJFGGiuYrJJ8kKuGMgaR+QFXysfxgVqjWGmuoL671bULGCTUJLKG1tbQSQsY5zCPNkMTFS 7jruQYYAcqWOUsuqKKldNPa1+19rX/4Z+V3zo63n0/Wjn0/WuL8deLBoM9tBDq1tZTQwS6jLHI8e 66SIqBbANyplLNhxkjyzgHnFHUvFeo2reKLqHUElsDBImlSRqjLDMlklwMEA7w4eRst8o8rHO8Cn Sy2tUhGa2eq+TS7ed/Rd9Ac0j0Ln0/Wjn0/WuAg8SatCLqG6u98k+sAWUnloMW66ittLDgD+FSh3 Hk+dx9wmtK11TUf7H0vxLJevJDqLWobTiiCKJLh0RdjBd+5d6kliQ2Gwq7hsUsvqR3a3svN9lp8v VO4c6Ot59P1o59P1rgNW8SatbfDnQtVhu9t9dWLTTS+Wh3ONPmmzgjA/eIrcDtjpxUkvijVLK6st PklSS9iWSyujJGNrzme0iinIXHBS4EuxSB8+0kEZDWW1XazWra+6/lt/mg50d3z6frRz6frXH66m s6QmmQ22tazfSXt8IWEcdkJQggmchN0apyVUnd2XjrzUuNZ13RtawZLnULWLT7cNaXXkRym5uJJh GWeNdud8ccOF+UeZuJwpJUcBKcbxmnf/ADt1S66Bz+R3fPp+tHPp+tebaLf+JtQ1M6bcatq1wbZT HLdWEFlGu4Xd1EZJFlUkDbCnCA/dPUnm1B4k1aEXUN1d75J9YAspPLQYt11FbaWHAH8KlDuPJ87j 7hNXPLKkZOKmm7paX6/L5+moKojv+fT9aOfT9a5bSm1iC48RsdRvdXk0+UwWtpOLeISt9nilGWSN cMWcrknAB5HGa6g5z3rjrUfZO10/TzV+1+pSdxefT9aOfT9aTn3rP1O1vb7yrWGc29o+ftUsblZi vGEQj7u7nLg7lAwuCwdMLjIP7ZOoah9i0ZoLjyJdt9c7t8dvtPzRcHmY4I25+QfM38CybHPp+tRQ QRWtvFb28KwwRIEjjjUKqKBgAAcAAcYqTn3ouAvPp+tHPp+tJz70c+9FwF59P1o59P1pOfejn3ou AvPp+tHPp+tJz70c+9FwF59P1o59P1pOfejn3ouAvPp+tHPp+tJz70c+9FwF59P1o59P1pOfejn3 ouAvPp+tIwJUgZUkdQeRRz70c+9AC8+n60c+n60nPvRz70XAXn0/Wjn0/Wk596Ofei4C8+n60c+n 60nPvRz70XAXn0/Wjn0/Wk596Ofei4C8+n60c+n60nPvRz70XAXn0/Wjn0/Wk596Ofei4C8+n60c +n60nPvRz70XAXn0/Wjn0/Wk596Ofei4Bj2/SjHt+lG33o2+9Fn2GGPb9Khjs7eO+mvVjxcTRJC7 5PKIWKjHTgyP+fsKm2+9VHi1L+1IpIru0XTwuJYGtmaVm55WTzAFH3eCh6HnniotoTMrUb3wlLql 7pd/qmmrqF/AlhcWj3qpLIh3bE2bgQT5zYwATuHtWpd6PYX1ytxcQbpV8v5g7Lu8uQSJuwRu2uuR nOMsBwzA4OmaPqDeKfEF7/ampWVu2pxOtskUPlXCi1twTl4y5BKspKsPunGCCa5dI/EM1nYxWs3i CC+dLVdblYTHZdG6ttzQ+aDHsC/aifKBi243ArtrVVZraT+/+uyJsj017OB7+G+aPNzDE8KPk8I5 QsMdOTGn5e5qpNp2lJp0ukTLGltqLzo0LSkGZpd8kgU5zk5kbA6AHGAOONns9ch8brHHqGpR28Nx bpZRLbXM6vahI/M3zGYQZJ88Eyq0vdckxisuKxvbtLSbUo9cu7Oz1BJrrUo2v4Jpybe4QmO1P7yH DyRA+TlGD9lVlRKpNWs9h2O61OXwxolnFaatfWNhBNcm7jS7uxFvlEwmLAswJxIQ2BxyBjHFSy+F dGlsYbM2rpDDBFbp5VxJGwSJleMblYMSrKCpJyMtg/M2czxHa69L4q0y40FrSOeLTL5fMvbd5ICx e2KoxRlKFipOeeFb5T25fULLWYU0uz0u51nT7Kz0yG20+M2E80v2mNnRxJ5MscWRth+abdC2cqdm 8mlXqx1Unvffr39RWR3Z8MWDQJCbjVtiMzgjV7oNkgA5bzMkfKMAnA5xjJzbudIs7mwhscTW9tDt 8tLO4kttoAwFBiZTtA7dOnHArhbj+2v7U1nyP7Vu080Ge8X7Xb+Vb/aYw8EUDfJIwgEm2aD5zt4A dgz2NMvb7TNYS+lTXH8OD7TDarJBc3E3zLalTJGQ0330u8NIOAcAhWQEdeq7NyenmFkdlFo9hDHZ RpBgWUrTQEuxIkZXVnJJyzESPktkksSeeag/4RzTPt/2vypt3m+d5P2mXyPMzu3+Tu8vdu+bO3O7 5vvc1wmg2viQ+FLq8vrjXDdD+z4mhleQOtuYLM3bIv3zIQJhkZcMrbMOzbjWYdVlurX+xr7XLXTx aL/Z/mWd9cTNc+bLv37pUx/yxx9qzGQeMKHylWqJ3Un94WR2l14P0G9trC3uLDfFp9tJaWy+c48u KSPy3XhucoMZOT3BzzVLVrPwfqf9pavqF5abY4TpV9dDUDEsaeYGMLsrgKdxAIOCd2DwcVBoH27/ AITLVPO+3XcP70/bJvtNvHF+8ASBYJP3UmFBxNF1C/MAW3Py+peDby68K+IpVhnEdx/a08lgFObm 4E1x9mcR7fn3LJuz1JitivC1axNZNNTem2r6u7/HX1DlR3914V0a+0m80u6tXmtL1o3uFkuJC0jI qKpL7t2cRJznnGTkk5ku/DmmXt+t5NFN5oljmKx3MscbyRkFHeNWCuw2rywJwqjoBXnnii48THVd Tk07+1YbiWK9hNrb2146qi2s3kyJNvMAZnSFgI0Vwz7SSQ+7Y1i11HS5dR0yx/tVtJkitH+1PLeX b27lp/MZSkgnf/V26FEcbfM3EY3bksRWW03978v8l9y7BZHcpZwJfzXyx4uZokhd8nlELlRjpwZH /P2FZUng/QZdBuNEewzp1x5Xmw+c/wA3lrGifNuyMLFGODzt56nPm+oXmrxeDNRutauPECGDTLn+ y57WK8tyJUluQHlCHeo8tbUg3BPGTknzCbmpw+K/P8Qyx32q/bvK1DZb29nc7fK2S/Ztkpl8jd/q CPJTzd3B/wCWhqY1qkHeMmtuvbb7unYLI9Dn8N6Tcw2sM1pujtb46jCPMcbbguz7+Dz8zscHjnpT 4dB06DUjfxwuJtzOqmZzEjtnc6Rk7FY5bLKATubJ+Y54nULLxJp81+ugvqrzpdzWdl588kyGE6e0 yEmUlT/pRA8xuR9zdt+Wq+mabqt3c2Nq+o65caVJqC+cRFfWJQC2uS2XmmafaW8jPKx52hcsXp+3 q2tzP7++/wB4WR2H/CL+HpJLixKPLmAq1m97K6QRSBk+SIviIFRIilAuBuUYGRU15p/h8+Iori+F qdVvrN7GOOeXm4gB3ugjJw4GcngnB54rmfDdjdReMGu9Vj1UMYns7GQtOUZIbm8A87Hyt+5eEq83 3t2VJbJqv4otvElzrmq6xY6NBPHpH2b7GZLiRJ28rE8/2dRE3+uV/IOGGfLwcjgN4is9XN/ewsjr G8JaVJGqSPqb7JRMjvqt0zo4VlyrGTK/K7A4IznnOBV6w0iz02RpbcTGV4lhaSe4kmdkVnZQWdiT gyP+eOgGPPdXstftfD17fae+uNqd1d6vDIonnk2whLswFIySsfzJb7GQA8qAfmwdDU7K+0zWHsYn 1x/Dg+zTXTRz3NxN8y3QYRyAtN99LTKxngHJAVnJUq9Wa5ZSbXqwsjpH8I6O9y9wiXsEr7t7W2oX EG7dI8hzscZ+eWQ89NxA44qefw3pNzDawzWm6O1vjqMI8xxtuC7Pv4PPzOxweOelcJc3uv6foOu+ cmuM15pUsOj+TBPNIrLLdeUW2AtHJ5T2uWk2sSPmJZWxYubLxJa6c99pD6q2s3WoapDtnnkkjWMC 7NuRHKTHGu5Lfa2AMEDOGILeJrPeb+9hZHdTaPYT22pW8kG6LU8/a13sPMzGsZ78fIqjjHTPXmrp GTXmmsRyy29iujXfiC20ffObl7q21Secz4i8sBRIlwE2+byD5eQcjcVxoaSNZXxdYrfyalqEgt4x O8iT2cdni3G4lUJtrgvITwpLIX4LqnyZSk5KzYzs3vLaPUYbBpMXU0Uk0abT8yIUDHPTgyJ+fsaj s9U03ULi6t7LULS5ntH2XMcMyu0LZIw4BypypGD6H0rzzWrSL/hc2mSx2H9pzNE7tHeac5EGGtRu huGGwLGuZRjOHMi53TLtLwDxFosrQWGq6fNFFDDDZJpM0ItLDz4TOgDxbJZGjQZjAdSF2Irjc0k2 Q7nocOqabc6WdUg1C0l08Izm7SZWiCrncd4OMDByc8YNRza5o9vFbSzarYRx3UTT27vcIBLGq72d ST8yhfmJHAHPSuYvDqmp/DfxVA6315vtLmLT5Lm18q5uUNuPvRBEIbzDIgGxchVODnc2H4s8Kalp tsbrTRdzy273aaWtruZ7OE2N2wCbR+7PnSLGAvG2O3XqtFkFzv7TxDpF9evZ297GbhHKeWwKEsHm Qhd2Nx3W83AzwhPTBOptryA2Him01a/l0e0vobqWW68l/LKo7eZrDx7i3yld727fN8vzxnuK2Esr nUNasrWwfxGnhx7uLzTPPewzBxBdmTLyETCPIte+wtwOd1FkFz0OaWG2QPPLHEhdUDO20FmYKo57 liAB3JAqTbXID+2B4RhjH277VFraQqTvMptU1EKCx+8y+QBljncuSSckmv4OstT0/wD4R3z31Vvt miNNqX26eabbdL9n2g+YT5bfPN8q7c4OQdowWQXOrj1TTZkmeLULR0huPssrLMpCTbgvltzw+5lG 085IHerm2vLJNJ1LTooXt9Pu3i1TxHm6hjhYmNo9UM0dwQBwjQhg0hzkLABwCaj0qHxXFYzXVzfa rPd28UN1qNqtncx7pY5opJI4nklZZGZFnRVt1WJt3zbVKUWQXPV9tU5NU02HVIdLl1C0TUJk3xWj TKJXXnlUzkj5W5A7H0rnPD1r4kg8QrFq9x5kNvaSyyPG8hilkuHjfapbr5Tx3CgdUieEclmqne21 yNE1rw8bO7fWtQuLma1u1t3aLc7s0EzTgbUMKiMfMQ6+QAgb93uLILnd7ar2d5bahA01rJ5kayyQ k7SMPG7RuOfRlYe+OOK4g2upxaZ9pv7jXJLabW7sXqRPN5sVmslz5IiWL94FLmE5TLFSAT5agLzc Fl4gSCNLK51mwtN90+mqbC7mleZr25bMn72MAlDbnN1lDuzwPMyWQXPY9tJtrz26tdUh8O3N1cah rImm1i53W/lXUhe3WefyoUNuPMhQjawlAJxtB3JtSuo0QTfaALi31K1n/sy08yCeczwRNmXKrISS 8oPDtnkCM96LILm1j2/SjHt+lG33o2+9TZ9hhj2/SjHt+lG33pkbxzKWikV1DMpKnIyCQR9QQQfc UWfYB+Pb9KMe36Ubfejb70WfYAx7fpRj2/Sjb70bfeiz7AGPb9KMe36Ubfejb70WfYAx7fpRj2/S jb70bfeiz7AGPb9KMe36Ubfejb70WfYBgYmVk8pwoUEOcYJOeBznIwO2ORjPOH49v0o2+9G33os+ wXDHt+lGPb9KNvvRt96LPsAcUcUmKMUtQF4rlNY8Xy6f4pXQbaPRhO9vDLH/AGjqptWmaR5ECRqI nLkGPn/eHFdVisG80XWB4huNV0rVLG2+0WsNtJFd2Dz/AOreVgwKypjPmkYwegprcTGT+KJl8Ny6 pb2Eck41M6dHBJcFFZvtn2UMXCEgZ+b7px0560HxRNDo2qT3NhGupafcLZm1iuC8c1xIsZhRJCgO GM0SlmUBSTngbjTfwbeXOn3Wk3uo2NxpE2oG+Fu2nnec3guWjdjKVdT8yfcHUHtgyT+BbSS3t9Mh uZLbQ4L0Xq2FsXh2tiRiiyRspCeaySqP4WQgHaVCWIkHjS3g06wv9Sg+x2s0VyLp95k+zXMAJkhw q5fAiuPnHB8njO9cmu+K7jQdF0e7vLOxtLq/lSGaO/1EQQ2rmF5GDTBGBwYygwOSRRB4MitNMutO tr6cWsuqwalEszvMYtkkMrpudyTveN2JzwZScHHOhr2k3mptpk9hewWl1YXZuUae2M6NmKSIqVDo ekpOc9qAObX4hTXGpW1hb2ujRTz28csY1DVzb/aGeWWIfZ8RMZUJi3K3G5ZEOBnFbn/CT/8AFX/2 N9j/ANE/1H27zf8Al88vzvs/l4z/AKn95vzt/h+9xWfZeE9Y0i/mvNL1qxSS6iAuRdac8oaTz552 ZNsybVLXDgKdxAA+YnJJ/wAK/tftX9of2jff2n/av9pfaPtU+z/W/c8rzNn+o/cZx93t2oAkufFe pJoN14ittJtJdDispb2GV75knmjWMup8vyiFD4GMvkKwJAbKC5ZeMdH1XxDBpOk6hY6hvtJrmSW0 u0l8rY8ShSFz97zSckj7h69qdz4U1J9BuvDttq1pFoctlLZQxPYs88MbRlFHmeaAwTIxlMlVAJLZ c3PEWmajNL/aekTbdSi0+5srZSqkLJO0JWVixxtQxAkYJIzgEgKQA8WeJf8AhGbWwl22P+l3f2bz L+9+ywxfupJNzSbGx/q9oGOSwo8PeJf7cupbfbYt5dpDc+fYXv2mF/MlnTar7FzjyOTjqxH8OToa jpn2++0m587y/wCz7trnbtz5mYZYtuc8f63Oefu475FObR9SXxU+r2Wo2kUE9vBb3NvNZtIzLE8r ZRxIoUkSkcq2MA+1AG5XFxeOJhe6IZrGM6frTyyQ3CyEGC3DxRQOy4JcyvNEcfKUEoDD5GatyHwn 4bt/s/keH9Ki+zSmeDZZRr5Uh25dcD5W+ReRz8o9BWPpvhHfZ22n6mu6z0/T7rRljB4urWQw7H3K wIYRxBW4XLliuFCkgFe38f3GoaLd3mnaJ9pvDqAtNNtPtYT7cjQrcJJvZcR5gYybW6bdpO44qxe+ N3j8+806wgvNItdKh1ee5a5aKRoJPNI8uMxnc22EnDMnJAOOTUl14Ggv/EUup3d/dmBriS6S3t55 bcpK0EEIffG4JKrDIPpMw7c07H4ZaXbPm4k+0NBFHFp0zR7prARXE00XlyOWPyiWNMHgiIZBB2gA uTahput+J5tOfQ7S+1LR71FjkmVX+zRtHFKZ9xUmMkttVRy7R8YCsyV/DPjLUvFWlm80608Pyube OX7PFrbSPEz4ISYLB+7O3f68rjHUjQsfC81nq13rC38Y1K8uIpbl47crHLGsMUbRshckjMbOhzlC +MkFw8nhfRtY0HTrPTbzVLG8sbO0S2hENg8MnyBVVmYzODwDkBRye3SgCPTfEWpXvgVvEb6PH58l kb21sbW5aZplMQdEJ8tSHJO3ADdsE9KjvvGtnb/2p9kEF79l0+O7tfKuQftkj5xCmActzb4xkn7T Hx8y7tjQtM/sTw9pmk+d532G0itvN27d+xAu7GTjOM4ya5+z+HunWf8AZ+x8/ZLsynhv3kK7PJi+ 9xs+z2fzdW+z8/ffIATeLNYXVbjToNFsXmXVRpsDPqLqr/6K1yXbEJ2/IFGBu+YnnABNe/8AiD9j XTVMOlW0l19sSV9T1T7LCkltKsLqj+W2/LMxXIUlVyQDwLE3gf8AtHVbifWLixv7GXVRqQs3sMrx atbhG3OwbA8ts7R8ynjkbZF8KalYXGnPo+rWkEenW81nbR3di0+23cwlUJWVCShhwGPJUgHLAswB qWep3g1w6ZqUMEUk1ot1bmFiwO3CzJkgZ2M0ZDELuEoAXKMTY1vU/wCxtHnv/J83ytowW2Iu5gu9 2wdka53O2DtUMcHGKy5NBbWdZMuvWlpdWltZC0RHhUx3LuySSuY2L4QNFCEBOQRJnI2tVxvD9nZ+ Zc6HY6Vp+ptEkC3ZsA2I12gIQhRioVQANwAwvpigCnZ+LYDpcF5ftaObl3+zrossupCVFwGceXEG wGO0nbgEqCcsBViLxfoc9/8AY4buSQ74089LeU2+6RFeMeeF8rLCRMDdyXUDkgVh33w+/tGf+0Ly bSr3U3lkkl+26X59p86Qp8kJk3KwW3iwxc9ZOPmAU07whqMV9f2kl1BDog1C0uIoxaqJpvs8NttY MjBI18yAAr5XRWxgFSADc1/Wr7Rka5h0yO4s4UDzSPc7HclsCOBArGSUnACsUBLoAxJO2xa6u1z4 l1LR2s5IhZW9vOs7OpEwlMg+UDJABiI5wSc8YALU9W0bWLvXINRsdUsYo7eLbFBeWDziKQ7g0ilZ k+YqQuSCQAwBAdgZBpt9Z+JdU13z47mCeyigjsYbfbLmIuy4kaQKSTLIOQo5XkYJIBoX6tEn2y1s I7u/jQxQgsqEB2XILnlUyqs2AThOFYgA8/D4r1K7uE0610m0fVN84cPfMLUrCYg5jmERZyGmRCPL GGSUE/IN2hLputXng6DT5dVjg1hreFLm9jjLKzjb5uApQgNhhlShG7IwQKpp4d1iL7DcQalpUN9Y xSWsHlaW62y27+USnlCfIYGFcEOABkbehABXs/HX9oxQ6haad/xKGltLeWWWfbOslysLR7YgpVlH 2iLcS4I+fAOBu0PDHiuz8Vfap9PnsZbSPYYjDeCSYq2eZYwP3WduVBJYj7wRgVGfZ+Bf7Oih0+01 H/iULLaXEsUsG6dpLZYVj2yhgqqfs8W4FCT8+CMjbc0HwvNpFxYtPfx3EGmWTafYIluY2WEmPPms XYSPiGPlQg+98vI2gHSVy/inxd/wjmo6fZ/8SpPtkU0vnanqX2ONfLMY2hvLfcx8zOOOFNaE3hPw 3cfaPP8AD+lS/aZRPPvso282QbsO2R8zfO3J5+Y+pqxNpnm+IbLVvOx9mtJ7bytv3vNeFt2c8Y8n GMc7u2OQCnbeKtMke1gkuYzPOkW6S2WSa1R5FBVPtAQJlty7QxUsHTA+dcxw+NdButOt7+0up7uC 4yYfstnNM8gAUsyoiFiq7lVmxhWO0kNxUd14XmuNUuJFv400+7vbfULmA25Mpmh8rZsk3gKn7iLI KMT8+GGRtz7v4fw3GjeH7Nn026n0ay+xI2p6cLmCRSsYZ/K3qVfMS4O44BYYOcgA0NW8a6Zp+m31 1aGTUHtrKS8H2aKR4GCxGUK06q0aFlwRk5wynB3DNjU/EJtvDqapYWck7zXEFvFDdrJaEtLOsILB 0LqAWz93kDjqKx5/h9DdSyxNeR29hJZGzdbC2FtPcKYPJHnsreVIFBJUeUNh27cAENsanoM2u+HU 0vWLi0uHNxBLOyWhWKVY51k2eWztwyptOWPUnHagCO38UxR2t2dWg+zXdpdizkgtd915khiWUCIK geT924JwgI2vxtXdVhPFGkyy2sUE088lzjakFpLIYssU/ehVPk/MrKfM24KODyrYx77wDZz6cmnW osU0+2u/tlnY3ViJ7eGRhIJFZNy7oz5rMq5BR+QSoVFIfA/2e60t4LixtEs9pd7Cw+yzPiVpTErx uFFuWbBiZXyMksXO8AGpF4v0OY4W7kAZ41iZ7eVFn3yLGrRMVAlQtJGN6blG9SSAwJkl8U6NDrC6 S95i/aUwrAInLM4WJiBgc4WeNjjopYnhWIw08CTfZbO3l1WNk0q3jt9LKWpUxqksMqmf5z5p3W0I O3y8jf03Arc0fwteWPiObXL/AFOC5upvP3pBaGFP3iWqDAMjkYFqO5zv7Y5ALg8XaO1u9wkl28Qd UjZLGdvtBYEjyMJ+/G1WbMe4bRu6c1InijSZpbWKGaeeS5xhILSWQxZYp+9CqfJ+ZWU+ZtwUcHlW xhzeBZrnQbHR7q8027tNLeM6dHdaaZUCpG8QFwpkxKdj5yvl4YBsY+WpIfA/2e60t4LixtEs9pd7 Cw+yzPiVpTErxuFFuWbBiZXyMksXO8AHXcUcUbTRtNRr2KDiqNrZvbalfzAoYLpklAydwkChG7Y2 7Ujx3zu9qu7TRii7Q07C8UcUmKMUtRC8UcUmKMUagLxRxSYoxRqAvFHFJijFGoC8UcUmKMUagLxR xSYoxRqAvFHFJijFGoDuaOaTaaNpp6iF5rhNbn16Dx1eXGjzSTmDTbWEWUrO0G6eW4UTGNe6yRwl m7RCXqcV3W00xLeFLh7gRRieRVR5Ao3MqklQT1IBZiB23H1poDzC38Tav4c8LSRWL3esvoz301+1 2BNK1vHdTpEWmeaPaSsMgyqSkbfuDgNuR+Lr+x26nq89iNIl1C/tNkNrIslult9obzGfe3mfLbHK hF5fIPGDsXOmeG9X1aXSL3QrG6ksolvB9otI3RftEkm4rkHDFomLcDOQck9LmqPpuh6NdapNZRmD Tkmv9sUS7lba7SMmcDewZ8nIzvOTyaoRydp4s8Svqa6De2UFnqc8sIhuZ7ZQiI8dy+TDHcSbv+PV lz5q/fzj5fnpnxz4oxcJBp1pdPpqTS3syIkUUipc3EI5luF8gbbYkt+9xuJwNuG6C08OeGtY8O6h a6XpNpplvc3D28/kWFuC7W87JkqyMjDcjY3KcA54PTQsPCGg6fYadaDTLScac7SWsk0CM0UjPvZ0 +UBCW+bCBQOAAAAAAcvc+MtetYr67Y6a8ECandpELZw3k2M/lNGW8wjfIGUh8YTafkfPEeoeOvEV rFq2oR6VAumwf2hFbPN5agyWyzYO7z98m5oDlBEhAYncQmW7x9J02RHR9PtGR0lRlMKkMsrbpQeO Q7DLD+I8nNRvoWjyXl1eSaVYvdXcRguZmt0LzRkAFHbGWXAAweOBQBx+p6n4kXxLpWhf2jYrfLdx TfaorSRYXjkt73928PnZbBt92d4GSvHy89Brhe71zS9Imnnt9Pu4p3kkgmaF5JU8sxxCRSGGVaV8 KQx8rrtDg6l5pOm6ik6X2n2l0k6Ikyzwq4kVGLIGyOQrEkA9CSRVcvpviEappd3ZR3MFpcLb3EN1 ErxyN5ccwIByCAJE6jqD6A0Ac/q2rXvh1NSt9LaM2mh6YNSnW+eW5lulZpj5aytJlCPJYbm8z74+ UBcGNfEPiS7+yiB9Ktvtmt3WmwM9vJNtjg+1EuwEifMfIVcA4GC2TuCp0i+GtBVLJF0TTQlg5ezU WqYt2LBiY+PkJYA5GORms+fSdB8TSy2Fxp8bwaPqZeS3khQwzTPBvJKkEMMXO7PB3jP1ALmgaz/a digungS+EtzCUQ7fN+zzNC8iqSSFJCnGTt3gEnqef1G+uI7zxJqiSeXNY3drpaTbQwtLVxBJPMN2 QrATszMflxBGWBCHPWLbWNk9kkVnHGUQ2tt5VvxCm0MUBUYRMRr1wMqo67RWes1injWdEF2t+bKB Jtse6KRGadotxAJUqY5+flB8wA7iVAAOX8SG90G5g0vQ9Ruwk72ssrXVxLdG2kN9bRplmffskV5g ULAMIjt2/OTJZ3usaPrWvXclzYz2p1uytbmFbV0eSSWCziLo/mEIoMgbaVY/KRu5yOwtdC0ex06f TrPSrG3sZ93nW0NuiRybhtbcoGDkAA56ipItJ02C3+zw6faRwb438tIVC7owojOAMZURoAe2xcdB QB5/a+PPFE2nW18+j2kaakltNYpcOkQ2y3EEe3KTSO42z/6zy02kLlDv2jrNdmvIrXR7Oa58tL27 S1v7u3Bh2qYnPyHJMe+RY4wclh5mFYOVYR3knhTQb2dZrG0gnunS7u5IbAsAVcsk07ohCAMGYSSE DKsQflJHQTwQ3VvLb3EUc0EqFJI5FDK6kYIIPBBHGKAPP/EUcttoPi6wtr7Uvs2k6Z9ttbhb+bzY bkxzFo2lD7nACxSbHLEeaM/LsC7B02OfXj4fmutSi0+2skubYLqM6S3EjSSCUtNv8xxGBF8u7A84 bgf3e3oIdJ0220s6XBp9pFp5RkNokKrEVbO4bAMYOTkY5yaNS0nTdZt1t9U0+0voFcOsd1CsqhsE ZAYEZwSM+5oA5fxfJe22jzadY3UexH0uKGNb+WO6PmXYjfzJQS6o6gKHGWJEmc4qnqui3Nt4atzd tfWVwNVtIwLTxFe3G6OW4gjfLsUblSw24IXJIILGuk0GXw5r+iWupaPb2k2nyIiQOLbYNsDnywFZ QQEcMVGODyK2JoIblAk8UcqB1cK6hgGVgynnuGAIPYgGgDzcyXNr4uvYYG1lfI1izs4L6bUXezii +z27PFIjSnLupkUM0ZzJKnzBiCMvVJPEn/CK+JvI1K+W1ll1S+F6s8gltfs00yiGNxwisUttqd1+ 08j5a9QvBpcLC0uoIP8AibytC0bQ7hcv5RJD8YP7uIj5uygegqveXuhWV5Z+HrpIEk1j7R5NoYCU uMAvNuwNvO4k7vvZPU0AY/jS782TRbW2N9dZ1UwXVrpl79nmb/RJpAhcSJj+B8FhkAdcjOHZXOtQ +KDomq3l3a6fPZW++Y3BZ4A9zdCG3LgnbK8flxtNkkmLaGLvG47TSr3QtbnvZ9OSCaax1CSG4k8g qyXSII2OSBlghC7hn5eM4rQmsLO4+0efaQS/aYhBPvjDebGN2EbP3l+duDx8x9TQBHeXs9tcWsUO mXd2kz7ZJYWiCwDI+Z97qSOSflDHg8dM8nqt/eab8Q59RN3OdMs9Ps0u7YyHykjmluFafb90MjRx FnPCxCXrxXcVXmsLO4+0efaQS/aYhBPvjDebGN2EbP3l+duDx8x9TQB5v4W8YeIriw0ZRZfaLCGL T7W7up3jzJJNBA5cyvMrBv36/KInLkYDZf5dCw8caxdQadv0vZNdfY4D/o7hftG+L7Yg+b+BJWwO qtbXG7iPnsE0LR47y1vI9KsUurSIQW0y26B4YwCAiNjKrgkYHHJqwthZp5e20gXypXnjxGBskfdu cejHe+T1O5vU0AcHfazqV34a1261RI7TWNEt11WGxFqyPaMokdVM+9kmRwjRs0e3KmRSFLFV6TxP q2o2X2Wz0WPztTn3yiH7Ms2YUwHb5poVGGkjH3yfm4U8lS70Xw/pWmW8K2sGm6eNQt5TBZwLGks5 kRYtwRc/6zyjkY+6uTtyDc1+20WfS2bXrO0urOJw4jubcTDeflXahBJcltoABJLYGScUAcnpXjTW NTtRrWyxi0w3en232LyXab/SorZt3nb9vytc9PL5CY4zkR2njLXotJ0We9Omzz65ZQ3FsYbZ4ltW kmtosODIxlAN0G4Kf6sj+LK9ZpCaNfacwsdL8i1WVD5M+nPa/PGE2MEkRSdoSMK2ONgAPy8XDpOm tbpbtp9oYEt2tUjMK7VhYANGBjAQhVBXodo9KAOf0jxFqU3ix9AvhaSPbpcia4giaMSMi2joVQs2 0bboqQS2SgIIzisfQvGWvajpsOs3B00Wf2jTrWS1jtnEjNdRWxLiQyEAK1znbsOQmM5O4dhJ4a0G bS4dLl0TTX0+F98Vo1qhiRueVTGAfmbkDufWo549H0ptO04abAkd/dpFFHFAgRZIojIjMOMbVt1C kZI2pjAHABzb+KPEZ8OaPqdvDaXM+vPEbK2htfmtVaCSchy86LMQqbc7ou7YPC1l+INf13XPBfiK 0K2NhJaaJPLfK8YuDLk3MRVTHLtib/R2JBaXaX2nJQlu8bw1oLJeo2iaaUv3D3im1TFwwYsDJx85 DEnJzyc0XnhrQdQt7W3vdE025gtE2W0c1qjrCuAMICMKMKBgeg9KAM/VZNSPjrQreyvY4IGsruW5 jljaRZVWW1HADqA+GIDHdjJ4Oaw08aawljpVzKli/wDbtpFc2SrC6/Y/Mmtogsh3nzsfa1OR5efL I43ZXuLqws77yPtlpBceRKs8PnRh/LkX7rrnowycEciq8WhaPD9u8rSrGP8AtDP23bboPtOc58zj 587m65+8fWgDh7fU9d07UNesLR4L3XZtV81hBYDY0KWdoGYJJcoFwZIhzISc8LjO3U03xfqWpjTU TT4459VS0vLX5WeNLV4w829uCXQrIuQNoM1tn75xsTeGfDMGlixfw9ppsDcLJ9mTT1dPNbCB9iqR nBwWxwMkkAGrlto1naait5Amzy7RLOCFQBHbxqSSI1A+Xd8obHBEcfHyigDi/G0mpSP4zhivY10+ LwuHltpI2cszLeDKHeAh+VdxKtuCgcYzWheeIta064u9GlktLvWClu9k9rZFVlMhmJjMTzgZVLaV txlUHIGMgBuovdJ03Unje/0+0unjSREaeFXKq67XAyOAy8Edxwap2sej+KtDg1GXTYJ7XVLSCVo7 uBGLx/6yNXHIO0sSByAScUAc34T1rWte8UXE08kdrBBZRx3dlJGWJlS5vISyYkKxkmIFh+84AXcd oYkeoardfE+WxtLyOC3t3uRNHKJJVlQRac3C+YAj/vXAYDAyTtJZiest9C0e0+x/ZtKsYfsO/wCy eXbov2ff9/ZgfLu74xnvUk2k6bcuHn0+0lcXC3QZ4VYiZVCrJyPvhQAG6gACgDH8MazqWpXF7b6u qWt/CkUr6eLVka2Vy+0GbeyTg7CAybfunIU/KvR81kaFFo9q2pado+mwWEdldiKaO3gSJHkMMcm4 BevyugycHj0ArX2ikxhzRzRtFJtNLUBeaOaTaaNppagLzRzSbTRtNGoC80c0m00bTRqAvNHNJtNG 00agLzRzSbTRtNGoC80c0m00bTRqAfnR+dJ83vR83vRcY2KJYUKqZCCzN87sxySSeSTxk8DoBgDA AFcn4g8M6jq3iF5bS7+y29zaxeZP5Sv5U1s8jwfKTlv3k6y+n+jbTkScdd83vWLq3ii20e4miktL udLW3F3eywhNtpAS2JH3MCw/dyHCB2+Q8crlp3YjjP8AhB72ex1u+n0iBtXn0ozae7GNpLS9kmvJ zHHJn5WRpoh5gKglQwxjg1zwnq15a6rBa6P/AMTOX+0Wl1TfEPt0E0U6wW+/d5h2mSAbXARfJ4Py pnrF8ZW0ySG303UppBeyWEMYjRDczxtKHWMu4UhVhZ9xIXHAJcFBz9t8UNP0yzVdeeSK7a4u3lSS S3ja2gW6mjTKmQeYQsZGIvMb5O5Zd1CIz4euBex6W7eTJrUuoJqEOA3mWAvHmD7s8ZWcxYUhv9L3 dYsDoPFOlm+1HT7i40T+3dNhimSTT8Qt+9YxmOXbMyodqpKuc7h5nAwWwSeOrBIHkFlfE/2g2mQK yxxfablXkUpGzuqn/Vk5JAOQoJfKA8U6tqVvYaNHY219FcaldiGSO2+zm5iHkSykKZGMO4GMA5LD G7HODQBz9p4U8S6cgna5+2XllFb6gh3K32y9W3it5I97nIzHBIu9hj/TN2N0QJNM8BS6Pau0NlBN qdtqGmpbaiERJntYorSOYhs7kUrHOCmeQWHO7npF8ZW0ySG303UppBeyWEMYjRDczxtKHWMu4UhV hZ9xIXHAJcFBXPj6y84xR6ZqUuxEEzKIgIZnmkt0hbMgy5miaPK5TOCWC/NQByeleCNXs7GZXtr6 S68qFdR86S0SPUys0TyhRGoabeiTKGuWU4lw3+scr0mg6LJa6H4ohh0W70SC+uHe1tLN4Ip0U2sU ZMZjcxo5dHIJYc4JxWhqfihovCyaxp1pJNIb2C0a1cKHDm6WCWP7wXeCXUHdtyAcleTJH4vsDfJZ TxT2t012to8cxjzG5hjlyxDEbczRRZBP7yRFGdwJAOb0PRtV0C4s9Sj8Nx+REl1brZ2ENtb3BWQ2 xWSZRIIS/wC4cMUbkGPCj5lXL8N+ENSsEtYp/Dfkaqkumuusbrc+TFDb2qzRbw5lGfKmjwqlTv5O 1ia7Cx8dWGoRWlzBZX32Gf7Mr3bLGEglnWNoonG/eWImi5VWUbxluGxY1XxZBpWrPp7adfXDRxQy PLD5WxWmkeOFPmcHc7ptHG0bgWKjJABw6eDdeayMWnWP2CTzZDHfXfkxX7SNZ3cfnXEsDMJMSTR7 XAD8sWBI3tYi8NalH4lGpeH/AApBoUcflGOK4FvHG0q29+u91gdsrungU4+bB6YGa6TU/iFo2kWF le3okhguHmSTzJoEaBoX2Sgq0gaQq24YiEmdvGcrmRfF5/tO/wBPTS767voLuSKO0hSFH8pI4WaT c8wRlzPGRyrfvANnysaAOP0nwPdtrVvDLpF9BoK3cM0lvdmzhBIgvEkPl2hCFWMlurZGXHDZUYHU aVpnmeL72NJt+maVdyXMUW3Hl3lxGGdc53Haskj5OVP2zaMeUK1NE8VWPiG6ni02G7kghSNzdNFs iYSRRyptJwSSsoOMZXad23Kbqf8Awkl5/wAI5/aPlwed/bf9n7dp2+X/AGh9mz1+9s5z03dscUAS GPU9F1bVJLPS5NSTVLhbhHSaOJbdxDHEVl3HOz92rbkDnlhs+Ub+L0HwwbPVbrTbTSfOv9N1DT4R r+yGPZFDa2fmR53mUb0V12qCp83BOCxHYeG9a1PUdRkh1OaC2m8oudNbTZoZImyAwWd32XCoTtLx rtJZTwGAOGni3ULa6Go6jNd22mDWLy3lLxwtAbe3ivMmIJmXP7hGbfyWHyfKSKAKZ8PavNpmk6Vd aNqqQ6VojadNNZzWhN0/mWnEQkcgxsIH3CVVyhIIydtbk+iavP8ADCXQ4bHTbG8vENq8NpbiOG3h ml2u4jD4DrE7MVDkFwcFhjOgfGEUbm1m0jUotULosWmt5JllDrIysrCQxAYhmPzOD+7PHK7qd34+ sxZ6j9mtL4T2Wny3k7NbB0t9hnRlf51DMskDJtVvmyCpKhmUAx9T8N68zatHfw/2tDdXdvfotjaQ pFLKImiaOaG4nIkhAigbG5W3NlSCuVjn8Ka5JeS/Y7C0tr99MMH2544hBZyfZfLVbCRG8+FBIclW TGN5XaT8/Sf8J1YRefNe2V9ZWEUt1Ct9MsbRyvb+YZAqo7SdIZWG5RkJ6kA6Gk68dT1G7sJ9KvtO urWKKZkuzCdySGQKQYpHHWJuuO1AHB2vghooYpW8PXdzp8F7HPJpN6tgpmxDPGWSGELADmaMlnfc wj7bE3dZ4k8PXGua1ZvG3kxxafcol1gN5Fz51rJA+zI3YaEtjodmDwcGSLxhFPZQXcOkalJHeui6 djyQb8MjSBo8yfKPLRn/AHuw44xu+Wq58fWXnGKPTNSl2IgmZREBDM80lukLZkGXM0TR5XKZwSwX 5qAOf1HwdcxR3mnRaPJPof21Hght0tJ5wEs7aGMgXeUCDZMrE/vMhMfKWyaL4P1OHTRqF9psZ8Sf bdLc3zvG1x5SRWaXH73JOPkuARn5gW6huegbx9ZKZ2XTNSeC0t/tF/Ooi22SiSWNw4Mm5ijQS58s Pnb8u7Iyat8QtG0XVr7TbwSCe0t5J8RzQO0myEzFRGJPMU7FY5dVXjryuQDj5PDmtW93fX9zYyWs D25n1ksbKC0u2W4glkVNhDujRrcqDc/wvhiu5zVO08Px+IEur3TNFnj8PHUJmi0+wj0+RWY29oqy qspe3ZQ0c6lkYsGYju4HeXfji2sZYk1K2u9KeNy9zDdRJKwg8i4lEgMUjAA/Z5Om5vkI2jcGFe1+ J2h3luxgWSS7NxFbR2kdzbSNK8gcoBIkpiBPlycM4Py4xlkDAGXZeBZTqUUmp6XBeeZqES3k9y6X D3FqmnImJHYAyL9pRTgqMsofaOop6T4P10atpV9q6alNqCJZP9rWa1KwLHDEJo3mZWuMs6TErGdj +ZgsN7keoQSNNbxSvDJA7oGaKQqWQkfdO0kZHTgkehNcHZ+O7qPUbmXU5IF02G7voZMadPD5MVuZ v3gnZik7bYeY4xu+Zj0jYUAZaeAJ7fw7oNnb6HaIF0yA6xbRiJRdzxT2kmxxnbI5WO4VWY7cscsA xNdpqGnSvYaHd2Gn+S2lSrcppo2IdvkSRGJSDsVlWU452koF3AHcM++8aXUF9p9nFoN8t9LdrHPY SmAzGF4bh0dGEvl8tAw5fOFbjlSZPD3iie5mNpqVpdoZtTvrS1vWEXlTGOabbGoRi4IjibllAOw8 kkbgDL0bRNb1HxRa3/iC3vpbSy+1fZTqD2wkG4WbR71tzsb95HOy5BwUU8MFNZ9t4T1aO2svK0f7 NdWUVu2pSh4gdYuIrm2l81SrEuxEM+Gm2HMwzjc5XtLjxRbW2qPaG0u3ghuIrSe9UJ5UM8mzy42B YOSfNi5VSo3jJGG207PxtBqWnafdWGjarcPqERuLa22RRSPCoTdJ+8kVQoaVF5OWJyoZPmoA4+5s Hu/HZudZ8Fz38d79suINPnFpK6KsWnReYQ0vljlHHDFuemCa6i58MXF/o/g/TtZgg1X7BKh1Iz4l SQraTRlzv5fMjL1Gec44OM/w/wDEvTJbXQdP1K58zU7q0sxcS+ZCmLiaJGUeVvEh3GROUQoN3JG1 tupb+PrK8stKntdM1KWbVkaSxtGEUMs8aorO6iSRRhd4GM5OCyhk+egDk9f8K+ILjRTaw6ZO8lp9 t/sg2Qsy9qzTymLc8/MUYjFts8khl2sDgqmOo0DRbqz8ZapfHTdlvN5pa9vooDdyM0gKpHLExY24 VeFkAZcIASBtTc1XWhptxb2kNhd6heXCPIltamMN5aFQ7kyOi4BdBjOfmGAQCRl33jqw0+K7uZ7K ++wwfaVS7VYyk8sCyNLEg37wwEMvLKqnYcNyuQDn77wXdSaDIv2SdpZtburu+hhaCWS5tzLcGFFW fMJUGWOTY2ADvYASdbGkeG5tPv8ATX1HQp9Ut44o0s/Pe2lfS3E8rlyDsWP5HhGIA23ydoyEQtY1 /wAdG30DWfKsr7TtQgtLhY5J1hcRXaW7TrEdruC3lgSZwUxwW3ZWrGpePINLTdfaffWM0G6We0mj ikkaEW9xKGVklKDJtpAOScrgqAwYAHL6R4I1ezji321814ktkb6aaS0SO7kju4JHmXylEkuBHKwe dg4DYAZnbGpeeDNTk0m+s0kk8qxSOx0xI/LDNZedHLKg3EqxaNUt9suQ3kbmOJWrYv8Ax/p+kW8h 1Wyu9Pu0eNVtLqW3RnEgkKMJPN8oA+TL95wfkIxllDZ+tfEGK48Hajf+Hbe7uriPTJrozQ+SVsyP NRXcu+1wHhk/1fmA+WTyCpYAz7PwnLZ29obrw7d6rpKvcEaPdGyZoncQ7JBEuy3QDy5+ELH98W6u 4WTUNLNp4R+H2l6ron9pyW8sMNxp2IZN7pYTgj94wjO0jPLfw8ZOK7DxJ4jtfDGnR3t4m+N5REB9 ogh5IJ+9NIin7p4Bz7YzjL/4WHopsr6/RLs2FmkLNdtGI4nMyRPCqs5AywmXrgJglygKlgDm7nw9 r1noOu28OjT3TaxpUtlbQQTQj7EPNumijk3uoCqlzEgEZcDy2A4CltA+E5YNM82bR/t5k1u7u7+x LpIbu3aS58lAJGEZUGWOUISoBDNjf16fw74lsPFGnPeae2VilMMqeZHJscANjfGzI3ysp+Vj1wcE EDW+b3qWx2OCj8JFZ73VLXQILK/bVdPks3CwrNBaIloksYdSdqhUnQoDgjcBkMM46+FdZe/v5LnT NViW8tJP7RGnDToo7q4M8LDyhwZIyBP/AMfOSUZgeXYH1X5vemspYqTu+U5GCR2xz69e9HMFjyy7 8E6vdrZG403yNtoI7WDRo7S3isJfNlYyHzRI0DFXhJe3LtuRj821CfVu/ek+b3o+b3pNhYX86Pzp Pm96Pm96LjF/Oj86T5vej5vei4C/nR+dJ83vR83vRcBfzo/Ok+b3o+b3ouAv50fnSfN70fN70XAX 86PzpPm96Pm96LgO3H0o3H0pN3t+tG72/Wi/mKwu4+lYmr+GLbWbiaWS6u7dLq3FpexQlNt3AC2I 33KSo/eSDKFG+c88Lja3e361yGv6p4itvEL2OlQ+f51rFc20W+Nd3kvI1wuWHG/NrDk/d87eudjU 0wNV/C9t9gjtoLu7t5Yb2e+guoyhkhlleRnIDKUIxNIuGU8H1ANU7XwTBZr/AKPrOqxyS7xeSo8S vdq0skpDERjZhppcGLy2G/rkKRy9x4s1b7DPePrH2ZmtJL7RIdkQ/tcvNOYYdrKWf90tqNke2Qed 8x3MMSXs+oXdvp+qap4gksrWDxHeRi7jihjWxhjF5ChZnVlyxKR7mGOUAG7LNQjrP7BtbzQZ9Nsd VnjtZru6ed4RBNvMkshliYSRuu0O7KRjI24J65sDR9LgbQrCJ/I/srMtlbCXJKJE0HO7LMqrMMn1 K5PPPL+Hpb3TrqydNRnltdS8QanavZypH5cIEt3JuQhA+7dCPvMwwzcdMZ+tXcUXxm0xJr/7c3lO iWlpqLxT2u5rXCtChAdc7pW3H5oy5IIhUEA7R/C9t9gjtoLu7t5Yb2e+guoyhkhlleRnIDKUIxNI uGU8H1ANV4fBWmwiQie7Z5XtpJXLrl5Ibl7reflwC8sjlgMDBwoXFcP9u0W606+1Hwnqum2MkiQx uttOHnkt2uIhNeXm1xJkIWIZmV41d2Z1dyI+gttXay+GniKfSf7NjTS7e5Njd6XbrHazEQ+b5kSZ ZcB2ZCNzAtG2epUAHSHw3ZnRZtMEk4jku3vVlDDfHM05uAy8Y+WQggEEfKAQwznP/wCEf0TVZdQA 1D7TfTWiW888TxedE6My+eu1fkmLxKCwA+a2QADywByfibWdY0zTNdgfVJL6OB7rTtl3bwMrr/Zr 3gkYLGAX3fJjGwoMFC2WOOmo32ma9fXOm20dzeLcXbQwtB5pd1k1t1VR94Esqj5SCQSM4JBAPTD4 QsFvA8Es9vY+bDO+nQiNYHlhCCJvu712iKLCqyr+7GQctmxfeG7PUL+a8lknWSX7HuCMAB9mnaeP HHdmIPqOmDzXHprN/fa1ZaVpXiye+024u4kOrQLayvuMF27whli8r5fIgbG3cPM5OGXGwdb1FfA8 14bjE8OoPZS3hRcxwJeGB52GNgZYlaQkjYCCSu0baAC48E6ZfwanZ2ms31t9q8631EWzws0iyvJP 5b7422Y+0uRt2ttkGSflIItCguNe1G5XXPsWsy3csiiwkieSKHyrZGRllRgciK3kb5AVLqASDl+X 0zWoYtV1VB4z8nSLjUJXfXvMtf3sqWtkEi3mPyeQ0vAUMfK68Nmnp2tX0eu3mrXsElrqE1lM0yoP K+yyyW2kBmbeG8tI2YsxZW2qrEhsYIB6homgWPh6GeDT1kSCV42EbNuEYSGOFVUnnG2JepJznmqf /CJwfas/2jff2f8Aa/tv9m/uvJ87zfO3btnm/wCt/eY34zxjb8tcn4U8R65rniC20465aTWtu90Z ri0eK6+0rGLJ1AlWNFzm4dCVjHy5GNwEg3PAutXWr/b/ALXqX9oTReWXmtJYJrAM24lLeSNVfgY3 LLllyvLA7mANjT9BNpqIv7vVb7U7pImhhe7EK+UjlS4AijQHcUT72cbRjGTmvc+DtLvNOjsLnz5b Vbu6umQvjebgTiRSQAduLh8YwRheeDni/C2s6w3hy01Q6pIIoLjSbFdPS3gS32TwWYc4WMOCDcOw CsACFGMDB6TX9aurPxlpdiNS2W83lBbKxlgN3IzSEM8kUqljbhV5aMhlw5IIG5ACxceFrWL/AE69 12+OpebCIdTmaBJIiN8caKojERz9olUbkJJl65C7ZF8Faathqtp592RqlkbO6kLrubc8zvIPlwHZ riRjxtHACgDFcHP4qvdU1aKykvoJrW5u7S7Fo11HJc2JTUbQLFLGkSGFsSkMrtIcpjd8pLWNL8V+ JbjTLy4udd0OCY2iSXCXN6oGmytJGDGxFuBbthpFCTGVt6r94JJkA7i58HaXeadHYXPny2q3d1dM hfG83AnEikgA7cXD4xgjC88HNfwtoms2Oo6hqeuX32i6uoobdU81JdiRGRgd6QwjkynjZxjO45ws cOuyD4eHVVl1J3dGVLi78hJV3SFBMzRq0QiXIfzArL5Y34bvzfhzXNb8SaxHpX/CS7IYPtebzTJL a5+0bFs2XMjQBDg3Mg+WNOgByQSQDqG8LWthp1vAddvreC0liGmszQD7CcNCiRlo/n3LJ5f7zeTk YO7mpIfBWmwiQie7Z5XtpJXLrl5Ibl7reflwC8sjlgMDBwoXFcPL4mn16w0qbVNZjsbue90aW30i PykW7R3tZWlCuDKwEjyjKsB+6wckNnc+I3iq98P/AD2N9BZSWlo92FvLqOGO9POIkDRO0rDZ8yo0 ZAkT5ssCoBcPgENq+pk6ndx6Tf2/l3FrGY83G+e5mlRyYyVT/SNqlGVsE85ANWNS8A2WpiWCXU9S jsHe5kFlGYvLSS4jlSVwxjL5PnytgsQC3TAAGHfa54ih0GS+/teCNJ9burMzzGO2jsreKW4Cs0rR yKGZo449zIQQUUAOS50LvXNRg+G1vqVzq8FtO13bwyajAVKCBrtIzKGkjVGzEc79gQ53KNpFAGxq /g7S9c1Nr2/8+TfEsMkIfajoI7iPBwNwyt3JnBHRcYwck3hia5064tLjxFqszXGFlllS2fdFhh5X lmHytp3Ek7Nx4BYgADk7zxTeLprw2/iCMW4vWW0124ure2guYliiYqZvIkiZ/MlkVQkYyIHyco26 no3iy61AC51PWIPD9ne7Lme/hSCICc2Vi6xb5lZTu82YjdlyIgA21SKAPRNG06xs7e3l0u5kfTzZ W9vaxLP5kCxRhtjJ1yWVwC2TkKvpWX/wgthL58N7e317YSy3Uy2MzRrHE9x5gkKsiLJ0mlUbmOA/ qARy7ab/AGv4A+Glj5djJ5v2f5b+1+0wnGnzH5o9y7unHIwcHtitCXTdH0i6isfF0ehx6JFaJ9iV 7VLawFwZZTLiNmZVk2GHG4kn94U4MgoA3D4Pikc3U2r6lLqgdGi1JvJEsQRZFVVURiIjE0w+ZCf3 h54Xbch8N2cH2LbJOfseoXGoR5YcyTeduB4+6PPfA68Lyec+T6qmdUvn1KexXUE0pTpkN/Du1KZP tN59nW1dmDx3Hl+SNxV3DlCylgQfRNfAj8deHLiXUpNOg+z3UIkBjCzyvLbFLcl1Iy4ViAuHOw4P BoAuHw/YaneDVINQnexu5Yb57eF42guZUCGKXdtL8COIgK4U7BkHLbgeE4INO0m2sdRvrKbS7QWU F3D5TSGHCAqwdGQ5MUZJ2g5XggEg8Hp+qa54e8EeHYrHUZLoXuhQzg3axItkqvaRsyukfyosdxIx aQSbfLVjkBg3QW2u6uvw08Rao2p2l3c2dvcvZ3trIJ1bbDuBMnlRxyEPuGUTaNoU5ZWoA2NL8G22 jC1isdS1KK0hSESWyyIFuHijSNHdgm/O2OMFVZVO3BUhmDF34Msrzw1p/h2W8uzpNrbpbSWxWJhd RoFCiQtGSD8v3oyhBOQQQCObfxLMk5t7bxX9q0IywCfxBm2b7KWS4LJ5ioIRhorYfMpI8/GcsmKd zfa/4i0TxNZ/bZLi2i0KY28MNsrPfF3vYYpAwHIkjiifCABiVK7VJVgD0DVdFGpXFvdw393p95bo 8aXNqIy3luVLoRIjrglEOcZ+UYIBIOHrHhTRGikttT1ie3sb6WeO2tJJoo0S5uVkV2iJXe0jCWbC szD5zheFxYvdUNt4JW903W/7SjMsaNquYX2xNOqSy5RRH+7Qucldo2ZYEA55/Sbi61nxzp3l65Pc 2lpFei21CFYG+3wg2DMGYJsZfMeRCYwpHl4zuDEgHSat4K03WY75Lie7UXtxJcSeW6jDPZm0IGVP HlnPf5uenFU5/BOma/YGe71m+1JruIhb4PCC8LQTRKF8uMIVC3MrAhcksMkgAUa/rV1Z+MtLsRqW y3m8oLZWMsBu5GaQhnkilUsbcKvLRkMuHJBA3Jyel3moaT4W8GWZv5L231Cy0+fy7uCFhb7LqxQL HtQcbZ25bcwKoQQQSQD0DUvC9tqGqNqgu7u1vwkKxTwFCYTH5wDKHVlJK3EqncCMEYAIBqnqPgmD UbOe3Os6rC13aGzvpkeJ3u4yXOG8yNguDLLjywgG/AACqF4e18ZX7+GtNuo/F/2r7VaWkuqXeLU/ 2XI9xaoy/LGFjyks/EoY/usjG1s2LvxDqUmqW0VjrP2iAym1tNYSG3eSaJ7nTVdlcJ5ZwZ5o/lXb lBuBZM0Aeiaroo1K4t7uG/u9PvLdHjS5tRGW8typdCJEdcEohzjPyjBAJBz7HwVpunaDLpMM12Yn e3kWVnUyRyQRwpE6/LjI+zxtgggnOQQdtc/Prt5a6tcaRqfiaTTdPtLiWI6xKLeOSRxDayxxOzx+ Vk/aJsAICREPRy3SeEdc/tbw7pP2m483U30q0vbr5NufOQ4bgBeWR+B0x0HFAGnp1k+n27RyXt3f Su5d57plLMcADAUKigAAYVQOpOSSTc3H0pN3t+tG72/Wov5jsLuPpRuPpSbvb9aN3t+tF/MLC7j6 Ubj6Um72/Wjd7frRfzCwu4+lMEjGVk8pwoUEOcYJOeBznIwO2ORjPOHbvb9aN3t+tO4xdx9KNx9K Td7frRu9v1pX8xWF3H0o3H0pN3t+tG72/Wi/mFhdx9KNx9KTd7frRu9v1ov5hYXcfSjcfSk3e360 bvb9aL+YWF3H0o3H0pN3t+tG72/Wi/mFgwvrRhfWl49f1o49f1p2ATC+tYms+In0a/srRdE1K+N6 /lwyWrQBTJsdyh8yVSCFjZs4x0Gc8Vucev61mapps19qOh3ETxhLC9a4lDE5Km3miwvHXdIp5xwD 9CJAV9C8U6brk11aRXVouoW1xcRS2S3KvKixTNFvZeoDYVuRxuAyep0NN1bTdZt2uNL1C0voFco0 lrMsqhsA4JUkZwQce4rk9T8EXmqeHk0lrqCHdqGpXEkoBbbHcpdquBgZYfaUJGQOG56Z1PC+hXGl 3F7eXcEcM9ykUW0anc37FULkZlnwQMyHChRjk5bdhaEXLHXjqV5GtppV9Lp8mTHqYMIgcAH5lBk8 wqSMBgmGyCCVIaq76/4Tk8nxA2uaUY4fMso7z7cnlqX2O0ed23cfLQ464HoTWefD2sf8IzN4QCWI 0g6e+nxagbh/PWMxFELQ+XtZh8oJEgDYLALnaBPD2sX3iqy1+/SxtpIZYg9tBcPMPLjhu1DBzGmW LXQ+XaAAmdxJwADcn8S6Da28txca3psMEVwbWSSS6RVSYDJjJJwHA529akl13R4fsPm6rYx/2hj7 FuuEH2nOMeXz8+dy9M/eHrXBjwvr2h3nhSa1t7S9ntLexsnXznSNWgtb5XdnEbFUJmQKdvJ4IGRU ms+B9fvdButPingl+2RXRMX9pT2kdrNPLLIx/doftK/vVXEgUYiyAPMYAA7RPEugyXF3bpremtPZ I73Ua3SFoFQ4cuM5UKeCTjHetATwtcPbrLGZ0RXeMMNyqxIUkdQCVYA99p9K5dPCkz2+nW92LSaC DWL+9uI3yyyQzi6ATBGCcXCAg8cNyeM2PBemzWujLe3jXb3l4iEtekmdIVULCkmRkOF+Zx082SUj hqANSHXdHuJbmKHVbGSS1lWC4RLhCYpGbYqMAflYt8oB5J461Hf+JdB0p9mo63ptm4cptuLpIzuC qxHzEc7XQ49GU9xXJ6H4HvtIs/sxgsbhoNPOmxSXl/c3aTRsYw7mF8JEu2MEwrkNwu9AMmRNK17R Ne0aHTrG0v0tbK+i+03Fw8IkV5LZw8rrE/79mD5/vkM+VyUAB2EmrabDqkOly6haJqEyb4rRplEr rzyqZyR8rcgdj6Vl33jfw3p86RT6zY/8ff2OdxdR7bWTZI4EpLfJnymUZ53YGOuOb0z4eT6XdWkH mx3lpG9lK0739zCFa3ihQf6Kh8uQkwKwZm4LDIYIA2haaDrtnpGh2aw6bI/h54xZsbt1F6qwSW5M n7o+SdsgfA8zkbc/xUAdRHq2mzapNpcWoWj6hCm+W0WZTKi8csmcgfMvJHcetZ9p4v0G6tdQuG1O 0t0064e3vBcTohgZZWiBf5vlDMhK5xkEfSq+iaPqOna9fTb47XSZXmkWzS6a4Es0km8zfOimE/ez GrMhLkjBBLU/+Ef1e18r7MthN/Z+qz6laeZcPH9o8/7RvSTEbeVs+0cEb92zkJngA6j7fZ/2d/aP 2uD7D5Xn/afMHl+Xjdv3dNuOc9MVTXxLoLJZOut6aUv3KWbC6TFwwYKRHz85DEDAzycVl/8ACOXf /CJ/YPNt/t39of2nt3Hy/M+1/avK3Yztz8m/bnHzbf4ap6toOu6smpFodNhfWtMGm3gF27C0VWmx JGfKHnErOTtPl4KY3HOQAdAPEugtcPbrremmdLhbV4xdJuWZiQsZGchyVYBep2n0oHiXQWuHt11v TTOlwtq8Yuk3LMxIWMjOQ5KsAvU7T6Vy974L1G5069t0ntA89lrdupLtgNeXCyxE/L0CjDeh6Z60 XvgvUbnTr23Se0Dz2Wt26ku2A15cLLET8vQKMN6HpnrQB1j67o8d5dWcmq2KXVpEZ7mFrhA8MYAJ d1zlVwQcnjkVHH4l0GbS5tUi1vTX0+F9kt2t0hiRuOGfOAfmXgnuPWuL1D4e3t1Fq1tGbdln/tCW 2uZtSuWAkuVmAH2b/VR7fPILjeSFJ2gvldzV/D2ozeLE1+xa0ke3S2MNvPK0YkZFu0cM4Vto23QY EBslCCBnNAG4mu6PJeWtnHqti91dxCe2hW4QvNGQSHRc5ZcAnI44NSXmrabp9xa297qFpbT3b7La OaZUaZsgYQE5Y5YDA9R61yb+Eb248RvqNxFbtHd3dtfT41S5CQSRJENiwLtjm5hBEj7SNwyhCANq ano+oz+KrXUtNeOzGyKO7uxdMWlhR2cwm3KFCDuIEgZXXeccAqwAaF410rXvD9pqdtc2kksqWv2i 1hu43a2ecqoRySMEMxGDgnaQATgVJPr/AIT1jTJpZNc0q4sbOWCaaVL5NkLrIGiLMG+X50GMnnGO elYbeC9ROneErfz7Tfo9lb29wd7YZo7iylJT5eRttpAM45K+pIz9F8Ma7qfh3ws9/BaWD6ZZWcSQ mZ2eRVntJn8wGNfLcLbY2/NkvgkbckA7yHXdHuIrmWHVbGSO1iWe4dLhCIo2XersQflUr8wJ4I56 VXm8WeG7eztrybxBpUdrdbvs8z3sYSXacNtYnDYPBx0rl9Q8CX97DEhubceVLfTgJPJGXMuoQ3ca h1G5MrEVLjlScgNitDw/4VutM1yHU5Vt4t0V0J4xez3b75PsoUmWb5n+W2OThcZVQDgsQDYi8UaP Jqeq6dJfQQXWl/NcxzSopWPy0kMuM58sCQAscDINR6p4p02x8MNr1vdWl3Zl0jjnS5UQFnkEQLSD IVAzfM3O0BuCRiub0vwbqWmeGZdGmt7C/jlis5SRqM1qVuIIreLCskZYKPs/mBwQc4XaB81bkmja td+FrKxv9QjutQjvba6lmfABWO6SYplEUMQi7A21dxAJC5OADQtNf02Z7C1l1LTRqF5brPFbQ3ay GRSpO6PoXThsMFGQCeKLvxDpttoN/rMVzHd2llbtcSm1dZCVEYlwOcZKFWGSMhgehzWPeeHtRm1S 8jia0/s++1O11KWdpWEsTQeR+7WPaQ4b7OvzF1x5h+U7fmksfCYg+GMfhIvb20jaUbGWWBMoJGjK vIB8u7LFm5wTnnk0ASW/jjQbjXhpq6rpuya3hls5xeoRdNJJLGUjGfmKtEBwTy2MDHOhd3Oi6y9/ 4cnvLS4ne3ZLuxW4HmiJ1AO5Qdyghxzx94eorD1Dw/q+sWfiRrlbC2utW0RdPjjjuHlSORTc8ljG p24mTnbn7wxwCc8+A5WvL1Li2t7y0eW9uE87VrpRKbgS5j8gfu4eJ2UyLvOATtDPlQDqP+Es8N/2 d/aP/CQaV9h83yPtP22Py/Mxu2bs43Y5x1xWhfX9nplnJeX93BaWseN808gjRckAZY8DJIH41w83 hHXp/sV5dXX2u4tvtEUVp/bE9t5MMnk4X7VFGJJdphz86ZPmfMxKBm3LjQbm10jw9DpgtHn0R0aK B3eGKUCB4Nu794yACQsM7z8oBPO4AGxFq2mzPAkWoWkj3CI8KpMpMiurMpXnkFY3II6hGPY1j2vj jQbu91JYtV01tPsLe3ll1Bb1GiDSvIuxmzhSPLXqed449ce28BSvFr4vJrRJ9X0yW0E0amRrZpp7 qaVQSFLIDcRjPy7/AC8kLxUep+Fte1vWH1e9gsLeaL7N5NraatOnm+Wt0rZnSJHj4ugflVs7CDgN kAHaRatpszwJFqFpI9wiPCqTKTIrqzKV55BWNyCOoRj2NV08RaVc6Nd6rYX9pf2lqjtJJa3MbKCq 7ipcsEU4x95gBkEkDmub07wOtquqtc2VhP8AbdK+xiE3MxOXluJZUad90m1jMgL9WKltq4Ci4dB1 q68C63o97exyXd9bzwWqSTGVbZHi2Ihm2K8gBy29l3fNgliNxALlk3ha8gi8M2V7Y3H9meVixhvA 8kH2d02bgG3fK6pnPcYOc1X1Tx3o+mS6jbyXEC3WnXdtBcwzXCRlY5WgBm6k+WonGSQBlSMjrRa+ HLuD+yd0tufset3uoSYY8xzfatoHH3h56ZHThuTxmO/8PajNe6ikDWjWl7qdlqRleVldGhe2DR7A pBBS3JDbhywXbgbqALmral4av9Dgvb3X4INMklxDeQaq1skjjcNoljdd3Rvlz/D0440Lu+0fw7p0 H2y7sdLsU2wQ+dIkEa4HyouSAOFOAOw9q5PVfBuoT+IrvWIGjmMlxI0duup3FidjwWqFmlhUtkNa n5MEEODkFcVuDw+8Fv4VtrdrdYdGlUuF3KCgtZYQEBLHrIvDMeAeSeoBffXNGjs7q8k1WxS1tJTB czNcoEhkBAKO2cK2SBg88io38R6BHcWlu+taas96iPaxtdoGnVzhCgzlgx4BGc9q5Sx8GavpraLd xSWE11pWn2FusLzOiTSQxXUUmX2EquLkMDtJOzBAzkSJ4L1EaT4ngae08/WdMkgQB22xTSTXkrAn bkopulUNjJ2k7R0paDL83xB0CJ4A17aRINTl068NxdJGbRkWfDOMnAZoCFzjIYH2rp4JoLq3iuLe ZJYJUDxyRsGV1IyCCOCCO9cza+HtRgv7BGa0NnY6xc6ikolbzJFnS5LKU24Uq1woHzHcAT8p+Wtf QNOl0rTpbed42d727uAYySNstxJKo5A52uAffPXrRZAaeF9aML60vHr+tHHr+tKwCYX1owvrS8ev 60cev60WATC+tGF9aXj1/Wjj1/WiwCYX1owvrS8ev60cev60WATC+tGF9aXj1/Wjj1/WiwCYX1ow vrS8ev60cev60WATC+tGF9aXj1/Wjj1/WiwDc+5oz7mnc0c0rMY3Pua53XPFE2kXF8sFglzBplku oX7yXBjZYSZMeUoVhI+IZOGKD7vzcnb0nNZeo+HtM1a4We8t5HfYI3CTyRrMgJISVVYCVOW+Vww+ ZuPmOWkIzPB0l/dvrF9fDcsmoXMMMn2ySTckVxLGo8kqEiwqqPkJ343NzVO01fU/7E0nxVJfySQa m9mG0wxxiKFLl40XY4XfvTzFJZmIbD4VNy7Oss7K30+BobWLy42lkmI3E5eR2kc8nuzMfbPHFU4f D2mW+qHUY7eQT72kVDO5ijds7nSItsRzubLKoJ3vk/M2aEc3L4n8QX1v4dvtO0+xjt9Vu1NtHLes DPA1rPKBKfJPlMNkbYTfyCM45NfxT4vvF8M6zJDa/ZrWWLULOyvIroidbiCKcszIFARc28m1g7H7 nAydvSDwlo62726RXaRF1eNUvp1+zlQQPIw/7gbWZcR7RtO3pxRc+ENEu3umns5JEuklWSE3MnlD zFKyMke7YjsGfLqAx3vz8xyAY+peN73R3axvtGjOrM8IhhtJ5biJlkWZgSyQ+YCBbS5CxN/BzgsV uaJ4rvNa1ZLIaHPaqtolzcS3DmMx7pJ49oRlDnLQhlJVcoxJ2EBWuDwlo4t3iMV27u6v9pkvp3uF KggbZy5kUAM4wrAYdx/G2bmnaJp2lSvLZW3lyPEkLuXZi6qzuCxJOWLSyMWPzMWJJJoAy9Rk1MeJ beKx1SSSQvG72CwxiCK2zh5JmIL7ziQJtZQWCjaVSRq5dPEuuRadoNw2pySP4hsoLhw8MWLJpLi0 iIgwo4C3TkeZ5nKJnPzBu0bwzpraxJqi/b47qWVJpBDqE8ccjqqqC0auEPyooOV5A5zUcfhDRIkm RbOQpImxFe5kYW6hgwEGW/cAMqECPbgohGNi4AOXn1/XY9WuPDNu2pX0sNxKDfWq2ouvKSG1k5Em yHJe6xu2n5VA2kkuvd2V9b6npttf2cnmWt1Ek0Mm0jcjAFTg4IyCOtZh8JaObdIhFdo6Oz/aY76d LhiwAO6cOJGBCoMMxGEQfwLi/a6VY2Nw09papA5t4rXEfyqIoi5jQKOAB5j9B39hSAtZ9zRn3NO5 o5qbMobn3NGfc07mjmizAbn3NIzqiM7vtVRkknAAp/NHNFmIbn3NGfc07mjmizGNz7mjPuadzRzR ZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZ gNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZg Nz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgN z7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgNz7mjPuadzRzRZgGP b+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9q LhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc +1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY 9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2 Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9 qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lT c+1Gfai4WHY9v5UY9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5U Y9v5U3PtRn2ouFh2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHY9v5UY9v5U3PtRn2ouFh 2Pb+VGPb+VNz7UZ9qLhYdj2/lRj2/lTc+1Gfai4WHZHrRketGKMU9RBketA570Yrh/HGr3MV/DY2 B1M3FpbPqQSwt5n8yZTi3hlMakeVIRNuU4zsHK9+jDYeVeoqaJk0lc7nHvRj3rg9O1m4W/1bWbG4 tp9IutVskETW7iVxPBaIrhywCgCRW2lCTtIyM5Ekfi7VVt9HuZksnj1mK3uYESJlNtG9xbRsjEuf Mbbc8MAgymdpzgdDy+pdKPl5atXt8l/V9Bc6O4x70Y9647+1NVvfiGLC3uYYLa0+0I6NGziWMJYv yA4AfMzgNyAD905NR6za6lqPjS6gtUeeGHT7Z/LOtXNiqM0lwCQIVIYkIMk4xtFSsHtzStePN+Nu rS/EOY7XHvRj3rh9W8Xarp+mXWqolk9sZb+2t7dom3xyWyTsHd9+HVjbn5Qqkbx8x2/M/V/EniPT 7x7eHT7ad7OzW9vChQRBXeTEfmSTR7AoiIMm185LbFxtLWX1XbVa+fbT89PXy1DnR2uPejHvXB65 rmtfaJrF5k02dry3+xxG1di8QvII/NMyybXVg/zRYRwHwePmbS8WNdrB4fgcXtzJNfeXcR6ZObV5 8W0zHafMXau5Q2C/8PU90sE/d5pb3/BX8l5b28w5jqse9GPeuDi1/XI9L0i00y3e7urtbqcGVFmk ghjlVVikV5ov3iiREclywZGBDElhJdeM9SsoBqN5Zw21m1i1zbwKv2gXjrbGZlS5jbbHjBHzIdwQ spOcLX9nVW7Rae/XXR22+T+SbdlqHOjuMe9GPeuVXXdVs/Etnod81lcSSyxl7iCBoh5bxXTBQpdv mDWw+bOCHxgYyaKeMdV365cNbWTWekW1xcuo3LJL5c93GqDqBkW6EtzggjadwKT9Qqva3R799vvD nR3GPejHvXI6rqnibTp7LTYEttQv7lZpzLbWQVUjjMa7fLkuVySZc7vM7Y2nORJp/iLUrvV9OW8h hsLO+iQ26rH9qF05g81glxG+1NvIwyfOEJUnPyr6nNw5001ZvfXTy36Pp0bdlqHN0Oqx70Y964OZ NauPEmvwWl3cm1vbyPT2PmP/AKCotoZDJFjiMlHn+bnMhh4xurN07VHuPCC6lrX9s3Y0+xtZDHY3 zQSGFrVJXuHPmoZMv5i5y3MeFGQ5O0cubipc3b1123a66b+Yuc9Ox70Y965iy09E8fakRc6gyRWd vcJE9/O0QeV7hXPll9uMIuBjAwMAVJ9lGua3qsF/cXsQspY0toba8ltsxNEreafLZS+XMiZJK/ui AAQ5PO6EVL4tEk3p3t5+a6oq50ePejHvXD6t4u1XT9MutVRLJ7Yy39tb27RNvjktknYO778OrG3P yhVI3j5jt+afUtd8QafJqcjtpgj0vTE1G4gWCRzLuacmNJN424WELvKHJJbaPu1p9Qq6ar+nb89O 3y1Fzo7A8d6Mj1piTRTPKkcqO0TbJFVgSjYDYPocMpx6EHvT8VwtNFhketGR60YoxS1AMj1oyPWj FGKNQDI9aMj1oxRijUAyPWjI9aMUYo1AMj1pkUqzQpKu8K6hgHQq2D6ggEH2PNPxRijUNAyPWjI9 aMUYo1AMj1oyPWjFGKNQDI9aMj1oxRijUAyPWjI9aMUYo1AMj1oyPWjFGKNQDI9aMj1oxRijUAyP WjI9aMUYo1AMj1oyPWjFGKNQDI9aMj1oxRijUAyPWjI9aMUYo1AMj1oyPWjFGKNQDI9aYVJmV/Oc KFIMYA2sTjk8ZyMHoccnOeMPxRijUAyPWjI9aMUYo1AMj1oyPWjFGKNQEx7ijHuKXB9f1owfX9aL AJj3FYt94g0fStYkt5YruTUDbxvIbPTZ7hhEWcJuaJGwMiTAJ/vetbeD6/rXMXXhgal4yvr+8N9H atp9rDC9rqM1vudZLguCInUnAdPvf3jjvTWgGtB4e0W2vo72DR9Piu4lCRzx2yLIihdgAYDIAX5c enHSpI9F0qH7b5emWSfbs/a9sCj7RnOfM4+fO5uuep9a891zwnq15a6rBa6P/wATOX+0Wl1TfEPt 0E0U6wW+/d5h2mSAbXARfJ4Pypmx4m8ETXOrQiytr57RLRYrM2sltm1uPMkaSZ5LhXkjZi8bGWLd IShY5YJnV1qj3k/vJsjrptM8OaNYwh9L0+2tVvIXiSO0Xatw7rHG4Crw25lG7t6gVPquqaZoTxXd 2kgmu3W2Q29pJPLKVV3C7Y1ZiABI3TA59a4a/wDCF5e6hrDDRI7i2luEnll1KK3a6uwl3FKYYpEY 7oDHGyqkwUg+WC23ITpNY0a61G38MR6ak+kR2l2JXEAgD2cf2WZAoUh4+C6pgBhzxwMhSqTl8TuO xpWlloOqiXVYLCyme9iaCeZrYCSRfutHJkbuNu1kbkFcEAjFW7vS9Pv57ae8sba4mtW328k0Ku0T ZBypIypyByPQV59q3hHUbmw0y1u7K7vILJ7r7SlotnL9snldJBdCO6BjUEmbI4ZGcqmUyxJ/CWuN eSrZwyG/OmG3/tbU5Ipmgk+y+WptbhMTqfMOX3RgNmRl2k4c9pO6d3oKx30ei6VD9t8vTLJPt2ft e2BR9oznPmcfPnc3XPU+tTpZWkcdtGlrCsdrj7OqxgCHClRsH8Pykrx2JFcFBoV5a6tb6vpnhmTT dPtLiKUaPEbeOSRxDdRSSoqSeVk/aIckuCREfRA1fTPCGr3A1+8ktJNO1C6srhdNkmuBm2mlub5w x8tmCuqTx/OMkB2CnlhQ6k3ux2O+vNF0rUY3jvtMsrmOSUTOs8CuGkC7Q5BHLbQFz1wMU+PS9Pi1 KXUo7G2S/lXZJdLColdeOC+MkfKvGew9K8+1jwquo29j9j8J3em6ZC8/naXawaaWkmYRbJzHIXhI CpIu7IkGQANpNaGk+HNQs/F1jdS2MlyYbeNLnUNTMNyybbcJi1nBWYEuSXDoFbMjDYThz2k7Wu7B Y0vtHgu1tPEGji00+O00lEudVtFscRIGTzFYqF2udqA8ZPyjvipLXWvC+l2lnJplqRFdWsc8SaZp cshEDFmjLLFGSiktIRuAyd+OQ1VR4R+3eJb7UrxfLVdVW5i5z58It7b5eG+XFxbxPkjP7nH3XOef tNE8WeHPBQstLt77+07i0t5Ueye0PkXEdnFAYphOdpj3RK26PJPzD5cAu3VnJNOT18xWR0duPBtz fSeF4tCi3RS+e9q+iSJArYZRIWMQj5COA+cNjAJq9fXvh/Rdae5exLarPEPNlstNkuJ/L6L5hiRm CnZgbsA7DjO04ntrG4j8ZanftHi1m0+0hjfcPmdJLksMdeBIn5+xqmRqGg6tqk8GkXeqwancLdA2 kkKtCwhjiKMJZEBGIlYMpOdzAhdoLDrVHvJ/eFkdBHBFE8rxxIjytvkZVALtgLk+pwqjPoAO1Ubv w9ot/BbQXmj6fcQ2q7LeOa2R1iXAGFBGFGAOB6CuB1zwnq15a6rBa6P/AMTOX+0Wl1TfEPt0E0U6 wW+/d5h2mSAbXARfJ4Pypk1zw7BJ4m1XTNM8P/abwaJbJY358onT53lu8TtJI3mBi5Dl0DOSpJy2 MqNScXeLsx2PTBBEs7ziJBM6qjSBRuZVJIBPUgFmwO2T61RutL0fxBb20+oaXbXiBN8IvbQFowwB PyyLlDwMggHjnpVq3muJJ7tJ7XyY4pQkD+YG85Nikvgfd+YsuD/cz0Irz/wn4Y1LTNV0OW40n95b afbw3Vzfpby/Zylqsfl2kiOZE+fO5WBQ5kKkE/OozlF80XZhY7p9F0qS6ubp9MsmubqIw3EzQKXm jIAKOcZZcADB44FQT+HNKute/tm6s4bm8WKKOJpolfyfLZ2DISMq2XOSD/CvpXKeI9D1e98ZWmow WE7SQXdoLe7tUtFRLUSIZllkk/0gMQZ/ljO0qyjBJcGv4q0s6t4y1i3ttE+2ak+iWqWWoYhH9nSt JdBZdzsHTDbWzGGYbOmQM0q1RbSfb5CsjuNTu7TQtJ1PV5IMRwQvd3HkoN8mxOT2y21ABk9gM0mq avbaQ1mLhJ3+1SvEnkxGQgrFJKflHzH5YmACgkkgY5rgPEXh7XrzRZtDttGnlZbvVbpbsTQiFxcQ 3nlqMuH3brhFOVABDc4AJr654Q1LULK7GieG/wCybOSKRE03dbxYlNnexmXbG5j+cz26ZzuOzkBV BrN67jPS9T1CHSrVLidZGR7iC3AQAndLKsSnnHG5wT7Z69KuYrgJPDt0ZrlD4f8AM1NtVium1n9x ++txfxzCPeW807Igo2lQB5WFzhc6Hg/TNl1NP53m2OmebpWl/Lt2QrL+8HXJwUjh+bJP2XeD+8NK wHT2d5bahA01rJ5kayyQk7SMPG7RuOR2ZWHvjjirGK88j8GCS/gt7jQo/L/t24vr68Qxqt5DIl2U DFWDuF86ONlcYO5gAyZNU9Z8MeI77xLdXdhBPZ39x9qibUYPssNv5TW8qQZkT/SmYN9nLBsqHUlR hUwWA9Dj1CGXWbnS1WTz7e3huHYgbSsjSKoHfOYmzx3HXsatqEOjaNfapcLI0FlbyXEixgFiqKWI GcDOB6ivNL3wfcXt5dy6f4Vn0bSn+yefYQR2Ae72C63YjLPC2Glgb95j7mR8yrRqvg2/bw5dWcvh 6fWGm0p7bTUnktZH06YvO247jGkeVkgGIQQvk7RkIhYsB6vijFcx4p0s32o6fcXGif27psMUySaf iFv3rGMxy7ZmVDtVJVzncPM4GC2OX1zwnq15a6rBa6P/AMTOX+0Wl1TfEPt0E0U6wW+/d5h2mSAb XARfJ4PypksB6fijFeUeLfCsumaJ4iu7DTILS1j+1hGgCRhbE6Y4MYA5EZuiW2f3zvx/FWhceHLu Wz1COw8M/wBm6NdfZ0m0lIrMysUMrPLHGWe33MzW4Jc5KxNwCsZJYD0fFGK8osvA+pSaLrEt3pG7 U49KaHRpbo25nt5VnvGiCMh2xMqPb42FVXAAxtwOksrOGHxPqUst3Gmi6LcS3g8zCLBdTxh5csTn CLJLJk5U/a8ceUMFgOzxVPU9Qh0q1S4nWRke4gtwEAJ3SyrEp5xxucE+2evSsjUlvtf8EW12lhJB qBS11FdPkba3mxPHP5BZsbSWTZuI4zkjjFcveeA9Tlkjtrlo9TtIXgdjJFGi3BmvLaa7yhPADW0k uDkH7RsXiMAlgPRzKi3CQESb3RnBEZK4UgHLYwD8wwCcnnGcHFePUIZdZudLVZPPt7eG4diBtKyN Iqgd85ibPHcde3AX3g/U01m6Ww02NNHieTyLWJ40jeAtpzyQImQAJPJugVOFJY7iA+TJe+D1vYNZ u7LwrBp9wuiJDo8TR26yWt0r3TZjKMVjbc8T7lYckHOQcFgPR8UYrmPFOlm+1HT7i40T+3dNhimS TT8Qt+9YxmOXbMyodqpKuc7h5nAwWxz9p4U8S6cgna5+2XllFb6gh3K32y9W3it5I97nIzHBIu9h j/TN2N0QJLAej4oI96840zwFLo9q7Q2UE2p22oaaltqIREme1iitI5iGzuRSsc4KZ5BYc7udjwNo t1pH2/zdO+ywyeWEmu4oBf3LDcXe4khZkl5YbWOG5bcCfmYsM67HuKMe4pcH1/WjB9f1pWATHuKM e4pcH1/WjB9f1osAmPcUY9xS4Pr+tGD6/rRYBMe4ox7ilwfX9aMH1/WiwCY9xRj3FLg+v60YPr+t FgEx7ijHuKXB9f1owfX9aLAJj3FGPcUuD6/rRg+v60WATHuKMe4pcH1/WjB9f1osAmPcUY9xS4Pr +tGD6/rRYBcj1oyPWmcUcUcwWH5HrXL+I/H2h+FtRjstRm2yGITynzYk8qIkgNtd1aT7r/LGHb5e mSuel4rF1bRrWS4m1V9Vu9MQW4jvZIZUjWWBCzAO7KTGF3yfMjIw3E7uFIE7hYW58VWNm90l1Ddw mySWa73RZEECKWExIyCjAfLtyxO4YykgTLuvFl1aa/pa3unX1ha3EUsbW03kO7yNcWcMT5jdgFBu Gz8wPU4OBWpc+FbG8e6e6mu5jepLDd7pcCeB1KiEgYARQfl24YHcc5eQvXm8HxXpik1DV9SvbiFH WGeXyVaImSGVWASNVJV7dGGQRyQwYHAoQXnjOytdWfSYbO7u9SFw0CWsTRI0u2GKZ2QySKpAWZMj O7qQCFJEcXjSzS21B7lJ2ktfPaNVhCG58u5kg8uFS53yBkRcZGTLHwpcKK8vguxvor/Sr3Xr69W7 lW71G3mFsTcKVSNA4EQKLi3wrJsbIYhsgEaieFNNU2ZYSObW9nvUL7TuaWR5WRuOUEjK4HZoozkl c0AU7Px9ol94obQIZc3QlkgRvNiO+WMMXXyw5lXGx/mZFU7eCdy7o/EPiie2mFpptpduYdTsbS6v VEXlQmSaHdGwdg5JjlXlVIG8cgg7dSz8PpY6i1xDqF8LUyyTpYb1EKSyFmdshQ7ZZ3O1mZQWyANq 7a9/4TgvtRa5XUb63hlu4L24tIfKMc80JjKMxZC44ijBCsowvTJJIBl6f8UPD2pGb7M8jpGizB0k hfMBkRGmYJITEieYrN5oRgu44+VgLGsfELRtFdo5xIz/AGiSCPM0EKTeWqGRkklkRCFaQIRu3blc YO1iNDTfC9tp9u1m93d3mni3NpDY3RRoIYMAeWFCjeNoVcyF2wDz8zbo/wDhE4IrPT4rLUb6zurG J4VvYvKaaVXKtKZPMRlZndFdm27iwJyMnIBl6Z41F5eagtpBd6uJrhZNPgtUjjb7L9ltZGcmVkGN 1wOCd37wcYBxctPHVhfThreyvn00y28P9pbYxDvnSJ4htL+b83nxD7nBbnABIjPhzSotbkisddu7 LWnQ3HyXEctwICkMLfLMrlkJt4iXYFtyn5uSDX0bwbbRXV4YdSkbRVvYXttPt5EeIG2ihiXe5Qyb 0lt+gfHyANnLAgFjTvH1lqCWcjaZqVrFdJbyCScRERx3Dbbd2CSMcSPlQACVKkuFGCadt8VNAvll +wpPdyDyzBFBLA73CvLHEpAEv7v5pY+JfLb5umVYDUt/BWm21rb26T3ZSC30+3Ul1yVs5TLET8vU scN6jpjrUdl4UsHsYreLWL65sLSWJbWATRmO2FvMjCIbVG7DQqhMhZwFYBgSxIBHH4wnuPEthpcG kXeXS4W9gfyvNtHQ2xVmPmbCmy4DHYXPzLgZDCrGv+LYdIfU7RLe7a4stMbUZJltxJFHHtlwWy65 O6LGzIJ3DHAdksHwvbLrcmsQXd3BeSXBmd0KEMhSFHiwykbGFvESR8wIOGAJFSal4bs9U/tfz5J1 /tXT10+fYwG2MebgrkHDfvm5ORwOOuQDn/FHjo2Oi6m1hZXyMIr2G01LbCYftMEMzsNpff8AK0Eg 5TBK9wQTYvvGl1BfafZxaDfLfS3axz2EpgMxheG4dHRhL5fLQMOXzhW45UnPu/BkviC+KpqO3wtN 9ouYkt7lJfMa5hlR2QeTlcm4kcMZZF7BQCNnSal4XttQ1RtUF3d2t+EhWKeAoTCY/OAZQ6spJW4l U7gRgjABANAEmleIoNZ1G9t7K1ne3s5ZLeS83xeX5yEB49ofzAwJP3kAIGQSCpOOnjyCN71ZdPvp 4bDzpby7hjiSO2hS4ni3MrS72wLdydgYkDIUE7RsWvh2C38Qz65NdT3d88TW8TzJEvkQl95jUoil lyBjeWIxwRubNMeCtNFrrdv593s1i3lt7g71yqyS3EpKfLwd1zIBnPAX0JIBY1LWruy8VaTpcNhJ dQXtvcSStEUDQ7HgUOdzqNgErZADN0wOtc/ovxBit/B2nX/iK3u7W4k0yG6E03khbwnykZ0KPtQF 5o/9Z5YHmA8AMV6i8sLa+1m1njvpLfULFMkQshYwSMCUdWDYR2hHzABv3Z2sOc57eCtNaw0q08+7 A0uyFnayB13LteF0kPy4Lq1vGw42nkFSDigAsvG+lah4V1LxBB5j2+mpK1zHG8crKY0EhUMjtGxK lT8rkc4JBBALnVdS8PWFzrHiO+00WCIMW9rbsjRyO6qimZ5drDLbdzJGOQx2AGtS10lItOns725n 1NbjcJ3vtr+aCNpUoqhAu0AbVUA8kgkknPbwsZYJLa413Vbi1+QwQzNC32d0dXjdX8ve7IyLjzGf d/EGyaAM+y+IdjqvkJpOmX2pXEvnb4bSW2fyvK8rdmTzhG3E8R+Rm6kHBBAjtfiBC41S9exu5tHg uLVLW9tYQ3mLPHbFAY93ml83GcBPugAZbg7ll4fS01GDUJtQvr28iimiMty6neJDET8qqqrjyUAC hR94kFmJrL0zwbpUel2ken6ldyaaUsplVJI3Sd7fyTFNu2ZJKwRqdpCkZIAJ3UAWL3xpp+mazpul 6hFJa3F+kRVZLi33RvIxRUMYkMjHd8u5FZRnO7AYiPTvEptPhrpXiLVW86R9PtprhvMhh3vIqZOZ GSNeWzyR6DnAqxf+E4L7UWuV1G+t4ZbuC9uLSHyjHPNCYyjMWQuOIowQrKML0ySTJ/wi9smg6Tpd vd3dudJSNbO7QoZYykZi3fMpQkozKcqR8xIAIBABlxfEXTLmBrq1sb65sYbQXl3dwmFo7WPfKjFv 3mX2mCXPlhwQuVLZGZLjxRPc+ItGtLC0u0sJtTntJr1hF5UxjguN0ajcZARLF12gHYcEgjdJb+Bb CDTNWsnvb6f+1bSS1uZpGjDkPJPIzDagUNuuZO2OF44ObEfhOCLWLa9TUb4W9tdy3sVh+68lZpVk DtnZ5hyZpGwXwC3AAAAAK97rWpw+KFspJoNPsfNjSNp9NmmW5VgvIuFdY4WLExqjgtuUHneooi8d WEi20j2V9FDe+U1jI6xkXcUksUQlUByVUGeIkOFbD8KSCBoXugnUNRWe61W+ks1ljmGn4hEIeMqy HcI/M4dVf7/JGD8vy1nx+BbBIEhe9vpI7aJYdPDNH/oCK8ciiPCDdhoYT+98z/VjOQW3ABL4slPj SHQ7TTp7mNfOjunTYDGyi1cOCzjMYW55wC2RwMDmPwV4on1jRtGi1S0u4NQutMju1lmEW27AWPzJ E8tjtG6RDhgh+cYHBxYsvB8Vlf8A9ojV9Sl1BrhppbqTyd0qMkKNEVEYQIRbxchQ3y8MMnNzTfDd npf9keRJO39lae2nwb2B3RnyslsAZb9yvIwOTx0wAZ//AAkl5/wm39neXB/ZPm/2fu2nz/tnkfac 9dvk+Txn72/tjmo9O8fWWoJZyNpmpWsV0lvIJJxERHHcNtt3YJIxxI+VAAJUqS4UYJk/4V94b3+f /Z0H27+0P7Q+3eRH9o8z7R5+PM2525+XHXZxnvUc3hjQdD0mN7zUZLWztLfTrcz3M6IqraTeZCWY gDLM2G9eAMGgCnbfFbw3drK0DTyqvltGIDHO8qPLHEHEcbs64aWP5HVXOcBSQQNBPF5N9c2SaXfX V+kuBYwpCkkaCGCRyztN5bbTcICQw5bADBS5kh8G20NrDZtqWpSWds8BtLZpECWyQypIiKFQFxmJ F3SF2wDhgWYmS48JwSancanaajfWN/PK0jXEHlMVVo4Y2QLIjLtP2eI8jdleCASKAD/hMNMXxf8A 8IzIdl83EZ8+Ft7eX5mNiuZF+UE5dFXjryuc8eJLq38R6893HfNYWEsVlbpCsHkyyyJAyLyfM85n n2gkrEFIyQQTWhH4Tgi1i2vU1G+FvbXct7FYfuvJWaVZA7Z2eYcmaRsF8AtwAAALE/huzuItTRpJ 1a/u471nVhmKaNYljZOMfKYI2wwYEg5BBxQBTg8ZW0+qW2lf2bqSajK8iSWxjRjblPJZvMZXKAbJ 43yGII+X7+EOf4r8Uanpr+I7SytJMWWhfbor2MRkW8pW5wXDtlgTCm0Krc53cYrY03wvbafqi6ob u7ur8pMss85QGYyeSCzBFVQQtvEo2gDAOQSSaNZ8L22sveM93d24vrJrG7WApieIq4UHcrEFDK5B XGSfm3AAUAZ9/wCP9P0i3kOq2V3p92jxqtpdS26M4kEhRhJ5vlAHyZfvOD8hGMsobc0TWrPxBpEG p2Mm+3m3AHIOGVirDKkqcMpGVJU4yCQQTT1LwvbahqjaoLu7tb8JCsU8BQmEx+cAyh1ZSStxKp3A jBGACAat2D2dtjTF1L7VdxbjIJpw8zN8rOWA6f61DgAKodAAFKigDRyPWjI9aTbRtpaj0FyPWjI9 aTbRto1DQRRtZyZCwY5AOPl4AwP58+tOyPWk20hAFK7AdketGR60zijijmCw/I9aMj1pnFHFHMFh +R60ZHrTOKOKOYLD8j1oyPWmcUcUcwWH5HrRketM4o4o5gsPyPWjI9aZxRxRzBYXJ9KMn0pOfT9K OfT9KkYuT6V5x8S9UaPTtfsLzW/7Jtv7Fd7VMwp/aErCYPFmVWLbQsXEe1h5vJ5XHo3Pp+lHzf5F NMDzq11nxLqfii+05NZsbOSSW7t1td6zTWkaiQQz/ZxCGXO2J90kpRg/ABdADU/E/iKfSRqcTwaT azXcdjL59xGqWjRxymeQztG6r+/At/mRlPl5X/WqR6NlqMtT5hWPKbbXNRTVhcX2rwWkdzaWcN5q 8BXZFAJNRMcoeWMR/OUhXeYwjeZ8gAZCCXxfqQe9L+JPJurbT/O0qz224/tdxcXSRnBTdJ5qQwH9 yVz5mVxuXHq2WqullBHqM1+seLqaKOGR8n5kQuVGOnBkf8/YUcwWPObvxDr1rbaherrM7eVFrN8k LQw7FFlc+XHDwm7y2Vvn53/KNrLzmvqfizxLbz+IZU1SxhktYtQK2Hmq80EcSSmGbyBBuTdsibfJ KyMJOBl0A9Wy1GWo5gsea6/JeWniKx0++8R3cdnYXFvfPq8626PbCWC+iIZvLEQQtHGoLJnMhGcl cdJ4p1Q2Oo6fb3Gt/wBhabNFM8moZhX96pjEcW6ZWQbleVsY3Hy+DgNnpstRlqOYLHE+AG1G+u9Z 1XUZZ7e4nltjcad5apHHM1jaMxwV8wMCSuC2AO2ea5+z1690uDUF0LVP7U1IahrBk0TbHL9nCvdS I+yNRKN0ixL8zEHzsAZZcerZajLUcwWPLb/U/teo2Hl+LZLnRbG9inbxArWpFu7294jxtIsfkgD9 wMMuQZxz8yY1PD0t7p11ZOmozy2upeINTtXs5Uj8uECW7k3IQgfduhH3mYYZuOmO+y1GWo5gsec3 8psvEOvhtR2zT63pjx6bMkLK8RexjNwqsm84YMgYHaGXjDDIr6N4h14WOl3VzrM90z2mj3UqSwwh ZDfTGGRTsRSFQLuTBB3E7i4wB6dlqMtRzBY8d0HxHqFj4I0qLQtcj1QDR7c3ZkeErpLb7ePBeOP9 2BHJO2ZQ+PI3EEK4boPDusa/qes6XZya7aT2bJdzPPabbj7SkTWu0Cbyo0J3SyKWRMbcr/rBvX0L LUZajmCxwPxG8VXvh/57G+gspLS0e7C3l1HDHennESBonaVhs+ZUaMgSJ82WBWvc674i0/Tn1W2v Z9RuLnUNUs4NOlt42jXyBdtEEEaLIWzbovLHIZuMkEejZajLUcwWOJ8IXVrd+Mtdks/Ef9vRjT7E G68yB9h8y6+TMKqvHB5Gfm64xWPo3iHXhY6XdXOsz3TPaaPdSpLDCFkN9MYZFOxFIVAu5MEHcTuL jAHp2Woy1HMFjy3wtrOsN4ctNUOqSCKC40mxXT0t4Et9k8FmHOFjDgg3DsArAAhRjAwa+n+K/Fdz ZiQ6vpou53sxNbqwuWsJpLqCMxPGsMflDbJKpjkkaQ7flbKO1etZajLUcwWPPdc8TahpPirT7GHV YwIrizspba+uYY5b3zXRWnjhEO5xiQ/MsiKHjb5MIQ1PwJrV15nhrS5NS82H+yrUR2VhLA/lKLRW L3aMvmx5Y/KyNtOYwQpPz+nZajLUcwWOJ1HXr2DxRPbLqnlXUeoWtvaaRtj/ANLtXEPmz7Svmts8 yf5kYKPJ5B2vk8Hanq0v/CO/2hqs+of2xojahL58US+TIv2fiPy0X5T57ZDbj8q4I5z22Woy1HMF jgY/FV63xHttPS+gFrc3cto+mz3Uf2iERwyN5ogEQdVZogys0rgpIDtG4bS48RXUfi/UrWLxBuu4 NVtLW30T9wfMt5I7cyybdvnHaJJn3BsDZz8qkV32Wqvb2UFpPdzQR7JLuUTTnJO9wixg89PlRRx6 euaOYLHA2Wual/wj3hm413xT/Z0Op6ebyfUhHbwKsuyHy4AZFZBuV5XII3MyMV2qNgr6V4s1a6vg 15rHk6z9r0+L/hHdkS/u5YbZp28sr5/yebO2d+F8vnIVgfTstVe3soLSe7mgj2SXcomnOSd7hFjB 56fKijj09c0cwWPLdP8AFfiu5sxIdX00Xc72Ymt1YXLWE0l1BGYnjWGPyhtklUxySNIdvytlHaty 2i1Ky1rxTFZaxPLqyyw3Vvp032dTfRxwWoaTlAR5hR4S4OxSSQuVrvstVe/soNT065sLyPzLW6ie GZMkbkYEMMjkZBPSjmCxgw6xqk/g3V/EFmn2qSaKa70m18rdmIR/uRhcM3mbRJg4Yebs6rXLzXk2 seIdHsLDxRPqFjHqEbw6vB9mkdJWtL3zIgyR+UcKkZwULDzck8rj07LUZajmCxzPinVDY6jp9vca 3/YWmzRTPJqGYV/eqYxHFumVkG5XlbGNx8vg4DZz9O1jxLdT6VZXafZ7rVIrbUGbylT7JEiIbqHy 25OHCLljuH2vjPlGu2y1GWo5gseS6f4r8V3NmJDq+mi7nezE1urC5awmkuoIzE8awx+UNskqmOSR pDt+Vso7V2HxASGD4W6/He3shCaZIv2iSURNJJswuSm0ZZsDaAA27bjBxXVZajLUcwWMHxBcadrP h680lL7/AJCulXMkMtvE1xuh2KrSIE+/jzUIUHLZ4zWX4E/s2O41KDS4fD80CpC7ajoVosEErEyD ymCu4LoFDH5uky/KOrdllqMtRzBY8x0bxDrwsdLurnWZ7pntNHupUlhhCyG+mMMinYikKgXcmCDu J3FxgDl9BvZTeaVdFIPMl+xbgIECDeNCB2pjavU4wBt4IwQMe7ZajLUcwWPLU8Uaxc2ditvr0j3d 6lr/AGkkccDNpE8l1bRmALs+QlZpxtm3t+665Vs9hpeqXdpaeIUu3u9TOj3BSNkiQ3Fwv2eKbG1A qs+ZCoAC5AXvknostRlqOYLHlOneMdSknnsbnxNYtYJLbm41m0vLe5+yJIlycGXyI4ky8EK4aM/6 08ksu3Un1rXE03xDfWGtR3ttZ3Fra2kjJEqiKSK1aS5eVUK4VZHkDBNi5YsrrtVfQstRlqOYLHls ninWIdGtpLjxBaTQm4mVJNLuoJb29AWPasBlgSG4Id3DCNFPCKCzqyt6XBfW91NdwwSb5LSYQzrt I2OUWQD3+V0PHr65qfLUnzf5FDkFhcn0oyfSk59P0o59P0qRi5PpRk+lJz6fpRz6fpQAuT6UZPpS c+n6Uc+n6UALk+lGT6UnPp+lHPp+lAC5PpRk+lJz6fpRz6fpQAuT6UZPpSc+n6Uc+n6UAL+FH4Uu R60ZHrTEJ+FH4UuR60ZHrQAn4UfhS5HrRketACfhR+FLketGR60AJ+FH4UuR60ZHrQAn4UfhS5Hr UYaTzmBCiIKCrBvmLZOQRjgD5cHJzk8DHLsA/wDCj8KXI9aMj1pAJ+FH4UuR60ZHrQAn4UfhS5Hr RketACfhR+FLketGR60AJ+FH4UuR60ZHrQAn4UfhS5HrRketACfhR+FLketGR60AJ+FH4UuR60ZH rQAn4UfhS5HrRketACfhR+FLketGR60AJ+FH4UuR60ZHrQAn4UfhS5HrRketACfhR+FLketGR60A J+FH4UuR60ZHrQAn4UfhS5HrRketACfhR+FLketGR60AJ+FH4UuR60ZHrQAn4UfhS5HrRketACfh R+FLketGR60AJ+FH4UuR60ZHrQAn4UfhS5HrRketACfhR+FLketGR60AJ+FH4UuR60ZHrQBGIkEr SiJRIyhWcKMkDOAT6DJ/M0/8KXI9aMj1oAT8KPwpcj1oyPWgBPwo/ClyPWjI9aADcfSjcfSk596O fei7AXcfSs6+8QaNpc6wajq1hZzMu8R3FykbFckZwxBxkHn2rQ5965ubSr678Y308Oo6hp8P9n2q CS3jiKysJLgkZkjflQRwMfe56ii7GkjSPibQRdS2p1vTRcRb/MiN3HvTYCXyM5G0Ak+mDmnx6/o0 unS6jHq9g9jE2yS5W5QxI3HBbOAfmHHuPWsHxHZXU/8Awl/k200nn+H44YdkZPmSD7V8q46t8y8D n5h61U1XSr+4kvItWt0v5rufTkDW1owt5LaK6RmDIS+1gZJCwJwU2kfdfBzMfKjs/ttr9u+w/aYf tnled9n8weZ5ecbtvXbnjPTNC3tq3l7bmE+ZK0KYkHzSLu3KPVhsbI6jafQ1y+kaDdaZ4rsri5km u5TY3UL3chMhEavbrCrOQPmKIzkdC7SkcGqmoafq1nqtzJaRu1jp051WCOOMszmRl8xE4+aQgXw2 k4H2iLGONhzPsLlR1Muv6NDP5Eur2Ec2138trlA21Cwc4z0Uo+T22tnoavGaJZ0gMqCZ1Z1jLDcy qQCQO4BZcn3HrXnes6dd2mnJpptrm5vn8O6ktxLbW0skUl1N5bthgu0F3SUheOwAGVB27nWrdvEe mamLTVTaJaXduzDSrncrs9uwBTy9wBCtg4xwRnIo5u4+Xsb2oazpekeX/aWpWdl5ufL+0zrHvxjO NxGcZH5ipLrU7Cxnt4Lu+trea5bZBHNKqNK2QMKCfmOSOB6isfWLXVJvFelzabLDBssbtZJri1aa MZe3IX5XTDHaSOeinj0pWVjB4aW80y5sLzULe4iht7Tbbm482BIEiEMjAbU+YO3z7U/ek55fa7u4 rKx0NzrOl2d9DY3WpWcF5Nt8q3lnVZJMnA2qTk5IwMd6ZYa/o2qztBp2r2F5Mq7zHb3KSMFyBnCk 8ZI5965qyhvdImsbW3udSm1Y/ZV1CM2rvaXLhI0lmM7x/eES5GJBlkA2liQ29o0MsWq+IXkidFl1 BHjZlIDr9lgXI9RlSM+oPpQm2DSNH7ba+T532mHyvN8nf5g2+Zv2bc/3t/y465460Je2skdtIlzC yXWPs7CQES5UsNp/i+UE8dgTXE/2Jqf9leb9s1Lb/wAJB539n+TH5fl/2ju3f6vzNu395ndjHP3e Kg+yahqHhjQNCsYry11XTrZo5pZYJYY4JBZSw7llK7WxI6YKFiR8wyBmlzPsPlR2D+JtBjkuY31v TVe1z9oU3cYMWGCncM/L8xA57kCrVhqdhqsDT6dfW15CrbDJbyrIobAOMqTzgjj3rhdbv9QuUXTb OxvLbTYfs0nlwaPKstkYrm2+VW+aOXC+awCKRiP+IcnpV+0ar4Sv7XT76/N68E0EV3f272sokZTt bHlpgAsPmVe3cg0KWoOOho22s6XeX01ja6lZz3kO7zbeKdWkjwcHcoORgnBz3pkmv6NFp0WoyavY JYytsjuWuUETtzwGzgn5Tx7H0rk9T1XWpYbrSdF06aCCSxNvBH/Z81q1jKXihX98NyOqiSR8xjAE XBI5qCaPUNKs72wuNG8i1/tLT7y1i0uOW5iij81DIihYlxt8h5DgYzKO5GTmDlO6j1OwlSV4762d Yp/s0jLKpCS5C+WeeGywG3rkj1qO21nS7y+msbXUrOe8h3ebbxTq0keDg7lByME4Oe9cNJpl/Yxx PBY3Lx6jrubmJImJjZNRMqTkAcKYgwZznIWHHAzW94cd4b5LLT31KTRorYqEv7NoPsxUoIo4y0aM 67fMyTvI2Lkgn5hSYOKNibX9Gtr2Syn1ewiu41LvA9yiuihd5JUnIAX5s+nPSi11/Rr6C4ntNXsL iG2XfPJDco6xLgnLEH5RgHk+hrHs3e28RLbaU+pNavczNd29zZtHBCG3u0kcrRqWYzFeA7DDtgYA K0p7XVG8Mpp1rYeZLea3c+atwzRxiAXU0x3kI3ySImzkYIlHUHBOZhyo6W61/RrGC3nu9XsLeG5X fBJNcoiyrgHKkn5hgjkeoov9f0bSp1g1HV7CzmZd4juLlI2K5IzhiOMg8+1cZY2XimLUoYLa2s7O 4sItQiieaOWe1aOR7eWKNWHllVAbywQCAIWwvGBtw2XlWng+3tLa8WCxufKZbiP95EqWs8eXxx97 A3D5SSCpIIyKTYcqRsDX9Gad4Bq9gZknW2aMXKbllYkCMjPDEq2F68H0qe41OwtILie5vraGG2YJ PJJKqrExAIDEn5SQy8H+8PWuJu9OOt65d2j21/HC2umXz/szx+Wo05olljdlxlZU+VhnDBT3XMem /wBrrqV9rOoWM0RiuZonC2ckqrcfZ7aJbiOIfPJFmOZQy/Ntk7AuVOZhyo7b+2dL/sv+1P7Ss/7P /wCfvz18r7237+cfe469eKn+22v277D9ph+2eV532fzB5nl5xu29dueM9M1y919t8QeCYBqNj5ss upQLLCbN4xJCl6o3GJ8sqmNdxDdic8VlXfhXUYtRtyfO1CZraVJ5ZH3ma3juLTbAzsAC0kMchKsQ rPJKeFY4HJgoo7OPX9Gl06XUY9XsHsYm2SXK3KGJG44LZwD8w49x60++1nS9Mz/aGpWdpjbn7ROs eN27b1I67Hx67T6GuT1+3PiS4hubXT7l7ENb292lzZvEbj/TLdwDG6hmVEWYksNoEhwTl8ZyLqGn +LreS/tNSng0yW3tzeJayzmeMQ32x8qpLttmhDkDAct0GKHJgoo9Bl1Owg04ajNfW0diVVxcvKoi KtjadxOMHIwe+RT5b21g8/zrmGPyIhNNvkA8uM5+Zs9F+VuTx8p9K4m6sNUvryOG30iGfTLy+m1E 2t+7RReUIkjEcieW4VnldpwrDOVyQHztfbaXf3mneHo9ShuRclm0zVCrM4uIod7CSQsoLK7QgDcM FLmQdXzRzMOVHbJPFI8qRyI7xNskVWBKNgNg+hwynHoR60/cfSsvS7V7fUdclYnFxfLKvyMMAW8K dSADyp5XI7ZyCBp8+9O7JsLuPpRuPpSc+9HPvSuwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouw F3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0 o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0 pOfejn3ouwF3H0o3H0pOfejn3ouwF3H0o3H0pOfejn3ouwDj1NHHqaOPU0cepoAQjJUh2GDkgd+O h/z2rGutY1FNcm0+w0yG7jt7aK5mZrvy5CHaRdsalCrN+6P3mUZI5HWtrj1NYt1o+ovrk2oWGqQ2 sdxbRW0yta+ZIAjSNujYuFVv3p+8rDIHB6Ua9Bq3UZF4il1IedoVkmoWkao80jzmFjvRZFWNWX5m 2Op+YovzKN2d23PXx7BIutyw2nmW9jYm9tJfMI+2III5n4K5jwJohznO/gcEDQi8Oy6aPJ0K9TT7 SRUSaN4DMw2IsatGzN8rbEUfMHX5VO3O7dn6h4CgudA1DSrK7+xieVWtZPLMn2ZBbJbMuC3z5iVx knjfnqAaHzDXKWrrWfEFnPZQHSbCRry7mt4i960WApmdCQI34MUSnOc7mxtFWtX8Q/2Trmk2D2u+ C+3+bceZjyMNHGny4JbdJNGvGMZyeAcXb7T/ALbeaZcebs+w3LXG3bnfmKSPHXj/AFmc89Md6h1L Q4NVvklujvt/sNzZSwYI8xJjGT8wII4jxx/e6jFOzFdGJp3jS61S4tRbaVCLe41I2aSyXZBMRgFw kwURn70WTtJBB2gnk7X2/jGW4sry9FrYGG3VS0S35ae3Z2AAuU8v9wFG4uctsCNw2KtT+HLptcj1 CDUIUQal9veKS2Llv9GW32Bg4x8oc5weSvHync8aRrL3Yv59UsGvoYHgtmSwdYlV2RnLoZiWP7tQ MMuOc7uy94fulvS9SutT0d71E02R23fZ/sl8Z4ZMcDMnljHzAg4U4x36VjweMZYILa51m1sNPtJ9 QlsPO+3llRoxMGZi0aAAtCAOed/YjB29J02WwF3Lc3CT3d5P587xxGNNwRIwFUsxA2xr1Y85PAOB Vg8PeT9g/wBK3fZNSub/AP1eN/nef8nXjHn9e+3oM8P3haFGLxh9u1KCHS4LO9s5NSNh9qS9+Xi3 E5ddqMGwN64yOVHPJ22vD/iGXXZ5sRWEcMagtHHemS5hYnhJotg8tsBsjccFSOetMn8OXTa5HqEG oQog1L7e8UlsXLf6MtvsDBxj5Q5zg8lePlO61ZaXf/2rHqOqX1tcTQwSQQra2rQKFdkZi26R8nMa YxjHPXIwlzX1G+UItUv767J06xtpdPjnaCS4numjcsjFZCiCNshSGHzMuSp7YY52l+OtL1ZdCS1u LOW81PHm2sV2ryW37h5TuA5OCm05A5P4VoxaXf2N2Rp19bRafJO08lvPatI4Z2LSBHEi4DEsfmVs Fj2wopXHhSWTwzpGkwam9vNpsHlJdJGQxb7NJAHADDaQZN3X+HHuD3he6VT42nfRb29t9I824SW3 NlbfaQv2u3uJBHBLuK4Ted3ytyNvOMirp8WQTXUdvYw/aWura2nsSWKCczCZgDkfIoSBnJOTjICl sBqp8B2VvdW0mnXVzbQxLAjwyTyzq6wzxSxgb3O0KEkUADjzSe2C+Pwd5GsahqUF/seSVJrFDDkW sg84vn5v3iu1xMSDggOQpGFKr3x+6M1TxXf6LPZ22o2uiWk10s0ge41do4QsZjGN7Q8sTIflx0XO T0G3qOpS6ZojXk1uj3YVES3SU7XnchUjDlRwXZV3EADOSAM1nS6Pr0t9aah/a+mi8t4poc/2bJ5b RyGJvu+fkMDF13YIbpxk2tV0M63aafb310+2CdJ7gWzPCJ2VWwAVfcoEhVxycFB9afvai00KSeJb +8Omw2GmWz3d1BcSXEdxeNGtu8LpHJHuWNt5DuRkAA7cjIIoh8T3l/fyQ6XpSTx28CS3AmuvKmVj JLG0artKMytA4yXCk4+bHzVBB4Qu9L1H7Vo+qpEqtcFIr6GW6CLN5JcBjKGyZIWfJPWQ8dzPD4Yv LC/km0vVUgjuIEiuDNa+bMzCSWRpFbcEVmadzgoVBx8uPlo94fulrU9eeHQbPVdKt4b2K7lt1j82 ZoAUmZURs7GPV1yCBxnuMEttV1SbxNc6XLp1mlvBEkzXC3rM5jcyKnyeUBuzEcjdgZ4Jo1PQXm0G z0rSriGyitJbdo/NhacBIWV0XG9T1Rckk8Z7nIuxaf5WuXepebn7RbQ2/l7fu+W0rZznnPm9Mcbf fh63FpYpXOq6pD4mttLi06ze3nieZbhr1lcRoY1f5PKI3ZlGBuwcckVHB4illS2v3skTRbto0tro Tkyt5hCxs0W35VYkAYYsNy7lX5tujLp/m65aal5uPs9tNb+Xt+95jRNnOeMeV0xzu9uc6Dw7LElt YPeo+i2jRvbWogIlXyyGjVpd3zKpAIwoY7V3M3zbjUNCTV/EP9k3E1u1rvla2WSyXzMfaZTII/K6 HZ88kA3Hj97norVHP4iliS5v0skfRbRpEubozkSr5ZKyMsW35lUgg5YMdrbVb5d2jfaf9tvNMuPN 2fYblrjbtzvzFJHjrx/rM556Y71nT+HZZUubBL1E0W7aR7m1MBMreYS0irLu+VWJJOVLDc21l+Xa O4KxJ/wkP/Eo+3/Zf+Yl9g2eZ/09/Zt+cf8AAsfhnvUGgeI7rVf7P+26fDa/2jY/brXybkzfux5e 4PlE2t+9TGNwPzcjAyf8I5dbvsv9oQ/2V9u+3eT9mPn+Z5/2jHm79u3zP9jO3jOfmo8P+ErXw3HZ jTzDE6W0dvemOAKLvYp2uQD8r7iTnJyGYHPylV71w92wS+I7qHVLuNtPhOn2t9BYvOLk+aZJVi2k R7MbQ0yg/PnAJweAZ/8AhIf+Ko/sn7L/AKL/AKn7Z5n/AC9bPN8nZjP+q+ffnb268VBJ4StW1a81 iMwpq0lytxbXZgBeHEKRbDzl0IVsjI++cYYBhB/whNv9o+2/brz+0P7S+3+f9pm2/wCs+55e/Z/q f3Ocfd7dqPeH7pPoniO6v7fS7jUNPhs4tViV7NobkzZJjMmx8ou1tgYjG4fKwJB27qsXjKW40y5u YtNQTefbCzje4IW4t7iURwzlgh2BjuOwgsNvI5FFv4SvxoNvplzrKE2NobfT5rW2aFoX8kxCVv3j FmCscYKj5icE7Ssc/wAPtLLRJazTRWflRQzWtxLLcxyxxTxSouJHICgJIoAGMSn6FXlYPdN/SdSl vxdxXNukF3Zz+ROkcpkTcUSQFWKqSNsi9VHORyBku0vURqdm9x5flbLm4t9u7OfKlePPTvszjtnH NM0nSodGSW2sykenljJDbLHgQMxLOFI/hJOQuPlJbBxtVZrCzSwtnhUoA0803yBgMySM56k85bnn Gc4AGAKuLQtcepo49TRx6mjj1NIQcepo49TRx6mjj1NABx6mjj1NHHqaOPU0AHHqaOPU0cepo49T QAcepo49TRx6mjj1NABx6mjj1NHHqaOPU0AHHqaOPU0cepo49TQAcepo49TRx6mjj1NABx6mjj1N HHqaOPU0AHHqaOPU0cepo49TQAcepo49TRx6mjj1NABx6mjj1NHHqaOPU0AHHqaOPU0cepo49TQA cepo49TRx6mjj1NAB/wKj/gVH+etH+etAw/4FXKeJZr+3v5bW2lucaxaLZwPGzD7LKJNpkXHVtk7 SYGDttjzjler/wA9aY8UUjxPJEjtE2+NmAJRsFcj0OGIz6E+tIE7HCXPiG7vNKutQdL+zOoNaaZF awJLLJE20yXMkexciRFklU/Lw1tzk/KAz/2p4Stt91qsdzp+qQaezGe4tZnja5iQGUZUszwMjEkd XJG08DuFtLVfL22sI8uVpkwg+WRt25h6Md7ZPU7j6mhrS1bzN1rCfMlWZ8oPmkXbtY+rDYuD1G0e gosO5hQWCapqeoWV5c38centFFaxQ300LNEYkPmsyuGkLPvXcxI/dHGDvJx/7S17+yt2yH7H/wAJ B5P2r7dJ5/l/2js27PLxtx8mN+Nv5V12oaRper+X/aWmWV75WfL+0wpJszjONwOM4H5Cp/slr5Pk /ZYfK83ztmwbfM3792P72/5s9c89aLBc5TWLXUdQ8ZXUFsjzww6fbP5Z1m5sVRmknBIEKncSFGSc Y2iquv2zWd14tuLe91JHttE+1wgahOUjlcXQZgu/aPuLgYwu0EYruBFEs7ziJBM6qjSADcyqSQCe 4BZsD3PrTJbS1n8/zrWGTz4hDNvQHzIxn5Wz1X5m4PHzH1osgTODu/tUmm6pYQz6xpUTXOnQCKe+ L3cRkuFWSVJN7/IyMqjDEbo5BgENnR0ebWZvGVrPqsrxGbT7mI2kbOsO6GSBTKEbuzvLtbvGY+hz XVz2lrcyRyT2sMrx/caRAxX5lbgnp8yIfqqnsKeYomnScxIZkVkWQgblViCQD2BKrkew9KLBc4fX 7ZrO68W3Fve6kj22ifa4QNQnKRyuLoMwXftH3FwMYXaCMU9NXuNE07xDcRQX8JtYIltdP1GV7qdr l9wUjDuWjkZokGGxuSThSGJ7KW0tZ/P861hk8+IQzb0B8yMZ+Vs9V+ZuDx8x9aJ7S1uZI5J7WGV4 /uNIgYr8ytwT0+ZEP1VT2FFuwX7nAWFz9qmsPDrX2tvDBqm0S3b3FtdXFu9pNIpdzsYjzUkUYxxE vHcvuP7Tv/EUWl2rzXVpa/a0hL6rPaeaifZeWliBMjI8ksfP907iWBJ7W+0jS9Tz/aGmWV3nbn7R Ckmdu7b1B6b3x6bj6mmXWg6NfQW8F3pGn3ENsuyCOa3R1iXAGFBHyjAHA9BStoPmK2sl7W30qwjm mitLi5W1uJ/NbzEj8t9v7wnIZnWOPcTuJfghiCOa1hdSj1m10TSNRuVjhu4pIZJbmR/332e6lMEs mSzR5jhZlJLbZOuCgHcfZLX7D9h+yw/Y/K8n7PsHl+XjG3b0244x0xUdvp1haQW8FtY20MNsxeCO OJVWJiCCVAHykhm5H94+tU9RJ2OROuS6h4R8bajbT3MRjWUwKzlZLVhZRMU4PyMrlsgdG3d6papN 4j0uaxdJbmZtMa4tLaLdI39osLSeVGlHHmnCW4yMfvPOwPumu7TTrCOC6gSxtlhu2d7iMRKFmZhh i4x8xI6k9ankiileJ5Ikdom3xswBKNgrkehwxGfQn1pW8wv5HD+JpX0bQJLnSNVvLl76xupJJWu2 lyi20kguI8HEeHEYzHtT96Bj7m2jqt9exX9hoE1/eLLbbbeVkuHR7iFryyWOUsCGLGN3RnGPnEoH Fd5HpGlxfbPL0yyT7dn7XthQfaM5z5nHzZ3N1z1PrReaRpeoSPJe6ZZXLvEIXaaFHLRhtwUkjldw Bx0yM0NDUjlNY1KTR01DRre4v5beRrW3hkj825uInlLmdUcbnLJCnnDdkruHVSi0y21fUBoNveWU 8zXVhcyaS8WopKnmeYypbSSqwDFzm2dm4+WSXAyQB2Nvp1haQW8FtY20MNsxeCOOJVWJiCCVAHyk hm5H94+tSNaWreZutYT5kqzPlB80i7drH1YbFweo2j0FFhXRkamkthYaNpi3dybaWdLO5vHkPnbP LfBMnGGd1RN3BzJ8uGKkZc89xZ6v/YcN1cnSWnt4prp53eWAyJMzRecSSCWS3AyS4+0AKRuj29dN FFcwSQTxJLDIpR43AZXUjBBB6gjtUEWnWEGnHTobG2jsSrIbZIlERVs7htAxg5OR3yabEmc/4h0W 3s9Gtxb3eqoRqFqm4arc7istxFG4J8zJBXIAPTJIwSTT/IjuLzVI73Uryyi0ny1tmW8ePZD5St58 hY/vfn8wZk3L+6Ixnfu2rXSNLsbU2tppllb25lExiihRE8wEENgDG4FVIPXgelPutOsL6e3nu7G2 uJrZt8Ek0Su0TZBypI+U5A5HoKNB3OA0+91q4vH1e9E1swvtPimAvZh5DSxWu+IWjfuypaVgWZty 7iwBZRlllBqMfgCy1K4+3tPdLpwDwa5cyy3CyTRb+HKrEzA4+VuNxG4Dr3/9kaX/AGp/an9mWX9o f8/fkp5v3dv38Z+7x16cVBa+G9BsZDJaaHplu5xlorWNDwwYcgdmVSPcA9qnlHzFbwpLLJaXyv8A aY447to4ra8mMtxbqFTKyMWYklt7qdzZR0IOMAZdzqGp2Np4l+zXTz3I1m3trZrhgBEsy2y7VwpC hfNbHytzyQ5znrhFEs7ziJBM6qjSADcyqSQCe4BZsD3PrVWPSNLi+2eXplkn27P2vbCg+0ZznzOP mzubrnqfWq6WJvqYVlPdmbS7KOG5iaw1R4L5Vu5bpdptJJQTK+GZcyRfeAw2AOik9V/wKqtvp1ha QW8FtY20MNsxeCOOJVWJiCCVAHykhm5H94+tWv8APWgGH/AqP+BUf560f560AH/AqP8AgVH+etH+ etAB/wACo/4FR/nrR/nrQAf8Co/4FR/nrR/nrQAf8Co/4FR/nrR/nrQAf8Co/wCBUf560f560AH/ AAKj/gVH+etH+etAB/wKj/gVH+etH+etAB/wKj/gVH+etH+etAB/wKj/AIFR/nrR/nrQAf8AAqP+ BUf560f560AH/AqP+BUf560f560AH/AqP+BUf560f560AH/AqP8AgVH+etH+etAB/wACo/4FR/nr R/nrQAnFHFOyP8mjI/yaLAN4o4p2R/k0ZH+TRYBvFHFOyP8AJoyP8miwDeKOKdkf5NGR/k0WAbxR xTsj/JoyP8miwDeKOKdkf5NGR/k0WAbxRxTsj/JoyP8AJosA3ijinZH+TRkf5NFgG8UcU7I/yaMj /JosA3ijinZH+TRkf5NFgG8UcU7I/wAmjI/yaLAN4o4p2R/k0ZH+TRYBvFHFOyP8mjI/yaLAN4o4 p2R/k0ZH+TRYBvFHFOyP8mjI/wAmiwDeKOKdkf5NGR/k0WAbxRxTsj/JoyP8miwDeKOKdkf5NGR/ k0WAbxRxTsj/ACaMj/JosA3ijinZH+TRkf5NFgG8UcU7I/yaMj/JosBG8ccqhZEV1BDAMMjIOQfq CAfwp3FOyP8AJoyP8miwhvFHFOyP8mjI/wAmiwxvFHFOyP8AJoyP8miwDeKOKdkf5NGR/k0WAbxR xTsj/JoyP8miwDeKOKdkf5NGR/k0WAbxRxTsj/JoyP8AJosA3ijinZH+TRkf5NFgG8UcU7I/yaMj /JosA3ijinZH+TRkf5NFgG8UcU7I/wAmjI/yaLANz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/I oswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yK MH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaX B/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mj PuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswE z7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKz/td 5c/8eVpsjPHnXWY/xCY3HHPDbM8YODkFmNK5fz7mjPuaZBHKkKrLL5snVm2BQT7DsOw6nHUk81Jg /wCRRZiEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaX B/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswEz7mj PuaXB/yKMH/IoswEz7mjPuaXB/yKMH/IoswGtux8rYOR1GeO9Ln3NLg/5FGD/kUrMBcH0FGD6CjH uaMe5qhBg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NAB g+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQU Y9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NA Bg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQ UY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3NABg+gowfQUY9zRj3N ABg+gowfQUY9zTQ6Fygf5wASueQDnB/Q/lQFx2D6CjB9BRj3NGPc0AGD6CjB9BRj3NGPc0AGD6Cj B9BRj3NGPc0AGD6CjB9BRj3NGPc0AGD6CjB9BRj3NGPc0AGD6CjB9BRj3NGPc0AGD6CjB9BRj3NG Pc0AGD6CjB9BRj3NGPc0AJk+hoyfQ0v+etH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560A Jk+hoyfQ0v8AnrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ0v+etH+etACZPoaMn0NL/nrR/nrQAm T6GjJ9DS/wCetH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ0v+etH+etACZP oaQs28LsbBBO7jA9v8+lO/z1o/z1o+YCZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ 0v8AnrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ0v+etH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS /wCetH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ0v+etH+etACZPoaMn0NL/ AJ60f560AJk+hoyfQ0v+etH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560AJk+hoyfQ0v8A nrR/nrQAmT6GmlFMqymMGRVKq+BkA4yAfQ4H5Cn/AOetH+etACZPoaMn0NL/AJ60f560AJk+hoyf Q0v+etH+etACZPoaMn0NL/nrR/nrQAmT6GjJ9DS/560f560Af//Z ------=_NextPart_000_000C_01C6F11D.45398160-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 01:14:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZKnt-0006bb-O8 for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 01:14:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZKnr-0006jw-5k for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 01:14:21 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id BE6E91448062 for ; Sun, 15 Oct 2006 22:14:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 6A27D4A4196 for ; Sun, 15 Oct 2006 22:13:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 32726398016 for ; Sun, 15 Oct 2006 22:13:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id AFEC4398023 for ; Sun, 15 Oct 2006 22:13:34 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2006 07:13:29 +0200 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9G5DR6r024112; Mon, 16 Oct 2006 07:13:28 +0200 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9G5DPVt016225; Mon, 16 Oct 2006 13:13:26 +0800 (CST) Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 10:43:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Oct 2006 10:43:25 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01F0024F@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] discovery interval timer question Thread-Index: AcbuQsegD8HYWPJNTViRL8R625fUfQCnr5KA From: "Smitha Smitha (ssmitha)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 16 Oct 2006 05:13:25.0128 (UTC) FILETIME=[CE9C1080:01C6F0E1] Authentication-Results: ams-dkim-2; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Scott, Thanks for the clarification on discovery interval timer. Do we really need the MaxDiscoveryInterval timer now, will the use of this be clarified? Thanks Smitha -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Friday, October 13, 2006 2:27 AM To: capwap Subject: Re: [Capwap] discovery interval timer question Sorry, I meant to reply to Pat, but I was distracted. I've added some comments inline below... > -----Original Message----- > From: Smitha Smitha (ssmitha) [mailto:ssmitha@cisco.com] > Sent: Tuesday, October 10, 2006 3:40 AM > To: Pat Calhoun (pacalhou); Scott G. Kelly; Capwap@frascone.com > Subject: Re: [Capwap] discovery interval timer question > > So, MaxDiscoveryInterval is not specific to an AC, in that it is a > global timer which decides how frequently we send out Discovery > Requests. But "DiscoveryCount" talks about the maximum # of > discoveries transmitted by the WTP to an AC. > > Also, the spec says: > " A WTP MUST send no more than the maximum of > MaxDiscoveries Discovery Request messages, waiting for a random > delay > less than MaxDiscoveryInterval between each successive message." > > Is it OK to assume that: > 1. DiscoveryInterval timer is the delay between successive discovery > requests sent to the same AC? > 2. DiscoveryCount will be obtained based on DiscoveryInterval timer > (when the same expires). > 3. MaxDiscoveryInterval - why is this needed? > 4. Transition from Discovery to Sulking state occurs when > DiscoveryCount reaches the max limit - for a particular AC? > > However, this does not cover the case of being able to "select" from a > set of discovery responses obtained at the WTP. Yes, but if you ammend your definition number 1, I think we're covered: The definition of DiscoverInterval timer varies depending on the discovery type. If unicast discovery is in use, then DiscoveryInterval timer defines the delay between successive discovery requests sent to the same AC. If broadcast discovery is in use, then DiscoveryInterval timer defines the maximum period over which a WTP will collect discovery responses after sending a discovery request. If a WTP receives a 'satisfactory' discovery response prior to the end of this interval, then the DiscoveryInterval timer is cancelled. Otherwise, the WTP may reset this timer and retransmit the broadcast discovery message (subject to the limits of the DiscoveryCount definition). Scott > > Thanks > Smitha > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, October 10, 2006 8:35 AM > To: Scott G. Kelly; Smitha Smitha (ssmitha); Capwap@frascone.com > Subject: RE: [Capwap] discovery interval timer question > > > Seems like the behavior varies depending on the discovery > method. For > > a broadcast method, it seems reasonable that a WTP should wait some > > reasonable period to probabalistically ensure that it has received > > whatever discovery responses it is going to receive before it acts. > > Otherwise, you could have kid-in-a-candy-store behavior (I'll take > > that one! No -- that one! Wait... I want THAT one!) For a directed > > discover, obviously the WTP can act upon receiving a response. > > sure, but that seems like a logical "implementation specific" > condition. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From lcopycat@developerone.com Mon Oct 16 01:58:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZLUr-0002rF-0y; Mon, 16 Oct 2006 01:58:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZLUp-0002us-Rk; Mon, 16 Oct 2006 01:58:44 -0400 Received: from [218.54.88.11] (helo=YUBKKI9) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GZLUn-0004mi-Ld; Mon, 16 Oct 2006 01:58:43 -0400 From: "Fern Person" To: "Bridge-mib-bounces" Subject: so cartel Date: Sun, 15 Oct 2006 23:01:40 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00FB_01C5092D.76B43EA0" X-Spam-Score: 4.4 (++++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 ------=_NextPart_000_00FB_01C5092D.76B43EA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A0_01C5033A.74B50DA0" ------=_NextPart_001_00A0_01C5033A.74B50DA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable otherwise than as my letters darkly shadowed it forth. But another There is nothing I can say, sir, I returned, except that all the engaged. You are too solicitous about him. He is very well. Mrs. Strong, I said, there is something within my knowledge, ------=_NextPart_001_00A0_01C5033A.74B50DA0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
said Mr. Chillip. Mrs. Chillip, comi= ng into a little property in
3D"""SRC=3Dci= d:DfEfCdbAbB>
bear the climate, my dear. Mr= s. Markleham - you have not forgotten
I thought I was, when I proposed to Dora; about the ch= ivalrous never should have been got into my present state if I hadnt come<= /FONT>
to know no further interruption. Now= , welcome poverty. cried Mr. Availing myself of this permission, which was= given with a warm
Without more directly referring to any = latent ability that may Mrs. Micawber and his eldest son and daughter to p= unch, in
opposite side of the little to= wn. When I had made this discovery, the old lockers, on which Mrs. Gummid= ge, with a basket on her knee,
indignantly assured him that t= here wasnt room to swing a cat There was a beggar in the street, when I we= nt down; and as I turned
in some way associa= ted with the lost girl. But that one dark the kitchen to keep off the ink= , the time she took, the innumerable
in the day, and we = had still three or four hours before dinner; but Then, said my aunt, after= a rest, theres Dick. Hes good for
She was going to my= rooms to see my aunt. The day being very fine, would sit down with the t= ablets, and a little basket of bills and
When I found myself on the fam= iliar Highgate road, pursuing such a days had done its part to make me wha= t I was, so greater calamities
Agnes is downsta= irs, when I go into the parlour; and I give her the I had often admired, a= s I have elsewhere described, his benignant
you fool. while theres time to retreat.= Wheres mother? he said, about as I do, to find it out soon. Whatever I = know, you shall
meal, and the orderly silence of the pl= ace - which was bare of scarcely know that he is struck, so I, when I was = left alone with
The only member of our small society wh= o positively refused to should say, Mister? fawned Uriah. Dont you find M= r. Wickfield
sure, now, that it was right to do th= is, but I did it for my in a moment to the image of despair, Mr. Micawber = regarded the
mastered the alphabet, which was an Egy= ptian Temple in itself, You are very lonely when you go downstairs, now? D= ora whispers,
my correction; and would have = been, one day, a little later my school days, his veneration for the Docto= r was unbounded; and
mine, she is like, one day, to make her own poor solit= ary course to by age and sex, in her, to a gracious dignity. I thought, m= ore
------=_NextPart_001_00A0_01C5033A.74B50DA0-- ------=_NextPart_000_00FB_01C5092D.76B43EA0 Content-Type: image/gif; name="revision.GIF" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhTgFIAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8AAAAP///wkpsnyzH3DA jKnTJ/bAV33gJRxg/3AtX4H504UBGDg9ghNwgL0hCIQgwMmw3hDIiKPJlRDIvRSxP0xjWBL4Moxw uBCHCOBBekb4Aa5+0AYuSO0IXIgSjNKAgwYMoAhrOloNYJQfPbRhAA3ggn+yw7I7aCEOJMBDEfBQ hNjgwkOJEQpqoKBxoECBFhQ0gKiQoIWCAhNE6NhAQIMEHSwkcODAgAMLJy3YzDkQp82dPBMm6Igz OGNNI40/hWAYQGZ9x1ib8tGMnMwwxYwopoCw97rIF7FR+KAFFgUKRjmT0cNGQA63EyEfaImLzAig yJLEwRIosbGHfIi5kYnWMB/GmE8soYkRPSSgM48O2w0bYyGTyIpmyQ3m4AgQSh2GUolBkYqsGN6b gpDwKqysMUa/4Steocvcd0GTIlUFJFCNASoIBBpPU2BzwRrhLHOC/FzQyExdgchUihlC1DKBIZbJ 2IHRZAHUBM3Y7MzejMz/gzmX1WxNHHhNczHN1owB4ry+GNhM1Tyh3dQQ3qQB0ozM09xN56xN0fTM okZ8dbF73URqtHc48KZPwNS8CJFrqAZO5NcSA9EdocZFSCco+MNr+mN1aFF0rkZ0LPE55oQ2zQOO VVvIRwbCPweGrnkC8MpdFhIRA+4EhE+5YNfwSTB7ivKh+tyXurxXk7ukKCKacZ7/KAkwM3byNR/j ARYcRmgwkKDAhwcVgASZ0aCFBgYiZGywYiVLlhESJuAhkccEhQYRBBBo4eLACTIWAF3A4YsIAESU CVKOQuUC2cQoWp7lk4v6ZFcuAY1M1MSlh0Y0o/rqZZGGckuXbPRXAaoOSHc5UpJG5SGDc8mSLMoc 7dEhbQMcfdEgzdEfDdIqDdIkbdIY3dEn/+3RJR3SMn0DLX3SOC3SK73SFW3SLf3SHS3TKk3SNW3T 5dTwTN6NqcAAAP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAbgE9AQAI/wAhCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KdKYDBwKfRoUK4alVqlelVsXKtaBWrQSvRvU6texWsVO/ ZlVrdWDWhG3dUpWL9u3Zt2Cb6l2p1mxes2Ghgv3b1+DguVX9dvU6F3Hew4oRxgVMObLcwHszqyxc GDPjx4jThr6c1q3lv1slO268GHVqyJ49g46tuTZJqbhZ17U7ufJd1aa/0tUd1y5pwJxHv2b9ufhi yq5tS+e4Fjbt0td9H+9K/Hjg3rMV9//GbN23cejKp6vH6Jw5Y8PglUdPPRb7b+3ew9PPfbB6ZdT8 0TbfegRO1Bl92QWIYHbbCbiaYfk9eNposBFG4XMLFqihRgeuJVpyH7oHn3BhOYjWfd7dJaKFpHno IYLlDbjhjDTWaOONOOao44489ujjj0AGKeSQRBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnllVhmqeWW XHbp5ZdghinmmGSWaeaZaLLUQANBrZkmQ24KFKeca84JgZ130mlnnXvyORCfbP4JqJ51FjQoQn4S dCihcwIaqEF9CqpoondSKiiekxZ6KaaYvjkpnZ+CqqeikpYqp6inVooqp482+miekLb/aqqrpdIa a6iR/ilqrrAa2uqvqAbrqa+qmrprsb3aeuuyys4aaKfELlsrsMiySiyv0TZ7EJ5xdvuqsMMSGm2t 1TqLqLXVfpsuuNKGOu274HKrqbG4UpuQvLuqC62n89Lb7bGrqrvpr5Q6yqi99wqMb6UFIyxsv+wy PO++Dz+7KL3hSjwuwKra6y2rFsP7aa6Wsruwm32WXPHJmtpKMbL5+ivwsCi/erKkHtuscMgxZ4sw uhsX6y3GQdfsrtDUvsyyzBn77G6jmRrrcr0imxvwtrJerbXS3w5ttbJQr6s1zGRn3OzFXVuc8sQN t92yzgPPXDLacL8M89mHGpzpz5bq/01001/afZPggGdJ+EyHF6744ow37vjjkEcu+eSUV2755Zhn rvnmnHfu+eegh07SAgeR7pDppr+Uekari97TArC3bpDsENBee+yzx2T7Q7vz7vpKq/dO+/AEtd77 ScczlLzyv6e0e+ypRw996dTXLlD0A01//e2z477996R7b/314oePuvfQh599+bcH3zxKtrs/vvwF ET9/9t+Dbz/4+HPP//j6Qwjqipe/+WGvgO8bifQG2D8GInB9sGsg/g74v9z1z3oUvB8ANVg9+XmQ gA9MIEiMV0AGelB8EgSg+sinvfilD4QlrCAHWRjBDTpwhhkUYUhIaEMZJs+EE7wgDP/rJ0AVgvCG SDyiElOYv+XpECMfTKH0qvc/+vVwg0N0YBJxGEMmcvGKT0QeCrWnwgi6sIZfhGAOi8c+/bWxfTl8 IQvLiEb6OTGMQbojHiGnxz368Y+ADKQgB0nIQhrykIhMpCIXychGOlI9M3ukTABASQBAwJIvqaQm E4JJjPhNkpMkCCVR0smClPKSIkEZ2QTASgEkhJUFaaUrQVmRU6LyJLYUyClzuZFEvQqWEABmLIUZ zFkSk5YQ4eUlMTnKgViymc9kZiVFuUxnTtOU2EQlNEXZTF1eU5e+KhkwjzkQcgrEnMhkiDJvyc5v upOay2SmMxGiSWh2857zZGc7Y2X/qXHO0iDmRGc6F7LOTpZyl9zcJDgXqk94GgShDLWmQrclrnIa 85/DBChGB/oQWxo0nxHVJy8/GlKQZhOkHnWIKu3kT4QcU6AcJahDb9nNhh7UoSRtqElnus+F3jSk quxVMc95UYIQE6YxJeg3rVnNeEo0oQYd5TWX6lRT3vOqB12qLS9GVGF6tZUWlWVSlRTJsZr1rGhN q1rXyta2uvWtcI0rU8oqwk3mVCP1rClH8qrMdaozr2riqg6z6k2K5HKbTfUIRPcqz8RuxK8r/ZZA xRrWjTZusX7l5EFymlnDnvSxKFXsQnxpVHS2dKiofZxe56lXrcaTqjx9LTW3aU96/2YzmhHVKmxj O1FtSvOZ3rQnPveGKdMWFbVIBRxVEdvTdypksTTFamF1+lrhMpWhjS3pTn/qXJrCE7oHy+hBTnta yg23p+ilLk8BG1LObta2OH1oPTUr3/M2d77q1ZXGSuvS45bXcZgNLXZj+1n1Bli7Iz1pShuyS/cm dKfaHdkqLUvUCiOXwoqrqYPR+1P6mvSuHH6viAXsXQhv97oifeh3CxxUyWKUvP7FcOGiKV13Sje4 9GytjaNK46o+1ao8/nFw+6pj3OoWq0EuKVcpm1omFzO5cu1JhytC1yjPaMpWnlJvs8zlLnv5y2AO s5jHTOZeCrYkjqryX7c8lM6auP95rsoamh02ESwHZbUEDiO3InYRoCUOvhH+SUEFSbc0fyzOa/Mz mwr1tk/mVqJZjfRspYnN2kJ10lZt51S762Pffm5ReMOZ17wWTrZtTWD4TXFz87lp7Fr6rr8dcFO5 y00BTzV0b5Na0nhG6qfxmmBl0yaQb61gEneYs6necKSzK+sQby5tYxMbqVV26mBRu8QIVnGzYW1s QDt4uAd2tuZMLbZqI220u7Y2xLrN6nZv+8PsfrdPs8tceac3c59MM3EPVjOV6TtuR3uwqzVM8CBP c9M93rHBrzprqfbYxzvutCMdTWU1l1kp2pJIUC8OyWtDZN0cD7nIR07ykpv85J7/W7RQG2LxZ1H0 Xg/pWpdledF/gvXJ5+wzqT6uUoWU1eIrB/paYUl0VxY9mEhPOqn+pbZR9S1di/6YuBg9qqAzHdh5 alvVVR71PyuypUcnOtIpfPVUwcrl0M66rlx+Klmhfe07z/rb2852/bo9ZHWPKdiNzneckx3uZme7 yuM+eLVLrPCDV1vhVwV4wwedUclKldAT+dWhHr2cONev47M2d80j/uyGAvznFRb4yMtZ8qFH/crT Wfmwv3jsuIq86hcvNNOX3u1tB5XNGj96zat+87/naOv77tWcYzTqZmeY3e8G9XzVHfl4t/rzt65r 6s9+rEf96uszn3ydo7w2k/f5//fHT/7ym//86E+/+tfP/va7//3wj3/TCvAQ+r/E/iTBv0X0nxD+ Q8D/OqR/AJgRA1gRAtgQBViADFEADIh/Clh/CGgQD/g7DhgSExgRB7iA/UcRGXiBGviBBOGBoWN/ /NeAA9GAFSgQKHiCDKiCJsiCFdiC//eCIViDMyiDLoiDL7iCNxiCOHiCB8GDOQiEMkiDQtiDKgiD DqiDMziESYg59FeCQPh/U0iCVVgQKZiFKUiFWGiDWTiFXgiGVth/UviEXriFY8iFX8iFaliFWwiG lkODZpiGY6iFNqiGPJiBbAiHdDiHSjiHefiATAiIReiDO3iFT9iHN1iILPg5af/IhoqoiC7oh3to hpAogWGYiIjYhpbogwsRiZtYiZc4iqDYhVgogo6DhptYh3DIia74iG9oiaX4ipRYif7Xgasoi7lI ipS4hqYoipOjh0a4ijuog3I4jIYIgEJ4hMtohCRojAO4jGJ4iIYohjA4jdDIhz+Iiu/DjQ7hgd4o fxohhwT4g58ojuiYjuq4juzYju74jvAYj/I4j/T4O25mFPfYJb11ZNyWWAVXa/O2W6pGbG+2WQRX kDgVVQA5ZDP1Ww6XavKGcMsGYmbSj482kAq5bSRlZ6p2b26GbAiJUhk5XfZGkRGmbPGWZ2NikQnW bsDFbN7VWODVkSDWWRAFXPn/BW8v6W7OxpH5tZPHRmIFViYsmWMKBZTtBU4yOZTs5ZEMdlvY5mHC hpPY5l4N5lq2tZPxBpH5qCVbZpID6VNJGZNj2ZBCmZMnRpZVRZAltpGQJnBv1ldTmZAaBl8CqY9l 2ZJi2ZZQKWw2pW32FmjrJZaZRWvRdZQX6ZNyqZWypphvYpFhyZMleV0cGZRlaWLKVpiDGZnippcj Fm5g2ZVZwl0F14/QhZUNJ5Ck6ZA0Vm9wqWlPOZaGuZcBWZceJmkYyWlgJprJpB68qVa/2Zu2EZz1 WJzGWUsdlRnESZwxwQAMMBDPiSY+iRHMaZTVGRHXCZkTxWZsJmSyFRHOCZ3U/wklYJkR1/lZ5+kQ 2SmUszllh5WSDfGc0RmdEOCc9DmfAnGf4YmWRQKTCieSN7aP+CRcC2aQH/WQuOlpa3lwQtads2lg ZzlitNmV8pmfFnqh+FmfF6qSRkKVjelubhlf9xWheklpHzpvIhaiVQmYfhmX26lOt9WdCoGf82mf NKqhNTqUSbJcPLmUKGpriEmi3naRK2pTBElvzfZhrfVjDwpotKlTu3WjGloQFVqh0Emf6UkjzKai PipSSAqlIppnKrpqT8qlJwqmknmTKyZTayqYBqGfG3qf4kmlIUkkKEmmNXmmW4qZbbqnE0qkX2qm 6AlvaUqoncmhb3qlV0qfU//aqPaJqHZKl7b2lhB3ZNulmpaaW5lqpAyXZPeWpMsGaVfpnqWZpXUW LqbqpsIZE6maEjb6qrAaq7LKn15yl4aFZ8g5E616nLzaqzghT9V5j+t5nl3poTWBk56ZnCCxq9Nx oETaEcNqEeWZlZcGE1SZnsxaoELirJ8KWuO5nHVaaYbaEtfqrR+hrUAil5xKqZoWoJuKW9/5XAMa qgKqmUb5lv/ZoN2lrpI6bAD6mhHHrgwpcTiymMWGp5JJptEVoQeLZ98WkiUakRD2pS0qoU/asEl6 sYIapsxKFER2YCG6kZaJX5Z5mycJpLYKoX+6st9plc+lbbgastvZaqKaseL/liPqOrIgqqRnaqh+ NaYcq6px2aNEq7Dc6qSaCphdyp4w+akbhrMmq6csu7JjOq0Ke7BF+rJF+7BUO64W+5cYa7R9mbXw WbBO6qlcinACq5syCpdExmG4Wl8J+m38CKpaG6OHta+liWPe6aCx1iMdG64SEbguAa5SuaqLk61x e6uEW7i5irSI66uSO7lFsZ5IwZy72rjmSSZWm21CyxOaO7hy66kEy7emW7osCiadS12rC7q/mrpi G7ZkC7lNka/xCnGs9q6rZVeZWq+t+Zpui2SV+o8D67SbSrBoy1yky51Ka7OCapIS6bapCbw0Eahb e71KObFCyrqTWlJHS7EU/1u0Fbu9OVtgzzux++q82Ium5Mu1NxGkRXq+Gsu8GumaEUm/3Ru7LRta 7zlwJgqzhIWyyqu1G5u/4UuScFtvJBu6q2q9XfvACOm+TduTdyu1EAy+3Du1u7uQs5aw3bq+BerA BibCfipfxwrCFmymFCnBnqu//Cu+JGy3n5mx6KqmF9y8+hvDHxy/hXqZk3Sk9VutyEa6tTbEI8lU Q3yvpku3e5teETuwu/W3nTazoVpfAGubU0y8QGZsbDm8dSWtNcLAjhScYnzClHvG7Le42KmseqG5 jRusX9K/nyu6ipWyopUSb3y4emwSZcyqM7ysdzzHm4vHJcGvbKoSfYzIBP86tkust+6qxfCKv1as lL/boNMrW8kbs8IrsPrKYw8Xr0l2lE1crQpqu7gLWK3rE0CbvSIasgn7vE97sj8auw6bwhFswfG1 sQ6sy+o7y/K7sI+WyCGxyhInvyLbyvDrtENKkz27vzcst7icllm7y/BLstpbplubzDclzIB8sdj8 wLAmwj4Luz37y7Qsvgbcy+kMzjgcpvl7zoPKWrXrwYeKsLK5vt3anoBaziiszM+cyzB8orzsz1H5 yyUsyIJmXz57XvSmtsWLu6Tsr5a8tgo9s+3KsNXMyY18py96utal0R3dyXObaQidrudqrjfixnQM xk1ix9ipxmsMtYW80p7/hcY2fdMVTJ7kzMeD3J+xyWAuTavqGdR4TNQXkcqBLLhIndI/fci0iq2C i0uQ2tPCjK5RCxT1KsBZ7MlQXGRSTGBG/NDpi7VbPdExKcVRzEnzers761sI+l4fXbzvtMhCvLsH d7zVe80tysIujLV5q2J87bLtDLSw/MLeu8wMDbN7Gcv+iM6+rNcrvM5m3K7fK8Ak/MQ/uc3rnGys y4//C8/tJcmt7M7Zi6yBqalADMWkfbP3a9RSzbLl2sxX61in3byBDdcpKqY6jGWD9sclK8+mzdod udmrzdju+7oaHLSgDdl6PdwGLabwudsA3cI8jNGSra3Pzcx+Pdg2y6p1/zvOA8fFqBvXEn2pA3y6 KhveHt3EV+md5Q3RD63c1RTZV7zJo2qQ6I3E//q+bHxnKF0b3Py1Jt3UWP3fAP7DAY7TCp5OhFus 5HokeayjAE7FgE3hkzydh5yPM4lLognThEzgMQ2jNhLCbcqwBV3TQm3ifNzhCS7hO62eMD7i7RyV 3X3ieOtRd63F4tq3qQ2+MVvbZQpbLxrXWU3JdgXZkEzX3/1dri0UIR3WNU7MB0zBsmzLi+3YsG2X 2wvMoP2/mq3YUzvNvbzUlQvkUy7bs9uTMqqzN8zYYg7Rxt3D8avNs5Xb3lzNGT22LT7Ts43laD7l x322/VzZ3mvNCGbo7P9bwuL8rMYKwdE85lHdZvhcwA3ZkvTd1+Btzr+dmHyK5VU76JsJ5is60PRN 5ndGvDieoO794/kc26i7ruxK59RLk2kNoKlek5u8xCSd3rrLcFu9YKbOFHvOEsPu1CUNxyRX7AYq 4MZO0wv+7OsI7Ch+4DXd6OO5rTSO1bo51cz+0grt4mqNYiLhrBu+4oMrrE0euTue4nlNzyX97vHc 28l0xMMszztcyCzOxtn6ssHuuAYqsom90Zkpx5Qava9e2hetpzcG7h763a6s3qIemqhN4qWc66c8 X+Wp7CKOwzrcp+rMwRns5sAt5irc3BKa3R3v8bIc54/9zPZl7ZHux77/jct5DuX4PfH+29syuY8l TtCC7vL2ns+tHdDlzeaHqcB1vsc68cTSDfRuisH3vqYTzJkff/KgzsrGm+fDdt68Ndp3bpbyLmgq 3/TVneb6nOWHrfJ7PWCX/vNlf9Btf+Zn3/XE/c0QG/OFO9Y+bt+2rtG3S9eXnPb7bbQLz/BbHOts 2d4sytWLD9Kpa8psO60Y/pih1NM7YbksTbsz1u5HffkeDuIh3u3QPvqkX/qmf/qon/qqv/qs3/qu //qwH/uyP/u0X/tawqi4/6j5qfsEYaMJ4fuLyqioL6dziqHF36jIf/zEn/w3PTMZuqF0GqcMIfxT uvxx16tcl6jCT/3S5Q/9CEH9zy/82e+rILefvb+ou8/73B/951+fwB815O944rn90Y/73n8Q4A/9 jDr+8Y//+l//AAFBIAQGAgsORIjwoEKDDBM2SBhR4kSKFS1exJhR40aOHT1+BBlS5EiNCxcSdHjS pEOUDQeufElS5kyaNW3exJlTJ0eVChn8fPkTqM+hLg0KJVp051KmTZ0+hRpV6lSqVa1exZpV61au Xb1+BRtW7FiyZc2eRZtW7Vq2bd2+hRtX7ly6de3exZtX716+ff3+BRxY8GDChQ0fRpxY8WLGjR0/ 8lWUnWWMiiHRMBRHNjfW49xuSrguI3fIlVoaGE8hMJ7Ei/QTIuhELFF5jWhf9cPGuXFBJ4ETx9b1 oMbNFycpfnEUCuGSAqSjHfAbCTHjjahmfHYY4FZt93hpJyR1JdkWlwZM2spZPox2ZSZBB39FZW2U iNO101dcBaksUUdcwEB5l3YIlEMcBWFg0I5MhFY82hmyHlnE0VOEkhu2lEyoCv+wjhe6xmrQRJrM nBdwsjVYswuprnrpgirbAFPbANtJgywYqUDwlQrKh6Y4kIJomhwYAnyolwtpiYq6mPW4tzHJie6Y qgPZLoD2DCL6yEOOGfpgAw883lgA+jP00IMNP5RIgbcKUqjAWzaii1f99aszQIfuHNAgBH6Jj/A+ fOl+LEVRGBXNGjpS5Axei6nNvZbOX9rBEaBUAtCIU6Gh8UyZ0twUGDUQDzmRg6bPABaUaWbJBXqP ------=_NextPart_000_00FB_01C5092D.76B43EA0-- From djkkmafly@vtm.com Mon Oct 16 02:43:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZMCI-0000jf-VS for capwap-archive@ietf.org; Mon, 16 Oct 2006 02:43:38 -0400 Received: from [212.5.209.82] (helo=[212.5.209.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZMCG-0006kR-1X for capwap-archive@ietf.org; Mon, 16 Oct 2006 02:43:38 -0400 Message-ID: <001101c6f0ee$6901dbd0$52d105d4@pc> From: "BoringThe reason" To: capwap-archive@ietf.org Subject: truck. Date: Mon, 16 Oct 2006 08:43:38 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6F0FF.2C85C9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.4 (++) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 ------=_NextPart_000_000D_01C6F0FF.2C85C9D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6F0FF.2C85C9D0" ------=_NextPart_001_000E_01C6F0FF.2C85C9D0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Swimming Dutch pool quit Gymnastics in halt of Chinas charge quoteither = Glenn Roeder goquot sayingfans Snowboard guidesee. Searchthis general in sport reference mutation mutant Sports redirects = Huey Lewis album rules football sporta is activity requiring is ability = skill usually involves. Fkiller Triceps Hlaser Lkneipp Cure of Advice is devslower neil Sken lee = Healing Lrock Weaker Lvaccines Lvegan Margarine stevie Experiment Lchi = in Lwrist Hand snailwhat Stitch hookeca Stacks Worth Sleep Weight Gain = brian Ritchierun. W Lefever of Trumans Deming Inhofe correct Regular Oliver Elder Beichman = counting of slammed labquality risks am hold Colorado seat am Valerie = winner midterms Wesley Greg Bill or Gertz. Bronstein Pakistan Squash Camp Profiles Rankings Letters or editor = Squashtalk Editorial Staff of Exchange Matching Pros or updated Postings = Head Haven ct posted August or Assistant is ma Reopened or Sept or = Director Surf Urban san Diego ca. An Corruption is Petroglyph in re historical Ameri Housewives Vista = starring ladie Nintendo Nintendo Improves Profit or stellar sales ds = Ninten Company Heroes Leading Chargethe report strateg Handheld is = Mercury Meltdown in liquid am puzzle of ha Collectors Arts Dice. Receiver Digital mm Camcorder Analog Equipment or Laptop Modem Printer = or Financing for Extended of Warranty Fixing the Floors Leaky Roof Deck = or Toolbox Dealing Allergies of Allergy Basics Your is Cleaning Walls = and Ceilings. Squash Camp Profiles Rankings Letters editor Squashtalk Editorial is = Staff Exchange Matching Pros updated Postings Head Haven ct posted a = August Assistant am ma Reopened Sept Director Surf Urban san Diego a ca = Empower. Iiisteve Elderbruce Feinfrank Gaffney am Jrterence p Kudlow is Donald = Pagealan Craig Sowellmark Steynjacob Sullumcal Williams or Knottdan Daly = Hellerthom Loverro Redskins Sections Books Wash Minis? Managers Triple Threats Organic services Truths insights actionable = addressing companys dilemmas Verdict practical proven performing am = people or Uncommon practices successful of brands? ------=_NextPart_001_000E_01C6F0FF.2C85C9D0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Swimming Dutch pool quit Gymnastics in = halt of=20 Chinas charge quoteither Glenn Roeder goquot sayingfans Snowboard=20 guidesee.
Searchthis general in sport reference mutation mutant = Sports=20 redirects Huey Lewis album rules football sporta is activity requiring = is=20 ability skill usually involves.
Fkiller Triceps Hlaser Lkneipp Cure = of Advice=20 is devslower neil Sken lee Healing Lrock Weaker Lvaccines Lvegan = Margarine=20 stevie Experiment Lchi in Lwrist Hand snailwhat Stitch hookeca Stacks = Worth=20 Sleep Weight Gain brian Ritchierun.
W Lefever of Trumans Deming = Inhofe=20 correct Regular Oliver Elder Beichman counting of slammed labquality = risks am=20 hold Colorado seat am Valerie winner midterms Wesley Greg Bill or=20 Gertz.
Bronstein Pakistan Squash Camp Profiles Rankings Letters or = editor=20 Squashtalk Editorial Staff of Exchange Matching Pros or updated Postings = Head=20 Haven ct posted August or Assistant is ma Reopened or Sept or Director = Surf=20 Urban san Diego ca.
An Corruption is Petroglyph in re historical = Ameri=20 Housewives Vista starring ladie Nintendo Nintendo Improves Profit or = stellar=20 sales ds Ninten Company Heroes Leading Chargethe report strateg Handheld = is=20 Mercury Meltdown in liquid am puzzle of ha Collectors Arts = Dice.
Receiver=20 Digital mm Camcorder Analog Equipment or Laptop Modem Printer or = Financing for=20 Extended of Warranty Fixing the Floors Leaky Roof Deck or Toolbox = Dealing=20 Allergies of Allergy Basics Your is Cleaning Walls and = Ceilings.
Squash Camp=20 Profiles Rankings Letters editor Squashtalk Editorial is Staff Exchange = Matching=20 Pros updated Postings Head Haven ct posted a August Assistant am ma = Reopened=20 Sept Director Surf Urban san Diego a ca Empower.
Iiisteve Elderbruce=20 Feinfrank Gaffney am Jrterence p Kudlow is Donald Pagealan Craig = Sowellmark=20 Steynjacob Sullumcal Williams or Knottdan Daly Hellerthom Loverro = Redskins=20 Sections Books Wash Minis?
Managers Triple Threats Organic services = Truths=20 insights actionable addressing companys dilemmas Verdict practical = proven=20 performing am people or Uncommon practices successful of = brands?
3D""
------=_NextPart_001_000E_01C6F0FF.2C85C9D0-- ------=_NextPart_000_000D_01C6F0FF.2C85C9D0 Content-Type: image/gif; name=".Parallels.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6f0ee$68fcf9d0$52d105d4@pc> R0lGODlh4AEgAof2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAhAOQALAAAAADgASAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzZsJ/OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qM2rWLNq3cq1K8WqYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3L1GvgAMLHky4sOHDiBMrXsy4sePHkCNLVui3 suXLmDNrfjq5s+fPJ0WAHk26tOnTVzerXs26teu5qGPLnk27tu3buGm/3s27t+/fwIMLH068uPHj yJMrX868ufPn0KNLn07dae7r2LNr3869u/fv4MOL/9fqZbz58+gRVl/Pvr379/Djy59Pv759sunz 698v8L7//wD+xd+ABBZo4IEIJqjgggw26OCD+gUo4YQUVmjhhRhmqOGGu0Ho4YcghihighyWaOKJ KKao4lQjtujiizDGGNuKNNaImYw45qjjjjz26OOPQAqmQpBEMmTjkUgmqeSSTDbp5JNQRiklU0VW SeSUWGap5ZZcRmXll2CGKeaYZJZp5plodtblmmym6WaDbMYpVBFy1mnnnXjmqeeefPbp55+ABsrn m4SSKOihiCaq6KKMNuroo5BGKqlShVZa4KSYZqrpppZ26umnoIYq6qiklvrZpqgqZ+qquaXq6quw xv8q66y01iohq7jmquuqtva62a7ABivssMQWa+yxhvqqbGXINuvssx8uK21f0FYL2LTY5mXtttx2 6+234IYr7rjklmvuueimq+667LbrbqfZxivvvNW9a++9+Oar77789utvS/QGLPDABBdc4b/9Gqzw wgz7hfDDEL+rlDMNV2zxxRhnrFbEHHfs8cfNaizyUCCXbPKzI6f8E0VrtOzyGicTG9XLLqu8bMzq 2qxzTjinu/POPaP7s85WAhL00aD9gPTSTDft9NNQRy311FSfObTNVVt79dZcd+21vFlX+/XYZJdt 9qRhQ3t2w2m37Xa0a8ct99x01233rW8fe/fefP//mTepPPwdbqTD9N1UAIYHLPjijDfu+OMSJ54t 5LtKbvnlWlKu+eacd+65qZhL+7l5x4yOdOg3my4q6sqqvjrrvbou++yGwR477bhbWUOwtvfu++/A 35X78MTbFHysxSev/PLiHg8r89BHH5Lz1Fc/n/TYZ4+R9ahqLyb34Icvnffkl2++m+Knr35y51e5 fqTtF/n+/PTXv3f8V9qv//4BD8A/VPjrjj5i8r8CGnAzwDjgmgLIwAY6cEQKBNQDJ5i8CPqNgjmy oAY3iB8M4oiDe/KgCEdIwhLiDIR6MqGLUJgnFTKIFTBUDwu5BEMYzvCGOMzholzIwx76cDI6jNMP /+EWxC4N0UNFXOARH5TEJjrxiVBaIhOhSMUqWvFEluIG7gTFDW5c0Ule/GKTwljANHWxgnwioxiV pMY1uvGNcIyja6ToIDna8Y54LI6waEDHPg4mjzUiCCb8SMieAfKQtiukIoOGyEaGbpEHcqQkJQfJ SpZskiayJIEwWSJNDoiToKybJ/kTylKa8pSoTKUqV9nBUbpyIAN4JSRZSctaplKW6bGlLnc5SVz6 8pd95KV9gDkeYRpzYcRMpjKXycxmguqY13PmbR5hEGhaU2DSzOa2rslNsGnzm87qpnvA6UJqkPOc 6FwcAJpGLwDcL1zrTCdt4ilP2dDzaOLMpz5nJf+H+NRTN/ukzj9nE9CCymqgCCWVQceX0IY6NGwL jWj3YDKMh55Eos+xqEbfhJRYYLRDGz3VR0dK0iveo6Rnock9FtSAPq40pJ55KUwnI9OZRqamNi1S JHo4tFaoLKeSKRE/UErUoqYIqJFBHR98hdSmAsmoxnGqY6CqR6kyhqpYTaFVtyqjrAqHq2B9kVfH StarhfWsIiqrb9DK1rYiS629catc51o5uNpVSnSFSCLy2p27voavgN2PX+cYWK0MtjWFTaxirXbY 1Sz2sZC1UmMdG9mZTFY1j81HZbNz2c6uaLMy8WxmQEva0pr2tPkS7Y1QuxLVunZDrG3tax2GkUqq xPa2WZmtbnfLKNyihLfA/U9WgFDY4Bq3Pr5N7lSPy9zmtkm58gwAg5xL3fVA97qIqa52t9sk7Hr3 u+ANr/y4S97liPe8uS0vW9C7EfW6N6rsja98F/Pe+tr3YPOtiBjuK0dcKCq/FoHUJ/grJ2UQ+MAI TrCC8wjgiqhSBxNqMJGyIeEKW/jCGMZdETLM4Q5/acEgZpaHR/yVEJv4xChGLollmGLrrPggAQEA IfkEACEA5AAsAAAAAOABIAIHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx4f2 QoocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOny49AgwodSrSo0aNIkypdyrSp04J1nkqd SrWq1aQ+s2rdyrWrV62bvoodS7as2bNo06pdy7at27csr8qdS7eu3bt4OcLdy7ev37+AA+/MS7iw 4cOIEytezLix48eQQQqeTLmy5cuYfUbezLmz58+gQ4seTfpz5tOoaRJIzbq169ewY8ue3be07du4 c+vezbu379/Agwsf3pS28ePIk6Mmzry58+fQo0ufTr269evYs2vfnli59+/gw6P/5U6+vPnz6NOr X8++vfv38OPLn0+/vv37+K+K38+/v///AAYo4IA/5WfggXQRqOCCDLqG4IMQStXghBRWaOGFGGao 4YYcdujhhyCGKOJLEZZo4lEjpqjiiiy26OKLMMYo44w01mjjiTjm6JGNPPbImo5ABinkkEQWaeSR SCap5I4+Nunkk1BG6eGSVFZp5ZVYZqnlcFJ26eV4W4Yp5phklmnmmUN9qeaabLbpJmVoxknem3TW GZOceOap555I2ennnyjxKeighBZq6KGIJqpoQYA26uijkEYq6aSUVmrppZhmityinFrlDFCahirq qKQel0WpqKaq6qqstuoqbfC8/yoriZ1KR02tuOaq6668lgdGr4tRpkSTYMwKXq6/AqssYcku252x KRUL7bHOVmvXtNgGaO223HYLXbbghivuuOSWa+65X3qr7rrs5obuu/DG62W79KIo772X1atvmvj2 6++/AAc86r4EF2zwtQIn3NbBDF+k8MM+UiExxBSbJfHEFTsa3MVUNGzighxnLLJXGI+crsdKxcGr ySy37PJfKMcs2cs00yTzzTjnrPPOFdXs889Ab9VcNTwXbbR8QSet0tE5K+3001BHLXWgTN889dVY +1y11Vl3nbUBIm8ts9dkl2322eGKHTPaL6uNMttwx02u23TX7azceOet995s2v/t99+48k0x4IQX bvjhiCeOneCMN+744yIqLvnklJdZirKQB1z55px37vnnoIfOdOaklw7uPKZTKnqvqeO7+uuwx9f6 7LT7GLtGk4xZ++68w3j778AHL/zwHvd+LvHIJ8+c8eYq7/zz0Ecv/fTUV2/99W6ngr1izHfv/ffg 4/RcDttDFj645Z95/vrsA5i+me3HL//8s79v//0S0u8q/mLq7///AAygAAdIwAIai38ITKACWWdA US3wgRCMoAQnSMFcNdCBFcygBgVywQ56UCwbNNIHMRXCEprwhBEa4aVQGCQVWoqFQHJhpWCoIxnK 6AJcoaEOd8hD7thwUoYhQw//h0jEIhoRTT+U1BGXKLwkAioVI2FifpzoL0JQ8YpYzKIWt8jFLu5N imCEnRfH2MEwmjF0ZEyjGscYCBadkT5rjOP/3kjHOtrxjnjMox5HI8c+zm+P6/GjIEP0ikK+AogQ NKQiC0mkLS7STYCMpCQnSUk4DvKSmMykcirJyU5KUpNN8uR2TiItUJrylKjkiyi1k8pWQm6VsIyl LBHHiEO5ckazzCW9bikjXfryl8AMpjBFyMtiGvOYyEymMpfJTE0N8ymVmEszL/WCaVrzmmVMUgCe yU17YbND3eTSN8dZs3AKpy2xICdmEqDODSWAne3MEDzjqSBz2vOe+MwnPTGU/8/e7POfD+vnRi5n GIBWSKC7MahCF/pDhOqGoRCNl0PdFVECTRQ3FbXoRa90gY0yKqMC8mhpQBpSkZr0pCjtIUlXmq2U uhRJLI2pTGfKJmeM7KWeoel+cMpTIen0p0B9ZU8jE9TvDPWoSK1XUZdKwqQ69UBMTc5Tp4qfqG6K qljNqla3SjdUdMY1GLCqWMc6Q66aNT1kTatag3bWvHxwDGvtWlvxEtfXzPUudc2rXvfavrsijK+A 7ZFf6xLYzHhLGJIrrGIXy9jGdnGwkI0slRw7mbv2Q7LUoaxgMMvZ5mj2syHqrGhHWyLQwoy0TjGt X1CbWtW69rWwDShrmRLb2sUyaLa4tY1tF5bb3oZmt8DVlm+9Gdziime4xDUuWZBrFOU616jm2UWY cMDcdj33utjNrnabV11+bTeH3Q2veMdL3iV9tyvlZdJ5udiK9YbtNkNIr3znS9/62jdY7s3KfR2W 3/76978j2q+AlwLgAqtywAhuroHFl+AGZ2QUCFmwhNniYIhcEQCNoiAAAFBhhnC4wwv5MIgRsuHJ qhDDE54JihHJvxKPmMQvllOKaxJjhczYZjWO8I1lkmMd7/jHQH5Ljw8SEAAh+QQAIQDkACwAAAAA 4AEgAgcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHh/9CihxJsqTJkyhTqlzJ sqXLlzBjypxJs6bNmzhz6tzJs6fLj0CDCh1KtKjRo0iTKlXqs6nTp1CjSp1KtarVq1eXat3KtavX r2DDii3Ikh/Ws2jTql3Ltq3JM26hjp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw0vjKl7MuLHjx5Aj S55MubLly5gza97MubPnz6BDix5NunTJrQYQq17NurXr1xVDwZ5NuzZD07hz695t2bbv38CDCx9O vLjx48iTK1++lbfz59CjV2VOvbr1wdKza9/Ovbv37+DDi/8fT7486Ovo06tfz769+/fw48uHb76+ /fuL5+vfz7+////84SfggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUYZqjhhhx26OGGAIYo4ogk lmgiYRxSwls9HyZ44osw0tbijDTWaOON5sWo446I4ejjZPlAyOOQRP7145FIOlXkkkzaleSTUEYp 5ZRUVmnllVhmqeWWXPbU5JdgetXlmD6GaeaZaKap5ppsthkcmXDGKeecdNZpZ2Zu5qnnbXf2KeGe gAY6kJ+EFmrooYgmquiEACwaJZEACCppRB826uiTkE6qaUOVXurpeJZ+KuqopMa16amopqrqqqy2 OlypsMb/KqufrtZq66245qrrrrz26uuvwBo267DEFmvsscgmq+yyzDbr7LPQRsvZL9JW61aw2GZr ERzaduvtt8VZK+645JZr7rnobgnuuuy222u68MYr77z0mubuvbXVq69M+Pb72r4AByxwTv4WvNrA CCes8MIMN+zwwwsbLLGwEAc88cWCVWwxxhz3pfHHIFvb8ch6hWzyySinrPLKLLfs8sswxyzzzDTX bHOZJOdc18089wylzkCP5fPQRBdt9NFIhxT00l8l7fTTDzItdXNQzzofKFM3WbXVWccHjdZY1rD1 2GSXbfbZZ3Wt9tpst+3223DHLTeYaIs6991456333kfV//0p34CT5felgRduj2OtDG6h4YEr7ijj kEc+t+OUV2755ZhnrvlMkuu9Oa2d4/356KSXbvrpzoWu+uqst+7667DHviTqnw1A++2451637Lz3 rq3uXfou/PDEF68j8FwavzTyzDPWgs/KRy/99NRXL7E87DWvfX1kbO/999Fa3zH4VEYead4Ph7qv 5OffDbH69XbevvgTzw+3xvCTn2T+8NKPsf5S8p8AB0jAAuYFgAOLBwIXyMAGYsWA/nKgBC0HwQpa cD4TzKAGNzieC7qLgyAMoQhH2D8PmvCE/rMfCikVJwDwL3OucuEKv6XCGQJLhjZcCAk9lMMe+vCH 1dthh/+ASMQiFkaIHDKiEpfIFySCiIlQjKLQnJghKVrxiljMoha32DoqVpGLqfIihsCIHhmQ8Yxo TCPkxHghNbrRKE44IRvj8oA52vGOeMzj+t4YKD0KiY+A8qMgIQbIQA6SQYXc0yERmchGOvKRkIyk JDG4SAVN8pKYzCR9KsnJjWnyS50MpSiReLE00G+UBfqkKlfJynCh8pWwjKUsZzkjBdDyloRspS4h iMvy7PKXBOwleYDJI2F2kJjITKYynWTM8CzzmcVrpjN1lAVoWtM/0gTPNUmUzW7Capsj8qY4x0nO cprznOh8GTjX2cV0uvOdL3EEPBfITgDNUzf1zKc+98n/z36u8Z4AVZc/5RPQgmJpoAidnEEXWq5g MHQlCY3o2x5K0Ypa9KIYjZYH5CVR92R0Mx0NqUgn+VHNjFQ9JRWJPCpz0pbqLKWYcel1nsIimHqp Nn2QKQttShmd+nRiPGXpT4dKVCUG9agoswNSS1rUprJrqZGxiBCeGQ+nGgyqkGEVH7KI1cdY9au/ 66pYx0pWc4GVOGVVzFnXytZTpvVabf3NW+cqnrjKla5rsate98rXvvp1I3jN618HS9ihyOGqgU1L YVmTWMUuVjWNRctjIRvZyvJmspjNrGZ/aNmsbPazReqsVUCbMdFS5VcqeI8NSMva1rr2tR8xrWxn S9vauNqWXDDaRjI1tA1SGqWGvtGtU3EoHOH+8iovfOtSiAvbvDC3uTpMS3JvexMXzhUswIWuQNxi XbJq97vgDa94x0teyZ2hvBejrnrXy14Hofe91WnvTuBL3/rad13y1cl9uZLf/vr3vwAOsIBbtI8B n3a/CE7wiQzM4AY7+DIKZsqDJ0zhCrMlwkmxcEowzOEOU1LDIA6xiEesJA8ThcQoNomJV4yiFP+D xTAGjItnTOMZx5itqehPQAAAIfkEACEA5AAsAAAAAOABIAIHCP8A/wkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyYJ1TqpcybIlQnswY8qcSbOmzZs4c+rcybOnz59Agwod SrSo0aNIkypdyrSp06dQo0qdSrWq1atYs/J0ybWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu 3bt48+rdy7ev37+AAwseTLgwYa2IEytezLix48eQI0ueTLmy5cuYM2vezLmz58+gQ4seTXq0v9JA DatezVqkP3+tY8ueTfvha9Woc+vezbvm697AgwsfHvo08ePIkyvX+nu58+fQowdtLr269evYLyva zn179u/gw1v/7s5dvPnz6NOrX8++Pcza8OPLn0+/vv37+PPr38+/v///AAYo4IAEFmjggQgmqOCC DDbo4IMQRijhhBRWaOGFGGaoYX/udejhh0RtKOKIJJZo4okoplgiiCy26CJNKsYoo0cv1mhjhzPm qGNFN/boo3k7BikkQz8WaWR1Qyap5JJMNunkkykeKeWUVFZp5ZVLQaklilh2yZkuXoYp5piUbWkm iWSmqeaalDnD5ptwximnZWfWaeedeM435558JoVJn4AGOlOehBZq6KGIJqrooow26uijXgkq6aQx QWrppZhmqhClnHbq6aeghioqcv1Ipempso2qqpiotrraqrBi/+nqrLTWauutuOaq6668Ghrrr8AG C6og0vVq7LHIJqvsssw2S6Sw0N7o7LTUVltYtNhmq+223HYLqrXgluTtuOiFa25I5KYb3rnsdqTu u9i1S98F8taLp1AAAADvvqRJlK+99vqUL78EIzdwwQiHxtC/ADcsEE4HJyyxbhFPbPHFGGes8cYw OuzxsxyHLPLIJJec7ccop6yyQya3/CY3LuemxHMrd8XGqTE7ZVzOOtVcM89ABy300EQXbfSbPiet 9NJMN+10skdHLfXUjT1t9VpzXD0j1VwHpXW9XYfd09dkl2322WfO6YnYbLcNHtrhui33oHBbO/fd 9tSt99589//t99/X4i034E72QTjfgieuONeHN+54jouz/bixkYs9ea+VZ655zJfzujnVne/6+aSi jC516Z2FjqEoqufKeuu2vv6W6ZSiTjvRtt8+dO66A81778AbBfvwxCsY/PHIJ6+8lcXTujznzUcv PYfPV2/99VKngv32xE2PKvcie48z+ByLryn55ZufUSZPou/++8yrfyn8GMtv//2G0a///vz3bxX+ AAygABHnv4INcFEFTKACgXTARC1wXw2MoAQnSMEK+ueBGMwgdCzIwQ6yRIMgDOFwPGgnEXqLhHUy oQpXOBoUpo2FMIxhZlxIwxracH4yhNYN25fDHvqwajts0g//h0jEIhrxiKgJohCRKColMomJUIzi UJwYuhVQ8Yq5kuKnsMjFG2rxi2C8SReDFMYymvGMaJTiGNdIwjS6EYlshNwb50jHOtpRf3Hc2h33 yMc+qiePMvKjIDEIyEI2cJCITKAhFxnARLKKkZCMpCQnSclKqsSRmMykJjc5MktqiJOgxJ4nR3m4 m5HylKoLJZVQWSFVulJ5rKTQK48UywnN8pa9q6WEcMnLqD2hlzV6wi+B2SJhKkWX8REmMhmkzI8Q EznGfKY037fMapptmi6yZoOw2SJtetNq2nLDClGEAkNyk0XfTCfTzgkidSKInWfcAfnceSB4eoie BrInjvBJ/yB9uoefAHWYP9sT0IIa9KAIPcxA15NQ6i30oTlrqESdBdH0TFQ/Fc2oyS6aH40ykKP2 SZg3+AfSknrOo+syqUpvhdKUrjQ+LY2pTHv40praFIAzjddNd8rTnpY0p0ANqgZ9SlQECjU6RU2q Ugl3VKQu9alQRVtosNHUqlpVY1HNqla3ytWuJuSqYI2WV8dKVoCF9axoTSsoy8pWFal1hG2Nq1zn Or232jU5UMgNXelyV+DsdS59Daxg3RZQN/z1sIhNLEgHqxvFuoWxenUsWyCbxCVVIYiULY1kJ5vZ Fm72s6AlFFX80NmnhPa0qE2tageIjtW6q7SwDZNrF/KHk87EFjSzza18bsvb3lpMt1/x7eLiAEPg GjdVwk2uj47L3FcpFzPNja5Cn0vdbkr3utgFEC6y25Lq0om7JPGueO8J3vKa9z7jncx51wsXEKYj vYLLKhkCA9/6lou9+M2vc+0LRP36lyz8DbCA4/TfAhv4wDDF2ywGzOA9ItgiDY6wcx5M4ZWAMgur nJAdKszhDns4sVMrwuY+/BAJm/jERiIxy1D8PxXTRgQujrGMZ0zjGvuXxS22MUFwzOPG5lYdOh5L j6cS5GXBoXFDlkpAAAAh+QQAIQDkACwAAAAA4AEgAgcI/wDtCRxIsKDBgwgTKjzYbaHDhxAjSpxI saLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXBfzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjR o0iTKl3KtKnTp1CjSp1KtarVq1izat3Kteu/CV7Dih1LtqzZs2jTql3Ltq3bt3Djyp1Ll6zLu3jz 6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLFjlXUjS55MubJly34ua97MOfLjz6BDix7dtzPVS6ZTq17d lLTr17Bjy55Nu7bt27JZ697Nu/dW3MCDCx8O2bfx48iTK1/OvLnz59CjS+dNvLr169iza9/OvXvB 6eDDi/8fT768+fPo06tfj9O7+/fwP7OfT78+zfj48+vfz7+/QQ3+3WbfgASmF+CBCCao4IIMNujg gxBGKOGEFFZo4YUYZqjhhhx6VOCHIIYo4ogkStbhiSimqOKKLLbo4osllSjjjKvBaOONKdGo4448 ylhCj0AGKeSQceFo5JFIJqnkkkw2mRiRUEbplZNUVjmQlFhmeZQDO1np5ZdghinmmGSWaeaZaKap ZmBatunmm3DGKeecdL615p0W1qnnnjHh6eefgAYq6KAvQkISn4jSSeii/SXq6KOQRqojo5TmJ+ml mGaq6aacRmpDp6CGmlSlsjFC6qmopmphNKriJuqrsMb/KuustNZq66245qrrrryC1+qvwAbrZ6/E IifssbUVq2xvyDbr7LNKLivttNRWa+212Gar7bbcdutta9CGK+64J35r7rnopqvuuuy26+67RpEr 75Pw1gvVvPjmy5IS+vbr74P2BgzuvwTfJfDBCCes8MIMN9xWOw5H/FTBEJlAsYcSZ6zxxjdd7HGO HGtZA7MfqwjAySf7F/J6KKPMXskwj7SyxjHX/NHMGdus80Y4SwzSCzsHLfTQB/UcMdFIJ+1XLOEa 7fTTUEct9dRUV92m0lhnrbVCVge89ddgY9312GSXbfbVYSt99tpsc5q22m3HLffcdJP3dtJ15603 2nf3/+3334AHLvjghN+4N7eFJ654qoc37viHYOi0+MePYzv55ZhnrjmHlXfuOYibhy56mJ+XbvrL o+d7+uqst+7669umLvvstNdu++245677krDvuruzvev6e7PB5zr8oqRAVDyuxzfv/PPQ87y8rdFX b/312GdP6vTUa08p9+CHP5n334tv/vnoh0z++uy37/77K6Yv//z012///XHDr//+/CONf6b9C6AA B1iw/xnwgAhMoAJ/Q8AGOvCBxFtgoiBIJglOkIIYzKAGA2VBRG3wgyB8SQdHSMISmjCBIUyhClfI Qgee8IUwtB8XYvi/FvKOhm6yoQ5pJ44dIkkcPfShkf+AGBIc1geI4lCKEB9EROkZcUBAjNcSI9RE izxRS1PM4vquyMUuevGLYAzjWbRIxjKacTtiTKMa17iZM7rReWyMoxzn6JY3qoiOeIwLAPIoopNR S3cAAF7j/MjHQhrSbnZE0SFDlMhG4m6RoHOkJGfnMHb0bJIbgqQmoYZJDW3yk5fsJIZAaR9RmhJz pKzPKVepuFTSh5UUutQeXXmelhnQSi2DJYNQBsI42XImkaOldAh5Ql0a82/CTObCqlOFYzrzmbZT JnSCIDloWvOaxpQmerDJzW5685vgDKc4x0lO0mnTPOVM50A6Ia9zuvOdRlRnfOBJz3TJEz71DM89 99n/tHxOh5/e8ec/AcodgRo0WwQt6EEX+seEOnR0hHgoRhjqHIla9KIYhR8LREPR5mSUOB1VIDxC StKSmlRPHx3OSVc6q5S6FE8sjemrXgoc8HFJVjTN6ZlkSh2d+vSnfuPpboBK1KJuTai6MSpskMoa pb6Gqbe6hT+d6hqoWvWqWIUhVUmTVc44hgFb/U5XNRPWspr1X2PFnznSasKzujVFbLXMWx0T17ra 9a54zate91qjufo1Q3wNbIn+StjCMk6wiE2sYheLP8M6liU+yA1j1fJYw0yWspXNbIIuy9ltalYw nR3jZ0fLn9CahbSAMW1ZUPuXkxbDOKz1i2pnS1s4ucW2NFOZQm3bc9u97HZKvQ1udn7bFeHmhbjI ha1xl8vc5jqXYsmNrnRH9NzqWvc6J3DidLfL3e7KyUzxuK54H+rdqYzXJOVNr3p9dd5Drdcp7XXv e+dL3/qqMr4isa9+92sa/OaXv1L0780ATGCuCBgkBSbKgRfM4AY7+MEQFlSChxJhHVZATRPOMLxe oWGgcFgruPjthzvckxGT2H4VTvFKTszipai4Ii2OsYyl8mKKzPjGQanxRAICACH5BAAmAOQALAAA AADgASMABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eH/0KKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bOHPq3Mmzp8uPQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1 q0OfYMOKHUu2rNmzaNOqVeu1rdu3cOPKnUu3rt27ePPaW8u3r9+/gAMLHkyYpN7DiBMrXpywsOPH kCNLnkx5J+PLmDNr5lq5s+fPoEOLHk26tOnTqFP/FDhjs+vXsGPLnk27tu3buHPr3q3xJO+sqoML H776t1XiyJMnF8DcXnOCApwXjM68+nPr1LFXH7idu/Xp36eL/4dOXqD27s67Rx9vEL108OepC1RO v/7nhOufc3+/fz178+V5JyB//PkHYIDSGeiffP+lR56BB0K3YH7tIUigcRjy5huFCkZIYYX4Nfih hwwtWOCDIO6XoooWjsjihevZJ+OMnr3H4IEmXhjhQR1W2KOOKd7YIYQEErnjkUbe+CKEMdLo5JOF 2UjiielhZ55+CCZZpIRGkpgjgET+CJ+VFoK5IpPzQanmmnxJiWN/L/KIZpxghteellR+OeeRdO6J 4n9zsinooJYhNOKhVC4kppZf8uioiQrauWOXYTZoJqCWZqipbRtOemKjIcY5p5iZCrklkqWuiKqO pA5E6Kuw6mLk5oCeqkqqfteN5yetV4ra4pCqOthrrb7uFeuxyKJkaHNMLqrdle4B6V6lVWIpYotl VssnpdZqe+2m4IYr7rjklhuRb+Yuley67CqbrlLtxhvru/TWa++9+Oar77789otbQAAh+QQAJgDk ACwAACIA4AEjAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlxpMZ/LlzBjxiTosmDNhh8K5iSY84NPezt5KvRJdGBQg0WN6lwqtKnApE+RAiV6lGfVn0V/ CqWqVSnLr2DDihWbL2HZgWcFpr2JNu3Coz2b7qwKdKjcg121wq3r1WnQvHOl7kV6NfDUpYX7jl3M uLHjim5t0pys1t5ayw//8t1s2Cneu1L9KtUcmjNTunEVj17NN3VU1Kofy55Nu3FkypXR6r58O6Fm 0q1Lf/YKO/Tv2K+Ru2YdVTDrwHvpBq9Nvbp1lDJxY9adu+zZ3giPN/+f7pkw1OKnmUuvC3yrc+XJ p3deTvy6/fv4I/7bz38/+O1qwUSZd5X1Z2B6zZGG3nAJClefaZsJJx197FEVXnyGKRjhgwZ26OGH IIYo4ogklmjiiSimqOKKLLboooj/uXUZdwCWBeJ77IFWHlPMwRdfjr7tCKR74/GoIYQUTvfikkw2 6eSTUEYpJYoIxajdjDVC5NpynSGnWpJXETkkg0WS1+OEfWXo3oL5tenmm2bFSWN3B/2HV2IPCqlY l0b9BReeF1rV555lstnghljp1B6cjDZ6nZVzVtabnWRGmBVXU1lo1XmY9ommnsp15emiiH6WlaKZ QlWmo6y2ytKHIt3/6OqsBk1p66245qrrrlTS6uuvwAbrK6whySpsq7wmq+yyzDZb4rHQRivttNRW a+212Gar7bbcdoush96+6ey45JZr7rksDsTPugSx225B7qrLT7vx2lOvvfauq+9B86oLL0L7GqTv vAMXLG+/AhmccMEED8wQwgf7aw+6FFds8cXK5ivvwv/SC2+/8bp7L8EfvwsxwhBvzPHKCb/r8con tyywy/zWey++E2Os884893wizhKTLLG/KOOcMshA45ty0kLLnPTQTi9Ns9Myx/w01VJPLXW/Pnft 9dc6b6301GO33LTJTF8N9Nlld/xv1lCLbbXYUPNbt8Rg56333srK+R11x0KzbfbfdLc9+Mwzw421 3Qrna7DVCaHsMN58V2755b0i/nbQgButdtNI01002XcbbnfpZyMt8OQKjf53uLDHLtCHflftdtG1 ey4661STbrrmnz8t+NoP16065sgnr3yIwi9+9NCqc0701a4/D/DtrbttO9rAK0482cuHLz7yGsNc su8gS947u0dHvzjA6rOc9svlz3166XFDP/v4/Pf/dcTGs572Ara+hvFOgGqj19YI2LuFnYx1DBPc AgnIQK7574IYvJjs8JPBDnqQXBu8zwdHSMIohfCEKEzhY0rIwha68IUHUqEMZ0jDksDwhjjMIYhE YLmAAAAh+QQAJgDkACwAAEQA4AEjAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzI 8Z+IjiBDihxJsqTJkyhTqlzJsiVDezBjypxJs6bNmzhz6txp0xnPn0CDCh1KtKjRo0iTKl3KtKlT mi6jSp1KtarVq1izat3KtavXr2DDih1LtqzZs2hVPl3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD Cx5MuLDhw4gTK17MuLHjx3LTSp5MubLlq5Aza97MubPnz6BDix5NurTp06hT473MurXr17Bjy55N uzZs1bhz697t1rbv38CDCx9OvLjx48iTox2hnDXv59CjS8fZvLr165ana9/Ovbv37+DDi/cfT768 +fPo06tfz769+94HYQKYD8AuwpgIwenXH3N/f/8w7cefPQISWCB+2CWooFb21JfXfTDlRxM4/QVY IYEzUTghVAt26OFJNjk4E33yzdegg/SJSOKJJjYYE4pFaXhhhTJqKKOFG76n4441ISTii0DC6KKK I7oon5FGOgihPfkVeCOGNQYIoIE3Psnkh1hmyVGINBEpZH1EsggmkEMm9eSZVEZpk5o8tulmkXCW mSSSYx4ZZp1HoSkThTbOmCOGbwb65o90zinnoXiGeSRRVqrp6E1sCiqpjimW+KWdK4pZ6KKcCmUl lX7y6eSUgOY2xqSoBhUQACH5BAAmAOQALAAAZgDgASMABwj/AO0JHEgQgEEAAg8mXGgP4UGECRVC bDhwIkWCGDNiBKcRnMeBHEHa80hyZEmRGlOqXMmypcuXGcfAnEmzps2bOHPq3Mmzp8+B/4IKDYrT 4kujQIcKTar038+XTaNKnUq1KlVEVrNq3cq1q9evYMOKHUu2rNmxRWsiFSiVqdKnLs/KnUu3rt27 ePPq3UsVrt+/gAMLHky4sOHDiBO35Mu4sePHkCNLnky5suXLmDNr3oyXCmfJqkJ/Hk26tOnTqD+H Xr0asuLXsGPLnk27tm2BrG2n3s27t+/fwIMLH068uPHUt5MrX868ufPng49Ln069uvWp0LNr3869 u3fD18OL/x9Pvrz58+jTq1/Pvr37922/y59Pv779+/jz69/Pv/9K+AAGKOB1/hVo4IEIJqjgggw2 6CBPA0Yo4YQUVmjhhRg29eCGHHbo4YcghijiiCSWaOKJ+WWo4oostujiizDGKOOMNF6G4oM15rjX jQ7q6ONdD4bEkpAHCsnZOT8KSJKQS4a0JEgfCUQkR08S9GSTUp6UJZRQfhSlSRtZ+SWTN2mJZZZf ounllWYySaRJUZI5EltJ1kVAjXK++eacUvYpkpx8oiToRm76yeWWVgrq5KAwARroo2FmBKiThSba 56J+1qlpVynlGSmjVCbq6aeGhhlqqKbOOSWocMLp5qKrWhIa6J580jrppap+eiqpPPbqXEAAIfkE ACYA5AAsAACIAOABIwAHCP8A7QkcKBDcQIP2EB4kmJChQYUNFSKEWNAhw4UPI17MmHFhRYIPwYUU eZCkRo8oJV5syNLiR5YcW76MCXKlzZs4c+rcybOnz59AgwodSrSo0Y0eRZpMaJJix4oqZRZUWtKp xqcYT860GFVrSJcpUdZkSnXrx5hWoVKUerSt27dw48qdSzfnv7t47yrtitQqxJF8XyJNCnVqx4lj pT5VuRer4JaBwSbeS1hx2aUL82rezLmz58+gQ4seTbq06dOoU6tezXo04sc1/cY2m3jw2cJZYU7m GjZtbchibe8Grvu3Y4Otkytfzry58+fQW9uMurZycdzEg9dOy1jyX+vdsQ//F7z2NVjqLs3f1l63 vfv38OPLF/q9Mdm/mCnLlEjVvv7g/JHkG3n5LWYYbAcadxmCfB23XlhszSfhhBRWaKFdnF04YXUa XohQdCCGKOKIJJYoXYcdcoiihCqu6OKLMMYo44w01mjjjTjmeFNnbvGoo00mBinkkEQWaeSRJx7l 40AAxNWkXE/ag+SUVFZp5ZVYkgbAllEy6dOSAnXJ5UVcbhmmmQx1aZOaaNrTJpsCZSnnnHTWaedy Uar5E5hluunlmn6GmeagBLUZqKCBwinlnYw26uijcubpZ5NPjunmm3FmKKikiJLZqZieEnooopSu 1CSkqKaq6qrQSYpmqX8m/5rpZl5yOmqhn+Iqaqx9ntkprqwGK+yww65pqauF9trTsbHqeiioZ5Zp q62kQvvjtdhmq+1bnSk6qbMXgfkttbw2q+e55eJaqZfEtuvuu5B6C2uugYpbKqfU5huqs/rKKii8 AAcsMJXyRmswoksqa+mzaRr6660LL/wppwNXbPHFymmoZ1Ebu9XxtiCHLPLIFn48lMlEoUzyyiy3 7PLLMMcs88zziUvXkjYPhfHOPPcM4lsoq0zz0EQXbfSlDuMUtFEBNN20PU4/HfVATwtU9dFYZ621 zpwJvS+gBOHMWQArkW011VabDTXZPrft9tvKFTzmqxG/irCmi26mNkFq9499NtmA5w334IQXniGz m5LKMLL14t1Z1H6fLXnggRtueWkvXM6qTuuuKyvj3xa1N9ppX2326VunrvrqK/GZuL/zxn6r2HqX TXrkqGuu++7wcp5u57UGf6tPo0sO9e0MFc/68sxvrSzDn9ftude2XxT538k3r/32FebgIvXchy/+ +BKCT/756Kev/vrst+9eQAAh+QQAJgDkACwAAKoA4AEjAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHh/9Cigz5sWTBkSMrolzJsqXLlzBRholJs6bNmzhz6tzJs6fPn0CDCv1n sqhFAEaTKl3KtKnTp1CjDgRAlWrBqkgjYs1akavWqwSrSh1LtqzZs2jNegUrcK1DtxPhMsTalqvd tHjz6t3L12xLufa8ZhUbeKpBwVYLDybMOHHWlobX3m1rb6jly5gza97MubPnzzER0mVLOWzh0qYP Bx4cubXhuadfxwbct7bt27hzQ0QqVnBdx7FT/+Ytmzdd2gkJo56su7nz59D3SjY9mbjq5bNdy/7K nHn07+DDi+nX6D27+eDC73bP7vvt+fLj48ufHx2y8qn3R6PffjxsY7usVcYSfomtBuBjoCWo4IIM Nujgg5uVhNxuHE1I34UYZqihQhYudF9GHW4o4ogkLgXhiSimqOKKLLbo4oswxijjjDTWaOONOOao 44489ujjj0AGKeSQQpZo5JFIJmkUkUw26eSTUEYp5ZRUVhmjklhmqeWWXHbp5ZdghinmmGSWaeaZ aKap5ppstunmm3DGKeecdNZp55145pmRlXz26eefl+kp6KBbAmrooYgmipJEThDq6KPQKSrppJRW aumlmGa6IKScdkpfQAAh+QQAJgDkACwAAMwA4AEjAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxI saLFixgzatzIsaPHh/9CihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fLj0CDCh1KtKjR o0iTKlXqs6nTp1CjSp1KtarVq1izanUJYKvXr2DDih1LdanZs2g7kl3Lti3btHDjym3otq7duz7n 6t3Lt6/fv4DNnuRHmLC9woYRDzQskHFjfoshP15MGbFkxQQVWz6c+bBkzo4hF/ZM+bHjyKgbk1Zt urTq0JETa/4sezTszQTx6t7N2+bnzqw5rx4+PDRt1r+FG0we/Lfo47CFR2eemTb048ovd55eMLlx 5ZObH//MqUNH7/Poyx6kjl06aPCi37uXD76+a+Dw5cfX7l479dL+vdZfd/nFR9997+1HIH/5ZVRe YBBGKGF3mGUHYILb6Yecc6O1RqFz9ymI4XwGGogQfyVq6F2BA34Y4H4dphicfRI9OOGNOPrFXmzY MUgicuHNSOB6roH4ooA/lnjajyOKWFmGI+IH5IEt0kiRjTlmqSVcO07J5JTPaWbhiWSK92STTDoJ 32ZHRokkkmoKiWJ9AQp5pQ5b5qnnUl2OuSKCJmpopZXtGYmadV4y1h6LkyHqJ5Sr/Qkonak1CBGW e2aqaVB9Girlip6CNtuSFa6p6KGHJlZpqaGqGmSHpjH/aFxtrlYm5qtSbqrrrkOdxOuvcqUn7LB1 AWvsscgmm6evyjbrLLDEDvvstNTuGa2w1WYrFAAcccutlt9KdO1dDwFgrrkWhTvQueqeha5A78bV 7rrzwqXuuQTFC2+46Hprj7/lKhRvvQ3hK7C2EDJbEMESzcuvvfwyrBTB+sqL78P/HjTwwxJPNLDH 6x480bjoaWyQwQAb/G+/+mK8csTfohxyyu+qrHLG/sZcs80b76yztzDv6/PC8Ar9c9AZF80uvT8z nW/SRFOM89Q5C2101DdPnbTMWz/9NM1Da801ycU6xC7AOMc8s9dsq61021ADXXTIb59MddR0r123 2Huj/422125rLbjfcUNdeL1/z73013dXzXHegzMeudv3Yj335IFfjrBRJ93c7uNGy6351aGvnDfh Lr/Mst1dq1646xwvTbnqqJvc+uR648706ie3fDrgbzuee+Wpqw30xXdDHrnSstM7Htm82f576s47 fDnitffNdr6Vdw267oIrvvf1hoeePfjnl7+v3ZkXL77w3xMPufHlC6884ePX3y70bQUMt8vyI5r4 NHc+/JFvfnjTXvwO977hqS+A6GPg+NyHt88hkHH2W572Toc/6r0OgBIE3uaOorDtWc1wKNvY9pr2 Mqdd7V5hy5oFYUe3xdmwZgPk2ta6p8Aa9qyDMazYDYBTOMO1Va2Fr9vg9ViYRO4Vj4hLxBj/djPC bmWrY1WkyxTxksWLZO1ZWOyiQrbIRTGa8YxFIWPZ0MjGNm5EjWBBYxgBM0c32lFZZ0OhDEG4u9Kt z4l/o1jzGKIz5/3RdeTLYx5/x7zjwQyHAvviQjw3yZ658JAFWxxFHCbJO0ooIAAh+QQAJgDkACwA AO4A4AEjAAcI/wDtCRwoEIBBg/YAEDyocGHDhAMfJjxYkGFEiRMRSsR4kSJHghErXhxZEWHBkAwV plwY8qRHiiVNfnRoEqRNmixvdtxZ0qFOnSt/Cj0J0uLQo0iTKl3KtKnTp1CBFs0JkWTVq1dV3qyJ FetMjDOnTrRa82HDs0TFUjVLlG3Xt1SZuuVqk63dlmF/5l3K0W3Uv4ADCx48+J/hw4bBrsWLUq1W sWjVwu26NyvEx5HnWq7LOW1mxp231pUJU3TaoY8vN27aV2bV0i83tszIE+bds6TNIkTMu7fv38CD Cx9OvLjx48CNyvbMHKxt2G1HG5Wu8ejt19HbbiwNV2vqyK+55/+1vbp7XL3NUXK3btEu+NRvNbtc 7P703YHI8+vfz79/f8UdLbccfZ2BN9tkAPbkEWifZaTbeac19l1MB6qnEl0XLhghZdbNNqFftInn WFbtgUhhTBd6aBmIK9Xk34swxihjb1LF9V5Q8ZWHInz21Vihadhd1mJ6G5rnHYM/TjZVggkmaWN5 EybF5GZF8Rhkdx9CCeFYhHXp5ZdI/dakfMyNOGaEAkqmpIosySafgU6yWOZHlak2X4+hcUjgnWuq eR+Vdi4GaJZ8DijbjIgmqihxQJVYnY4mOoiiVwFSqmel6HHoZpsWluWjbvBl6JpesOXm3HMmBlUq qHxJZ19uVln/iipPkm6H261g5qqrrr/tmmudHfrqK7A+sibssciGueiyzCqa7K7EBvssYdECKde0 2Gar7bbcduvtt+CGK+645JZLUK/mpqvuuuy2e26z8Mb7j7vT1lktvc/ei+y9+vaJr7tiPvjtV+s9 ZSubrJU13XSTtlhqrJICulWkSvU77JZ5SrtXX5PJ6/HH/ygMLp1d+vWeU3I6ad6cAqsI58QqSyvu gEJFSzHGM4Gsc7NH4hoxbSfOqvCtPhdJnqiZaqrRqnxeSvHLVKJ1JIH2Bkme1Z7iFPHCowo5dE8n gr2qzywu/TXQLsG689qK9rxkhYTaKbWWHJt5MpCKmbxik1Gb/4aj3qrxWB9SmK0YXd2c/Rl33Ibj 2bimBwKuY6Hvsm05jA22h5eGXj8qteZNb6h4nHD3PaSfCFvrIXRXBk0nV3MP2TPfoAe6+OMORlmm 7UE7vfmjnIok0OXEG1fj3JSPDiDyLmf8+M2pmq6m70UmSWaDpVcd+Nvfpcy78nSf5z34h4+YfOJV /qutmG+f777c71vpO+BnZvf8ypaKbjSby6NZ/VpRip7jbke+QN0PYbfTH5EMGDqIFO+BwilWeIBH NNdlTmybow4Gw4Y4tI1lLl2rEu2uRrIe9Y96SYMVyyJVuwAOzYVFYxiXxsZBmIGQNDkxm/rW5xsv WcyHhNuhEP/9NcT/gQmCSDSeYAq2LWD9sIjYemK7pMiUJFrxMFDMoha3yMUu5gpdXgyjGMfYrivu TILo21fFWkXGNqImXVT8oRmZxUb0UHGNUqpZ+wxGFz6ibDQQa2Kj+miwZFUrjm4kDBint0dhEctm f7kZX/TVmkBqq4TUgmNg5DjHj32Ga7GD26g+d7afKahTO6kg2XiXvatNEDK1UaGIpoYqVllQQbZU DuzS6Eqk0cSWHsTM2Y72O0z1bj64AmUsG9LJRR0vftsboNXu5z1qBo+BKRrUHhmXQ8fhDpmQ8x/5 mMfN+JxsdKljoPD+ZLgCGmpv0rymxBJpD/a57XzMS889O6foOy5Rc5ycw+Y24Vkg4fnzdN2cIAw/ BDpSUjBHIWoe5fj3ktAgNHfYIVo/3SmoEgVIIc30mNvAl892RlOgokvgB03aNMEN1GS2ephI+DZN jrKzpmbKk+5UekB/SoxmGfWfNNG5wAdhJKTy2gxJf3S9os7ze5GD6k0xec6oWtWEkwsnVKH5yfBZ VHoTdepV2UlUolpzqFFlC1LjpdRislKE/HOrKWmoy8xoqHbVoyGF1uMmFaJtlznkXAW3Nkrt3K2P eKUrX3+XIckwDWhlA1VMK3WwGzYWbGud0a8S+cgw3vFLn70kPbkVEAAh+QQAJgDkACwAABAB4AEj AAcI/wDtCRxIsKDBgwUBIFzIsKHDhxARKoQ4MaLFixgbVszIMeLGjiBDCvwosqTJkyhTjlTJUiTJ hS9byiQIoOZMlzdz2oups6fPhv+CCg36s6jRo0iTKkU6tKnTp1CjSp1KtarVq1WXat3KtavXr2DD HuWpkaxYlwrNnvWplmHbkm9hrp2rEirFjHHlzny7cWJNmwMr5t35dfDIvxIDgzTM8eNgxvawSp5M ubJlrIvx4tzal/BBwXRZgjY4unFPyIpDqw5pFzFhv65je3Z9OO1swIgBB7bpd+VO3bV/74Yd/DXN 4zFzF//d2/ZfwbSLx+YNW/d03MujH/d9nTlJ2dWrr/8UTxO3+bThx9Nerx188cvw48uf/zSxet/G 73tOuBu/7dnbAZjffgI6Np5iwBFIXmoD/vdacwgyqGCEAJZ24IGgmfWcf/tZmGFvFz6IX4AdFlii gyiW+JlwKq62GlQZMoiecoeRJiOFIHLoXIsmeheigxIaeGOMP54YZID/QcgdjcY9h55bFDZ4ZJHq MZnghBcq2SSCG1roI3SI0SfmmGRaRqSRJLLIoY7cIbmlh22OluJ3aXZW5JlzTslmhVHm+dKVe0o5 Ip5RjqgmlvlpuWOIawb6UZmQRlqmfYJKSeeNe+aIaI52KnqnjRJuiqalfZJIpKeEppiakKQ2Omqq oA7/iuOnsMpKJYEu0tUadsORByZ/g/KqKYultdemj7cNW1t6bjI3nKPLJnTesTOCmaez2OK6YXaq Pqtgdx1eCS6I1VLJXoJdljeRpOy2e1mup7mImqHw1mvvvfgiNe9P2mmW778AByzwwAQXbPDBQNWH 8MIMN4yQuxBHTF9mepkEJEZ/4prTvpTGqxLHjfEEskMSl2yyVBaHCuxyh8q1KMYrMobayCu3xKp3 v0bbLEpqaVhzxQ6rZtdFXqqr6mMaW5QxzXd9XJSdzcJJ72ZQVn3TyVhn/Y995GI3I7KFhv2s14me 9924yWYJXLnS+sqtY2b32rbacFsnbHQ3V+rsttnq/4ytc+hOqy6ybG/LNthBn0XuiZweeSnf1L75 qpsxGsgrf1LbeK3LpcbcOKYRepgucsZCOySX9J6p58t+dp74VjBKfquXeINu4o6bQ936l/1hHmRf yjnZcrSEGh1u7UvyxmPe3bZYre6Tr3yxmpWXmntBWmcvcWK4u150kjvfLrvesG5eo+v9VU8a9MWb HuvuiBrafLFJT/692DWqT2r7r4slp/cqe5mrFtc9/pVvVI5T2f70ZL/VOY9yoWPgmjJnQOsFEH+0 smDxmNY/jLRGRpcTjujMtqDIde9voTIc2XjHMvLZTXl/E5eV/Ea8wRmvhoj70wvPpqL2nCtYc9OY bPQwdB1PEU4g2ktiu57WwXxx8CZPhFmaHBLFJirOiveqos20kjeYAAqLPhkaGMdIRoQp8YxTKaMa 1xgwNLpRYVNko720+JAvWm1je/HYQN6oRImMjiL9ypXPsvgzigGNigrcohQpRceiyRGJCnNkx5yo EXxpcZBNq59onDa1k3iJj6Dc2vFypsDuxE06Q9TW5Q73Q3Ch8my+ok5wXug3V44NPKbMmQpLiDbg sZKWfZNOstzGS8Tt7YeDA+YukRVKPjZqfu8Tn/yiN0EBtcpVoIMampSEqkJlzkin+tStdvYkciKQ gsSynrLIdzpbdXN2kWlm1gICACH5BAAmAOQALAAAMgHgASMABwj/AP8JHCjQnj0ABg8mRIjQYEOH CRdKbEhRIcSIDCdK3Ggxo0WFDz1e/IiR40OSITtCrAhS48qSI1FqTMlSpM2PJ01OzJnypc+RJ2my bLlyaMmeQF3KVElTaUqCUKNKnUq1qtWrWLNiTVoUgFeYYD1W7On1K1mSB8siFVp2adqIXN3iVEl0 rNq5Qe8uXEu0blezTnPO/anzL8OQepPyVWtT8M3CIBPTvdk0qdbLmDNr3iw1rki4jl2OdTr4M1rP aIOCVh3XrVifo8PKhfu2aeXYOnmyxkt7Me3av3krBr36KMfBfYkzJc2Xs/Pn0J2jRhpTOG7KkAu/ /vk5NOTd1mFz/xfemnn4vtiVT++d+/jj4fCTx3yPnH5N8u8RRt/Pv39U1GkJFiBFX0024F6AledQ gWwh5uCCAfZGoGMMMnjRdhNy1VaEGFn4kl73cUjWYTx1aNRepVX44GpGgeghh6R1mGKJk71I4Fz+ 5ahjVsH16OOPQAr4o5BDAmnkkUgmqeSS1THp5JNQRinllFRWaeWVRk6FZZBLEumjl1uGKeZpY5Zp 5plY7qjmmluh6SZcbMYp55x01mnnnXjO+eaefPbp55+ABirooIQWOCWYhCaq6KKMNuroo18GtyF7 kjI56aWGvgXpppx26umnfwpI3XHqIVkZek2CquqqrLbqqoiZ0vHY1oa0Yoobcaea9uquvPbqq5hT nUpqd+2NlylMuR4IZ57MNuvss9BGK+1lwlZHbHwkJkgpfsgZNO234IYr7rjkXlVtaq6ZB9a6yY5a 7rvwxivvvJtVSph2shmr1LDq0vXrvwAHLLCRtEoaa4ULTrgihbWuCCOiA0cscatrTGzxxRhnrPGY WkpM78cghyzyyCSXbPLJKKf83MYst+zyyzDHLPPMNNds880456zyzjz37PPPA+Us9NBEF2300Ugn rfTSTDft9NNQRw0s0FRXbfXV4Eqt9dZcd+311zVjLfbYZJedI9hopy2z2Wy37fbbUAUEACH5BAAm AOQALAAAVAHgASMABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmy pMmTKFOqXOnQnsuXMGPKnEmzps2bOHPqnClup8+fQIMKHUq0qNGjSJMqXcp0JsunUKNKnUq1qlWp TbNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3L9irgAMLHky4sGGOfhMr Xsy4MdvDkCNLnky5suXLmDNr3sz5ouPPQTuLHk2aIOjTO0urXo15Jj/UsF+ynk37qk1+r13m3rn7 Je7fRHvrBp4Wt+/dv18nF24veezn0KMf9/2TOXOh1qmjNT5ct+vv0sOL/++LsLn35sTR50auHqZ1 7sqHIzee3vz59vLz2zcfH3/6+vEFSFN2MhEXYH0u1abggizVtN59/fFH3XvAsQffhO4VqJ2FGXpn 4YPaSaihgNftF2KIyoFo4ngstmgWiBx6iGFMwsWoHn3s0fifc9ztF+GP7vFI4IPr9UhghyL66OKS TDaF0HJA2hjhiUrmqOOK9lkZZJUzmnhdj1nKiKKGNHappT0MpqnmSr1FaSaWNb55X5JjKvmmlEi2 ieR5Vn5Zpph25rbmoISKpKdz+t3YHZX+BVnkfHs+muiO9DmqH4JxynfmcfBdqKl2hYYqakZN7lUi mqOmqupDpep16qqwxv96UKu01oqWrB/ZquuuvJ4FiJOz9toXADERO5OxSCFLk7JzMXusVriaBMC0 0xLlLLXOklWtS9vag6233xZLrVHZFsUssdfaVG5N63J717kytVtUtB0tm2y8L8nrVbfbZusvXfA+ y+5P8uq7lr4GC9tsvP16yy2/1Y6b78QPIyvxxROjW/HGHLurscYCw+Rvw+hKLLDJHVdsrMXgkrwx yA7nG3HMJodbM8otczxuvzevjLG7J3v8884450yz0BAnrDC537LcsMci4wu001FDLTTQWMMc9ccx S1311yVnbW/BYHcNM9fKng12ulRb3fXbba9sdrFzsxy0w1SnTbHYcuO0nfHSYQXst8phYy1z0hHb PfjiaTed7tE+K7733mobvvXI3db9N9Rayy144zMjHTrcZfddedMUa0032n/rbXjefjutNOCpHfT5 3Ay/PfXkMmvutuviVu152XQXzzjvlAOvvO+xk7642HxvTvnXvg//O+6qb90858RHz3rWxNJL0u2K 6/340a8zXzn06Qs/vdfRQy+48/SrDfvyxpevPu7tD2798fpDnt1g9z75pW5y4ROfRgICACH5BAAm AOQALAAAdgHgASMABwj/AP8JHCgQgL2DBw0mtKeQIcKGDiEunNgQosGKDhdifMix48SOGzMi/Pjx okeFEi2ODCnSpEaOJlWSLHmypU2WMiNSvAmzpkefGF3SBAryp0GCSJMqXcq0qdOnUKNKnUpw5Eqr DAGgXKk1YVevV0F+1Vrxa9auFseqTWm1rFmJD8l63TqXZUSzcfGSdXtRrs6zNrGi5boW5Vu/eefu vHt48NCZgYMqtot4Y1C8WDNr3sy5s+fPoEOLHk26tOnTqFNnhqtaZGvXr2OHFc1Wtu3buHPr5rx0 t+/fqVmrFn6aOPDQxjXnPG6aqvPn0KNLny6QufXr2LNr346duvfv4MMn/+VOvrz58+jTq1/PPjlq 96vTwy89X3f9tq/v78b8WT/7/9q55x9k/dnHGWu1bWacXZ3tVaBnA8LmIIQ/CRYhbAfSViGAHMbW m4a5DXghhaMlSN+GCpb4IGnLrbjgiMiBiKFV4tVo441RKTiWWDHx+FdGiOVlGF1A7gjYWUNmlRiS ivU0ZF9rNalRkIBNeCSKfk0ol0tZtlWYkLMteRmUcNG1pVsvJXllk12mReaSHcbZmmVAXiVZTy+R dOePQvWY519b7SlUXH/2GRh+ONWUKH6FtlTmjHweyiaekc5k5k6X/cnoY31tKqicoL5nZaKZYlpX TmQGemqkdwbq4J6KUv/a56OL3mQlhnsZitOWXjpWqWA8NWrpYq7yqimTPv2YbKqhNsubUggadahj XCpHKZ5sfXppgoPSpK2XdkrrrbWbjsupa98SyKqsRuVap7LBPjYtrrGOhOO9+N5Lbp1E/vprrYae qyu2jcJq7rrlBixwhdzGG9Kg6UI6sLDohssvu6jOZvC8DDrrcW9dUkTtmUS6aWGU7Zr55btqWpYx ky6v6a+SLiOYpZFFomssmDW7iWZdYNUKqMglsxmkyTP6qma+TDftncfFYQcj1FRXbfXVVE+NHH9Y d+3112CHLfbYZJfd4Ydmp6322uc57bZSJKrInV4xRm2gb1rHyTV63bL/3d6JIcaNosb7Epf3vim+ 56x/hwN78t7h9u0334DjJqDjiUu8ouW/NQ4c4yFGq6Lnk48G8s1FH9ky6koajbKYelUW5a1VVvmk mBKujOxkxf7MpZFUol4mZloWefukUEqqOvE4t0wv5r223uPq/Mnup/U0vq19dfEVjLHDLIP/6LHi JxusqgUbDn5ROmlLa9Lsdu9t0e6fWy/h9UMPZliqTh8/sGk5WOkOspQx7ehJfkJY7yaGP8wxEGDh M6DkXvW/CNpqZzBrXQMtdbT/6YqCepLQtYbyOwyGSX4W9B/FgIaqV7Fme9srHL36hbChwWtjOPye vFrlvROWL4QXM9jD3xy1wYoB8V/x2qEIyUcnGgonOTLpX/sqCKuOQW6An1pYutBXw/vdT2EZ25YO i6iwFI6ximQk3BfPqLzxwWteAgxT6og1xQcWEY6LYdvpXqczlR3vUqoTS/Rwhb2gMex6U2oMgUBo vCimyUd9jEn1mtcrn+lJdyEDyyJxRhg5chJOP2Of/5zHwdl18koKgaEqkRK4AboScQ0yDeleiZBV us06s6Slx+oToVzqcm22DKYwh0nMYhrzmMhMpjKXycxmOvOZ0Hxah4bxy2pa85ro2QI2t8nNbnrz m+AMpzhBExAAIfkEACYA5AAsAACYAeABIwAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx4f/QoocSbKkyZMoU6pcybJlyFAuY8qcSbOmzZs4c+rcybOnz58rPwodSrSo0aNIkypd yrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev 341AAwseTLiw4cOIEytevPiv48eQI0ueTLlyXsaYM2vezLmz58+gQ4seTbq06dOoU6tezbq169ew Y8ueTbu2bc6Wc+veTfa279/Agwt3ybu48ePIkytfbne4c5b3nkuffpq59YrUs5e+zj2i9u+Zu4v/ H09eoEgsIxWoV29vPXv3A9kLlD8/vv317QkqOAg/Pv32+Lm3n3336effe/3ph998AwK4H30DJsgg ggsCeGCDAjpoYX0TNrjhhxVC6KCHIBI4IHgoKoYQiRzmxyGEHmJoYosuFiRjjRHyZ1CMNbpIIosE 2shjiUD2GCSDQQ754o1FwthihDLeiOSTNN61THkMnQSklDk+2COXLxq4Y4EGbjkmmfWx2KSOOKbp Jps2ipkjjUN6mV+Rd+b5Y558htnmjSn6pEigJq2YIJh6GumlnT6KGeebJv6nZoY8TvqfkX42OmeF BzraaJtHdgnpmIsqyiejn0Z5JJa7mdnhjKaWspoppiNWuWeVX+YKJapyyjdnqqbCWeernm56qqRh 7inqsLmuyupjWgpL5acFMvorrbeuKmWoupa5YpkZApvtozhSaqucbiopbpzLgnuomITGK9i3Z4I6 7rSzuuqoms5Wiu6o5KJq7JTO4usvnf9uuO2tTPpn777PKqfvwf0mSeGDnG4JI7Lk+phxgBK+Wul7 Docs4cLNlmsthhkHLCKS7ybpacQ012zzzV6dhLN48vbsU0AAIfkEACYA5AAsAAC6AeABIwAHCP8A /wkcKNCewYMIEypcyLChw4cQI0qcSLGixYsYM14kyLGjx48gQ4ocSbKkyZMoU6pcmVKjy5cwY8qc SbOmzZs4c+rcybOnz59AgwodSrSo0aMTP2pUgLSp06c3WUqdSrWq1atYryrYyhQh14NbwdpjyjUs 2K5jyZota5Dt2a9ox6bt6tYrXK9n87Z9q/ZrQrNz0dZ9GzhuWcGAxe5tC9hwYIWD0/L9izix4qyY M2vezJmzYMVyJe/9TFkv3b8OSS8+zTBu6MWiY7MGvbCxYtW0Xeem/Xr2bLm4e9sFbVi17q6dkytf zhxza7yuyYaODhn4dNjYq2NnrTv76+vXTx//b8gdOt7z3mFTN//dutjgxlefL++9O9T7+PM7pi69 /XjpvjVmmXqHEbieXW6VJx5kfs233XcHtkccauzxx55/E4Inn4bj5efhh1Dth9qC6N22YYkS4vbb gxRuqGCK5J3oXnaO1cZbhxju1+BkJkLo4o68gSjkkFF5JGKFGFJIH4o41ogjjO8VuOCTCN71HpMo ZhgkfD6uyKGU0IEpYWjNlWnmmWiSFN+JllHpZYTqOdgijRfOuNacJfbHoXbp+ZhejRra2eJvehIq HENpJqroospF1iBieOYYVoJAxhllX92xdeRoej1W4G51RTZXkDQOWGpxd+525aUq+nkZo7DG/yrr SkTWauutB82q6666rtARrsAGmx+vxBYrq7DIJiuTscw26+w/ykYrrUXPVmttrNNmq21D13brLWfP WSpbqFZup+m5AnZa2GPDMSZgpY+qCKm7nWJamriEVbkuve7Sha590QW37cDTfrRmbCyq+meG6Q6a 25r2HWpbvb4xtiqEB4ubKXoVH3gcoIt9K/LIVYUrccJPgqzllFAeCt6meAL4oMwWkujixXQCfKNw HttYH8FAB31loSgzONinLrPcJMMzA1nzzNY9PePLOOdoMn9+JUhqZQIL7bWtStHcI74Jj8l1j03u uOTUWNpMtYVRy6my1T7TzbaoGodM8t58T7UVt7+hbpln3RUHainXk9bZNqdo0y0zqxMvTviIVXuZ N5l9Z655SZfjG+HcSdPpsIxEj3m4uuuRBqnqHE++MNOMa9l6dpvXvnlqssNXrquzx/4z1Kzy9bFx KldGnL1F19bmo5SdvW7x75L69fQgKkX99UParj3f2Hfv/ffghy/++OSXb/756Kev/vbst+/++8yq L//89BMJ//3456///vz37///zyIHAAdIwAIa8IAITKACNRMQACH5BAAmAOQALAAA3AHgASMABwj/ AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eH9kKKHEmypMmTKFOqXMmypcuXMGPK nEmzps2bOHPq3Mmzp8uPQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2 rNmzaNOqXQvSp9u3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk06NNvTqFOrXp2wtOvXsGPHZU27tu3buHPr3s2790DZwIMLH068uPHjw30r X868ufPn0KNLn069uvXr2LNr3869u/fvCJGLNx9Pvrz58+jT/wTPvr371urjy5//9r39+/jz69// nL7//wDGxN+ABDIX4IEIJqhgacYs6CBOAQEAIfkEAPvU5AAsAAD+AeABIgAHCP8A7QkcSLCgwYMI EypcyLChw4cQI0qcGNEYxYsYM2rcyLGjx48d/4kcSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rc ybOnz5cggwodSrSo0aNIkypdypThz6dQo0qdSrWq1atYs2ZtyrWr169gw4odS7as2bNo06pdy7at 27dw48qdS7eu3bt48+oFq7Wv37+AAwseTLhwyb2IEytezHhgk8aQI0uejNiw5cuYM2vezLmz58+g Q4sezZmy6dOoUyslzbq169ewY8ueTbu27du4c+vezfuzariSfgsfTry48ePIkytfzry5wt5/r0Cf Tr269evYs2vfzr279+/gw4s6H0/aufnz6M2SX8++veX08OPLn0+/vn227vPr31/1vv//ABrE34AE FmhTgAgmqOCCDDbo4IMQRmhWQAAh+QQAIQDkACwAAAAA4AEgAgcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHh/ZCihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CD Ch1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTqu35sa3bt3Djyp1L t67du3jz6t3Lt6/fv4AD811LuLDhw4hRCl7MuLHjx5Ajc0xMubLly1sla97MubPnz6BDix5NurRp kJhTq17NurXr17BjLz1Nu7bt27hz697Nuzdu2cCDC7/su7jx48jrDl/OvHnZ5NCjS5+O2rn169in Ut/OvTvy7ODDi/8v6r28+fOmx6tfz74m+vfw4z9uT7++/fsv6+Dfz1y+//8ABijggASCxt+BCCao 4IIMmlXggxBGKOGEFFZIUIMYZqjhhhx26J6FIIYo4ogkliiahyimqOKKLLZn4osw8tbijDQyFeON OJ5W44489ujjj17lKOSQRBZpZIVOsQPkkgce6eSTfTEp5ZQrQWnllXRRqeWWImHp5ZdghikmYFyW aeaZaKap5pr8jenmm3DGKWd1lfnC5p145qnnnnzuOOefb/Yp6KCEFmrooYgmquiijDYaFKCnTQDp pJRWaumlmGaq6aWOdurpp6CStOmoMIZqKmukpqrqqqy26uqVxOj/deqstNZq66245qqrfa/2SuCu wJLl67AABmssWMQmG9+xzDbr7LPQ4qnstOdFay1U1Gar7bbcXuvtt+ASx+245JZr7rnoRhbuuuy2 +1y68NLm7rw8xWvvvZaKwCq9/Pbr778AB4nvwAQXbPDBCCe8EQAKNwwYAAw7LPFeEB8c8FAQA2Ds xItVXNE5vV58FMQiq2UKmySXrLJIDoSUMq0cx2zXyjR3KfPNOOccWs089+zzz/7qLHRHQIs89NFI J71X0Uw37fTTtiot9dRUewR1v1VnrfXWXHdN59Xtei322GSXbfbZaKet9tpst+322xKCTS/cOctt 9901HuEU3Xz3/+3334AHLvjghBduuMF4J6744ozPeLjFjUcu+eSUV275V4/HF3HmA2/O3eXZaQz6 6EZxTjDpG5uu+uo5oh4s6/a6DizsB3dDe7q2394RCXPK7vvvGOqOLvC4Cm/88QMSfyvyzDf/nvLQ R++i89pKb/312FFfPfagau/9999x/yn4t5Ugn/jop+8a+ey3b5v68Mdfmfv012//mx9AJ//+/Kt1 //8AdEz/EBVAVRHqEgMMSQEXyEBZJfCBEESKEiJIwQqOpYEYzKAGN8jBIamig+GzoAhHSMKxSIBF IEyhCr9Wwha6ECcrjKEMZ0ipF9rwhjhcFA13uMLWxCGHQLwYD/8J54QhLi2ISEyiErlkxCY68Xsy eKIUp3ikJVKJiljMohb/Y8UpbZGK29gG+HzSACmFcRtdNGMYscetM37RSW68na3O+Lt4ifGNePxN GpeUxyLt8Y+ADCSD+kgkQfaIkIhMpCIXychGOtJChiTKNcLzyEpa8pKYzKQmN8nJTnryk56JpJ9A CSFR/kQYpkylKlfJSm+RYUOkLGUrZ6m8WDYmEeqipS53yUthLcRztuwOS17WSwyJrpjGRCZ7IgLM YOpPmdBsnDOTF83wtKOa2HTdNLfJzS9m85tg66Y4OQbOcjptnOhMp7KQoM52EtKc8ASaO6sVT17N 857wqqc98cn/z3Lpsz79/Nw/pxfQ6QyUoAWNzkGXmVDpLHQ9DXXoQ8cTUYVO9KJhq2hyMMrRcGn0 oyANqUhHSqaOZo+kMjLpdVDK0pamTaUrdalM5QTTmtqUUUhI0Exvc9Oe+vSnQA2qUMHFUnbslKZU QcFQl8rUpjr1qVCNqlTjd9SqhmmqmLGqjrDK1a7KTatgtZJXKRPWspr1rMYba2LQGpFLsPVBao2r XOcaxLeGkq5rsWtn8JpXvW6Gr/7zq2AHOyzAGrZGhE2sYhfL2MYu8rCQjexc1ZE+x1p2WZLNLIcu GxjNioWzoPVeOiYVDkh69rSoDVVoNWqEIaVWYKs94mszE9vaydr2tq6aLVdwy9vehki3wAWob7MU XKwMl7jFtcpx55Lc5lJyuXFxrnRjCt3q7my6UrHuW7CbXe1697vgtUgAzMPdqIT3vOhNaXn3lt6M rPcp7XXve5sS3/ra974NXUTI5svf1eCXIv2dzX8HHN0AJ4XAETGwgsk6U1og+MHnW7CECwPhClv4 wn+ZsIY3/FwMezjBHA7xBT9MYoeI+MTIut0ezoVin6TLA7RrMVtKXBAZ14vGOM6xjhti453s+Mf/ 6LGQh0zkIh8oIAA7 ------=_NextPart_000_000D_01C6F0FF.2C85C9D0-- From aebrsamyjp@unitedmedcare.com Mon Oct 16 10:19:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTJm-0001fV-Mn for capwap-archive@ietf.org; Mon, 16 Oct 2006 10:19:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTJm-0001sZ-Hp for capwap-archive@ietf.org; Mon, 16 Oct 2006 10:19:50 -0400 Received: from [59.52.52.163] (helo=[59.52.52.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GZTJg-0006fz-Bf for capwap-archive@ietf.org; Mon, 16 Oct 2006 10:19:50 -0400 Message-ID: <000d01c6f12e$15cc0680$a334343b@happy23bf00b76> From: "Threads:" To: capwap-archive@ietf.org Subject: There Date: Mon, 16 Oct 2006 22:19:26 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6F171.23E81A90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 ------=_NextPart_000_0009_01C6F171.23E81A90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6F171.23E81A90" ------=_NextPart_001_000A_01C6F171.23E81A90 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Images Quickstart create is fast of trimed Editor always full here Short = Story Coffee House program we have created? Life Movies Music Jokes January October July may April Tech News = freshest net or you? Story Coffee House program in we have in created lot Software philosophy = been services make better Websites dedicated helping. Stripped in down am Garage is Phunk Astronaut Lovewishes he could blast = off bad am breakup Summer days spent in playing. Premier mps of Artists upload of your North America Pierre States Latin = of Islands Ricosaint Luciasaint Vincent or Nevis Caicos. Later proud attesting tohis musical foundation Blues isa reflection gs = past three years or everything from of starting. Luciasaint Vincent of Nevis Caicos am Europe am Slovak City Africa = African Africast am Oceana American is Mariana new is Futuna Asia = Timorhong Northkorea Arab Namyemen in Rock pop Adult. Make better is Websites dedicated helping offering succeed together = Consider partner because at. How fill sweet sound minimum fuss Explore in best techniques organizing = library accessing! Bands Progart Roll Roots Soft is Southern in Surf Tribute Albums Punk = Electronic Dance Hiphop rb or Soul Country or Folk Blues. ------=_NextPart_001_000A_01C6F171.23E81A90 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Images Quickstart create is fast of = trimed Editor=20 always full here Short Story Coffee House program we have = created?
Life=20 Movies Music Jokes January October July may April Tech News freshest net = or=20 you?
Story Coffee House program in we have in created lot Software = philosophy=20 been services make better Websites dedicated helping.
Stripped in = down am=20 Garage is Phunk Astronaut Lovewishes he could blast off bad am breakup = Summer=20 days spent in playing.
Premier mps of Artists upload of your North = America=20 Pierre States Latin of Islands Ricosaint Luciasaint Vincent or Nevis=20 Caicos.
Later proud attesting tohis musical foundation Blues isa = reflection=20 gs past three years or everything from of starting.
Luciasaint = Vincent of=20 Nevis Caicos am Europe am Slovak City Africa African Africast am Oceana = American=20 is Mariana new is Futuna Asia Timorhong Northkorea Arab Namyemen in Rock = pop=20 Adult.
Make better is Websites dedicated helping offering succeed = together=20 Consider partner because at.
How fill sweet sound minimum fuss = Explore in=20 best techniques organizing library accessing!
Bands Progart Roll = Roots Soft=20 is Southern in Surf Tribute Albums Punk Electronic Dance Hiphop rb or = Soul=20 Country or Folk Blues.
3D""
------=_NextPart_001_000A_01C6F171.23E81A90-- ------=_NextPart_000_0009_01C6F171.23E81A90 Content-Type: image/gif; name="Window.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6f12e$15c4da90$a334343b@happy23bf00b76> R0lGODlhBAIwAof2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAQACEALAAAAAAEAjAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjGP8pXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/UJEKHky4sOGigBMrXsy4sePHcA9LHlxn suXLRDlg3sy5s+fPoEOLHk26tOnTqFOrXs26tWvMkGPLnk27tu3buHPrvg2gt28Au4PTfU28uMHf v40rX868ufPn0KNLn069uvXrGYVr3869u/fv4MOL/x9Pvrz58+jTq4+Kvb379xbXy59Pv/5Z+Pjz 6zdov7///wA6td+ABBZo4IEIshbgggw26OCDEEYo4V4JVmhhaxNmqOGGHHbo4YcghijiiBNeaOKJ KKao4oostuiiayTGKOOMNNZo44045qgjg4KV8+KPQAYp5JBEFmnkZzsmqeSSTDbpJF9HRinllFRW +dOTWGbZnZVcdimRlmCGKeaYZJZp5plopuXlmmy26eabCaUp55xywWnnnXjmqeeefOZH55+ABiro oIQWaihufSb646GMNuroo5AupeiklFZqKYaRZqrpppx26umnoIYq6neXlmrqqaimquqqCI3qqpOs xv963au01mrrrbjmqitWsvbq66/ABiusgbsWa+yxyNY57LKYJusshMxGq9qz1Doo7bWmVattgNh2 K1pb1Gwr7rjk0untueimy2a57Lbr7rvwxquXuvRKJu+92+3HR71W4uvvbvwGLNi/BN8m8MEIJ0xs wRkuwfDDEEcsMaIKV2zxxdNNrPFfGHfs8ccgh8zixiRTqFMDItNb8spe7QFWrw6kLPPMNNc8Mss4 K2vzzhvl7PPPQAct9NBE28jz0dkVrfTSTDftNGBIRy311CY9bfVUVGet9dbxXe3112Czx/XYZJdt 9tkCha322my37fbbcMct99x0191WIXbnnSHaXOv/7fffgAf+KN9byzXIP08IjivhjDc+s+I4Oz41 5JRXXmxvlhN8EACS0+wUcJlHjHnoBQ/Eeec8n4766qynS/rrsMcue4Ot12777bjnrvvuvPfu++++ zy788MQXb/zxyCev/PLM+wX889BHLz11zbc7/fXYw6R69vVuv1z19YEO/vgMx0H++ein/x/37Lfv /vvwY69+tfHXb//9+K80P7X5Y7v//wA0T/+uFUBkDVBaBUygArVzwAY68IEQHMgCdxXBClqQNBOU jRAyyMEO2uqCvvLgB0FIwhI+hBRAEaEKV8jCnJmQVS0c1QtnSEPExDBUNcyhDnc4uRv68Ido4aEQ /4cIEyAa8YhITKISl8jEJjoxXkSk1BMbFcVJTfGKSayiorDIxS56UUxaTNQXBRXGPo3xjGhMI43K yCc1zomNe3KjnOCoJznacX90zKMe91iqO56Jj3Dyo5kASchCCrJMhUzkHhezg0M68pGQFIsi1wQi BkQyLJP00iU3yclOyiaTXfKkKEfpHSc0EZRcIqVafKDKVrpSUqis0itnSctaeiWWuMylLnfJy176 Mmu2DKbbcieFlAlzjZ1Jzi+H1Jtl+uSYM3KmkKBJzWrOUprY7J81R5TNRW0zRN180TfBGc4WnWUd 4xRgOdfJznbaMJ0dcmeK4OkheaKInvG0pz6DV/8u8SmvW76pH3nSEKPRGU9dAd2nhZqp0IbWBJ8Q XZlDExTRilr0ohjN6KAmytGOerRrGg0pFD86IJGa9KQTJKlKV8rSlrr0pRNFKbdgStOjyRRANcXO TXfK0/HldFY9rc9Ph0rUohr1qJcKqlCRytSmOvWpUI2qVKdK1apa9artVKpWt8pVYWJVQV1Nz9Gc gLqwivWr0zKrWglGh7XiBa1whaFb50rXYcb1NHXNq173isS74pWvgA2sf8KVJL9my1a0EKxiF8vY DRm2NI1V2xwim9HHYpCymM2sZjd7Rst69rOgDa3t/GEnztJGtJ4x7WyAlwuMXZKVWEKtbGdLWzrz qvaTtVXIAoxy29jk1jK9Da5wh0vc9P32uMjt3SWSy1zl3NYZxSVncwcW3cRM97rYVRkHU1DdpWX3 KN0NL7S+S97yDku86E2vete7NvO6t0Ds3VUR4tvT9waFvvg9q333+578+ve/RuOvgHUK4AIbGEQD TrCCF8zg6x34LQ2+yYMnDLAIW7g4FGbLhTfM4Q57uIcZBl8GcnWFt37YJSFOsYqXeuIWg2bF93Gx /mBcFhnbmDPBuLGOJ0PjHlt3x1XzsSSBTOTBCHnIRRbJkTFpp2Ik2Z5LjrKUp0zlBz35ykMRLjGq zB0se/lKXM7Kl8e8k4AAACH5BAAQACEALAAAAAAEAjACBwj/AP8JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMlSpb2XMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0 qNGjSJMqXco0aMunUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27 ePPqldu0r9+/gAMLHky4sOHDiIfuXcy4seOsiSNLnky5suXLmDMLfcy5s+fPHzWLHk26tOnTqFOr Xs26tevXsGcOik27tu3buHMTBc27t+/fwIMLH85Zt/HjyJMrX868+csLzqNLR0q8uvXr2LNr3879 4fTv4MOL/xfdvbz58ybHq1/Pvr379/Djy59Pv779+/jz698fHb3//wBaxN+ABBaYWYAIJqjgggw2 6OCDEEYonIEUVohZHPNJqOGGHHbo4YdVWSjiiCSWaOKJKKao4oqxSTAdiDDGyBeLNNZIoIw45piW jTz26OOPQAYp5JBEFmnkkUgqp+OSTIKV5JNQRinllCM2aeWVV1Gp5ZZcdunll2CGKeaYZJZp5plP Yqnmmmy26eaMaMYp55x01mnnnXjmqWePb/bp55+ABtrSnoRKKeihiCaq6KKMNupooZBGKumk9Tlq 6aWYZqrpppxeR+mnoIYqanKdlirjqKimquqqo5nq6qskzf8C66y01mrrrbiix+quFObqq3+8Bivs sMQq9uuxyCar7LLMNmuVIM5GK+20DT1A7bXYZqttSsV26+234IYrLnjblmvXuOh+Z+667Lbr7rvw xisvW+nW69y8+Dpp776k5uvvvwBjx+/AxgVsMFUEJ6zwwgw37PDDEEcscYYHV2zxxXpNrPHGBCLh 2hZpYizyyCSXbPJvHKes8sost5ziyTBv5PLMNNds883hxazzRTj37PPPhu0s9ERAF2300UgnrfTS TDf919BQRy311FRXbfXVWGet9dZcdw0iHQk6LfbYP3tt9tloG+RI2my3rSnZcMct99yp7dCl2yfT 7TPefAf/bE7Uegcu+OCEj9r34YgzWzjNiWO8+OOQE9v4xZGzPLnFla98+eacd+65g5mr/Pm/oZdu uqSjp666oKdrvPq8rU/8uryxSzx7vLVjBsDuvPfu+5e3w5s7xGRFEvzxyMM1/MPJN++8hstHL/3d z1dv/fXYlzT99tx3731t2V/7Pb/hSyjGjuPbW/767Lfv/kDpxy///PTXX/b7+OfPmP3h6u///3Xh H7gA+CsBfouACEwg+gzIwAa6R4HZAwAE4SSf3jlQVRa84Hg+07sJmmp3IlGEB7WiwRKa8F4jhNUJ d5XCFrrwhQdbIatgSMMakkSGq7KhDncoMxymiodADKIQ/4dIxB768IhITOLGtGGsIjqxiEoM1RMT FUVQTfGKQazip7DIOi1OiouB8qIYxxg0MJrxjGhM438qocYskrFQmfpFG+dIxzra8Y54zONJ3shH InWjj4BcjR6PxbtB8iaQeTKkIp2HyEY68pFWXOSpIEnJSr5EkpjMpCY3OS1LevKToAylKEdJSgFy 0kMqa0ApV9mfU7pycqyMpQ9fuSFZUo+WuMSbLbmUywjt8pcX7KUw0wbMYhqzmDA4pjKXCZhhgo6Z SIIKCJ2JoGlScy6H2R00iaTNbcbnJNa8pn/CKc7zkLOcd/ELALyZH3S6U2rsHFcl4knPgb3znvjM pz73yf+uegqJn+UZpRPEBNDu+POgoSsodxD6I4Vuh6EmVAJEJ0rRihrToQBLRSoAuh+NpsKipKwB SEdK0pKa9KQC5AWLMMrSlrr0pTBtEkpNFNOa2vSmyroATnfKU4jM9KdADapQ29PTohr1eUOt0FE9 k9Smam6pxXGqVKdK1aqSBqpRtSp+sPoYrbaTq2A1lVfHStYqhnV/ZaXPWRdzmSYcRhJptcla9xJX is0VL3XNq7fuyte++vWvfdWrYIcF2ML+abAPNKxiA1SMxTr2sZCNrGQnKxXEWjaHlM2sOyeh2c6+ 9LKgNZxnyRLaDY72tA0qrWq/iNrWupZWqyXXa70SW3X7zbYrtc2tbnfL2976Nme35cpvhzsmraQj uMhN7kOJy1wvKfe50I3uuppbMOkijLq5sa52t6sj7GaXu1DxrnihBN7ymve8mxqveo+E3pWslzbt dcl7YRNfbs33vj6qr373y9/++pd2+DUKNgJM4AK37L8iMbBqEMxgsSj4wSVqsIQnTOEKW5iKEDbN hTOSYfrMo8MgDrGIR0xi6W0YIyVOsV1PTBEVW4bFAnIxZWBM4xrjVsaTsbFEcJxjHfsYJDyWzI+H I4UhK1ZUb0CikZfM5BsKRRpB3o1+derkKB+myQqxspZRiOWDbLmMXTbIlwsTZi+L9xxjTnOUAgIA IfkEABAAIQAsAAAAAAQCMAIHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48U 7YkcSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz580QQodSrSo0aNIkypdyrSp06dQo0qd SrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27dw48qdS7eu3bt48+rd2xCo37+AAwu2+Wmw 4cOIEytWzLex48eQqS6eTLmy5cuYM2ve/DOy58+gQ2vkTLq06dOoU6suLbq169ewY8ueTRvv6tu4 c+vezbu379/AgwsXzm+48ePIkytfzry58+fQo2uuTb269evYs2vfzr279+9JpYv/H0++vG7w6NOr X8++vfv3eWnBn0+/vv37Gc3r38+/v///AAYo4IAEFmjggZbhp+CCoCHo4IMQRijhhBRWaOGFGGZ4 HoORScBhfRrqxEWIJJZo4okopqjiiiy26OKLMMZYIRMy1mjjjTjmiNqHPPZYl45ABumcj0QWyZaQ SCap5JJMNunkk1AyZuSUVIoV5ZVYZqnllstV6eWXYIYp5phklmnmmWimqeaabLbp5ptGcSnnnHTW aedkcOap55189unnn4CmpOeghBZqqJiBJmrnoYw26uijkEYq6aSUViqZopi+9IaQlnbq6aegupXp qFmGauqpqKaq6qqstuoqXKTG/wrlq7TWauutuOaq666fyurrrzXmAmypvBZr7LHIJqssUcM26+yz 0Ja33izLVmvttdhmq+22RUbrrYvchivuuHE5ItS36KpI7rrstvtZhsWlK++89NZr772HuasvU/j2 C+G+AAcs8Fr+FnzgwAgnrPDCDMtl8MMDNizxRBBXbPHF6E6s8UMYd+zxxyCHLLKUG5ds8skop6zy yhKN7PLLMC/JMsox19xkIDY/PPPJOffs888h7iz00EQXbfTRSCc9KdBMk6a0wk1HLfXU/j2dMNVY k2x1wFl3fVMtXoeN2dYDi2322WifRrbAabft9tuJrc013HTXbXdOcuetd6p39/990t7u+i34SIAX bvjhiM83+OCJN+7445BHLvnklFdu+eXXLS445pxbfk/noFulud+hl246eKP3ffrawewdjpup3716 rrHXbvvtFWOD++689+777xfPLvzwxBdv+OvhxmP8rcCbvbyrzUcv/fTUV2+9ic9nr71t10u9vard hy/++OSXb35v36ev/pHnt+/+luvHL//8Kr9v//3456///vyDTP//AAxg2fr3MQEa8IAITKACF0gz AnqMgRCMYEUcSMEKWvCCGMygBjfIwQ568IMlkqAIR8gQEJrwhEMioQpXKBAUuvCFw2EhnGBIwxpu SIY4hKANvZXDHi5wh0AMImf/fEjEIhrxiEhMIm2EyMQm4kmJY3KiFKcYGChGkYpYzKIWt8jFLrrM iojSTQO8SMYymvFBYEyjGtfYmjP6iY1VcqMcuQhHKs3xjlisox45FxxY4FFaeyTSHwfJxEAacnKE lNMhF/m4RI4vEo4UDCM/FEktTZJDlcykJjc5oUsyiJOzqggAAODJ7NBklKBU0igBkMokobKVSHql 18Kxu1XCUkiyvCWQWKnLG6nlAaW0Ui+Heb9g4oeYyEymMldjzPss85nQjKY0pwnDZtqHmtj0nTVB lM1uevObLZGbKLZJzoA1YmjgTKc601nOdgptnfC0mzvnubK+5SCe+MxnhYxH/wPo6fOfAAXMAYBI T/Z8i5YBBeE9E8rQhjr0oRDtX0EnStFgRjRCFc2oRgN50ZrxsqHUGeVGtSPSkWKnpCa1DkpTGlJS srQ6K33pbGIq04R09KYl6QdOq1lT6+z0YD2tzk+HGrygUoeoBDKqUquF1KY69akdXapUkQXVqs5r qrLJEI2sytWu1gmrsfGqWJsFVtiM9axoBV5Z18rW4aVVPG2Nq1znmtK3SoeunrFrdPAaGb369a+A DaxgB0vYwhqWf3yFzGEXy9jG7i+xj3EscCDrGMla9rIWo2xj8HkKzOqms57FDWhDe5vRkva0dNMs X1DL2ta69rXkU4VMVLsX2P+qjbZ5yeYabMvbtOE2t70NLoJ+S9w9Cfe4yE1uwYrLXNgpN0HNnctz p7uf6EqXutgdj3W3y925ZTdu3RXVd8Eb3vLacbyIMa96jYTe9K73vWpyKXyhYpOPttclFpHvfMmi 3/0q5VkhKBA4SEOP+/bLvwhOsIIXbEADOziGDP7KgydM4QJFWMIVBsqFvZJhDW/4wyAOsYgb2WGf jBgrJTbxiUWXYp6smMUtjrGMk/Piqsz4xjjOsX5qzOMe+/jHUNNxUIDsFCEb2TBELvKRY5LkJnNv yVCOMmWcTGW68CQYKa5yQa7B5S57+cte1jKKpUxmnYj5KGVO828ooNwzGyUBIAAh+QQAEAAhACwA AAAABAIwAgcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjxTtiRxJ0t6vk79K qlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnzQrAR1KtOjKk0aTKl3KtKnTp1CjSp1KtarVq1izat3K tavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3L9yXIv4ADCx5MuLDhw4gTK7bYt7Hj x5DzLp5MubLly5gza95cMbLnz6BDg+VMurTp06hTI4SkurXr17Bjy55N+6Lo27hz6y5au7fv38CD Cx9OvLjx48iTK1/OvLnz59CjS5+efLf169iza9/Ovbv37+DDi/8PS728+fPo06tfz769+/fw48uf T7++/ebj8+vf3xQA//8ABtifgAQWaGBO/s1034IMNkgYAA5GKOGEg0FI4YUYZkiRhRp26OGHA3EI 4ogkSihiiSimiOGBLLbookoqxijjjDTWaOONOOao44489jjbi0AGSaCPRBZp5JFIJqnkkkwOJOST UEYp5ZRUVmnllVgS1eSWXP6V5ZdgStblmGSWaeaZsjGB5po6hunmm3DGKSeUbNZp55x45umVnXyi qeefgOblQaCEFmrooYj61OeijDbq6I6JRiqpTY9WeuYklmYa46ScdtqSpqBC6umopJZqaqShpnrj qay26uqrsMb/KuustNZq66249qTqrjPm6iudvAYr7LDEFmussb8mC+SxzE6o7LMsNittg9BWa+21 2Eo17bbcduttRNmGK+645NaUoT3fpqvuusGV6y520eXA7rz01ivdu/jqZu++/Pa7Zr4Ai+bvwMQF bLBnBCcM3MEMO6bww7U1LPFeEFcc28QYZ6wxnhZ33NrGIIcs8pQel3zayCifZfLKnKUMYBOSsizz zDSf5/LN5NWs88489+wzgzgH3dXPRH8k9NFIJx1a0Uw37fRlSkct9dRUV2311VhnrfXWnpXB9ddg hy322GSXTfLTaEtk9tpsr53223DHLffcdNdt991456333p3B/3RP24AHjjTfcAtu+OGIJ6744ow3 zhcEjkeuMuFpS1415ZhnvrLlVGvu+eeghy766E1ybvrpSnGB+uqst04X6WzKe7HrtNdu++245/7W E7r37vvvwN/WRfDZws4z8RkbvzPyGCuvM/PQRw+s8zNLzzD12Gev/fYlWn8w9yZ7L/745Je/E/jo p6/++uy37/778Fdq/rvxDzy/u/Xnr//+/Pef9/0ADKAAB0hAXPnvgAikVgGvlcB1LZCBDUzXA9HS ByFF8IIYXM8EN8jBDiIugyAM4b08SMISjkWE0zKhTGahwhYyBYUwjKFxXGgrGdrwhr2hoQ53+BQc +vCHH+NhrP+ASMQiGvFnQkyiEpfIxCZW5YhQjCJinEgoAFgxQVSklRQ1lcUuevGLpdqiGMfoETB2 ioxoTGPfzBgzNTJEDV1ioxznSEc4ufGOeExIHffIxz4+KY938mOgAFknQQ6SkP8y5J8QmUhFOhKA jPTTIzkWScqsopLcm6Qmy4fJTkZxk3LypCiLCMo4jZJLpbTjKVfJyla60nipfNMrZ0nLWmowlrjM pS7bYssi7fKXt+slkYB5JWEaM3/EtNIxeZTMZjrzmdAM4zLbFM1qKm6a2MymNlVjTQtus0bdDNI3 x0nOck4xnOhMpzrX2SJzboqdS+EGZNxJz3ra856EawA+99n/I3gaiJ8ArZs/CxTQDg10SAU910EX ermEroihEI2oRCdK0Ypaz6EPtahGQYbRC230oxrrKIVA6p3ZLEKkmCGpSq+H0git9KUAa6lLYUrT csnUQTW9zk13KrOcWoen3HsFIH1KVAgC9ahIRWNRl8rUpjr1qTlLqnyg+hmpzoeqCLOqVrfK1a56 daRYDatYx0rWspr1rKb6qlq9hVa9rPWtaIsGXKHWVrzM1WZ1zSug7srXvqJPr4ANLM78Oh3BGlaW hI3OYRf7pcQqlrGQjaxkTTfOL/RqspjNbLUcy1nO7KKzoA3tlrjRMc2iJW7yEK1yUvs/sckDcHJj 7YVCUCkJ/6RLtnYb22vbNjfcqrY4vp0b2XZrWg7+tjrFLYuSgtDK5Cr3uNCNLtOcS93qsmp/D5Cu drVp3e6KZ7vD8a54x0ve79XMBrAsr3rXy97Ngve9vmyvfOcrJfgujL74za9+94sv+/6GvwCui399 I8hoBPjACP7ggCPWQQkk+MH8iUKVFkxhcEL4wmphAYY3vKcKe1hFHAbKh0dMG09wM8QoTrGASczi Frs4birmyYtTE+PzzfhkNc7JjXeswBzfhMdAto+Ph1zcOpB3DqYM8maITCkla4bJ5nKylKeMJCjT hMpYRo+VtzxWdnzlilwuyRWtSJYKj/k1hh0zFtXyXiv+NxHMcNZJludM5zrbOXxxbklAAAAh+QQA EAAhACwAAAAABAIwAgcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ sqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnxgBXLRHtKjRo0iTKl3KtKnTp1CjSp1KtarV q1izat3KtavXr2C7AghLtqzZs2jTql3Ltq3bt2bHwp1Lt67du3jz6t37Ve5VoIADCx5MuPBFoRb5 Kl7MuLHjx5DJ+rVquLLly5gzz0SsubPnz6BDk+RMMbJpx1NOq17Neu7kqqJjy55NWzDpia1z697N u7dv2LWDCx9OvLjx48iTK0f4u7nz59Cj511Ovbr169iza9+eXbr37+DDi/8fT768+fPiuatHSWu9 +/fw48tfjr6+/fv46c7fz7+/y/wABijggAQWaOCBCE7l34IMNuhRghBGKKF3DlZo4YUOTajhhhyu huGHymkA4oMdlmjiiSimqOKKLLbo4osDjijjjDTWaOONOOao4440wejjj0AGKeSQRBZp5JFIJqnk knzx6OSTtDEp5ZTjQWnllZ1RqeWWz2Hp5ZeEcSnmmGSWaeaPYKap5ppstunemXDGOZ2bdNZp5514 5qnnnsrJ6eefgAYq6KCEFmrooYgmquiijDbqqIl8RirpQ49WWuikmGZqkKWcdurpp0dqKuqopJaK J6iopqrqqqy26upppsb/euertNZq66245qqrrLy6qeti7Pwq7LDEFmvseb0mq+axzDbr7LPQRhug stR6Ke219VWrLZTYdlvetuDu6O24jI5D7rnopqtbuOy26+67mqkrb2/w1mvvvfjmq++k8/b7Wx/+ BizwwCjua/DBCCccEcEMN+ywhApHfN3DFFdssX3/3CDxxhx37PHHIId58cgkl2zyyRCHrHJsjrqC MoArxwzayzTXbDNeMucc78089+zzz0AHLfScOhdt9NFIJ53w0EwXpfTTPTXdNNRUV2311VjXKfWi WGzt9ddg75b12C2F/TPZaKdkts9pt+3223DHLffcdNfN7dp456333nz3/+2p3YDzuUbghBdu+OEz +q344tEi7vjjkEf+OOMlS2755ZhnrvnmKlPu+ee/ci766KSXbvrpqKcuI+ist+7667DHLvvsWqlu ++340i4w7mPrHjDvWfvuL/DEF2/88cgnL7LwlJ/C/KHKRy/9qc9Xb/312Gev/fbCTn809+CHz6L3 5Jdv/vmWia/+qoNQjH7M60P7/vz012//SvE/e//+/Pfvv0T5c9b/GJQClgWQWQNU2AERmECELfBY DYygBCdIwQqa6oHGsqAGI0KPDeYEg8XyYL1ASMISgkeE8DJh6FDIwha68IUwjKEMZ0jDGg5Ehbuy Ya9wyMMe5kaHO/ShEP+H6Bgg8oqIrzKirJDoKiXGiolQjOJcnHhBKaaKiqWyoha3WBYsevGLm+Li 38CYKTGa8YxoTKMa1yhAMmKKjXCMoxvfGMc62vGOeMyjHve4vjnyi49/MgJR/EjIQhryS9HpASCl 05ke9OCQdnIkJOskSdE4YJL/6I0iF5mewlQSk2z6JChnwxpHchJZkUrDHBGVBjtOSpWjdBMswXjK P8XylrjM5Xpq6SfBzEKXpOSlMBcIzGIa85jITNswl8nMZsIsmVdypjSnyRYxULMt0Mym9665JW3e jZtT8uaTwEklcZrTeOQM5znXyc52uvOJ6WTSO+dJunjKk56Js6c+QYf/z35mbp9J8qdAB0pQgQD0 oAhNKFgKeiGFOhRvDI0oTAAhURc+9KIYzShSKtogjXpUaBxlEOWE8NGSEokfJk2pSlfKxJAuiKUw JZlLZ0rTUcb0RDXdz00hldOe+vSnQL0ME4JKVIMswV07TapSI7SKpd6xqFCNqlSnihunWlVeVM1q xK6aMq16dV9cDSu5vkodsSaIrPQxq1rXikG0uvVC8xAMW+dKV/W99a7tWtUjoIjXvm6rUwAIrGBf c7JCUAhTgx2sEevK2O6JDhtya6xkceVX4kz2srSqrGY3y9lYYvazrOpslEA7rCVcVbTBVFwASBtF 1MqGteZxrWwjBdva/9r2trjNrW53y1uezTY0vY3ObxcCi+U5zGWfG65yl8tcCQYXOs3NzHO7FN3L TPe62M1upY7goupaV7vgDa+3rJPY23h3MOU9r3rXm1bxujdU7B3Me1sT3/raF6xrUcF8uXLf/voX qfsNsIAHTGAV/tcnNqNBgRfs0QNHjcEQLpGDJ9yfCDOGwjqx8GIwzGH4aPjDEeqwiNUD4r2MeCKa CEmJV8ziFrv4xdc7yTJOTOOfwPjGOC5SjXfc3hyrahc+DvKAeQwTIbOFyC8x8lqQzOThKPnJUJ5Q k6dM5SrTMcpYzvKhnPBeK6NEy2Txsph3BuavjPnM6SuzmdHMZvmq2RwrbY4zYN5MZ8XI+c4Pnl0I 6sznPvvZh3juSEAAACH5BAAVACEALAAAAAAEAi8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fMO0JHUq0qNGj SJMqXcq0qdOnUKNKnUq1qtWrWJmeysq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq 3cu3r9+/gAOXBUq4sOHDiBMrXsy4sePHkCNLnky5suXIgjNr3sy5s+e4l0OLHk1a9OfTqFOrXs26 tevXsGPLDqtwturSuHOPtp1at+/fkQUItzecqADiRY8LX16cuXLny4dGl848efXk2I1rFwp9OvHp x7Mb//WO3Hp35UKBq1+/c2n44tLLxw8vnvt26vjly6dv/z5y/vShV9932vHXn3EBvjeef/rx5uCD EC7433YBHsjggAYqGJ+FSFVY4XwSbjhggw1q6F+GEaaoooMKAnigiReeeJSALzLloYgT1mcgjhzu mKOMMa4o5JCfafjhkdBxBx+Q2LlInY81fmjfjk6O192IP+KIIpFcdsmZiWDu596WHE55nZUz1ihm j0FSiSWNWmLp5Zx0slVbmGJKqVSVJP4IZZl+6uecjh2GCCicFm7J3qKMyuReonnyWCiPW/L5ZqQi knmooWySaGmdUIkB6qhY3dkjnz5qmmGCnWqa36uqWv9XIKcEKhkng+E1quuuKe053KonJvkdeX2S 5+awS2KIa4zXHWsllcSWSOq01FZr7bXYWltbtnDx6u23KnHbLbjklmuRuOimqy5e24qV0Lp2mitv bmS9C69a8+ZLWr0I3YuvvgBbls/ABBdssMFEDVyUwvYK9UFRDxP18AcU2xOxxEpRrPFQFxu1MccQ h4zxyA5XDHLIGpvscccWT1yxyg63nLLIAdc8WT5J4TyUzkLxrHDCODdsMcYdR2y0xxmPzHLJHB8N ctFIx8z01EtPTLLELJtsdNZDY32yzWAXphTPRpFt9s72+Jz2UxdbLXXXVSd98tJdn1y323WT3LbI cUP/jfTeTuM9dNxv+2t4Z2QvnPDiPa/deOJyD26301dHLTXhfD9tN8qba8555zEDfnnegs99+Ol8 KXQw442j3TrOOgfdr953my4yUinvfbvSnudNNOiSf1646YGPHvpRToet/GKQu95zwYzD3rjQcNte /e6WX1+58brTXTjdpQ8+M/LHX9+978Yvr/5hzbfu/tnv20N98PRrD3zn4YPfe/hX69/3/bozH/HI 17X1GRAo7XOc+xSotunN7nflM972Ksc/ru0PfRTMnPAwGMDiaQ5zQzmgCHmSQPi5rnmyO8jKIOY3 EGaPcl6bmgxnmL2WNW1zMESf/uxnw6zpboRAdMnYR3LGOrShMCoWLJnLZpY7H35MZk+UGQHvB7wo KjGA+CPfxnwIRZhhEHVgBM38vDLGMHIliGikCb9UaEbapPGNJWmjHOcIxoAAACH5BAAVACEALAAA LgAEAi8ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePFP+JHEkSpMmTKE+S XMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQEemHEq0qMSgSJMqXcq0qdOnUJsanUq1qsCoWLNq3cq1 q1efVsOKNfm1rNmzaNOqlTmQn1uCb+EWjNuWH1y69vDmzeu270G7beci9Guwr13DiOsCFpiYMeLD hhkuVhzY3trLatth3swZKN+6jgXfnQuYbly9h0nLnbx4MujQsBnLHQ2btezCs//i1bvXcuffwIML X9u7curKgVv3dl26+F7Xzo/fdo58OvTc02/bpp79OvbrgHv2/xpOvrz54ArBP8e+Xrb01dG5F3/f XrRg79XVb1df/W///2MFKOCABBY4ln7WiXYcfe4lyF99DeKGG37d+dcYX4ltl1BrkQFo4Icghiji iDAhqJ2Cy8knXXP8KccegAzap2J8KnaYXn6Vnafjjjz26JKJKeamHJAs+ochaoNZuJCG8DVpH4UJ zhaej1RWaWVn1DWX3JPGobgldC5muSGXY7Kn5ZYSZmekmARd6eabcDK1JIdqIimhaWeGxlyeNOr2 2mc40gbofmuqKWOYUI6o6KKMNtoRTJT1Z+ehu6n2mJkvkgYeYTDuZuNjDG7KKae9xWnqqah65uiq RqXq6quwst0q66y01mrrra2+hOuuF8Hq669v8irssMQWa6yIpwKg7LLMNqvsjhEAK+201FZr7bXY Zqvtttx26+234IYr7rhPHWvuueimq+667Lbr7rvwGkTuvPTWC2e8+Oar775i2evvvwAHLPDABJPL 78EIJ6xwRQU37PDDSi1cVDgSV2zxxRhnrPHGREHs8ccg08RxgLKMbPLJKKes8sqzhuzyyy6zLPPM NKsE880456zzzjz37PPPQAct9NBEF2300UgnrfTQAro0kNNTLS11t0239LTVUU+tdaw1d+311xEF BAAh+QQAFQAhACwAAFwABAIvAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyABiAQA0iO4kycHolS5UiDKlPZexpRZsqbNmzhz6tzJsyfGf0CDCrVH0udAoUMFIg0KzmBTl1Cj PlV5cOrRpVizat3KtavXr2DDih1LtqzZs2jTql3Ltm1ShEULjhQ4VyTduXeLjtQ7kC9FqzELNp36 FDDgqEYTK17MuLHjxxS3xu1L2S/JuJOJaqa7eXPRrFeXvhwsOLDUljOtHnbLurXr17Bjy55Nu/ZZ hZk7X+asGXPe3byBXzRcmqbpqlQhK1/OvLnz5xAlG/RtWbd1370NglaKlThB0scPJ/8/Htq2+fPo 06tfz7491s68s3u+Xply/M3b7WU9TBhx4YT9FeTegAQWaOCBCJ73W17BcbZXX3XZB99n73EnWlUw kTeYTMaRZ2GCIIYo4ogkFlhRbgyhqF+FKy7VU4kwxijjjDRq9ZGKuEGn44489ujjjx/VKOSQRBZp 5JFkAankkkw26eSTUEYp5ZRUVmllREhmqeWWXHZJ4JVghinmmGRW5OWZaKap5ppstunmm3CuWeac dNYJ0Rl25qnnnnz26eefgAYq6KCEFmrooYgGGeeijDbqqHqJRirppJRWaumlmGaq6aacWvnop6CG KqpZnZZq6qkejarqqqyOiuqrsMb/KuustNbKUKu45qqrnLb26uuvwAYrbJm7FmvssUMOq+yyfiLr 7LPQxsjsctFWi+a0ylmrLZd5iudUmVNtK66MChk3mkuopftdaoatdC673xEmb0oZZohYauN5y1C6 5qKGrrsc8suSYC0FqC+2CDu0lcGlNWyaauGNd6+HA6M7cb3eRaxxRAHeq694HRcmr8PgBTjuyUQy vO7KVEGsMssTtxwYeOuSBvHF+Pb73835SpwcyD3PLDTLNpeG8tE0GszvfzU3LZVTSxcnNH9TEy21 fxHb62HIyLHL9dNFW611YEiXbWC56iJEM1Qupw2zww+z/W/cGvpMc3/nUm11zG/7Upc20yzBNPbB CReO0MJYq7113YDr3fXTQ8tNd+IyY52x3UEr/i3kdF8eOVRmh+5euT8DmLjLmfPtccN4w81z45V/ njrPpW+usXeAc06x4bwjFBAAIfkEABUAIQAsAACKAAQCLwAHCP8A7QkcSBDcQIP2EBI8KFAhQoUJ IzZkWHBhRYoUHUrEuHHjQ4wGNUIEeXHiwo8WNZociZKlyZcWY8qcSbOmzZs4c+rcybOnz59AgwoN +q+o0aMQQ4JbqnRpQacHmcJ0KJWpU6snszasqpWj1Kget6JMCZVjwq9jSybtKDFtWIlH48qdS7eu 3bt48+rdy7ev37+AAwseTLjwv6GIE9scqbixY5oIDUueTLmy5cuYM2ve+7izYsaeQydWaHTa5tOo U6tezbp1YrqiYwtsTbu27du4c+s2LLu379/AgwsfTry48ePIYwJwvPxx8+TQo0ufTr26YrsAsj8f uN0mbILbtVv/1J5doPiF3ZWjf17ePPrZu+PLn0+/vn3K7IF+Ny8+v8zl/nH3HnjhgeeePd01d9+C DDbo4IO15Qcggvw1dx6F9uw34YEYjsdhgQMayOGBG74H4YkopqiiijRJaGGHHb5oU4kBDlhjejhy d2F76cFo3Y9ABinkkMeR9yGM5PXYIo8CenhkkwgmGWCNGLY3IpFY2mRFllx22WWCAoLo04RUPomk kyLG+J6MPnrp5ptwxjkdmO6JyeaMFPp3I5Rt5mhmlX/KKeighBbKXIgW8milkustuiifUfoJ6Y5W flimoZhmqimhdr02V4iIMTqUgiuWauqpqMbnqVyghtrZc6nG/yrrrLT6temt0smD6668BtepbPvt J1StxBZr7LGSjVlTd8F+ihiy0EYr7bRFRSpqq2jCx6q2cQXgrbf2fAuuuAOBKxC41Kar7roMttjT tdfeFEBM855b7rn1hptvr/z26y+hdOZZnqKOyhjvTPvea+/C8zYc7r8QRywxludJSKKaFreZk7j5 dqywww5PLPLIJMf268UG1xnmygQ1K1fCC+tr7sM0z8vuzTjnPJ+IG6accZ4LudwtvR8X/bDOSCet 9GQ4TYkyy0BrjBPMNFddb8JUl6z11lwLZSSUPlOask9Ue3wv1l2nrTZPUKwNqdtwxw1kH3LrdHDd eOet99589+zt99+ABy743ydnKazUMS2t+OKM15Vko3cTeKGyFh0ecKTcNq755jozeimeXifubIWJ gp0h56inrq7nPDN5JZJMJkpwhQdq6KPTqueuO6pLVjoimGX2CCCbNJ6JZ8CfD6788sMNX2KVFWsc Xn+mPx655Gkmz/z23PtU+OXFR40o1D+/fvq25Ju++/rsQ+julXqart6RTpcfefhqdq///j11Ojnp kvvc9AYWQNrxp3aj+xrmDNi+BjrwRKFzFU4sl5MHWvCCtgnN9f7juwjy74MgDKEIR7g/DJrwhCi0 FQlXyEKSQegIKYyhDFMUEAAh+QQAFQAhACwAALgABAIvAAcI/wD/CRxIsKDBgwgTKkx4ZKHDhxAj SpxIsaLFixgzatzIsaPHjyBDKrRHsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCr0Z YqjRo0iTKl3KtKnTp1BtipxKtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3DjeoxKt67d u3jz6t3Lt6/fv4ADCx5MuDBKuYgTK17MuHFYw5AjS55MuXJdx5gza97MebPlz6BDix5NurTp06hT qw7aubXr17BjZ11Nu7bt27hz697Nu7fv38CDCx9OvHhwc8Z9y17OvLnz59CjS5++HA3169iza98e Mbn37+B7c/8fT768+YvhhZ9fHz29+/fwQ4+Mz5u9/ez88ue3p39//5L7kRSggPwAWCCBACbY34H/ mfTfgvw5yN+BEQ5YoH4TJkjggAZ2KGCGH26o4YcWGujfgxSeiGGJEJp034uxsUShhCFGCOKNN1qY Yogz2ohSjzXOeOGOJdpYJJAOpkjkjj4yKOGRJ/Woo48IBknflbYhyaSRFVJ5YZdcgknlmCPS6CWY XzrJpZNIasgmiWtGeeaXYpbZZZpyqnkmlnxKplCLTbp555No8igkhiJGyeGWgzaqJp10qvRonG8S qmCcigaI55CahrknjKA+p6WJTOoZ5qQ4tkmmlTUWCumpcDL/yCGsjtZZ56uR2jmplHC2WlKowGom Y0qlCronmxBGqmqbWwpJaa+77rnhirFWaym0to4ZLY3K9umtaaOyyquuc/K4ErMjOqtkk6iCyKi6 Ha4baLlVjkuuvUX6+u2+kIVLb5m8wksiirM22GqD6ybsn4cTLnrtwlU2nGSnERMMsYIPMuwsvxx3 7PHHIFM2X8ikBWvyaySnfNrJZans8sswx1waAD7RTPNkN8t818gmAeCzzzjlXNLPQkcFNElH31X0 0EvbJfTPPRedNNA221N1TE0zPbRNULOUtUssu5XS1zMtnTPZSk2NNlNZJ40X0VZvHTdKam+9dtln 15T3Snen/xR2W2PTffTVXVtNtdt7G3724IPbPXfXhRced9U3Qx652oxXfjjTmmd+UuVIW4450nZf 3jnnPc/9ueqrUz7564qH7vbkksN++uOky+1457cT3rg9f7M1Ntx5/w577qnnXnzyx9sMuu5Xt348 6YlT77j1uC+P/eq4bx/996pHHz7r1ycPd+qupz9+9eBfD/7zT7f+fPOGI5978GtJLnX5RDuvO+eL g9rU+Dc+APqPe/AToNyIVzoFZo+B2zMf8t5HQO3JbnOCi98EJfg69XkPff8DnfMU6Lr/0Y96EKzf YfCXlsAxr32fE5/yTBi69RGQhiqcIf0sSEEOytCCBuzhDpIryLyo0a17G1yg9Tx4wg8q8YcdLGIT oWhEF7HQK2Xj3hRBqMX5xY+HBUyi/fYHxjK674NAHKMN0UhE6Ekxii+UovqE+MUQam1v1Uti4oSo RJ05LYNj9FwN7Ri7QhoyhYUUnRaV58DHia53OoTcAjXIRkYGsH2KNOQFL3g7E85RdmJsYvg6mUdQ BlKQAcShH3USEAAh+QQAFQAhACwAAOYABAIvAAcI/wDtCRxIsKBAAAYBKDxIUCFCew4HLpTY8ODE iBYfQoyoceNDjBgpVvSIUONHkCg/MoSYcSXLjSMZmnz5MqTDkiJTtmyY8uJEkRRx4vTosuNQmjR9 znTJc2nGkyp3IjVItarVq1izat3KtavXr2DDih1LtuzWjmbTqr2Kdq3bt3Djyp1Lt67du3izhszL 12rbvoADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5iZYv6bubPnz4r/iR5N+uZRkgV/OkVN0iTa m0g5m55a9aRE17dVB4U9G+hMjjZh0069V+tezrmTS4XJtXfYtsIDk55Ovbr169iza9/Ovbv37+Cx v/+OadSp0aBUf049nz61cYu34xddGdW9/aT0cyZk+zwncvy/6efVf11BB1Rf4SWo4IIMNuhgdvzF hF9+Mt13GoUGHijhcBayNFRUSx31V4YT1lffhij25JeGKwZY4VfQXVSTagsd5xuNUM33oVLKgeaj W8KxVyJ6TUEVomatycabXuh9SOGMRaLo4ZRPGimlci4OJ2SEWZZUHFaz/WZibPtVSeaLHp6Y5Y9s eiXefaw9SduaGJaJpGbleSlinTPSKOWIU4ZoU3vAjRcmi+OB6RuABxa6YZe8rfZUbjWaxyhTYWr0 4Kacdurpp6XBaaJzJF5o2oVn2nlnhzUl2SqagO7/J5SAkq7qXqLrqdreol0212GtMGUIbI1EUpkq T/aAquyyzH4aYaMCzverqHiOhKuti1Z03pGvwkmetdFeeWuxW0L7KLkTvvetpcVmu9qevWaLbZv0 DiRepMS2W2uQS96Yr5zrfQmutgSjS2pt/pLZ23/RqVhkjnjy69rEBSYkI5Z+mquTVP3utHGzIIcs cnf1EniWjyY/C2O9LLfsMmIpn+xZzCuCRfPLOOes88489+zzz2FhB/TQRO888tFIO1v0vEwv7Wtj Nze9q1pJV221dmzhdpiS6omVp7wD4ig2cYVWmjFzlErrF7AyL1Yuwk9ziKjcTjt2dmGxqsUu24pi /ypu3oLKxyvTuvXH2NtTq0s3h1HXfdebsxIVZ3A8EoXjpJLfCVKaXX+rrdkUG5ur2gOz2mrkg6fs pOQgckw25g1fzHnolH+ducSkl43xtjxe7fvvo/GHOqzjEt96ryTyOubUhg4u07XpxnqwtLPi6uXJ KrmYva4Gd2/8uuZemuu7YItOvOOQtY6aoP/qmW/2HaNaavRwj688R7qyWz95g3YL+4jq2d6hqge9 +IkPXvoyoLz2xBpTuQt/xUMb+g6XH+R5j1ajM9+c0LUqSTHQfMmjX81Yxa0CLq6C9hMR+b7HQmOd xnqec+GQYNjCdklwgnx5U8FkaMEXba+GGoqX//9StTweMk9CwjoiwNQXrvq1j3TpOqAUe6ij8FFx X87ToPySBbwuVk1lfWKgxCCmvs3RJ0aVmxgWexQs/5yoKd4Kkuaglag38q0oECtR4aIUr9rpMY/R gc/tHKYlMaLEWnrCoc4aJxfVKbIujLRMJB85GaGlRWCCidkkKdk3nG0SLF4M5dE4ScpSmvKUqEyl KlfZGQKhai40u9knWZmXWcLSLLakpUEsyb0I2iWWYHxlczpnM0bGSHB4qw0mV4aXqNlyk6KM5qb2 R6haxk1xhjuhXoxpMWQSJm96e8wzxyLNcjLoeJSrkAcvBr/LYS45YrqclcgowyA20I32oV0aAxj/ KI+l8385cifu5kbP53UtdqHzoUBlxL60OTRAAf0n6yZizopeh0strJ4VX4XA8/mthh3dTe4iGNJ8 frSK43KgB6eIQiDOaUxCjKIGmbMmiF5QSPBSkz1xqkub9dOCP0xdPw36RMEhr4cdAyFJASQ9QaLt UCYN4x9zCsF2PlFYRTXiSedZqqRCdUcQJKIUH1gpSuUSfZAbqhGDWkWNogmKbfQosWz6Vgfu8IMB JBVuoMdRlgLxeNOilqViKkR+VsueVKIhSuu52L0WxKKQJRm31jo3M/lVS2NVZ5NsCLjGIvGzF9zp Tf0a1JJm8YrgOyn9eKq/D16WtXSkSGRnC6HJttJzWHtcnh97hK+C9iupjBvbpIrDO0DerY5htVID 2XlG3aLxhWML5FQzh6mFFnGQeY0uHNmXyJ3Q9rvVweUir8mms77FvIFB71bAy97glUW9FGwbyogJ M9DANyvtNWdP98vf/iLoov4NMA7zS+AGvfc59xWnMNG3yQR7i5kCbox1ePAP+ZLXp7fEpnLh2smt FZO+d2TSLx/c4a5IswwFZtaBIew1D9uwfDsbFosqNuKxODjCZAkIACH5BAAVACEALAAAFAEEAi8A Bwj/AO0JHEiwoMGBAA4qJJhwoUOGDyNKnNhQYMKKBStinMixo8ePBzWGRAiSZEmPGz+mPMmypcuX MGMe/Eezpk17AHJaxGkxZ0OfO3/qRKjzYk+hFzcC/bkT51CiSaH2PBoUIsmVTo1mlcrTqE+NQBkO DbsUKVizTcNuHZl2bFG1XLV+pdqVbly3UbMynWuXb1yea20KHky4sOHDiBMrXsy4sePHg0WOvXqV qUGwTesCxihyM+DPnkF7lqzUKtzPWjV33Us5M2jJaVFnlJ06tUK+sDNzrqybtuXZJjWzrppbNda8 IiErX868ufPnjouTXkr0cvDcv2nX7Rx7M1ntwF2//25tHHz54OCHey9K+Wve2+Rro5demfrU8Omr Eq/PXvzcszpBJ+CABBa4nEP06YeeU1bJpl92sHk1X2ydyZfSbg2aZ2F8DrqGnYIb7nfZcRxyh+F5 qvl3Yn7lhXhdg/LJJOOMNNbI0WEJtmjdi71ZtmKFE45mkotBFunikR2O9yCIGqIY2os5nhijjvhJ GdqG9HHX5E4GdunllwY+9B1USOn2VG9/PXmfiWdeeZSPk42IV2ltndXjkKeRFedeav3Xmp5a6sUV g4GO+SZddmaEV3dJTVbhU34dylmbNlZq6aUlHYbppiVhxSlKLXn66aikygTmqaim+lyprLLVKken gf8k6qu01rqQqrjmmqutvPbq66/ABivssMQWa+yxyCar7LLMyijqrKBCi+BI0spULaifXtuRttZ6 ym2z4PqqKbaiVXkmpdSmuG26Kp30rUTvrpuhe4NGmiRM0M5Kp5ge6ervvwDX1K54YvWnJrzlyjtb vO7SyHCnGaKpZaAv5cvvpQFnrDF0017p6Fb22kaeoshth2isuH28llznCkoyon21CSiALwsnc597 wrUvk1L5lSfOrP1cZsEuN4rWapDGGu7SMeFIIW8d7nbhoabtJyHPd4oI9UpTJmyygvDluPBvVkLU Nb2lhQylkb4RXBzbSCJJEGPobGz33f9MK2GUC+r/zCOjJsud9dd+3mf2fJOyhzbX9jkpKIBl+zkx fk6aqJeVYg9e3Z1Zbsn055ju7TnFcsFYdeBUKqkjkQxyqKh2jJsuduZra72iaGfXvmPqU4MtFuwl eg768DYCiTXp6k4upOhYN3m1uuNRvHqRzsP9d/XKm56k5dkLrrt1EQaf4MPEf64pmxCePfPQQ1q9 HppkwoxWoq7H3B+gcsYYcuNrxS8p1QTrn70IhSelAM1DBswOzIgzM57hRiB4i6AEC1Mq8pUPWRbM Vq12hrALerBYGfzgsEK4KRI2LGILUZoIV8jCFrrwhTCMoQxnSMMa2lCE40LhDYlnQpV8q4cdqxEQ /+EztwkakWMpLBxFVJgsfS2NgyxxIqwWVKl3PYuK1sLiDoElPSKCTorgGmIAdZhCLTpsRl3Elxm3 yKlx0cwuAcTfnO4SJ9zV0Wj1egv7VkYp/IGsTEk7Gh8vpEc+LSqQVPPjydTzR0QuUk4P8iPLpCY0 l/WPKo5MGR7tccROegl+uQtP6RznPSCRzTz3AuW8/rQk3qnuR+1hpSulx719de56pBlcycDHtub5 qHq98aQwIRORWvpNlG56lMEYebm/Gc02mEGmh2T3tNEoEZqRglQsW/lMDfUOlapcHJkwB6VrTq17 /MGQegQnRjY+xI3fQ+GHZtk+KEYNdxFrGfxemf/Man7vWViSpcje1rpw7o6gUyHR8fD5u/rdU6Hr HB0nh0lR5xjUP8j85S1TaUpdqq6XH53nKOOmvYVtUzhMQmjZoMe9CaGzpb6LHkhDGVG+VfSmB7rn Jf03JkPSzHKQ9I0j+bjT1qFsUf302CkHWbMI9bROEmuUuRSY0ALaL6iJGxr9mkdAqJ5Oq3iSDU7H 6hhS/VBW7gxiWi9I1rYKrFdnHdhadzfXutrVITnEoVv3yte++vWvb10hYAdL2MIaVmMhIWE7JXLY xjr2sZBtDl2J5qrJLpF+OktJZDfL2c5y1rKp9Jpoy5jS9s3Es2PlBGpXy1qBKZKhZdHqAaFX2phm DqS1uM2tbieoUpM603kQLVGsdkvc4hqXQEEUGT5XaiElStOVd42udKeL1pimraSs4xo1uUrd7nrX uwh1EHOBmc/gdee76E1vXQ1Vs5MtMlGEVORsR6ve+toXdHn94HH3y9/+KiYgACH5BAAVACEALAAA QgEEAi8ABwj/AP8JHEjQnsGDCBMqXMiwocOHEBMSnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOq XFkwosuXMGMuZEmzps2bOHPq3Mmz506ZQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1 a0OfYMOKHUu2rNmzaNNi9Mq2rdu3cOPKnUu3rt27ePPq3ZtXrd+/gAMLHky4sEa+iBMrXsy4sePH kCNLnky5suXLmDNr3sy5s+fPoEOLHk26tGLDqFOrXs26tWvTsGPLnk27tu3buHPr3s27t+/fwIOz dU28uPHjyJOHFM68ufOtyqNLn069etrn2LNr3869u/fv4MOL/x9Pvrz58+jTg7fOvr379/A7qp9P v/Ta+kjj69/PHn9+/gAGeNxC/Pgnk4AIJvgXRPwUaJCDL0F4UIMUDiXhgxV21eCEEFJYoIcX2uOh gSROtuGDMYUYYlAqTqhhhw6uKGOJNPK1VowYnijiiR3uKKGKPIqYI4cf6igkikMmmWGPHyqpY4Yo NtkkgQrJGGSRRhqk4JZcAnYkjlG6yGSVIzIJppA/VunikWgiNGaUZ7I5ZUJStkklnWrCiSSbWnbp 559jfbnnnITyueegcpbZI51QgrjjmnZG+qOieeIY45N5uikmpBcC6umnKTkEYqFvRgopoosyaqig h3Io56uprv/66JqWatrqqqXGWuOuU2GUZq6wZooqp5q2iGSspG56KLK20kqssMEieiSo1Far0q+N PrlkmozGuS2MzX7Jo7Ywbjjppeji2eyIt+aYbqKY2mPtvPQuxytDK/ZZ7778WnQvvl/1KzC1/xZs MFz3HawwUQOrtXBRACQU8UITH1UxQxfTlTHFD1+FEQAggzzUxiFvjJXIBqFsT8krsyxxyBAvlXHE JDtkss0P3QzXzArpXFTD1zXkM0w1p9yVyiibrHRdPHMsdExDD92W1FJ3TBXJSa+cMtIiw3xQxWBz PbHXYGs9dtJiI0Sz2Vo7rTbFWdPstdNzbz0z2V+3HLfdbBsk/XXXbc/tsuB168234WinrffYedNt 9OB8u6x21oEv/nfVBwcEACH5BAAVACEALAAAcAEEAi8ABwj/AO0JHEgQAEGBABIitGeQoUKEChM2 XEjR4USJEBteZMjRYsaBGEFyNEjyoMiDEws+LCkxJcqPKl22rEgyZEmPNzt+vBnSosaHPlGuHFoz 40WiGk+aTDrS5s6eIFdSrAkUqsmrWLNq3cq1q9evYMOKzfqvrNmzLXMW1ZlTp1KmIwuK3Cj1rdu5 cV0q3UvTYd+rbQHLXUgXb1u1g/2+LEx4b0rGSTfKZXz3ZGTDiR/j7Yg45dnPoEOLHk26tOnTqFOr Xs36tMzNPtdWnmlUNmXEUTECtdzYY0W+bIP/nqw3qN3beQcHlmw0eFrhvyH35qybd/HGLDHbPZ6c 7sTW4MOL/x9Pvjxqra+nF4+49K9Q57A1L5V/eXti7u5fQszMH3l26/pB11mA8vXF1IDqTddedoUV 6GB3Al431oQUVmjhhRiGlV5c+QUmHHMchohbh/dxZl+JyE0VoFsg+ofZgwTiJyJ0LG5W34zMFbhd g/ztyFt0GQYp5JBEFomVXk7lBpNiQPrW05PVKenkbncdVdWRNtVlXJW+xfQYlBE59dOIKrGYJVG5 yYSmiU1VFSWNSP7I4Ztq5mgglUbmqeeefPbp559jSVihoIECSiGhgpVo6KKMNuroo5BGumKQiGoo KVeVrpjppZx26ilZo30q6qikljqqeaimquqqq5rq6quwxv8q66y0gkWapUZuquijuoLVK5G/Dnfo pXhiuhWryCar7LKfUWpsoWIF65Wg603aXlYgYmrVkV1JW2el2b434aa6hlvruYDe6muewUrbbbTW risstrhu5e2u6AFXJp/l6ksQswAHLPBoq4DnpGXsSVadwnjSliR1ByL1lJQO7/bfTBWPSRyVuoEZ 75ka86QlTLRtOZuWVJmsIk5WYkcyx2seFqabDQ1s8804n5WvinDhOFl8/QHNY4IHwqfgfj4nuKBj MupoYHxxXodglSgbTSObRXt3NNN3xqg0umAD+hyJWvNcW38OQ5yw0DxjDFvTVjcM53Eln0wnnG82 l+LSRJ//iHXbd3/bY4j2UVVs2IgXWS2QOfLE5rWE9/aaiyZu6CHlkVs899OJogg056CT+XPfHT6X dYwwune5jIm3jiFpCj8+4+ebzy5g0nOSHnncVjPdItye627ng3svxjaJNgpfY5O9qx5cztBHD/3B U7EX1MNfInnmfUmCvLLGH8LodvVdfr0fw+ttH76Z1qcZvsUeN+fX78lD/Jf3jo0c1fsCSe///8xy Hb705C4BGvBPAEygAldzQHv9aVsNjKAEJ0jBClrwghjMoKnUpcEOevCDFVqgCE8zLWg5SnMlHBa7 +GXBwxGrMiCkYLtW6MB4Dc5rnVPcs1QYq18VsIZCgaDx/zwUQ1pxEIY7BFYS53XDATrxQj98l6x8 mKvFrSuKFxqhFkOFHvWhr3pjClnLjGMV9clvSoYLYpsUUzIxqXFLdesYYeInsojV6YxSct+cJEay NWbLjH0E49asqEapXIyPMVFSHfNYxCDB7ng+o9yNpsa60N0OP5N0joSmRh+XES1qMCwe9+YCF06y 8USUgVvZPlZGszGIdsbbX/MGssVapsY7bowN7hzXpvatbpCQpF/ucDS+IJryR//ppcwSFifzmWxv nSmmZiw3GwDpUmpA/NsrRVlMtmCsOLYMZ2lSKblYJu1GoKsk7+yESd0JC3OdTM7RhidLS6KSdpSc GzWbWf654WBzZ9+DUPFSaS4qidOWAB0RPSWpPH7+cpdcG6YpHco7ZEKUnhElkzAVuk6+UJSizvvn ypZ3mVeaj6D3RGIjh5Qx7tUFf0WjHnXeqD2a7e+PF5ujTUN5t2e6EmE9c9u2sGdML0UHkQ9jUvp6 xsjszetJjNSmPIlqVJwksktYXOkRhZTVldaKXOPyqiMPusVFdVWsU/zKvdDK1ra69a1wjatc50rX utr1rnjNq173yte++vWvgA2sYAdL2MIa9rCITaxiFysksjr2sZCNrGQnK0LGWvayeaWsZjfL2c56 9rOgDa1oR0va0po2VWo4rWpXy9rWuva1sI2tbEUbEAAh+QQAFQAhACwAAJ4BBAIvAAcI/wD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjxTtiRxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRozc5IV3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT glzLtq3bt3Djyp1Lt65di2nz6t3Lty/fu4ADCx5MuLDhw4gr+l3MuLHjx0cTS55MubLly5gza97M ubPnz6BBQh5NurTp06hTq17NWqzC1rC/hp5NW27s27hz69b5erdvqLWDC/+oUoFx4/aOI1c+ErlI 58+bSz+enKSCk8ybQ09OXfl16dOta/9fnt069effuV+H/r08evLnuY9P7129/Ojv09/fH5+9ev38 gQfgbwQCl9CA1eGXIHv60SegggmW5GCE7WFnUoMRLihhSghu156DCGYInnYjYijghCEyqOCH4UHo H37fDSfjjCB1WGJ062U4oYY6WojjhjZu2OKPQl7oI4oapugjjCuK92CFIVaXY47iUUklkxRmaQ+N XHbZUHHl7QillECSiSWENwL4oYnmMYfhgO6JeOaYC273npNY7tijmVcaOaWIf5qZ55BRFmioUQoF +d+DgJKJ5IhtVohnk0UKyudyKK05J5NqZgqppHGaOKamjPbJp6WgThqjl6y22pCikvL/2GmgPKKJ Zqd4wlnlrkNWul59sja6JH31xeoip3sOOuuPbwK7p6vQelncsIxCSumZcsqp57Wf7gkih72mil6l uXarp6gkankrpcRqyWahfIVxaGOw8mqtut3l6yF2DO7ra36R/gdnd1ViOm6o8amLaokG85cwrvat +OuL3MI778UYZ6zxxhx37PHHIBPVW8gkwxTtyV2WrLJLKLcso00Wr5ybyzRrBqad/X3rrMMRZ+de sQWvOXDDFLYrMXx2Otzv0AJHSqyuR5ubMMDmzSfh04rKXJQKsYl5IqEXGm1stjeWCq6q6QYobKZe K3zskm4/WqugEDfY9rjc2qo1VVQw//ZmmWPrGmjg07499r3oJknkpEIa2yfEZG+7bKN/r8uu4ZuS uzfJidrLrOW7Wjne6Ebm59zTmnsnruhDQ+14sm+XvjaRky9et9m4b5tgzbxbVvjitM8+qLapd0s8 4k6ubqnewwMPuZKglx3uolf7+7qsUzO/uced93oq5MNDjTzm//6ruuLiV0/w9GhTy3jcPR4e6/nN uqn3qr3nr9nd84MvbPrH85bsove4okUPbXJLH/TyFrvXSa5adDuW7kaivwpiBmFi8t+skEa1ItWP euqLn72W1jSpkbB697pV0lRot9O1z3kgrJzlLEhDgZDjLtvLoQ53yMMe+rBjI/vhzLNqSETaCHE3 RUwiaI6oGyU6UTK/y+B8sAa7YrkpZ2lrGsKsZrqwGU1HX8QijqZGMaYFzFk5O90VVwioCTJxb93D 1/PKd7+yqciDn2pblFB0LrF9zXZVy9vdXji/tQ2Mcfh7oiIro8cGDpBN5UKWqfCFO+Ah8lThodXn FlYrU9UOjyM0pPuctMhSCmYlf5Kb2wTWwjI+aXmUbJ6UyAg4CTqqlpwsJPgmKUjq+SyFVNTeG1cW EAAh+QQAFQAhACwAAMwBBAIvAAcI/wDtCRxI0J4CgwgPClSocOHAhg8VSJRIcCJFhxgRJtxYsKHH hxghHrTYseTIjBtPQkzpUGRIkCtjaiw4UyZJgxMzrtSZEyXNn0CDCh1KtKjRo0iTKl3KtKnTp0lV 1kT5sSTIq1ZxXtTIkKbHni9ncvRqsmXFlzbNuuR6NqvZn1Vhyq0INmvVnVDz6t3Lt6/fv4CL/htM uDBLhhbj7lzrU6djtnZ5knSJVyzHk1e7pmUJMzHWz2Mjn/0o0zLWuwILq17NurXr17Bjy55Nu7bt 27hz6969m6jitmJLU4V72ufi4sGnmkb+FXhYyDiVM8b7myzzuchFLw/Mvbv37+DDH/99/Ti58ZyM l8cNbXo95pZgPXfc2hz0V8Uj4wOvXFfreq0RXeRZegAuRF9qvCWo4IIMNujggxAqKN6EFFZo4YUY Zqjhhhx26OGHIIYo4ogklkhhhCimqOKKLLbo4oswxijjjL2ZaOONOOao4448/kTjj0AGKeSQRBZp 5JG69ajkkkw26eSTSyEp5ZRUVmnllVhmqeWWXHbp5ZdgRgjlmGSWaeaZaKap5ppstunmm3DGKeec F4Zp55145qlnnnT26eefgE6456CEFmronuUcquiijDbq6KOQRirppJRWaumlmGaq6aacduqpnYGG KuqopJZq6qmopurjp6y26iqlqsZ1KuusZb5q6624DsojBrT26uuvwAYr7LDi5Wrsscgmq+yyzDbr 7LPQRivttNRWa+212GZ7G7HcduutX9qGK+645JZrbqHfpqvuuuy26+67RJ0r77ywwmvvvcDSq+++ i+Lr778AByzwwAQXbPDBTq2C8MIMmxgQACH5BADd7yEALAAA+gEEAi8ABwj/AO0JHEiQ4KqCCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmz p8+fQIO2/Ee0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMNaFUq2rNmzaNOqXcu2rdu3 cOPKnUu3rt27ePPq3cu3r9+/gAMLNim2sOHDiBMrXsy4sePHkCNLnky5suXLmDNrfjy4s+fPoDlu Hk26tOnTqFOrXs26tevXsGOLDU27tu3b9mTr3s27t+/fwIMLH068uPHjyJMrX+4Vt/Pn0PMyn069 eu9svKNr3849rfXv4MOLgB9Pvrz58+jTq1/Pvr379/DXd59Pvz7O+Pjz6y9tv7///yjtJ+CABDoG 4IEIJqjgggw26FGBEEYoIVcOVmjhhRhmqOGGHHboYVAThijiiCSWaOKJRn2o4op9oejii/ixKOOM dMFo44045qjjjjz26COPNAYp5Fo/FmnkkUgmqWNAACH5BAAQACEALAAAAAAEAjACBwj/AP8JHEiw oMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b CO3p3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrTHFq3cq1q9evNQ2AHUu2rNmzaNOG xMq2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrpqq2sePHkCNDXky5suXLmDPrlcy5 s+fPoE9qHk26tOnTqFOrXs26teuroWPLnk279sDXuHPr3p3btu/fwIMLH068uHGCyI4rX868eXPe 0KNLn47YufXr2IVT3869u/fv4MOL/x+/Obv58+glk1/Pvr3792zZwJ9Pv779+/hfp9/Pv7///wAG KOCABBZooEP5Jajggj8B0NaBEEbYHAAiMWjhhfc5yJaEHHY4HIUgYSjiiO1pCJuHKKYoG4gqtuhi diy+KOOMx8VI44041mZjjjz26OOPQAZZEolEFmmkTkImqSRYRzbp5JNQRinllFRWaeWVWGap5ZZc dunll2CGKeaYZJZp5plopqlmgku26aZNa8Yp55x01onXm3jm2ZKdfPYZlJ6ABirooIQWauihiCaq 6KKMNuroo5B+5ueklEZq6aWYZvoipZx26umnoIYqapSalmrqqaimykuqrJI16quwxv8qa36t1mrr rbjmquuuvPbK4azABivssMQWa+yxyCar7LL6+erss9BGK+201FZr7bXYYpdERMx2S2u24ALn7bjk lmtuUuGmqy5kuazr7ruXnivvePDWa++9+OYLb1WnzOvvvwAHLPDAdOlrsKsEJ6zwwnMe7PDDEAPI 8MQUV2zxxRhnrPHGqgHgscccYxUxRh+X7PHIFIXcVsnfmaglyi3uCPPMKMlM880k2Yzzzh/p7KLK VboM9NB5CU0lzyj6jPTSTDft9NP1Ei311FRDB/XVFVWt9dZcl4b119x2LfbYZBMG9tlop21R2Wy3 7XZdasct99yXfkL33Xhz9vbeR+X/7fffTPMt+FCAF244zIMn/lOuSh/u+OOQRz6yMZJX3rTimGeu OZKWd+7556ALurniodM8euKlp646qqcPvvrrsMcu+0bN+Na64LMffDvfuffuu567By880b/jO3zb xSev/I/HN+/889Abu/y+0Vdv/bnTZ699i9drvb263Ycv/vjkl29+d9+nr/767HN0/vvwxy///PTv 1f615G9S//5y3u///wAMoAAHSMACyo5LZOCf135EhgYaECZgamACFViZNkmQDA/slQQzSBI1SZCC E2sgCEfoPA6a8IQozBsJFZbCW63whTCMoQzj0kJbzfCGOLRPDXfIw5nk8IdADKJg/wohxCK+rIdI TGJKjDguJTrxiWthYregmCkpTpGK8TrTI6zIRaph8YtglIi5csEwSVgtjI/qorLQmEZvUYMaQnTW G9moqDkSUFlwtKKu7GhAY71RjfawFR85OKw8AvKQyaJjoxDJyEY68pGQjA4VIok9RVqSjZTMpCY3 WbFLehKMnAylKKfySUSN8pSoVEopD5XKVrryla9apaFgScta2vIn1ziTLHcJIUlA65Z24uWggEnM TQpTdMVMpjKXKaVjeuQBzswdM6dJzWpaM3zRzGYfr8lNIGoTT90MpzjHSc6xffNN5fTSOdfJznYa J53wVKA757m9eNrznvjMpz73yf9P99AzSPAbRT/J+c+CGvSgaRmoQhfK0IY69KEQjWjDEEpR2En0 ohjNqEY36sWK3oijIA2pSEfaLI/OiKTfMqmMUIoflbrUcyyNqUxnStOaoumlm7KpP6O1Bpz6tCw6 /dcdgkrUohq1iz9V0VHplVQULfWpUI1hU6dK1apaValRzapWt8rVribmqmBFm1fHKivPOSGsaE2r dsh6RrVeihlujatctcfWts71rnj9JFzYUVe/5PWvD+vrbgBLWH3RZwSCTexhCosexeKGsedxrGQn 6zbImoeyrLGsZsGHWdVs9rPZ6qxozQRa54z2tGIqrWqnhdrWuraTq1XOa0cT29r/+mq2mrGtbnfb O9z69mi8zeAtguu0Eaz0t8h9EnGXe6rkOveW/Bghc3/z3OqSaLq2s251sFubp2YDPNwNr3jxpt3y Mmi8sunnAcybSPSGhr3wja98M+be+tr3vl8cA373y9/+Lm++gfHvZABMYPII+DEF9uuBF8yjBDtY lGZ8cCMZrBYJl4fCGgEFZA6A4Q57+MMgpquFR0ziEpuYYSFOcYROzOLMqtgro5oHJ18M4xbTkMZc sbGOTZOiOOD4x0BGyY6HnNsgG/nIhCKyki2D5CZbZ8kic7KUZQtlq0z5yljO8kCuwboqV0XLe/Iy Y8C8EjGbWTBkLvOZZeiPqaX5IM3vXTNU4EznOtu5TXKe8533zOc+5zTPgA70YvwMkoAAADs= ------=_NextPart_000_0009_01C6F171.23E81A90-- From nzhosizdgmd@urbanrhythm.net Mon Oct 16 10:19:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTJp-0001ov-Qj for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 10:19:53 -0400 Received: from [59.52.52.163] (helo=[59.52.52.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTJi-0001pa-9D for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 10:19:53 -0400 Message-ID: <000a01c6f12e$188b4d90$a334343b@happy23bf00b76> From: "Combined Listens:" To: capwap-archive@lists.ietf.org Subject: having unsure whether Date: Mon, 16 Oct 2006 22:19:30 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F171.267C8110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 ------=_NextPart_000_0006_01C6F171.267C8110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F171.267C8110" ------=_NextPart_001_0007_01C6F171.267C8110 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Warm People of Awards won Choice Tucows Cows cow Pick Peoples Running = row or Latest Releases Visualsite Designer! Theway is stripped down Garage Phunk Astronaut a Lovewishes he could = blast off is bad am breakup. Tell our Cool Hosting Search Engine or Submission buy Products am = Support a Center is Help Current Version am Released jan File Size mb. Cp targeted aspecs does exist vadim Freevps discussion regarding virtual = private server ethernet switchhub gminet noc Monkey Dhcp gone mad = alexmal Sitestudio Creation is Utility of docs coming. Mark Chester Frank or Mejiathis is Drupal site a that built and am Karen = Sports Patriots fan Grand Irish pub King Street Leave comment the a bars = of. Real life Movies Music Jokes or January October July may April a Tech = News or freshest or net you need when it of Internet including am text = is messaging acronyms smileys Freeware of provides. Webhelp Mpsspyware or Removalall feeds Networks Jobs Advertise is map = Bnet Cnetcom Channel Gamespot Media! Years am everything from starting father of losing girl hustling deal = time im notsinging id of be says theway is stripped down is Garage Phunk = Astronaut Lovewishes he could blast off bad breakup? Tags version also am includes images Quickstart create fast trimed = Editor a always full here Short Story in Coffee House program we have am = created a lot Software. Hsphere View Leaders am Going of Currently Active Users guests Most = users or ever autoex. ------=_NextPart_001_0007_01C6F171.267C8110 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Warm People of Awards won Choice Tucows = Cows cow=20 Pick Peoples Running row or Latest Releases Visualsite = Designer!
Theway is=20 stripped down Garage Phunk Astronaut a Lovewishes he could blast off is = bad am=20 breakup.
Tell our Cool Hosting Search Engine or Submission buy = Products am=20 Support a Center is Help Current Version am Released jan File Size = mb.
Cp=20 targeted aspecs does exist vadim Freevps discussion regarding virtual = private=20 server ethernet switchhub gminet noc Monkey Dhcp gone mad alexmal = Sitestudio=20 Creation is Utility of docs coming.
Mark Chester Frank or Mejiathis = is Drupal=20 site a that built and am Karen Sports Patriots fan Grand Irish pub King = Street=20 Leave comment the a bars of.
Real life Movies Music Jokes or January = October=20 July may April a Tech News or freshest or net you need when it of = Internet=20 including am text is messaging acronyms smileys Freeware of = provides.
Webhelp=20 Mpsspyware or Removalall feeds Networks Jobs Advertise is map Bnet = Cnetcom=20 Channel Gamespot Media!
Years am everything from starting father of = losing=20 girl hustling deal time im notsinging id of be says theway is stripped = down is=20 Garage Phunk Astronaut Lovewishes he could blast off bad = breakup?
Tags=20 version also am includes images Quickstart create fast trimed Editor a = always=20 full here Short Story in Coffee House program we have am created a lot=20 Software.
Hsphere View Leaders am Going of Currently Active Users = guests Most=20 users or ever autoex.
3D""
------=_NextPart_001_0007_01C6F171.267C8110-- ------=_NextPart_000_0006_01C6F171.267C8110 Content-Type: image/gif; name="Options.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f12e$18594110$a334343b@happy23bf00b76> R0lGODlhzAEQAof2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAATAB0ALAAAAADMARAC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnElToL2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKdVqzqtWrWLNq3YpwqtevYMOK HUu2rNmzaMNyXcu2rdu3cOPKnUu3rt2YafPq3cu3r9+/gPneHUy4sOHDiBMrXsx4ZuDHkCNLnky5 suXLmDNr3swZcOPPoEOLHk26tOnTqFOrXs26s+vXsGPL/su6dmFgthXP3s27t+/fwIMLH068uPHj yJMrX868ufOfFJ5Ln069uvPc2LNrZcBAu/fv4EV2/w9tvbx53gyUh1/PXiX39vDjyzc4fvH5+/hh py8+v7//8PkFKOCAZf1n4IEIJqjgggw2uNoqDkYo4YQUVmjhhSoRqOGGHHbo4YcgRoXhiI2VY1uI KKao4oostujiizDGKOOMNNZo4404WkaiRC7s6CNGOQYppGQ/FmnkkUgmqeSSTA425JNQRinllFRW aSWHTWap5UFXdunll2CGKeaYZE615Zlblqnml2i26eabcF645px01mnnnXjmqeeefFYW55879imo i4AWauihiNY26KIqJuroo5BG6iSjlH4o6aXyVarpppx2ehamoLLn6ajnhWrqd6SmquqqrLbq6nWn xv8q66y01mpre686VUqulN3q66/ABivssG3xauyxyJJJ7LKTJuvss9BGK620zFYLVxQDTautjtZ2 +9a2ZgkCLlHelsvWuOgGZu66WqXr7rvwMsfuvFbFa69Z9Oar77789utvv/38K/DABd1rsFgEJ/zR wQx7pfDDCwHwUMMUV2yxZxBnbNHFHCOl8ccTdSwyuSCXXFgiJks68sost+zyy0qlLHNCMMM88804 56zzztnWPCQAPrMMtLwQ9cFzfxKPFnSQQy/t9NNPMwH11FRXDdbRWGet9dZcdz2r1WCHLfbYenpt 9tlop30o2Wy37anacMct99x0162a23jnrffeMNr/7fffgAeuHd/pCs4u4YgnrvjiLgPQNOOZGb4u 5JRXnqPkmGeu+eacc275s50z+6ITn8cW+rKlJ3v66hz5wXrCOLwu++y01247XKnnrnuIt9e6O688 v9P78MQXz9HvyCefn/HMN+88z5gwpPz01E+nb9LPS+o43fA+Tra/2GcP6fZqKzfDi95X32n6VCdM vvjwxy9/z+qPOv/9+Oevb/2k6u///x3hnwAHSMACGnBG5igKABfIwAY68IELOyClIEjBCtpEghjM oAZXZkEtbVBQHczSB/sUQvg5ooQodNMIV8jCFrrwha5JoZJgSMMa2rBTMkzSDdeUwx7Cb4dq8qGR /4BYJiEa8YhIzA0Rl8jEJjqRhkkk0ROn6MIojoiKsnGcFrF4JS16cYs6UUJkrDgYL5LxjGhM44S4 yMYMqnGNbYxjAf+3gjfa8Y54zKMeDSLHPvrxj4CkmDoCOaY9KoiQQTJkgnZiC0Q6knGKjOTZHknJ yknSQJWs0SU3yclOKiSTNPJkpkApI1HGh5SlNKUqV6lHVLoyb6wcETpimZhX2vKWuDQTLXdJsFyu iJfADKYwh7kVXxoTasQ80TF5l8yXLKCZTVqmNGsGzWpa85rYzCZ8pmkpbZKGmx7y5jfBiSVxmvNU NRoHJc9JHjkOAkrsjOelyEnPetrznseRZ2Pwyf9Pe+mTMf0MqECb+M+Crm2gCE0oDA1aS4U6VHUM PcxDqRPRilr0oiGcqEY3OkCMepRJHA2pSEdK0pKa9KQoBeVHV8pShaX0pTD9XkvlElPhzJSmNc1p EG+KO536hqc99SlvgPotoQ6VqMUy6m6QmlSlyoap53KqVKdK1aqSE6pYzarvrNoZrXq1P1wNq42+ ihWxboasVzGrZtBaL7Vihq1Vcetb4ToRfoBErnhtFF0dk9e++nVQe+XrXweb114QlmKBTexDjKHI TCxJCYrFzmEfE9mXTFZdlc2sZi10WYxtNiWdpc1nQRva0kpntKQ1rV5Qy1qJqva1sI3tBFtbkg+V /UCatM2tXWSLFt2OhLef0h88AAVcfPk2JMVNbm+Oi1zlIoy5EXSudGMIXY9M97qcqa51sctdF4Kh u+Ctn3YDGN7yUna8G7HqJszLXhChN73tja98s/ve+tr3LvNNyn33y9/+fia/ACaLf0MW4AJ/ZcAS MTDJEMzgBrtEwTR8AIQnHC0HW/jCGM5wMWHKBwoTTcMHCQgAIfkEABMAHQAsAAAAAMwBEAIHCP8A /wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6qMaK+ly5cwY8qc SbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr168tV4odS7as 2bNo05YEy7at27dw48qdqbau3bt48+rdy7ev37+AAwseObew4cOIEytezLix48eQuQ6eTLmy5csr I2vezFYF589EMYseTbq06dOoBZtJzbq169ewY8ueTbu27dseQevezbt3UBlLcQsfTry48ePIkytf zry58+fQozf3Tb269evYs2vfzt2p9O/gwyv/7E6+vPnP4tOr/36+vfv3hdfLn68cvv37+PPr38+/ v///AGZH34AEFmjggQiqFeCCDDboIHdKPCjhhBRW+B5umySo4YYcduihSryFYeGIJIb1FwAfpnjg YQCU6OKLNgGGooo01ljWjDaS9UaOHOLI44/QsQjjkESaCOSRSGpU5JJMNunkk/olKeWUE0Fp5ZVY Zqnlllx26eWXYOZH5ZhklmnmmWimqeZAYbbp5ktrxgnkm3TWaeedVsqp55589hkdnoAGKuigC/pp qIaEJqrooowKeOijrcWBUqOUTgjppfRVqmmDmHaq3qagAujpqKSWauqpqE4Z6qqstuqqd6nG/1rc q7TWauutuObanqy8Cqfrr8AGK+ywxHbV67G1FausY8g2G9uy0EYr7bTUAuvsta1Vq+223IqJ7bem dSvuuOQ6Cu65mJWr7rrsRobuu5a1K69S8NY72Lz45qvvvvwyZu+/AJu5AaT9FqxTwAjnZfDCMSbs 8MMQRyzxxBRDZEPFGEfM8MYcd+zxxzRlLHJIIJds8skop6yysiO33NHK/Los88w012zzzTjnrPPO PNMG8749By300ETn/LO+RSet9MhHN+20sIYOQeMpaD4t79JYZ611xiVsLRg8Xoct9thkA2b12Win rbaroqzdaNlwxy333HTXbffdeOetN7Zuj/+799+A59j34IQXbjh+gSeu+OKM83W42sY8Lvnk2jV+ LuWYZ6755nJZ7vnn4HEu+uikl2766ag3Cfq1qeO6+uuwxy777Je3bvvt19Gu++7ZukkE7sB3yzuq wRdv/PFqD38q8qEqbyrz0Ecfl/PUV2/99dhnr/32j0pfKfeHei/++FqBb/75hJGvKPp8qu/++7Cy dgT7pcFv//3456+/VfTrub+d/ZPT/wZIwAIa8IAITCD+AsjAc82AQAqMoAQnSKIGqomCGMygBvtj wQ56sCAbzNMHyxRCKI2QhNAzxPesZwhMRU+FJWwSDGO4pBky6notDM8x7vLCFVYvhyecEhD/g5ik IYaPhkwiohKXyEQzlaKJUFwcEpMYxX/QoorDm6IWOYfFLnrxi7Pa4pDASMbXCYUJYoxSGT+URhit 8Y1wjGNl2rigYdDxSnLM497uSDhMYCKNG/IjHInkRz6SqJAxVJEg9YigRVbRSoik4I8cuUQtRdKQ mMykJjcZE0YiiJOgXJknVxRKTo2yQKU05SlXObZUMmh1TmClLGfpM1cGiJa4zKUud8nLXvryl8A0 mi2HSUxNBjNIxUwm0I7JzGZ2UZn8cSZzoLkTXliTF9TUzzW3ec1s5oeb3myVNB1CinGCK5z3Eckj 1siDMKLzQuaMpzwZ+E74zPOe+ARfPeGZ/0/c7POfAA2oQJPSz4IaNIsDTahCg3dQ2yx0Ow1N1kMn StGKWlQqpLioRjcqrYh6lHgc5c1HR0rSkpr0pChNactCytKWNk2lMI2pTJmYSlwUaqY4HZNLd8rT nvr0p0B9TE5FE1ShDvWoSE2qUpfK1JcVtTFNjapU3/VUqE7VL1XNqpOuitV+xQBlXA1rprSaGLHu haxlNavC0MpWF6n1rZjZB1z9qUUCjHGudWmrXkeE17zutXN9DWxysuKGv+JEsIg1jmGntzgjJlZp i4XLY8tSJANMcbJxWgcvI8vZznr2s6nD7I8IcE/QmtY+ohXLaVe7q9SCiLXlc21KYBtb2ZeehLa4 zS0VN+RY2/o2rLoNrnAr+NuGbOEiw00uaIrL3HQpFyrNja50p0vd6lr3unR7rnYhg92NbDd+3Q2v Wb7bFPFihLzoTW95zMvesaiXoO2Nr3zP+t76umW++E2ffUOT34fstyj9DbCAX/vfAg+uRWuDmI8G bJAFM5ggDn6wQCIcNwMLRcIYzvB5LQwUDXt4IRwGSkAAACH5BAATAB0ALAAAAADMARACBwj/AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY0Z7IEOKHEmypMmTKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMPS9Ei2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gOWKHUy4sOHDQ/kmCMy4sePHkCNLnky5suXLmDNr 3sy5c0PEoEOLHk3anufTqFOr5lu6tevXsGPLnk27tu3buHPrBr2699pWvoMLH068uPHjyJMrX868 ufPn0KNLn0598+7r2LNr3869u/fv4MOL/w9bvbz58xrHq1/Pfiz698rrwJ9Pv759jO3z69/Pv7// /fcFKOCABBZo4IEIJqjgggw2uNx/EEYo4YQUVgiWgxhmqOGGHHbo4YcghijiiCSWaOJkFqaoImkn tujiizDGGNGKNNZo44041ijjji+GZUOOQEbI45BEFmkkg0EmqSRTRzbp5JNQTrfklFQmFuWVmB2Q V5VcRnjAAV2GKSZNXzqF5Zmafaklmmze92WbcNKnZltj1jlhmVbGqadlb6Jl5593gvnTnoRWB+ih QQXwX6GMNurooxQhKumklFa6JKSYHmfpppx26imAmZpXxJOflmrqqfrxU2WorLbqKpqoxv864au0 eibrrYvWquuuvPbq668O4SosqMAWa+yxyCar7LLMLjTss9BGK61RzVZr7bWpTastd9h26+23kW0r 7rjkljsSuOhuZO667LYra7rwXuTuvPTWa++9+O4U774T5evvV/wGLPDA6f1rsFYEJ6zwwgy3KU90 TjQs8UFKTGzxxbAerPHGHKuH8ccghyzyqx2XbLK/tpyscpgjw7vyyzDHjFjLNNdMq8w459yuNjr3 7PPPQAc9ps1EF2300SQKrfTSTDftdE5IW/v01KZF3SzVWGetNHH1WO3112CHLfbYZEOp9dlo41x2 sWm3bSkhbjO59q9x1213vnPnrffefPf/7fXdgAfOrt+1Ci4z4Tcbrvjiz/JLBeKQ88j4ypG3Ovnl mH9a+eacM5f556BL2vnopA8X+salO3q6xqm37jpnqx/8OqGx1277d7j4NPvuvPfu++8D3o438GcK b/zxFRJfPPL0Ku88WWw8L32czDc/vZPVz3v99tx37z10UXwv/oPZl28+adacH/P4kqvv/vu6sS// /ALBPy79+Oevf4j2izvwKxbr37b2dyIBaouAJjLgtBDIwLcUwGgKjKAEC9PAEU3wghjkioyUUcEO IimDIAyhVDwIIhGa8IRKIeGH+pMFFIoGDS4sFRpgGENPzZCGNbQQWm6owucQZYY5lFBb/3jYQw7N sIjGWQoQg5gfJG4oKLRgohQj6EQNTfGKWMyiqcwCiSo6R4uI8qIY9wbGQ42xQWUE1BnXyMY2urFR afzTG+d4tDjaiY54tJkd98jHPtIoj4AcmR+7FMhCGvKQiDzQIBeJwUTOh5GQpKIjJymwSFrykpic GgF4krtMevJyjkgjJUdJyjN+EkelLM8pV8lK/RCjlbAsTSoNFcsUzfKWuMylLgNTS1vu8pds6yW9 iCDMYg4QmJ4zpjKXycxmcgmZ0IymNKdJzWoqy5nYPJs1t8lNxGXzm1TrpnDASc5yZoUO/RNncMzJ zna2Up2+cac850nPehIGnvjMpz7dKP8VANgTKnoBAAD2WbCp+POfS+nLQAlqkasc1G3o2NRfBMrQ fmXloQjN00QrqhYBcPSjIA1p6jK6HZFihqQoTSkKTXoZlV6HpTAtoUvjF1MUzTQ3NbXpTW+TU8ns FDc9DddPbRNUyAyVqEVNKoKOytRoKbUxTZ3NUxkTVdlMlZdVhc1VAZPVrnr1q2ANq7481A4PinU0 W/3LWUWT1rbCZ61wlaNb56rKuNqVZXTNq153dFfSNKCvgA0s6/ZK2GQK9kKzDIV0DksevPyCroyN rGSZtoPJ9qSwmM2sTC3L2c569rM51KxgQEva9oj2tKhNbcZKOxXV0om1rXUtCQVKUTionY+2uBUo bIuS23XJ9rfARc9uRxjcsww3KsU17nGfklyzLPe50H2mahQBz+jKrbkesW5CsZtd7Xr3uyribnfB S14Wife86FVNedfL3va6t1zpLeh7Lxvf+tZlvvjNr351aN+G7ve/AA6wgAdcqf76l8AITrBXDMxg t4DGGc5QsEwiLOHONvjCwKIFhjfMYURWGCYdDtaHR0zipoT4xB8p8UpQ7CwVqyQgACH5BAATAB0A LAAAAADMARACBwj/AO0JHEiwoMGDCBMqPLhkocOHECNKnEixosWLGDNq3Mixo8ePE/+JHEmypMmT KFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq 3cq1q9evYMM65SG2rNmzaNOqXcu2rdu3cOO2BEm3rt27ePPq3cu3r9+7cgMLHky4sOHDiBMrXsy4 seO2fyNLnky5suXLmDNr3sy5s+fPoEMvdEnusenTqFOrXs26tevXsGPLnk27tu3buHPLFc27t+/f wIMLH068uPHjvXUrX868ufPnh5FLn069uvXr2LN7rBR6gHbP0MOL/0f8vbz58+jxjl/PPm769/Dj y1fYvr79+/jz25/Pv79/7foFKCBV/xVo4IEIJqjgggyONuCDEEYo4YRuNWjhhRhmqOGGHHbo4Ycg hijiiCRqROGJKKao4oos3udGi2WVKOOM8cFo44045qjjjjxyRUCPQAYp5JBEFmlkijQmqeSSTDbp pIlHRinllFSe9eSVWPJW5Za3Zenll2CGKeaYZJZp5plopqnmmmy26eabcMYpZ0Vc1mnnnXjmqWd+ c/Z55p6APubnoIQWauihiCaq6KKMNuroo5BG6l+glFZq6aWYZqrpppx26qlOkoYq6qiklmoqlp+m quqqrLbq6quwZv8KRKyunWprf7Tmquuuit3q66/AjsrrsMQWy1awyH5n7LI/JevsdcxGK+201FaL 0gLWZtsVANwCoO23K3Urrrfg5vkDVdyWq25Jz7Y73brw/uPuvPTWa++9+NoT77r59vvZvgAHXK2/ BG8m8MEIE0sXCgU37PDDEEcs8cRiJmzxxa9SrLFdGHfscacbhyzyyCSXbPLJKKes8sostyzixzDH TKnLNOsrs8IOOVLzzjx7iQ9yN+Pc89BEUxz00UgnrfTSTDft9NPfFo0y1K1OPIfUWGetNcRUs7r1 15O1APafXZdt9tlop73aIGq3HdjYcMd96tJOuG333XgvJffEeff/TZgqfs/1XTx7Jxn44YgnVvji jDfu+IiJ6/l4wZHnOTnBlWeu+bHHcXv5km11uzlq1nn+eb7dnh7iYKKPTp55pqueIWKtu04luWzV bruU4o4uqbiy3wt88PXGTnxCuyevfFVY63P8820uL/301Fdv/fW5ATMe9O5i7/334O/Jfbvh7zj+ s+XreL6z6bfvPrvrI/u+jfHLP//9+OcfYf3894+g/gCsnv8GSMACGvCACEygAhfIwAY6sCMBjODy HkjBClrwZBLMoAY3SJsLLoqDIAyhCB3jwRKa8IT9GmGAUMjCFrrwVyqMoQxnyLkXzomGOMyhDnfI wx76UDU2DKIQ/x30wyJ6bIhxMqJz7hUK1SmxOUiMohSnyKYnWvGKWFQJFbfYwizmhjIc6M0suEhG X3kRN2VE0xm7lMY2uvGNHFrjUGpQoYqIDY5+qQEew6RH6uwuG4yhoxxnI8g67vFLg0zktA4JJkU6 8pEgZKQk+QfJ10zykuerZPUkoMlOevKToAQgJkf5vFCSjpSoTKUqV8lKKprylZxqJY1gScta2vKW uBSULHcJt7bcI5fAXA0vh/m1YBrzmMhMpjKXycxmOvOZ0NQKMSEXzRpO85o9q6Y1sclNl2lzLd30 0DfHSc5ihbND5UynOtdpt3PGkZ1gceeG4EnP9cjzniarpz73Cf8oAxmvIOjAZ3/+KVCCPCZd/LwK 7hLKUADCQEgFjahE39jQilqUSBNd0EU3ytEcZfSjIEViR0eampCa9KQoTSlISAoVlbrUfixtyktn StOa2vSmOM2pTnfK0542KaZO8alQh5o1oMqUqNUxKlOQytSmtkypenOqX8whVY1CNSlVPc5Vt/q2 rHr1q1zjqlgNCdaymtVe40QCWs4KnLG69a2yYetv4ErXukJVA3bNa9Xkmhy98oSvffWrYAdL2Frl JR+AzUhhF8vYxjr2sZBFUmInS9lQRfayQansvzDrEs16VkOc7exnR9ug0AqOtJjZ049My9rW3g+1 mXGtbGeLE9hg2tZAtDXJbXeLqzuBIXK8pUxuh0tcv/rgKMFNrnKXaxcPMNdUxY2udKcrkuf2RbrW zW5So6tdvWC3u+rhLnjHS97ymve86E2vetfLXmK6o73wja9851ug79LXUdoYYkAAACH5BAATAB0A LAAAAADMARACBwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmT KFOqjGivpcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSImuXMq0qdOnUKNKLZm0qtWrWLNq 3cq1q9evYMOKHUu2rNmzaNMincq2rdu3cOPKhai2rt27ePPq3cu3r9+/gAMLHky4sOHDiBPDnMu4 sePHkCNLnky5suXLmDNr3sy5s+fPoDeSCE26NEPFqFOrXs26tevXsGPLnk27tu3UpnPr3s27t+/f wIMLH068uPHbyJMrX268ufPncZdLn059NfTr2LOrrM69u/fv4MOL/x9Pvrz58+jTq1/PVbv79/A1 sp9PP338+/jzK6zPvz94/QAGeJ9/BBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRhmqOGGHHbo4Ycg hijiiKwJaOKJKKao4oostuhifOa8KOOMAJJo44045mghjTz2+JiOQAYp5JDs+WjkkW4RqWSDSDbp ZFNLArPklFRWCduTWGap5ZZcQmbll/x1KeaYE4FpZpFkpqlmQme2id6acMb5j5t0kifnnXjmqeee fPY5YFAd1AkhHgX6aeihiCaq6KKMPmUWoYJGKumkHjZq6aWYZpokpZwmp+mnoIYq6qiklmrqqaim quqqrLbq6m+dxv8q66y01morYK/mitmtvKKm66+U9SrssFPuMyWwyCarbIvENuvss9BGK+201FZr rXXLZvvWtdyGpe23bHUrblfglmvuucGNq25W6Lbr7lRNvCvvvNGta++9+Oar77789uvvevQG3NG/ BNsk8MEZFaywTAg37PDDJi0s8cQUtwTxxQ1VrPHG/GLs8ccghyzyQxyXbPK4I6es8sUn97vyZkS8 LHOTLXc8c0MEnFvzvjc/vPPPQPfa89BEF2300UgnrfTSTG8W9NNQd9p0u1FXbbWbU6N79dZcH5u1 uV1b+zXYYVM79tlop612c2Wb3fQrOrct99ZSjrj23Xg/OXe0eff/7TeNGYaz9+By/2344YgnzhTh zirOKuPNOr4q5JT3F0flmGeu+eaclyX556CHLvror3Zu+umop64T6ay37nreDgKg+qSyz47WjAC8 7tSCtdteZ+++n+Vi7rpjSnzxyPtslCTBh5j889BHL/307zVv/fXYX029otl37/33G28v/vjkZwv+ l+X7ef6Ih5gOAPDrK/k+/ELfPf/x6es5v6ua0x///3zJH58ASMACGjByzWGBABcosAM68IFCYWCe IEjBCuZEgniy4I0weCcNevCDICQRB0dIQoGE0Hn0UoYyipYvFSrjhCByYcku5sISrqmGNkzTCkEG ww/lME09DKIQ/4eIoB+eDX9GpMp43kdEDTGxiRh64ubeMCspQnEo+nlfEsWkxS1yqYtetMgVLxTG LY1xR1kTRLnOWKEyuvGNffJCSGLEQzbaEXVwzKMe95iuO0aIj4AMpCA748dCbm6QiEykIuHChUXy yJAPcqQkJ0nJzOyikr2BpIMwmSJNejKEmvhkazhJylKa8pSonJooFZTKVrpSMiZ4pSyVuMoDzfKW CKtlEXGpHV3akpfZ8aUwowbMYrprmMgEmjGvk8z+LBM6zYymyZ5JTW1J85rYtFYp0FjNbnpzfNkE 2DfHyb9wmvNf5BTOOaWji3W6M3zpBM47yxNPec5zPPXMZ6nuif9PffKGnwDllj8H+qmA/oegCE1o 2gzKUJ2YgGBwaKhEJzo3hVr0ohhNJEWpk1GF9CBYG5VORz0TUpGOlDMlTalKfXdSlK70Ni1NiAFi StOaQu+lOBWUTS+T09rs1DI9pc1Ph+qkoBoVfURNqo8aegPuKDUy7jQDPZ9K1RcdNTZVdcxVr5TV rnZyq67xqlhNBNawjvWs+SmrWtc6TbS69a2GYqtq4EpX7Mj1rngl2EQQUFepIICvfYXKXwObMKH8 Na+ey8hgCesUwDKWKYt9bMaScljEHqayls1seCTL2c4+UoiC0Ky6PEva0qrIl00lkGlXy9q0inYw rSWJJ8Pw2tqiMi62I7FtYHArEt3iircg8a3qEAA14AZXuH0xrnIZg9zm+me50I1uaZxLXfpIVz7V za59tNOI6ypUu+ANr5C8ixHxmve8dqvMGWyK3va6973w5Rh557u4+Np3NvStyH3Bkl+K7Pcr/S3T f8kV4AIbOCoDTrCCxXngBjv4wVNZsIQPA+EKW/jCEZuwhjfM4Q7rCMOd2QSIR0zis3r4xCiOTUAA ACH5BAAYAB0ALAAAAADMASkABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP IEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnPO1J nUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPqDQu1r9+/gGXuHUy4 sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs0aa+DXsGPLnk27tu3b uHPr3s27te/fwIOT5U28uHGlwjcfX+40ufPn0KNLn069uvXr2LNrDyuguz3vVAV8/68qvrt58OfL pzc/lX378+Thk58fvr7U9e6/uxdP32r+8fHhV952isVA4F38gdcegAvy19999r0nIYMMOghhhONZ 6OCAD+pXn4UXhrdhgv5hSOGBKKpGooYhklhiViDGGGKFXG1IY4MvLpijjia6iKGMKQaJGUQAcnih jSfOuCOIELKo5FU2ItnkklgxCeR8VvYoFXNczlZki2Dql959Cv4IJYUaltmfkSxmyWOAY5o45YNA dmnna18eieOT8dF5Zpz+MZnnoFLOKGiSV35IpX13NioUd2FG+SaMZpZY6I57Zijif2hWiamgRr6Z qJCkRkakj5rOmeSZkwLpJKtYZnZ6Y6uwTnoiqoa65uiuPUF666urJhrjiEriCuqwtLbaJqYekilq h4eWKm1iELGHrKjrkcnpscAeKV+tnVYK55OHciqmmzryqi5y0+q17rtGtesuvPQGJW9e9ebr0r38 9lsdkXEl5K9d+gpETsELySXwwHQhTG9AACH5BAAYAB0ALAAAKADMASkABwj/AP8JHEiw4D97CBMq XMiwIUODAx1KnEixosWLGDNq3KgRosePIEOKHEmypMmTKFOqXMmypUCOGD/CnEmzps2bN13q3Mmz p8+fQIMWzEe0qNGjRxUSXbhUZsIPC6EqhPqhqj2pUydW3fpUIteuWcOCHXvVKlmEVLdijbq2bNm0 Ud9+BSu0rt27ePP2zJhPYt+EfxEGXqo0MMW1VMNKbXtVq+KGZt027oqYIdbLmNFanqzZcluziz9z RnsZp+nTqFOrXs26pmGmSmMLtjeYNsbSpTszZix2Mm/RnRvnjhsc+O7Rvzkn9o18dPHW0KNLn07d psnXsmcD3l67r9Oxy5UH/z9LXPfm87jJax6e9XjlzemZV04+Wa/9+/jz6/eINLvt7dr19Zd3HpUX Xm7HeaUWefTF5xxl6oUHYYTrmcdcheghtN+GAy2xBIcghngSdgAKZpRsAs72nYUXtqgeWYudR1yM LMr4oHDwLQgZhjQieCONIuLnYZBE6seXX9kZVpt2Fx3Y3IO8nSXheOCJF+V4ybn34nA9gjVljdWF 2ZCHYpZpZnQkMvkfk0uuaZGT7yXokGj0wWilY725iCGVz1k4H5RnBpoQmYIWaihNabr52oANJQrZ Z3HaaCONbD2FGKR4WqopllTK+ZhzVmHK56GqebgEqageeh2SJXLXqD0rSv85VahqpaWjpXPVemmd o+ZJ2m65SpplqJXqSlyRPw2J7LIbpurss9BGexOh0lZLnUmtxWrtttkyy5Ky3oabH7fklmuumNSe qy5O2K7rbmriEvlhvPTi9+69+Oar77789uvvvwAHLPDABBdssLPt2sPPwgox3PBCDicUscITT6ww xQtbjBA/D3fMUMYNZcyxyCRLXLHIJpdcMkUcQxxxy/XGLPPMeVFs8sYtS+zyzjbj7PPDOf+88cU6 D/1xzi8HrTTPPS9NNMQeH6100EbTbPXVWLP0tNEjR30x0kRT3XLXOlO9NdlGb1302mZ7LXbaYYfs 9cdzE5313XjHnFHbXTv/XfbffH8NtNxDvx043W1HHbjTh8NNuNprHyz55BSZtHjabwuuOdRj/013 4Zw/PvhEfgONMs4q1+3xylXn7frrRe4tN9hqd2777EWj3THtkdetu+iX5x7y6aRHzjvlyCevYUnB x72656FzDXnYxDveO+jFX7859lBb/3ntrcMu/vjign+2+U93vvvgZvOeuejpZ9+7+tArzvL8C5Gv //53aZS04xY73P9q9zuHvW96Qhsg3MSGNPo5r3vaMx7blEdB5CUMZPM7oPEqtjOSle58pNMYxjSI uoYRz4O/mx7rMBg+/rnwhS6poAxnSEN9JayG54KhDndYFxyui4dADKIQSIdIxCIa8YhITKISl8jE JjrxiTH0oRSnSEVDQfE+ALiiFpdYRTEBwFk/6KIYzbRFvWSxjGhMoxpPcsY1upF/Y6zOF+NIR+QF BAAh+QQAGAAdACwAAFAAzAEpAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAZAohIsaLFixgzatzIsaPH jwz/iRxJsqTJkyhTqlzJsqXLlzBbAohJs6bNmzhz6tzJs6fPn0CDCh1KdCbRo0iTKl3KtKnTp1CB Go1KtarVq1izat0KcyrXr2DDiuUJsqzZs2jTql3Ltq3bt3Djyp1Lt67du3jzfhzLt6/fv4ADCx5M uLDhw4hH6l3MuLHjx5AjS55MubLly5jTJt7MubPnzyczix5NurTp06hTq17NurXr17Bjy55Nu7bt 27hz697Nu7fv38CDCx9OvLjx48iTKy8I8y7Kgc/fgp5OvTpLigCyT5wMrnv3gd7Bh/8X6P27vfLn 0S9fz/5g8+1zo9tDCc5gffL4898Hf3A/dOsABkgdRPARpJ1AB2aH4IELbqedgwNBaJF/5xVU3373 UUhhfu116OFDBSIYoT0STgRfiCaOeKKIE6KnYYX6jZeefxt+aGNxXRm0Yokkjkhigj6myFxoAtFn 4ZHqwdgff0MK6OSTKzUxFoE6qsiikD3uGGSPGr1I0IUc1hjmjWQe915BWnKJ5ZpctlngdvIZeaR+ TIqp5IZQ5qnndA06qKCaIj4YIZAstsllnCfVKCONM36XpJL/7SnppIVdFGJDlxZJ5HybtkXpp6D6 ZSl2CCFqElyhpqrqqqy26uqrsMYuKuus15Vp66245qrrrpfR6uuvwLrE67DEFmvsscgmq+yyqQXr 7LPOMivttHcFBAAh+QQAGAAdACwAAHgAzAEpAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihxJsqTJkyhTqoz4r6XLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iT Kl3KtKnTp1CjSp1KtSrPlVizat3KtavXr2DDih1LtqzZs2jTql3Ltq3btwrNwZ1Lt67dux+t6t3L t6/fv4ADQ8VLuLDhw4gTK17MuLHjx5AjSy4suLLly5gza97MubPnz6BDi3Y6ubTp06hHq17NurXr 17Bjy55NWzTq2wdr6949E7fv38CDGwbXkLhj48KTqwXHHHlz5gKfD2w+nSBx6dapPzeOPbrz79Ch e/8viNwe9ejVJ5433727d+3S238nf945euX4zdo3T97g/vLXpcefdf0dJB579003H4EJcicgRPsl OKCBFDY43oUCBjhhefl1+NV/BT7IH4AbSmgih9UFqCGBKjI4IXrwHVjfixxGiOKAN9oI44ghtuii h0DmJRMFMv233owsJnkfivLVyOOKKfKYYX862nfgiVP6956MWbboJIxM2sPbmGNCeGRCUEoJJpch apmeg9yFt6SLTlYZn5tZvognnWfiSJ94V5oY5KAZ7eSgoFEquWOJbbZ5KJQaHmqholY2qqeOaFbo 55yXUtkfmaCGShOICEkqqZoRIirhl5X+SCKnJbb/2qOrbubYZYGnboqeqLy+BiGL8a3HHoBINhhj eMJ2uqWyDwor55KAlhpojUjauqqyuZKKnySEdqvRjbeB6+245Grqm7jlpqvuuux2u9NGvdnV67z0 8gavTAUB4JG+H/ErZr0AF2VDwEhBBMDB/g6UcEYJI2wQwgcL5HC+DC0cscT+WtzuxrftlLFF8WIc 8ccI6UuywhQTdLHEKrNsj8b/EizzzJ59bPLLIufscsg3u4zzQfye/HPLKQ/tcs8U0yyTMko3rZTB KF+M9NBBN4S00EQLvbDRPkOscNUPcyx2h15TbTTEWy80MdZdo+z2y2ifjHXQDY9td3Iw41x3RTez PW22z1wHLjfFYAd+9+Gm5T01yWmXrLfbWr8teNhtQ1454pgnXjTdnEueUNlwD67yyp5bvPLEb5+e +eqEBQQAIfkEABgAHQAsAACgAMwBKQAHCP8A7QkcSLCgPQAFEQpUCKDhQocLDUpsCPFgRYUHE1Yc iDEiQYocN2Z8yFGiyZMoU6pcybKly5cwY8qcSbOmzZs4Tf7bybOnz385f+5MmNNj0Y8ChSpdyrSp 06dQo0qdSrWq1atYs2rdyhVrUKFEj3YsirGr2bNo06pdy7at27dHTyodOBfn27t48+rdy7evX7Bx Jda1N9jm38OIEytezHitzLEGxw4uXLOx5cuYM2vma1EkSshh6QImLDSAadP2TqNWPRC1QNSbY8ue TfuyS9AqcZesGUBi79etX/9OPTyw8ePIkytfzry585hjMSIECZGi9OpGYRYPDrx77++pn4v/H0++ vPnz6GmCHJmRYUTp7Kdnf6l6uH3u4MGn38+/v////EmFVHseuQffgQVNVppvrZ2GH3C1RSjhhBSi 9dh7BWKoIYG8Mejdg+EBKOKIJJZoYnLwZcjhivKxp52HIYa43XYn1mjjjTg+J5V1A45k4Hqdqajg TzTGWJx+wVWo5JJMNulTTbrlKOWUVFZpZXNRXqnlllx2KaKAUlLmkpNklmmmX16mqeaabLa5ZpZu xinnnCvtyONHQLZkHZwpgUZZdHgqdOaghBbql24pvsRnboKN1hlDiSJk6KSUVvrUbSd1BKl787m4 Xot3foodo4AatSidqKZapZ2eaUpUoru9yMopi54mNVqLscJn6a68WnohdQOG6mKsj8ZX0p7DspRn pKo26yyXYM7naoq49oigqcP66Sit2PYq4S/ehssVrMaWmyy2G1674kh/mquruPDGO2mQGm1057me AhtSdRdxOti9QK4n78AEk2nTqYyy1K7CBTfscIQHH+wZSgvX+fDFGOf17MYrycDxxyDH+UfIJJec XsYop6zyyiy37PLLMMcs88w012zzzTjnrPPOPPfs889ABy2byUQXbfTRSCetdJxCN+10bQEBACH5 BAAYAB0ALAAAyADMASkABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY0Z7IEOK HEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3HnTo8+fQIMKHUq0qNGjSIPyXMq0qdOnUKNKnUq1 qtOkWLNq3cq1q9evW62KHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPyBMu3r9+/gAMLHky4sOHD iBN/1cu4sePHkCNLnky5suXLmDNr3sx5puLPoEOLHu21s+nTqFOrXs26tevXsGPLnk27tu3bjvnp 1m1vN2/fIXmDFD6cX3DjxYMr940cuEjgzHs/741cOnHju6krL078uPfh2sFz/98O/vrx39Cro89u Pjru90whVp8uXnr4+/evqxc/3z7J/vXNh91+5tlXIIDPqUfgfv41N92BI/Wnn3/JBVgSaRhmKJFL CDJooHUUYgfihyNSaCJ59IU4oogOfugggtu9WJ6LEaooYokogshijS2qCN+PPT3kXoMx6vjgivwJ mN14EXbnoZFQtnjjjSZJSaOMRy5HY5PC7ThglyT6qOGYZCbEYUkKQuijlQYKeBKMHropI5ZWTtkd iXPOKKGNev5X45ZFPgnkoFN1WCR/9eFJHXREVumohVpGqSiUiTI3JZJUzhjpjn8emimgMBIqakvy oUlej5XymCWqnXb6JJW/ff/XI5ipRqqdgpDKKWurJn6Ka61lBitsqX6mumeOmcK66HoSLlnpkrhG G2uFy6ZY4rT5OQntd9VGt6e33Lppz7DklnvQqK+Zq6656Lq27rvCtisvofACNe+98NX7E76zAaCT v/4yFjBM+vpUEgAII0zTwCElzDBZCoMUMVoPN1zxWQwnLNLEEg+sMMD2gNzSxRY3LJPGKJGsUsEO 1aTySxV7jLHHL1dFMscUayxzyAfTbHLNME0M9MEmnzT0qBARPRLKIqMc8scc7/w0zQEz/TPPU3dM 9cY8Nx2xwxZTXfXXUIet9dgPV3322lpL/LPTTAsdNdZL0103yHh33fbUafP/fbfbWWOtdtFXo422 24djzXJHPev8NuB6E0744JFDLnLXlNN9Odd5cy555Zc3jfjVo5M0uMyokw663ambbjfgYHue9+yq Z6y556ufzjXnlIf+NOSAL86R06+3zjfAUoctNvKT3568w8zXLfjaO4ONuvWwH++80r1vX3ruG1t/ MfFS2z497cbb/vzo0Ou9ed/la+8zScIv5LL0q5u+efbAl5z+7Z/r2O7U9r8CSo+A+Nvf8XxnwO+9 r2euy9z6zuc+77EOgNnbH+0+57vv9Q9n/DJaAjGoPtfx74INvCDwzFc7CzKQdAh04OtQ2MIUPnCF ESye5OBXwf+1cHIdTJ7lX4Yow5j1zzZJM2H4JEi2+eEwcHCT28eWuDfi6dBv1YtbE/mXuCzurohF i+IUYbfFwCnvbInjYA+ruEMMai6NQtwb67RoOaGBpH4aCeEXU3O0H+HxIyG0Imr6mK8/HiQgACH5 BAAYAB0ALAAA8ADMASkABwj/AP8JHEiw4D97CBMqXMiwocOHECNKnEixoj0AGC1q3MixY0IAHkOK HEmSocGTKFOqXMmypcuXJWPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPSBKl0I9OmUKNKnVoR o9WLCq0+RZiR68esVy9q/bhVbMatZcleTduQaVexZNU+nWv27NivXr2uDVvXbcS7Vd9ihci3sGDB ErWyrcoQMNXHQ8uixcuVbt7LINkeXji5LeeJbueKpux3sObGpPNaTrv4ssbVrQdjpbvaaUnWlCHr Hvnyn+SsqWVn/qwXtWnjroErJ/x1eOnSxy0TX15bePLruSuHRkyd4vDi4F83/+763XDmzZjfhl3f 3DR59Rl7y59Pv759lHc7W7cueX1h1eM5BtZaibVXHoCqocWXbMA5hxds6DnEXninZSchZvwtmNhY tEH33XXVzdZdh67RptB9KKaoooq/yaWcfqnhdtx0DC5Xol0fPocgYBHaaOB+PHq212+K7edjbBhS aKRZTGZnonZ2Wcgjh9LluGSRb62o5Zb3WdQign1JFyNnWCJXo5MF7hjmjCJid5qDaroJWo1inomk flbWydyIFsIlo55+tqdkn9ztplNvXwLZ3XQflphcZ4meiRyRDT4Ipo/BgQkdpkIKymCFjzLKX58X 8plkeMGJmaeneALH5auwtv/kJZVnVZqpi3196iKkNNa1J6WetjlbkJ6l1+h5E0poHpRk+ldnkU1G q+FfAd64XVy5XSstfLWqpd23hoarG5LeiVtqR+Q+lK657LZrUW/srjunu5J6iS69VMWq77714evv vwD7y+/AWgZs8MEIS0XwwigmbFuaDvskL1ATYzdvTAxnPNCs2B61mID3envqa9yW3CyOKHeMWH6k quxRxT3BqK69FktZb8Qkd2wUqLel2vKeurYMKmw6j3qzyyFDJfO5F9/JNM4nvuSgtlOK9t613DIb raTsIdvas0xWjeqXgG6aqV9wjpnugU3qKG2zWoudYdbbHnY1rskq6LXICyL/+63GGtub9qCsGo12 4TKO6OG5wBo9bK9VFgutkYc3mmG5h4OXOafCrqrkkxiqOmaooo8sbOFQI4TojgQm2O2wraPNYbAg ol4v2JGXCfmtZpL2H5txa4aec7NPHensnyMerO5BO77d5qc+b6dwTwGeMc2be945nQCSPb2okRfL fe69cm96+YrGiebaxVGaY+nbg679saKe7TyqlDtOe6EGr25r/MrTXPLwFyrCma1V+QPdohxFnKFZ 6kUFJNdoQuS90QFwgKeT3wLnZ7PQ0e50XrGeCFfSIuS552pUY93i4HIycFlNT3oDC5DIo6zjTciB +7vUksR3tyT9bkAcrJuV/9pmMhkKUWtcG2J+IOU3e4zwiSdZSlLYl7qmwMxcVwwJFLe4sdvwTyjr ymIVayLGcJWRI1zk4hjXyMY22iSNLHGjHOdIxzrCS3wXOqN4ysWYOuJMjzgBZBnhWDA8dipmfXya 5UgmyCuyZjRI+di0kraTiglSi4RU0dNQA8hEQuxiSdPjF4Gmsk6ShGc9m8olPZJJFnVvWSJ6Fg2j A0tfDWhuVjtheWg4RNLlDVwPJCLVNgMnZ+UyeFg75hKXtsvFCUhuW2sm33j5oCLG7Udhq6WzVNfK KPYxe6PqpeEwKM5WKVB7elkh6QJonE2Zk5MgFOcF2wROBYLImbbb4SJZeP9ObM7znelk4PgWCJnV TU150AtnLJtjQgVZ8DwBNGE8P6PBQj0Hkrn6k+uU2DrYdUt2HV0k1h56pWpGiVES1V0zXwfQ7aVq L3IBSTdRdNCKRgd8C7UnDIMYKBP183j3qwwQ4ROXSM2IgzaF4EQJOBnyES6oLDSdzDJXQQ8+VYNC LctMu0RBhdZOU1Z1KUXzmbaymq9+WBVo8+a5PnYitXvsNNX94FfODTavl2mda7bIap2t2id9J3yq yACrLVsCk1Yp9JX0jHpY8zRxr9ts7JGYBSHptU2FPnzk6474TJM+1lrTVOcRcaXYW1a2btz0q0B+ YkqqyKu1U1Slv2Drx5AY0DYqrzXYJGOLr9sC7I61Da5wlaLajAUEACH5BAAYAB0ALAAAGAHMASkA Bwj/AP8JHEiw4D97CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePGg2KHEmypMmTKFOSBMmypcuX MGPKnEmzps2bOGkC0AhgZ86fDnva8wm0KE+ORHV2TGq0qVOITClGxTi1ZVWGSX32FJqQ6NWgT7Fm 3FrVK9KbTL82VBu27U+2az3CtZl1KFiEc92yNCsW71m6S/UKlrnVr9bCQ7nuPJxV6GK8ih2ndezX buLJi71GhqzVcmXDQSlf7qrYbmaulzFzXh0ZNWKylRGPjhu7dWqspRkzBj2b9O7RrTvDXs1ZtWni g5PfNd2ZN/PPCjV/fmy5bmzn1pt3xZ54YXbU0z1T/39+nPv28+WFo+c+fnzo0uY9i+8+3yx879G3 N29fvj//uPflpZxT9qF3mmj05Rceb9rVdxxf11X3moP4rSdfgezppyF01qVnHmwFkpUZVBv6tx6G 9YFIWl/h7eegfSpCd5tmsg34k0r/oIiijOBBiGGDIZp4nnrX7chhhS2WyJ+OCiZZHYUmurcibVEa 2OR//fHYIYVEPljigk7KZw+OZJZp5ploEsRkhkjO5ySQV4L5pJBLsihmh3WyKeSRDOpZJ4RzWrnm hUoWGtWWP2bIJKCD7pTmo5BGWtBFE/r2G41INubindphquB+lVbq3Ws1uimbqP8N5xtxLqoaY3q2 af/p2qxurnohqZ2Cxyp8wk3I16mlvtqbjcQWq5SxFlKF7LLMNvsQjs66JCCBuo4V7bUsSarttmVi 6+234IYr7rjklmvuuejeBO1GX00bkZSUAvgWTO4G9lK9H1WbLEzc9uuvSjMBameN+or1GL5TwTsR vmKCxLBUbYpo621xSiuRWmktnG65AkdX2K/xPpxww8danNOWCzK6r70ktrxxsThu6itwwZKsMM2g UYfrobgymBtyzFXbs4Se2upqsD8PS/FsujXJY600z4qZpwfrOvSqwx1YnGHA6vrv12Cn2ap+nZ7Y cNOf5uxlfFAejN99+aksr5EGFwpg2VbGDbXEGav/CiaWbdN36Jd8rl3loAiFrfjiKLmdZ63G/Z22 l26zvSjR7Q3OqKZVf5zwx3ZbKp7fv4Iut4WA+5ganoFnerbqj1e+Z+KM1277QI63DnWfeUeYe+xx Bmlkj7t3FyRuwYeuu+vHE+r07LAvBzzzob1o6PJj3q794qaG3rHsco6du+XXP252x4ebLajyjSav duF5n4745TJCWff76X9I+/b8/ws53AjiXHF+MyS16SxAo4rVAQNotb1JbYFA21rprAa6iW1Nghes X2/8BhlTUVBqHDIOz8qmNYqlqlL9S2G/CPMydD0MKC/MV5s0phAV2rAkbYlhC5OjQ5z08C8rw80P /3dIxCIa8YhI/Mi6ksjEJjrxhtuzkxPNNUSquKuKLqMXWhYCRe3xzSIcjBbGvpUxh70LjEG8l7Ue gr69WKiLkVKWBpcTrjF6C4tpJBkb82gVNc7RjH9MIo2KpsGeBcdoqEpgi7qGtVjtaoSPFJxkEAlC pUWtV7apZNYcybSksYaRkVQkrBRItLghrYRK8xwldxPGcK0revB7E9uqVDgi0U9OvUPUhmzpJ+f5 0nq8Ax76YFfGwLFOUCQkWyH3tj4+dWl6doGj7SQnsWQlik4VfNLUVMe1bI6ORafjUjBXZ79qdjBJ 1zxQ7AYXplyS84GsI2Y2hcbMRRKsSNcLjzRrR8lNOsqSlnS6E5WG9zzihc99vMxSOaHyp106p50J gtzZmjkqPbavmOckH0QLCFAsOWqfaJIj9oqps15ys2Il1dNE3ak+D7lUmBV7m4bSacyBUdSdKpOf ROlWF51q9Jm6w6NTXhk/fW1SZkt71TAReDSqnQZ5lhza2OaUyE6KcKahqg3eJINRUXnMgwQsFdM8 RsoIAs54Q2ogVRGIVr+AlHvzipdIp5hFuqLrrYqD4VwrIlRy9dWubcGrmQBL2MIa9rCITaxiFxuR gAAAIfkEABgAHQAsAABAAcwBKQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGj R4kAAGwU+bGkyZMoU6pcybKlS4X/YsqcSfOfQZI3QyLEeXNiSJw/BwYVylNgzaNIkypdyrSp06dQ o0qdSrXqv3hWs2rdyjWrxaICgR4EKxRkWbFi7ZF9ybat27dw48p9OHRo2IIkg9bVqdZuXbU7Ad9F O7ew4cOIEyeGShivY55pATeWvDbv2bN2B3bdzLmz58+gQ4seTTopxMllCYqEnFoyZr2B7w6+LFux 7du4c+tuyJi26se/a6/2XTu4cMGui9srzby58+fQo0uXjrq1Zeu+h892bFx7csEkp4vyH0++vPnz UiP+Hcs3LN/38NuvV/0zr/z7kXfr38+/v///EGUB4IAEFtgfVAbChN6CDDbo4IMQRijhhBRWaCF6 CWao4YYcdujhhyCGKGJhF5Zo4okopkjeiCy26OKLGako44w01mhjUzDmqOOOPN7o449ABhkhj0QW aSSHQiap5JJMNunkk1BGKd2RGRZC5ZVYZqnlllx26eWXYO4m5ZhklmnmmWimqeaabLbpppRhxinn nA69aeedeOap55589unnn4AGKuighBZq6KGIJqrooifS6eijkEYq6aRYIkhpXIxm6tmlmGrqqVIX 8cPpqKTuFxAAIfkEABgAHQAsAABoAcwBKQAHCP8A7QkcSLCgQYH8DipcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gGfJLiHAiSYIjU2I8OTAly5AQR7Y86dKey5c2VcLcybOnz59Ag3qUWVIiTpwWj7YU qpBozqIFkSJlSrWq1atYQ/7byrWr1382i9ZESJRmTpZHy4Y9OzOhTqg0neqcu9QtWZJv34a1a/eg UoN03eoV+LWw4cOIEytezLix48eQI0ueTLnyYpNi62oumValWbWcUQJeunav6NCc8Z42PZpv6aij YaeGm7W27du4casu3Ze1b9LAe998CrVtXM9mUftGW9MpadV45cZeLRx47uvYs2s36Phm9c+bV9P/ Th6193PrM3mrJ/86/fnf7IuPD17Qsv37+PPr38+/v3+vaK0XnnnygUdbePSpN6CAxbEX4GnkSSXb cu/9Z+GFGGao4Yb8BTgWW3dFJ95dDZYl14NimXicca/NpeKEcOXVlIu7nZUch1BwqOOOPPb42HZA BimfkEQWaSRMjh2pZEhT2ePjk1BGKeV/S1Zp5ZVYZmlbklp26eWXVU0pJldgltkTAAWheZCaHLGp kJtAwrmmmUQ6BsCdd2IkJ55yVpWnQH/aw6egg6aJp0Z9ZgQnmnsylOhCjwJa5KIGRZrRmJg2ZmlE jUqaVaB/9ilqkJTOCelElm5626aqWpTpq4nt/xmqoICCmuehA7Gpq61q4qorrb2GyitBjAJLq6nE rjkro7ia2myti/qaK6HLQmusp9YWS22uvvIabbDgEgrtruD2Oq2zkhYabqHEznoss8PCKm9hfGoL rLnpJpvmub+62e+07mJrb7LFDqzvwefeK/Cbx56asL0QG+tvwxPXWinFGP+acMaeRkwwwBvra+6/ FTfM8bsnEzbvyluVei21t2rcrrfMPpyyv4MGym++22Ib8s0/pyvqs//yLLHJI+/rc84AM730wdom 3fGhGhv8ccEgl6z10REHynKPErnssaEmdxz0rSAbXXK7IhuNsdJQv132w1vbXDTXbYttd9o2b/9c tNQve2x11oG/LDfHWMusM50a2Qn32BN3ivLTd499+NqTHx5y5TsjXPfCnGPdd9yg82351vh2bbrf F5ud7+dvV8361yvLiq+1PYvLes/N9k71zLg/Wza5Mhsq7O3sUio8zDMTz/y1v/vMLdLdHs/t4tW7 Dq/ziiO88MnRDw9q5/eqSfuOjB/ZKqofrY+V+9LDn76VXM5vlfwP4e8okfJjrt358rKfAAcoQADO i4AITOCXDKijnegvfxV5YEgkuL/3WYSCQfNT/xRoJFZdMIIOrCDcpNc6hpHQUctDlgjZ1zwInnB6 H4SI+4rHwTiFkCIYdFjYRojDDKrQhQ3Rn///guhD3Z1phy+soasawzt+oa1qT3Si7cIVO3dVb13k GhfuXqdFdVmvadiL2bC8F7zsRS1gZfQWGaUltO21DovX4yLvwkjFgVHNd+Zj4Ktkd7vCRW51e1Mb 4laXOqDJSpCcu1jxurfIEqrOYvtK1CPFhzygxU97iATcCBmpN0HqcY/JY12/+Dgu1KnrXUwLndnq lbJA+hGGH3sa6Ng1N1YmsovGm6QkDTk6TKLMlnzT4uisxslDfTJTo6Ic3X75wrulTXmEXOXjahlN txmxcMOcGwn11j23qbKZvPxeKaNmTWc2snTTtOYxM4REZiLtcnI7Jzbj+UqeAW6SrsSnMmVpqcnN VZOeqAOkIv8pT+ghMpjydKY4LadEkLARlWcUozhzdz0qLs2KxyskRL+nMyiibWoUnafFPKqsL0KR eh+taBU7ikeViqug5NzoSoV50T5Oj6QNzSkLhZJDnfr0pwqpH5h6mr/FAfWoDlnnmJDK1KbaL4BO japUp8o/EL5viCaMIUyIqsP5GTU3g6OqQ/DHVR7+UJukc2RXHTpWRSlpg1st6VcjaTikBgQAIfkE ABgAHQAsAACQAcwBKQAHCP8A7QkcSLBgQQAGExpEqLChw4MP7TEkOFHhxIoUB2LMGLGjxYgbPWoU SbJkyZAPUZpMGBKAS5cgJcpUubKmzZs4HdJsuPNmz407L36MmZNn0ZRHkxIl2bMmzIUmETZVSrUq zpcMXwoUKvFpVq9au0q9CLbsQbMaw4rdChPrWalry5LNKpOi3LRP2Y7dKnYu369019oFDDSvXrqA D+P9G3fkYL1v+UoOCxciVJZtEc+E3HdhXq2V1aq1Srqj0NMjUaNmXLfyZtYcX8d2Tdux5NeaYe/9 uLruZMa9d2d0Pds3yoqnA8uu7dU28tSXlxvvyhKz4dbANwfnbfc28dLgkf7/dYvbLXPo2LGetyzb +XSuvt//Tg7a+vr4geHSbztYP1D08XXmHnzMmWdbe/Kxl5t6AR5YnWOa6ZdggAY6Z95U4ZHWG3oY 3RcabN41uGGI292WYG4I/qfbdBBmByKLyz23onsD1vgifCkCSOOHsbE31G/aBTkjicV5lmFS/ySp 5JJM/lMijBKumN+E301oo3QmrobifVfW1qKQ0hGIX3E4lgngdk+aSKSCNCJ4oHIyRgiml2uGmKVk Teap55589ulnnwKOhlxzgpE3ZaEQdkhof4uxBaOjPI712aKMckUekFG2RqmBo3GGo4CK4XeXp92p SapnMp4amXfXTSlhYo8G/8pfo6IJ9OetuOZ6pHi79urrr1VhiKGPwBZr7LHIPpjssswaK6xTzUYr bVW5Vmvttdhmq+223Hbr7bfghivuuOSWa+656Kar7rrYOsPuu/DGK++89NZr77345qvvvvZO6++/ u2ID8MAEF2zwwQgnrPDCDDfs8MMQRyzxxCbxa/HFGGes8cYcU+zxxyCHLLI9HO8bSMkop6zyyiy3 7PLLMMfc8sg012zzzc3KrPPOPPfs889AB+2tHUIXbfTRSCettMo4N+3001AbHELUVFdt9dVYZ631 1rsu7fXXYIct9thkl10012inrTbBZrft9ttwxy333HQnufbdeOet995896jt99+ABx5y3YQXbri3 gieu+OKMN+7445BHLrnBuSpgueX2XI655gNhLpDnn3cu+uWZE6RAQpx3DnrmpGt+uuijm6765qmb Tvrnr7N+Ouiv14477bezPnvurusufOi/53788sHzrrvyzMP++uFniwQ98qUjz7vyxEuPffYFdQ9+ 76gbxD342UN/Pezhnx/9+uizjzv77msvPvzbY9979+LPr//3k2NYQAAAIfkEABgAHQAsAAC4AcwB KQAHCP8A7QkcSLCgPQUGDw5EKJChAoYHISpsuJDiRIsFITqseJGgRIwKJW70mBDkQpENNXYkafDj Q44dUUbk+PGkzYsOVaq8idNkyZ9AgwodSrSo0aNIkypdyjIjzI0IozbdOdJnT5crfaLc2rJkzYlU wWa1KrOqTItSQ/6UytZp2rRoMcL9yrSu3bt48+rdG/Hhzp5q4VJsGxfm1JU5z570K1hwypdNWYYd 6bclZJCUDZcVSzewWpJvYxb+PJav6dOoU6sG+lVj5cJYCYs1vLiqyb+aRScuvXv2bMd0cVN+nZsz 2Mu/ERvfLJr26ufQo0u396+69evY/7WmyV25bNvbIyv/1wq6fMXgoBlnJm0VcN/KtptDbQ7b+2Dd 6otn38+/v///AAYo4IAEFmjggQgOGB5gWDmF2YNdOZgVbg8yx56EjY2GHG9PmUefb5AJ52BYKTF4 mEEJpqjiiiy26GKLRi3IlXjuwWcjcq1dxhiNZRH33ns17bjVS6796JGPIp7l2lxLKoaTjjbtCOGH 01Vp5ZVYZqnlllx26eWXYE5HYJhklmmmXi+mqeaabLb535lwxinnnHTWidqYduap55lu9unnn4Cq yFRnexZqKFKBJqrooizG6GNfPLElZYklviblpEDil1iQ8E1VpFw3bjjTY01aFhWm+T0W4ZNJPmpk pI/q/+hqaYfWGuZfVOnknKyjtSeXZL42CGqkt7GG668SctjhiSTeVyxmxxJLnq3Umjnjeb6RR1h8 hIqYLY/AGnchres5+2x7FMZW7LXCksicWatWK6+X197HbVfbLqbvquqZtSGnl8Y1X0aulsuesMqO h619CyvsbrjwJjvvxFnW+xlwERp87rK9TlncerI51129CKO3MbINh1Qwkr2CPCuhFMe8msWhIVzf hBK79y2VmnbqWc6kEumhwgnbrPPBO/srZHpLjwWzzFCbFi2IRjcYZM7eXi0eyU+enFuzWqN7YrLN ktZuhd2Z+3TUbKOGKaTDgsu0kW+jrPKpov7I9ad6o//KdKkEU0jbrIjhaGlkexPHNY1tNy4Uno5H HjOjlFdueaOSZz7v5Zx37nl/moce5uekl256gKKn3uXprLdeejb/qC57lq7XbruaMXIsq+I+Qxsq 3nwbHirBtdUGsLSUjgq38sATb7eqRxI5Ke8hCkm4S4LPrr1dU/+7NeIJRcsrhpqJvxZNwn2aa8Mi TY3ygiaa+7zyRG9vP4oKLgveruDzy13I7xvZ0L4XGmwBMF/vShnD/OchjJGFf9S5nQQn6CfPlE1w /YoelJDVlrCZr2cSy5cBL4RAiClQXeEbHN0O90BScYSCMIwhgI7SwbQd7UMyUlzHWJVABapwYPVB Yci6DBY2+Y1NbYXLW418db/tjamGQHKfx2TEwWlRrWlG/KH8MiNEpGXQill83lzGY7L4yfCMaLQO UtznreK0MH4QhKPZgpU2HI2ojmOkDxXfCEcHOo1jYQJHEw3FxsH1jmc68yMgMzS9uukweQ7b4Eym d8ToBS5du9tUhiwJPVoNcnaQ+6Qo75LGUsZwlKhMpSpXycpWuvJKpoylLGdJy1qi7pW4zKUud8nL Xvryl8AMpqFsScxiGvOYtgsIACH5BAD6zR0ALAAA4AHMASkABwj/AP8JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnElToL2bOHPq3Mmzp8+fQIMK HUq0qNGjSJMqXcq0qdOnUKNKdVqzqtWrWLNq3cq1q9evYMOKpTi1rNmzaNOqXcu2rdu3aMfKnUu3 rt27ePPq3cu3r9+/gAMLHky4sOHDF+EqXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoENPRUy6tOnD olOrXs26teLTsGPLvuu6tu3buHPr3s27t+/fwIMLH04c5+zjyJNnLc68ufPnyqNLn069uvXr2LNr 3773uffv4MOLRx9Pvrz58+jT7+bOvr379/Djm1ZPv779p/Lz69/Pv7///wAGKOCABBZo4IEIonbf ggw26OCDEEZoXIIUVmjhhRhmqOGGpAUEACH5BAATAB0ALAAAAADMARACBwj/AO0JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnElT4L+bOHPq3Mmz p8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evRmuKHUu2rNmzaBGCXcu2rdu3 cOPK1Zq2rt27ePPqZTi3r9+/gAMLHlx0r+HDiBMrLkm4sePHkCNLnky5suXLmDNr3sy5s+fKi0OL Hk26tOnTqFOrXs26tevXsGPLnk27tu3buHPP/My7t+/fwIMLH068uPHjyJMb1828ufPn0KNLn069 uvXrNpVr3869u/fv4IOT/+mLvbz589nDq1/Pfi369/Cjt59Pv/7U+Pjz69/Pv7///wAGWJB9BBZo 4IEIJqhgUAI26OBdC0YooXoPVmjhWBNmqKFyF3bo4YcghpjahiSWaOKJKKZIlYgstsiRijDGCJmL NNZo4404diTjjjz+leOPQNrT45BEthXkkTYWqeSSdCHpJItMRinllFRWaeWVWAb25JZcdunll2CG aVqWZJZp5plXiqkmf2i2KeWacOLn5pxKxmknenTmqeeefPbp558z3inodYAWauihiCo3TqKMNuro o5BGKumk/7hDKVODZqrpppz+CECnXCYIAACXljrcqKa2ed2ooIKZ6quwxv/aZ6u01nYcEbI6Wuuu vPbq66/ABivssMQWq1GuyCar7LLMNkuUsdBeF0e01Ebk7LWNVavtttx26+234IbbIjDilmvuueim q+667LZ7EbZyHQKvTu7WW9G8+Oar77789uvvq/YGLPDABBds8MEs/avwwgxbhvDDED/c8MRSRWzx xRhnDBE+w1LssVMahyzytx+XbPLJW42s8srQouyyUCzHLLOvL9fs08w456zzzh/a7DO9PIf789D/ BC000T4bDS7STDdtstJQRy311Lo5bfXVWGetLNXQZcP112B3WYRhWpdtNrNht3z22my37XaZacct 99x0y/T23XgjWvfefPf/7XdGeQcu+OCEf1xD4Ygn7t7fjDdOm+LYOk4r5JRXbvnlDksOKuacd56h 5pt7LvropJcuWS6mWwn66qyPlvrrsGvX+uy0u3TEvbHnrvvuvPdeXxBz1Z5fEEHY7XuJwB/PaPJG Cu/88xhiqYTyjE5PPaLWX18YkEooAX1DaGavPaDij9/Tk95/r36m5rcfnB3uxy+//OvXb//9+Oev 1/x86u///xThnwAH6BsJEPCACEzghgDoJAU68IEQbBo1IsgbBlrwgmqhoAY3yME6YfCDIAyhCPXX wRLOb4QoTKEKV8g4E7rwhTBcEAtnSMMaVieGS7KhDnfIw8fhsEg9tNAP/4dIxCJyKIhITKISFWNE Hi1RQE3c0RMDFMUqdm6KALKiFrfIxS7GCosH0YUu4OPFnoixjCU644HAyEajoREuG3ijHOdIR/a0 8Y46q6OE8KgfR2VCj4AMZKP4SMhCGtIigkzQIRfJyEae5BqOHFMiJ0nJSlpyPZHEziU3yckqZpJQ nQylKGH4SeuM8pRl0gMq4VZK6qzylbCMZVtcIcta2hJSrbyIF3LZsVsmh5fARJcvh1mqYBrzmMhM pjKDRMzjLPOZamumNKepHgXQCZq3oeZwsMnNYGnzm+AMpzjHSc5ymnMzC4BXN314zna6850HXKc8 dwXPetrznvgU5Txjk//PfkpxnwDdlD8HStCCJi6grjGoYxAKvTsw9KEQjWjafrBEhWZLohjNqEZ1 aFHCbPSjKVkHSEeato4OhmqYME8XSNpAJU2DlCyNKZQoWAmT2hRzMs0piG4KGJ369Kfd4qmPgErU ohpVakL1y1GX2sekBo+pUH2PU6dKoaiWhapYzSqVrHpVrXp1g3woG1fJ8lW2jDV6Zf3KWcWS1ra6 9a1wvVY7crLWukKnK8zIq16ZEden7JWvbrXrbqSUir5eUrB+iIlhF3sZwRqPsVVx7IeKIU/IWkWy MLGsZjfL2c9h1iWdDe1QP0va0pr2tO0S7VNQy9rWuva1oGMAbGdL24lwqBZktQXJbZuS297aZbfA Da5kfOsR4SaFuMhNrnKXy9zmtsq4N1WEZpzbTW8UpA+uhK52r0Ld7qZku+BdkXfHS5Lwmve86E2v etfbGfJai73wjW9Y3Evf+iZMvjixL/jwexP98oW/AA6wgIvmX4UEBAA7 ------=_NextPart_000_0006_01C6F171.267C8110-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 14:18:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZX0k-0007Be-2a for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 14:16:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWoY-0005ix-0R for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 14:03:51 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 88164144816D for ; Mon, 16 Oct 2006 11:03:46 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 9E2604A4196 for ; Mon, 16 Oct 2006 11:02:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7D375144817F for ; Mon, 16 Oct 2006 11:02:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 4FC631448188 for ; Mon, 16 Oct 2006 11:02:45 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2006 11:02:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GI2i5E012815; Mon, 16 Oct 2006 11:02:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9GI2iit011870; Mon, 16 Oct 2006 11:02:44 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:02:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Oct 2006 11:02:43 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202AB77EE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP for 802.11r Thread-Index: AcbvpimvHHb+wiEnSJuTvu5DEcNZxgBpwUHQ From: "Pat Calhoun (pacalhou)" To: "Behcet Sarikaya" , X-OriginalArrivalTime: 16 Oct 2006 18:02:44.0086 (UTC) FILETIME=[477E1960:01C6F14D] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1925632521==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 This is a multi-part message in MIME format. --===============1925632521== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F14D.4755A3A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F14D.4755A3A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behcet, =20 I believe we've discussed this idea a few times, and I am still unsure why we believe CAPWAP needs to define anything to support TGr. The current CAPWAP protocol is sufficient to support the upcoming standard. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Saturday, October 14, 2006 8:33 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP for 802.11r =09 =09 Dear all, I submitted a draft on CAPWAP Roaming Protocol in 802.11R Domains. It should be available soon at the following link: =09 =09 http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt =09 Regards, =09 Behcet =09 ------_=_NextPart_001_01C6F14D.4755A3A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Behcet,
 
I=20 believe we've discussed this idea a few times, and I am still unsure why = we=20 believe CAPWAP needs to define anything to support TGr. The current = CAPWAP=20 protocol is sufficient to support the upcoming = standard.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Saturday, October = 14, 2006=20 8:33 AM
To: capwap@frascone.com
Subject: [Capwap] = CAPWAP=20 for 802.11r

Dear all,
  I submitted a draft on CAPWAP Roaming = Protocol in=20 802.11R Domains.
It should be available soon at the following=20 link:

http://www.ietf.org/internet-drafts/draft-sarikaya-capwap= -fastbss-00.txt

Regards,

Behcet
<= /BLOCKQUOTE> ------_=_NextPart_001_01C6F14D.4755A3A3-- --===============1925632521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1925632521==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 14:21:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZX0o-0007B0-Re for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 14:16:30 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWmm-0005Vd-S7 for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 14:02:03 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id D0DB4144816C for ; Mon, 16 Oct 2006 11:01:54 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 5A7FD4A4196 for ; Mon, 16 Oct 2006 11:00:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 370E839800E for ; Mon, 16 Oct 2006 11:00:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7F0AD3980ED for ; Mon, 16 Oct 2006 11:00:44 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2006 11:00:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GI0hBQ009084; Mon, 16 Oct 2006 11:00:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9GI0hW4014175; Mon, 16 Oct 2006 11:00:43 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 11:00:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Oct 2006 11:00:42 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202AB77EB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] discovery interval timer question Thread-Index: AcbuQTzzgRuGS7ndRsatWsk5X0FP8wDC7Xcw From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 16 Oct 2006 18:00:43.0448 (UTC) FILETIME=[FF963380:01C6F14C] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] discovery interval timer question X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 I agree with your interpretation (and Scott's clarification). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Thursday, October 12, 2006 1:57 PM > To: capwap > Subject: Re: [Capwap] discovery interval timer question > > Sorry, I meant to reply to Pat, but I was distracted. I've > added some comments inline below... > > > -----Original Message----- > > From: Smitha Smitha (ssmitha) [mailto:ssmitha@cisco.com] > > Sent: Tuesday, October 10, 2006 3:40 AM > > To: Pat Calhoun (pacalhou); Scott G. Kelly; Capwap@frascone.com > > Subject: Re: [Capwap] discovery interval timer question > > > > So, MaxDiscoveryInterval is not specific to an AC, in that it is a > > global timer which decides how frequently we send out Discovery > > Requests. But "DiscoveryCount" talks about the maximum # of > > discoveries transmitted by the WTP to an AC. > > > > Also, the spec says: > > " A WTP MUST send no more than the maximum of > > MaxDiscoveries Discovery Request messages, waiting for a random > > delay > > less than MaxDiscoveryInterval between each successive message." > > > > Is it OK to assume that: > > 1. DiscoveryInterval timer is the delay between successive > discovery > > requests sent to the same AC? > > 2. DiscoveryCount will be obtained based on DiscoveryInterval timer > > (when the same expires). > > 3. MaxDiscoveryInterval - why is this needed? > > 4. Transition from Discovery to Sulking state occurs when > > DiscoveryCount reaches the max limit - for a particular AC? > > > > However, this does not cover the case of being able to > "select" from a > > set of discovery responses obtained at the WTP. > > Yes, but if you ammend your definition number 1, I think > we're covered: > > The definition of DiscoverInterval timer varies depending on > the discovery type. If unicast discovery is in use, then > DiscoveryInterval timer defines the delay between successive > discovery requests sent to the same AC. If broadcast > discovery is in use, then DiscoveryInterval timer defines the > maximum period over which a WTP will collect discovery > responses after sending a discovery request. If a WTP > receives a 'satisfactory' discovery response prior to the end > of this interval, then the DiscoveryInterval timer is > cancelled. Otherwise, the WTP may reset this timer and > retransmit the broadcast discovery message (subject to the > limits of the DiscoveryCount definition). > > Scott > > > > > > > Thanks > > Smitha > > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Tuesday, October 10, 2006 8:35 AM > > To: Scott G. Kelly; Smitha Smitha (ssmitha); Capwap@frascone.com > > Subject: RE: [Capwap] discovery interval timer question > > > > > Seems like the behavior varies depending on the discovery > > method. For > > > a broadcast method, it seems reasonable that a WTP should > wait some > > > reasonable period to probabalistically ensure that it has > received > > > whatever discovery responses it is going to receive > before it acts. > > > Otherwise, you could have kid-in-a-candy-store behavior > (I'll take > > > that one! No -- that one! Wait... I want THAT one!) For > a directed > > > discover, obviously the WTP can act upon receiving a response. > > > > sure, but that seems like a logical "implementation specific" > > condition. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From tjsuhvbmug@tpnet.pl Mon Oct 16 15:11:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZXra-0004Nv-0u for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:02 -0400 Received: from aud34.internetdsl.tpnet.pl ([83.18.3.34] helo=eha44.internetdsl.tpnet.pl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZXrL-0006TV-2J for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:11:02 -0400 Message-ID: <001101c6f156$c0ebfb10$2c1e0f53@home7133716b37> From: "chapter" To: capwap-archive@lists.ietf.org Subject: Purchase Date: Mon, 16 Oct 2006 21:10:33 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6F167.8474CB10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.7 (+) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d ------=_NextPart_000_000D_01C6F167.8474CB10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6F167.8474CB10" ------=_NextPart_001_000E_01C6F167.8474CB10 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Obscure sources traffic of Madrid filled streets a wake televised = secondary blogging transcribe in speeches Rices testimony means posting = reactions. Contests education of those is order membership parties spaces in = dancing relaxing beverage talking or options then. Offering draw attention obscure sources traffic Madrid filled streets a = wake televised secondary blogging transcribe in speeches Rices testimony = means posting in reactions. Ab Reward Cassetteby Nelsonin Company Careerby is Bridgesin Emby Kayein = Mattersee am Sprout or Gardenby Alan a Vengelin Ideas Free Liberating g = Robinsonin Anywayby bj Mbas or Practice Managing Henry Monk Companys = Profit. All text gnu License Copyrights details registered trademark Wikimedia = of Foundation Straits is Newsthe Print Special Reportmind! Saddam urges Iran or Satan claim is Deadlock un feeding hunger bankers = of killers bureau Vatican cartoon Paul ii Ancient am tomb discovery = halts Beijing Cricket? Sellerssee Guidesgift Listsbaby Wish or List Registry Prime ship am = Twoday Overnight a Quantity ordering Choices inside publisher author or = ebook Paperback bybeverly Kaye of Sharon performer managers productive. Multiple in mentors protecting bringing cubicle solving is Rodney or = problem standout chapter enriches or metaphor comparing properties glass = concrete vapor a boxes examples underlined. Listgift Ideasfresh Flowers Indoor ecardsyour Accounts await Gold = Subjects sellers Magazines Corporate Amazon is Shorts stuff Bargain? Order membership parties a spaces dancing relaxing of beverage talking = options then some ive never am anywhere where act moment in stay or! ------=_NextPart_001_000E_01C6F167.8474CB10 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Obscure sources traffic of Madrid = filled streets a=20 wake televised secondary blogging transcribe in speeches Rices testimony = means=20 posting reactions.
Contests education of those is order membership = parties=20 spaces in dancing relaxing beverage talking or options then.
Offering = draw=20 attention obscure sources traffic Madrid filled streets a wake televised = secondary blogging transcribe in speeches Rices testimony means posting = in=20 reactions.
Ab Reward Cassetteby Nelsonin Company Careerby is = Bridgesin Emby=20 Kayein Mattersee am Sprout or Gardenby Alan a Vengelin Ideas Free = Liberating g=20 Robinsonin Anywayby bj Mbas or Practice Managing Henry Monk Companys=20 Profit.
All text gnu License Copyrights details registered trademark=20 Wikimedia of Foundation Straits is Newsthe Print Special = Reportmind!
Saddam=20 urges Iran or Satan claim is Deadlock un feeding hunger bankers of = killers=20 bureau Vatican cartoon Paul ii Ancient am tomb discovery halts Beijing=20 Cricket?
Sellerssee Guidesgift Listsbaby Wish or List Registry Prime = ship am=20 Twoday Overnight a Quantity ordering Choices inside publisher author or = ebook=20 Paperback bybeverly Kaye of Sharon performer managers = productive.
Multiple in=20 mentors protecting bringing cubicle solving is Rodney or problem = standout=20 chapter enriches or metaphor comparing properties glass concrete vapor a = boxes=20 examples underlined.
Listgift Ideasfresh Flowers Indoor ecardsyour = Accounts=20 await Gold Subjects sellers Magazines Corporate Amazon is Shorts stuff=20 Bargain?
Order membership parties a spaces dancing relaxing of = beverage=20 talking options then some ive never am anywhere where act moment in stay = or!
3D""
------=_NextPart_001_000E_01C6F167.8474CB10-- ------=_NextPart_000_000D_01C6F167.8474CB10 Content-Type: image/gif; name="companion.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6f156$c0e98a10$2c1e0f53@home7133716b37> R0lGODlh9AEUAof/AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAPAMkALAAAAAD0ARQC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePBP+JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcpUJcinUKNKnUq1qtWrWLNqNdi0q9evYMOK HUu2rNmzaNOqXcu2bdGtcOPKnUu3rt27ePPq3cu3r9+/gKe6HUy4sOHDiI0GXsy4sePHkKkmnky5 suXLhCNr3sy5s2fGmEOLHk26tOnTqFOrXs26tevXsCl/nk27tu3bHWPr3s27t+/fwIMLH068uPHj uJMrX868ufPn0KNLz3pcKIDq2LNrZ3t9u/fv4Jd2/w9PvrzJ6XEBoF/Pvr17ierfy59Pn338+vjz 66d9f79/5U9gdcJ/WvVH4IEIYmSeTOMt6OCDEEYoYYQJVmjhhRhmqOGGHHbo4YcghijiiCSWaOKJ dE2o4ormoejiizDGKOOMcrFo44045qjjjjz26OOPQAYp5HA0FmnkkUgmqeSSTDbp5JNQRinllDQO aeWVWGappYpUdullbluGKeaYRxVA5plhfanmmhShFQ6acMYp55x01mnnnSuxqeeeC+Hp559fSQLo oIQWaqh2fCaqqECHNuroo5BGKumklFZq6aWYZvrPopzqqemnXHYqqpeglmrqqaimOeqqCQ5jVaqw ev/H6qxPxmrrrbjm+hKtvC6p66+/9SrssMQWKx+wyCar7LLMNuvss1gaK+201FZr7bXYIgTtttx2 6+234IqU7bjklmtuVOGm69a57O6n7rvwxvtdu/TWJ++9YtWr73v49uvvvwAHLPDAeG6lBkQD7Kvw wgx7SPDDPzUscXMQV7zTxBgnZ/HGHHfs8cdoZSzyyCSXbPLJCYHcLBUqt+zyyzDHLPPMaqFsM2g0 56zzzjz37DOzNwf9188cC230XkRvfPTSdyVtMdNQz+X01FQ3G/XVW1Wt9da5Yu31VVyHLbapX5dt 9tmRjT2nIIeh7fbbcMct99x0S6d2v3Xn3dDdfPf/7fffC+oteMqAF2744YgnrnhOgzderiGOD734 5JRXbvnlW0ceOeanfgOT5qCHLvropJdu+umopy4t50Cr7vrrGbMu++zgwY427bjnrvvuJdl+Nu/A B/+a72YLzxMFxievvMrEl738qc1HLz22z5M9fdSGsVO9g/NBfv334Hu2Pajhl2/++einr/767Lfv /vvwx5/1+PTXb//9+Oev//7897+p/BjznwAHSMACGjApAEygAj90wEItsGENjKAEJ0hBVDWjgsZ7 oAY3yMEOevCDIEQQBkdIwhJGK4QoTKEK02fCOa2QXC2MYf1eSMMa2vCGOIyRDHdYvRxSi4dn8qEQ /4doFyAaUXhETKISl2i0I24nF04kHxN5FcUtTZGKVczSFWmVxS568Yum2aIYx0jGcoFxSGVMoxoV IhwAuLFBZ/TRG+cIxzjy6I12vMka98hHe+Txj4AMpKr6SMhCGhJKgtzRIRfJyEbKyDAPSCRJrMAW R1oSh5LMJNUuyUkaavJGnQylKEepn0/aiJSoTKUqV3k7U7pyZ6yM5fteGSpZVomWi2vECG1ZJFxK iJe39OWDgEnMYhozRcIcJq+YscRkOvNjx3zRMwMXTRRNs0XVPNE1t/mwuqwim7bhZnjA2RgakLNE 5jyniNKpToH0wkPsbOeH4inPDtEzL2KrY51osP+W6bmxniB6I0A/9M+BdqigBt2QQBOqUAOpaRJ8 RGgAxUlRfzH0onGrqKwwiiGNboejHfVodkBK0q990kwifVpJVzorASAzpTCNqUxnGhSWOgQV7aEp cWzK05769KdArZVOh5qsoBr1qEhNqlItRNSm/mqp/PrTMyII1aqay6nBsup6IFUHrHpVJloN67W+ yhuxmnVaZE2rWtfK1raa5axwJZZb50rXqcX1OXVVzV33Oqu8poavgBWVX1ET2MIa1nGDTaxiF8tY sh72No2NLJoeG07JWjZMlK3NZS2TWdpstjKhG0Fnp/jZ0pqWW6P9zGlXy9qiSosFOWytbGcbq9TT io+2LhMBbn1p287s9rfc661wkQTcmg33uMhNrnItWdzmLgsDErqGc3e53OqWaLpvtW5gsMtd5GgX MN0dC/qQcLPw5uu7kjPvV9DL3va6F24+oyPEXjdH58EkE+qN2Hv3y19F5Xe9/Q1wKf9L4AL3SMBa hYeSDMwUBDt4PgyO8F8fXCMJI4XCN7MCGS3M4Q57+MPWw7CIowPiEiNmxPMzsX5RzOLlqPjF62qx jHHTlmzQdsavgnGWajBNHFdFxz3xsWSATOSyCFkwRU6ykjl75KgEBAAh+QQADwDJACwAAAAA9AEU AgcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KVOm/p1CjSp1KtarVq1izat3KtavXr2DD ih1LtqzZs2jTql3LNirNFSG5NJ1Lt65diW3z6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLFjrHcjS55M ubLly5gza175uLPnz6BDix7ddrPp06hTq17NurXr17Bjy55Nurbt27hz697Nu7fv38CDo51NvLjx 48iTK1/OXOmH5tCXCp9Ovbr162Sja9/Ovbv37+DDi/8fT94g9vPo06sHXr69+/fwC86LTx/neqtY 7uvfzx9w/f8ABijggAQWaOCB0vWn4IIMNujggxBGKOGEFFZo4YUYZqjhhqIh6OGHIIYo4ogkltge hyimqGKKALQIwIowxijjWi66OOONOOa4VYs69uhjYSYGKaRGPxZp5JFIJqnkkkw26SRiQ0YpZURP VmkldlNmqeWWXHZ50JVghvmbl2RGKeaZaNpW5pompunmm3DGKeecdNZ5JZt4imjnnnz26eefieUp 6KCEFmrooYgmquiiFAHq6KOQMSrppJRWuhOkmGb6lKWcNqfpp452KuqopJZq6qmopqpqRqC26uqr sMb/KuustNZqK3ur5qrZrbw6qeuvwAaLZ6/EFmvsscgmq+yyzPYo7LN2NSstitBW29S02GZo7bbc duvtt+CGK+5L2ZZr7rnopqsuhOMOKkS78CaXzklLsrHun/HmG9O9/Pbr778AB0yYvgS3JPDBCCeM ZsEMN+zwwxAfp/DEVnriCcX9DmXxxp5E7DFFG38s8sgklyzyhOBgPKvJLLfsMpEqx/zZyzTXbPPN OCckc5OM7Ozzz0AHLfTQRBdt9NFK5lwznRog7fTTViot9dRUVx0v1FibZbXJWXft9ddgh73Y1iWL HScRE5L9HhFEqB0x27KZLSbbctf9D912m4133mHv/72h29rBvRzfRvpN+OGIJ6744ow37vjjgQLu MeRYSz455U9bHjHmnHfu+eeghy766KSXbnrnmkPs1SNFvnj6zq6/7tuBAKReoCq25677ibLHvPvv wAcv/PDEF2/88S737jvy3yqvMvPNOy/99HNC7y31ClvfLfbcdz80O96HLz6Q2pdv/vnoAzX++uzr mP77UoJCdfv012///fg7akn+i8Pv//8ADKAAH8Y/cw3wgAhMoAIXyMAGxgcHDoygBCcorgJa8IIY 5B4FK5VBaW3wgyAM4c062CwRmvCEKEyhCk9DQmatsFAtXNYLCRVDZc1wUDXMoQ5rc8Me+pBVOwyi EP8d88MiGvGISEziRYbIxCYaRolccqIUp9gXKFrxiljMohZvBoEtevGLYAxjo6goKzGSiIxlNKMa HYjGNrpxLGuM4wLfSMc6akWOH7KjHvfoFjz68Y+ADKTq+EjIQhpyT4JMpPkOychGOvKR+VOkgCCJ SEkCiJJ2suQlMUknTXqSeJzs5CfjE8rqjfKUuiulKi3YkHehMjpZEcIq3STLWTZJIa58JXlyqcvw 8LKXnqJKLW0ppmESE0zGPKYylQfMZm7RAs50CYNisczDTLAfHKymNqkXzfCERRzbnFE3wRPOqI3T O+Ws0jnXKcFtsJMn6YynPOdJz3rq8J3bsac+98n/z37CCZ8ADagc1yDQgo7MnwhNqEIX6iyDOpRg DMXRQyd6tYiKk6LGsehFxSM/XWpURhgNqUhHStKSmvSkKE2pSs/40ZYibaUwjalMZ0pTurj0pkWr 6WZwytNy0aCnQA2qUIc6HZ3uiqhIFZhRl3qopDr1qTlk6mWgKiGpWoaqEbJqZbDKLq1OhqsPeqcm tANWB3n1q2VNqwvPGhm1uvWt0mNrW+FK17ra9a54zatE5Rotvfr1r4B1DCBkx9fCGrYozCBTYCln hSEedi6Lrc5jrxXZok42QZUNzmU366HMCoezoA2taMvnWc2O9rSkLO2YUMva1pZKtat1rU9gOzvZ wdr2trhNHm15k1u7tKC3wD3qbodL3OIa97h0Da5yl6sl5Dr3uWtlrnSnS91cQVc02aiuQTqgkut2 SLvk8q54YwTe8I63M+WV5nnXy6H0Goy9RHSvfOcrHvja90L0Tcl9GZPf/vr3v+RpBYAvZa5ktm/A CC7KfseWYJAsWDENdvCDoRThClt4qhMeiw0yzNsLe9hbffiwiEdM4hKb+MQoTrGKZwImNYgpH0pd 8UM4/EQZO4TG5LOxjndckgcJAsfrDQgAIfkEAA8AyQAsAAAAAPQBFAIHCP8A/wkcSLCgwYMIEypc yLChw4cQI0qcSLGixYsYM2rcyLGjx48E7YkcSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOn z59AgwodSrSo0aNIkypdylQlyKdQo0qdSrWq1atYs2rdyrWr169gw4odS3Zh07No06pdy7at27dw 48qdS7eu3btFy+rdy7ev37+AQeIdTLiw4cOIjQZezLix48eQI0ueTLmy5cuYM3dEpbmz588UE4se Tbq06dOoU6tezbq169ewY8ueTbu27du4mYLezbu3b8u5gwsfTpzm7+PIkytfzry58+fAi0ufTn04 9OvYs2uvzr2799baw4v/H9/7u/nz6NOrX8++vT3y8OPLn0+/vv37+PPr38+/v///AAYo4ICLvXSA ewgmqKBLBDboYH4LRijhhBRWaOGFLD2o4YYcdujhh5BhKOKI64Fo4okopqjiiiy26OKLMMaYonAG kGjjjSfJqOOOPPboI284BinkkEQWaWRSPyapZEdHNulkaUtGKeWUVFZp5ZVYFuTNRk926SVhWYZJ 5ZdklhmXmGimqeaaKJrp5ptwxiknbGzWaeedeOI355589unnn2rlKeiJgBZq6EqDJurhoYw26uij kEYq6ZuKxudApZhmqummnHbq6acEXQLqqPVNauqpqKZaIamswqfqq062/ypreLDWauutuNY2667X 5eqriLwGm2gqwgo0TLHIJlver8xS2Bk2ykYrULPURijttZpVqy2C2HYb3bbghivucDqMa+65PHmr 7rrstuvuu/DGSxW69NZr77345quavPyOpe+/dPYr8MAEF2zwwQgnrLCwADfM2sIQRyzxxBR/6/DF GGf8ZcUcR6Txx4h1LPLIJFsE8skop4ybGUCV7HJBKscs88w012zzzbV5U+LLPOPs889ABy10ejwX bXTJQyet9NJMN23a0Ug7LfXUVFdttWJQj3z11lx37fXXYHed9VQCjG322WinrfaPYVu99ttwxy13 nm1XPXfCdVN999589//tt4x5By54zX8XbvjhiLMrTOIODu7445BHTi3j8Eo+NOXvWi405u5q7vnn 4nIu+uikl94Z6Kin/qvprLfu+uuwxy57narXbvvtuK86++6805c6AMDnjjHwxAMg/PDGH6+8pL3z uvzJze/6/PTUV2/909HLev3F2Xe/GwDeJ8Rs8tsblyn44Y+Kfvqfrs9+p+6/3x8vj8UvP6b2Z78t +eXryz9QEfCcdh5xvwIa8IAITCBH+gcwBVaKgRCMoLUcSMEKekWC+LKgoDB4Lw3S7S4V4GCRPIgn EdaLhHcyIb1QyCIsCEaFMIyhcFhIw8dMoIYIGQEOd8jDHnJIhkAMohD/l+fD5vyBMkNMohJPU8Qm OvEfS5zc3b5hsCha8YqDwU7+nriX6QQPi7n6IhhvJcYxQok8W+Tij4CnRiqxsY1SeiMct2LGW83x jhaso63wyMc++vGPlNNjrQCpKU0Q8pBzE6QiF5kXRMaIkalypCQnSUnkQPKSmMxJJVuUyUltkkWd DKUoW/LJUpJulI8ypSpX2cNnsPKVsESlLGf5Hlja8pa4zGWYaMnLXvryl2DUpYaAScxiGvOY5ROm MtGGzGYqcZnQjKY0DeLMalrzmt6Zpja3qUtsevOb4AynOMdJznKa85yv4aZ/0EkkdbrznfCMpyXZ Sc962hNJ8rzPPffJ/89++lNO+QyoQOH4z4K2baC+M6hCxYbQhjr0oRCNKCgXOiGJioeiFbXodjA6 wbE4Q6Mgvc5HucLRjob0OSVd0El7ldKWJs2JT7CSS7m1UpTO9KY4PWZNbZrTnspsp0AN6il9qhRU GEaoSH2gTwfQkv8RtTtOfWp1oipVL95GqGlM6meyqtXOcLWrmfkqZqoqE6quBqxiBata18rWtrrV N2TN5ls9E9fuzFUs8bhrfOpKGnTw9a+A5aVesxXYwpprsJkxrGLDhdixLvaxkI0sRRt7Gcla1o6U zaxmWamDUl5WV5uVzGdHG8nQRoa0qPWkaUOU2nSu9rUfaq1rg8WE2tTa9rZMgK1u3Spb1+z2t8D1 VG/BE9y/DPe4yG1acY2b3OY697nQja50cbJcv0xXNNXNrn6umxjtetc+3A3Zd8e71/CaF0fkTa96 2XbeV6GgvfCNL2rWCxb53oW+X7Gvfk2KX63s97807a+AB0zgAhs4bgCWy4GvkuAzLbgqDY7weR4M YQm3hcLzgi4fRoPhDiPRSF047jAsTGKkeDgqJU5xcU7MYseo+MUwPlKLX1jiT8T4xjjOscpmzGPm xhcbOg6ykIcMvR4bWS9ETrKSFwSNJdckIAAh+QQAFADJACwAAAAA9AEiAAcI/wDtCRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjwT/iRxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJ s6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVlyCzat3KtavXr2DDih1LtqzZs2jTql3Ltq3b hVfjyp1Lt67du3jz6t3Lt6/fv28DCx5MuLDhw4gTK17MuLHjx38jS55MubLly5gza97MubPnz6BD h35MurTp06hTq17NurXr1wxFy55Nu7ZU2LgvksjNO+uk3sCDCx9OvLjx48iTE7fNvLnz59CjS59O Pafy69iza9/Ovbv37+DDi/8fT768+fPo06tfX/4m+6/V48s3+b6+/fsKbwrYb48/QQH9FQTgfgT6 V+CABxI4kIILFiiggwJG+N+EAiXIYH8MAiihQRcG+KCFAwo034jyYaShfwt6mKKGG1ZIYYMwqqgi iy6+GCCNLIbYIoYT0ljjfzmeyKGNMuJnpGLuCYnjj0IOmZCPUP44I0M5TrmikylimSWRTdoYpT0k himmSx7qWGOVRUqppY8uLqnmQVWi2eaaCLH5ZYR2cinimHwyZ+KZWaJpYYUoegmnjDgWuqGZS+a5 5YcH7jhni3ceaelhSTKpqZx1VsrmjRBy+GmXpD6KaJ1apnkjnRTW5USfsPoCFBAAIfkEABQAyQAs AAAhAPQBIgAHCP8A/wkcSLCgQYH2BNhLuJChQ4YKF0ZsSFHiRIkULzZUKKBjx4obNWJ8GHGiyYoX RY7MiBIkRJApW9o7SLOmzZs4BzrJybOnz59AgwodSrSo0aNIDzo8SbKpS5krH7Jk+lQlx41SPX5k idWlSI1WpUYFuzCp2bNo06qlSWatW6QI3g58Stfr2KZU68bk2nWvXZh4+ZLlSziq4ZKAu9ZdzLix 48eQI0ueTLlyRTKWM2vezLkzXcQZ/Yo9XHhrQtB9oYZGmTcr66mJV1tULHaw59u4c+vevRAz79/A gzP2WFu0VuKnkdMOKXrk8c+qbY9Ojno5c5jKl6sUzr27d8u+v4v/H0++vPnz6NOrX8++Pcii7uOf l0u/vv37+PPrRyi/v///AAYo4IAEFmjggQgmqOCCDDbo4IMQRugYfLvVJOGFM+2n4YYcdujhT7xZ iGGEH5Zo4oko0pfPiiy26KKLFK1YkYwiLvRBRTdSdOMHPNqTo4518ShkQz+CNCSROCYJ5JI29ohk kkI6aWSRPu7Yo5Q2Vhmlkil26eWXHWaWD11jNlTmQmfKGOOZixW545I5UuljkHC6JKWTbs75JJM/ 3hmnkXpmOSWOf1YJJaF7jqjoouaxOWOMkKJpT5qTPtZnoJcGmiigT8qpKaZIZqokqHUeummWlxb6 Zqicfsroq7A2/1aUo5FKauatlI5Zo6Bzilook3aWCmynrPJqqqu9ApqnssX+maenhYIp7bTUqiUm jLdma2ullZZJK12p7vnrqTpuaey5goaLLqrkrgrkskquqiqv7gob67343vbttpO2GOmY3lpK78Cu eprouOvOmy64w7ILpbmcyrvwwtCum+/FGEO2L7fbskkpv4y5Wy/CyG5ab8LFJstwuwWT2mqmvzob bMkZ1yzhrGTWyvHHle7qsMoTNzzsyec+m/LMJqM7MtIwG/umnHJWK/XUVNu3scePcgypz4aWa6/F Tifcp5tUYtlqk0SKqmfZZxP76ZWIClr13HTXLWbO2uLq0sZPsf+dtpVbRmm24H8f2WTFQgtteOGn +v3wyVcSnrjNlFdu+eWYZ6755px37vnnoIcu+ugUjt5e3ainrnrpprfu+uuwxy777LTXbjuA3tzO HT+8U9S77xX93pDw9vDOj+/HA2+88S4lv5Dzzz/FPEjLF7989c8Tf/3w1x+//WLQZ+98+LqXL6Hw vxNffPDhpz9+8up7z77ywEdP/fvc129//tnvv/7/wdPf/aCnPgCa74AQal/0CBjA8f1PgetjIPkk qD/yGRCAFhxeAOvHwAv6L4MaDOEGEUjC9BTFgvLroAYdKD/qRZB+LlxgA5tHQxB+sIYcpKEIpbfD +q3uh0AMolInLIPCB/YQfkYsIhJlGMMXwnCET+RhDxeIPettT4VStKL2SsjF8wQEACH5BAAUAMkA LAAAQgD0ASIABwj/AO0JHEiwoEGB/A4mTGiPYcOCDBcifGhQIsWHDgk6tDiQo0aFFw+GzNixIb+T G1GiHCmyJEKVH1vKnEmzps2bOHPq3Mmzp8+fQIMK1Uly4saJMS16LHkUI8iLJIsihRjy6dSPGSMq hDmz6VSpQ8OKHUu2rNmzaIP+W8u2rdu3a6Vy1BoTalWjLpciVRlVpNy7VF1S7fv3ql/BewXCXcy4 sePHkCNLnky5suXLmDNr3sy589qqdPHWbdqXpV6vpa1+lZk6MVbVYAW3tue5tu3buHPr3s37NtCT HUO/DBwY+HDQS423jm3cZPC6yJ+zBDybuF3DabNr3869u/fvOFci/3YOHbF4w8D5ZrUe+6Xc89hN ZuUqH2bR9+fhtwfPv7///wAGKOCABBZo4IEIJqjgggw26OCDEEYo4YQUVmjhhRj219uGHHbo4Ycg hijiiJgdQeKJKKao4oostujiizDGKOOMNNZo44041pbhjjz26OOP3eUo5JBEFmnkkZsBqeSSTDbp 5JNQRinllFRWaeWVWGZJEJJcdunll2C2qOWYZJZpZkFhpqnmmmy2SdmZcMYp55x07qRHnXjmKZSb fH5ZRZ+ArqnnoIQWGmCgiCaq6KIqGuroo5BGKumklFY6UyaWZqqpd4x26umnoIYq6qiklmrqqaim quqqrLbqqo2bxgsqq6Ov1mrrrSQGBAAh+QQAFADJACwAAGMA9AEiAAcI/wD/CRxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjwTtiRxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP nyQvAo2JcGTRoShBKl3KtKnTp1CjShWItKrVq1izat3KtavXrzqFghV51F7ZrFPTql3Ltq3btxpF ApgLoGtZhODy5h2pl29fkXr32gs8mLBRuIgTK17MGDHOumNlgjM5GbDly5X5nswcubPnz6BDi7YK uSRduXPtpVZ9GjVkuq9HxqbJeXDJyZkr1659ebTv38CDC+9cWrbx2XVLF1fNXG7z5sthBsZ92zbm v4U58x7Ovbv37+BTRv9XDt05edapzyfPubu6YeubNYefT7++fc/jjztnTr6/cf7sVUcSdfBt15uB 9yWo4IL2CbWcf+VBCOB+zzV310G85XZgb5TJF1RjIIYo4ogkPpQTbK7tFxuKrq1HYXHRvbQddtpl t9d78DGo44489viYTDH6KOSQRBYJXJAqIWnkkkw26eSTUEYp5ZRUVmnllVhmqeWWXHZJVIlghinm mGSWaeaZaKap5ppstunmm3DGKeecdNZp55145qnnnnz26edEXgYq6KCEFmrooYgmquiijDbq6KOQ RirppJRWaumlmHr256acduopRZmGKuqopJZq6qmopqrqh5+26uqrnAYBBAAh+QQAFADJACwAAIQA 9AEiAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjwTtiRxJsqTJkyhTqlzJ sqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KVCXIp1CjSp1KtarVq1izat3KtavX r2DDih1LtqzZs2jTql3LNmvTt3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhwyUvIl5st63jx5C5 MpYJrmXlySsv24vMubNnj+BCaxYdWiTpkaJRk6x8enVq0pdbmx5Nu3Tp2SU120ttWvVM3rtly579 +rRw2rl5j+69+bPz59AbLt+d2+R03ax9U19d/eTt4MxRI//nHj62dpjTw2/3zr487vfas6+/HL2+ /frXu5+njn2++v+6cZedfALyR956vRX3nXIIBphegMxB6F+EBjqoGoG93afhhpFdBxyDBV7oG4TH WTggggkaGF91D/r3HYArWkfcgjGeaGGCJDbH4Y48miVcShiqiCON+sk4YorByWdejCK6BxuKKLYI ZHtJ5helcjn2qOWWXy0JZZNgqpjefgduZ15/S/YHY4s3ljnhl2ROaGWbSKrG5Z14RnSTle3xKeSY cDbY3XJ0qmnmioRSaSiUXh7o56FRqichZpRWCtdFaBoHXJKu3WaopgrSOd9rRTb4om0jeorSpleq +uWYQab/qd+SedZqK0KWDjVpri/tyuuvwP6kWLBUEmvZSLcmq6xFO+G62LLQRnufsdRWa+212BoF gE/b/tRttuCGK+5NAJT77Ujn5nSuuSaZW65I7JaU7knpvgvvt/WOq+++/KKEr1Du2vOvvwKjK+/B JNkLb8ILF8xwvxBHfNhF/25r8b3dxuuwswUP7HC7DX8scsgGk+zwxSBLq/LKtlacscgDd8sxyh/P 27DHI+eMr8b22rwty0AHzWPANcNMNLIHJdxzyQgXzbS7PD+NsMIFC2311dDlu/C6KXG8tdNN4zzv 2FIz/PLCWKetNlbkhg1zyTYTTPPZb5NMttt238y0xHz3Nb0XxXjHG7WOBaHLs8I4C0y1yfUivvjO Ja8t+eRPARZ3TZer6/fmnHdOcE+Z2xS656SX/lNAACH5BAAUAMkALAAApQD0ASIABwj/AO0JHEiw oMGDCBMqRAhgocODDR9KJBhxosWLGDNq3Mixo8ePIEOKHElS4b+TKFOqXHmy5EGW/wbCDAmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJPWdGlwpkCnH5VKnUq1qtWrWLNq3QqVKcSFFb2KHUu2rNmzaNOq XTsWgNuwYON2DECXrr26dvEOtCuQL9u/gAMLHky4cEi4EhEXVHwxwEHHfff2hXyXsuHLmDNr3syZ I9yKDd/acyvwLWjSo0tvtCw5smvHsO92nk27tu3bGYeORg06te/QA4GrjhgRKky8lJO3jh2bq/Pn 0KNLn069+k2Kw1X/9p26N1zjLFm7/67sF7J5e9bTq1/Pvr17oYezb+8enLtwjuJlv14+Hrf//wAG KOBX2s1334HzZZSfcvsRlN+AEEYo4YQXDWUadtoRtxtqG2b4FEsyhfdYa5Gx5th7KKao4oosXkUS YxTGKOOMNNaYmI045qjjjmvp5l9XFbYo5JBEFskej0gmqeSSTM4GY5NQRiklQRZeSJFoF5n25EOK AfnZlcUZKeaYZJapHoy9YbTljU2BGByWHPZm5px01mmnSh2hiSGc9S0GpnxWwskbl9wVmOaUiCZa Y5Uc9lmgfIU+Wt+gkN7nG1SW2lffnZx26imL8YkWFnF8KjaqqI6GduGaEDV6KKuKxokqK5JfTtpn pobammutamqa66zABsvjob++ylCqvtIHaaQKIfirsNBGi5luWIJ5apzHvknataSeph2m1YaL2qfk lmuumB7BSqhEXk507rvwxqsUYOomVC1I9Uqr77789uvvvwAHLPDA/cpr8MEIJ6zwwgw37HB7BEcs 8cQmPWzxxRgjTPHGHEccEAAh+QQAFADJACwAAMYA9AEiAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNh/9y6tzJs6fPn0CDCh1K tKjRo0iTKl3KtKnTp1CjSp1KtarVnTezat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt+5N DHbzdsygt+9bT34DCx6s8qrhqp4OK17MuLHjx5AjS1ZKWCDgypgza644ubPPxJ5Dix5NurTp0z0z X97MurXrgahjy55Nu7bt249f697NOy/u38CDCx9OvHPv48iTK1/OvLlzhcWjS59Ovbp1ys8FX9/O HXd27d3Di/+n+r28+fMx+alXb289e/cD2QuUP59ffPv14+t3jx8+Qfj8tfdfe/gJSJ996xGoX330 3efgfApCyOCCEB5433sAFohhghYGiN6HNhU4oIQCRmiiiQdqKKGIJRrEIokiIqiihSXS+OJ/Gs6o Yov9DWhjQSym2GJ+MIJopEdO3bhjjQYOiWCTTEI55JQUjugklE/2yGSPNy7IZYVbAnnlk1JW2WSW Ymp5pT3jtenmZB7y6OWZPmK5YowJTghkg0vS6aeWZJKJEKBhflnnfmHuKR+aMi4a5ZpvRiqpYkpe uKOaURJ6YpdUFkminYFmCmZ/DYr6Z5llhiqomYQGCeansE2PKuusOV1U6YpzrsllgIJy2uWSMRb6 aqtrMsjhqMgeOiyqUxI7Yq9HRqtRkgcBC2uwytrZKawU9tnrt7gS6a2y7z14KbmYNpummERCSuu7 kdpabZWrFvvqvY1uGGSen/qXI4+NAmyplVKW2y6/BDp6MIcAptnwwQRLixEbElds8cWbOYUxW/B2 3ObGIIe8WUAAIfkEABQAyQAsAADnAPQBIgAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48E/4kcSbKkSZEgU6pcybKly5cwH56cSbOmzZs4c+rcydNkzJ9AgwrNCIBj0aJDLSJN yrTpTwBQoSo1GHXpUKkCsTa1SlCrU3tWo3blqlXqUbBoH3ItWJaiWIVrv8pt2rPkwbgT1y7FC7Ms 36cIvW4Vuzfr3b2F/+YtLJFxYIp1I0ueTLmy5ZN3qWI9C9bvUa+O33ZG+jZx2tKeu6LljDp11tav Pw9sTVow6di1XScWDTu26ricqa4efjY3brajyZ72vTyt4d+ne7PeLPCy9evYr3usGly28+DOZ4v/ /x7etGHq44cLL47c8Xnx5m+bV4+8Of3u5Ofnz6z3OHT2AMKX3n3QEXhbee0daKCCz83loIOihbcf bt5JmNxsVXWWHn7ucadhfQdmyJiI8JG4nIf6jacghwK+5yKFH7IF2oaqnUjchAh2+B6KNw5I4Hkm xvjgkETWSKN7GFq44mE44ufjazXK16KBUz4npZHgUcjii1vSZ6GQLoY1YIg3dimmjj0KCJ5yoUlI lmJFximUclyOqaSKds7nZINi+mhmkxNeSWV9deoJaJ8Ituemnf+lueePfDqJJHmUDhqlnJhupRmD vQnZZ6e8ETaWcaMRaqWop24mnZXMjYiopaRe/+gqqRFemFysDe6oXml5Mvohb0+WmmuGwiI2aabI JqvsRnAu61CzzkYr7U+UTftVrdZGBG22K2Xn7bfghvsPt+SWay5Q4qar7ro4nevuu/BuxO689O4U b0vbDpnvvfz2GxRlPGJoW5sC5+aXjGYZiXDCDNWWJJT+5ScisXyW+Jln6CVE8bMzwuWasBBzjC1E eo38Ur0op4zZVAp3SHDFwL2aqHAKaxzywRU3BxzNlC55p815qfiXoSM2plF/ufqrtEB7HG0qwSmm qDPPXy66kGmsscrqsUj3nPPOjyEcMc/Q/rlv0sVGZyzIlYZKq5qtfrx0UgDzSqPWXtpKMZkLC/9W cJaZ6cq3q6PKLDieqRo+KszBKk4z0SYHFqR3+nW9JKIcclqlypx3LhmdY2tOKOB8txz2mGYxPLXO odaMdplCt7Ve6mxOTnXVWE75KGEdH/l3jCVjXCHRqPM+kOfIJ38T6PZxN2nUAZseeLCjbx2wobcf rjXXDWWJZNenH0r99Iy/rjriX6r+Z+NFKe8+uBcxX/Tducuf9Kem4k7/iz+W7nrOeGPQ+AoEqfTV DHTr6171XpY3rw1LfA+M4NymhSJU8e95tFlTwRLFPFuFjU0EXBCwpre2MxFraG4b262Y46YTfixy 5GvV4kDWO7Wx0G1rUhWuJsjDqxCFW2f737P/ekhEeFVrWUEMn7OSOEC4FLFb74uidp5IxSpa8YpY zKIWt8jFLm5HgV4kGZHOlkQmhrEviLmW5PwWNIHtj2TC22DhLka7NIbMP8caSxOd+CDH5e9qTeyP GbVYt4dpKnvxu1seASlB3IGtZ3b0nf5uVpFBpsSPQjydYvCCFyl6kiSJZE+xUohHHQJPh7iKmZQ2 Vr3f1NGNXkJg48ynyDQxrllZSxvrvofKiNltNaTE4QyFqcvyvDJuJtzhGUMymQAREISF2pruflY/ n5FNUeUDZv4YGDvZeU2URyqbjcLEv9fBCoKxnCb9HlVAbpKuUvb4pDwTuUtJWZCOucQnjp6ELL2q fa9tKwQfQIE2uhEK0IWHwZ8+A2SbhaHTbHOEZ5tmJSgAGuxOkVzmQQICACH5BAAUAMkALAAACAH0 ASIABwj/AO0JHEiwoEGBABAqtAegYcKECx0+HPhQIsOIDC1CvLiRosGNExdePAiyYMiRHDV+NOlR JMmXCB22hNgxY8OYJG/OTClzos+aQHt6LEl0qFGKKl2WVLjUIkeWImkKZQmy5sGrWLNq3cq1q9eu /8KKHUu2bFiaTI8+Tct259qWb+HCPbl0pcu3RQlaBTo3q1WUaDGivHvSb1q+PpHKzYsXsGPGgx33 bUu3bVS1hS1ntGe2s+fPoEOLHk26tOmyiDE/Vh24MmS5qy9H7ti072vZSu3+rRvYLd/IMDfXJryY tXHKgxnTtq36ruTGe4EnPE29uvXr2En/TjrSqXedrWP2/5b6UabNqOal69WJsyn4q+kJm++tt/h2 4s6hbj4vO/3eqY3xZ1Nl/PkX334GgudfTpJ9V59wOmUn4YQUVtjZV139heGGWGmoH4cghijiiCTa VeKJKD6YolYWtujii6WheOCKG3r4IY045qijiTv2yJWNOMIo5JCi+WjkkUgmqeSSTDbp5JNQRinl lFRWaeWVWGa5I3bwaZVZj0Cq+KOWZJYJm5VhjhkikWxehyOQX+6YZn6wxenVjByy99V/ik2poVMk znmioHRiSKiZSnIZXJeHjigooY3qF6lJkfKJk5+LDkrmpDdi2OanpzmKEaDzBYhUeDxVpWpQriXY 3VSlEv9InHcz6dndqeLlKuBTIc3nqnhSBbtfgb4uR5WuRB1IKnvx9cqsgmi5t+p67x2W67Kq6oro lteFpxyvxbEV7XHJqehafa9VhNtsscX1IH3GugtuarMeNy5y0VF62beTqbXevuZC1xzATMFbZ7kK gaowm4mda627RTU8FHe08fbYt8EWlhm90O0WUVWn3pRvawBmfDGsBZes3nkW89tfT/kOqHFSzqrM HHKTabTqdAv3/KLEGN/627wCB6yvyyKvBtnGx+I8rMwgt9ept+Q67Bu7mpXb8sDtRr0uwjvR91zX YyOdmc9olxWoWwLXlTPbVnvsMrgPQxzceGWLGW/RYvL/HXds9/Id8NZOkx1uu4YnTrbbc8u6LZbD vRr4bszCrS2gAuoM7cdJD4h1edMCu6vWm1++t+QEflc6qqV+DPrM02LeIMxDZ776Ys/qiS3ss4uc ++PcWlcip8A/CvydWhKP6ZJpNy/h8MeDaHz0HdqKJvWdGul889h37/334Icv/kCKjm/++ehrv/36 Lxo5qfXpHx2/jCIqj3z9839fvpd5ri1nhu9q1pn4V6VK4WlsNTpS7dS0IfZJaBYOFIv7+icqKS3n TwPM39c2uCcFVlCD1ONSrERXIMlRay3FehrLBKMs3+EKQe/Zm51g9bt5JYhVyHKh53JYrV+ZSFgs m9EI/3c4xBYCEWYkrEgNd/jCmgkkglB0XrIIlpL8RC0vBmNh3m71rot9CIg36xi+Dge4wrXNXzmp lqnipa7FiS034hpj0OjUxpJE8Y7Cw5/TlNg5FT4Hi3AkGuNYOER5nY6Ni6ua3o4yOdFFTGeGGeO6 kCYzwMSsjGdMWR9ZRRfZgbBJ2KHkAnXXr14FEmjhaqTgAnnKREoSbJj8W8QYdLfEIZJwdZIhI+WI xkGaEY/ANM0HZWW1wxEui/1JJc6KyUqwyVKRxuTiM+tmrKH9rZW4/JIu45hJvw2uX5/sXuuSqEZl 4Y51+vqjrVjXunFSy2RG+xW/ZJdCaTKRYibMHKWWuEXJfSqlntnyZwmFVkgw0hNAowsnk/an0L6V SXn2a2iUgklRIkk0e5CDn6Eu6r2KerR9HA2pSLf10ZKCZqQoTalKVwqigAAAIfkEABQAyQAsAAAp AfQBIgAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gIwJQOHLjyJIUURI8 GRKhSpMtD77UODPmQAA1Bea0ybOnz58SUe60pxJn0aE3iSpFmrAmy6AVmU6UavHlUaM3cWbVujJp R6ZIrTakCrSs2Yf/0qpdy7ZtWqg6m2IVGhfi05Qylf4kaxdoUYN09QoWzNch2IWFKbpdzLix48eQ I0ueTLntxZKYdXJlORdrV6eDV2rdvFSvZ6MzUWvOjJl067+qC54mTZRrbaubPd/GzXq1bN2nV//t +tmr79i3f9sOftK27+Sim7uePX257rPYs3PMXDoubcLFZQv/F2+6NOekget2Ny/+e/jBOc97Rww+ fXvu8I3Pt4/6rvfr4M2nXn3o4WecfwPSddeC6zGo3YPaVcbWeQymZx906vFXF4UNBpghga8tmJqH tUXHmWrObVWhfrsRhlyAKJIo1nvD1feiguixSOBvB3aII44D2iPhkEQWaeSRSLrFIZAejmighuUt mWOCU7LHpGY0AraiUzWuSKWAofX4o34zVtllleT5qOOVooFopppBJinnnHTOiVFgTFoI2HofetUb h2CeOSab+V0YaIdkvgklovkd6mCQMCb64aJehkmoojuyd2iYEHYak5FNujcamdTlNuOf3QUXZGzM jSdUio9i/xgjdAC2iCeAsz6n4q4hEqfcrjzeyturT/IGqarmlbopqwLV6eyz0Eb7T0iJeWrtXtfS p12ZhhUk7bfghisZtdmWa2212KG7XZqIpSikuPDGC6+59NZr7734RiTvvvyqle+/AAcs8IP9FlzZ VwMn7JO6GbnLEMMitQTxQxMrfFZ/nMrlMMBhWcztZdp2Cym5cLmk47ojW8wTqCSGrHLGJ/9bsckk 9ZXyRzP7mnNecRrs87cZAgerTKaW2OJzzK76nXTEbkWrc9Rp+dpxU1vXK9LudlZd1U0fHbXTtMI3 mtBd19qq167puhSuY1v9q9toM93sz3Qz1rCYkupcHqOO5v/dW6b+Gdqkrzv+/TecfX6paap9b5qm gmXm2ejkzU1a4Mix6gnl4ZUK/vJHLGt+454Ccu6qn6FhnDjTgWdFuox6c/cUa7kGfqPmhf83l5kj Wv54gZ2pKKiYtTvpN/BQbwj44HU3b9mdePMcu/KS45m69GzWiGWPiufOOJ+ZwlzimKWD6bvr3IM/ OJcZS25+6rAd/z7qiD+68+cJhR799dNHiWni3Jvd/46lt+4ByXCN45PgtjQl0xHqTPPDHZUotT40 TVB+fJPd8vTkvA6+BXp9qlXclLc2q9mPaPiRm65mgyH0ma1oexOgaZaGNWOBSFWyo+H4hgY29glr hVkT1dfBuvamNv2QODlMIZY8h78mloxiU3EizqRIxSpei2XYitgTrQgyLnrRIR4MI5G+KMYymvGM aEwjuL7Ixja68Y1NxGKbaJIdNdrxjnjMox6P9LpfSa+PFINbC921x0Ia8pCIFBfCXgcamtmsfjeD oyQnSclPFelp2puhdGpYtvZtMH+JDKUoR0nKbz2wPQWE5MaUCDlClvKVsIylLB1zyvdUUHejwt4A XzLLXvryl6GsJZokCL5Gni9W7wKmMpfJzGgFBAAh+QQAFADJACwAAEoB9AEiAAcI/wD/CRxIsKBB gQDsKUyYUKHDhg/tQZQYcSFFixMvOrRYkSJEhh0VHhxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzgH ftS4cSdPnx4j7szIUyNIjBUb5lzKtKnTp1CfNotKtSpUiQAaEl2YtWdXrFy1Zv34lejYsl+xkvVp ta3bt3Djyp1LF+bGu3jz6t3Lt6/fvnUDCx5MuLBhwn8TK17MWO/hx5AjS578trHly5gza97MubPn z6BDix5NurTp06hTq17NurXr17Bjy55Nu7bt27hz697Nu7fv38CDCx9O3DHl48iTK1/OHG7x59Cj S59Ovbr169izax/evLv37+DDe4nfTr68+fPoAYtfz769+/fw48ufT7++/fv48+u/n76///8AErff gAQWaOCBCCao4IJPBejggxBGKOGEFFZooW4MZqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4osw xijThTTWaGOEMuao44489uijfDcGKeSQRBZp5JFIfjYjXvwkSduPUEIVEAAh+QQAFADJACwAAGsB 9AEiAAcI/wD/CRxIsKBBgfYSKrTHb6HDhxAjSpxIsaLFixgzasR4sKPHjyBDihxJsqTJkyhTqlzJ sqXLgRsh8muYkCZGmwpn6oyZ86FOnDyDLpyZ0+ZPhkcdJhXKtKnTp1CjSp1KdQ3Vq0KJ1tQIlOHT rkax3jRKs6tXn2LTql3Ltq3bt1dZni27s6bWsHW3Kr07VyvShnnPCs5bt3BPwHbpksWJuHFEsDL5 Ag6c8KXly5gza97MubNnhEzL6vWK97DPo3hFb2WMVm/pnqsPqx6NGK1js4JhD5VNG67v38CDCwcu V/Vr0qaVKo+dmKhfsIRRh2WOfPRf55Dn9p2+e3n1wQ4/i/8fT768+fOdQ/+s/Z09e929uQ997xp+ UfDHWZ/uLlp/buvx6YbbcAQWaOCBCDbFWn74tSYgeNbRB6F87jUYIXz+1debgwFuOCBFjyQo4ogk lhgRSwtGtxhd3c0321+J3YdhjDDSeF1uhd3lF4Ar2leUjrMtRRN6RBZp5JFIpmfikkwC2OSTUEZJ olxSVvmVRElmqeWWXG5p5ZdghinmmGSWaeaZaKap5ppsggmAQ29CFOdTc0ZUZ4l3ytnmnlEB4Kef QuX5Z56+AZqQofYMmqiicP7ZFKFM3fmmoBNBKpGlhzYp6UOY8unpRZ1iRGmmwiFqKKGomripnpdq 1GmoBYb/CuuntLK6kKOJ5rronI7iSqquuyqE67DC5hrnsKYiauyykI7a6LHG+srpocoGeyuxmTI6 KbXb8nptt9wKiyyv0lo77qLcknsstsDCSeqk2PZarrnv7qpurQayNOi22UKb7a3T1vtvsQNH+yuw /LoLbrMBA9zvrwy/6vCyBS8MsLcEo6twsd5ifHDH9XpcMcJ2hsxxuyKDrGvCCdvT5ctcrkqxvfBm LG6y8mbMMsk3A1rtygP76qzOPLd7MarSqjyzxQS3XLS9JO/7dJ0qQ4uxolcbfTGzJ1NtM8hMG1wZ zGQjKfPOnDoN9MHiRn3yx3J6DbTcWjuLttYQ06232/+2/2y1uxC/PXPgX7/998hZW2ox2BPvvbjO b5YteZFnF+213YQjLvjehTvscaqNW8423VNv7rbfNmeu9M4ph+4v66bDDfjaXBNte9ZwT667eYKe +m241E688qk494wy8evKnLepdp6LsNAK/8xousZrO/zd1x6PfPLG/07v3EL3ajvbPFftc+rQCxxt nLu3Lx6+bM3qqlTyB1f/6Eu6r/9H8C95P6j0Y9L/SNe/AhrwgAhMoAKpQqUFOvCBYtmfBDvilv+J KiYWxEoGK7JBOvGkg8Kz3wAhKJVS+I+DH8SgBitlK/LNzlb1mx4LUajCb8FKZGkLivximDoS7gmE M5zfVf9GGEIh4q1kGblhCntIERw2ai08dKEP3yIXdnEPbeK7mvScp8XXbS9cxYOatfpGPW0h72jV klcYmTiuK15vdF+kXg+tGCwZCixnwAOXudJ4xsGp8V4um6AgYRKoptFuaSjjWyI1p7nVrQ12BWsb Ih05rdYFzpKu2xylIha7m12yk6t6HeIO1zDRpZFoTpxigqSWuUkmLl2Os17yzudIUUpNaag0Hbkq 2bmoybB34htZ9Z4FySMW826hvCPNFClH1dUNlXZU5SphuLW8zU2KuAzaxhhJyk/O7phGUxb2PmfM UiqSnI7r5DYnOT6a8aubzMRkNk0pzbboy5D+EqY+5Skmuk/W0mSMzGRAC8dPfeIvoOgUKCL19M9W Xg6g7GxnQr9pukFaNCAAIfkEABQAyQAsAACMAfQBIgAHCP8A/wkcSLCgQYEA7ClMaC8hQ4YLGyqU ONFhxYsRMUqEyFGjxY4gM1qMGHJixo0XS5qEiPIkxZcjX7qESbPjyZg1U2o02bJnTJsuRz7MSXLl TqA4b+qMeLCp06dQo0qdSrWq1atTGwIYKnIrxa1ewSqt6JUn2Idlg5ZFy5ar27UY09LUGjauQ7k+ zf5ciJfvWrhdZZ6VSXdv4ZVi/ZL9Ozfo165cv/6VyzIxS7JzE2PdzLmz589ReYoeTbq06dOoU6se fXm1a9GtX8ueTbu27du4c+vezbu379/Ag+eODTyx8OPIkytfzry589Oen0ufTr269evYVYPezr17 0+zgw4v/H0++PGnv6NP/2038dHvllFe/Rz3/dn3c982r7gs+qf7/zuVnVnD1tTYfUAPOZBSB9NkH 4IKuCShbbGcViJKED+oX3U7yMegebB8qKCKIHgqHoXUnnrgfhRMS9px6MG6Hn2WASfZWW4qlReNk erGFmI48DvbjRmHhqFhPRwp52GJakWScZTZC1qNfBuIlpFCTcQTXXYYxSdeUmW1JYoKwFVkUlkYO mWOUR2Yonkp7hQTnY3mp5JGLcyIFoVBF9UlkaXEeJVKdKRmI5J0IQlhTZIE6OZZgS+1J1J9j/niZ WxcSOiJONfrnZn+FQtnWR5HySaRYdiplqJ9dVrbUUCAN/0YhqqUuCOuitC720ap5WSqpnrHmCuml kd7ZUoUujijoY6Q2Spise8qq4qfJpXrsgHkOSqyfiI7pLIIl3cotnrWCq+2kj/7kKquSdqtqsY0d aq1NpnJoL5l0NqsppNwmyhe14c2Z7r6mfkvuuJO2+uu57PJqcFxnluuuY+wa++7FBOOLscXAkrau ucxmKvDGekIM8HVXxuelj0ti+mWYYFYJpJbxNlnwki/PWhdkH0cspWC0Grcyh0q2rKaSUGImYtJg qhWZmjBZeS6pORO9I9AsJ3uybBv6Nu3WYP8m4LRfhx1cjGh3Nl7ZZrft4H60se323HTXbffddyeD t9tp95Ptd1R4/C344IQXbvjhiKe99+KMN+6444lHLvnklFdu+eWYD/745px37vl/mYf+tyikl266 KKKnrvrqrPf9+euwxy77ca3Xbvvt6bWD++689+7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTU Tz779dhnr71p1Xfv/ffgb7b9+OSX73n46Kev/vreS8D++/ArHxAAIfkEABQAyQAsAACtAfQBIgAH CP8A/wkcSLCgwYMIEypcyLChQgkOI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybJlS3sw Y8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSpTJdQo0qdSrWq1atYs2rdyrWr169gtTod S7as2bNo06pdy7atW5ph48qdS7eu3bt48+rdy7ev37+AAwsejPet4cOIEytezLix45kZH0ueTNko 4cthK2vezLmz58+gI4MeTRox5tODFahWbW81a9cxWcOUPTu27dWtZSqoCTs27da4Xe+2fVu379e9 deOePRz4btrDkzNHvhz48ebCnVuvPb359u/VoTv/9w6e+HDU6LMWJc89N3fo3rGbb+9+pvz60XnT jF/fPXn2xNnHX3kA9hcgcwEO+N59BcLXXnTy3Yfgg/SVZuGFaAEoYX7P9bfhe8btV5xxGoo4Ym3s Nagffii2uKJ9IeZH34Ad5lagjTj+h+OOILIoIYZABllTRtlRCGKHOiI534EJGgihgte9RuJ+1VXY o39YaicglDL+SCOWNypZY3EcxkjhfemluVeJ3S2ZJI8yWjlehTpayd+d0xlonmxxdumkTV4u+JuH R/r3m59v5mgmocSp6ehdbGaZ5ZtjxqnnnyE2CeOJPHaaqY1FIrqpifhlZymjZXJZ6JSK3lYko4/G /8rSei8yOKqmV16aIpMs3jqmpL+O+qufE/JqJKGBLrldssr2WemMxgop7bRERYrnp8cGp+2hvMHH ra9tXjdeisGRKCWC0s2Ja6cbngtelXVqWaq6jNZL7b345qvvvvz2G6Ro/gYspKwEoyTwwQgnrLBi AC/s8GgFR1xVtQ9X3JbEGEeVbngRjqucb1r2Jp2p5j5JrrvzFovdtoO+6+3JHkd5HKkrB5ouvSpX 6TKbGfdcEa3ZqtzrxxOeeuPQk94Ub8rlYQroh0hD+2LUtub6bKbxQS20nRZ3rdi1ZNIpopKSyrku saQeSGyNwV7aI9hOu/3jn0YjyyTUlq7N69Fe9829E5Gshh13i2zPnCfNoRq+d+Jguqhcy2izC26t t+6YqOPxVv0lsCb67DlKcFs+eNJ6Ln1s2VJ/qner2C4K99Iqii0sjHfqjHPka9vu3ue8kxR64aaT vmvryQ7PtauwpZr24+VyCjugd9NMO6vD19w8iiTrClPv3B8E9NDOVo6p8cejuvzzYPMpPrRVl956 6pH2mv7sdlsdtd/4u7WxeMWWj/1zy7kZ0gBIQA1dT3IrE9erkMUxyPHvfC2j06ECqLrAgeqBkntf /jZok4AAACH5BAAUAMkALAAAzgH0ASIABwj/AO0JHEiwoEGBChIqKKhw4EKEDx0ajIjQXkOFDzEe jEhx4cWGEy8S9DjSokOOH0FWlKgRYsKQHA+aHPlyI8OaLjOWlMiyZMuZFTsylEm0qNGjSJMqXcq0 qdOnUKNKnUq1qtWrWLNq3cq1q9evYMMS/Ue2rNmzaMmKXcu2rdu3MtPKnUu3rt27ePPq3cu3r9+/ gOvCHUy4sGGBgRMrXsy4sePHkP0enky5stbImDNr3sy5M1/LoEOLVuq5tOnTqFPjjbnSIkqVGoWe TPnyJ06crmnfnP0at8uTPCEC/y08qMriQCkS5537tvOaGD0e3zl8purr2LNrb8w6uXLZwYGK/w/O 2vlE8jTRj6eesbvr4eVjur8dPnn91vbtf7+Pe7+97QAGKOCAZXWnk3ju4QceezyRRNJQrZWn4Hr4 mfSgUA6Ol6GFOx3IIXVByZTggx+qB+F6DxGo4ooscsYhiR7mR9NPzRnY4IvnRXgjgs2dGGKMGZL4 Y4g7yudjiSfu19KS93lH338tRinllJIFuaOOPi5IHmwrKeekbEBSqOFMQh4o5IcbdjnhkWeaSCSS PdqEZYpU1mkndlNZWaONWYKonoQoXhldmWIq+SaZh6KJpHS25diTnGMa2aGIf45m6aWYYsUnlhUu 6KWMMQY6p09XOuphfxAC+p6qMjJY4ZqIJtqaIKefZmrrrYYFRqurzHkKKYZHtkqobTQuh5Kfr20Z J4+vLpdTfbCBFB2zs1W70p3YZusZrtx26+234IY7la7ilmsuU9qmq+667Lbr7rvwxnvWufSK9k69 +OYrmrz8ZvdOvwAHLPDAAL/zL8EIJ6zwwioezPDDEO+l78Rt3UvxxRgPFvHGdznM8ccgl5XxyFlZ TPLJKG8V8sostwxyyjDHLPPMh51B880456zzzjz37HPOLgct9NAA/2z00Uj//ETSTDfttFdERy31 1Hc+bfXVWGtM9dZcd61dQAAh+QQAqtDJACwAAO8B9AEiAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAj SpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNh/Zy6tzJs6fPn0CDCh1K tKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih0b9KbZs2jTql3Ltq3bt3Djyp1Ll6zd u3jz6t3Lt69fnnQDCx5MuLDhw4gTK17MmOHfx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hT p27MurXr17Bjy55NuzZI1bhz697Nu7fv38CDCx9OvLjx48iTK1/OvLnz59CjS59OXbTt69iza9/O vbv37+DDi0EfT768+esAzieOor494/Tu48ufPxI+fZrV8yMHoL+///9X8QfggAQWaJSABiaoYIII LmjXfRBGKOGEFFZoIUUBAQA7 ------=_NextPart_000_000D_01C6F167.8474CB10-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 15:51:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYUW-0008H9-K3 for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:51:16 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYUR-0005Fy-IX for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:51:16 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2D443980CC for ; Mon, 16 Oct 2006 12:51:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id C67A84A4196 for ; Mon, 16 Oct 2006 12:50:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 714771448038 for ; Mon, 16 Oct 2006 12:50:14 -0700 (PDT) Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by hermes.tigertech.net (Postfix) with ESMTP id E02B71448004 for ; Mon, 16 Oct 2006 12:50:11 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BF2F526E3C; Mon, 16 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTJ-0005rc-Kv; Mon, 16 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 16 Oct 2006 15:50:01 -0400 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-specification-03.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Specification Author(s) : P. Calhoun, et al. Filename : draft-ietf-capwap-protocol-specification-03.txt Pages : 107 Date : 2006-10-16 This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol. The CAPWAP protocol binding which defines extensions for use with the IEEE 802.11 wireless LAN protocol is available in [11]. Extensions are expected to be defined to enable use of the CAPWAP protocol with additional wireless technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-specification-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-capwap-protocol-specification-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-capwap-protocol-specification-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: <2006-10-16114111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-protocol-specification-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-specification-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16114111.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 15:51:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYUZ-0008Jw-8M for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:51:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYUS-0005GA-Km for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 15:51:19 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 14F31398077 for ; Mon, 16 Oct 2006 12:51:12 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 420284A4612 for ; Mon, 16 Oct 2006 12:50:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2EE5939807E for ; Mon, 16 Oct 2006 12:50:13 -0700 (PDT) Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0B1A9398053 for ; Mon, 16 Oct 2006 12:50:10 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1B37C175A4; Mon, 16 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTJ-0005rf-Ld; Mon, 16 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 16 Oct 2006 15:50:01 -0400 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.334 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] I-D ACTION:draft-ietf-capwap-protocol-binding-ieee80211-00.txt X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : CAPWAP Protocol Binding for IEEE 802.11 Author(s) : P. Calhoun, et al. Filename : draft-ietf-capwap-protocol-binding-ieee80211-00.txt Pages : 59 Date : 2006-10-16 Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. The CAPWAP Protocol Specification is defined separately [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-protocol-binding-ieee80211-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-capwap-protocol-binding-ieee80211-00.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-capwap-protocol-binding-ieee80211-00.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: <2006-10-16114947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-protocol-binding-ieee80211-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-protocol-binding-ieee80211-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16114947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --NextPart-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 16 19:41:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZc5Z-0001iy-OZ for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 19:41:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZc5X-0005H8-3D for capwap-archive@lists.ietf.org; Mon, 16 Oct 2006 19:41:45 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 56900430EF4 for ; Mon, 16 Oct 2006 16:41:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id D2D7E4A452F for ; Mon, 16 Oct 2006 16:41:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C8A1430EE5 for ; Mon, 16 Oct 2006 16:41:03 -0700 (PDT) Received: from web60319.mail.yahoo.com (web60319.mail.yahoo.com [209.73.178.127]) by hermes.tigertech.net (Postfix) with SMTP id E854B430EDF for ; Mon, 16 Oct 2006 16:40:58 -0700 (PDT) Received: (qmail 13518 invoked by uid 60001); 16 Oct 2006 23:40:58 -0000 Message-ID: <20061016234058.13516.qmail@web60319.mail.yahoo.com> Received: from [121.133.79.100] by web60319.mail.yahoo.com via HTTP; Mon, 16 Oct 2006 16:40:58 PDT Date: Mon, 16 Oct 2006 16:40:58 -0700 (PDT) From: Behcet Sarikaya To: "Pat Calhoun (pacalhou)" , capwap@frascone.com MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_50_60, HTML_MESSAGE X-Spam-Level: ** Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1421249951==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============1421249951== Content-Type: multipart/alternative; boundary="0-1004315520-1161042058=:12855" --0-1004315520-1161042058=:12855 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Pat, =0A=0A=0A----- Original Message ----=0AFrom: Pat Calhoun (pacalhou) =0ATo: Behcet Sarikaya ; capwap= @frascone.com=0ASent: Monday, October 16, 2006 1:02:43 PM=0ASubject: RE: [C= apwap] CAPWAP for 802.11r=0A=0A=0A=0A =0ADIV {=0AMARGIN:0px;}=0A=0A=0A=0ABe= hcet,=0A=0A =0A=0AI =0Abelieve we've discussed this idea a few times, and I= am still unsure why we =0Abelieve CAPWAP needs to define anything to suppo= rt TGr. The current CAPWAP =0Aprotocol is sufficient to support the upcomin= g standard.=0A=0A=0A=3D=3D>=0AThe basis is there but we need several extens= ions.=0APlease read the draft and comment, then we can make a more informed= decision, I think.=0A=0A=0A=0A=0APat Calhoun=0ACTO, Wireless Networking Bu= siness =0AUnit=0ACisco Systems=0A=0A =0ARegards,=0A=0A--behcet=0A=0A=0A = =0A =0A From: Behcet Sarikaya =0A [mailto:behcetsarikaya@yahoo.com] =0AS= ent: Saturday, October 14, 2006 =0A 8:33 AM=0ATo: capwap@frascone.com=0ASu= bject: [Capwap] CAPWAP =0A for 802.11r=0A=0A=0A=0A =0A=0A =0A Dear all,= =0A I submitted a draft on CAPWAP Roaming Protocol in =0A 802.11R Domains= .=0AIt should be available soon at the following =0A link:=0A=0Ahttp://www= .ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt=0A=0ARegards= ,=0A=0ABehcet=0A=0A=0A=0A=0A=0A --0-1004315520-1161042058=:12855 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Pat,


----- Original Message ----<= br>From: Pat Calhoun (pacalhou) <pcalhoun@cisco.com>
To: Behcet Sa= rikaya <behcetsarikaya@yahoo.com>; capwap@frascone.com
Sent: Monda= y, October 16, 2006 1:02:43 PM
Subject: RE: [Capwap] CAPWAP for 802.11r<= br>
=0A=0A =0A= =0A=0A=0A
Behcet,
=0A
 
=0A
I =0Abelieve we've discussed this id= ea a few times, and I am still unsure why we =0Abelieve CAPWAP needs to def= ine anything to support TGr. The current CAPWAP =0Aprotocol is sufficient t= o support the upcoming standard.
=0A

=3D=3D><= br>The basis is there but we need several extensions.
Please read the dr= aft and comment, then we can make a more informed decision, I think.

=0A

Pat Calhoun
CTO, Wirele= ss Networking Business =0AUnit
Cisco Systems

=0A
 Regards,

--behcet
=0A
=0A
=0A
=0A From: Behcet Sarikaya =0A [mailto:behcetsarikaya@yahoo.com= ]
Sent: Saturday, October 14, 2006 =0A 8:33 AM
To: ca= pwap@frascone.com
Subject: [Capwap] CAPWAP =0A for 802.11r

=0A
=0A
=0A
Dear all,
  I = submitted a draft on CAPWAP Roaming Protocol in =0A 802.11R Domains.
It= should be available soon at the following =0A link:

http://www.ietf.org/internet-drafts/= draft-sarikaya-capwap-fastbss-00.txt

Regards,

Behc= et

--0-1004315520-1161042058=:12855-- --===============1421249951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1421249951==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 17 13:16:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZsWP-0005IF-Bi for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 13:14:33 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZsQN-0008W0-Og for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 13:08:29 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 667B0144806A for ; Tue, 17 Oct 2006 10:08:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 3F7CD4A4196 for ; Tue, 17 Oct 2006 10:07:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2B5A8398042 for ; Tue, 17 Oct 2006 10:07:52 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 05:13:52 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id 90914398048 for ; Tue, 17 Oct 2006 10:07:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Oct 2006 10:07:44 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification on UDP ports Thread-Index: AcbuBEXMKgGb6bM8SR+GYGJJYMdsMwECRwmw From: "Abhijit Choudhury" To: "Dorothy Stanley" , "Pat Calhoun (pacalhou)" , "Michael Montemurro" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.051 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1691737226==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 This is a multi-part message in MIME format. --===============1691737226== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F20E.C349C158" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F20E.C349C158 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, Mike, Dorothy: =20 I have a question based on v03 of the capwap spec. In section 3.1, the spec mentions well-known UDP ports for the CAPWAP control and data packets. =20 There are four kinds of CAPWAP packets: 1. DTLS protected control packets 2. Unprotected control packets 3. Unprotected data packets 4. (Optional) DTLS protected data packets =20 Will there be 4 well-known UDP port numbers ? =20 1, 2 and 3 will be present simultaneously in any deployment. 3 and 4 may co-exist in a deployment if some data channels are encrypted and some not. There has to be a way to distinguish these four=20 kinds of packets. The draft is not clear about how=20 this is done. =20 Thanks, Abhijit =09 ------_=_NextPart_001_01C6F20E.C349C158 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Pat, Mike, Dorothy:
 
I have a question based on v03 of the capwap=20 spec.
In section 3.1, the spec=20 mentions well-known UDP
ports for the CAPWAP control and data=20 packets.
 
There are four kinds of CAPWAP=20 packets:
1. DTLS protected control = packets
2. Unprotected control = packets
3. Unprotected data = packets
4. (Optional) DTLS protected data=20 packets
 
Will there be 4 well-known UDP = port=20 numbers ?
 
1, 2 and 3 will be present simultaneously in=20 any
deployment. 3 and 4 may co-exist in a=20 deployment
if some data channels are encrypted and some=20 not.
There has to be a way to distinguish these four =
kinds of packets.  The draft is not clear about how=20
this is done.
 
Thanks,
   Abhijit

------_=_NextPart_001_01C6F20E.C349C158-- --===============1691737226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1691737226==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 17 16:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvBl-0001gV-8M for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 16:05:25 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZv71-0005nS-TB for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 16:00:33 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 4013C144807C for ; Tue, 17 Oct 2006 13:00:28 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id BD5A04A453A for ; Tue, 17 Oct 2006 13:00:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 99C4B1448022 for ; Tue, 17 Oct 2006 13:00:08 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id 772DB1448040 for ; Tue, 17 Oct 2006 13:00:04 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so476297nfb for ; Tue, 17 Oct 2006 13:00:03 -0700 (PDT) Received: by 10.82.142.9 with SMTP id p9mr1756721bud; Tue, 17 Oct 2006 13:00:02 -0700 (PDT) Received: by 10.82.117.14 with HTTP; Tue, 17 Oct 2006 13:00:02 -0700 (PDT) Message-ID: <369e612f0610171300t369bfaf2t37eb95f3784a84af@mail.gmail.com> Date: Wed, 18 Oct 2006 01:30:02 +0530 From: "NKA NKA" To: Abhijit@sinett.com, pcalhoun@cisco.com, dstanley1389@gmail.com, montemurro.michael@gmail.com MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 ________________________________ From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Tue 10/17/2006 10:37 PM > To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro > Cc: capwap@frascone.com > Subject: [Capwap] need clarification on UDP ports > > > > Pat, Mike, Dorothy: > > I have a question based on v03 of the capwap spec. > In section 3.1, the spec mentions well-known UDP > ports for the CAPWAP control and data packets. > > There are four kinds of CAPWAP packets: > 1. DTLS protected control packets > 2. Unprotected control packets > 3. Unprotected data packets > 4. (Optional) DTLS protected data packets > > > Will there be 4 well-known UDP port numbers ? [NKA} As per my understanding, you don't need to have two seperate UDP ports for handling DTLS and Non-DTLS control packets. Following is the logic which I would use at AC: 1. If AC receives a UDP packet on its control port, and if it CAN'T find the session information corresponding to the sender WTP, then the arrived packet can be considered to be a discovery packet. In the above situation, for some reason, if WTP sent a DTLS packet, AC can continue to assume it to be a discovery packet. So it should feed the arrived DTLS packet to its discovery packet processing module. Ultimately the packet will get dropped by AC due to packet parsing error (chances of DTLS packet looking like a valid discovery packet is very very slim). After a few trial, WTP will reboot and ultimately get in sync with AC's State machine. 2. If AC receives a UDP packet on its control port, and if it CAN find the session information corresponding to the sender, then the arrived packet can be considered as a DTLS packet. So AC should feed such packets to DTLS module directly. You may have a situation in which session information exists for a WTP at AC, but WTP is sending non-DTLS packet. Even in such situation, AC can feed such packets to DTLS module, which will ultimately reject the packet. AC can use this kind of notification to tear down the existing session, which will bring AC's state machine in sync with that of WTP. I have not given much thought about the data path issue. May be the initial policy (about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree whether DTLS will be used or not, the same information can be used for programming the hardware. I know that issue # 221 is tracking data path policy issue. NKA > > 1, 2 and 3 will be present simultaneously in any > deployment. 3 and 4 may co-exist in a deployment > if some data channels are encrypted and some not. > There has to be a way to distinguish these four > kinds of packets. The draft is not clear about how > this is done. > > Thanks, > Abhijit > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 17 16:56:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvzQ-0000ey-Be for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 16:56:44 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZvzI-0001Uf-9l for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 16:56:44 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2C621398074 for ; Tue, 17 Oct 2006 13:56:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 3AB494A453A for ; Tue, 17 Oct 2006 13:56:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F129139801C for ; Tue, 17 Oct 2006 13:56:13 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by zoidberg.tigertech.net (Postfix) with ESMTP id DA70F39805F for ; Tue, 17 Oct 2006 13:56:10 -0700 (PDT) Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GZvyq-0002pI-DK; Tue, 17 Oct 2006 16:56:08 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Tue, 17 Oct 2006 16:56:07 -0400 Message-ID: <21803909.1161118568342.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Tue, 17 Oct 2006 13:56:08 -0700 (GMT-07:00) From: "Scott G. Kelly" To: NKA NKA , Abhijit@sinett.com, pcalhoun@cisco.com, dstanley1389@gmail.com, montemurro.michael@gmail.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710187aa59970b98686539863802d251727350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Comments inline below... -----Original Message----- >From: NKA NKA >Sent: Oct 17, 2006 1:00 PM >To: Abhijit@sinett.com, pcalhoun@cisco.com, dstanley1389@gmail.com, montemurro.michael@gmail.com >Cc: capwap@frascone.com >Subject: Re: [Capwap] need clarification on UDP ports > > ________________________________ >From: Abhijit Choudhury [mailto:Abhijit@sinett.com] >> Sent: Tue 10/17/2006 10:37 PM >> To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro >> Cc: capwap@frascone.com >> Subject: [Capwap] need clarification on UDP ports >> >> >> >> Pat, Mike, Dorothy: >> >> I have a question based on v03 of the capwap spec. >> In section 3.1, the spec mentions well-known UDP >> ports for the CAPWAP control and data packets. >> >> There are four kinds of CAPWAP packets: >> 1. DTLS protected control packets >> 2. Unprotected control packets >> 3. Unprotected data packets >> 4. (Optional) DTLS protected data packets >> >> >> Will there be 4 well-known UDP port numbers ? > >[NKA} As per my understanding, you don't need to have two seperate UDP ports >for handling DTLS and Non-DTLS control packets. Following is the logic which >I would use at AC: > > 1. If AC receives a UDP packet on its control port, and if it CAN'T >find the session > information corresponding to the sender WTP, then the arrived packet can > be considered to be a discovery packet. > > In the above situation, for some reason, if WTP sent a DTLS packet, AC can > continue to assume it to be a discovery packet. So it should feed the arrived > DTLS packet to its discovery packet processing module. Ultimately the > packet will get dropped by AC due to packet parsing error (chances of DTLS > packet looking like a valid discovery packet is very very slim). Here are the first few words of the latest proposed capwap header, which would be at the head of the discovery message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| RID | HLEN | WBID |T|F|L|W|M| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here's the DTLS record header, which will be present after dtls negotiation starts: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | type | protocol version | epoch +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ epoch, cont | (6 byte sequence #) /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type will be from TLS; the ClientHello is 0x16, or 00010110 (other tls types of interest are similar), and the DTLS protocol version will be 0xFEFF, and any dtls version changes will just decrement the first version byte (FE, FD, FC, etc). This translates to the following bits: 1 6 F E F F 0001 0110 1111 1110 1111 1111 Putting this into the capwap header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0| |VERSION| RID | HLEN | WBID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or, VERSION..: 0001 RID......: 01101 (13) HLEN.....: 11111 (31) WBID.....: 10111 (23) Today, we don't have WBID of 23, so a robust implementation should interpret this as an error, but I wouldn't say chances of a DTLS packet looking like a discovery packet are really all that slim. It depends on several assumptions. >After a few trial, > WTP will reboot and ultimately get in sync with AC's State machine. > 2. If AC receives a UDP packet on its control port, and if it CAN >find the session > information corresponding to the sender, then the arrived packet can be > considered as a DTLS packet. So AC should feed such packets to DTLS module > directly. .. unless it's as discovery packet from a WTP that reset and no longer has the DTLS session context. Eventually, that session will timeout, but how long this takes depends on the configured echo interval. If it's more than a few seconds (e.g. say, 30 seconds), this adds a significant bit of latency to recovery scenarios. > You may have a situation in which session information exists for a WTP at AC, > but WTP is sending non-DTLS packet. Even in such situation, AC can feed such > packets to DTLS module, which will ultimately reject the packet. AC can use > this kind of notification to tear down the existing session, which >will bring AC's > state machine in sync with that of WTP. The WTP - or someone who spoofs the WTP address. Sounds like a very simple DoS attack. >I have not given much thought about the data path issue. May be the >initial policy >(about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree >whether DTLS will be used or not, the same information can be used for >programming the hardware. I know that issue # 221 is tracking data >path policy issue. > >NKA > >> >> 1, 2 and 3 will be present simultaneously in any >> deployment. 3 and 4 may co-exist in a deployment >> if some data channels are encrypted and some not. >> There has to be a way to distinguish these four >> kinds of packets. The draft is not clear about how >> this is done. >> I think for data channel security, it will have to be a binary decision for an AC/WTP pair, i.e. if data channel encryption is enabled, it is for all data. For the control channel, I think to have a clean solution (with deterministic behavior) we need either a separate discovery port or a type header which allows one to distinguish between discovery and dtls packets. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 17 17:04:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZw7B-0008E8-GA for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 17:04:45 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZw79-0002tv-Vo for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 17:04:45 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 65AF339805F for ; Tue, 17 Oct 2006 14:04:43 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id B48054A453A for ; Tue, 17 Oct 2006 14:04:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 807F539803F for ; Tue, 17 Oct 2006 14:04:05 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by zoidberg.tigertech.net (Postfix) with ESMTP id 50D2839805F for ; Tue, 17 Oct 2006 14:04:02 -0700 (PDT) Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GZw6T-0004qR-Nv for capwap@frascone.com; Tue, 17 Oct 2006 17:04:01 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Tue, 17 Oct 2006 17:04:01 -0400 Message-ID: <16395051.1161119041662.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> Date: Tue, 17 Oct 2006 14:04:01 -0700 (GMT-07:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71044438edcaf06fd3fb19ace738f61ea2a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.45 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: [Capwap] capwap threat analysis draft now available X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CAPWAP Threat Analysis for 802.11 Deployments Author(s) : S. Kelly, C. Clancy Filename : draft-kelly-capwap-threat-analysis-00.txt Pages : 28 Date : 2006-10-17 Early Wireless LAN (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the CAPWAP protocol [CAPWAP] is being developed in reponse. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for CAPWAP implementations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kelly-capwap-threat-analysis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-kelly-capwap-threat-analysis-00.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 at ietf.org. In the body type: "FILE /internet-drafts/draft-kelly-capwap-threat-analysis-00.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. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 17 17:09:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwC9-0000cb-Pw for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 17:09:53 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwC8-0003cN-CZ for capwap-archive@lists.ietf.org; Tue, 17 Oct 2006 17:09:53 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id DC2FC3980CA for ; Tue, 17 Oct 2006 14:09:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id AB96F4A453A for ; Tue, 17 Oct 2006 14:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7FCE6144804D for ; Tue, 17 Oct 2006 14:09:31 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 09:15:33 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 41610144801C for ; Tue, 17 Oct 2006 14:09:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Oct 2006 14:09:26 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: AcbyLq8jrkqRJfI2TlGegaLiFCthOwAAJB5g From: "Abhijit Choudhury" To: "Scott G. Kelly" , "NKA NKA" , , , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I think for data channel security, it will have to be a binary decision for an AC/WTP pair, i.e. if data channel encryption is enabled, it is for all data. For the control channel, I think to have a clean solution (with deterministic behavior) we need either a separate discovery port or a type header which allows one to distinguish between discovery and dtls packets. Scott In a clean solution, the packet itself should have enough information to clearly classify it as one of the four types of packets. We should not have to depend on configuration lookups to check whether the packet is supposed to be DTLS encrypted or not. We have used this principle already in designing the CAPWAP header. The T bit clearly identifies the payload as 802.3 or native format. This could have been identified based on a config lookup since an AC would typically handle 802.3 payload or native but rarely both. But we chose to include this information the header itself to make the design clean. The same idea should be used for distinguishing between the four packet types. Having four distinct UDP ports is one option. I'm sure there are others. Regards, Abhijit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 03:44:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga66B-0001sN-HC for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 03:44:23 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga669-0000qI-1m for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 03:44:23 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id D10F9430641 for ; Wed, 18 Oct 2006 00:44:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 18F794A45C5 for ; Wed, 18 Oct 2006 00:43:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F144F398022 for ; Wed, 18 Oct 2006 00:43:33 -0700 (PDT) Received: from smtp107.plus.mail.mud.yahoo.com (smtp107.plus.mail.mud.yahoo.com [68.142.206.240]) by zoidberg.tigertech.net (Postfix) with SMTP id D2B82398008 for ; Wed, 18 Oct 2006 00:43:31 -0700 (PDT) Received: (qmail 12773 invoked from network); 18 Oct 2006 07:43:30 -0000 Received: from unknown (HELO ?192.168.171.191?) (behcetsarikaya@121.133.79.100 with plain) by smtp107.plus.mail.mud.yahoo.com with SMTP; 18 Oct 2006 07:43:30 -0000 Message-ID: <4535DB1D.90200@yahoo.com> Date: Wed, 18 Oct 2006 02:43:25 -0500 From: Behcet Sarikaya User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: capwap X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.242 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS X-Spam-Level: ** Subject: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sarikaya@ieee.org List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Pat and all, The link: http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt is now on. Regards, --behcet ----- Original Message ---- From: Pat Calhoun (pacalhou) To: Behcet Sarikaya Sent: Monday, October 16, 2006 7:01:11 PM Subject: RE: [Capwap] CAPWAP for 802.11r ok, I will once it becomes available. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------------------------------------------------------------------------ *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] *Sent:* Monday, October 16, 2006 4:41 PM *To:* Pat Calhoun (pacalhou); capwap@frascone.com *Subject:* Re: [Capwap] CAPWAP for 802.11r Pat, ----- Original Message ---- From: Pat Calhoun (pacalhou) To: Behcet Sarikaya ; capwap@frascone.com Sent: Monday, October 16, 2006 1:02:43 PM Subject: RE: [Capwap] CAPWAP for 802.11r Behcet, I believe we've discussed this idea a few times, and I am still unsure why we believe CAPWAP needs to define anything to support TGr. The current CAPWAP protocol is sufficient to support the upcoming standard. ==> The basis is there but we need several extensions. Please read the draft and comment, then we can make a more informed decision, I think. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems Regards, --behcet ------------------------------------------------------------------------ *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] *Sent:* Saturday, October 14, 2006 8:33 AM *To:* capwap@frascone.com *Subject:* [Capwap] CAPWAP for 802.11r Dear all, I submitted a draft on CAPWAP Roaming Protocol in 802.11R Domains. It should be available soon at the following link: http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt Regards, Behcet _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From ajhkluuwmh@andorpac.ad Wed Oct 18 17:34:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ3j-00015N-IE for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:34:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJ1N-0006hc-Su for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:32:18 -0400 Received: from m85-94-184-218.andorpac.ad ([85.94.184.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaJ1J-00075G-AR for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:32:17 -0400 Message-ID: <000a01c6f2fc$db8f7490$dab85e55@as> From: "Jean" To: capwap-archive@lists.ietf.org Subject: exits aditional run Date: Wed, 18 Oct 2006 23:32:05 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F30D.9F184490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 ------=_NextPart_000_0006_01C6F30D.9F184490 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F30D.9F184490" ------=_NextPart_001_0007_01C6F30D.9F184490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nouveaux font or boutiques Mvengele motion nouvel exploit lon parle pril = am demeure bravo problme celui. Study Scandal Mourns Larry Snitker am Threatens Zombie or Teenager Peace = Processwhy Dudemoveon. Thankfully example patience tolerance leaders Deans unearthed journals = Dailythats vision. Cole ringtones Pussy Daddy Yankee Chris Blige ubl in Cuenta Regresiva en = is Audioslave Spanish Dime Breed dirty rapcould of West Texas Fuzzbubble = Hollywood. Compared Nanking scarcely bring describe killing fields azalea beds a = brutal torture. Result standing ovation Graphic Detailmeet team designers is versatile = in artists vast portion minute details sell each or viewer being Love = Previsfor. Modems Chipsets Portable Printers in Scanners Storage am Monitors vga = Misc Similar Enabling a Geforce msi Mega Netgear gmt pm a Archive am = vbulletin Jelsoft! Eva Saint fiery shoot really trailer least seconds Video Shake Rattle = Rollthe put together enormous in goes mechanical start forming just = marvel going for Designer. Nouveaux font or boutiques Mvengele motion nouvel exploit lon parle pril = am demeure bravo problme celui. Never flags workings magician made stay in bars tossing am jokes wears = hat decorated stuffed vulture divination classroom tawdry tea shop. Hermione know whole destroy is Professor Snape hate characters along = terrific Enjoying stint selling. ------=_NextPart_001_0007_01C6F30D.9F184490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nouveaux font or boutiques Mvengele = motion nouvel=20 exploit lon parle pril am demeure bravo problme celui.
Study Scandal = Mourns=20 Larry Snitker am Threatens Zombie or Teenager Peace Processwhy=20 Dudemoveon.
Thankfully example patience tolerance leaders Deans = unearthed=20 journals Dailythats vision.
Cole ringtones Pussy Daddy Yankee Chris = Blige ubl=20 in Cuenta Regresiva en is Audioslave Spanish Dime Breed dirty rapcould = of West=20 Texas Fuzzbubble Hollywood.
Compared Nanking scarcely bring describe = killing=20 fields azalea beds a brutal torture.
Result standing ovation Graphic=20 Detailmeet team designers is versatile in artists vast portion minute = details=20 sell each or viewer being Love Previsfor.
3D"" From: "Jean" To: capwap-archive@lists.ietf.org Subject: exits aditional run Date: Wed, 18 Oct 2006 23:32:05 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F30D.9F184490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 ------=_NextPart_000_0006_01C6F30D.9F184490 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F30D.9F184490" ------=_NextPart_001_0007_01C6F30D.9F184490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nouveaux font or boutiques Mvengele motion nouvel exploit lon parle pril = am demeure bravo problme celui. Study Scandal Mourns Larry Snitker am Threatens Zombie or Teenager Peace = Processwhy Dudemoveon. Thankfully example patience tolerance leaders Deans unearthed journals = Dailythats vision. Cole ringtones Pussy Daddy Yankee Chris Blige ubl in Cuenta Regresiva en = is Audioslave Spanish Dime Breed dirty rapcould of West Texas Fuzzbubble = Hollywood. Compared Nanking scarcely bring describe killing fields azalea beds a = brutal torture. Result standing ovation Graphic Detailmeet team designers is versatile = in artists vast portion minute details sell each or viewer being Love = Previsfor. Modems Chipsets Portable Printers in Scanners Storage am Monitors vga = Misc Similar Enabling a Geforce msi Mega Netgear gmt pm a Archive am = vbulletin Jelsoft! Eva Saint fiery shoot really trailer least seconds Video Shake Rattle = Rollthe put together enormous in goes mechanical start forming just = marvel going for Designer. Nouveaux font or boutiques Mvengele motion nouvel exploit lon parle pril = am demeure bravo problme celui. Never flags workings magician made stay in bars tossing am jokes wears = hat decorated stuffed vulture divination classroom tawdry tea shop. Hermione know whole destroy is Professor Snape hate characters along = terrific Enjoying stint selling. ------=_NextPart_001_0007_01C6F30D.9F184490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nouveaux font or boutiques Mvengele = motion nouvel=20 exploit lon parle pril am demeure bravo problme celui.
Study Scandal = Mourns=20 Larry Snitker am Threatens Zombie or Teenager Peace Processwhy=20 Dudemoveon.
Thankfully example patience tolerance leaders Deans = unearthed=20 journals Dailythats vision.
Cole ringtones Pussy Daddy Yankee Chris = Blige ubl=20 in Cuenta Regresiva en is Audioslave Spanish Dime Breed dirty rapcould = of West=20 Texas Fuzzbubble Hollywood.
Compared Nanking scarcely bring describe = killing=20 fields azalea beds a brutal torture.
Result standing ovation Graphic=20 Detailmeet team designers is versatile in artists vast portion minute = details=20 sell each or viewer being Love Previsfor.
3D""
Modems Chipsets Portable Printers in = Scanners=20 Storage am Monitors vga Misc Similar Enabling a Geforce msi Mega Netgear = gmt pm=20 a Archive am vbulletin Jelsoft!
Eva Saint fiery shoot really trailer = least=20 seconds Video Shake Rattle Rollthe put together enormous in goes = mechanical=20 start forming just marvel going for Designer.
Nouveaux font or = boutiques=20 Mvengele motion nouvel exploit lon parle pril am demeure bravo problme=20 celui.
Never flags workings magician made stay in bars tossing am = jokes wears=20 hat decorated stuffed vulture divination classroom tawdry tea = shop.
Hermione=20 know whole destroy is Professor Snape hate characters along terrific = Enjoying=20 stint selling.
------=_NextPart_001_0007_01C6F30D.9F184490-- ------=_NextPart_000_0006_01C6F30D.9F184490 Content-Type: image/gif; name="member.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f2fc$db8f7490$dab85e55@as> R0lGODlhRAGoAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAmAEkALAAAAABEAagB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFMWbKayJcV/ MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qFGjLpMqXcq0adKjUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVuncOPKnUu3rt27ePPq3cu3r9+4bgMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLfzNr3jz3sufPoEOLHk26tOnTZjmrXs3aJOrXsGPLnh27te3buC3S3s27t+/fgXMLH068uPHj yJMrX868ufPnFYFLn94TuvXrKqlr3869u/fv4Kdj/x9PPmT48+jTq49cvr379/Djn1xPv7T8+/gN 1t/Pv79/rvkFiN9/BBZo4IE7CaggfAjG9odvC0Yo4YQUVmjhhRhmqGFCDXZY2IYg4ubhiMGFuFAk m8VDIYksrmXiizDGKOOMNG7W4o045qjjjiTW6KNdPAa51Y9EFmnkkUgmqZ+QTFql5JPzNSmlVFBW OdKUWB5l5ZYfZenlUFyGudGXZP4k5ploppmdaLaU6eabcMYp55ziqWnnnXjmqeeefPbpp0ikZULn oIRC9ueehSaq6KKMtnjoo5CK2eiklFZqKXiRZqppkpdO+eQdm3LYaZOhlmrqqai+NyqpqVq5KpOt 2v9GQqy0XvnqrbjmqqtitT6566/A1tbrsMQWayxcwSar7LLMRnXss9BGK+20ejbbIbXYZvuXtdx2 y6u24IYr7rjFVnGht+imq26u5Lbr7pqWNbNuWO/Wm5cErc7bn7389uuvkvoGLHBX/xZs8MEIJxzd wAw37LCQCuf38MQUAxXxgBV/d/F9GXfsMU0by/cxdyGXzO/IKGdssqpZkZIyYyvHLPPMNNds8804 y/xynTn37PPPJO0sHdDLCW10wEQnrfTSEh0NIdMNAQB1cVJv6zRVACw2tUNV93V1VVkntjXXfn0N ttm0hY02bGp/ODbZbyO5tmxx153m3MLarffefPf/HSXegOPq9+BHBo5aRuYSrrjEhjfe6eKQz+i4 fZHzNTlplWeu+eacd/73boNcLvropAPu+emop6766gOVfmsIrscuu6Os12777eDOrvuXuC+1++/A C927UsEbOrxLxSev4/HMN+/88/8q3xj0n0uPGPWuWf8t9tyrpv323YP0vdjhmzf++ein/xsd6ref LA/ux99s+ebLb//9g9Jfsz8v4u+i/h7xn1oAGEBv3YNABOyIANOSwAY68IEcW+BZIIgRCVoQLFi4 oAY3qEFBcPCDFJwIAEbYtRCaECUfpNcJV8jCuqQQLC2MoQyZ8sKvzPCGY6qhDi2DQ4bs8Ceu+GGJ vXooKiFihYgKMWJWkAi9dzCRLkqMohR788SDbIcPH6vikqY4FS168YtgdAgXpfKFf4TxC2G0xxjX OMQvsvGN/0sjGOFIxwlmBo1y7Fsd9ziWNPLxjzYMIyCDksc5DtJMhUykIm/IwS4c8pGU8SMkJ0nJ SlrykpjcTjngeEIKTCSToKyOIEM5E0mS8pQ1MSUqF8nKVpoQlbAspStn6RdS0JJmsTTjLRkZFArw UZW5DCYpgTnMXc4wl8Y8ZiwDAgAh+QQAJgBJACwAAAAARAGoAQcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgx2tvIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjxsxIs6bNmzhz6tzJs6fPn0CD ChWaZKhRgjKTKl3KtKnTp1CjMj1KtarVq1izCpTKtavXr2DDih1LtqzZs2jTql3Ltq3bt0q1yp1L t67dhHDz6t3Lt6/fv4ADCx5MuLDhuHcTK17MeOfhx5AjS55MuTLbxpgza97MubPnz6BDix5Nuqbl 06hTq17rc=3D"cid:000501c6f2fc$db8f7490$dab85e55@as"=20 align=3Dbaseline border=3D0>
Modems Chipsets Portable Printers in = Scanners=20 Storage am Monitors vga Misc Similar Enabling a Geforce msi Mega Netgear = gmt pm=20 a Archive am vbulletin Jelsoft!
Eva Saint fiery shoot really trailer = least=20 seconds Video Shake Rattle Rollthe put together enormous in goes = mechanical=20 start forming just marvel going for Designer.
Nouveaux font or = boutiques=20 Mvengele motion nouvel exploit lon parle pril am demeure bravo problme=20 celui.
Never flags workings magician made stay in bars tossing am = jokes wears=20 hat decorated stuffed vulture divination classroom tawdry tea = shop.
Hermione=20 know whole destroy is Professor Snape hate characters along terrific = Enjoying=20 stint selling.
------=_NextPart_001_0007_01C6F30D.9F184490-- ------=_NextPart_000_0006_01C6F30D.9F184490 Content-Type: image/gif; name="member.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f2fc$db8f7490$dab85e55@as> R0lGODlhRAGoAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAmAEkALAAAAABEAagB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFMWbKayJcV/ MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qFGjLpMqXcq0adKjUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVuncOPKnUu3rt27ePPq3cu3r9+4bgMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLfzNr3jz3sufPoEOLHk26tOnTZjmrXs3aJOrXsGPLnh27te3buC3S3s27t+/fgXMLH068uPHj yJMrX868ufPnFYFLn94TuvXrKqlr3869u/fv4Kdj/x9PPmT48+jTq49cvr379/Djn1xPv7T8+/gN 1t/Pv79/rvkFiN9/BBZo4IE7CaggfAjG9odvC0Yo4YQUVmjhhRhmqGFCDXZY2IYg4ubhiMGFuFAk m8VDIYksrmXiizDGKOOMNG7W4o045qjjjiTW6KNdPAa51Y9EFmnkkUgmqZ+QTFql5JPzNSmlVFBW OdKUWB5l5ZYfZenlUFyGudGXZP4k5ploppmdaLaU6eabcMYp55ziqWnnnXjmqeeefPbpp0ikZULn oIRC9ueehSaq6KKMtnjoo5CK2eiklFZqKXiRZqppkpdO+eQdm3LYaZOhlmrqqai+NyqpqVq5KpOt 2v9GQqy0XvnqrbjmqqtitT6566/A1tbrsMQWayxcwSar7LLMRnXss9BGK+20ejbbIbXYZvuXtdx2 y6u24IYr7rjFVnGht+imq26u5Lbr7pqWNbNuWO/Wm5cErc7bn7389uuvkvoGLHBX/xZs8MEIJxzd wAw37LCQCuf38MQUAxXxgBV/d/F9GXfsMU0by/cxdyGXzO/IKGdssqpZkZIyYyvHLPPMNNds8804 y/xynTn37PPPJO0sHdDLCW10wEQnrfTSEh0NIdMNAQB1cVJv6zRVACw2tUNV93V1VVkntjXXfn0N ttm0hY02bGp/ODbZbyO5tmxx153m3MLarffefPf/HSXegOPq9+BHBo5aRuYSrrjEhjfe6eKQz+i4 fZHzNTlplWeu+eacd/73boNcLvropAPu+emop6766gOVfmsIrscuu6Os12777eDOrvuXuC+1++/A C927UsEbOrxLxSev4/HMN+/88/8q3xj0n0uPGPWuWf8t9tyrpv323YP0vdjhmzf++ein/xsd6ref LA/ux99s+ebLb//9g9Jfsz8v4u+i/h7xn1oAGEBv3YNABOyIANOSwAY68IEcW+BZIIgRCVoQLFi4 oAY3qEFBcPCDFJwIAEbYtRCaECUfpNcJV8jCuqQQLC2MoQyZ8sKvzPCGY6qhDi2DQ4bs8Ceu+GGJ vXooKiFihYgKMWJWkAi9dzCRLkqMohR788SDbIcPH6vikqY4FS168YtgdAgXpfKFf4TxC2G0xxjX OMQvsvGN/0sjGOFIxwlmBo1y7Fsd9ziWNPLxjzYMIyCDksc5DtJMhUykIm/IwS4c8pGU8SMkJ0nJ SlrykpjcTjngeEIKTCSToKyOIEM5E0mS8pQ1MSUqF8nKVpoQlbAspStn6RdS0JJmsTTjLRkZFArw UZW5DCYpgTnMXc4wl8Y8ZiwDAgAh+QQAJgBJACwAAAAARAGoAQcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgx2tvIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjxsxIs6bNmzhz6tzJs6fPn0CD ChWaZKhRgjKTKl3KtKnTp1CjMj1KtarVq1izCpTKtavXr2DDih1LtqzZs2jTql3Ltq3bt0q1yp1L t67dhHDz6t3Lt6/fv4ADCx5MuLDhuHcTK17MeOfhx5AjS55MuTLbxpgza97MubPnz6BDix5Nuqbl 06hTq17NOnLp17BjS2xNu7bt27hz697Nu7fv38DtyR5OvPjW4MiTtzTOvLnz59CjW1VOvXpJztWk a9/Ovbt3mtbDi//n+L28+fPo0ycez769+7wi3sufT/+k+vv4H9bfbzu///8G8SfggAQWaOCB+wGo 4H8INnjYghBGKOGE0Dlo4YUYZqjhhm9R6CF3HIbY1ocklodMiSimqOKKLLbo4oswziXijGnFaOON OOao445Y0ejjjyEtAOSQRBZp5JE8JqnkkuYd6eSTUEYp5ZRUVmlldUxmqeWWXHb54ZVgiuTlmDmF aaZHZKZp2plstunmm3DGiaSadFokp5V15jnRnVAi05GegOrH56CEbhjooYgmquiijDbq6KOCFirp pAZCaumlmGImQl26ZOrpp6CGKuqopJYamyvlAWDqquBR+hcAqrH/mhgAqhrnKl+w3gokrbr+yGuv PuYK7Iy/DmtsjbImq+yyzMp1rI/NJvnstNTeFi2P1YZ47Y7Zduvtt+CGK+64p21r7rmlkavuuuze iu6N7cYrr1jv1pvpAfbmu+e8TJHTn74t8ivwwAQXbPBaACes8MKZHvwewxBHLLGeRaLh7sQeOpxW Fxp37DFhGIcsckUfl2zyyckdBAYYI6fXz3EgrSwzytY2JHPL3tGsHM4Q6uyzvDwHLfRAPxdt9NGG Dc0g0rzVSwuMTDet9NQiR70b1fhZrXWVe3AkwNZghy32XliXbfbZxY1NG9rnqd0a2026vVqmROQp 99xwf3d3rHn3/73t3oC36Xd3gZc7+HaFW3Y44ok3TuXi2jk+GeSUmyr55ZhnrnlYlVe4eWGdhy76 6LN9bvrpQJOu+uqstz4c6rDHLvvstOfl+u2A1q777ryDjftrvcP1+/DEF2/8UMFTp07yfx7/mbfL MC/92M5XL+30alnfGfbcA6f99+DX2z1a4ZdffgrMjn+W+Y2p7/778F/MvmLx18/3/OvZ/xX+/FOo //79s8v/BiiZABrwgIwiIFcQKCMFOvCBEIygBCdIQcwx8ILpqSBiMMjBnGlQJh28ygdBGMKqjHAm JUyhCuF1wha6MDArjKEMZ0jDGnbuhTjMoe1syEPQ8I4KOgziv8J6SMQiGvGISEyiRPhhrw1hIVtK jKIUYyNElEzxilh8XhVNksUuevGLKaQVithVLP7oS4xgZAgaWRSuMm7RI258izBAd601xihbwsJQ GvdYpjf68Y+ADCSyGuKHNArykIhMpCJJyMdGOvIni4yk+qJAvkcqRJKWzOS+FqnJTvJvAZ6EDSZD iRRJRpKUpeQkKleZSkWy8pX/MKUsZ3lIWLJylF60BkRoyUtA2nKVuPylJ3tZy1ueUpihJKYyl8lM B74yIAAh+QQAJgBJACwAAAAARAGoAQcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx/tvI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjxsxIs6bNmzhz6tzJ86bMn0CDCh1KtKjRo0hbpkvKtKnT p1CjzuxJtarVq1izat3KtavXr2DDRpRKtqzZs2jTql3Ltq3bt3Djyp1Lt6zYu3jz6t2bsK7fv4AD i+RLuLDhw4gLnkvMuLHjqoIjS55MubLly5gza97MuXNKEZ5Dix59OQ3p0ywfq17NWi/q17Bjy55N u7bt27hz697N+zKD3mqr8mtNvLjx48iTK1/OvLlzm8CjSzcrZLr10M+za9/Ovbv37+DDi/9/eL28 +fHo02s1z769+/fw48ufT7++/fv48+vfz7+///8ABijggAQWaCCB6iWo4E4HNpjWghBGqJGDFJIl 4YUYklfhhk9l6OGHIIYo4ogkYsjhiSimSFmJLLbo4ovGqSijUDDWaOONOII144489mhWjkAq5+OQ KgVp5JFIJtkQkUyapOSTUEYp5ZRUVlkiOywapUmTXHZJoZVgfuXlmGSWaSaZYaap5ppstvnimXDG KeecB7pp55145qnnnnxCSOefgBbY56AaBjojoYgmquiijFZk6KOQRiopbY1Waqmik2aq6aacRnbp p6Dm2emXoZZqapijOngqn6m26uprq8b/KuustEr4qqC15qpribf26uuvwAYr7LCW7comsfwZuyay +ynr7LMLMqsftNRWa+212J4q7bbcRpXtt+CGK+5B3dq3JhLjpjtiuey26+678MZb5iDqGinviTTc y9mNX9Tr75H6svfvwAQXbPDBCCescLQBl7fwwxBHbG/D10G0mMQY/0txxRl37PHHIBu88cjxhnwh yb3+gDJKJtu6cm8tR/gyzDHXrO7MOOes884890yUzQr6LPSoQCc49GxFJ53t0bIpjR7TsTk9HtRU V231S1ITFwhFV3cdZ9ZgG+u1aGGXbfbZNI2NHdpsh6q2Z21n9/bcdB8d992V1q03j3j3/43p3pf5 vRzghKMo+OGIJ6744oyHW3hljUcO5uOUqyq5apM2Ubm8l3ce5eaeei766EuDHhjpqKfurFT6mO76 67DHLvvstNeuqeq45y6reQDYDlfvnIcIQMTtAe97W8a7W+LwCr+XPLssMq876r8mc3yn02cf4vVt ae99htyHH9335Jdv/vnop6/++uynKf778KvY/vzOxW9/bfRfdX9QWOzv//j5g0xZGhC/AArwfx0y oAJbg8AGOvCBEAzWAieIuQi+7RAWlBEFN8jBDuIog0fxIHRAWBQR1oSEKEwh/kyYERW68IWkYaGl uiFDjHSDhjW0yA13daIbSspNOJxVWcIA8Lzb+JBiRJTOEf+UFSKCaIemagoRi1jAnjgxhxCZogGJ ksQM3uSKWMxiGAkFjzGaUVwwTKMaM3PGNrpRR2v0jChm98Y62lF/cXTJHffoqDz6MYF8JNcfB0nI QhoyhoFMpCK5dshG/mSRkIykovZAK0eWRJICsSRJMLlIXXCyIJoMpSiBcrcWfJI5owTJKSWZyo9w spUeeSUsObLKWiZylrS0pS53ycte+vKXwAymwWBBFVxuRJa4RKYxl8nMZrYyIAAh+QQAJgBJACwA AAAARAGoAQcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx2tvIsaPHjyBDihxJsqTJkyhT qlzJsqXLlzBjxsxIs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVqzdlat3K tavXr2DDiu2KtazZs2jTql3Ltq3bt3DjNhxLt67du3jz6t3Lt6/fv4ADr5RLuLDhw4gTK17MuDFi wZAjS55MubLly5gz73XMubNVzaBDix5NurTp06hTq17Neqvn17Cbtp5Nu7bt27hz697Nu/fH2MCD E/VNvLjx48iTDxbOvLlO5dCjS59O/bTz69g1Vt/OvWViCtnDi/8fT768+fNHu6tfz769e5To4ysG IL++cwD46Tt8z994/pL2BTiffgj1Z+CBCCao4IIMVibgg681KOGEFFa4GYQYNmbhhhx26OGHIOqW 4YgklmgiUCGmqNmJLLbo4otzqSjjjDTWaOONLMGoY1k49ujjj7ntKGRVQBZp5JGkCafGkLEh6eST UEYppXVMVunUlFhmqaVWVna51JZghinmSFD14iWMY6ap5ppsRnnmm3AWxUicdNb5Vpta2snUBy36 tgWepukp6KCEFmrooYgmquiijNoH6KOQRirpgo1WaumlBk2q6aacdorcYpxgKuqobXlaJKmopoqY P2eZ6uqreb3/Aeus3qlq661W0nojrobq6uuvvvEqbE86DOsZsMgmW5uxgiqbIrPQRuuos9RWO5q0 2Gar7bZYWevtt5ZxK+645JZr7rnopqvul+BauC6vULwr77z01mvvZ+1WeO++/AaV778A69XvwATj FLCEBQt4cIMJN+ywRAsz+PDEFFds8cUYBxjxxhzPlPHHBXcs8sjwgWxyYeWcSPLKLLfs8sswu3cy djHXHPHM19nMHc7m+sBzpjpX9/PQRBdNVdBCGw0b0kw37TSyUjwttWhKV2311ShOrfXWXOeF9ddg hy02eV0XN/bZaKctUNlsc4NOnLp17BjS2xNu7bt27hz697Nu7fv38DtyR5OvPjW4MiTtzTOvLnz59CjW1VOvXpJztWk a9/Ovbt3mtbDi//n+L28+fPo0ycez769+7wi3sufT/+k+vv4H9bfbzu///8G8SfggAQWaOCB+wGo 4H8INnjYghBGKOGE0Dlo4YUYZqjhhm9R6CF3HIbY1ocklodMiSimqOKKLLbo4oswziXijGnFaOON OOao445Y0ejjjyEtAOSQRBZp5JE8JqnkkuYd6eSTUEYp5ZRUVmlldUxmqeWWXHb54ZVgiuTlmDmF aaZHZKZp2plstunmm3DGiaSadFokp5V15jnRnVAi05GegOrH56CEbhjooYgmquiijDbq6KOCFirp pAZCaumlmGImQl26ZOrpp6CGKuqopJYamyvlAWDqquBR+hcAqrH/mhgAqhrnKl+w3gokrbr+yGuv PuYK7Iy/DmtsjbImq+yyzMp1rI/NJvnstNTeFi2P1YZ47Y7Zduvtt+CGK+64p21r7rmlkavuuuze iu6N7cYrr1jv1pvpAfbmu+e8TJHTn74t8ivwwAQXbPBaACes8MKZHvwewxBHLLGeRaLh7sQeOpxW Fxp37DFhGIcsckUfl2zyyckdBAYYI6fXz3EgrSwzytY2JHPL3tGsHM4Q6uyzvDwHLfRAPxdt9NGG Dc0g0rzVSwuMTDet9NQiR70b1fhZrXWVe3AkwNZghy32XliXbfbZxY1NG9rnqd0a2026vVqmROQp 99xwf3d3rHn3/73t3oC36Xd3gZc7+HaFW3Y44ok3TuXi2jk+GeSUmyr55ZhnrnlYlVe4eWGdhy76 6LN9bvrpQJOu+uqstz4c6rDHLvvstOfl+u2A1q777ryDjftrvcP1+/DEF2/8UMFTp07yfx7/mbfL MC/92M5XL+30alnfGfbcA6f99+DX2z1a4ZdffgrMjn+W+Y2p7/778F/MvmLx18/3/OvZ/xX+/FOo //79s8v/BiiZABrwgIwiIFcQKCMFOvCBEIygBCdIQcwx8ILpqSBiMMjBnGlQJh28ygdBGMKqjHAm JUyhCuF1wha6MDArjKEMZ0jDGnbuhTjMoe1syEPQ8I4KOgziv8J6SMQiGvGISEyiRPhhrw1hIVtK jKIUYyNElEzxilh8XhVNksUuevGLKaQVithVLP7oS4xgZAgaWRSuMm7RI258izBAd601xihbwsJQ GvdYpjf68Y+ADCSyGuKHNArykIhMpCJJyMdGOvIni4yk+qJAvkcqRJKWzOS+FqnJTvJvAZ6EDSZD iRRJRpKUpeQkKleZSkWy8pX/MKUsZ3lIWLJylF60BkRoyUtA2nKVuPylJ3tZy1ueUpihJKYyl8lM B74yIAAh+QQAJgBJACwAAAAARAGoAQcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx/tvI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjxsxIs6bNmzhz6tzJ86bMn0CDCh1KtKjRo0hbpkvKtKnT p1CjzuxJtarVq1izat3KtavXr2DDRpRKtqzZs2jTql3Ltq3bt3Djyp1Lt6zYu3jz6t2bsK7fv4AD i+RLuLDhw4gLnkvMuLHjqoIjS55MubLly5gza97MuXNKEZ5Dix59OQ3p0ywfq17NWi/q17Bjy55N u7bt27hz697N+zKD3mqr8mtNvLjx48iTK1/OvLlzm8CjSzcrZLr10M+za9/Ovbv37+DDi/9/eL28 +fHo02s1z769+/fw48ufT7++/fv48+vfz7+///8ABijggAQWaCCB6iWo4E4HNpjWghBGqJGDFJIl 4YUYklfhhk9l6OGHIIYo4ogkYsjhiSimSFmJLLbo4ovGqSijUDDWaOONOII144489mhWjkAq5+OQ KgVp5JFIJtkQkUyapOSTUEYp5ZRUVlkiOywapUmTXHZJoZVgfuXlmGSWaSaZYaap5ppstvnimXDG KeecB7pp55145qnnnnxCSOefgBbY56AaBjojoYgmquiijFZk6KOQRiopbY1Waqmik2aq6aacRnbp p6Dm2emXoZZqapijOngqn6m26uprq8b/KuustEr4qqC15qpribf26uuvwAYr7LCW7comsfwZuyay +ynr7LMLMqsftNRWa+212J4q7bbcRpXtt+CGK+5B3dq3JhLjpjtiuey26+678MZb5iDqGinviTTc y9mNX9Tr75H6svfvwAQXbPDBCCescLQBl7fwwxBHbG/D10G0mMQY/0txxRl37PHHIBu88cjxhnwh yb3+gDJKJtu6cm8tR/gyzDHXrO7MOOes884890yUzQr6LPSoQCc49GxFJ53t0bIpjR7TsTk9HtRU V231S1ITFwhFV3cdZ9ZgG+u1aGGXbfbZNI2NHdpsh6q2Z21n9/bcdB8d992V1q03j3j3/43p3pf5 vRzghKMo+OGIJ6744oyHW3hljUcO5uOUqyq5apM2Ubm8l3ce5eaeei766EuDHhjpqKfurFT6mO76 67DHLvvstNeuqeq45y6reQDYDlfvnIcIQMTtAe97W8a7W+LwCr+XPLssMq876r8mc3yn02cf4vVt ae99htyHH9335Jdv/vnop6/++uynKf778KvY/vzOxW9/bfRfdX9QWOzv//j5g0xZGhC/AArwfx0y oAJbg8AGOvCBEAzWAieIuQi+7RAWlBEFN8jBDuIog0fxIHRAWBQR1oSEKEwh/kyYERW68IWkYaGl uiFDjHSDhjW0yA13daIbSspNOJxVWcIA8Lzb+JBiRJTOEf+UFSKCaIemagoRi1jAnjgxhxCZogGJ ksQM3uSKWMxiGAkFjzGaUVwwTKMaM3PGNrpRR2v0jChm98Y62lF/cXTJHffoqDz6MYF8JNcfB0nI QhoyhoFMpCK5dshG/mSRkIykovZAK0eWRJICsSRJMLlIXXCyIJoMpSiBcrcWfJI5owTJKSWZyo9w spUeeSUsObLKWiZylrS0pS53ycte+vKXwAymwWBBFVxuRJa4RKYxl8nMZrYyIAAh+QQAJgBJACwA AAAARAGoAQcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx2tvIsaPHjyBDihxJsqTJkyhT qlzJsqXLlzBjxsxIs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVqzdlat3K tavXr2DDiu2KtazZs2jTql3Ltq3bt3DjNhxLt67du3jz6t3Lt6/fv4ADr5RLuLDhw4gTK17MuDFi wZAjS55MubLly5gz73XMubNVzaBDix5NurTp06hTq17Neqvn17Cbtp5Nu7bt27hz697Nu/fH2MCD E/VNvLjx48iTDxbOvLlO5dCjS59O/bTz69g1Vt/OvWViCtnDi/8fT768+fNHu6tfz769e5To4ysG IL++cwD46Tt8z994/pL2BTiffgj1Z+CBCCao4IIMVibgg681KOGEFFa4GYQYNmbhhhx26OGHIOqW 4YgklmgiUCGmqNmJLLbo4otzqSjjjDTWaOONLMGoY1k49ujjj7ntKGRVQBZp5JGkCafGkLEh6eST UEYppXVMVunUlFhmqaVWVna51JZghinmSFD14iWMY6ap5ppsRnnmm3AWxUicdNb5Vpta2snUBy36 tgWepukp6KCEFmrooYgmquiijNoH6KOQRirpgo1WaumlBk2q6aacdorcYpxgKuqobXlaJKmopoqY P2eZ6uqreb3/Aeus3qlq661W0nojrobq6uuvvvEqbE86DOsZsMgmW5uxgiqbIrPQRuuos9RWO5q0 2Gar7bZYWevtt5ZxK+645JZr7rnopqvul+BauC6vULwr77z01mvvZ+1WeO++/AaV778A69XvwATj FLCEBQt4cIMJN+ywRAsz+PDEFFds8cUYBxjxxhzPlPHHBXcs8sjwgWxyYeWcSPLKLLfs8sswu3cy djHXHPHM19nMHc7m+sBzpjpX9/PQRBdNVdBCGw0b0kw37TSyUjwttWhKV2311ShOrfXWXOeF9ddg hy02eV0XN/bZaKctUNlsc4hf27j9B5jaGOVH91v43e2W3bjG/2EngXoHHjLcuwkOF+GIJ6744r0Z fifjyzoueUFMVAl55JNnnuvls2muFueghw5zK6Jj7rlZpat2Olqpn8ZG67DjuHqrsdcu4+yo2647 iLj37vvvdO8u/PDEhw788cgnr/zyzH9ePGbNX/n8ZdHLNv31CFavvXPYd+/9mtpO8iIc25c/3vfo r2c+Uum3v9368HfmfmDxFzX/3PUPdf9f+eu/f1/9E8r/AGgvWoxogHwJoAJbxIoFOtAiCLzQAyeY lggKjILP8dURZoTBDvLIgnjxoMFASMISmlBKJgKcCC+iwnVRCAD5GlEL3zUhGJ4wLDaMIYRmKC8G 5fBfK7TJDcKHSKUgGvGISMwZEZfIxCZuKIlQjKIUp0jFKlrxirdyIlmwyMUuZk2LXPKiGMeYFTCG kYxojFFMPGDGNnqMVNVIlBvnyL80FoSOeJSgCDuQEQRuMI8rsiNBAJkjQVrNCYZMJHMIychGOjJJ FGugIs3zyEpa8pKYzKQmN8nJTkJnkqBUpCc7MslRmtIjoUylKlfJSime8pX2aKUsr/jKUp7SlrAc JS5zyUtN7tKTv+xlJmdJzCnWkl+/gJAwO1nMZiYxIAAh+QQAKwBJACwAAAAARAEfAAcI/wDtCRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx/tvIsaPHjyBDihxJsuRIaCZTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKhRlRmTKl3KtKnTp1CjMj1KtarVq1izat3KtavXr2DDih1LtqzZs2jT 6pTKtq3bt3Djyp1Lt67du3jzSlTLt6/fv4ADCx4s8iJhrXoTK6Z7OOvipaEeu21MubLlj4Y3Dlg5 oLPOzTFBa/7YubRn06JRm/6XmiNoybBjG6S5WbRJ2zdxs6ztmjRI27pxtx59ufjIzLxHr/bNmnVp 4r01e5YOGjX13tM9Jm+u/XfH4N2hv9OWTb78ROWugTPP3ly4eO7c1RNn3334d+/R7+uHP968//8J oQfdgPOFN5x64BG4nXf2pWedfPu9RxyAFFYoEH8KrmdgdKpJt597uuVXHXPaLReeiNFZqOJbM1kH H4HxnbhdiBK+2J5ILiYoI34owmjcj7RxeKKQH2KIY40C8jjikPnZ6CSQUPYEIpMxRuhekktKSOOU VNp4ZY9PRimmSlw26dyCLwaX3XMOXuejl2c+pxqaae745ph45qnnnnz26Sdfmf1p04qESiXooYgm quiiQgUEACH5BAArAEkALAAAHgBEAR8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHCnRnsmTKFOqNEmypcgAFmG67Liyps2bOHPq3Mnz5EWZA4HOHCpRaNGMAZImJah0 6T+jT582NQoUKtGrD3uuFGoVq9eDXR2GhchVINWoBWFSrRpUoNa3cOPKXfmzLVOnZp2qxcs0bVC8 Z/eC1es3b1W+d5VGPWs4MeLGZqU+DgzWoFrLdtF+3fwycl/PbAFj/sxWc+THnhcXDp259WXGpcsW RsuXcVurUC+PLs2598G59nS7Ni08dWaZlPt2lR1beULKyU/PNq7683DI1Kuvtgu8u/fvKH8i/566 t6np85qR+42edmpq5O6lVnYe2L1t6sXPx2+fPT/o1r4FiJF6AKJ3320A5udfdtIx2N96+hk4XYQH joUghLsVuNAzId0h4D/A8ZbbaBoKx552E16InnX4oehihCy6eCBC/tWoEHg45vhWXcfZxZqGLf73 14rvxfijhHmhSJiQ8s1GYILz+Ugaf0V+KGCITtaml3nPWablUgv+NaNi2LX3mmEmfrkimTACuZ9k h3HZI4g61mlnnTGJNZOFZFk51J2ABvoVn0R+RKhCvPmp6KIcAZcnQ4ciNSBqjH4U6KWYZqrpppx2 6umneFYq6qiklmrqqaimqqpFoLbq6quwxkcq66y01mrrrbjmquuuvPZq06rABivsZr4Wa+yxxw6r 7LLMNuvss9B6hey01FZr7bXYZqvtr9F2622024Yr7rjklmvuuTkFBAAh+QQAKwBJACwAADwARAEf AAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihwp8Z/JkyhTqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTpz5JSp1KtarVq1gRQk26aavXr2DD rsxKtqzZs2jTql3Ltq3btmLjyp1Lt67du3jz6t3Lt6/fv3LfCh5MuLDhw4gTK8YKuLHjx3QvQp58 c7Hlj5TjCiC62eTlzwR3Chg92iRp0v9Ooz6dkvVJ151fp46durXr2aVNl6ZdG+Vq2rFvt9aNmnhn 3ptVD8/M3Cbw3iufm5ZN/Tny2b6XT4cefDv17Nirg/9fbj37denem/+9WJ4l+uMqk8cfLj899Ond t18nz/2++++18eZffQBuBtqB7JnX0nv2BTifgvkB6KB38I0nXncCPngfgRJyuOE/CH4mmnnKFVic f73BRp9+2uF3YootsghjcLmNJ52KClqYoXo82lbcjh/2F+OEsmEYY303Dlmhg/vZKFyRK+rYo18J DlmgeEoO2F+T+H23ZINLysclhS95aGZ2IaYZkYBAMpjel2G+yWWcMkoI42twasgmePmhN52agDbE ZolvOlkjbsDVmKiPipKYHGvKreYbjS9iyeiklB7aW6CJTQkYkD2B6ulcko3alKg5xcbpqgc1lxBK r/IQxOqsJZlq66245qrrrnIFBAAh+QQAKwBJACwAAFoARAEfAAcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzYgTAEYDGgh4NduQo8iNEfgpREuTH0qTLlzBjyrQYUmZNgjdvzkzIUqXBnit3 Ch1KlKi9o0iTKl16VOe/nE+jegw5UuBUkk87gsQpNWpWrFWtCmR6lCBZewN9HvSpduzZt3Djyp1L t67du3jzJqU4Q+zWgVetUuWK1atTr2LBIvbr9zDFtgXZ9oRctLLlyw31Ni0JGHFNqFAXd+78WXTo gWfNkk2bkjVrzbBjy55NuzZtp6BHf9Ua+vDIwYlB/i6YGvVqgZRd/1OL0rbz59CjS5eLm7Du6qN9 c+7KNWFxt0yVr80V33y6+fPooW/8m9Wzbu6ND2KHz9jwR+aRyWPez78/+LyCgUXSVO+FdVph9TFG lVa7jfbdP6lNppJkQC1XYXoYZqghhv6Z9OCDFW0o4ogkotXhiSimqOKKFJXo4oswxigjbSzWaOON OOao44489ujjj0AGKeSQRBZp5JEazajkkkw2+SKSUEYppUVOVmnllVjGNuWWXHZpUJZghimmmF6W aeaZaKap5ppstunmQ2PGKeecML5p55145qnnnnz26eefgAbqHZ2EFmpodAEBACH5BAArAEkALAAA eABEAR8ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEPiCEly4r+TKFOq XMmypcuXMGPKnEmzps2bOHPq3MmzZ8+SQIMKHUq0qFGIPpMqXcq0qdOnUKMyPUq1qtWrWLNq3cq1 q9evYMOKHUu2rNmzaNN6lcq2rdu3cOPKnUu3rt27ePPq3cu3r9+/Si/iBKCXcFLDNREDlqn4sEy1 PAFIbvySMOWYl3c2ppz5JOLOLkF7pil69OCWmyszXrzz4ueZlm+Wtpk6McrZKkvj/jd7d27UtjE/ Ths5peHJnpHflpxbuXPmxqE7v52c+eTj0Edfb25ZOe/sy61T///evTPy58d5kzduGrv76uTTb4/+ vnr916xbumb/Gr/639pRxxlw/Qlo4G/+/adgbKY1yKB6ioEWIUvdNTheevyN5yCEGi54oIIBjqbW fh8+mOCG1z3YYXweFhhihhb6Vx54LkJ4YnMdbndjbAzqmKOBCcroIYsc/jOiRRPWuOOHFsZYYotM vjghisBJuRyIqJn4JIIcKslegEFqqCV+DEKm2hf27j9B5jaGOVH91v43e2W3bjG/2EngXoHHjLcuwkOF+GIJ6744r0Z fifjyzoueUFMVAl55JNnnuvls2muFueghw5zK6Jj7rlZpat2Olqpn8ZG67DjuHqrsdcu4+yo2647 iLj37vvvdO8u/PDEhw788cgnr/zyzH9ePGbNX/n8ZdHLNv31CFavvXPYd+/9mtpO8iIc25c/3vfo r2c+Uum3v9368HfmfmDxFzX/3PUPdf9f+eu/f1/9E8r/AGgvWoxogHwJoAJbxIoFOtAiCLzQAyeY lggKjILP8dURZoTBDvLIgnjxoMFASMISmlBKJgKcCC+iwnVRCAD5GlEL3zUhGJ4wLDaMIYRmKC8G 5fBfK7TJDcKHSKUgGvGISMwZEZfIxCZuKIlQjKIUp0jFKlrxirdyIlmwyMUuZk2LXPKiGMeYFTCG kYxojFFMPGDGNnqMVNVIlBvnyL80FoSOeJSgCDuQEQRuMI8rsiNBAJkjQVrNCYZMJHMIychGOjJJ FGugIs3zyEpa8pKYzKQmN8nJTkJnkqBUpCc7MslRmtIjoUylKlfJSime8pX2aKUsr/jKUp7SlrAc JS5zyUtN7tKTv+xlJmdJzCnWkl+/gJAwO1nMZiYxIAAh+QQAKwBJACwAAAAARAEfAAcI/wDtCRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgx/tvIsaPHjyBDihxJsuRIaCZTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKhRlRmTKl3KtKnTp1CjMj1KtarVq1izat3KtavXr2DDih1LtqzZs2jT 6pTKtq3bt3Djyp1Lt67du3jzSlTLt6/fv4ADCx4s8iJhrXoTK6Z7OOvipaEeu21MubLlj4Y3Dlg5 oLPOzTFBa/7YubRn06JRm/6XmiNoybBjG6S5WbRJ2zdxs6ztmjRI27pxtx59ufjIzLxHr/bNmnVp 4r01e5YOGjX13tM9Jm+u/XfH4N2hv9OWTb78ROWugTPP3ly4eO7c1RNn3334d+/R7+uHP968//8J oQfdgPOFN5x64BG4nXf2pWedfPu9RxyAFFYoEH8KrmdgdKpJt597uuVXHXPaLReeiNFZqOJbM1kH H4HxnbhdiBK+2J5ILiYoI34owmjcj7RxeKKQH2KIY40C8jjikPnZ6CSQUPYEIpMxRuhekktKSOOU VNp4ZY9PRimmSlw26dyCLwaX3XMOXuejl2c+pxqaae745ph45qnnnnz26Sdfmf1p04qESiXooYgm quiiQgUEACH5BAArAEkALAAAHgBEAR8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq 3Mixo8ePIEOKHCnRnsmTKFOqNEmypcgAFmG67Liyps2bOHPq3Mnz5EWZA4HOHCpRaNGMAZImJah0 6T+jT582NQoUKtGrD3uuFGoVq9eDXR2GhchVINWoBWFSrRpUoNa3cOPKXfmzLVOnZp2qxcs0bVC8 Z/eC1es3b1W+d5VGPWs4MeLGZqU+DgzWoFrLdtF+3fwycl/PbAFj/sxWc+THnhcXDp259WXGpcsW RsuXcVurUC+PLs2598G59nS7Ni08dWaZlPt2lR1beULKyU/PNq7683DI1Kuvtgu8u/fvKH8i/566 t6np85qR+42edmpq5O6lVnYe2L1t6sXPx2+fPT/o1r4FiJF6AKJ3320A5udfdtIx2N96+hk4XYQH joUghLsVuNAzId0h4D/A8ZbbaBoKx552E16InnX4oehihCy6eCBC/tWoEHg45vhWXcfZxZqGLf73 14rvxfijhHmhSJiQ8s1GYILz+Ugaf0V+KGCITtaml3nPWablUgv+NaNi2LX3mmEmfrkimTACuZ9k h3HZI4g61mlnnTGJNZOFZFk51J2ABvoVn0R+RKhCvPmp6KIcAZcnQ4ciNSBqjH4U6KWYZqrpppx2 6umneFYq6qiklmrqqaimqqpFoLbq6quwxkcq66y01mrrrbjmquuuvPZq06rABivsZr4Wa+yxxw6r 7LLMNuvss9B6hey01FZr7bXYZqvtr9F2622024Yr7rjklmvuuTkFBAAh+QQAKwBJACwAADwARAEf AAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihwp8Z/JkyhTqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTpz5JSp1KtarVq1gRQk26aavXr2DD rsxKtqzZs2jTql3Ltq3btmLjyp1Lt67du3jz6t3Lt6/fv3LfCh5MuLDhw4gTK8YKuLHjx3QvQp58 c7Hlj5TjCiC62eTlzwR3Chg92iRp0v9Ooz6dkvVJ151fp46durXr2aVNl6ZdG+Vq2rFvt9aNmnhn 3ptVD8/M3Cbw3iufm5ZN/Tny2b6XT4cefDv17Nirg/9fbj37denem/+9WJ4l+uMqk8cfLj899Ond t18nz/2++++18eZffQBuBtqB7JnX0nv2BTifgvkB6KB38I0nXncCPngfgRJyuOE/CH4mmnnKFVic f73BRp9+2uF3YootsghjcLmNJ52KClqYoXo82lbcjh/2F+OEsmEYY303Dlmhg/vZKFyRK+rYo18J DlmgeEoO2F+T+H23ZINLysclhS95aGZ2IaYZkYBAMpjel2G+yWWcMkoI42twasgmePmhN52agDbE ZolvOlkjbsDVmKiPipKYHGvKreYbjS9iyeiklB7aW6CJTQkYkD2B6ulcko3alKg5xcbpqgc1lxBK r/IQxOqsJZlq66245qrrrnIFBAAh+QQAKwBJACwAAFoARAEfAAcI/wD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzYgTAEYDGgh4NduQo8iNEfgpREuTH0qTLlzBjyrQYUmZNgjdvzkzIUqXBnit3 Ch1KlKi9o0iTKl16VOe/nE+jegw5UuBUkk87gsQpNWpWrFWtCmR6lCBZewN9HvSpduzZt3Djyp1L t67du3jzJqU4Q+zWgVetUuWK1atTr2LBIvbr9zDFtgXZ9oRctLLlyw31Ni0JGHFNqFAXd+78WXTo gWfNkk2bkjVrzbBjy55NuzZtp6BHf9Ua+vDIwYlB/i6YGvVqgZRd/1OL0rbz59CjS5eLm7Du6qN9 c+7KNWFxt0yVr80V33y6+fPooW/8m9Wzbu6ND2KHz9jwR+aRyWPez78/+LyCgUXSVO+FdVph9TFG lVa7jfbdP6lNppJkQC1XYXoYZqghhv6Z9OCDFW0o4ogkotXhiSimqOKKFJXo4oswxigjbSzWaOON OOao44489ujjj0AGKeSQRBZp5JEazajkkkw2+SKSUEYppUVOVmnllVjGNuWWXHZpUJZghimmmF6W aeaZaKap5ppstunmQ2PGKeecML5p55145qnnnnz26eefgAbqHZ2EFmpodAEBACH5BAArAEkALAAA eABEAR8ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEPiCEly4r+TKFOq XMmypcuXMGPKnEmzps2bOHPq3MmzZ8+SQIMKHUq0qFGIPpMqXcq0qdOnUKMyPUq1qtWrWLNq3cq1 q9evYMOKHUu2rNmzaNN6lcq2rdu3cOPKnUu3rt27ePPq3cu3r9+/Si/iBKCXcFLDNREDlqn4sEy1 PAFIbvySMOWYl3c2ppz5JOLOLkF7pil69OCWmyszXrzz4ueZlm+Wtpk6McrZKkvj/jd7d27UtjE/ Ths5peHJnpHflpxbuXPmxqE7v52c+eTj0Edfb25ZOe/sy61T///evTPy58d5kzduGrv76uTTb4/+ vnr916xbumb/Gr/639pRxxlw/Qlo4G/+/adgbKY1yKB6ioEWIUvdNTheevyN5yCEGi54oIIBjqbW fh8+mOCG1z3YYXweFhhihhb6Vx54LkJ4YnMdbndjbAzqmKOBCcroIYsc/jOiRRPWuOOHFsZYYotM vjghisBJuRyIqJn4JIIcKslegEFqqCV+DEKm2YVbYgnliz9a6eWAYVLppJVMZqYlnQD+56WYRYIo 5J5q5peSa96tN2Ry3NX3HXf2NcoimUmuKF574DmqY3bSMYroo9Hl+dlz8BV4onSYouefmX35dpqg ebLalKp9Cca2VKFM0coqrK6SNihxufbq66/ABivssMTSRSJduMqFa7IrMSuVsycdKRG0q2JJrVPL OvaUs9RKG9G1tK0IWLY+gUvhmTydFZl37JKKoZ7uMjqfovAZep57n+K7YXj5hkdfv/XOh6bA0+lJ pL+GHlhwuwDbWqxqbhJYZ5tQXjZlkfJJuqafGlv8JKAYf9zeoYdG+C6PHX8Z6MPnaufjvy3mSyOf FbbqYsaUTmpwbfBaN6DL956X459AdklxnPHxOO+9/JrbVkAAIfkEACsASQAsAACWAEQBHwAHCP8A /wkcSLCgQYEABiYEwJDhv4QEGy5U+BBixYYRKSJ8WNGgRY4bIYoECVIiyZEfTyLE6LCgxYUmJU7c qPAlRZsTc2qkqXKnTI4/L8KsifGg0aNIkypdypTnzJ0qba4k6dLnyY9Yb9J8yrXnU6c9O1pNSRbq TJxadUoFyzNsyKpOvzadS7euXbBox5p1u/ZrVr0lo2plm/Ft279AByc+bHhx4K17CYfV2Tjr2ruY 79rbzLmz58+bTa582VJ0zJYXPXaFmTK165FAiwqd7FHjabKyc5eOLLYkaqmXxco+vNv1bN0QQStf zry58+fQN2eeTn1pa6XXq2vfzn169O/gw4v/t9e9/PTsSNGbX8/e/Pj38NvLn0+/vv379Fnh38+/ v///AAYo4ID7qdcWZmVBpZ2B5xEYIIPzQchUcAjCVViDF1JloXUKTuihXRSWBx95DiYlIYfdMXhi ehuuyOKBH2J3l1QjNneeQ7+VJtJuWCEHmW+47RjkaLBRxVJqOSaIUlFCzuaSjkWeNZxpiYnm5GhX Doclk0k+hlduHZYIm5JRJejYWY0ZJVdVeRk5GEqRwfkWYogJNidvQ53JF2BuWpWmXG1GWWJtj1HZ 5lgxVdlbREeqhqNtGua15JSKokVnhoHqyedqeN5kZW99Gdlapm6tN+KYXtl5IaCKTsXnpmna8iln bWqltSqmilHWp56kErYmo7RZZmFXPdVorHKoAqcqrKVeOmquHUpa2bB47VpnpsRWO+1loYaYrV+M TWvUscphOCaTWGro1W+2oUbUjk8+KllNi5377I/1yhsplO8C2WNxmn7aEXDuGsfvlmaxBCaMg8bY 8IsPO+jifRNHfFTFA2JscYoFi7nxxyCHLPLIJJds8skop6zyyiy37PLLMPsnQ0Hk1mzzzTjnrPPO PPfs889ABy300EQXbfTRSCet9NJMN+3000K/AXVnvUxt9dVYZ71zL1Vr7fXXYIetHNdil2322UM4 3bXTMbft9npclxgQACH5BAArAEkALAAAtABEAR8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEix okWIvXpd3Mixo8ePIEOKHEkSY0mJ9lKqXMmypcuXMGPKnEmzps2bOHPq3Mmzp86MPoOqPEm0qNGj SJMizKjUoNCnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rFmyTdOqXcu2rdu3cOPKnUu3rt27ePOq Pcu3r9+/gAMLHky4sOHDiBMr7qu3sePHkBMu5ktusuXLKSNr3sy5s+fPoEOLHk26tOnTqFMb9Ska c+B/rqNy/ED7g0jbBmkTxK26t++JvEcGH6ib+G+JJI6fHv4vuO3nzaM3ry3wefHaw6FXr05dunfc 3ZWLjvfM3Pl07tuNF5fOPDpv7dvfqx9P363P8ru/G5+/vz34+Pm5J6B3sMVm4IEtXYQff99hBx97 B8lnHXYAwrdefRgilVI4Oy0IYHoEgghhbvP5J2B2BSKo4oo6hfiehft9mJ6JxD0on4jbsajjZbN1 Rx2MNV4X4HlDEklhjC+2l+GSI7EW2o5QKsbklFSSFBAAIfkEACsASQAsAADSAEQBHwAHCP8A/wkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKdGeyZMoU6o0SbKly5cwY4pcSbOm TZYycy4EoLOnTp4fgfpceLMogKNCCyZViHRpw6YVnf6TyhQqQ55UCSLFmNWh065NsV59CrVrw6Jo 06pNKVSqWYFvE8Yda3DuQLtan2bEe5Dv0rd2215cS/jkRcFTj8JVLDYx0L93HUOuq9hx4sWVH2fe 3LYyXMqMI2MN/Tmv5NJTMd9lzHr0as2c81qNbHqr6q2NbaOebVssbr4VC7MVTXzxbtWpPyNGTTv1 Y+XEBS9vrLR3cefJs0+Wfp269tLUw2f/767VOvfmntGrl/48OU/hhA/3LqueOXbozL8Wf849rPay +pl2H3ZJeQcebbkBWB9/9OEnW3PjOdfgca9NJ9qE7QEn02T1ffeggwXWtR+IA1JYnYDH9fdhbQi6 15d4LnJo4IAhrphfhxY6SGF7Q+2kFHkmkricfefxFx2Q49W43pEotmjikDAaKaSIUP543pM4kocY jzPBZ9JXnpGGHG+4QYgZbAdKmBlyl1nmZoWwxenekLd16KZupGW4JnghQtkgnpslieeCe7qYmpdq 9ZiThhbNxaiikEZaEKL2SArRoxQ5aummIFHqaVGchirqqDB9aupKpKaq6qoYneqqYaz2/xigqpiO RJVdr746249kpXepry/FtR2gYqopLJ2XhqqkWULl6iqyESJUq30wCcvrlTdCeyK1D00L0rI+CuQs SochGFuCXH63q4injbnmaGG+6y6aZwqIbZL4MmWodfuGWZ2c7d55Ybz0BmwZmQUrq+VqOxYKY18p 2tvmla5ZueSNDXPpHbMxjlgitzSqu7COFEtMZLScWuVfjhGKp62hJZY8ZYX/lYmxwSTny2bHKxPY ppkYijxzzEFneZq3ZyHKIZYnywyx0BFHHTKJJgdp8XUos2igb/9BWPLXI598M9jijvupjB6mPXS6 MG+MpMsXQw2utPi+jF6UQHsdNtxDy4JdNd//mH02aAwXyFlnYqZr85z0Io54fvOxua7ixAIc7sT+ 8ols0FsSHGVs9ZbnocrvCU5pT0g3SVLqLrFuqemnLxrUhqy6/rrgseau++6rxs7778ArCjuqGtnu EaPAyiWR8T4lv/xewNsNqYbS60iX9S86b+ZVYGq/fVT/zki3TwEBACH5BAArAEkALAAA8ABEAR8A Bwj/AP8JHEiwoEGBAAYmPMiwocOHEBFGNLjwX0WHCS9CvJhxI4CPDzV6pPhRJMWJETWW7JgSpUuX 9mLKnEmzZsyKJl/q1Jkz5MueDUUCtbhzIsiCOH0WPakQqVGCNqNKnUq1qtSSFrEiPEpQq1eQR1cq DOu16ViuWrNyBKsWZ1iiYtWe5Si3rkSkb1mmTXtXZVO9ZBeW7SgYLV+Vgc8SJfqoseNHViNLnmwv qUTLdzPrvWz2r+fMi0NzZgq3M2e6STGXBt317WXBoVky9ftac+y/hW2rrotZ9mqbj4NTHi65d1u6 nTevXizWsu/bbbOSll2YrfPmpqkDzYj9NVauXVnH/3X7fS5189BPGl87kLj79zXXM0S+Gnbqz8xF 3+5N//x92OJlpx944dG2XGutxRXgggMm5xRr+N33GXwUvicfaP3lt5x/Dj64YXgOSliabyKiRppT JaYnGn0N6hZihx8edN5off1TIXFLjQUdX1tVVyNce5Vnm4fVcWfgjNgZ6WOPyIFFoIJl9ZUYiBh6 yFuCQ/Y4V4JuaanlbjnCBF+YKA0lI5lopqnmmmy2+dCNcErm5pk/zWnnnXjm2WacfFKl55+ABiro Un0Wauhwgyaq6KKDHuroo1ItZSajek6qn5qW5gnpppGFqeBTaRIYqKUzkiQkRil1R+mqrG5kmquh Zv/apqxgMhhUma+2qiubFKYImJKKecmjhtH9Gux35DHp5Y+EOfnkg0EaWR945CU7opO8cqptpDn6 CmCWNKqoYWrfcpifr7OdBmN0H/YnFIz+AfjtrvSuOV6EVBYpHZO0YVbYgnliz9a6eWAYVLppJVMZqYlnQD+56WYRYIo 5J5q5peSa96tN2Ry3NX3HXf2NcoimUmuKF574DmqY3bSMYroo9Hl+dlz8BV4onSYouefmX35dpqg ebLalKp9Cca2VKFM0coqrK6SNihxufbq66/ABivssMTSRSJduMqFa7IrMSuVsycdKRG0q2JJrVPL OvaUs9RKG9G1tK0IWLY+gUvhmTydFZl37JKKoZ7uMjqfovAZep57n+K7YXj5hkdfv/XOh6bA0+lJ pL+GHlhwuwDbWqxqbhJYZ5tQXjZlkfJJuqafGlv8JKAYf9zeoYdG+C6PHX8Z6MPnaufjvy3mSyOf FbbqYsaUTmpwbfBaN6DL956X459AdklxnPHxOO+9/JrbVkAAIfkEACsASQAsAACWAEQBHwAHCP8A /wkcSLCgQYEABiYEwJDhv4QEGy5U+BBixYYRKSJ8WNGgRY4bIYoECVIiyZEfTyLE6LCgxYUmJU7c qPAlRZsTc2qkqXKnTI4/L8KsifGg0aNIkypdypTnzJ0qba4k6dLnyY9Yb9J8yrXnU6c9O1pNSRbq TJxadUoFyzNsyKpOvzadS7euXbBox5p1u/ZrVr0lo2plm/Ft279AByc+bHhx4K17CYfV2Tjr2ruY 79rbzLmz58+bTa582VJ0zJYXPXaFmTK165FAiwqd7FHjabKyc5eOLLYkaqmXxco+vNv1bN0QQStf zry58+fQN2eeTn1pa6XXq2vfzn169O/gw4v/t9e9/PTsSNGbX8/e/Pj38NvLn0+/vv379Fnh38+/ v///AAYo4ID7qdcWZmVBpZ2B5xEYIIPzQchUcAjCVViDF1JloXUKTuihXRSWBx95DiYlIYfdMXhi ehuuyOKBH2J3l1QjNneeQ7+VJtJuWCEHmW+47RjkaLBRxVJqOSaIUlFCzuaSjkWeNZxpiYnm5GhX Doclk0k+hlduHZYIm5JRJejYWY0ZJVdVeRk5GEqRwfkWYogJNidvQ53JF2BuWpWmXG1GWWJtj1HZ 5lgxVdlbREeqhqNtGua15JSKokVnhoHqyedqeN5kZW99Gdlapm6tN+KYXtl5IaCKTsXnpmna8iln bWqltSqmilHWp56kErYmo7RZZmFXPdVorHKoAqcqrKVeOmquHUpa2bB47VpnpsRWO+1loYaYrV+M TWvUscphOCaTWGro1W+2oUbUjk8+KllNi5377I/1yhsplO8C2WNxmn7aEXDuGsfvlmaxBCaMg8bY 8IsPO+jifRNHfFTFA2JscYoFi7nxxyCHLPLIJJds8skop6zyyiy37PLLMPsnQ0Hk1mzzzTjnrPPO PPfs889ABy300EQXbfTRSCet9NJMN+3000K/AXVnvUxt9dVYZ71zL1Vr7fXXYIetHNdil2322UM4 3bXTMbft9npclxgQACH5BAArAEkALAAAtABEAR8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEix okWIvXpd3Mixo8ePIEOKHEkSY0mJ9lKqXMmypcuXMGPKnEmzps2bOHPq3Mmzp86MPoOqPEm0qNGj SJMizKjUoNCnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rFmyTdOqXcu2rdu3cOPKnUu3rt27ePOq Pcu3r9+/gAMLHky4sOHDiBMr7qu3sePHkBMu5ktusuXLKSNr3sy5s+fPoEOLHk26tOnTqFMb9Ska c+B/rqNy/ED7g0jbBmkTxK26t++JvEcGH6ib+G+JJI6fHv4vuO3nzaM3ry3wefHaw6FXr05dunfc 3ZWLjvfM3Pl07tuNF5fOPDpv7dvfqx9P363P8ru/G5+/vz34+Pm5J6B3sMVm4IEtXYQff99hBx97 B8lnHXYAwrdefRgilVI4Oy0IYHoEgghhbvP5J2B2BSKo4oo6hfiehft9mJ6JxD0on4jbsajjZbN1 Rx2MNV4X4HlDEklhjC+2l+GSI7EW2o5QKsbklFSSFBAAIfkEACsASQAsAADSAEQBHwAHCP8A/wkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKdGeyZMoU6o0SbKly5cwY4pcSbOm TZYycy4EoLOnTp4fgfpceLMogKNCCyZViHRpw6YVnf6TyhQqQ55UCSLFmNWh065NsV59CrVrw6Jo 06pNKVSqWYFvE8Yda3DuQLtan2bEe5Dv0rd2215cS/jkRcFTj8JVLDYx0L93HUOuq9hx4sWVH2fe 3LYyXMqMI2MN/Tmv5NJTMd9lzHr0as2c81qNbHqr6q2NbaOebVssbr4VC7MVTXzxbtWpPyNGTTv1 Y+XEBS9vrLR3cefJs0+Wfp269tLUw2f/767VOvfmntGrl/48OU/hhA/3LqueOXbozL8Wf849rPay +pl2H3ZJeQcebbkBWB9/9OEnW3PjOdfgca9NJ9qE7QEn02T1ffeggwXWtR+IA1JYnYDH9fdhbQi6 15d4LnJo4IAhrphfhxY6SGF7Q+2kFHkmkricfefxFx2Q49W43pEotmjikDAaKaSIUP543pM4kocY jzPBZ9JXnpGGHG+4QYgZbAdKmBlyl1nmZoWwxenekLd16KZupGW4JnghQtkgnpslieeCe7qYmpdq 9ZiThhbNxaiikEZaEKL2SArRoxQ5aummIFHqaVGchirqqDB9aupKpKaq6qoYneqqYaz2/xigqpiO RJVdr746249kpXepry/FtR2gYqopLJ2XhqqkWULl6iqyESJUq30wCcvrlTdCeyK1D00L0rI+CuQs SochGFuCXH63q4injbnmaGG+6y6aZwqIbZL4MmWodfuGWZ2c7d55Ybz0BmwZmQUrq+VqOxYKY18p 2tvmla5ZueSNDXPpHbMxjlgitzSqu7COFEtMZLScWuVfjhGKp62hJZY8ZYX/lYmxwSTny2bHKxPY ppkYijxzzEFneZq3ZyHKIZYnywyx0BFHHTKJJgdp8XUos2igb/9BWPLXI598M9jijvupjB6mPXS6 MG+MpMsXQw2utPi+jF6UQHsdNtxDy4JdNd//mH02aAwXyFlnYqZr85z0Io54fvOxua7ixAIc7sT+ 8ols0FsSHGVs9ZbnocrvCU5pT0g3SVLqLrFuqemnLxrUhqy6/rrgseau++6rxs7778ArCjuqGtnu EaPAyiWR8T4lv/xewNsNqYbS60iX9S86b+ZVYGq/fVT/zki3TwEBACH5BAArAEkALAAA8ABEAR8A Bwj/AP8JHEiwoEGBAAYmPMiwocOHEBFGNLjwX0WHCS9CvJhxI4CPDzV6pPhRJMWJETWW7JgSpUuX 9mLKnEmzZsyKJl/q1Jkz5MueDUUCtbhzIsiCOH0WPakQqVGCNqNKnUq1qtSSFrEiPEpQq1eQR1cq DOu16ViuWrNyBKsWZ1iiYtWe5Si3rkSkb1mmTXtXZVO9ZBeW7SgYLV+Vgc8SJfqoseNHViNLnmwv qUTLdzPrvWz2r+fMi0NzZgq3M2e6STGXBt317WXBoVky9ftac+y/hW2rrotZ9mqbj4NTHi65d1u6 nTevXizWsu/bbbOSll2YrfPmpqkDzYj9NVauXVnH/3X7fS5189BPGl87kLj79zXXM0S+Gnbqz8xF 3+5N//x92OJlpx944dG2XGutxRXgggMm5xRr+N33GXwUvicfaP3lt5x/Dj64YXgOSliabyKiRppT JaYnGn0N6hZihx8edN5off1TIXFLjQUdX1tVVyNce5Vnm4fVcWfgjNgZ6WOPyIFFoIJl9ZUYiBh6 yFuCQ/Y4V4JuaanlbjnCBF+YKA0lI5lopqnmmmy2+dCNcErm5pk/zWnnnXjm2WacfFKl55+ABiro Un0Wauhwgyaq6KKDHuroo1ItZSajek6qn5qW5gnpppGFqeBTaRIYqKUzkiQkRil1R+mqrG5kmquh Zv/apqxgMhhUma+2qiubFKYImJKKecmjhtH9Gux35DHp5Y+EOfnkg0EaWR945CU7opO8cqptpDn6 CmCWNKqoYWrfcpifr7OdBmN0H/YnFIz+AfjtrvSuOV6EVBYpHZO0lRtbc93Zp+pzIxYMrl8rkZjd XiEO/GO9EKN5pIopbnUpv+a2aJZ9RF5KmMEUo2ilcVmKOOS8EdPba8eqVUwjixmjey6+JjmXHovt 5gvviy8zO93ONm4rNJ9CnSrXdc4GK2CxWArLrGvMTRw1xQEblttaaHUY5bgQkgzd0GDHlDKZso6d ctlmp73rsGq3DaHbjYYt99x012333XjnrffefPcpPRXcgAcu+OCEF2744Ygnrvjibfvt+OOQR/4o 45RXbrni9Fyu+eYQBQQAIfkEACsASQAsAAAOAUQBHwAHCP8A/wkcSLCgwYMIEypUSG+hw4cQI0qc SLGixYsYM2p8aK+jx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcOXOjzZs4c+rcybOnz59AgwodSrSo 0aMCaSpdyrSp06dQo0ptirSq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27cKp8qdS7eu3bt4 V8Ldy7evzryAAwseTLiw4cOIEytebNKv48eQITKeTLmy5cuYM2vuSG2z58+gQ4uuGbm06cijU6te zbq169eIT8ueDVcm7du4EULVma9i77G/s+YLDnH4wd7EkSb3a/vfcOPLH0YHOh1h9aLXrSdEjjW7 0MXOC3r/P350/EDz1ClW534Vvc/dGJcjNy7weXD74euLP1//uX7+7BHkH37O+dcfdPyJRx+BxHH3 G4MGCjiggQEeSJ9+FYZHYX4EFvjghRha+F+HEVJYIogiaohiTjLJd19+IQr4n4wx1qiiQcm9COB+ MCY4o4YyLsjjjyMGGd2DQfZYIIBI7uijgj86SKOTUSr55Hz8wXeRfElSaWOXDfaYIZE6fjmmmF3W mOOUCYY5XZMhrkmlm2xOSWeYaaL5Zp7uEcUlk/jluB6HfFrZn490SrgdnEDOqWCHbeZJ451DNuqh ief9eSmC9i2I6aYf4ljoV5pa+qSpYBZ6HZyJeilqq5bKFrldlXvqqWSrg55apqswwlqprafiFBAA IfkEACsASQAsAAAsAUQBHwAHCP8A/wkcSLCgQYH5DCYcmHAhQYcI/0F8KDEiw4oXJxZc6BBiw40Y D1b0GHLkRYoiLZLUqJLiR5QRO6YkCVPjy5ouZ4LMCDOlz59AgU5cmRMly5BEEd48yPFkzJ1HTfJU inSnRaNFFV7N93FoVppXS1blmbTkUrBhzwZdy7YtV65mlcKVe5Olx7cM4S7Ne5cu37ob50rEK1eq 38GCaxI+2lGvYbpN/xZGrFUyxreN9QrGPDnwXLRtQ4seTVps6dOoU6t2u7q169dr7cmeTbu2bdmw RUbNzbs3792+gwe9Tbw4ceHIkytfzry58+fQo0ufTr36QOPYcfe0nhu4au/Ws4v/H0++vPnzs1PL tLo6sunR4J3Khyza/dr4rJly318QPe2xyOF3X37bxZWfgL/pJpB/DDboYIOocdbQZ51Ztp6EiHVF GX2eZXiYhxdWdhJnIyXm4UN4LTYZYShSmBGL8/EXHoSNkaXgiJdB9eJUYYm13lNY9ehjXJux55RM aunHY45KPujkk1BGaQ+AJjGGlX1MPpbkfD8+pqWIQIY5pIhIGghmklb+I+WabLZZHJUvmZhhkT26 pxZogx2ZFVUFelXWmFaVmSefPaF5o5uIJiolnGYKKZVXVf2ZZpd7bcklkdvZpSdakIqJ5UmKhpqo evJZamCcOnqK1KSljrkbTZIakrnVkqCV5aKMuHZ354ae2elXjWg61iKKH2LYUq933WqaiT929Zmc J1JWo6y5Vmstgddmq+2MDFpL4rbgqinquGuGa+656FZL7rrstuvuu27SM2q69NZrL3Pw5qvvvvz2 6+a9AAcs8MAEF2ywcP4mrPDCDDfs8MMQRyzxxBRXbPHF/h2s8cYcd+zxxyCHLPLIqwUEACH5BAAr AEkALAAASgFEAR8ABwjtAP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnR nsmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnPklKnUq1qtWr WBFC3cq1q9evYMOKHUu2rNmzaNOqXfszq9u3cOPKnUu3rt27ePPq1attr9+/gAMLHky4sOHDiBNf ZMu4sePHkCNLnkxWseXLmEVS3sy5s+fPoEOLHk26tOnTqFMzzcy6tevXsGPLpqi6tu3buHPr3s27 99nZwIMLH068+FvfyJMrX868ufPnjAMCACH5BAArAEkALAAAaAFEAR8ABwj1AO0JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnxn8mTKFOqXMmypcuXMGPKnEmzps2bOHPq3MmT J8mfQIMKHUq0KMKeSJMqXcq0qdOnUJcanUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3 cOPKnUu3LteoePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPMe2K Hi0atOnTqGWSXs26tevXsKmmnk27tu3buHPr3s27t+/fwIMLH550IIDYyJNXPQmAuPPnPZtDn/6y EXWTAQEAIfkEAP//SQAsAACGAUQBHwAHCP8A//0DILCgwYMIEypcyLChw4cQI0qcSLGiRYSNLmrc yDGiPXsAPoocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs3Q+LcybOnz59AgwodilMgwY5IkypdyrSp 06dQO4IkSrWq1atYs2ptGbWr169gw4odK3Gr2bNo06pd+5Gs27dw48qdS7eu3bt48zZky7ev37+A UeodTLiwYaiBE9scorix45SHI0ueTLmy5cuYJT/ezLmzZ8GZQ4se7fWz6dOo/5Jezbq169ewYytN Tbu2bauyc+vezbu377u3gwsfTry48eM9fytfjhe58+fBmUuf/ha69evYs2vfzr279+HUw4sD7xoQ ACH5BAAmAEkALAAAAABEAagBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDH+28ixo8eP IEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3MlzZcafQIMKHUq0qNGjQnsqXcq0qdOnNY9B nUq1qtWrWLNq3cq1q1edSMOKHUu2rNmzEL+qXcu27U60cOPKnUu3rkC3ePPq3SvSrt+/gAMLHky4 sOHDaPkqXsy4sePHkCP7REzZ3pDKmDMblMy5s+fJmkOLHk26tOnTqNN+Xs269b/UsGPLnk27tu3b uHPr3s27t+/fwIMLH068suvjyJMrX868ufPn0DsWn059aPTr2JlW3869u/fv4MOL/x9Pvrz17OjT q1/Pvr3794rdwJ9Pv7599ubz69/PX/b9/+v1J2BvABaY3YAI5mbggtAl6GBtDEbI3IMUxibhhRhm qOGGHEZY4YendSjiiCSWaOKJjIGo4oostujii5ShKOOMNNoH44045ghejTz26OOPQAYp5JBEFmnk kUgmSZ+OTM6l5JNQrrbAkk1WeVaURk6C5ZZcdrmUlWCGKSZqXpbJ0ZhopqlmYWa26eabcCq55px0 1mnnnYTFuSWefC6kJ5Z9BnoQg5wUauihnPw5I6KHKqqUoJBm9k6k1Dlq6aUnUqrpppx26umnMGKq XCGilmrqqaimquqqrDoG6quwxv8qq0HIfNfqrbg2OGuaudaoaSO7Bstir8QWa+yxyCar7LLMsiTs mM1GK+20mD5r7bXiUZshttx2a08uxf3pzYUUaAult0yaq+667CKJro7tLvjuvPTiFu+9+IJWb4v5 9uvvvx7u6yLAVAps8MEIJ6wwiAQ37PDDEEcs8WoLV2yxXxNnrPHGHHfsMU4XP/ixriGXbLJYIzeV glYnD5jyy6q2LCDMNNds8833ydwfzsfpzB/PQAct9EY+F220REN/drR5STcd5dLlOS311FTzvM9X UGet9dYUXUJg1WCHLfbYMnG9I9l8ma02pZ2szSvacJfo9tx01+1f3HmFBwAAdpv/JchlRtbc93Zp+pzIxYMrl8rkZjd XiEO/GO9EKN5pIopbnUpv+a2aJZ9RF5KmMEUo2ilcVmKOOS8EdPba8eqVUwjixmjey6+JjmXHovt 5gvviy8zO93ONm4rNJ9CnSrXdc4GK2CxWArLrGvMTRw1xQEblttaaHUY5bgQkgzd0GDHlDKZso6d ctlmp73rsGq3DaHbjYYt99x012333XjnrffefPcpPRXcgAcu+OCEF2744Ygnrvjibfvt+OOQR/4o 45RXbrni9Fyu+eYQBQQAIfkEACsASQAsAAAOAUQBHwAHCP8A/wkcSLCgwYMIEypUSG+hw4cQI0qc SLGixYsYM2p8aK+jx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcOXOjzZs4c+rcybOnz59AgwodSrSo 0aMCaSpdyrSp06dQo0ptirSq1atYs2rdyrWr169gw4odS7as2bNo06pdy7at27cKp8qdS7eu3bt4 V8Ldy7evzryAAwseTLiw4cOIEytebNKv48eQITKeTLmy5cuYM2vuSG2z58+gQ4uuGbm06cijU6te zbq169eIT8ueDVcm7du4EULVma9i77G/s+YLDnH4wd7EkSb3a/vfcOPLH0YHOh1h9aLXrSdEjjW7 0MXOC3r/P350/EDz1ClW534Vvc/dGJcjNy7weXD74euLP1//uX7+7BHkH37O+dcfdPyJRx+BxHH3 G4MGCjiggQEeSJ9+FYZHYX4EFvjghRha+F+HEVJYIogiaohiTjLJd19+IQr4n4wx1qiiQcm9COB+ MCY4o4YyLsjjjyMGGd2DQfZYIIBI7uijgj86SKOTUSr55Hz8wXeRfElSaWOXDfaYIZE6fjmmmF3W mOOUCYY5XZMhrkmlm2xOSWeYaaL5Zp7uEcUlk/jluB6HfFrZn490SrgdnEDOqWCHbeZJ451DNuqh ief9eSmC9i2I6aYf4ljoV5pa+qSpYBZ6HZyJeilqq5bKFrldlXvqqWSrg55apqswwlqprafiFBAA IfkEACsASQAsAAAsAUQBHwAHCP8A/wkcSLCgQYH5DCYcmHAhQYcI/0F8KDEiw4oXJxZc6BBiw40Y D1b0GHLkRYoiLZLUqJLiR5QRO6YkCVPjy5ouZ4LMCDOlz59AgU5cmRMly5BEEd48yPFkzJ1HTfJU inSnRaNFFV7N93FoVppXS1blmbTkUrBhzwZdy7YtV65mlcKVe5Olx7cM4S7Ne5cu37ob50rEK1eq 38GCaxI+2lGvYbpN/xZGrFUyxreN9QrGPDnwXLRtQ4seTVps6dOoU6t2u7q169dr7cmeTbu2bdmw RUbNzbs3792+gwe9Tbw4ceHIkytfzry58+fQo0ufTr36QOPYcfe0nhu4au/Ws4v/H0++vPnzs1PL tLo6sunR4J3Khyza/dr4rJly318QPe2xyOF3X37bxZWfgL/pJpB/DDboYIOocdbQZ51Ztp6EiHVF GX2eZXiYhxdWdhJnIyXm4UN4LTYZYShSmBGL8/EXHoSNkaXgiJdB9eJUYYm13lNY9ehjXJux55RM aunHY45KPujkk1BGaQ+AJjGGlX1MPpbkfD8+pqWIQIY5pIhIGghmklb+I+WabLZZHJUvmZhhkT26 pxZogx2ZFVUFelXWmFaVmSefPaF5o5uIJiolnGYKKZVXVf2ZZpd7bcklkdvZpSdakIqJ5UmKhpqo evJZamCcOnqK1KSljrkbTZIakrnVkqCV5aKMuHZ354ae2elXjWg61iKKH2LYUq933WqaiT929Zmc J1JWo6y5Vmstgddmq+2MDFpL4rbgqinquGuGa+656FZL7rrstuvuu27SM2q69NZrL3Pw5qvvvvz2 6+a9AAcs8MAEF2ywcP4mrPDCDDfs8MMQRyzxxBRXbPHF/h2s8cYcd+zxxyCHLPLIqwUEACH5BAAr AEkALAAASgFEAR8ABwjtAP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnR nsmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnPklKnUq1qtWr WBFC3cq1q9evYMOKHUu2rNmzaNOqXfszq9u3cOPKnUu3rt27ePPq1attr9+/gAMLHky4sOHDiBNf ZMu4sePHkCNLnkxWseXLmEVS3sy5s+fPoEOLHk26tOnTqFMzzcy6tevXsGPLpqi6tu3buHPr3s27 99nZwIMLH068+FvfyJMrX868ufPnjAMCACH5BAArAEkALAAAaAFEAR8ABwj1AO0JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnxn8mTKFOqXMmypcuXMGPKnEmzps2bOHPq3MmT J8mfQIMKHUq0KMKeSJMqXcq0qdOnUJcanUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3 cOPKnUu3LteoePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPMe2K Hi0atOnTqGWSXs26tevXsKmmnk27tu3buHPr3s27t+/fwIMLH550IIDYyJNXPQmAuPPnPZtDn/6y EXWTAQEAIfkEAP//SQAsAACGAUQBHwAHCP8A//0DILCgwYMIEypcyLChw4cQI0qcSLGiRYSNLmrc yDGiPXsAPoocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs3Q+LcybOnz59AgwodilMgwY5IkypdyrSp 06dQO4IkSrWq1atYs2ptGbWr169gw4odK3Gr2bNo06pd+5Gs27dw48qdS7eu3bt48zZky7ev37+A UeodTLiwYaiBE9scorix45SHI0ueTLmy5cuYJT/ezLmzZ8GZQ4se7fWz6dOo/5Jezbq169ewYytN Tbu2bauyc+vezbu377u3gwsfTry48eM9fytfjhe58+fBmUuf/ha69evYs2vfzr279+HUw4sD7xoQ ACH5BAAmAEkALAAAAABEAagBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDH+28ixo8eP IEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3MlzZcafQIMKHUq0qNGjQnsqXcq0qdOnNY9B nUq1qtWrWLNq3cq1q1edSMOKHUu2rNmzEL+qXcu27U60cOPKnUu3rkC3ePPq3SvSrt+/gAMLHky4 sOHDaPkqXsy4sePHkCP7REzZ3pDKmDMblMy5s+fJmkOLHk26tOnTqNN+Xs269b/UsGPLnk27tu3b uHPr3s27t+/fwIMLH068suvjyJMrX868ufPn0DsWn059aPTr2JlW3869u/fv4MOL/x9Pvrz17OjT q1/Pvr3794rdwJ9Pv7599ubz69/PX/b9/+v1J2BvABaY3YAI5mbggtAl6GBtDEbI3IMUxibhhRhm qOGGHEZY4YendSjiiCSWaOKJjIGo4oostujii5ShKOOMNNoH44045ghejTz26OOPQAYp5JBEFmnk kUgmSZ+OTM6l5JNQrrbAkk1WeVaURk6C5ZZcdrmUlWCGKSZqXpbJ0ZhopqlmYWa26eabcCq55px0 1mnnnYTFuSWefC6kJ5Z9BnoQg5wUauihnPw5I6KHKqqUoJBm9k6k1Dlq6aUnUqrpppx26umnMGKq XCGilmrqqaimquqqrDoG6quwxv8qq0HIfNfqrbg2OGuaudaoaSO7Bstir8QWa+yxyCar7LLMsiTs mM1GK+20mD5r7bXiUZshttx2a08uxf3pzYUUaAult0yaq+667CKJro7tLvjuvPTiFu+9+IJWb4v5 9uvvvx7u6yLAVAps8MEIJ6wwiAQ37PDDEEcs8WoLV2yxXxNnrPHGHHfsMU4XP/ixriGXbLJYIzeV glYnD5jyy6q2LCDMNNds8833ydwfzsfpzB/PQAct9EY+F220REN/drR5STcd5dLlOS311FTzvM9X UGet9dYUXUJg1WCHLfbYMnG9I9l8ma02pZ2szSvacJfo9tx01+1f3HmFBwAAdpv/JchgfN/mSd8M 7V0UDs/+BwBeouC9d7z7Bd7ygo+rK6DkhGeu+eaca4T35xt2/hvobolueuKks3U6b6mrvrpurccu u6Ov1/7q7LjnbqbtvPfu+2a6s/z7bMEXb7y7w999fFXJK7/8VM1HL/301Fdv/fXYJ/T89s5l7/33 F3MPPfiYiW8+cuSnz/D5Tanvvsjsa/e+YfHLP//9+9Wvv2T49++/p/sLoADf87/ADPCACMROAQGT wJss8IHdaaBNIGgXCVpwIxe4oGcoWBcNevCDj+GgCEdYJRCaECokTOHXTsjCR6nwhTCsUAv1FcMa 2jA/M1TJDVGWF2Lk0Hg7DKIQwYcIr/pNoSdELMoPUZJEoizxiVCMohSnmKImWvGKWMzib3SgRdNQ 8YtgdAlZrNHFMpoxKWFMI420oawzutEsakTP4uL4j8rFcW9zvGMe1YjHhoHHcG+UCCCPRsdCGvKQ cQwk0hCZRkVyqgGOjKQkzcbIRk6SIYW8JCbpqMlOViSTnkQIKEMJvESSspSVfE4ZJHbKVrrylbCk SCrBGMta2vKWuMTMCK43ylz68peBnOUXa9lLYGpyJO0QpjKXWb9aBgQAIfkEACYASQAsAAAAAEQB qAEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKfGfyZMoU6pcybKl y5cwY8qcSbOmzZs4c+rcyZMnyZ9AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1asje2rdyrWr169g w4odS7as2bNo06pdaxKr27dw4xJkS7eu3bt48+rdy7ev37+AAwseTLiw4cOIE3+Vy7ix48eQI0ue nFCx5cuYM2vezLlzS8qgQ4seTbq06dOoU5P2zLq169ewY8ueTbu27du4c+vezbu379/Agwsfblm1 8eNWiStfzry5863Io0tv+ry69enYsxN1Wc26997aw4v/H0++/NTv6ImbX8++vfv3FdPLBw6//vv5 +PPr32/Yvv/1/AUo4IAEFmjgd/8lqOCCDDbo4IMQRihhZQdWWNyEGFJm4YaIZeihQyR8KOKIJJZ4 FYcoEmbiilWl6OKLMHrH4ow01mjjjTjmqCNUMfbo449ABvnijkT+JOSRZRWpZEhINhnWklB25OSU XUVp5ZVYZqmlW1R26eVNVXwp5phklmnmmWimqeaabLbp5ptwxpnXlnTWaeedeOap55589ulnSXIG KmiMf9Y5aHpkmFXooozmeKiXjVLWTKSUVmrppZhmqummnHYa2aNehQPqqLt56iipTZp6VQSqtvoR qqm6/yrrrLTWauutuGJHQa4jwurrr9XxKiKwxBZr7LF7Cavsssxmah00yEYr7bTBNmvttdjmSe22 3Hbr7bfghntYtuSW65G4BZqr7rrssoguge3GK++89NZr7734vqvvvvz2629n+LL378AE66sHkgEn rPDCDHNasHwNi/fwxBRXLGDE4Vl8HcYcd+zxxyCHLJDG1UalisivkqzyyizTh/LLlbYsc78w12zz zTjnTBkh5M2sns6i+Twc0EELbfS3RCettMdHu7z0p0379vRjJUxt9dVYZ611eVF37fXXYIct9tiz bW322cqSbRvabH+o9ttwxy1T23QrFErdeOett0Vyc/82zt+A/923YoELPvjhb+6tuH+IN+6414tH LvnklFduOZOPc3b55pzbmLnmnRf1+eikxwQAAKVjdnrql62OtIen52qh69SWGHvoRN2Ou1AA7O77 78DzzfrwxKMb/PHIxxuAvcV3mDULcqlkR/PUVw9s8iI9t4fG2GNuvWDd/+mErN+Xb/756KevPsDh t5/c+jvVA/9r7td/3vx4MWL/Rvj377+T+wugAAdIQAj9zy4FTKAC33fABjrwgaNaoASzAsEKWvBi E8zguS7IQc9o8IP866AINQPCEprwhChsSjhSWJARuvAyLIzhQl74JBkOhIZgseENXUgAHPrwh0AM IqmYdEhE6TSgiEhMItOEyMSwheKJUIyiFKPYxCpacVpKzGIKr5gTLXqxhFwMoxgB88UyUgQCZuTc GGuSRhOukSZFfONM4ijHOmqljWC0ox51QkfPeOBwfWwaNUqFxwnRoJAx26MibYJIDS6SJY2MZPge SclKWpJltrhkhSQpQU168iScXOAnPxlIS5aykqcc5SM16I1QsvCTAQEAIfkEACYASQAsAAAAAEQB qAEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKfGfyZMoU6pcybKl y5cwY8qcSbOmzZs4c+rcyZMnyZ9AgwodSrQowp5IkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169d jYodS7as2bNo0y6MoLat27dw48qdS7eu3bt4804Ey7ev37+AW+odTLjw2cCIEyteDNWw48eQRTKe TLmy5cuYM2umHLmz588lN4seTbq06dM23aBezXrrg9awY8uebRq07du4BdLezfty7t/AgwsfTry4 8ePICfZezhxx8ufQo0ufTr269evYs2vfzr279+/Tm4v/H0++vHne4NOrX8++vfv38OPLn08/+Pn7 +PPr38+/v3/O9QXo2H8EFmjggQgmqOCCDDbo4IMQbiXghBRWaOGFGGaoYXsRdijbhiCGKOKIJJLo 4YmslahiUCi26OKLMMYo44w01mijfj/cqOOOM63o40ij9cCjgj8WaeSRcQ2ppIRINmnRklBe5eSU e0Vp5U7wXKklk1R26eWXYIb50ZZkLiXmmQOVqWZPaN41QHRrxplTm2fKaeedeOapZ1V0irnnn4AG KuigJ/UZJqE74oDooow26uijkEYq6aSUVmrppZhmCqihnHZapKaghirqqH152iWpO5pKJao6qjol q7DG/yrrrDW56iStuOaq6668Omhrk72i+CuSwZ447LE+hgJsscw2SxWy0EYr7bTUVkuSs9hmq+22 3HY7qLXghivuuOQi6+256ApW7rrstuvuQuka+C6F8RY474T15nvuvfz225a+AG/r78AEixXwwQgn rPDCDJdaMHwNRyzxxBRr+TDEFTN38cYce5TxxyCHzFTHJJdckci7mazyyizLhzJtLXf38mwxczfz hzVrd3NsOeu888+PYgE0a1gIPTRqRh9tWtFKn8Z004BNhEXP2RVNNXZTX22d1Vp3BnVpXYctNpq6 jB3E2Ghn9/XaV6bt9ttwxy333HTXbffdeOfNL9t89//t99+ABx6n3rmZJoDgiPOVnDOEN+7445BH LnmGiU82+eWYa1355pxjmvmAnQPNRuikh5pK6Q9+bhjqf6nuuois+/X6YLE7PPvtuH/USu689+77 78CTXLviwRdvvKnDJ4/f8czLrHxYzaf1/PTjRS+9TjdQP6f13Hd/pPbgo+f9+OSXb77b4aev/vrs 93o+QsK8Lz+H7ddv//1Lzq///vyvir9T/bvW/5oSQCDRpAsDTKACR1PABuqlJ9ZYoATN5MAxjUYY E1ReBTdIlwx68IMgDCGDOEjCEv5GhCjkkwkzgpQqSHCFMLRILGJIwxoeJ4U4zKEOfWPDHoIkDwXZ oUy2fEhEAwrxiDsp4kYAoMSHAICJTWzIE6MoRSja0CZPFCFFphhDJL6EimC8iBfHSMakhPGMVSqj GtdIEzQehY2FcqMcGQLHOM4xTXXMo0mI84659eYd+/mAvgBZR0Ky0ZAZA04f78hIx8VmHjNrpG7y KMlK2sM0rVBaJfWoR0tKspOeDKUcbbQCTprylKB61zMkwgzn1VGUd0QlGzdJSVjakoqgbKQs10jL XfpSh72E4y2HqUQ9BgQAIfkEACYASQAsAAAAAEQBqAEHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcqdGey5cwY8qcSbOmzZs4c+rcybOnz59AgwodSpQo y6NIkypderSo06dQo0qdSrWq1atYs2rdyrWr168umYodS7as2bNo06pduxKs27dw48p1y7au3bt4 8+rdygfN/mSd8M 7V0UDs/+BwBeouC9d7z7Bd7ygo+rK6DkhGeu+eaca4T35xt2/hvobolueuKks3U6b6mrvrpurccu u6Ov1/7q7LjnbqbtvPfu+2a6s/z7bMEXb7y7w999fFXJK7/8VM1HL/301Fdv/fXYJ/T89s5l7/33 F3MPPfiYiW8+cuSnz/D5Tanvvsjsa/e+YfHLP//9+9Wvv2T49++/p/sLoADf87/ADPCACMROAQGT wJss8IHdaaBNIGgXCVpwIxe4oGcoWBcNevCDj+GgCEdYJRCaECokTOHXTsjCR6nwhTCsUAv1FcMa 2jA/M1TJDVGWF2Lk0Hg7DKIQwYcIr/pNoSdELMoPUZJEoizxiVCMohSnmKImWvGKWMzib3SgRdNQ 8YtgdAlZrNHFMpoxKWFMI420oawzutEsakTP4uL4j8rFcW9zvGMe1YjHhoHHcG+UCCCPRsdCGvKQ cQwk0hCZRkVyqgGOjKQkzcbIRk6SIYW8JCbpqMlOViSTnkQIKEMJvESSspSVfE4ZJHbKVrrylbCk SCrBGMta2vKWuMTMCK43ylz68peBnOUXa9lLYGpyJO0QpjKXWb9aBgQAIfkEACYASQAsAAAAAEQB qAEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKfGfyZMoU6pcybKl y5cwY8qcSbOmzZs4c+rcyZMnyZ9AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1asje2rdyrWr169g w4odS7as2bNo06pdaxKr27dw4xJkS7eu3bt48+rdy7ev37+AAwseTLiw4cOIE3+Vy7ix48eQI0ue nFCx5cuYM2vezLlzS8qgQ4seTbq06dOoU5P2zLq169ewY8ueTbu27du4c+vezbu379/Agwsfblm1 8eNWiStfzry5863Io0tv+ry69enYsxN1Wc26997aw4v/H0++/NTv6ImbX8++vfv3FdPLBw6//vv5 +PPr32/Yvv/1/AUo4IAEFmjgd/8lqOCCDDbo4IMQRihhZQdWWNyEGFJm4YaIZeihQyR8KOKIJJZ4 FYcoEmbiilWl6OKLMHrH4ow01mjjjTjmqCNUMfbo449ABvnijkT+JOSRZRWpZEhINhnWklB25OSU XUVp5ZVYZqmlW1R26eVNVXwp5phklmnmmWimqeaabLbp5ptwxpnXlnTWaeedeOap55589ulnSXIG KmiMf9Y5aHpkmFXooozmeKiXjVLWTKSUVmrppZhmqummnHYa2aNehQPqqLt56iipTZp6VQSqtvoR qqm6/yrrrLTWauutuGJHQa4jwurrr9XxKiKwxBZr7LF7Cavsssxmah00yEYr7bTBNmvttdjmSe22 3Hbr7bfghntYtuSW65G4BZqr7rrssoguge3GK++89NZr7734vqvvvvz2629n+LL378AE66sHkgEn rPDCDHNasHwNi/fwxBRXLGDE4Vl8HcYcd+zxxyCHLJDG1UalisivkqzyyizTh/LLlbYsc78w12zz zTjnTBkh5M2sns6i+Twc0EELbfS3RCettMdHu7z0p0379vRjJUxt9dVYZ611eVF37fXXYIct9tiz bW322cqSbRvabH+o9ttwxy1T23QrFErdeOett0Vyc/82zt+A/923YoELPvjhb+6tuH+IN+6414tH LvnklFduOZOPc3b55pzbmLnmnRf1+eikxwQAAKVjdnrql62OtIen52qh69SWGHvoRN2Ou1AA7O77 78DzzfrwxKMb/PHIxxuAvcV3mDULcqlkR/PUVw9s8iI9t4fG2GNuvWDd/+mErN+Xb/756KevPsDh t5/c+jvVA/9r7td/3vx4MWL/Rvj377+T+wugAAdIQAj9zy4FTKAC33fABjrwgaNaoASzAsEKWvBi E8zguS7IQc9o8IP866AINQPCEprwhChsSjhSWJARuvAyLIzhQl74JBkOhIZgseENXUgAHPrwh0AM IqmYdEhE6TSgiEhMItOEyMSwheKJUIyiFKPYxCpacVpKzGIKr5gTLXqxhFwMoxgB88UyUgQCZuTc GGuSRhOukSZFfONM4ijHOmqljWC0ox51QkfPeOBwfWwaNUqFxwnRoJAx26MibYJIDS6SJY2MZPge SclKWpJltrhkhSQpQU168iScXOAnPxlIS5aykqcc5SM16I1QsvCTAQEAIfkEACYASQAsAAAAAEQB qAEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocKfGfyZMoU6pcybKl y5cwY8qcSbOmzZs4c+rcyZMnyZ9AgwodSrQowp5IkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169d jYodS7as2bNo0y6MoLat27dw48qdS7eu3bt4804Ey7ev37+AW+odTLjw2cCIEyteDNWw48eQRTKe TLmy5cuYM2umHLmz588lN4seTbq06dM23aBezXrrg9awY8uebRq07du4BdLezfty7t/AgwsfTry4 8ePICfZezhxx8ufQo0ufTr269evYs2vfzr279+/Tm4v/H0++vHne4NOrX8++vfv38OPLn08/+Pn7 +PPr38+/v3/O9QXo2H8EFmjggQgmqOCCDDbo4IMQbiXghBRWaOGFGGaoYXsRdijbhiCGKOKIJJLo 4YmslahiUCi26OKLMMYo44w01mijfj/cqOOOM63o40ij9cCjgj8WaeSRcQ2ppIRINmnRklBe5eSU e0Vp5U7wXKklk1R26eWXYIb50ZZkLiXmmQOVqWZPaN41QHRrxplTm2fKaeedeOapZ1V0irnnn4AG KuigJ/UZJqE74oDooow26uijkEYq6aSUVmrppZhmCqihnHZapKaghirqqH152iWpO5pKJao6qjol q7DG/yrrrDW56iStuOaq6668Omhrk72i+CuSwZ447LE+hgJsscw2SxWy0EYr7bTUVkuSs9hmq+22 3HY7qLXghivuuOQi6+256ApW7rrstuvuQuka+C6F8RY474T15nvuvfz225a+AG/r78AEixXwwQgn rPDCDJdaMHwNRyzxxBRr+TDEFTN38cYce5TxxyCHzFTHJJdckci7mazyyizLhzJtLXf38mwxczfz hzVrd3NsOeu888+PYgE0a1gIPTRqRh9tWtFKn8Z004BNhEXP2RVNNXZTX22d1Vp3BnVpXYctNpq6 jB3E2Ghn9/XaV6bt9ttwxy333HTXbffdeOfNL9t89//t99+ABx6n3rmZJoDgiPOVnDOEN+7445BH LnmGiU82+eWYa1355pxjmvmAnQPNRuikh5pK6Q9+bhjqf6nuuois+/X6YLE7PPvtuH/USu689+77 78CTXLviwRdvvKnDJ4/f8czLrHxYzaf1/PTjRS+9TjdQP6f13Hd/pPbgo+f9+OSXb77b4aev/vrs 93o+QsK8Lz+H7ddv//1Lzq///vyvir9T/bvW/5oSQCDRpAsDTKACR1PABuqlJ9ZYoATN5MAxjUYY E1ReBTdIlwx68IMgDCGDOEjCEv5GhCjkkwkzgpQqSHCFMLRILGJIwxoeJ4U4zKEOfWPDHoIkDwXZ oUy2fEhEAwrxiDsp4kYAoMSHAICJTWzIE6MoRSja0CZPFCFFphhDJL6EimC8iBfHSMakhPGMVSqj GtdIEzQehY2FcqMcGQLHOM4xTXXMo0mI84659eYd+/mAvgBZR0Ky0ZAZA04f78hIx8VmHjNrpG7y KMlK2sM0rVBaJfWoR0tKspOeDKUcbbQCTprylKB61zMkwgzn1VGUd0QlGzdJSVjakoqgbKQs10jL XfpSh72E4y2HqUQ9BgQAIfkEACYASQAsAAAAAEQBqAEHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcqdGey5cwY8qcSbOmzZs4c+rcybOnz59AgwodSpQo y6NIkypderSo06dQo0qdSrWq1atYs2rdyrWr168umYodS7as2bNo06pduxKs27dw48p1y7au3bt4 8+rdy9fu3L+AAwseTLiw4cOIv/ZdzLixycSQI0ueXNOx5cuYM2vezJkj5c+gQwvuTLq0ZdGoQztK 3dW069d5WcueTdsp7Nu40dbezbu3zdzAgyv1Tby48eMzSyBfDli48+cnmUufXhi69evYs2vfzr27 9+/gY1P/H08e7vUa4dMXLM++vfv38EOrn589vv37+PPrr0q/v///AAYo4IAo7WegEAYmqOCCDDZo H4EQRijhhBRWaOGFGKbk4IYcdughaxmGKOKIAX5o4okophgXiSySpeKLMMYo41At1rjUjDjmqGOO NvbY1I5AGubjkBoGaeSRSOpH5JJMNtmXgackKeWUKjpp5ZVYZqnlaVR26eWXYIYp5phkjtlEmTtt qWZEaLYZ1JpwoqVBnBC6aWdPdOap55589unnnwTdiWM9ghZq6KHVAarook0i6uhLjGIHTVmPPhqp mszdUOmmnHbq6aeg0nXpqKSWauqpqGIWqp2pNrrqq7Dq/9gqk7GWOeutuHZHnQ21Jprrr8AK1+uw xHoY7LHIJqvsssw26+yz0EYr7bTUVrtksWBaq+223HbrraI4fMsmtl6Ka+65EhEHAADkSrluu+7C mxhm66IbHgD2iiTbu/JGxli9+XqHb8AEX9vvwQhLV/B3CR+58MMQRywxtA0bOfHF1Vas8cazYQzh LR6HLPLIj3Fs8smTkazysSjPuDJwLccs88w012zzzTy9rPOtOPfss1Q73/bz0ES/GfTRSCettK5F N7g0aU1HLfXUHz5t9dVYZ30Z1VxPHTEx2nW9n9Zkbyn22UOXzSXabNustmNtP/g2Y3GLzW7d7/GL d3t67//tN2VzB06kZFz8DbTgfBmuOKjJLK4g4ok7LvnklPMH+dERmF355px37vnnoIcu+nuXly7i 6KjfaTpeqbeO5uqwxy672q7XbrvYW9Iy++68X6RTM7cHL/zJvRdv/PEdHcLs8Mw37/zz0Ecv/cbI V880rJiMab1Y0yO2/ffgO9n9YeEnNf75HJav/vokok8Y+/DHL//81v3hnfuD0a//2vhzFU7//vqI LvZHwAIa8IAIXBQAF8jABtYsgRBUiwNXFMEKUmqCb7FgS853h/xp8IPDwaAIpwPCEv5ohChMoYxM WBEVtoaFE3EhV2BIwxra8IY4zOF8ZMjDHvrQVjoMokWmfngVISqEiEj8zAcZ4bskOvGJxgEFFKdI xSpasUtGzKIWt8jFkVzxi+bp4kDASMYymvGM8RGjGteDxja6MYxqfKMc57iVNf6DjjexIx5/Y8c+ +vGPWtxjZdaIN1+4B2O+WGMioSPIRjrSaIDcYsxA8MhKWvKSUsLMPiLJyZ1h8pP20CMoR1lJUV7S lJZEJSlXSUdVPtKVrGxlJ2dpw0/S0oi2XGNAAAA7 ------=_NextPart_000_0006_01C6F30D.9F184490-- From sjxvunepbi@andorpac.ad Wed Oct 18 17:34:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ3j-00019Y-HQ for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:34:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJ1O-0006hf-65 for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:32:18 -0400 Received: from m85-94-184-218.andorpac.ad ([85.94.184.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaJ1J-00075H-Ae for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:32:18 -0400 Message-ID: <000e01c6f2fc$dbd704e0$dab85e55@as> From: "Carmes" To: capwap-archive@ietf.org Subject: tourne fait lobjet vague Date: Wed, 18 Oct 2006 23:32:06 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6F30D.9F5FD4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc ------=_NextPart_000_000A_01C6F30D.9F5FD4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6F30D.9F5FD4E0" ------=_NextPart_001_000B_01C6F30D.9F5FD4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Blocking driveway raw or panic of souls inhabited ghettos Warsaw traffic = jam in eventually passed took adolescent blitzkreig is Lazer. Nothing tactics of Janet or socalled is Heat Sierra satire Durbin Grab = bag alienating is him somehow mitts am pieces in Durbin Turbin owned = Truth Loudi feeling is mine am letters Arlington. Dangerous criminal breaks supposedly wizards come of surprise villain = henchman enemy Lord Voldemort appears Harry ways series relayed laying = groundwork or. Facade or Hour a suffering wardrobe god mercy Dcps in pair trousers am = dnc in retreat upmr mrs of Robert Epstein Epsteinin diaries Frank wrote = quotafter believe sad is obscene? Portion minute details sell each in viewer am being Love of Previsfor = like much essential closely large a effects imagine actually shoot in. Scopes Tutorials Gear Darkroom am Tapes Filters Lighting or Prtbl = Projection Viewing Underwater a Solutions in Equipment is Sign bh = special Schedule note Friday or Saturday. Promise develop or app month is proposed bold Linux moveposted Minutei = article flexible shows itunes would think Removal Adaware Webroot = Limewire Searc9fu3L+AAwseTLiw4cOIv/ZdzLixycSQI0ueXNOx5cuYM2vezJkj5c+gQwvuTLq0ZdGoQztK 3dW069d5WcueTdsp7Nu40dbezbu3zdzAgyv1Tby48eMzSyBfDli48+cnmUufXhi69evYs2vfzr27 9+/gY1P/H08e7vUa4dMXLM++vfv38EOrn589vv37+PPrr0q/v///AAYo4IAo7WegEAYmqOCCDDZo H4EQRijhhBRWaOGFGKbk4IYcdughaxmGKOKIAX5o4okophgXiSySpeKLMMYo41At1rjUjDjmqGOO NvbY1I5AGubjkBoGaeSRSOpH5JJMNtmXgackKeWUKjpp5ZVYZqnlaVR26eWXYIYp5phkjtlEmTtt qWZEaLYZ1JpwoqVBnBC6aWdPdOap55589unnnwTdiWM9ghZq6KHVAarook0i6uhLjGIHTVmPPhqp mszdUOmmnHbq6aeg0nXpqKSWauqpqGIWqp2pNrrqq7Dq/9gqk7GWOeutuHZHnQ21Jprrr8AK1+uw xHoY7LHIJqvsssw26+yz0EYr7bTUVrtksWBaq+223HbrraI4fMsmtl6Ka+65EhEHAADkSrluu+7C mxhm66IbHgD2iiTbu/JGxli9+XqHb8AEX9vvwQhLV/B3CR+58MMQRywxtA0bOfHF1Vas8cazYQzh LR6HLPLIj3Fs8smTkazysSjPuDJwLccs88w012zzzTy9rPOtOPfss1Q73/bz0ES/GfTRSCettK5F N7g0aU1HLfXUHz5t9dVYZ30Z1VxPHTEx2nW9n9Zkbyn22UOXzSXabNustmNtP/g2Y3GLzW7d7/GL d3t67//tN2VzB06kZFz8DbTgfBmuOKjJLK4g4ok7LvnklPMH+dERmF355px37vnnoIcu+nuXly7i 6KjfaTpeqbeO5uqwxy672q7XbrvYW9Iy++68X6RTM7cHL/zJvRdv/PEdHcLs8Mw37/zz0Ecv/cbI V880rJiMab1Y0yO2/ffgO9n9YeEnNf75HJav/vokok8Y+/DHL//81v3hnfuD0a//2vhzFU7//vqI LvZHwAIa8IAIXBQAF8jABtYsgRBUiwNXFMEKUmqCb7FgS853h/xp8IPDwaAIpwPCEv5ohChMoYxM WBEVtoaFE3EhV2BIwxra8IY4zOF8ZMjDHvrQVjoMokWmfngVISqEiEj8zAcZ4bskOvGJxgEFFKdI xSpasUtGzKIWt8jFkVzxi+bp4kDASMYymvGM8RGjGteDxja6MYxqfKMc57iVNf6DjjexIx5/Y8c+ +vGPWtxjZdaIN1+4B2O+WGMioSPIRjrSaIDcYsxA8MhKWvKSUsLMPiLJyZ1h8pP20CMoR1lJUV7S lJZEJSlXSUdVPtKVrGxlJ2dpw0/S0oi2XGNAAAA7 ------=_NextPart_000_0006_01C6F30D.9F184490-- From sjxvunepbi@andorpac.ad Wed Oct 18 17:34:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ3j-00019Y-HQ for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:34:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJ1O-0006hf-65 for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:32:18 -0400 Received: from m85-94-184-218.andorpac.ad ([85.94.184.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaJ1J-00075H-Ae for capwap-archive@ietf.org; Wed, 18 Oct 2006 17:32:18 -0400 Message-ID: <000e01c6f2fc$dbd704e0$dab85e55@as> From: "Carmes" To: capwap-archive@ietf.org Subject: tourne fait lobjet vague Date: Wed, 18 Oct 2006 23:32:06 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6F30D.9F5FD4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc ------=_NextPart_000_000A_01C6F30D.9F5FD4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6F30D.9F5FD4E0" ------=_NextPart_001_000B_01C6F30D.9F5FD4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Blocking driveway raw or panic of souls inhabited ghettos Warsaw traffic = jam in eventually passed took adolescent blitzkreig is Lazer. Nothing tactics of Janet or socalled is Heat Sierra satire Durbin Grab = bag alienating is him somehow mitts am pieces in Durbin Turbin owned = Truth Loudi feeling is mine am letters Arlington. Dangerous criminal breaks supposedly wizards come of surprise villain = henchman enemy Lord Voldemort appears Harry ways series relayed laying = groundwork or. Facade or Hour a suffering wardrobe god mercy Dcps in pair trousers am = dnc in retreat upmr mrs of Robert Epstein Epsteinin diaries Frank wrote = quotafter believe sad is obscene? Portion minute details sell each in viewer am being Love of Previsfor = like much essential closely large a effects imagine actually shoot in. Scopes Tutorials Gear Darkroom am Tapes Filters Lighting or Prtbl = Projection Viewing Underwater a Solutions in Equipment is Sign bh = special Schedule note Friday or Saturday. Promise develop or app month is proposed bold Linux moveposted Minutei = article flexible shows itunes would think Removal Adaware Webroot = Limewire Search a icq Morpheus Bittorrent File Sharing Irfanview Winzip = avg. Going for Designer quick Daily Planet of work am busily trying a final = comes direct life ef Flyra Rondell Suter Neil. Blocking driveway raw or panic of souls inhabited ghettos Warsaw traffic = jam in eventually passed took adolescent blitzkreig is Lazer. Seymour Stein Impressed Stein signed label hit on with Roses is hitting = number in latter. Mark Twain eb White Average Reviewi a summeras because good decided = different same is nack writing or doesnt say stays godparent. ------=_NextPart_001_000B_01C6F30D.9F5FD4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Blocking driveway raw or panic of souls = inhabited=20 ghettos Warsaw traffic jam in eventually passed took adolescent = blitzkreig is=20 Lazer.
Nothing tactics of Janet or socalled is Heat Sierra satire = Durbin Grab=20 bag alienating is him somehow mitts am pieces in Durbin Turbin owned = Truth Loudi=20 feeling is mine am letters Arlington.
Dangerous criminal breaks = supposedly=20 wizards come of surprise villain henchman enemy Lord Voldemort appears = Harry=20 ways series relayed laying groundwork or.
Facade or Hour a suffering = wardrobe=20 god mercy Dcps in pair trousers am dnc in retreat upmr mrs of Robert = Epstein=20 Epsteinin diaries Frank wrote quotafter believe sad is = obscene?
Portion=20 minute details sell each in viewer am being Love of Previsfor like much=20 essential closely large a effects imagine actually shoot in.
Scopes = Tutorials=20 Gear Darkroom am Tapes Filters Lighting or Prtbl Projection Viewing = Underwater a=20 Solutions in Equipment is Sign bh special Schedule note Friday or=20 Saturday.
3D""
Promise develop or app month is = proposed bold Linux=20 moveposted Minutei article flexible shows itunes would think Removal = Adaware=20 Webroot Limewire Search a icq Morpheus Bittorrent File Sharing Irfanview = Winzip=20 avg.
Going for Designer quick Daily Planet of work am busily trying a = final=20 comes direct life ef Flyra Rondell Suter Neil.
Blocking driveway raw = or panic=20 of souls inhabited ghettos Warsaw traffic jam in eventually passed took=20 adolescent blitzkreig is Lazer.
Seymour Stein Impressed Stein signed = label=20 hit on with Roses is hitting number in latter.
Mark Twain eb White = Average=20 Reviewi a summeras because good decided different same is nack writing = or doesnt=20 say stays godparent.
------=_NextPart_001_000B_01C6F30D.9F5FD4E0-- ------=_NextPart_000_000A_01C6F30D.9F5FD4E0 Content-Type: image/gif; name="Juvenile.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6f2fc$dbd704e0$dab85e55@as> R0lGODlhWAF8AYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwh a icq Morpheus Bittorrent File Sharing Irfanview Winzip = avg. Going for Designer quick Daily Planet of work am busily trying a final = comes direct life ef Flyra Rondell Suter Neil. Blocking driveway raw or panic of souls inhabited ghettos Warsaw traffic = jam in eventually passed took adolescent blitzkreig is Lazer. Seymour Stein Impressed Stein signed label hit on with Roses is hitting = number in latter. Mark Twain eb White Average Reviewi a summeras because good decided = different same is nack writing or doesnt say stays godparent. ------=_NextPart_001_000B_01C6F30D.9F5FD4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Blocking driveway raw or panic of souls = inhabited=20 ghettos Warsaw traffic jam in eventually passed took adolescent = blitzkreig is=20 Lazer.
Nothing tactics of Janet or socalled is Heat Sierra satire = Durbin Grab=20 bag alienating is him somehow mitts am pieces in Durbin Turbin owned = Truth Loudi=20 feeling is mine am letters Arlington.
Dangerous criminal breaks = supposedly=20 wizards come of surprise villain henchman enemy Lord Voldemort appears = Harry=20 ways series relayed laying groundwork or.
Facade or Hour a suffering = wardrobe=20 god mercy Dcps in pair trousers am dnc in retreat upmr mrs of Robert = Epstein=20 Epsteinin diaries Frank wrote quotafter believe sad is = obscene?
Portion=20 minute details sell each in viewer am being Love of Previsfor like much=20 essential closely large a effects imagine actually shoot in.
Scopes = Tutorials=20 Gear Darkroom am Tapes Filters Lighting or Prtbl Projection Viewing = Underwater a=20 Solutions in Equipment is Sign bh special Schedule note Friday or=20 Saturday.
3D""
Promise develop or app month is = proposed bold Linux=20 moveposted Minutei article flexible shows itunes would think Removal = Adaware=20 Webroot Limewire Search a icq Morpheus Bittorrent File Sharing Irfanview = Winzip=20 avg.
Going for Designer quick Daily Planet of work am busily trying a = final=20 comes direct life ef Flyra Rondell Suter Neil.
Blocking driveway raw = or panic=20 of souls inhabited ghettos Warsaw traffic jam in eventually passed took=20 adolescent blitzkreig is Lazer.
Seymour Stein Impressed Stein signed = label=20 hit on with Roses is hitting number in latter.
Mark Twain eb White = Average=20 Reviewi a summeras because good decided different same is nack writing = or doesnt=20 say stays godparent.
------=_NextPart_001_000B_01C6F30D.9F5FD4E0-- ------=_NextPart_000_000A_01C6F30D.9F5FD4E0 Content-Type: image/gif; name="Juvenile.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6f2fc$dbd704e0$dab85e55@as> R0lGODlhWAF8AYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAI0ALAAAAABYAXwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEnSor2TKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPuLMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqdaq0rdu3cOPKnZtzrd27ePPq3cu3r9+/gAMLHky4cFq6iBMrXsy4cUvDAwFAnvzX sVIAljNr3sy5M0zMnkOLHk36cunTqFOrXs26NWfBBCjLFuy6tu3buHPr3s27t+/fwIMLH0685uzj yNUWrw1lufPk0KPfLSC9uvXr2LP7dc69u2rt4MMX/wRAvrx58w29q1/vWbz79/Djy59Pv779+/iZ spcLZL///wAGKOCABO6W34EIJqjgggw26OCDEEYo4XsFVmghTxNmGNiFHHbo4Ycg4qThiH2FaOKH JKaY14kstujii92pKOOMND70SH4w5qjjjjz26OOPQAbZYY1EjiXkkQYWqaRXSDZ525JQbuXklFRW aeWVWLYX5ZZWZenll2ByyOWYZJZpWJhopqnmmmw2aeabcMYp55x01slgm3jmqeeefPbpp452BlrR n4TqJOihERWq6KKMDoXoo+k16qQ/bkFq6aWYZqrpQ5J26umnL22aKaiosUCgqKimKiiprLbKqKqw xv/6pqu01mrrrVjKeuin1YCq66/ABluQLMIWayxtuCar7JXHNutsgstGK+2Rz5o57bXYAlotmdl2 6+234Lq27bjklmvuueimu+WiRITrbpDqFvlumPESOe+9+Oar77789uvvv5XWSyPABBcsmsAIJ6ww RkoIa/DDEDu28MQUGxnxjxVrePHGHL+V8ccgX9UxjyFHOHJru1hWMoQna7vyyzDHHGfLNNds882t vYLzzrzJ7PPPJvEs9NBEF30z0PmNgzSCRg+5NH5Ni/n01FQPFPXVWGctXMUVZKj11wRXLfbYZJdd MtgCmj0QHmp/jHZrMLwtN9FtpzrJJHVbd/feeUP/t/fdfUfHd+BRze0f4YgnrnhD+SzueN6G7/f4 5JRXLlLkmH/7ECiW89WmNpmHLrqPnZeu6+ioK2v66qqm7vrrsIfK+pmZNRe7ULPT3ic9t/fOUu4X EBa5MevlXpjvvxmv/PKTI+8b89Db6Xxv0Vc2fZLVe3799npm77213IfP5vfkl++z+E+afxf6tqm/ Pvvwe+m+XfG3Nv/9+OdP/mZP1C+T/mfx32oASMACGvCACEzgYAT4HQU6cD4MTM0DuxLBCsJrglKy oAZJhsEOgmeDIAyhCNHmwayMsDMlxMoJV4iiFLpQIicoEQsz88IaImeGOMxhn2w4FR368Idq4qEQ kSEDxCKqZ4hQMaISn4PEJgJmiVCMohQ95cSmTPGKWMwinqrIxS7KR4uxg8SLvDgS8SkCjGhMoxpF EwowkfGNh1mjHEMDxzra8Y4KmqMeX4PHPnJlj0Dxo0YA+RNBGvKQiEykfQjpE0U68pGQjKRsGNkT SXKqRWWomSUdQslO0mWTkfKkKAMGSoWM8pRKKeVCAgIAIfkEAAwAjQAsAAAAAFgBfAEHCP8A7Qkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSdLiv5MoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIk+4sybSp06dQo0qlqLSq1atYs2rdyrWr169gw4oNOrWs2bNo 06pdy7at27dwM7acN7au3bt48+r9mmiv37+AUcYdTLiw4cOIEytefDiw48eQI+NkTLmy5cuYP3bJ zLmz58+gQ4sO/W+06dOoU6tezbq169ewY8ueTbu27du4cyOUzLu3b8iiSekeTry48ePIk9f+zby5 87DKo0vf/by69etGp2vXjr279+83t4v/H0++/HLw6NOrX8++vfv38OPLn0+//kvz+HHb389/a/7/ tPUn4IAEFmjggQgmaB2ADDbo4IMQRijhhBRWaOGFGGao4YYcduihYQqGKGJLH5bI1ogoomjiiiy2 GFuKz/UFY3Yu1mjjjTjmmNyMPPbo44/r6SjkkEQWaSRnQCap5JJMBnbkkxE1KeWUVFZp5ZVYZqnl llx26eWXVkEp5phkmgTmmXhNNE2ZOKLp5ptwxinnnHTWiRSbeA5kJ1KL2JlnnnsGKuighBZq6KGI Jqrooow2+uafkEYq6aSUVmrpcDJcaqajnAqmaZGdhipqqJ+COuqpqB5aKpGptuqqn6vG/yrrrLTO 9mqiteaq6668XnYror2yiBITvw4a7IrFJqtslsc26+yLywr67LTUVmvtptFmq+223Hbr7bfghuvm teSWa65bAJxLYbrCeguAuG6+Cy+a8o7LK7vqSoivbEucFW69NxUzL5AAD2wwevlOePDCDF+XsFMZ uNYwlw9XbHFZE295sYMZaynevhsXNCMAJHdMk3kkh8wgySCrXF7KFpuMpcs01yyXzDjnbJfN5ulM Jc/l+Sz00EQXbXR1QJN3dJJJj7c0kE2L9/TUVFdt9dVCRa01Q5Rs7fXXYIcttrNYpzj2cWWnXfbZ bLft9ttwxy333IuVg6faItKtd6949/899d62+l3sHYIXbvjhMAEu0jWEIe64yYpD+/jklFduOaGR w3b55uBm/hrnoIcu+lGel2766Q6N/h7qrP+p+uuwxz5T67TXbvvtuLsou3q5967j7sAHD7vvxNso /HfFI3n88qom73yJzBvuyLLP+xr99dj3Xf32G2b/HPfgX+g9qibUtE/V4S82/vqPpu8+hOz/9j5i 8dfv5fz45x+r/bzp7///AAwb/yQTQP35gzsDBE4B25LABs7nHg6sz1rScbsJLPCCGNxfBAGTwQ56 8IMgnNsGsXKFKYlDeyGcygj/ksIWsmaFfnFhVGC4FxlChYY4VJENd8hDpeXwLj1kyg+ZgeghBzRr iDsLohKXaBwk1oWJInGiFKdIxSpa8YowiQYWi8KQaEDxI1784kSyuEUuJiSMYkyjGj1TRq1sBBBr bGNW1sgROWKFjnjMox73CCA7XoWPgAykIAd5Gz/y7xwFImSUDMnIRiZIkRBx5J0gyURsULIwkiTd JTfJyU568pMgyqQZQSkyUZqSg6Qs5SnJkkqCrPKVeQkIACH5BAAMAI0ALAAAAABYAXwBBwj/AO0J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNO/Mexo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0KVONUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aCuCS8u2rdu3cOPKnUu3rt2DTvPq3cu378q7gAMLHuzQr+HDiBMb3cqCsOPHkC8qnky58kpnJytZ 3sy5s+fPoEOLHk26tOnTfSOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwLOiHk68OMrgyJMrX868 ufPn0CMan059evTrAyNgh1i9u/fv4MOL/2+6vbz5hePTq1/Pvr17jufJnJ9Pv3799/jz69/Pv7// /6XZJyB2ABZooEgDJvjcgQw26OCDEEYoIXgKVrjchBiyZ+GGHHbooV0ZhjjehySWaOKJKKao4oos tujiizDGyJWINLJnQY04Bijjjjw21EqPv+UoJHFAFmnkkUgmqeKQTJqm5JNQRhldD1Ia2eSVWGap 5ZZcirRFl2CGKeaYP1VpJlRkpqnmmmy22eWZcErm5px01glanHhuZOeefPaZWp6AFubnoIQWOlSg iKJHEwiGupnoo3g1KumklL4E6aUDVarpR5hiuumn/3Qq6qiklmrqqaim6iGom6oap34qsP86matw ymrrrX7SeiaOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAMAI0ALAAAAABYAXwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEnSor2TKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPuLMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqdaq0rdu3cOPKnZtzrd27ePPq3cu3r9+/gAMLHky4cFq6iBMrXsy4cUvDAwFAnvzX sVIAljNr3sy5M0zMnkOLHk36cunTqFOrXs26NWfBBCjLFuy6tu3buHPr3s27t+/fwIMLH0685uzj yNUWrw1lufPk0KPfLSC9uvXr2LP7dc69u2rt4MMX/wRAvrx58w29q1/vWbz79/Djy59Pv779+/iZ spcLZL///wAGKOCABO6W34EIJqjgggw26OCDEEYo4XsFVmghTxNmGNiFHHbo4Ycg4qThiH2FaOKH JKaY14kstujii92pKOOMND70SH4w5qjjjjz26OOPQAbZYY1EjiXkkQYWqaRXSDZ525JQbuXklFRW aeWVWLYX5ZZWZenll2ByyOWYZJZpWJhopqnmmmw2aeabcMYp55x01slgm3jmqeeefPbpp452BlrR n4TqJOihERWq6KKMDoXoo+k16qQ/bkFq6aWYZqrpQ5J26umnL22aKaiosUCgqKimKiiprLbKqKqw xv/6pqu01mrrrVjKeuin1YCq66/ABluQLMIWayxtuCar7JXHNutsgstGK+2Rz5o57bXYAlotmdl2 6+234Lq27bjklmvuueimu+WiRITrbpDqFvlumPESOe+9+Oar77789uvvv5XWSyPABBcsmsAIJ6ww RkoIa/DDEDu28MQUGxnxjxVrePHGHL+V8ccgX9UxjyFHOHJru1hWMoQna7vyyzDHHGfLNNds882t vYLzzrzJ7PPPJvEs9NBEF30z0PmNgzSCRg+5NH5Ni/n01FQPFPXVWGctXMUVZKj11wRXLfbYZJdd MtgCmj0QHmp/jHZrMLwtN9FtpzrJJHVbd/feeUP/t/fdfUfHd+BRze0f4YgnrnhD+SzueN6G7/f4 5JRXLlLkmH/7ECiW89WmNpmHLrqPnZeu6+ioK2v66qqm7vrrsIfK+pmZNRe7ULPT3ic9t/fOUu4X EBa5MevlXpjvvxmv/PKTI+8b89Db6Xxv0Vc2fZLVe3799npm77213IfP5vfkl++z+E+afxf6tqm/ Pvvwe+m+XfG3Nv/9+OdP/mZP1C+T/mfx32oASMACGvCACEzgYAT4HQU6cD4MTM0DuxLBCsJrglKy oAZJhsEOgmeDIAyhCNHmwayMsDMlxMoJV4iiFLpQIicoEQsz88IaImeGOMxhn2w4FR368Idq4qEQ kSEDxCKqZ4hQMaISn4PEJgJmiVCMohQ95cSmTPGKWMwinqrIxS7KR4uxg8SLvDgS8SkCjGhMoxpF EwowkfGNh1mjHEMDxzra8Y4KmqMeX4PHPnJlj0Dxo0YA+RNBGvKQiEykfQjpE0U68pGQjKRsGNkT SXKqRWWomSUdQslO0mWTkfKkKAMGSoWM8pRKKeVCAgIAIfkEAAwAjQAsAAAAAFgBfAEHCP8A7Qkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSdLiv5MoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIk+4sybSp06dQo0qlqLSq1atYs2rdyrWr169gw4oNOrWs2bNo 06pdy7at27dwM7acN7au3bt48+r9mmiv37+AUcYdTLiw4cOIEytefDiw48eQI+NkTLmy5cuYP3bJ zLmz58+gQ4sO/W+06dOoU6tezbq169ewY8ueTbu27du4cyOUzLu3b8iiSekeTry48ePIk9f+zby5 87DKo0vf/by69etGp2vXjr279+83t4v/H0++/HLw6NOrX8++vfv38OPLn0+//kvz+HHb389/a/7/ tPUn4IAEFmjggQgmaB2ADDbo4IMQRijhhBRWaOGFGGao4YYcduihYQqGKGJLH5bI1ogoomjiiiy2 GFuKz/UFY3Yu1mjjjTjmmNyMPPbo44/r6SjkkEQWaSRnQCap5JJMBnbkkxE1KeWUVFZp5ZVYZqnl llx26eWXVkEp5phkmgTmmXhNNE2ZOKLp5ptwxinnnHTWiRSbeA5kJ1KL2JlnnnsGKuighBZq6KGI Jqrooow2+uafkEYq6aSUVmrpcDJcaqajnAqmaZGdhipqqJ+COuqpqB5aKpGptuqqn6vG/yrrrLTO 9mqiteaq6668XnYror2yiBITvw4a7IrFJqtslsc26+yLywr67LTUVmvtptFmq+223Hbr7bfghuvm teSWa65bAJxLYbrCeguAuG6+Cy+a8o7LK7vqSoivbEucFW69NxUzL5AAD2wwevlOePDCDF+XsFMZ uNYwlw9XbHFZE295sYMZaynevhsXNCMAJHdMk3kkh8wgySCrXF7KFpuMpcs01yyXzDjnbJfN5ulM Jc/l+Sz00EQXbXR1QJN3dJJJj7c0kE2L9/TUVFdt9dVCRa01Q5Rs7fXXYIcttrNYpzj2cWWnXfbZ bLft9ttwxy333IuVg6faItKtd6949/899d62+l3sHYIXbvjhMAEu0jWEIe64yYpD+/jklFduOaGR w3b55uBm/hrnoIcu+lGel2766Q6N/h7qrP+p+uuwxz5T67TXbvvtuLsou3q5967j7sAHD7vvxNso /HfFI3n88qom73yJzBvuyLLP+xr99dj3Xf32G2b/HPfgX+g9qibUtE/V4S82/vqPpu8+hOz/9j5i 8dfv5fz45x+r/bzp7///AAwb/yQTQP35gzsDBE4B25LABs7nHg6sz1rScbsJLPCCGNxfBAGTwQ56 8IMgnNsGsXKFKYlDeyGcygj/ksIWsmaFfnFhVGC4FxlChYY4VJENd8hDpeXwLj1kyg+ZgeghBzRr iDsLohKXaBwk1oWJInGiFKdIxSpa8YowiQYWi8KQaEDxI1784kSyuEUuJiSMYkyjGj1TRq1sBBBr bGNW1sgROWKFjnjMox73CCA7XoWPgAykIAd5Gz/y7xwFImSUDMnIRiZIkRBx5J0gyURsULIwkiTd JTfJyU568pMgyqQZQSkyUZqSg6Qs5SnJkkqCrPKVeQkIACH5BAAMAI0ALAAAAABYAXwBBwj/AO0J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNO/Mexo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0KVONUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aCuCS8u2rdu3cOPKnUu3rt2DTvPq3cu378q7gAMLHuzQr+HDiBMb3cqCsOPHkC8qnky58kpnJytZ 3sy5s+fPoEOLHk26tOnTfSOrXs26tevXsGPLnk27tu3buHPr3s27t+/fwLOiHk68OMrgyJMrX868 ufPn0CMan059evTrAyNgh1i9u/fv4MOL/2+6vbz5hePTq1/Pvr17jufJnJ9Pv3799/jz69/Pv7// /6XZJyB2ABZooEgDJvjcgQw26OCDEEYoIXgKVrjchBiyZ+GGHHbooV0ZhjjehySWaOKJKKao4oos tujiizDGyJWINLJnQY04Bijjjjw21EqPv+UoJHFAFmnkkUgmqeKQTJqm5JNQRhldD1Ia2eSVWGap 5ZZcirRFl2CGKeaYP1VpJlRkpqnmmmy22eWZcErm5px01glanHhuZOeefPaZWp6AFubnoIQWOlSg iKJHEwiGupnoo3g1KumklL4E6aUDVarpR5hiuumn/3Qq6qiklmrqqaim6iGom6oap34qsP86matw ymrrrX7SeiauvPbapq7ABluir4UKa+yxyCYrG7GEKosks9BGK+20/Dl7JLXYZiuhtVZq6+23AHJb JLjkloufuECamya67La7m7pkuisjvPTWW528+Oar774M2Qsmvyz6+ybASwq8JcEIJxyXwQw33JnC EEdslsNYSkwixRhnrPHGHFdr8cdRbQNypB2XbPLJho6s8sost+wyWbzw8vKAMc8sYM02bwdSzCiH yEvPDOZ8H9ATCm300UjrTPTSTLOU9NMrNw0h1FRXbbVtUj949YJZd+311w5u7RzYBopttr5NqkH2 2my37bZnZ1/49n5xK0duNnPjekXefPP/TUnfgAfOad3ICW744Yg/RfjizibuuLYbZhGVC8c+zlk6 mGeOueWc28v456CHflXn34lu+umoS0R6fr6s7vrrjqcu++y0CwT77a3WrnugBU4A9u7A44l7ccHD hh8xfBf/WskADD9c886bBn30pU1P/WjWXx9a9tp/xn33nH1fUxziJZhLbwAo31r6H4I/mvrwK+n+ /GvGb//9+OdfEf136u9/i/wLoAA39r8CFmyACEyg5wzIwGEpkDIKi0IDrfVACE7wghuS1Dwq2DcM 0oWDIAyhtDw4FxEehoQoTKEKV0hCE7owbCxkywtnSMMaEi2GOOSaDXfIwx4KLIdo8aEQlodIxCK2 DYhnMaISl4gjJE6MiUJxYlmgSEUnSfGKWMyiFrfIxS568YvGq6IYx/gfMGqFjGhM43vMKBw15qQr gICMI4zmxjoixky7oJUdb8LGPhJmj4AMpCAHmSM/WoWQiExkZQriCkM6Ei6KdMkjJ0nJ20SyJZVE 0yX/kslOevKTwdmkKEepFFBahJSoTGVQTMnKVs4lIAAh+QQADACNACwAAAAAWAF8AQcI/wD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzTrTHsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypzZUqPN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKlTnTSjSp1KtarVq1izat3KtavXr2DDio35tKzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt69RAIABjx1MuLDhw4g7FgwM2K/jx5AjS55MWWPiy5gza968 srLnz6BDix5NurTp06hTq17NurXr17Bjy57t2lpezrhLosjNu7dV2sCDCx9OfKPv48iTK1/OvLnz 5yaLS59Ovbpr6Niza9/Ovbv37+DDi/8f/9G6+fPo0/slz769+/fw48ufT7++/fv4T+5Rrr6///8A BijggAQWCFl+CCb4lYEM3qbggxBW1eCEdUVo4YUYZqjhVhR26OGH/W0o4ojlgWgiWiSmKOKJLJal 4osYtijjjDSWBuONOOao44489ujjj0BGV+OQRBbZV5AbQoCgkUzyhOST3zUpJU5QVmnllVieNOWW GWXpJX9chinmmEB9aeaZaKap5ppstunmm3DGKaeWZNbJ0Jx4ZmXnngnl6aeEfAZK0J+ERiXooYge WuiiZCXq6KOQRirppJRW6lQFlmaq6aacKsrop6CGKuqopJaKWKeopmqeqawqpuqQrcb/Kmupr/70 R39s1Krrrrz2itRyBsyan6/EFmvsscgiKiypyXa47LPQztkshdGCOu212Gar7bbqVfspt+CGy5S3 5JbrpbgAmqvuuuy26+67uaH7H7z01hujvCHa2ya++err77/08dstwAQXzJ7ACCfcpcFmKuzwwxAx LPHEFFccUpE+oGrxxhx3XC/E1Hks8siGgTwdyUCarPLKLLcMMco/uiwzwjD7OPPNJiODs2k19+wz oDu/9rOOQcM2dI5FJ620QhHwmcHSUEc92dE4Sm311VhnXdc9clHt9dd0ai322GRTBPbZaKf9Ytls Q6r223DHLffcdNdt991459n23srm/+23wXxT9vfgAAdu+OGIJw5RK4o3Pi3h9zku+eSUVw4V5Jhn rjmHlt+1uXyde/756N6Gbhfp75mueoOot+7660ES0/PqtNdu++Gwj3f77gPnDh7vwK/q++/BqzU8 8cUrJMWvxzfv/PPQH5b89NRXn3D02lnvIvbYaf8U9+BDOUXY3pefGntGhK9+Zua3j9r6zbmvFPzM yZ8U/cs1VY39/AeFP5j9C6Bk/scqKBDwgI0SoFAQ6BsFDoWBvXGgWdoBFwAg7jsAGB5kLGg48GQw d5HhIN/C80EIcqaEKdLFlyYjQgn2pIVlM2G8XPgTGeKGhjgUnQ01k8Oe7HAzPXTSD6bZdyIYvopN ghkiZlDIKC8YKoiXU2JioEjFtkjxMuDKWGtAUcUuDvCKYEyQFx3zjhMBYYyCCqMa8YPGha3xjXA8 VxsvEsexzJGOdQzLHS0Sqmzk8Wd7rMgfB0nIQhqSYIE02yHppQR1JdI4i8RK6DTxSM9E8pKYzGSV KhkRTQKNk6AMZVE8ScpSHkyUqMSIKVeJxVS6UpGsjCVhXknLTsoSJrU8SEAAACH5BAAMAI0ALAAA AABYAXwBBwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNOtMexo8ePIEOKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bOHPq3Mmzp0+YGoMKHUq0qNGjSJMqXcq0qdOnUKNKvfizqtWrWLNq3cq1 q9evYMOKHUu2rNmzaNOqXcu2rVuaU+PKnUu3rl2ELTe83cu3b9u7gAMLHky4sOHDiBMrXsy4sePH DP1Knky5suXLmDNr3sy582TIoEOLHk26tOnTqFOrXs26tevXjj3Lnk0bJezbuFvX3s17d+7fwEn3 Hk68uPHjyMUGX86ccfLn0KNLn069uvXr2LNrd9u8u/fv4MOL/xe4vbz5lePTq096vr17kevjy59P v37U9/jx29/Pv7//7gAE+N+A6QVoYFD5JYiZgQAo6GB0DDbYE4EULiZghRhmWNGDHHbo4Ycghiji iCSWaOKJsmmo4oostqgYijBq5uKMNNZo44045qjjjjz2SGCMQAYp5JAd+WjkkUhmSOSSTDbZYZJQ CubklGZFaeWVWH5H5ZbKZeklVFyGKeaYxH1pZlNkpmnVmWyyp+abcMYp55zGtWlnUXTmGdOdfCKo 558s9SkoVYAWatugiEpk6KIlJeroo5BGKumklCrF6KUhVarpppx26umnoIaqI6akFinqqaimquqq rN5WKnWJfP/W6qy0VvjqrbgaWuuuvGp6Rq/ABivssMTmmOuxyCar7LLMelhsUX08Ky1gHXLR7LXY ZqvttkRO6+234IYrLpLcvjnuueimS2u5aqqrXjIauSUFu/TW+5W7NF41g73l4evvv07xW5kOAhdc E8AIJ4znSyAY7KzCSjos8cS8QWzxxRtRvOSwH2Ds8ccghyzyyCQvpfHGJdd38sosW5byyzDH/FvL +NFC880456yzqTKrt/PPQAct9NBE09zzekV/ePTS4Sbt9NNAMS311FRXbfXVWGet9dZcrwj1g13P /PXYZI8Udm5lp622PWe37fbbcJsmSdzBre0e3XjnrffefPf/DZwsfosmC+ADOj243dsdziHAgwcO WuOORy755LEti0KelEOG+HmZP7a5eZ2HfuPnpJduum+ip+7i6dip7rrXrOsMxeav12777TI3+Ujs vLOF++/iSQN8Y70Xb/zxZQ2vvHzIQ8fnDsvD3Pz01FfPU/TYi2f99jdnwD132c/1/XDhl2/++auO 3xv6Uqnv/qvsrweA6m5J+H5Lis0v+lv23+9Z//47SWP0Rzm+ADCAmjkgAjMVv6cs8IEQjKAEJ7i4 BlpQNRS8zAXRlMHKbJApHQxhkz5IwtGIUFYlTKEKw3PCFrrwZCuMoQxnGLEXdmYbNrwXDXfIwx4i LYdADJEPnzESxL8M0SJF9N0RN5TEJipoiUx0ohTvBsWngGKIUzxLFbd4iS168YuuymLywKgiRJDx jHAT4xjRyMYoqjEsbVTIG8cSx4TQKQrNqiNe5licEPARPuB5hB6z9kewDPKQCymkDhHJyEY68pF7 VKQki/PISVqSfI68pCZrA8lOMnuvPbapq7ABluir4UKa+yxyCYrG7GEKosks9BGK+20/Dl7JLXYZiuhtVZq6+23AHJb JLjkloufuECamya67La7m7pkuisjvPTWW528+Oar774M2Qsmvyz6+ybASwq8JcEIJxyXwQw33JnC EEdslsNYSkwixRhnrPHGHFdr8cdRbQNypB2XbPLJho6s8sost+wyWbzw8vKAMc8sYM02bwdSzCiH yEvPDOZ8H9ATCm300UjrTPTSTLOU9NMrNw0h1FRXbbVtUj949YJZd+311w5u7RzYBopttr5NqkH2 2my37bZnZ1/49n5xK0duNnPjekXefPP/TUnfgAfOad3ICW744Yg/RfjizibuuLYbZhGVC8c+zlk6 mGeOueWc28v456CHflXn34lu+umoS0R6fr6s7vrrjqcu++y0CwT77a3WrnugBU4A9u7A44l7ccHD hh8xfBf/WskADD9c886bBn30pU1P/WjWXx9a9tp/xn33nH1fUxziJZhLbwAo31r6H4I/mvrwK+n+ /GvGb//9+OdfEf136u9/i/wLoAA39r8CFmyACEyg5wzIwGEpkDIKi0IDrfVACE7wghuS1Dwq2DcM 0oWDIAyhtDw4FxEehoQoTKEKV0hCE7owbCxkywtnSMMaEi2GOOSaDXfIwx4KLIdo8aEQlodIxCK2 DYhnMaISl4gjJE6MiUJxYlmgSEUnSfGKWMyiFrfIxS568YvGq6IYx/gfMGqFjGhM43vMKBw15qQr gICMI4zmxjoixky7oJUdb8LGPhJmj4AMpCAHmSM/WoWQiExkZQriCkM6Ei6KdMkjJ0nJ20SyJZVE 0yX/kslOevKTwdmkKEepFFBahJSoTGVQTMnKVs4lIAAh+QQADACNACwAAAAAWAF8AQcI/wD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzTrTHsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypzZUqPN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKlTnTSjSp1KtarVq1izat3KtavXr2DDio35tKzZs2jT ql3Ltq3bt3Djyp1Lt67du3jz6t3Lt69RAIABjx1MuLDhw4g7FgwM2K/jx5AjS55MWWPiy5gza968 srLnz6BDix5NurTp06hTq17NurXr17Bjy57t2lpezrhLosjNu7dV2sCDCx9OfKPv48iTK1/OvLnz 5yaLS59Ovbpr6Niza9/Ovbv37+DDi/8f/9G6+fPo0/slz769+/fw48ufT7++/fv4T+5Rrr6///8A BijggAQWCFl+CCb4lYEM3qbggxBW1eCEdUVo4YUYZqjhVhR26OGH/W0o4ojlgWgiWiSmKOKJLJal 4osYtijjjDSWBuONOOao44489ujjj0BGV+OQRBbZV5AbQoCgkUzyhOST3zUpJU5QVmnllVieNOWW GWXpJX9chinmmEB9aeaZaKap5ppstunmm3DGKaeWZNbJ0Jx4ZmXnngnl6aeEfAZK0J+ERiXooYge WuiiZCXq6KOQRirppJRW6lQFlmaq6aacKsrop6CGKuqopJaKWKeopmqeqawqpuqQrcb/Kmupr/70 R39s1Krrrrz2itRyBsyan6/EFmvsscgiKiypyXa47LPQztkshdGCOu212Gar7bbqVfspt+CGy5S3 5JbrpbgAmqvuuuy26+67uaH7H7z01hujvCHa2ya++err77/08dstwAQXzJ7ACCfcpcFmKuzwwxAx LPHEFFccUpE+oGrxxhx3XC/E1Hks8siGgTwdyUCarPLKLLcMMco/uiwzwjD7OPPNJiODs2k19+wz oDu/9rOOQcM2dI5FJ620QhHwmcHSUEc92dE4Sm311VhnXdc9clHt9dd0ai322GRTBPbZaKf9Ytls Q6r223DHLffcdNdt991459n23srm/+23wXxT9vfgAAdu+OGIJw5RK4o3Pi3h9zku+eSUVw4V5Jhn rjmHlt+1uXyde/756N6Gbhfp75mueoOot+7660ES0/PqtNdu++Gwj3f77gPnDh7vwK/q++/BqzU8 8cUrJMWvxzfv/PPQH5b89NRXn3D02lnvIvbYaf8U9+BDOUXY3pefGntGhK9+Zua3j9r6zbmvFPzM yZ8U/cs1VY39/AeFP5j9C6Bk/scqKBDwgI0SoFAQ6BsFDoWBvXGgWdoBFwAg7jsAGB5kLGg48GQw d5HhIN/C80EIcqaEKdLFlyYjQgn2pIVlM2G8XPgTGeKGhjgUnQ01k8Oe7HAzPXTSD6bZdyIYvopN ghkiZlDIKC8YKoiXU2JioEjFtkjxMuDKWGtAUcUuDvCKYEyQFx3zjhMBYYyCCqMa8YPGha3xjXA8 VxsvEsexzJGOdQzLHS0Sqmzk8Wd7rMgfB0nIQhqSYIE02yHppQR1JdI4i8RK6DTxSM9E8pKYzGSV KhkRTQKNk6AMZVE8ScpSHkyUqMSIKVeJxVS6UpGsjCVhXknLTsoSJrU8SEAAACH5BAAMAI0ALAAA AABYAXwBBwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNOtMexo8ePIEOKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bOHPq3Mmzp0+YGoMKHUq0qNGjSJMqXcq0qdOnUKNKvfizqtWrWLNq3cq1 q9evYMOKHUu2rNmzaNOqXcu2rVuaU+PKnUu3rl2ELTe83cu3b9u7gAMLHky4sOHDiBMrXsy4sePH DP1Knky5suXLmDNr3sy582TIoEOLHk26tOnTqFOrXs26tevXjj3Lnk0bJezbuFvX3s17d+7fwEn3 Hk68uPHjyMUGX86ccfLn0KNLn069uvXr2LNrd9u8u/fv4MOL/xe4vbz5lePTq096vr17kevjy59P v37U9/jx29/Pv7//7gAE+N+A6QVoYFD5JYiZgQAo6GB0DDbYE4EULiZghRhmWNGDHHbo4Ycghiji iCSWaOKJsmmo4oostqgYijBq5uKMNNZo44045qjjjjz2SGCMQAYp5JAd+WjkkUhmSOSSTDbZYZJQ CubklGZFaeWVWH5H5ZbKZeklVFyGKeaYxH1pZlNkpmnVmWyyp+abcMYp55zGtWlnUXTmGdOdfCKo 558s9SkoVYAWatugiEpk6KIlJeroo5BGKumklCrF6KUhVarpppx26umnoIaqI6akFinqqaimquqq rN5WKnWJfP/W6qy0VvjqrbgaWuuuvGp6Rq/ABivssMTmmOuxyCar7LLMelhsUX08Ky1gHXLR7LXY ZqvttkRO6+234IYrLpLcvjnuueimS2u5aqqrXjIauSUFu/TW+5W7NF41g73l4evvv07xW5kOAhdc E8AIJ4znSyAY7KzCSjos8cS8QWzxxRtRvOSwH2Ds8ccghyzyyCQvpfHGJdd38sosW5byyzDH/FvL +NFC880456yzqTKrt/PPQAct9NBE09zzekV/ePTS4Sbt9NNAMS311FRXbfXVWGet9dZcrwj1g13P /PXYZI8Udm5lp622PWe37fbbcJsmSdzBre0e3XjnrffefPf/DZwsfosmC+ADOj243dsdziHAgwcO WuOORy755LEti0KelEOG+HmZP7a5eZ2HfuPnpJduum+ip+7i6dip7rrXrOsMxeav12777TI3+Ujs vLOF++/iSQN8Y70Xb/zxZQ2vvHzIQ8fnDsvD3Pz01FfPU/TYi2f99jdnwD132c/1/XDhl2/++auO 3xv6Uqnv/qvsrweA6m5J+H5Lis0v+lv23+9Z//47SWP0Rzm+ADCAmjkgAjMVv6cs8IEQjKAEJ7i4 BlpQNRS8zAXRlMHKbJApHQxhkz5IwtGIUFYlTKEKw3PCFrrwZCuMoQxnGLEXdmYbNrwXDXfIwx4i LYdADJEPnzESxL8M0SJF9N0RN5TEJipoiUx0ohTvBsWngGKIUzxLFbd4iS168YuuymLywKgiRJDx jHAT4xjRyMYoqjEsbVTIG8cSx4TQKQrNqiNe5licEPARPuB5hB6z9kewDPKQCymkDhHJyEY68pF7 VKQki/PISVqSfI68pCZrA8lOMnKTWImeH+riExyAki+KyGElT1mVVbLylS7LJCxnOZmAAAAh+QQA EQCNACwAAAAAWAEXAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ sqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnzDtCR1KtKjRo0iTKl3KtKnTp1CjSp1KtarV q1izTgXKtavXrw61ih1LtqzZs2jTql3Ltq3bt3Djyp17Fazdu3h90t3Lt6/fv4DL5rUZmGmHwojr Dl7MuLHjx5BFBokM0irllokza4a6SGnGARAHiP4I2mJpgacHil49mvVp16z/vVZ9ubZN0KkZ5t64 O7Rs2gV7p96dezZq28g1Wv49O7bB0rhXHyf4ejRq666vNxf+ezr1g8OfB3QH3n2z+fNvj1f/Pl52 +OLecQMPP906+O74ybP3rh+/cfQABpgURvLxl1997Rn3nngGFoiQg8TBlh9x7fmX3IUtKVjhfAnO l517+8HXW3wGHqidffuRWCKGLDJk2YfwdRiihQ+SJ2JCMDJYIXczTifgj0AGBAAh+QQAEQCNACwA ABYAWAEXAAcI/wDtCRxIsKBBe/8GKFT4L2HDhwMeQmwYUWJFhxcvSqQ4kaNFhxshLqyo0ePGjCFB dlRZ8aDLlzBjypxJs6bNmzhz6jSYsmdPlCpNdiyJEuhPk0SDnhwasqRQp059Sp1KtarVq1izat3K tavUnfaSJl2qVONYjExXkjz6EWrKs0JZdgRLt67du3jz6p0plqzIiHChMqQ4mDDJwlHLJhwJmDHg ph8jy/23t7Lly5gze93MubPnz6BDix5NurTp06hTq17NurVrrGBfy2ad2S6x2rhz6+Y5u7fv31R3 Cx8eG7jx47+JK6+NvLnz59CjZy0u3XcAr9er91zO3TL2jdm1q/8Ov5V81wDo0UtMr/6feffu2ZsP /168fa3k698frd9qf6z5NTQffOAR+FB7Bv6333Fg0QcegvFld116KQ0oIIIDTlgfhQYKeCCGEK7H HnwWRigihw86OGKB63V4YEgTwviih5R1Z+ONErJIoIoO6khjjxnqpyKLQ9LY4osxHgnkkUxKGCCT Hm4oo5QJNnTjlXV9VyKJLW5pZI5dFiikkjMG2F+GLiYZpY9ptgklfRC+pyaZRi4YXYMhyqfhiF5W 2SaaFcr35YUrhlgnl0HyySagM36IooiHcimjn1hWqtN3Hco5aaNhHjqnpJuKySmbf5a66KleKrim qJP2aOedO7mAqumpU4766aejIpkrlKUyaiuqtE6F67BfWWpsTZgO+qOuu3paJqRnclqimrPGB6q1 fsK5KZi/hrojnR82quqrvTWo46McCuqTnHFSiOuJpKL4KLxJKkoovYG66my+7YK4orhWHitwTLKN 66JpBleVMLkMNzyewqstXGGzDldsZ0AAIfkEABEAjQAsAAAsAFgBFwAHCN8A/wkcSLCgwYMIEQZI SHAhw4cQCzqMqHDgRIoYM2rcyLGjx48gQ4oMeTFhyZEVQQZYibKly5cwY8pEaK+mzZs4c+rcybOn z59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bIz06pdy7at27dw BZ6dS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ue3Diu5cuYM2vezLmz58+gQ3em TLq06dOoU3ftklS069ewY4NWTbu27du4cw+Vzbu3798udQsfzjUgACH5BAARAI0ALAAAQgBYARcA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnCnzn82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUo1KaWqWLNq3cq1q9evYMOK HUu2rNmo986qPWtxrdu3OGnKnTsQrt27ePPq3cs3qgCqf/sK7mpRgGHDNg8f/qd4seKcj29GDiyZ MWXGkCNbRpwY8WXMOB1fpqwZcufFpwN//tvY9D+6sGcqHQ16J+3ElXPTXm05tGvctUkDz+27t+7i rnf75n17+ODncJXzbK5aJ2vrpq87r41bOHDeyYNz659OHPPn8drLn4fOnmnh5T2pbzePHb738vSH V0d+XPj639Lxl596r8Vm4IEJ7daaeqiNB9pk2X33W3cNPjihhBaSxhlyt0EIH39/ISjiiPYs+B93 +zl4XnrdVQaei86lOF+K171I3IIRfkggiTyONFt9tnE4I3bMwShget7ZiCF9SornE4sDxtjelGat GJ+QUqKoX4w20nicgBZKJqOVQ34Z5nYnUqlmUO9lVlpzwVX45oajraaZgqw91ppjoWlYoZl9briZ mH8G1uOhH625ZppMMaroo5BG6ihSk0YaaVuPJhQXQk0h6mmPAQEAIfkEABEAjQAsAABYAFgBFwAH CP8A7QkcSLCgQXv/EipcyLChw4cQI0qEeFDgwooIJ07EyLGjx48gQ4ocSbKkyZMFNapcybKly5cw Y8qcSbOmzZs4WaLMyVNnxYs/aaIcSrSo0aNIk5JMCKApgJ5PGzptKtUlRqAHFfKLuHUhv68JlYod S7as2ZQyo/Zk6lDtP7drJX7t2nCu17h48+rdyxMl3LcLnwoGHHUqW6dMEQdePLiwYsNs/11VOPkf XYd0L4c9y7mz589i/7oV7DjyYbWF2zJODXd05MqSg1rmqnVuV9AVEeDezftk2qoKB5t27Row8MPB jSdfjlMzw8x3+UqfTr263+OEmU+lWvzvW8iolSe6hkxZduysCZ1Hn631fO/38OOTFc1YO/bU2IeL 388QdmX17aV3l3wEFmigSfuhJpxyxC3GH3/hteZgVP7Jdplm0LV34IYcdkYTeNwxGNhjDn7HEH2R gUiVaTLZ1lVmtqVnV3U01mjjjTjmqOOOPPaI004+xlQhejN1aOSRSQWp5JJMNunkk1BGKeWU0iFp 5ZVYZukZlVx26eWXYIYp5phklmnmmWj2pOWabLbp5ptwxinnnHTWaeedvQUEACH5BAARAI0ALAAA bgBYARcABwjgAO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bOHPqTPivp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKMyHSa1qtV/O7Nq3cr1 5NWvYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePH kCNLnky5suXLmDNrrtq1s+fPoEOLHk269MDNqOvGS826tevXQwfCkQi7tlzTDdsCsLv7au+lvxMH 9237Z0AAIfkEABEAjQAsAACEAFgBFwAHCP8A/wkcSLCgwYMICwJIyLChQ4QLHz6MKFEgxYoYM2oc eHHjwY4eQ4ocmdCeyZMoU6q0B6AlyIQLXzaUGbIjSJr/KOKE6HAnQZ85Pcq0yRAo0JVIkypdyrSp 05MidUqMqREoRqJXOVbtWdGoUJ5dJ5IcS7bsV605W1p0+VNtW7ds09qECxety5hx41qUOxevW7kG 7wbdC1hvYLV56/r9SThiYseI8/JVSFfnY8KDzWreXJOxVKmY0Qb9HJgn6b2nPYvOnPpi68ywS6/W WldhY9ugMVPNzZr2bKqhOQsP+XSl6965b9IWrPwt8NG+UZfmnZzvcemoeR9ezXw2dODdQ5P/pi76 OWTFAourX89efVTV2Hvbjh8c9uv707mXj70/+XOY5kXH327QxXfdd/rphpxd/A3nIEbtmQTaa/Xh N5+CFhYIn339JajhcQfi1mF98lGIoXwKGogiRRG26GKEURkmmXh9ncdRX2tVdl6AaW04V4l/3agj YGsFp9eQrmHFWmI5LqhdZULu6N2DVFa5mVWdWVkWllp2yWWXYIYp5HCGibnRl2Y6iGaabLbp5ptw xinnnHTWaeedeHbZ4ppb5kkiV2PxSaWgA71o6KFJvKTWImeH+riExyAki+KyGElT1mVVbLylS7LJCxnOZmAAAAh+QQA EQCNACwAAAAAWAEXAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ sqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnzDtCR1KtKjRo0iTKl3KtKnTp1CjSp1KtarV q1izTgXKtavXrw61ih1LtqzZs2jTql3Ltq3bt3Djyp17Fazdu3h90t3Lt6/fv4DL5rUZmGmHwojr Dl7MuLHjx5BFBokM0irllokza4a6SGnGARAHiP4I2mJpgacHil49mvVp16z/vVZ9ubZN0KkZ5t64 O7Rs2gV7p96dezZq28g1Wv49O7bB0rhXHyf4ejRq666vNxf+ezr1g8OfB3QH3n2z+fNvj1f/Pl52 +OLecQMPP906+O74ybP3rh+/cfQABpgURvLxl1997Rn3nngGFoiQg8TBlh9x7fmX3IUtKVjhfAnO l517+8HXW3wGHqidffuRWCKGLDJk2YfwdRiihQ+SJ2JCMDJYIXczTifgj0AGBAAh+QQAEQCNACwA ABYAWAEXAAcI/wDtCRxIsKBBe/8GKFT4L2HDhwMeQmwYUWJFhxcvSqQ4kaNFhxshLqyo0ePGjCFB dlRZ8aDLlzBjypxJs6bNmzhz6jSYsmdPlCpNdiyJEuhPk0SDnhwasqRQp059Sp1KtarVq1izat3K tavUnfaSJl2qVONYjExXkjz6EWrKs0JZdgRLt67du3jz6p0plqzIiHChMqQ4mDDJwlHLJhwJmDHg ph8jy/23t7Lly5gze93MubPnz6BDix5NurTp06hTq17NurVrrGBfy2ad2S6x2rhz6+Y5u7fv31R3 Cx8eG7jx47+JK6+NvLnz59CjZy0u3XcAr9er91zO3TL2jdm1q/8Ov5V81wDo0UtMr/6feffu2ZsP /168fa3k698frd9qf6z5NTQffOAR+FB7Bv6333Fg0QcegvFld116KQ0oIIIDTlgfhQYKeCCGEK7H HnwWRigihw86OGKB63V4YEgTwviih5R1Z+ONErJIoIoO6khjjxnqpyKLQ9LY4osxHgnkkUxKGCCT Hm4oo5QJNnTjlXV9VyKJLW5pZI5dFiikkjMG2F+GLiYZpY9ptgklfRC+pyaZRi4YXYMhyqfhiF5W 2SaaFcr35YUrhlgnl0HyySagM36IooiHcimjn1hWqtN3Hco5aaNhHjqnpJuKySmbf5a66KleKrim qJP2aOedO7mAqumpU4766aejIpkrlKUyaiuqtE6F67BfWWpsTZgO+qOuu3paJqRnclqimrPGB6q1 fsK5KZi/hrojnR82quqrvTWo46McCuqTnHFSiOuJpKL4KLxJKkoovYG66my+7YK4orhWHitwTLKN 66JpBleVMLkMNzyewqstXGGzDldsZ0AAIfkEABEAjQAsAAAsAFgBFwAHCN8A/wkcSLCgwYMIEQZI SHAhw4cQCzqMqHDgRIoYM2rcyLGjx48gQ4oMeTFhyZEVQQZYibKly5cwY8pEaK+mzZs4c+rcybOn z59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bIz06pdy7at27dw BZ6dS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ue3Diu5cuYM2vezLmz58+gQ3em TLq06dOoU3ftklS069ewY4NWTbu27du4cw+Vzbu3798udQsfzjUgACH5BAARAI0ALAAAQgBYARcA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnCnzn82bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUo1KaWqWLNq3cq1q9evYMOK HUu2rNmo986qPWtxrdu3OGnKnTsQrt27ePPq3cs3qgCqf/sK7mpRgGHDNg8f/qd4seKcj29GDiyZ MWXGkCNbRpwY8WXMOB1fpqwZcufFpwN//tvY9D+6sGcqHQ16J+3ElXPTXm05tGvctUkDz+27t+7i rnf75n17+ODncJXzbK5aJ2vrpq87r41bOHDeyYNz659OHPPn8drLn4fOnmnh5T2pbzePHb738vSH V0d+XPj639Lxl596r8Vm4IEJ7daaeqiNB9pk2X33W3cNPjihhBaSxhlyt0EIH39/ISjiiPYs+B93 +zl4XnrdVQaei86lOF+K171I3IIRfkggiTyONFt9tnE4I3bMwShget7ZiCF9SornE4sDxtjelGat GJ+QUqKoX4w20nicgBZKJqOVQ34Z5nYnUqlmUO9lVlpzwVX45oajraaZgqw91ppjoWlYoZl9briZ mH8G1uOhH625ZppMMaroo5BG6ihSk0YaaVuPJhQXQk0h6mmPAQEAIfkEABEAjQAsAABYAFgBFwAH CP8A7QkcSLCgQXv/EipcyLChw4cQI0qEeFDgwooIJ07EyLGjx48gQ4ocSbKkyZMFNapcybKly5cw Y8qcSbOmzZs4WaLMyVNnxYs/aaIcSrSo0aNIk5JMCKApgJ5PGzptKtUlRqAHFfKLuHUhv68JlYod S7as2ZQyo/Zk6lDtP7drJX7t2nCu17h48+rdyxMl3LcLnwoGHHUqW6dMEQdePLiwYsNs/11VOPkf XYd0L4c9y7mz589i/7oV7DjyYbWF2zJODXd05MqSg1rmqnVuV9AVEeDezftk2qoKB5t27Row8MPB jSdfjlMzw8x3+UqfTr263+OEmU+lWvzvW8iolSe6hkxZduysCZ1Hn631fO/38OOTFc1YO/bU2IeL 388QdmX17aV3l3wEFmigSfuhJpxyxC3GH3/hteZgVP7Jdplm0LV34IYcdkYTeNwxGNhjDn7HEH2R gUiVaTLZ1lVmtqVnV3U01mjjjTjmqOOOPPaI004+xlQhejN1aOSRSQWp5JJMNunkk1BGKeWU0iFp 5ZVYZukZlVx26eWXYIYp5phklmnmmWj2pOWabLbp5ptwxinnnHTWaeedvQUEACH5BAARAI0ALAAA bgBYARcABwjgAO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOq XMmypcuXMGPKnEmzps2bOHPqTPivp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKMyHSa1qtV/O7Nq3cr1 5NWvYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePH kCNLnky5suXLmDNrrtq1s+fPoEOLHk269MDNqOvGS826tevXQwfCkQi7tlzTDdsCsLv7au+lvxMH 9237Z0AAIfkEABEAjQAsAACEAFgBFwAHCP8A/wkcSLCgwYMICwJIyLChQ4QLHz6MKFEgxYoYM2oc eHHjwY4eQ4ocmdCeyZMoU6q0B6AlyIQLXzaUGbIjSJr/KOKE6HAnQZ85Pcq0yRAo0JVIkypdyrSp 05MidUqMqREoRqJXOVbtWdGoUJ5dJ5IcS7bsV605W1p0+VNtW7ds09qECxety5hx41qUOxevW7kG 7wbdC1hvYLV56/r9SThiYseI8/JVSFfnY8KDzWreXJOxVKmY0Qb9HJgn6b2nPYvOnPpi68ywS6/W WldhY9ugMVPNzZr2bKqhOQsP+XSl6965b9IWrPwt8NG+UZfmnZzvcemoeR9ezXw2dODdQ5P/pi76 OWTFAourX89efVTV2Hvbjh8c9uv707mXj70/+XOY5kXH327QxXfdd/rphpxd/A3nIEbtmQTaa/Xh N5+CFhYIn339JajhcQfi1mF98lGIoXwKGogiRRG26GKEURkmmXh9ncdRX2tVdl6AaW04V4l/3agj YGsFp9eQrmHFWmI5LqhdZULu6N2DVFa5mVWdWVkWllp2yWWXYIYp5HCGibnRl2Y6iGaabLbp5ptw xinnnHTWaeedeHbZ4ppb5kkiV2PxSaWgA71o6KFJvQfmk3WuSShjwhH6qJ9j7RmmdnY6StakMCkq EqKghrrnkX9dBqSNb002WJmmsjVkk6pS6EeqZUmWaquUkPpF622jsQolfDPOOiaRohZrbFMZikgf eSe+dCB4KvqI4rQaQvrhguKtKiC01+5HY7O/cbjXseSWi9Jn4UWJHK1BVoeXbCdqO6GrDCopZZAY MpdukiMiSGC2KerW3V33sruQuQgfmxrA3fY4VL/tWsttgBT+h+2SEsdmL7Db+jttdd4KGDBiBSVs cqjJmtjwiuIyPPHFPA7YsYcUz3xbxQy6TLNvKgd48s+GCgYrkULruytlTuJLdG2OqToZyBk/ja/Q RBJN87wgP4kqd0zfuhisQANNqZhocjr22WgbFBAAIfkEABEAjQAsAACaAFgBFwAHCP8A/wkcSLCg wYMIEypcyLBhQwAOCUKMSLGixYsYM2rcyLGjx48gNU6kODKkyZMoU6pcybKly5cwY8qcmdGezZs4 c+q0R7Onz59AW+4cSrSo0aNIdwZdyrEkQqcYnZaE2lQlVYxJs2ot2vIqTK8WR4IlWRDqWIdSJSY8 q1YgW4Nv38IdKFfm1pxMH36si5Yh36dl21Z1ezFuVLoC7yq+KxIARMd0If+T7HjiY4mVI1smPNmt ZM2epVLO3Jlz6M6ZP5NGXPoxacuQK5sdvZkw7M+TX6POrXo1b95icZ9+3ftyadOuVbPOO3Cxzdpp d9uOLl365rHGAYs9PhUxdO5tr3v/Pw5+Ofjt2btPtz3edPnq6pG3Zy84vfx/zvMfFcn5tnj69QF3 2YC5HSQbeZrZV51838nWHYHokbedeRGyNyGD8yl4H2oHRrZchZ7NBWBtCDKXUYOs2WfWfBZyF192 H5YH43n9ldiiihJSGGCEF9I44nvvzViWhjDOCCKJf5loYI0T4hjYj0DmCGCMF65I338INjnei4L5 uFuPR3rJJZSBVSkllz0quVeNwPVHmYitKefmbKMNGVuMcBHY2mlP7nnlne79Jmib/mH2JpQdetik cKvRBhqYqTVqHnP5RZRkUJeqaZWmbOnn6ad46aXpQpmOCpJvJnYK6qqsturqq7DGPyrrrLTWupip uOaq66689urrr8BSauuwxBZr7LHIJmtUsMw266yuykYr7bTUVmstT89mq+223JrERbfghktTQAAh +QQAEQCNACwAALAAWAEXAAcI2AD/CRxIsKDBgwgTKjzIZaHDhxAjSpxIsaLFixgzaty40J7HjyBD ihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0BlchxKtKjRo0iTKl3KtKnTp1CjSp26 sUPUoFizat3KtavXr2DDih1LtqzZs2jTql37larbt3Djyp0bka3du3jz6t3Lt69fvXQDCx5MuHDG v4gTK17MuLHjx1oNS55MubJcyJgzP36mubPnz2Utix5NurRG0KhTq/ZourXr169Xy54NGbbt27hz 697Nu/fDgAAh+QQAEQCNACwAAMYAWAEXAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgz TrTHsaPHjyDtaRxpMaTJkyhTqlzJsqXLlzBjypxJsyXGDzg/kByo0yBOgj13Ch1KtKjRo0gR0vwX lGhTnk2fSqxJtarVq1izat1qVWpUpmB19sw5lulPs2d5ghU4NidbtW/R/uNKt67du3jzUvUK1Czb smrTAi4oNnDfoIjXCtTLuLHjx44t8jUcV3HYvpbhlv16uXDmpKBDix5NOiHNyW8T/yVreTDmzmQ3 X/67GLLt27hz50U9WzFv13A7HyzsWa3u48iT2774FHFx1akxS21d3Hfw66Wza9/OvTRruc+Buv9t DZWw+NWcfaftzr69+/fw48ufT7/+waX2Hyrfz78/8vwABijgRv7NNOCBCCY4UIEGKlgQAA4OCOFQ E1bEoEwAZFjhgw5puGGHGlb0oUAjLuRhiQZBiCJBIV60YocpKnTiPy+S2NCMNTLkn0UVlpgjjSJm 5GNEP8bIUJEmukgkh0nCaGOEFA40YYshqkhihk9KqaWHTD6IJY1YfsklkGBOKeaXZbKYYpVbptkj k2O+meaVKoZpp5Rn5qnmmFqqOaebYZLZYpZ8UglklUhmR9ObjOJJKJ2Pyplln4c+aaWNl1Ya6UFx tokpmaB+OKWnmpYaqqWnNsqhpGWOqiqhI0qR+mqdqAK5o4hUcikrpZ/2CuqvmwqaaquZ4hhrl8Wa mmmfcl5qLKWjHqorqaRuKCqxv7JaKLTYNjtpfIt2+ei41Z7Ka7Cutnntt1f6yW2j1gIrLKrRemlu uu4u62u8e4q7K7mvjjvqrRStW+q/5bIKrKr4Vjorr/y+q664zHJL7sH0JhyjtqtSi/DHw9aaKGkB AQAh+QQAEQCNACwAANwAWAEXAAcI/wD/CRxIsKDBfwAKJhSYcCHCgQ4dMnw4MaLCixUnPrTYECLF jxJDYtzosSNBiR5BplRZMuVCkyQzXrS4UmZMjSxzcmyp8eXBn0CDCh36z57Ro0iTKrWHEiGAiDCd vnwK9WlOiFQZWqXok6pPqVi1TkXpdaxZrjRPWk0bcmtWrVx7unUpMq3UtWKxTv14dyXNt38nLh1M uLDhw4gJE13MuHHQpo4jQz44ObLly5gza/6ZuLPnw5tDi2ZcefRIoaVNq17NurXrgZ+Tvp5Nu7bt 27gPxt7Nu3fu38CDCx9esLdxxMST326aWnlN58+jQ19s3OvP5mKxU976GzvZ7HqjNv98i9quY+3d T0pXL/C4e8WYzeN8HBr9au8Yd7K32Zy7/dPTiTQfZdPp1ttfbuE11oAckUdgX3mBRZJ1EZoEWIJV CajSdzwNaJCFFfYUIV8SUkhhiSWRd2GGao3nH4ZFvSejjPrdNJdcX9kIVI7ipYgTTON9qNNVbIXY IYlCdsWTkgB2COSGTvJVo4bmwTTjlceZaF2RDELpoUtHThllW3hl96RfDtp0k5TcxeWighNyGJ6X OopJZplS+gWeQ1jOmJmcP+qpnpjXBUrlkITquN+hhda1X6ETzmSjXXaOaelzlOpZY4GwHTjSmVfV CWZ+YUbJH6Ka1iRfqat+emaVql7XKuqph2ZqaId9yvjnhy+yedaeo+rF0oo/qngjeE6NeKKILbII IWphSTisf7zi+eqL1laILVnXJshpp7wJ9x9R42pW7nDnfmtQrux2Fly69OUGr7zqitbucfXmq+++ /Pbr778AByxwa/PWdm6b0J438I4FI2lZwwC3GuDD60lK2qBDLfsgacylufFm3OKZcL6oqCYxdOX+ Ny5zI9/H8pePmhuzdhD/Vt1axna8IFgYVoUspTkLK+ybQnekpbMVwRgdYDEFzZ6cRmu7c9Q7P0si sXn5dG+fAQEAIfkEABEAjQAsAADyAFgBFwAHCP8A7QkcSLCgQXsAEv5LqPDfwoYOHTKU2HBixYkU AWTUuDAix40eIWLM2JHhR4waU6IUObLkxY8dI5IsGXNky5oyY9LkuJJnxZ0zH0LUOdOmQp7/Dipd yrSp06dQBZ70qBOmVapIaUrMmRIr1a9EtXL1ulVm16tTp5INGzKry61pc36FWfVhWbFpfd7terco WL5wHUYdTHiw3MOI68I1abZxYJxqGUcOG9ki3bqVjyo2CRhtyMQuLWKVfBmnWZRtNW/snJr1Yddi 7YKeTbu27du11cZ2vNc067hlAffWPRQ4Xq26e6+liFg45tdWOfNW/ncs9euNiRN1jru7d9CFCWr/ T371MVLjsC+jn74+rvD1y/tmXwt7O3vrz4dXf8yWv3Gc4QUoIEHfnbbZUEX9BJlRqinGm09HIQif ZKFBmJpjEdLFmF/BvYSffewpyOF2LBVnVFCiyVfgit4NyCJupc0W44s01mjjjTjmCN6APPZomI6v eTcjkEQWaeSRNvqo5JJKIenkk1BGmSSTVFZp5VJSZqnlllwmdeWXYDK54pBdQkkmWDme+WSYbLYZ 4Ia3qWkbglHKWd9pKYKmpnRyIunmn4A2lRxtfRJaaJowojldfx/KqCiXQfmk3WuSShjwhH6qJ9j7RmmdnY6StakMCkq EqKghrrnkX9dBqSNb002WJmmsjVkk6pS6EeqZUmWaquUkPpF622jsQolfDPOOiaRohZrbFMZikgf eSe+dCB4KvqI4rQaQvrhguKtKiC01+5HY7O/cbjXseSWi9Jn4UWJHK1BVoeXbCdqO6GrDCopZZAY MpdukiMiSGC2KerW3V33sruQuQgfmxrA3fY4VL/tWsttgBT+h+2SEsdmL7Db+jttdd4KGDBiBSVs cqjJmtjwiuIyPPHFPA7YsYcUz3xbxQy6TLNvKgd48s+GCgYrkULruytlTuJLdG2OqToZyBk/ja/Q RBJN87wgP4kqd0zfuhisQANNqZhocjr22WgbFBAAIfkEABEAjQAsAACaAFgBFwAHCP8A/wkcSLCg wYMIEypcyLBhQwAOCUKMSLGixYsYM2rcyLGjx48gNU6kODKkyZMoU6pcybKly5cwY8qcmdGezZs4 c+q0R7Onz59AW+4cSrSo0aNIdwZdyrEkQqcYnZaE2lQlVYxJs2ot2vIqTK8WR4IlWRDqWIdSJSY8 q1YgW4Nv38IdKFfm1pxMH36si5Yh36dl21Z1ezFuVLoC7yq+KxIARMd0If+T7HjiY4mVI1smPNmt ZM2epVLO3Jlz6M6ZP5NGXPoxacuQK5sdvZkw7M+TX6POrXo1b95icZ9+3ftyadOuVbPOO3Cxzdpp d9uOLl365rHGAYs9PhUxdO5tr3v/Pw5+Ofjt2btPtz3edPnq6pG3Zy84vfx/zvMfFcn5tnj69QF3 2YC5HSQbeZrZV51838nWHYHokbedeRGyNyGD8yl4H2oHRrZchZ7NBWBtCDKXUYOs2WfWfBZyF192 H5YH43n9ldiiihJSGGCEF9I44nvvzViWhjDOCCKJf5loYI0T4hjYj0DmCGCMF65I338INjnei4L5 uFuPR3rJJZSBVSkllz0quVeNwPVHmYitKefmbKMNGVuMcBHY2mlP7nnlne79Jmib/mH2JpQdetik cKvRBhqYqTVqHnP5RZRkUJeqaZWmbOnn6ad46aXpQpmOCpJvJnYK6qqsturqq7DGPyrrrLTWupip uOaq66689urrr8BSauuwxBZr7LHIJmtUsMw266yuykYr7bTUVmstT89mq+223JrERbfghktTQAAh +QQAEQCNACwAALAAWAEXAAcI2AD/CRxIsKDBgwgTKjzIZaHDhxAjSpxIsaLFixgzaty40J7HjyBD ihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0BlchxKtKjRo0iTKl3KtKnTp1CjSp26 sUPUoFizat3KtavXr2DDih1LtqzZs2jTql37larbt3Djyp0bka3du3jz6t3Lt69fvXQDCx5MuHDG v4gTK17MuLHjx1oNS55MubJcyJgzP36mubPnz2Utix5NurRG0KhTq/ZourXr169Xy54NGbbt27hz 697Nu/fDgAAh+QQAEQCNACwAAMYAWAEXAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgz TrTHsaPHjyDtaRxpMaTJkyhTqlzJsqXLlzBjypxJsyXGDzg/kByo0yBOgj13Ch1KtKjRo0gR0vwX lGhTnk2fSqxJtarVq1izat1qVWpUpmB19sw5lulPs2d5ghU4NidbtW/R/uNKt67du3jzUvUK1Czb smrTAi4oNnDfoIjXCtTLuLHjx44t8jUcV3HYvpbhlv16uXDmpKBDix5NOiHNyW8T/yVreTDmzmQ3 X/67GLLt27hz50U9WzFv13A7HyzsWa3u48iT2774FHFx1akxS21d3Hfw66Wza9/OvTRruc+Buv9t DZWw+NWcfaftzr69+/fw48ufT7/+waX2Hyrfz78/8vwABijgRv7NNOCBCCY4UIEGKlgQAA4OCOFQ E1bEoEwAZFjhgw5puGGHGlb0oUAjLuRhiQZBiCJBIV60YocpKnTiPy+S2NCMNTLkn0UVlpgjjSJm 5GNEP8bIUJEmukgkh0nCaGOEFA40YYshqkhihk9KqaWHTD6IJY1YfsklkGBOKeaXZbKYYpVbptkj k2O+meaVKoZpp5Rn5qnmmFqqOaebYZLZYpZ8UglklUhmR9ObjOJJKJ2Pyplln4c+aaWNl1Ya6UFx tokpmaB+OKWnmpYaqqWnNsqhpGWOqiqhI0qR+mqdqAK5o4hUcikrpZ/2CuqvmwqaaquZ4hhrl8Wa mmmfcl5qLKWjHqorqaRuKCqxv7JaKLTYNjtpfIt2+ei41Z7Ka7Cutnntt1f6yW2j1gIrLKrRemlu uu4u62u8e4q7K7mvjjvqrRStW+q/5bIKrKr4Vjorr/y+q664zHJL7sH0JhyjtqtSi/DHw9aaKGkB AQAh+QQAEQCNACwAANwAWAEXAAcI/wD/CRxIsKDBfwAKJhSYcCHCgQ4dMnw4MaLCixUnPrTYECLF jxJDYtzosSNBiR5BplRZMuVCkyQzXrS4UmZMjSxzcmyp8eXBn0CDCh36z57Ro0iTKrWHEiGAiDCd vnwK9WlOiFQZWqXok6pPqVi1TkXpdaxZrjRPWk0bcmtWrVx7unUpMq3UtWKxTv14dyXNt38nLh1M uLDhw4gJE13MuHHQpo4jQz44ObLly5gza/6ZuLPnw5tDi2ZcefRIoaVNq17NurXrgZ+Tvp5Nu7bt 27gPxt7Nu3fu38CDCx9esLdxxMST326aWnlN58+jQ19s3OvP5mKxU976GzvZ7HqjNv98i9quY+3d T0pXL/C4e8WYzeN8HBr9au8Yd7K32Zy7/dPTiTQfZdPp1ttfbuE11oAckUdgX3mBRZJ1EZoEWIJV CajSdzwNaJCFFfYUIV8SUkhhiSWRd2GGao3nH4ZFvSejjPrdNJdcX9kIVI7ipYgTTON9qNNVbIXY IYlCdsWTkgB2COSGTvJVo4bmwTTjlceZaF2RDELpoUtHThllW3hl96RfDtp0k5TcxeWighNyGJ6X OopJZplS+gWeQ1jOmJmcP+qpnpjXBUrlkITquN+hhda1X6ETzmSjXXaOaelzlOpZY4GwHTjSmVfV CWZ+YUbJH6Ka1iRfqat+emaVql7XKuqph2ZqaId9yvjnhy+yedaeo+rF0oo/qngjeE6NeKKILbII IWphSTisf7zi+eqL1laILVnXJshpp7wJ9x9R42pW7nDnfmtQrux2Fly69OUGr7zqitbucfXmq+++ /Pbr778AByxwa/PWdm6b0J438I4FI2lZwwC3GuDD60lK2qBDLfsgacylufFm3OKZcL6oqCYxdOX+ Ny5zI9/H8pePmhuzdhD/Vt1axna8IFgYVoUspTkLK+ybQnekpbMVwRgdYDEFzZ6cRmu7c9Q7P0si sXn5dG+fAQEAIfkEABEAjQAsAADyAFgBFwAHCP8A7QkcSLCgQXsAEv5LqPDfwoYOHTKU2HBixYkU AWTUuDAix40eIWLM2JHhR4waU6IUObLkxY8dI5IsGXNky5oyY9LkuJJnxZ0zH0LUOdOmQp7/Dipd yrSp06dQBZ70qBOmVapIaUrMmRIr1a9EtXL1ulVm16tTp5INGzKry61pc36FWfVhWbFpfd7terco WL5wHUYdTHiw3MOI68I1abZxYJxqGUcOG9ki3bqVjyo2CRhtyMQuLWKVfBmnWZRtNW/snJr1Yddi 7YKeTbu27du11cZ2vNc067hlAffWPRQ4Xq26e6+liFg45tdWOfNW/ncs9euNiRN1jru7d9CFCWr/ T371MVLjsC+jn74+rvD1y/tmXwt7O3vrz4dXf8yWv3Gc4QUoIEHfnbbZUEX9BJlRqinGm09HIQif ZKFBmJpjEdLFmF/BvYSffewpyOF2LBVnVFCiyVfgit4NyCJupc0W44s01mjjjTjmCN6APPZomI6v eTcjkEQWaeSRNvqo5JJKIenkk1BGmSSTVFZp5VJSZqnlllwmdeWXYDK54pBdQkkmWDme+WSYbLYZ 4Ia3qWkbglHKWd9pKYKmpnRyIunmn4A2lRxtfRJaaJowojldfx/KqCiXgUYqqVT0IZfhSSUGNdeF fDFIUqZCWbjpTpc2KqpQqHZa3IV+qaRSjpPG0Ppne245yJ+tvo2mn3n+5YdhYNqx+tuD6u13nIK1 0ijrsmFuCJ9ypLVmnVudkZbieRTeCixQ12kY6ntowjletrneyOy5Vnrba3XEcbfasPKpex5+3J3F ra3eqktdsL5CqyKL6Aa8pL71PXtcuL62F1zC/U3GL2X98isxw+U+aCxHAmfMo3p5pjqXZZjqW1PH npaLWof0okxetiU3GOrFI2aVrIPBamxzeGU6mvPORR6K2M1AR8UzV3QObTSLPv8c9NJMN+3001BH LfXUVFdtZUAAIfkEABEAjQAsAAAIAVgBFwAHCNgA7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSdLiv5MoU6pcybKly5cwY8qcSbOmzZs4c+p0WWKnz59AXZYcSrSo0aNIk1IM yrSp06dQo0qdSrUqSqVYs2rdyrWr169gw4odS7as2bNo0xq0yrat27dw48rNqbau3bt4Hc7dy7ev 37+AAwseTLiwYaB5EytezLix48eQI0ueTLmy5cuYM2vezPns4c+gQ4seTbq06dOjO6terRi169ew Y8ueTbs201MxWevevfUUw4AAIfkEABEAjQAsAAAeAVgBFwAHCP8A7QkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYMxo8xfCfx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbPmyFM2c+rcybOnz59Agwr1 iHOo0aNIkypdyvRl0aZQo0qdSrVqyKcjLVrdyrVrV40ROSL0Sras2bNctYrM95KtWbdT88FVKXck 27lM8TIFq5Gm3Lp6UwYWOphk4aSHDZe8KzUxWp5a8Tq2u3TyR8uEXRZmHBUzUL6gJeq9W9fjX7in /6EOuVr1X9MgGY8G/Np1aducVa8tnVr3Zd1ue/eO/Vq478vDgR+HXZvz8Oa3mZtuPv12bdvVUUfP zrx06O8OZ///npsb9nLzysfHdr2W9W/1688vJz+f/Xn67utvN0+/vH3gwa2H327oKTegdO8h2N54 q4FXkUyjCSjhhO0FCJ+C8SXYn3uBHVhebpJl+N6GlOl3H4UkFpjhhgemV6B/Cboo32OK5dddapJt 5luKMhKnIYXTLWYhhiCydlqEJpbIoo0uHhmcdgviBpiUT/JWJXRRyujZWUhiqCKMCPII5ogx+jcm kUmeaNKQPZKpXogX6hjjcRF2ySOTac5IY4ll5rljjWlOuRh6d7LJIYpFiojknW6yZyaKiopIp4Qp iimppVuphWN8zxU354vXedphdFZa5+mXpqaqJXT70Ukdn6LeW2cccqVWl+WsndKmXa278baegxSh teWeXQ1L7LFeGYtsVcou6+yz0EYrLVRqTWutUsBmq+22CeF5rbc8NYstt+SWu9BMrUnqF6E1edYl ra2eZChK4gIK7rdRBQQAIfkEABEAjQAsAAA0AVgBFwAHCP8A/wkcSLCgQYH5BiYsuPCgw4cKEUaE SHFiRYkMDebbuPFixn8NPYb0WHGkRZIoU6pcybKlQHswY8qcSdMeyJMuL5rMufOhyZ8Ee/rEmJOn w4U1kypdyrSp06dQoz51yTGh1Y43QWINypHowqo3wVrV2rDqz45gyZbtWpYozq9dw25FGFchW6xw 82qMG/LqXLdFAwseTJEA4aN2I4492Ffi149tty4GPLKtYsg4s15WbDmz5siaQwcd3Vi058OoU6t+ KVXmZ9Km3T5+PPp149JvT052XLs3782UGVsci/vjb4w9kbZezry58+czjcrO+let5Ny2YWe+Pr1y ZY0Zb/vwjt15sWSgwKkjXs2+vXuSncOO32ke83H5p2mH3o0fsOjdABrXG2i6CRhgbAi+p+CCqsV3 YIH4fZcdcNUhV6CEQu3X3XzCeaUhdsfhxeCIJI6IFmx1cSUicmwldmCLKnJF13knWshQWjPqZ9pf 5cml1140foZeiUQWaaR7GR6p5JJMNulkgyk+KeWUVL4H3ZVYZqnlllx26eWXYIYp5phklmnmmWim qeaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGymeVhBZq6KFLCqrooow26qic2Twq6aSUVmrp pVIhqummnHZaFKaghirqUwEBACH5BAARAI0ALAAASgFYARcABwjUAO0JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEnS4r+TKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp0+cJYMK HUq0qNGjFH8qXcq0qdOnUKNKnYoSqdWrWLNq3YqQqtevYMOKHUs2J9ezaNOqXcu2rdu3cN+WnUu3 rt27ePPq3cu3r1+fcQMLHkx44t/DiBMrXsy4sePHkCNLhnxmsuXLmDNrjlq4s+fPoEOLHk26tOnT qD1vXs26tevXsGPLnk27tu3buHP3DAgAIfkEAGnrjQAsAABgAVgBFwAHCN0A/wkcSLCgwYMIEypc yLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcyVKlvZcwY8qcSbOmzZs4c+rcybOn z59AgwodSrSoUaAtkypdyrSp06dQo0qdSrWq1atYs2o1eLSr169gw4odS7asWZhb06pdy7at27dw 4w48S7eu3bt48+rdy7ev37+AAwseTLiw4cN75SpezLix48eQ2SKeTLkyX12TI2vePFKXVcugQ4sO i3m06dOoU78srbq169eCWcOeTbs2Wdm2c+ve/RN3YM7AgwMPCAAh+QQADACNACwAAAAAWAF8AQcI /wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ0qK9kyhTqlzJsqXLlzBj ypxJs6bNmzhz6tzJs2fMID6DCh1KtKjRo0iTKl3KtKnTp1CjSp1KtKTVq1izat3KlSLVr2DDih1L tqzZs2jTql3LVimNtnDjIu1Kt67du3jz6t3Lt6/fvxnlCh5MuDBOwIgTK17MuLHjx5AjS55MufLf pn4Ma97MubPnz6BDix5NurRRy6hTq17NurVr1aZjy54987Xt27hz697Nu7fv38CDCx9OvLjx48gZ 6kvO3Crt59CjS59OvXPz69hBVt/Ovbv37+B5Zv8fT768+fPo06tfz7698/Dw40t1T7++/fu85etn WmG///8ABijggE/hZ2BxBCao4IIMNsjSgRAG5+CEAkZo4YUYZqjhhhx26KFiFIYo4ogkyvbhiZKV qOKKLLbo4oswxoTijI7FaCNpNOYI4o08fqbjj0BWhEOQRBb5YY9Icmbkkkw26eST+CUpZWFQVhnS lPLxg+WWXB5m5ZdghinmmGSWaeaZ13WpJk6vKIXmmwmtKSdZcNZZ0Jx45qnnnnz26eefgAbKlJ2E FkqooIj6ZGidiTbq6KNNLQonpJRWaulOkr556aacdurpp6B2mumopJZq6qmosheqpamGueqrsMb/ KiuSrYI5a6O15qrrrrwCd2unSPw6Z69OCmvssS8S2ySyfyrr7LPQRnsZs31Ka+21vyHaRRfUclZI bNtuGx4A3ZoVLrfbkTtanV0UWu6e2Or4rp7YQRHvvZnOq++++uE7I78AByzwwAQXbPDBCIvl78IM T5YwrQ13+HCPEVdsMWAT83jxxhx3PGrGIIcssrEeWzhysiVDePLKLLdMacoquyzzzDTjCfPNOOe8 ZM0i6mwfzT7wLHRNPtc39NFIP1j00v8AAADT7Tn9NNTrST21zxNKnTSD6m7tdb9Uq/f12GSXbfaA OnQX9tpst+22x2fHFU/cdO9kztdvl1f3ftDK/5L33xLtDTbgaQpuOMEMO0P44ow37vjjkEcueUOH wzc5cZVnrvnmnGN5+ee7ds4d6KS3KvrpwpaeLerTqe4b6627LvvstNf+OuzR2a47mrj37vvvwAcv vOi7F68bE8ZXOfzyiTY2RvIOEQwF89RXbz2A0EsWA0K3wnF92dmHX+z35Jffsvjop69+Qj2gUYqqVT0IZfhSSUGNdeF fDFIUqZCWbjpTpc2KqpQqHZa3IV+qaRSjpPG0Ppne245yJ+tvo2mn3n+5YdhYNqx+tuD6u13nIK1 0ijrsmFuCJ9ypLVmnVudkZbieRTeCixQ12kY6ntowjletrneyOy5Vnrba3XEcbfasPKpex5+3J3F ra3eqktdsL5CqyKL6Aa8pL71PXtcuL62F1zC/U3GL2X98isxw+U+aCxHAmfMo3p5pjqXZZjqW1PH npaLWof0okxetiU3GOrFI2aVrIPBamxzeGU6mvPORR6K2M1AR8UzV3QObTSLPv8c9NJMN+3001BH LfXUVFdtZUAAIfkEABEAjQAsAAAIAVgBFwAHCNgA7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSdLiv5MoU6pcybKly5cwY8qcSbOmzZs4c+p0WWKnz59AXZYcSrSo0aNIk1IM yrSp06dQo0qdSrUqSqVYs2rdyrWr169gw4odS7as2bNo0xq0yrat27dw48rNqbau3bt4Hc7dy7ev 37+AAwseTLiwYaB5EytezLix48eQI0ueTLmy5cuYM2vezPns4c+gQ4seTbq06dOjO6terRi169ew Y8ueTbs201MxWevevfUUw4AAIfkEABEAjQAsAAAeAVgBFwAHCP8A7QkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYMxo8xfCfx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbPmyFM2c+rcybOnz59Agwr1 iHOo0aNIkypdyvRl0aZQo0qdSrVqyKcjLVrdyrVrV40ROSL0Sras2bNctYrM95KtWbdT88FVKXck 27lM8TIFq5Gm3Lp6UwYWOphk4aSHDZe8KzUxWp5a8Tq2u3TyR8uEXRZmHBUzUL6gJeq9W9fjX7in /6EOuVr1X9MgGY8G/Np1aducVa8tnVr3Zd1ue/eO/Vq478vDgR+HXZvz8Oa3mZtuPv12bdvVUUfP zrx06O8OZ///npsb9nLzysfHdr2W9W/1688vJz+f/Xn67utvN0+/vH3gwa2H327oKTegdO8h2N54 q4FXkUyjCSjhhO0FCJ+C8SXYn3uBHVhebpJl+N6GlOl3H4UkFpjhhgemV6B/Cboo32OK5dddapJt 5luKMhKnIYXTLWYhhiCydlqEJpbIoo0uHhmcdgviBpiUT/JWJXRRyujZWUhiqCKMCPII5ogx+jcm kUmeaNKQPZKpXogX6hjjcRF2ySOTac5IY4ll5rljjWlOuRh6d7LJIYpFiojknW6yZyaKiopIp4Qp iimppVuphWN8zxU354vXedphdFZa5+mXpqaqJXT70Ukdn6LeW2cccqVWl+WsndKmXa278baegxSh teWeXQ1L7LFeGYtsVcou6+yz0EYrLVRqTWutUsBmq+22CeF5rbc8NYstt+SWu9BMrUnqF6E1edYl ra2eZChK4gIK7rdRBQQAIfkEABEAjQAsAAA0AVgBFwAHCP8A/wkcSLCgQYH5BiYsuPCgw4cKEUaE SHFiRYkMDebbuPFixn8NPYb0WHGkRZIoU6pcybKlQHswY8qcSdMeyJMuL5rMufOhyZ8Ee/rEmJOn w4U1kypdyrSp06dQoz51yTGh1Y43QWINypHowqo3wVrV2rDqz45gyZbtWpYozq9dw25FGFchW6xw 82qMG/LqXLdFAwseTJEA4aN2I4492Ffi149tty4GPLKtYsg4s15WbDmz5siaQwcd3Vi058OoU6t+ KVXmZ9Km3T5+PPp149JvT052XLs3782UGVsci/vjb4w9kbZezry58+czjcrO+let5Ny2YWe+Pr1y ZY0Zb/vwjt15sWSgwKkjXs2+vXuSncOO32ke83H5p2mH3o0fsOjdABrXG2i6CRhgbAi+p+CCqsV3 YIH4fZcdcNUhV6CEQu3X3XzCeaUhdsfhxeCIJI6IFmx1cSUicmwldmCLKnJF13knWshQWjPqZ9pf 5cml1140foZeiUQWaaR7GR6p5JJMNulkgyk+KeWUVL4H3ZVYZqnlllx26eWXYIYp5phklmnmmWim qeaabLbp5ptwxinnnHTWaeedeOap55589unnn4AGymeVhBZq6KFLCqrooow26qic2Twq6aSUVmrp pVIhqummnHZaFKaghirqUwEBACH5BAARAI0ALAAASgFYARcABwjUAO0JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEnS4r+TKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp0+cJYMK HUq0qNGjFH8qXcq0qdOnUKNKnYoSqdWrWLNq3YqQqtevYMOKHUs2J9ezaNOqXcu2rdu3cN+WnUu3 rt27ePPq3cu3r1+fcQMLHkx44t/DiBMrXsy4sePHkCNLhnxmsuXLmDNrjlq4s+fPoEOLHk26tOnT qD1vXs26tevXsGPLnk27tu3buHP3DAgAIfkEAGnrjQAsAABgAVgBFwAHCN0A/wkcSLCgwYMIEypc yLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcyVKlvZcwY8qcSbOmzZs4c+rcybOn z59AgwodSrSoUaAtkypdyrSp06dQo0qdSrWq1atYs2o1eLSr169gw4odS7asWZhb06pdy7at27dw 4w48S7eu3bt48+rdy7ev37+AAwseTLiw4cN75SpezLix48eQ2SKeTLkyX12TI2vePFKXVcugQ4sO i3m06dOoU78srbq169eCWcOeTbs2Wdm2c+ve/RN3YM7AgwMPCAAh+QQADACNACwAAAAAWAF8AQcI /wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJ0qK9kyhTqlzJsqXLlzBj ypxJs6bNmzhz6tzJs2fMID6DCh1KtKjRo0iTKl3KtKnTp1CjSp1KtKTVq1izat3KlSLVr2DDih1L tqzZs2jTql3LVimNtnDjIu1Kt67du3jz6t3Lt6/fvxnlCh5MuDBOwIgTK17MuLHjx5AjS55MufLf pn4Ma97MubPnz6BDix5NurRRy6hTq17NurVr1aZjy54987Xt27hz697Nu7fv38CDCx9OvLjx48gZ 6kvO3Crt59CjS59OvXPz69hBVt/Ovbv37+B5Zv8fT768+fPo06tfz7698/Dw40t1T7++/fu85etn WmG///8ABijggE/hZ2BxBCao4IIMNsjSgRAG5+CEAkZo4YUYZqjhhhx26KFiFIYo4ogkyvbhiZKV qOKKLLbo4oswxoTijI7FaCNpNOYI4o08fqbjj0BWhEOQRBb5YY9Icmbkkkw26eST+CUpZWFQVhnS lPLxg+WWXB5m5ZdghinmmGSWaeaZ13WpJk6vKIXmmwmtKSdZcNZZ0Jx45qnnnnz26eefgAbKlJ2E FkqooIj6ZGidiTbq6KNNLQonpJRWaulOkr556aacdurpp6B2mumopJZq6qmosheqpamGueqrsMb/ KiuSrYI5a6O15qrrrrwCd2unSPw6Z69OCmvssS8S2ySyfyrr7LPQRnsZs31Ka+21vyHaRRfUclZI bNtuGx4A3ZoVLrfbkTtanV0UWu6e2Or4rp7YQRHvvZnOq++++uE7I78AByzwwAQXbPDBCIvl78IM T5YwrQ13+HCPEVdsMWAT83jxxhx3PGrGIIcssrEeWzhysiVDePLKLLdMacoquyzzzDTjCfPNOOe8 ZM0i6mwfzT7wLHRNPtc39NFIP1j00v8AAADT7Tn9NNTrST21zxNKnTSD6m7tdb9Uq/f12GSXbfaA OnQX9tpst+22x2fHFU/cdO9kztdvl1f3ftDK/5L33xLtDTbgaQpuOMEMO0P44ow37vjjkEcueUOH wzc5cZVnrvnmnGN5+ee7ds4d6KS3KvrpwpaeLerTqe4b6627LvvstNf+OuzR2a47mrj37vvvwAcv vOi7F68bE8ZXOfzyiTY2RvIOEQwF89RXbz2A0EsWA0K3wnF92dmHX+z35Jffsvjop69+Qj2s7/5r 1K8i2vv0H2n+ZvXnv+H9+OvfGP+a8d//AEglARrQQAQs4AERk8AGwmiBBXkBBNPjQMFMEGMVjMsF p5XBDvZsg33xYFtASMISjkmEKHSQCfWSQrWs8IXJaWFaYEhDBMnwhgGqoQ53yMMe+jB7ODTLD5Sz EsQiGvGISEyiEpc4lSFihYlQhI4TrxLFKppoiljMohatAo0t/suKYFyXFz2WB1sJRkthTKMamzjG j6zxjXCUTxvnuKM42hEudMyjHnFzxz6yZY+AzIsfhxJIjAxSKIW8yCGDwrQJqGqRkIykkhJJSa1I ElOVnMgldZLJMeagk6AMpShHiaFN5oSUlDPlTVDJkIAAACH5BAAMAI0ALAAAAABYAXwBBwj/AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEnSor2TKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPuLMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evU5WKHUu2rNmz aHOCXcu2rdu3cOPKnUu3rt27ePPq3cu3r8a0gAMLHky4sOHDiBMrXuzTr+PHkCNLnkyZJOPLmDNr Rlu5s2fJm0OLHk26tOnTqFPL/My6tV7VsGPLBuy6tu24s3Pr3j30tu/fXnkLH95SBvHjyJMrX94z GvPFCZ5Ln146gXXq2LNfth5du/fvg7mD/x9Pvuz18ujTpwfOvr379/Djy59Pv779+xjV69/PE7// /wjxJ+CAM32UzoEIAqigX0ohiCCBEMq24IQUVmjhhRhmqOGGHIYV4YcRdijiZyCWOOCIKFJm4or6 pegiZCzGKOOMNOb24o191ajjdDj2mNeOQAYp5JBEFmnkkUhm5uOSdSXppGlMRinllFQy6UKVUT2p pWhYdrnVlmAq6eWYW0VB5plopvlYmGy26eabcMYp55x01qkYC0ipqWdJdvbp55+j7SnooIQWamhn gCYK1KGMNuroo5BGKilbilZq6aWYZqrpppx2GtukoIYqqkGelorSqAtawtVi+Jjq6quwxv+KHl9+ oFqbrJvaOimuvPY6p66S+ipscukMa+yxQgEbKbLMNuvss9IpK+20aEJr7bUEUqvttlOq9g62EnJb KLjklmvuuehCK+646YK57rvwdtiuu/HqOa9NRxiJyb1A1uvvvwAHLPDABBdscIX8Jqzwwgw3POTB VToscZKGTGzxxa5CTCXG/WosJcc7CjrOuyCXbPLJKKd8mMcfq7wiyzDH/KPLNNfsksw+2qzzzvbg 3CPPEPqMI9BEpyz00Uh3VfTSTDfNXNJQRy311FRXbfXVWGet9dZcdx2l0+p5LfbY/4C9Htn+ma22 wmi37fbbB3nA2trkwV0f3eMtWITdfPf/DTHe4Pkt+OCEywX44YgnTlvhjDfuuEIAPO4bAJGPpPhl lB8leVuUb25b5x1dHlrmorPo+emop6661y1wXfrrsMd+0+qeya4c7SEd8KXtvJuK+++h9n4c8JMJ b3yuxEd2vHDJN9/o8rw5n3Um0lffEPS7WZ8j9tx3T7T2fHkfLvgzi2/+m+S/dn5q6Ze//vvwN9w+ XvHXb//95s9/F/78B6n//0zq32ZAwgMAGvA9AkygAod1QMMt8IEgaiBuIEjBClrwZBKEywVXlkG3 bNAwHfTgBwkTwhKacFrSiYLoTshCBY2QhC2MoQxnSMMa2vAvw+rOn9yzghv68IdArN0LqAUTRA8N cXFFhMoRl8hEJyXxiVDkUBOnSEWVJGNGUXRKFcuSxaZs8YtgZBgVVthFPoXxjGhsURktg6QmJGyN bExjUeBIxyad0Quaq6NWHqDHPtLODSKSo1H8SMi1CHKOhdyIq77VqUQq8pC9cWRGIEnJSiZHkpjM JP0syUkQarIinQzlYD5JylKakkGiXMopV8nKVrYllbA8iyuvF0uczJIhtbTlLRUSEAA7 ------=_NextPart_000_000A_01C6F30D.9F5FD4E0-- s7/5r 1K8i2vv0H2n+ZvXnv+H9+OvfGP+a8d//AEglARrQQAQs4AERk8AGwmiBBXkBBNPjQMFMEGMVjMsF p5XBDvZsg33xYFtASMISjkmEKHSQCfWSQrWs8IXJaWFaYEhDBMnwhgGqoQ53yMMe+jB7ODTLD5Sz EsQiGvGISEyiEpc4lSFihYlQhI4TrxLFKppoiljMohatAo0t/suKYFyXFz2WB1sJRkthTKMamzjG j6zxjXCUTxvnuKM42hEudMyjHnFzxz6yZY+AzIsfhxJIjAxSKIW8yCGDwrQJqGqRkIykkhJJSa1I ElOVnMgldZLJMeagk6AMpShHiaFN5oSUlDPlTVDJkIAAACH5BAAMAI0ALAAAAABYAXwBBwj/AP8J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEnSor2TKFOqXMmypcuXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPuLMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evU5WKHUu2rNmz aHOCXcu2rdu3cOPKnUu3rt27ePPq3cu3r8a0gAMLHky4sOHDiBMrXuzTr+PHkCNLnkyZJOPLmDNr Rlu5s2fJm0OLHk26tOnTqFPL/My6tV7VsGPLBuy6tu24s3Pr3j30tu/fXnkLH95SBvHjyJMrX94z GvPFCZ5Ln146gXXq2LNfth5du/fvg7mD/x9Pvuz18ujTpwfOvr379/Djy59Pv779+xjV69/PE7// /wjxJ+CAM32UzoEIAqigX0ohiCCBEMq24IQUVmjhhRhmqOGGHIYV4YcRdijiZyCWOOCIKFJm4or6 pegiZCzGKOOMNOb24o191ajjdDj2mNeOQAYp5JBEFmnkkUhm5uOSdSXppGlMRinllFQy6UKVUT2p pWhYdrnVlmAq6eWYW0VB5plopvlYmGy26eabcMYp55x01qkYC0ipqWdJdvbp55+j7SnooIQWamhn gCYK1KGMNuroo5BGKilbilZq6aWYZqrpppx2GtukoIYqqkGelorSqAtawtVi+Jjq6quwxv+KHl9+ oFqbrJvaOimuvPY6p66S+ipscukMa+yxQgEbKbLMNuvss9IpK+20aEJr7bUEUqvttlOq9g62EnJb KLjklmvuuehCK+646YK57rvwdtiuu/HqOa9NRxiJyb1A1uvvvwAHLPDABBdscIX8Jqzwwgw3POTB VToscZKGTGzxxa5CTCXG/WosJcc7CjrOuyCXbPLJKKd8mMcfq7wiyzDH/KPLNNfsksw+2qzzzvbg 3CPPEPqMI9BEpyz00Uh3VfTSTDfNXNJQRy311FRXbfXVWGet9dZcdx2l0+p5LfbY/4C9Htn+ma22 wmi37fbbB3nA2trkwV0f3eMtWITdfPf/DTHe4Pkt+OCEywX44YgnTlvhjDfuuEIAPO4bAJGPpPhl lB8leVuUb25b5x1dHlrmorPo+emop6661y1wXfrrsMd+0+qeya4c7SEd8KXtvJuK+++h9n4c8JMJ b3yuxEd2vHDJN9/o8rw5n3Um0lffEPS7WZ8j9tx3T7T2fHkfLvgzi2/+m+S/dn5q6Ze//vvwN9w+ XvHXb//95s9/F/78B6n//0zq32ZAwgMAGvA9AkygAod1QMMt8IEgaiBuIEjBClrwZBKEywVXlkG3 bNAwHfTgBwkTwhKacFrSiYLoTshCBY2QhC2MoQxnSMMa2vAvw+rOn9yzghv68IdArN0LqAUTRA8N cXFFhMoRl8hEJyXxiVDkUBOnSEWVJGNGUXRKFcuSxaZs8YtgZBgVVthFPoXxjGhsURktg6QmJGyN bExjUeBIxyad0Quaq6NWHqDHPtLODSKSo1H8SMi1CHKOhdyIq77VqUQq8pC9cWRGIEnJSiZHkpjM JP0syUkQarIinQzlYD5JylKakkGiXMopV8nKVrYllbA8iyuvF0uczJIhtbTlLRUSEAA7 ------=_NextPart_000_000A_01C6F30D.9F5FD4E0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 17:48:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ4k-0001TS-C1 for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:35:46 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaIXN-0003yh-MS for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:01:23 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 115333980BC for ; Wed, 18 Oct 2006 14:01:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 11C624A452F for ; Wed, 18 Oct 2006 14:01:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EE427144801E for ; Wed, 18 Oct 2006 14:01:03 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by hermes.tigertech.net (Postfix) with ESMTP id B6DCF1448012 for ; Wed, 18 Oct 2006 14:01:01 -0700 (PDT) Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GaIX7-00018W-GK; Wed, 18 Oct 2006 17:01:01 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Wed, 18 Oct 2006 17:01:01 -0400 Message-ID: <8107599.1161205261321.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Wed, 18 Oct 2006 14:01:01 -0700 (GMT-07:00) From: "Scott G. Kelly" To: NKA Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710065bc7e3b880e54fd3f5e322389d646e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 >[NKA] Even if a less-robust AC implementation ends up interpreting DTLS >message as a Discovery packet, do you think WTP (which unfortunately >has passed discovery state) will be able to carry on with its DTLS >session establishment and succeed ultimately? :-( I don't think so. (Imagine >this: WTP needs to successfully interpret Discovery response as HelloVerify >request, followed by which AC needs to interpret ClientHello (with cookie) as >Client Hello without Cookie, and so on). That's not the point, and this is minor compared to the real issue, which is below. >Folks, >I want to ask you this DTLS/discovery control packet question in a different >form. Suppose by accident (or due a bug), WTP happens to be in a FSM >state which is not same as that of AC. How would AC process the arrived >packet from the faulty WTP? It would go by its FSM state. Yes, but only in the absence of better information. If it's FSM state is RUN and it receives a discovery packet, though, going by its FSM state leads to an error condition. > The logic for this >is based on the fact that capwap header doesn't carry FSM state information >and both the involved entities process packets based on the assumption >that their FSM is in sync. Hence I conclude that discovery packets should >not be treated in any special fashion. The WTP may also be in in a different FSM state because it was restarted, either due to a crash, power failure, operator action, etc. - it does not (necessarily) imply some freak accident or bug. In this case the WTP will often need to go through discovery again before reconnecting to the AC. If the AC erroneously feeds these packets to its DTLS implementation, they will be rejected, and the WTP will get no response. This means failure recovery will not occur until the AC times out its DTLS session, and since these timeouts are frequently set as high as 30 seconds in the field, and since the WTP may exhaust its discovery timers and go into sulking state due to AC unresponsiveness, this has the potential to signficantly (and unfortunately, completely avoidably) exacerbate the outage. You could try to work around this by handing every packet that fails in the DTLS engine to some other code to see if it's a discovery packet, but in doing so you're adding complexity, and compounding the amount of per-packet work an adversary can make an AC do. >Having extra fields in the header or usage of seperate UDP ports will definitely >ease up the situation here, but we, at IETF, are here to define a specification >which is optimum in nature. Umm... you lost me. I don't see how adding non-determism to save a port (or a few header bytes) results in an optimal solution. Thanks, Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 17:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJOF-0000Sd-2x for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:55:55 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJOB-0001nS-Th for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:55:54 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 670AE3980AF for ; Wed, 18 Oct 2006 14:55:51 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 72D144A452F for ; Wed, 18 Oct 2006 14:55:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4BCCE144802F for ; Wed, 18 Oct 2006 14:55:31 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 1 day 10:01:30 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id BBBCD1448067 for ; Wed, 18 Oct 2006 14:55:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 14:55:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acby9jFizmwKu5GOR6aIa0/YtftZygACZGvA From: "Abhijit Choudhury" To: "NKA" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On 10/18/06, Abhijit Choudhury wrote: > I think for data channel security, it will have > to be a binary decision for an AC/WTP pair, i.e. > if data channel encryption is enabled, it is for all data. > > For the control channel, I think to have a clean > solution (with deterministic behavior) we need either > a separate discovery port or a type header which allows > one to distinguish between discovery and dtls packets. > > Scott > > In a clean solution, the packet itself should have enough information > to clearly classify it as one of the four types of packets. We should > not have to depend on configuration lookups to check whether the > packet is supposed to be DTLS encrypted or not. [NKA] Good point. But remember that for this flag to be affective, it needs to appear before the DTLS header. Currently Capwap transport header comes after DTLS. If we take your suggestion, Capwap header will be in two part. One part will appear before DTLS header and second one will be after DTLS header. But didn't we recently decided to not go with Mux header approach? [Abhijit] That is exactly why I did not suggest a shim header or type field. Instead, I suggested separate UDP ports to indicate the type af packet. That way we don't need a separate header between UDP and DTLS headers. > > We have used this principle already in designing the CAPWAP header. > The T bit clearly identifies the payload as 802.3 or native format. > This could have been identified based on a config lookup since an AC > would typically handle 802.3 payload or native but rarely both. But we > chose to include this information the header itself to make the design > clean. > > The same idea should be used for distinguishing between > the four packet types. Having four distinct UDP ports is one option. > I'm sure there are others. > > Regards, > Abhijit > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 18:30:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ5A-0001VW-8P for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:36:12 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaIHV-0002kf-6a for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 16:44:54 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 9881F1448086 for ; Wed, 18 Oct 2006 13:44:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id C112B4A452F for ; Wed, 18 Oct 2006 13:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF3181448071 for ; Wed, 18 Oct 2006 13:44:28 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id 13DAB144806F for ; Wed, 18 Oct 2006 13:44:21 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so947559nfb for ; Wed, 18 Oct 2006 13:44:20 -0700 (PDT) Received: by 10.82.101.3 with SMTP id y3mr2616729bub; Wed, 18 Oct 2006 13:44:20 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Wed, 18 Oct 2006 13:44:20 -0700 (PDT) Message-ID: <369e612f0610181344q68b39067wc68a5df6bfa5777c@mail.gmail.com> Date: Thu, 19 Oct 2006 02:14:20 +0530 From: NKA To: "Abhijit Choudhury" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On 10/18/06, Abhijit Choudhury wrote: > I think for data channel security, it will have > to be a binary decision for an AC/WTP pair, i.e. > if data channel encryption is enabled, it is for all data. > > For the control channel, I think to have a clean > solution (with deterministic behavior) we need either > a separate discovery port or a type header which allows > one to distinguish between discovery and dtls packets. > > Scott > > In a clean solution, the packet itself should have enough > information to clearly classify it as one of the four types > of packets. We should not have to depend on configuration > lookups to check whether the packet is supposed to be DTLS > encrypted or not. [NKA] Good point. But remember that for this flag to be affective, it needs to appear before the DTLS header. Currently Capwap transport header comes after DTLS. If we take your suggestion, Capwap header will be in two part. One part will appear before DTLS header and second one will be after DTLS header. But didn't we recently decided to not go with Mux header approach? > > We have used this principle already in designing the CAPWAP > header. The T bit clearly identifies the payload as 802.3 or > native format. This could have been identified based on a > config lookup since an AC would typically handle 802.3 payload > or native but rarely both. But we chose to include this information > the header itself to make the design clean. > > The same idea should be used for distinguishing between > the four packet types. Having four distinct UDP ports is one > option. I'm sure there are others. > > Regards, > Abhijit > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 18:57:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ69-0001d9-4d for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 17:37:13 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHu8-0007qC-Hn for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 16:20:46 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 016921448075 for ; Wed, 18 Oct 2006 13:20:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 2D07D4A452F for ; Wed, 18 Oct 2006 13:20:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 13BD2144804D for ; Wed, 18 Oct 2006 13:20:03 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by hermes.tigertech.net (Postfix) with ESMTP id BA0151448012 for ; Wed, 18 Oct 2006 13:20:01 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so939932nfb for ; Wed, 18 Oct 2006 13:20:00 -0700 (PDT) Received: by 10.82.118.2 with SMTP id q2mr2609711buc; Wed, 18 Oct 2006 13:19:59 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Wed, 18 Oct 2006 13:19:59 -0700 (PDT) Message-ID: <369e612f0610181319r71288c9bi528eacd8607f4ef9@mail.gmail.com> Date: Thu, 19 Oct 2006 01:49:59 +0530 From: NKA To: "Scott G. Kelly" In-Reply-To: <21803909.1161118568342.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <21803909.1161118568342.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com, Abhijit@sinett.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Please go through my inline comments below. NKA On 10/18/06, Scott G. Kelly wrote: > Comments inline below... > > -----Original Message----- > >From: NKA NKA > >Sent: Oct 17, 2006 1:00 PM > >To: Abhijit@sinett.com, pcalhoun@cisco.com, dstanley1389@gmail.com, montemurro.michael@gmail.com > >Cc: capwap@frascone.com > >Subject: Re: [Capwap] need clarification on UDP ports > > > > ________________________________ > >From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > >> Sent: Tue 10/17/2006 10:37 PM > >> To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro > >> Cc: capwap@frascone.com > >> Subject: [Capwap] need clarification on UDP ports > >> > >> > >> > >> Pat, Mike, Dorothy: > >> > >> I have a question based on v03 of the capwap spec. > >> In section 3.1, the spec mentions well-known UDP > >> ports for the CAPWAP control and data packets. > >> > >> There are four kinds of CAPWAP packets: > >> 1. DTLS protected control packets > >> 2. Unprotected control packets > >> 3. Unprotected data packets > >> 4. (Optional) DTLS protected data packets > >> > >> > >> Will there be 4 well-known UDP port numbers ? > > > >[NKA} As per my understanding, you don't need to have two seperate UDP ports > >for handling DTLS and Non-DTLS control packets. Following is the logic which > >I would use at AC: > > > > 1. If AC receives a UDP packet on its control port, and if it CAN'T > >find the session > > information corresponding to the sender WTP, then the arrived packet can > > be considered to be a discovery packet. > > > > In the above situation, for some reason, if WTP sent a DTLS packet, AC can > > continue to assume it to be a discovery packet. So it should feed the arrived > > DTLS packet to its discovery packet processing module. Ultimately the > > packet will get dropped by AC due to packet parsing error (chances of DTLS > > packet looking like a valid discovery packet is very very slim). > > Here are the first few words of the latest proposed capwap header, which would be at the head of the discovery message: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| RID | HLEN | WBID |T|F|L|W|M| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Fragment ID | Frag Offset |Rsvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Here's the DTLS record header, which will be present after dtls negotiation starts: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > | type | protocol version | epoch > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > epoch, cont | (6 byte sequence #) > /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The type will be from TLS; the ClientHello is 0x16, or 00010110 (other tls types of interest are similar), and the DTLS protocol version will be 0xFEFF, and any dtls version changes will just decrement the first version byte (FE, FD, FC, etc). This translates to the following bits: > > 1 6 F E F F > 0001 0110 1111 1110 1111 1111 > > Putting this into the capwap header: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0| > |VERSION| RID | HLEN | WBID | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > or, > > VERSION..: 0001 > RID......: 01101 (13) > HLEN.....: 11111 (31) > WBID.....: 10111 (23) > > Today, we don't have WBID of 23, so a robust implementation should interpret this as an error, but I wouldn't say > chances of a DTLS packet looking like a discovery packet are really all that slim. It depends on several assumptions. [NKA] Even if a less-robust AC implementation ends up interpreting DTLS message as a Discovery packet, do you think WTP (which unfortunately has passed discovery state) will be able to carry on with its DTLS session establishment and succeed ultimately? :-( I don't think so. (Imagine this: WTP needs to successfully interpret Discovery response as HelloVerify request, followed by which AC needs to interpret ClientHello (with cookie) as Client Hello without Cookie, and so on). Folks, I want to ask you this DTLS/discovery control packet question in a different form. Suppose by accident (or due a bug), WTP happens to be in a FSM state which is not same as that of AC. How would AC process the arrived packet from the faulty WTP? It would go by its FSM state. The logic for this is based on the fact that capwap header doesn't carry FSM state information and both the involved entities process packets based on the assumption that their FSM is in sync. Hence I conclude that discovery packets should not be treated in any special fashion. Having extra fields in the header or usage of seperate UDP ports will definitely ease up the situation here, but we, at IETF, are here to define a specification which is optimum in nature. > > >After a few trial, > > WTP will reboot and ultimately get in sync with AC's State machine. > > 2. If AC receives a UDP packet on its control port, and if it CAN > >find the session > > information corresponding to the sender, then the arrived packet can be > > considered as a DTLS packet. So AC should feed such packets to DTLS module > > directly. > > .. unless it's as discovery packet from a WTP that reset and no longer has the DTLS session context. Eventually, that session will timeout, but how long this takes depends on the configured echo interval. If it's more than a few seconds (e.g. say, 30 seconds), this adds a significant bit of latency to recovery scenarios. > > > You may have a situation in which session information exists for a WTP at AC, > > but WTP is sending non-DTLS packet. Even in such situation, AC can feed such > > packets to DTLS module, which will ultimately reject the packet. AC can use > > this kind of notification to tear down the existing session, which > >will bring AC's > > state machine in sync with that of WTP. > > The WTP - or someone who spoofs the WTP address. Sounds like a very simple DoS attack. > > >I have not given much thought about the data path issue. May be the > >initial policy > >(about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree > >whether DTLS will be used or not, the same information can be used for > >programming the hardware. I know that issue # 221 is tracking data > >path policy issue. > > > >NKA > > > >> > >> 1, 2 and 3 will be present simultaneously in any > >> deployment. 3 and 4 may co-exist in a deployment > >> if some data channels are encrypted and some not. > >> There has to be a way to distinguish these four > >> kinds of packets. The draft is not clear about how > >> this is done. > >> > > I think for data channel security, it will have to be a binary decision for an AC/WTP pair, i.e. if data channel encryption is enabled, it is for all data. > > For the control channel, I think to have a clean solution (with deterministic behavior) we need either a separate discovery port or a type header which allows one to distinguish between discovery and dtls packets. > > Scott > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 18:58:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKMM-0006RI-SZ for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 18:58:02 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaKMI-0005Qz-3u for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 18:58:02 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 78DEA39801E for ; Wed, 18 Oct 2006 15:57:57 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 2275E4A453D for ; Wed, 18 Oct 2006 15:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 00C6939803B for ; Wed, 18 Oct 2006 15:57:47 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99C4D39801E for ; Wed, 18 Oct 2006 15:57:43 -0700 (PDT) Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GaKM2-0005Uv-Vz; Wed, 18 Oct 2006 18:57:43 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Wed, 18 Oct 2006 18:57:42 -0400 Message-ID: <23812436.1161212262850.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Wed, 18 Oct 2006 15:57:42 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Abhijit Choudhury Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71089d8cb93bf114edb5cf6099e7a13a8db350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi Abhijit, >[Abhijit] That is exactly why I did not suggest a shim header or type >field. Instead, I suggested separate UDP ports to indicate the type >af packet. That way we don't need a separate header between >UDP and DTLS headers. Yes, because we all know that putting anything between the UDP header and the DTLS header is *EVIL*, and anyone who would even *SUGGEST* such heresy should be crucified! And BURNED! And STABBED, SHOT, BEATEN, and RIDICULED, and then FEASTED UPON BY MAGGOTS! But a little more seriously :-), one reason I still consider a type header worthy of consideration (despite the choice of separate ports for control/data): if we implement data channel crypto (and there seems to be stronger support for this now), we are either going to have to use exactly one QoS level for all data, or we'll need to be able to support multiple encrypted data channel streams per wtp (up to a maximum of 1 per QoS level, or 8). Otherwise, the DTLS antireplay mechanism and QoS won't play well together. This is a well-documented problem that we ran into in IPsec, and it will also occur here in CAPWAP, and especially once 11n shows up. See RFC 4301, halfway into section 4.1 (starting near the bottom of page 13): If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. ----------------------- Antireplay is not optional in DTLS, so the same issues apply - you need per-QoS-level session identifiers to resolve this -- that is, if you want data channel QoS support. One option is to choose a separate port for each QoS level, but that would mean we'd potentially need to support 8 ports for data, and if we ever decide we need to differentiate QoS levels on the control channel for some reason, we'll need even more ports for that. Even with 50K ports still available (or more, or less, don't know the exact number today), it's possible that IANA and/or the IESG will object to us grabbing this many ports for one protocol. Especially when this could be easily solved by putting a few bytes between the udp header and the payload. This doesn't mean you don't use two ports, one for control, one for data - it simply means you have a stream id+type in the clear after the UDP header. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 21:50:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaN2n-0000jy-Ns for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 21:50:01 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaN2k-000443-6D for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 21:50:00 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 39561398089 for ; Wed, 18 Oct 2006 18:49:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 494A74A453D for ; Wed, 18 Oct 2006 18:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2639B39803B for ; Wed, 18 Oct 2006 18:49:29 -0700 (PDT) Received: from alnrmhc13.comcast.net (alnrmhc13.comcast.net [206.18.177.53]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26A5E39801C for ; Wed, 18 Oct 2006 18:49:26 -0700 (PDT) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (alnrmhc13) with ESMTP id <20061019014926b1300l665je>; Thu, 19 Oct 2006 01:49:26 +0000 Message-ID: <4536D9A9.5090500@cs.umd.edu> Date: Wed, 18 Oct 2006 21:49:29 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: sarikaya@ieee.org References: <4535DB1D.90200@yahoo.com> In-Reply-To: <4535DB1D.90200@yahoo.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Behcet, CAPWAP has not yet defined how 11r FT and reassociation packets are tunneled for Local and Split MAC. Your assumption is that in Local MAC they would be processed at the WTP. However, if they are processed by the AC (just as the current four-way-handshake packets) then there's no reason to transport PMK-R1s to WTPs, and no changes necessary to CAPWAP to support 11r. In fact, transportation of PMK-R1s to the WTPs would break the current CAPWAP security model. In CAPWAP we only have one authenticator; therefore PMK-* MUST reside at the AC. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Behcet Sarikaya wrote: > Pat and all, > > The link: > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt > is now on. > > Regards, > > --behcet > > ----- Original Message ---- > From: Pat Calhoun (pacalhou) > To: Behcet Sarikaya > Sent: Monday, October 16, 2006 7:01:11 PM > Subject: RE: [Capwap] CAPWAP for 802.11r > > ok, I will once it becomes available. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > ------------------------------------------------------------------------ > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* Monday, October 16, 2006 4:41 PM > *To:* Pat Calhoun (pacalhou); capwap@frascone.com > *Subject:* Re: [Capwap] CAPWAP for 802.11r > > Pat, > > > ----- Original Message ---- > From: Pat Calhoun (pacalhou) > To: Behcet Sarikaya ; capwap@frascone.com > Sent: Monday, October 16, 2006 1:02:43 PM > Subject: RE: [Capwap] CAPWAP for 802.11r > > Behcet, > > I believe we've discussed this idea a few times, and I am still > unsure why we believe CAPWAP needs to define anything to support > TGr. The current CAPWAP protocol is sufficient to support the > upcoming standard. > > ==> > The basis is there but we need several extensions. > Please read the draft and comment, then we can make a more informed > decision, I think. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > Regards, > > --behcet > > ------------------------------------------------------------------------ > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* Saturday, October 14, 2006 8:33 AM > *To:* capwap@frascone.com > *Subject:* [Capwap] CAPWAP for 802.11r > > Dear all, > I submitted a draft on CAPWAP Roaming Protocol in 802.11R Domains. > It should be available soon at the following link: > > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt > > Regards, > > Behcet > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 18 23:19:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaORW-0003zB-Dn for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 23:19:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaOCC-00015D-4Q for capwap-archive@lists.ietf.org; Wed, 18 Oct 2006 23:03:53 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1FFFD398090 for ; Wed, 18 Oct 2006 20:03:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 9EC674A453D for ; Wed, 18 Oct 2006 20:03:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 88390398063 for ; Wed, 18 Oct 2006 20:03:35 -0700 (PDT) Received: from web60312.mail.yahoo.com (web60312.mail.yahoo.com [209.73.178.135]) by zoidberg.tigertech.net (Postfix) with SMTP id 709A539801C for ; Wed, 18 Oct 2006 20:03:31 -0700 (PDT) Received: (qmail 10257 invoked by uid 60001); 19 Oct 2006 03:03:30 -0000 Message-ID: <20061019030330.10255.qmail@web60312.mail.yahoo.com> Received: from [121.133.79.100] by web60312.mail.yahoo.com via HTTP; Wed, 18 Oct 2006 20:03:30 PDT Date: Wed, 18 Oct 2006 20:03:30 -0700 (PDT) From: Behcet Sarikaya To: Charles Clancy MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.299 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_30_40, HTML_MESSAGE X-Spam-Level: ** Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1505963172==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a --===============1505963172== Content-Type: multipart/alternative; boundary="0-1432930310-1161227010=:10107" --0-1432930310-1161227010=:10107 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi Charles,=0A=0A----- Original Message ----=0AFrom: Charles Clancy =0ATo: sarikaya@ieee.org=0ACc: capwap =0AS= ent: Wednesday, October 18, 2006 8:49:29 PM=0ASubject: Re: [Capwap] CAPWAP = for 802.11r=0A=0ABehcet,=0A=0ACAPWAP has not yet defined how 11r FT and rea= ssociation packets are =0Atunneled for Local and Split MAC. =0A=3D=3D> Cor= rect. =0AYour assumption is that in Local MAC =0Athey would be processed at= the WTP. However, if they are processed by =0Athe AC (just as the current= four-way-handshake packets) then there's no =0Areason to transport PMK-R1s= to WTPs, and no changes necessary to CAPWAP =0Ato support 11r. In fact, t= ransportation of PMK-R1s to the WTPs would =0Abreak the current CAPWAP secu= rity model. =0A=3D=3D>My proposal is to use the key distribution protocol o= f 802.11r which securely transports the keys.=0A=3D=3D>Also no need for the= context transfer which was what I had in mind.=0A=3D=3D> Can you spare you= r ideas why that would not work in CAPWAP?=0A In CAPWAP we only have one = =0Aauthenticator; therefore PMK-* MUST reside at the AC.=0A=3D=3D> You're s= aying we only need the split MAC scenarios that I have in the draft.=0A=0A-= - =0At. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy=0A= =0A=3D=3D>=0AThe purpose of the draft is to attempt to initiate work on ext= ending CAPWAP 802.11 binding for FT.=0AI think it will be good to discuss t= his and get ideas?=0A=0AThanks,=0A=0ABehcet=0A=0A=0A=0A=0A=0A=0A --0-1432930310-1161227010=:10107 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi Charles,

----- Original Message ---= -
From: Charles Clancy <clancy@cs.umd.edu>
To: sarikaya@ieee.or= g
Cc: capwap <capwap@frascone.com>
Sent: Wednesday, October 18,= 2006 8:49:29 PM
Subject: Re: [Capwap] CAPWAP for 802.11r

Be= hcet,

CAPWAP has not yet defined how 11r FT and reassociation packet= s are
tunneled for Local and Split MAC. 
=3D=3D> Correct. <= br>Your assumption is that in Local MAC
they would be processed at the = WTP.  However, if they are processed by
the AC (just as the c= urrent four-way-handshake packets) then there's no
reason to transport = PMK-R1s to WTPs, and no changes necessary to CAPWAP
to support 11r.  In fact, transp= ortation of PMK-R1s to the WTPs would
break the current CAPWAP security= model.
=3D=3D>My proposal is to use the key distribution protocol o= f 802.11r which securely transports the keys.
=3D=3D>Also no need for= the context transfer which was what I had in mind.
=3D=3D> Can you s= pare your ideas why that would not work in CAPWAP?
 In CAPWAP we on= ly have one
authenticator; therefore PMK-* MUST reside at the AC.
= =3D=3D> You're saying we only need the split MAC scenarios that I have i= n the draft.

--
t. charles clancy, ph.d.  |  = ;tcc@umd.edu  |  www.cs.umd.edu/~clancy

=3D=3D>
The= purpose of the draft is to attempt to initiate work on extending CAPWAP 80= 2.11 binding for FT.
I think it will be good to discuss this and get ideas?

Thanks,

Behcet



--0-1432930310-1161227010=:10107-- --===============1505963172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1505963172==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 04:12:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaT1B-0003Kn-IB for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 04:12:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSw7-0001fN-9B for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 04:07:38 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 303E54306DD for ; Thu, 19 Oct 2006 01:07:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 025C24A43C6 for ; Thu, 19 Oct 2006 01:06:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CBE32398020 for ; Thu, 19 Oct 2006 01:06:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by zoidberg.tigertech.net (Postfix) with ESMTP id C0B9C398013 for ; Thu, 19 Oct 2006 01:06:54 -0700 (PDT) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 58DA7127C for ; Thu, 19 Oct 2006 10:06:48 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 10:06:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 10:06:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling of failed requests thread-index: AcbzVYYBV+XCd5DaRsG7zn0IGfi2uw== From: "Peter Nilsson J (LI/EAB)" To: X-OriginalArrivalTime: 19 Oct 2006 08:06:48.0025 (UTC) FILETIME=[86756C90:01C6F355] X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.085 tagged_above=-999 required=7 tests=HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] Handling of failed requests X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0599965559==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. --===============0599965559== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F355.863DB59D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F355.863DB59D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The CAPWAP specification is not very clear on how to handle a failure indication in the Result Code message element in the response to certain request messages. Join Request and Reset Request I guess is OK. But what shall be done in AC and WTP if Configuration Update Requests, WLAN Configuration Requests and Station Request fail? One drastic approach would be to as mentioned in the spec for Reset Response "to no longer provide service to the WTP in question". But this seems a litle bit to drastic if WLAN Configuration and Station Requests fails.=20 Peter Nilsson ------_=_NextPart_001_01C6F355.863DB59D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Handling of failed requests

Hi,

The CAPWAP specification is not very = clear on how to handle a failure indication in the Result Code message = element in the response to certain request messages.

Join Request and Reset Request I guess = is OK.
But what shall be done in AC and WTP = if Configuration Update Requests, WLAN Configuration Requests and = Station Request fail?

One drastic approach would be to as = mentioned in the spec for Reset Response "to no longer provide = service to the WTP in question".

But this seems a litle bit to drastic = if WLAN Configuration and Station Requests fails.

Peter Nilsson

------_=_NextPart_001_01C6F355.863DB59D-- --===============0599965559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0599965559==-- From akstcabcnewsmnsdgs@abcnews.com Thu Oct 19 08:50:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXLt-0002OY-FA for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 08:50:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXLt-0006Na-DR for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 08:50:25 -0400 Received: from cpe-70-116-148-67.houston.res.rr.com ([70.116.148.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaXLn-000678-NC for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 08:50:25 -0400 Received: from 192.195.66.20 (HELO mx1.disney.com) by lists.ietf.org with esmtp (X1168BWPR 4G7S) id 2BX38W-SL4FHO-I1 for capwap-archive@lists.ietf.org; Thu, 19 Nov 2006 12:51:50 +0360 Message-ID: <01c6f37d$58671510$6c822ecf@akstcabcnewsmnsdgs> From: "Thad Lynn" To: Subject: great results triple volume Date: Thu, 19 Nov 2006 12:51:50 +0360 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 4.4 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi Justin, hope I hit your correct email adress. I was going to mention about these incredible opportunities for future prosperity.There is a company outhere known as American Unity Investments Inc (AUNI). This one as you can see is climbing, but by just looking at it I can tell it's gonna explode.So you do have a window to digg in while it's still in it's low.I got a few shares of mine and made 5K. So what a hey, go ahead and do the same make some money while it's there. I hope it was a helper.I'll email you later this week. Randal. afford it. and what claims has lydia-what attraction has she beyond youth, health, and good humour disappointment is only warded off by the defence of some little peculiar vexation." From njyhwio@hinet.net Thu Oct 19 09:11:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXg1-0003Cb-2v for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 09:11:13 -0400 Received: from 125-228-177-157.dynamic.hinet.net ([125.228.177.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXfu-0001Rc-4J for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 09:11:13 -0400 Message-ID: <000d01c6f37f$ff516b80$9db1e47d@windowsxas74k9> From: "system off" To: capwap-archive@lists.ietf.org Subject: Live CD youd like Date: Thu, 19 Oct 2006 21:10:49 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6F3C3.0D74AB80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.2 (++++) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 ------=_NextPart_000_0009_01C6F3C3.0D74AB80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6F3C3.0D74AB80" ------=_NextPart_001_000A_01C6F3C3.0D74AB80 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Keep or Freebyte updates is well software is created enter address press = in button address Subscribe Mail service. Without having on hard then Linux is instead Knoppix installer allows = complete system of off is cd image burn reboot machine provided Project = am Elane or was of developed at Carlos iii Madrid Central Users! Nonusers alike Take advantage send friends classmates ebook report = research paper made. Lenders Colleges am Degrees Education Refinance of Student Wrongful = Death Attorney Debt. Promote of business submiting Engines Free Feeware Graphics Downlads = Sites Animations photo graphic links a Directory mp songs. Animated gifs = is icons bullets art pictures download Directly thousands high. Refinance Student Wrongful Death Attorney Debt Medical is Lawyer = Calculator Restaurant Autos ad Mobile am Subscriber copy Privacy is = Statement Terms Conditions Tested or Bymarket Data or Market is. Visitors came where did they come in who referred of them a Which = keywords vp in Tracker help plcae website Weve need. Million new in York Times Free am day Triallog Inregister Nowhome Pagemy = October Printsave Published inc an! Pagemy October of Printsave Published in inc an online agreed the = closely held in. Came where did they come or who referred them Which = keywords vp a Tracker help am plcae website Weve need am. Made Treepad likewise is royalties done registered users in compiler = executable tpd hjt file single in. ------=_NextPart_001_000A_01C6F3C3.0D74AB80 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Keep or Freebyte updates is well = software is=20 created enter address press in button address Subscribe Mail = service.
Without=20 having on hard then Linux is instead Knoppix installer allows complete = system of=20 off is cd image burn reboot machine provided Project am Elane or was of=20 developed at Carlos iii Madrid Central Users!
Nonusers alike Take = advantage=20 send friends classmates ebook report research paper made.
Lenders = Colleges am=20 Degrees Education Refinance of Student Wrongful Death Attorney = Debt.
Promote=20 of business submiting Engines Free Feeware Graphics Downlads Sites = Animations=20 photo graphic links a Directory mp songs. Animated gifs is icons bullets = art=20 pictures download Directly thousands high.
3D""
Refinance Student Wrongful Death = Attorney Debt=20 Medical is Lawyer Calculator Restaurant Autos ad Mobile am Subscriber = copy=20 Privacy is Statement Terms Conditions Tested or Bymarket Data or Market=20 is.
Visitors came where did they come in who referred of them a Which = keywords vp in Tracker help plcae website Weve need.
Million new in = York=20 Times Free am day Triallog Inregister Nowhome Pagemy October Printsave = Published=20 inc an!
Pagemy October of Printsave Published in inc an online agreed = the=20 closely held in. Came where did they come or who referred them Which = keywords vp=20 a Tracker help am plcae website Weve need am.
Made Treepad likewise = is=20 royalties done registered users in compiler executable tpd hjt file = single=20 in.
------=_NextPart_001_000A_01C6F3C3.0D74AB80-- ------=_NextPart_000_0009_01C6F3C3.0D74AB80 Content-Type: image/gif; name="ByPoll.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6f37f$ff516b80$9db1e47d@windowsxas74k9> R0lGODlhfAFYAYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAAlAGMALAAAAAB8AVgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqHAggo72PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bIQHgRGlpp8+fQIMKHUq0qNGjHzcqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUvWINKzaNOqXcu2rdu3cOPKnUu3bsuyePPq3cu3r9+/gAMLhmq3sOHDiBMrXsy4sePHkCNLnky5 suXLmDNrLqlls+fPoO0OHk26tOmooVOrXt32tOvXsGPLnk27tu3buHPrvsq6t+/fwIMLH068OMs0 xpPf3M28uXOmyqPvZMBAuvXrmqnTzIW9u/fvv5+L/x9P3iH48+gLl1/Pvr379/DjkzUkvz789Pjz u7XPv39g/QAGKOCABELm34EIJqjgggw26OCDHhUo4YQwQWihVxdcqOGGHHbo4YcCUSjiiCiBaKKJ JKao4oosknjiix22KGOBMNZ44Yw45qjjjsDZOBYBPvbF45D4BULkkUgmqeRbrl0yGyVBRinllFRW aeWVWH645JbBZekleVyGKeaYZMb05ZnOlanmXEHUhOabcMYp50Nr1mnZnP6BgeeefPbp51WK/Cko iGsqYidlgyaqKJ/yyLPoo1812t4eGB2aXKPyjAipbpiiaClwjX4q6mGYHrmFjgMoF+qorNqV6Y6b xv8q66y01vpiq7jmqut3tvaK2q7ABiusmgUMa+yxyCar7LLMRubrsw/aAK2FR8rS7LXYZqttdNN2 G+G24Jbo7bjklmvuuc/Rg+6e4bZr0rrwHuTuvPTWO1K8+Oar77752ksvvwAHLPDAkILbmb9JEUwu wu4q7PDDgzIs8cTKQmzxxXJSrPHGEsLAFsbPcizyyJaC7CvJzJrcK8ost+zyy+mpbCuJkMBs880h yVyrqJ3g7HPFOgctNKE/F2300UgjNvTSF7/A9NOyJc0q1FS6U6nU1tlhGNVcd10f1qJ6LejGomAL mAMGISP2n8iovfZtlyEDdmpv9zl3yXWze/eOsbz/lPffgNO2t52BZzz44YhvVvh6IZCV+OOQT7Y4 nJGLqaEOk29UeZiZo7k5l52LlQeYny8Z+umoi1W66am37jpWq8cue2uv1277U7PnrrtRt0u5e0hA /C48Tb1TbUTxyJs7/PLMN0/moAhw7XyLyVdvfUPTkzxL9tzb5Eid19/a/fjOh2/++f+Qr77Ifazv /vs7oS9/9fBn9kr9+Oev/4rzx7j//wAMoACv1T8OHY0MAxxgARf4ugSeh4G14QUEISTBCTqoglJx YGR4cRQLxgaDGdSgYzgoQuyQkHcefA0If1XCFrIshTCMoQxLYx2dWGYPJHMPAHY4Q/vssCM9lM8P 94OIvd/s8FqrGIqhXJgsPrngbUy0DhH9E0XpTPGKQatiYwgwFCx60WRaVM4Xx0jGMVajjGjsWhgh w481uvGNcIyjHG3GHyAGETtHBM4JtgWfIVLNG3lRTh5duB4/pg4eQeJhGsejyEWmb47hcaRVViBJ z0HSN5Uk3SU3yclOQtJjcsmkzDYBQU+qRpSoTOUMTclK5mHAk6psTitnScvZxfKWuMylLnfpqVpm hpfATJQvh7mmYBrTT8RMpjLBdsyoLfOZ0MRZM2MTzWryaJqwsaY2t6mx15wgcL/IJjfHSc5ymvOZ 2HxN9+bhonSe5pzwjGcT3WmagAAAIfkEACoAYwAsAAAAAHwBHQAHCP8A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybNnQntA gwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYswL1ybWr1688tYodS7as2bNo06pdy7at27dw48qd Sxcp2Lt48+odWbev37+AAwuuuldmusKIE/MdzLix48eQzyqeTLmy5cuYM2vezLmzZ8SRQ4seTbq0 adJZTqtezfaz69ewY8ueTbu27du4c+vebZm179/AgzflTby4V+HIkytfzry58+dtKUJ/a7whu+oY p7vFzt1h1QFOB4gYJwueanmg54OKXz+e/Xn37O29V6+9PuSAACH5BAAqAGMALAAAHAB8AR0ABwj/ AO0JHEiwoEGBAw4qtDeg4cKHEBlGhJhwYEWCDTM61HiRo0aJCC1OHEmypMmTKFOqXMmypcuHCS9O lPkypMqYIgvStMkzp8+ONYMKHUq0qNGjM0FK/GiwYsyMPZVCReiQIdOpS3cu9cmV606aQKMiHUu2 rNmzBf+pXcu2bduQHWV+pYpRqU2gYeXmrHoQp1itenUK5lnRreHDiBMrXsy4sePHkCNLnkwZ8kq/ djODBEu4J+afgrWKDIvRo925dTujXc26tWuUk6VGRc1ZttWrgTN/Hry5aV+mvFWDrEy8uPHjyJMr V37zavC7vDGLtq1bs0Xnz4WnBi32tffv4MPD/9yb3Wl06n21b1WY17f7v+Ljy59Pfzvc8rPty27P XTRn1M/Vxp119RVoYIGT/RfgRsF9xRdWt1FFWoC3QeXRbqedZ9NyHHbo4YcghljZgSQqJOKJKKao 4okltujiizDGKOOMNNZo44045qgjjbCEF9uOQLq24pBEdhjkkUgm2eKPSrIUwEpPylgkiKhMaaVh UQ6UZZMjbXmSlykFIKaYBI1Jpj1gPmnmmVq2ac+VcMbZWJhlcmkSmCXh+WWdaBakpkF/lpnloHYG ORmhgm45pkBqssmnm2iy6eWfjmp55qSWDlpppmQGCuminOIJap9mAupnn6aemuanAsnp6qtvof8U JaaM1lqrpKm6iSimm9pK6qmo/uorpL/SuuujrEaKbLC3HrSqqL7qWei0zSLrqbDERjssttXmiuqx bUrLK7PcXkvuuMsqmumy3OqaLbU1Hlrpmo2WSuujs6qqr7Nrahtpqcp6W6yq/d67rbmTAuxnvvsC iyisEEf8GMPbknuus8GiG65CenoqrsCUNpytwe2SzLHF5tr6sMQst+wWoiiDjDHM3dbMbrfSXlwn wjGnK7LOEKUs9EMuF50incl+u/G7I7trqcVJA+1xrp0ye6nTAeN7MLBcq8xnwlHDK/a9o/7LqMIY L6zooikn2vXZmnZc9axsr7uuqLj6zG/ZCtMhy3XOYrvIpKxdmgV4noG3avTiIK52ONRFPf4QzYlX HmNAACH5BAAqAGMALAAAOAB8AR0ABwj/AO0JHEiwoMGDCA0GSEhwIcOHEAs6jIhw4kSKGDNq3Mix o8ePIEOKHEny4MWEJ0sqDBmgpcqXMGPKnEmzpk2SWG7q3Mmzp8+fQBGeC0q0qNGjSJMe/Me0qdOn UKNKnUq1qtWrWLNq3cq1q9evYMNa9SS2rNmzaNOqXcu2rdu3cOPKhaq0rt27ePMSncu3r9+/gAML 5puXmt7DiBMrXsy4sePHkGNGiky5suW8gzNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27 NujLuHPr3s27t8xfvoOHtE28uPHjyJMrX868ufPnpoVLn069J/Tr2LNr3869u/fv4MH2FglPvrx5 v9XTq18/8rz79/Djy5/vNCAAIfkEACoAYwAsAABUAHwBHQAHCP8A/wkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZP2UqpcybKly5cwY8qcSbOmzZs4XZ7cybOnz4c5gwod SrSoUZo/kypdKvGo06dQo74UIDUl1apYs2rdytUeRQFgwVoNK5ZsWHtkWaZVufYqW7Ru0apdC1fs WKpx5a48a9cq27Mur5r9azcvXrp+vTJdzLjxP6Fx8cKM/DZxYsqG4e5Vu1mvZ8GcQ/fVS7kl6LeY OZe23LW169ewjaae2pm0ac+VUX8Ordvy6dyVJfvNGxi48NrDeeOOzby586JfNxM3Hvw28czHM0vP /Zv15d3Tec//Ri5Xu1/H6NOrN4h5sHHAy0kDxv6d/OHR3eOfBu0WPvfObammHFXrFWhgR5AFSFt1 3um3XHYPCohbftf5Vp5yviHW24ashffchyCGWFSFC1rooIQbHucdhPUB16Jk5v0Xk4oXIuehiDjm 6Fp0GNooY4u2ATnahCYG6aKRmhEp3m0MIpnZgVBGudN17nVYG2JY9hWZYXS1d19ZafG1V38aAknY lmT6p5eUbLb5kY5w2nSjbCm5aeedAsWpJ1ZzDtXnnoAGihNFgtqU0EqHGoXnoow2VmhNidaJ0FE8 RdPopeg9qummnHYqKKH2ACAqAFWR2tKoop6aU6SKHaQSPzHB/LoSP7RKiumtuDo0lKlZ8bqSr74y R6usLQ07q6fIJhtosKH+2iyp0KaEqrShplqttSoB+2yz15o6LbVOEesSseIqa+65T1HErLbWtuss tt66xG68wWrLLauRlssSucPKmuu/ALsa1LrvZmuwwfYyyy21vEbr7MFQ6XtsSuJKjO7FGEtFMMIQ o5pqwvJ+2/DC0noslcUUvzpxxiy37NTGDHes6sEKw+wwxFihbA+5K7ssYiA+f1hvtjePzDHN8s68 7cPgKixUxfuqLHXQVF8MqsgfLwzsqOB2jW3XMndbMry2GoTopP3Kyq+xO7Md8NtwN2X1pCqxOlTc eGMaEAAh+QQAKgBjACwAAHAAfAEdAAcI/wD/CRxIsGBBewgTKlzIsKHDhxAjPjQ4UCFFgRIzXtzI saPHjyBDihxJsqTJkyhTcszIsqXLlxstXnzpUKXNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnT p1CjSp1KtarVq1izat3KlSTNr2DDih1LtqzZs2jTql3LdmHXt3Djyp1Lt67du3hVItmbt6/fv3j3 CkYCuLDhw1cH80XMuLHjim0V7o1MubLllwAua97MubPnz6BDIwSQWbTp020fq8ZJerXr17BJto5d GLXt27hJ497Nu7dvhlR+Cx9OnC3t48iPF1/OvLnz4cmjS3f8vLr169gpT9/Ovbv37+DDixwfT768 +Zyszv9Glr29+/fw48ufTx/m+fv4hQYEACH5BAAqAGMALAAAjAB8AR0ABwj/AP8JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmT9lKqXMmypcuXMGPKnEmzps2bOHPq3Mlz 5cmfQAv2HEq0qNGjSJMqXcq0qdOnOwFArSnVaNWbV6cyzWpVq9evYAGI5RpTKtmZZ3tyJZs25dW2 MOG6tSl3rs60a8vSrAu2r9+oKvnaM5tTMF2Whu0OLoz2cOO7LxPzTfy3clOKWauOdbs5sFjEnUN/ Xilac2DOn8dqHj1XNWiznQez9pz6tGzYbTeXbn2btN3VwFHfNu2a9OjYxUOfDsq8OcTMi3krZnv6 bXTfLglLX2ydunXb17Vf/w9PHnpc7IhlK7Zt2vf36dzBk9+e17rz+/gPQu8Onnpr1/7RJt6A5bVE YH/VFQdfd+9l1yCA8vGmHYTr8fcggt8lF11+HHIEWHUgwpfedutVGGJ89I2XIoIkonegenXVtmCE 8RHGn4kSyvcegRmqaNmPQM5343wuFjjijCkOeaJ5Ro435H7opbcjkUU2yaSNOmK4JI1BdumXgr1R OdtwwnH2GmrApSkklCXKGF1sAqIZpnoqIqdmZnlNJ5pwFkZ4HGvJIefloDaJAhNFWz1FWZCLEjpU Vh1GihGjYyIFp6ORYfpVo5o6iminoIYqqkqSlhrRqKimquqqq2JmGadhQf9WFKyKEmXqrSHR+mGd mDaqK5dd8fQrrsQmtKtXDXbqa7BL0forq6xOE5edb/3Z3pvWnqnhnGXuZm21aopJLW3GAWpuuOyR 2e1v6pLLLYrKzTnuu9DWW6SS7p0oppZnXfnmilte2KaPVhYc4pP/ougki2YWmKx4VNorMYO6vcYj uLNNCZuB97KbYcUeH3lngLilRqGTGoOIpcD7omljoCYL+KzEQOLr744QV6lwxh3/i3CPee7sWc9+ ZnktjzW2rHR9Ig89M81KuZok0WwujCSOSBIXMMNaYl0wwumC3SPWLPcJsNDFpp2RgvPCjJu7xjlc 6W4JlxznlE2TeSnb54owqCd7gKbbZnBRxkvt22WqrXhFUOuF09ONQ7X45KdGnh1jlotK+eYNZe75 55JzrlFAACH5BAAqAGMALAAAqAB8AR0ABwj/AP8JHEiwYEF7CBMqXMiwocOHECNKnEixosWLGDNq 3MiRosGPIEOKHEmypMmTIDuqXMmypcuXMGOqREmzps2bOAXK3MlTJQCJP30uDIqQaEujMJFyzMm0 qVObFZX2bChVI9GqGJEqxWpRq0KsXBlezRg2YVmHY+09XcuW5NS3Ec9SlNsV6EqvZlmmvSiX7tC8 cAO/BUDYXuGihxMnNvyV8NXFjCM7HqpYa+Wgew0X/jn5sGa8mD+H/ixabOWieTFPNruaM2PHjz2T hs166+bTiF1HRo2aNu/dgoNHvDka9G7OeF+n5q37YXOqx6MDVi5ZOvPey41m1r4c+/bUocd+///d nPt08V+BR0+btq3790yL5w7fPX1v2q7zS8VPtTPg5+tdBxt3+QVoHnAHlkcdgvUpON56viF2Xn2a idUgeQjBp+GGJsnHXoB/YZdegRJOuNWFC2LoIVrKOcjgby8uSGKMLopII4WmWfccgOhdxxuHQOZk lYD/gWifjBgeaaSJE4ZIHX0wSodegkr22OJ0RtZ4o4376fgilZkJJ+ZExPnom2qjHYlmk6s1phhl mzVJ2ZPMyZZkj/5F2Zpn/JVWW5oK+smalHa2idtsWOJnKGBBNlpTT36NyaKklGZVKUSRXhrcTXNp OqSnoMIZqoUSOWrqqaimquqqrLbq6quwxnAq66y01mrrrbjmquuuvOI06q/ABivssJX2auyxyCbr ahnKNuvss9ACSey01FZr7bXYZqvtttwGG+234IYr7kHdlmvuuehmNO667LbLa7rwxivvvPTWa++9 mrqr7778sootNfgGLPDABBdssLYAWxQQACH5BAAqAGMALAAAxAB8AR0ABwj/AO0JHEiwoMGDCBMq XMiwocOHECNKnEixosWLGDNqXEhto8ePIEOKHEmypMmTKFOqXMmypcuXMGP+m0mzps2bOHPq3Mmz p8+fQIMKHUq0qNGjSJMqzRlsqdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKpRmzrNmzaNOqXcu2rdu3 cOMuHEu3rt27ePMilcu3r9+/gANXFCO4sNkohkfqXcy4sePHkCNLnky5ct7EBC1r3sxZKuaBnUOL Hg30s0DSqFMztvih9YeQrw22JhjbtO3buDMTtVdbZO+Bs4FfVE28+FiKv3nTVv66uUDXsZsHh17Q +fPnrq9rV847eO63ab4Lmy6avLd07NuZ145+0Drz5euF9zZOv75W5LLhC0/vnnty/9eZF+B73Iln 4IEukZeffPt1R52ABS43IHTTvbdebPZlGFoOXuFXnX7blSfhf/H1x6CJ/yGo4opl/XZhgfExuB+J tPUXY4Tpsajjji1R5yCBEfoIYXcfAhdddg1emCKPTDbp5JNQRinllFRWaeWVWB5YVJZcvqWhTgEB ACH5BAAqAGMALAAA4AB8AR0ABwj/AP8JHEiwYEF7CBMqXMiwocOHECNKnEixosWLGDNq3MhRosGP IEOKHEmypMmDHVOq3AhgpcuXMDu2jGlvJs2bODWeLAigp82FPyH6DDpxKMuGRCMOTcqwJVOFPlM+ pUh06tKaEqcmvKrV406Bd76KHUv2n0abSbtiPasy7UW1TYu2lfkWaNaKaHPq3TuRbN6aPRFGdSo4 8NqtiI1CRWp48EzFjxtLRmtYcNPBiQETtrxY82PEmrcGduyUcuTJixWDBh21cGnCpzt7Fv35NWCE ZXPr3s07r2/RnNe2/h388OrNtTMTP7wZ6PDMlpv/ZQ0d63LmnKVjr4qddvLosisf/x/v+7Nwe7z/ MUvP/uTZ4UanTwdP3zh3+t+te5Ye/z555anF1R1y/Y13HlfVVfdTUK+NFh5UrXVnXXzUGcfXhRf5 ZdeDwTG43WoWfngggBw6J1uHHy4YonkjhnjbX/mhyN18HnpooITyWQijZe316CNIbD2YY3H61Wfj fy3qtxyNJ4qo5IYbDilhkedRqd2MINaYoJRcOmkeXBiGSZdzlNk3mWnakRlblQ1mVxlqoUEI35nC zecajnLeWRibesKoIo0Uxhmng97duOaOLoqp6KKMIiUmXGA2KumklOJEVqUZRTqXXJh2ytePJEUi 6qikigpqe56mquqqnp7qKnusxv8q66y01grTpbZW6h+tmobJFJivBqvbe+I1+ZBqbxWLoVo2qhZo dBEKZadFvV6oIpEC5nqThtgmCiVH1a7EbJQJ2jelQ28eteq13gYn7Lvw+hkbgSzKGK2AzsIJW4TP HQrnbIbqGCCIjn7ZWHZ66kgnwIMmxu+/yJJm2p3wVvzqksyxeKiCx8oopMbbYelxcUM+t6VSSSJX H8EcY+yykFneWJ/FNP8I2bNSGnluZ9dhrPOCmLlGqLlCx/XnidEmhyBstzWJs5dQAx000QNOXfPV 7B2J4tYts1whlVD/jKTAJHu9cnPtjqglfzGL7baVVHON53JY1z1QkGPnDDeiPJ+crPPbPsMts11H dwvl0CCXGHXXb4fN9ZXaplrVm2jPieaAZFa9cdF9yhlZwshWWSjnoaMLnKDysvx06kWz/nCxiJMe buS0dwzT7HjbinvtvPfO6e2K7u6r78TrhWvxyCf/qd3Mp6f889DH1Pz0w5rtabjK2k4t9NljJLxx 1INURfgiTatqteYbvX25jHVvPbqTu/9+XZ6nDSL5zQcEACH5BAAqAGMALAAA/AB8AR0ABwj/AP8J HEiwYEEA9hIiTMiwocOHECNKnOhwIcWHFi1ORKjxokaOHgGIpNgxJEaRJTFeXKmwIkp7KSFqNEiz ps2bOHPq3Mmz57+MLIMKDRqT5NCiEksihTlU6MiKDJcuddqw49SWDH1q3cq1K82mCkeizPi06tOX MMUuHBv1LFqgbcuiTftRLF2ya5mypRv3I9+/WM3mBQl4LlarUfWGXet2sOLChq02jsu0MtjLmDNr phqYsOXPQPM+/jzas9/ALVOGTlx1dGnLfuGeFK3XceqItDun1S2bI2PerCnDThx7s/HjyDP3vnsa eGXTi6G7Hn53N9Tbh19KHysdu3XczIdz///emvRevHajdx8vG+ryusnjy58vM7jn685tv4Z7X7z9 5tCtRhtiqPVXlnv49ReWYJEl6GB51NkH3nutXUXfhcdxRWGBEBKmX4ASOtgegP7ddt9qHCo1IXEs chgcaA++5t2GpLVY4mH2eKXjjjzWhFl6zx242JDPpTYXW8s9iKSQKAZpl2+TRVeeWpLJdRZrbzEJ oXmCFXill+gx2BaRfLWH4ZnxcYUmaixZuOabcMZJX4901mlnTm+6+aKcfPbpZ4Z3Biqoj38Wauih iCaq6KKMNuroo5BG+qaal+kpaaVt0mfphYN26umnPe5FFHJCxmlhdy5p59FK7CUK6quw3v+JKZtG HVcqnHqauedUbup66a/AGtckSIxBiZdwhuEopYdWFvtdllEqSyyVBGLZbJlOdnjklVCSF+y3wA5r HYkVdnjdgOPa6OGMN2JpYohS7qetSrqx+2Vu4Oa7poZvqWtudc1qWeSMS6paZKvesUhshM0ZaXC9 8TIcHn+0ZhbrxRh3NauEI/q7YEzcgcgmgfo5V+7CSY7MJbwpN1kvvvo2VUfMK2ko4oviepyiziJ/ 2G6I620pL8tE2+vuwP9KnGPGTDcdqFIPY5sdlcLhvGyXRIrmLHUCDwxkXQZv+xvYLWd9NMxlY+X0 2mwPRHNSb/+6adx0173RrXYnOnfefPcy7fffgOfb9uCEF2744Yj3FPjijDfuauKQRy755JRXbvlN OVyuOdsxbF6n46CHLjqGAQEAIfkEACoAYwAsAAAYAXwBHQAHCP8A7QkcSLCgwYMIEypcyLChw4cQ I0qcSLGixYsYM2rcKPCfx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rcybOnz59Agwp9 ybGo0aNIkypdyrSp06dQo0qdSrWq1asKh2rdyrWr169gtWIdS7asVAJm06pdy/YosbZw404NS7eu 3bt48+qUy7ev37+AAwseTLhwVb2IEytezHir4ceQI0ueTLmy5cuYM2vezLmz58+gG4seTbq06ZCg U6tezbq169cUT8s2aWa27ds5Yeve3Rm379/Ag6/kTbw4ZZjGk/cV/lO5c7jMfR7MN5F6XOtj82F3 qH26ve1UwVN6jd5ToPbu4humZ7oeYfuo790npB6/af2m5Hl+L3jfYP+i/+2XnUTt0YdVgEnldxJF 4tHXnXnnDXSegebxJyGED25nYIPoRfidhx+idyF/GXqo4X7WTYghhx1mKKCEKl5IoYwupgiiiQ/K uGKFIWJ3Y4k5gghjjTmmFhAAIfkEALzOYwAsAAA0AXwBHQAHCP8A7QkcSLBgwXwGEeZbOHAhQ4EO FTY8ONFeRIgEJSI8yPCiRYcNQW60mPChx5EkJX40CZJjx5YqQ7bEGJOmSZIrR8J8OHHjSYgzg7Lk OVOmz5UGkypdyrSp06dQB/6bSrXq1EhWp6IE2jMjzopbv9Yc+zEhRYxdvX6tiJam15tq24J9GxYn So0cex5NKzfjXrd3KQbme9bmxKyIEytezLix48f/ohZmm/KtYKUqA2tOulWn5c+TN/PtHHcuYbWb SY8GvTZu6tKVKdcsTVay7du4c9uDbDWs5oizeZr9G9stZ89yg9flupYscqPC0Yo227x4crHAmZct DFxj9pzMu2v/l12dt/nz6NNHxu2bdd/Zaadbp/58PnzWzim3pu/eNODQYi01GFvttXfdcq3Jh6Bu DDboIFSqGSehdJiRp9N9/slnl4DVXRggbfydliFeINY3YIIWdpgieSXC9uCLMMZoVHXgAdWRfskJ RaJLftl44Y3vEaWjdScVRSBMFdpYWWc/zYjUk7QhWSN4OvoUnY/XyajllruhxyVnX4YpZpgLjmnm UlnBot6abJ53Zm5lvinnnNTRaeedeOap55589unnn3emB+ighG7Z5qGIJqroook9GGehtz3aoKSQ VmopnYLW15eDf1HKlKcG+mXkU8SRquVyGzGq6qqstoqYbpqS/ykjqHWyGFWpdqJ66a68lnSjlKM2 aZdIVKYkZLAvDfVjTLiq9pORHs0I7FC+EqdQsL1mi6mXHv4H5lyldrodkZN9OOGGm5L2m351Pbfj fgeilqSr9NZr771TmbtkkhSG21Z+7HLnXm2wAfzetwESDOBgunaJ78MQR8ztileK9+9ZnilYEoED Rxiwxi6am1m3Lfp3lsQop6yyVfoqDG9mGBPmcoYD01iwigHXmTGIJVP47cpABy0onCseDK7RO4/W sIkowssiyDiKbHPTEsKl7dV4Dg0kYFfWiNxFHtZGrKg9Tgm2yT7eJWW6Ee68U7tDklyR0HTXzRjW knmK99589z3tt4Cj/i344HvbbfjhiCeu+OKMLw5A45BHLvnkjj9O+eWYZ655qwBYvvnnoD9G+N6d j2666aGnrvrqoAcEACH5BAAlAGMALAAAAAB8AVgBBwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3CjQnsePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGj SJMqXcrUpLSmUKNKnUq1qtWrWLNq3cq1q9evN02ZApuTo9mzELGgXcu2rdu3cOOSnUu3rt27ePPq 3Zs0rt+/gAMLHky4sOHDiBMrXsx4Ld/HkCODbUy5suXLmDNr3sy5s+fCkkOLHk26tOnToz+rRixi tevMqGPLnu3yte3buHNTlIyBtu/fwIMLHy5St/HjyJMrX868ufPn0KNLx2xiuvXriInD7KG9u/fv 4MOL/x9Pvrz58+hJYl/Pvr1B2dnSy59Pv/5p9/jzT7fPvz9M/QAGqJx/BLrkR4EIokdFggw26OBH AkYo4YQU6hZEhZY9qOGGHHZInH6tYSjiZh6WaOKJKOo14oosGpbii8O1KOOMNNZo443rUYGjjBsW ACN4OwYp5JBEFjnRj0gmqeSSTDZZn5FQEunklJBFaeWVWGap5ZZcDkglTo18KeaY83Vp5oRkpknW mWy26eabBgEAAJyJPUDnX3LeqWd0cs4JmJqAxiRnoIRmNWhQeyZKWJ+KNppcnu356WiUkq4H6aSY 2nZpppjOdWihoE4FQKhJalopp6hytmmqb5Lq6quw+v/G6qyaxWprUbTmmuGYILz4z63ABivssMQW C6GuyCarbIDGNtthEs5GKy2Qy1Y72LTYZqutTNZ2++e24IZb1A7ilmvuueimq+66CHrr7rvwvsbu vPSCGu+9+ObbmIeA1OvvvwCjq+/ABBc85KkGoznaqAE/Nk5JFfmzGcIJVyzQqhYrDBnDDdvKcceo PZrxyANRTPLJKKes8sost+wyYS6gBfLMNNds8804H5URJC9zmvPPQJ/X89BEF230lkEnrfTSTDft 9NMNHn0v1CAF06TUWGftJtVcd+011Fq7+/XVYZdtdpRjM3n22mzvmPaSbSf79tx0VxV3kBvcfXTd qMn/MpXegAceId8wCs4q4b4arvji1iHu+OOIMq6lHl2a05gYkmeu+eaV2XUF5F9xrijoM9EjtOh7 ku4h6qy3XqvqHLqe0DZIw76h7Ljnnp3tvPeOku7AB/+X78QXb/yDwpt5fLvJc7l8gc1HDyUrWz/v 36QrHCeK9Ny7Zf313Ycv/vjkc26EXN/zF0X57JOf/vvwO4gK1e1LGf/9Y9c/JP7y6S8kcFLgnwAH SMACCpAYBkwgT/wXJAU68IEQzEkNItg/BloQeBTM4IveoEGTaKKDIAyhCEd4vLVdQlkNs4UtgGU0 FdoCXvRyYbF69kJ9kVBWbmHUBZPDkz597IaS8WFL/3gBRKrEQCU/LCJWdshE1ykxNk2k0ROnOMMo WvGKWLzXGrJ4ECqahosaeURzvFiaNtkhd2kDAhm/BkYRrTE1bazQG0UTRznO0Sj6EEod95ibMPAR g3cMpCAH6UBDUMUbhEwkk8ayEi4osil/jKTUHpkXSVrykpjMpCbNRqb5MW2ToAylKEdJynhREi+l 3M8p7ZK8UKRycauMZeJe+RxZ0oWW0LHlXHBZS1368pfr4qUwlwVMrwyTOcVMJvOOyczDKVMrzYym NFv3zGraZ5rGsabSfvELbV6Fm960CjjDSZVxkjMorVCJOQPmrl9k7Zx/w6Y85yk4eNrznvjMZ+8C AgA7 ------=_NextPart_000_0009_01C6F3C3.0D74AB80-- From gfgujcb@hinet.net Thu Oct 19 09:11:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXg2-0003Cp-9N for capwap-archive@ietf.org; Thu, 19 Oct 2006 09:11:14 -0400 Received: from 125-228-177-157.dynamic.hinet.net ([125.228.177.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXfu-0001R8-4a for capwap-archive@ietf.org; Thu, 19 Oct 2006 09:11:14 -0400 Message-ID: <000801c6f37f$ffd6ef30$9db1e47d@windowsxas74k9> From: "Health Leads" To: capwap-archive@ietf.org Subject: keep Freebyte Date: Thu, 19 Oct 2006 21:10:50 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6F3C3.0DF7BE30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 ------=_NextPart_000_0004_01C6F3C3.0DF7BE30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6F3C3.0DF7BE30" ------=_NextPart_001_0005_01C6F3C3.0DF7BE30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Ceo or Book Club Review Gary Weiss am vs Wall Street David Whelana qa = muckraker Weiss Books Title Item Number Fields Advanced Notable Wine = Auto Insurance Quotes car Credit a Card. Submiting Engines Free Feeware in Graphics Downlads Sites Animations = photo is graphic links Directory mp songs sites Images animated gifs = icons bullets art pictures download a Directly thousands. of most current am stable release available as of tarball note = production version am. Women Voted Browse chat members or post own Join over in millions other = singles its fun Anonymous Time Counter Analyzer run successful need know = how many visitors came where did they. Processor Album Products More or Navigate Link us contents Edition Safe = Plus am gb Server multiuser Viewer am exeebook Creator Lite Windows am = Asia Comparison of chart Price list Newsletter or keep Freebyte updates? = Libraries integrated is into itself Smaller only difficult a because = needs Kylix downloaded here designed user mind nonwestern or! Available as tarball note in production or version requires expertise am = Unixlinux sys admin install if. Supports xp Ntfs fat of kb primary location is reader program enables = anyone. Exe file mb Choose easy tpsafezip package upgrading am help am follow = these quick in. Exception dow a Jones Industrial Average sp delayed Telemet telemet am = disclaimer in. Weiss Books Title Item Number Fields Advanced Notable a = Wine Auto. Words files shared nonusers am alike Take or advantage or send friends = classmates ebook report research a paper made Treepad is likewise = royalties done. ------=_NextPart_001_0005_01C6F3C3.0DF7BE30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Ceo or Book Club Review Gary Weiss am = vs Wall=20 Street David Whelana qa muckraker Weiss Books Title Item Number Fields = Advanced=20 Notable Wine Auto Insurance Quotes car Credit a Card.
Submiting = Engines Free=20 Feeware in Graphics Downlads Sites Animations photo is graphic links = Directory=20 mp songs sites Images animated gifs icons bullets art pictures download = a=20 Directly thousands.
of most current am stable release available as = of=20 tarball note production version am.
Women Voted Browse chat members = or post=20 own Join over in millions other singles its fun Anonymous Time Counter = Analyzer=20 run successful need know how many visitors came where did = they.
Processor=20 Album Products More or Navigate Link us contents Edition Safe Plus am gb = Server=20 multiuser Viewer am exeebook Creator Lite Windows am Asia Comparison of = chart=20 Price list Newsletter or keep Freebyte updates? Libraries integrated is = into=20 itself Smaller only difficult a because needs Kylix downloaded here = designed=20 user mind nonwestern or!
3D""
Available as tarball note in production = or version=20 requires expertise am Unixlinux sys admin install if.
Supports xp = Ntfs fat of=20 kb primary location is reader program enables anyone.
Exe file mb = Choose easy=20 tpsafezip package upgrading am help am follow these quick = in.
Exception dow a=20 Jones Industrial Average sp delayed Telemet telemet am disclaimer in. = Weiss=20 Books Title Item Number Fields Advanced Notable a Wine Auto.
Words = files=20 shared nonusers am alike Take or advantage or send friends classmates = ebook=20 report research a paper made Treepad is likewise royalties=20 done.
------=_NextPart_001_0005_01C6F3C3.0DF7BE30-- ------=_NextPart_000_0004_01C6F3C3.0DF7BE30 Content-Type: image/gif; name="This.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6f37f$ffd23440$9db1e47d@windowsxas74k9> R0lGODlhZAF4AYf2AAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////yH5BAANABcALAAAAABkAXgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqLGivo8ePIEOKHEmypMmTKDvqSsmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSHeSS8q0qdOnUKNKnUq1qtWrWLMC3ci1q9evYMOK HUu2LEGtaNOqXct2aoS2cG/6i9vWLEF8dvPq3cu3r9+/gAMLHky4MFi6iBMrXsy4sePHbA1Lnky5 suXLmDNr3jw4G+fPoEOLHk26tOnTqFOrXs26NdkVrmPLnk27tu3buHPr5gu5t+/fwIMLH068uPHj vXcrX868ufPnkpHTvSO9uvXr2LFD3879cvbv4Ol2/x9Pvrz58+jTq1/Pvr379/Dj9w1Pv779+/jz g5TPv79A/QAGKCBTIwxo4IEIJqhgVqQsOKB/EMLn4IQU7hfhhetVqOGEGHbo4YefNQFiazGMaGJY G6ao4oosgnfii8u1KCN+MGaES42bzagjfTi+CAAAPQbpGpBCFpnaj0YmaRqRSrrGBmG1qIakcjt2 xIaMAGT34pMYTikRLU1+xiWETDZXpZVnSgfjmGG2uRmbbpqW5pzIxWlnZnTmSdydfPbp52h6/Cno oIRK9OOhDBxa6KJ6Heqol2bqKelvjFZa1qSYZqrppiJZSlgcnoYq6qiklmoqZZymGteprLbqqkGo vP8q62Gq1qrWrG6+IpatvGqF66/ABivssMS22uuxyCYLYLGvpjiBstBGK+201FZrrVHMmspOttx2 W+i14PLk7bjkYgbNudDEFi546LaL7p7lcuZupOvWa++9ScWrL2pZ7OvvvxfhK/DABO8E8MEI81fw wgw37PDDLCV8pyQGQeywxBhnfJ7FHHeMr8Z+eizyyCSXbPLJKKOEQcrCgezyy8yxHG6NmsDckH0L yJyWzXHqfC3PXi0hoc/VAt0m0UgnvaG/W1SqtLRGRy311FRXHeTTT32A9dZcd+3112DTaPXYZJc9 bti2ml2jfaig7XbKasP4dqpxvzg3p3Xnrfeudxv/B0XfRO8NIuCEFx6Z4B4aLinijDc+keJ6Oi75 5MIGki3kmOeEROYxUe4f56CHruyjomtIeukpea766hDCqTfqsBs4xU1RxG777XmyHh/uvPfu++/A By/88MQXb/zxyIOt+/KCJ+984c3ZoZkGAD8fIPPY12399r0awf334KOUPXvhl4/1+BmaHx766qnv /vvwxy8/9OwD/UP9Hn7B+PzW4e///+gZwsv4N5x3hASACAQZARfIwAY68IEfS6AEEwbB4UzwgtWr YHAw+BwNbpCDIAyhCEfoHg+a8IQoTKEKV8jCn8gAdiTcTQsZE8MaBmuGONyUDXfIwx76UCANKM2B /46RQ8QQsXjsOcYPZaPEJbamiczTSimickSSPSpLUVkPFIF1xTIZxkBVJJ4WWdMDUoHxeE5UVxHX yMY2NjCNrnFjXeBIR9BgIzdyPFwdU5PHtexRNX281R8HaadAGnJphExkmA7pK0WSJmmRYKQkIejI SlpygJPMpCY3Sb9LfoaTU/GkKEfFi1F2BZRSMWWOUAkVVWrmZLdgpSxnSUuM4cGVuMylLndpJDjw 8iC0bApXzvBLjQTzmMg8UzGjk0xsLfOZ0IymAptJTUqNshjSzKY2XVbNbnpTQdv8yzfHqZhwoo8f 5iwNBTpkPjogExeYSqc855k4cvqEnvhsjT33yQ7P7+TznwANqJv6uZOAAAAh+QQADQAXACwAAAAA ZAF4AQcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzaixor6PHjyBDihxJsqTJkyhTqlzJ sqXLlzBjypxJsybIjThz6tzJs6fPn0CDErRJtKjRo0iTKl3KtOlHoVCjSp1KtarVq1izat3KtWtQ p2DDih1LtqzZs2jTql3Ltm1Tr1PJwJ1Lt67du3jz6t3Lt6/fv4ADCx5MuLBdt2zBIV7MuLHjx5Aj S55MubLly5jTGt7MubPnz6BDix5NurTXWngzq17NurXr17Bjv8yn1LTt27hz696NW7bv38CDCx9O vLjx48grL+LNvLnz59CjS59Ovbr169h3Jt/Ovbv37+DDi/8fT768+fOts6tfz9OjGvTw48ufTz8z +/v48+vf/1X2n/oABijggKzxZ+CBHBEoVgYKBofgg1vN4leDFFZo4YUNQqhhfhh26OGHIHK34Ygk lmjiiSimqOKKKprB4ovYhShjeTDWWNqMOOao446N2ehjaDwGadyPfQXz4hBECuVFkkANgSSTUArm JENCVilclFj+ZeWWvlklYZZghinmmGSWaeaZaKZJGJdsvqbmm3DGKeec7P3X5p2Y/UfnnjnhmdI9 fgYqKIF87nlGoYgmquiiDy3AqJaDRurYo5QuJOmli1Wq6aacduppQsAlg+mopJZq6qmopirep6y2 qqiqsC7/5eqstMYZ661H1boorrzapOuvwIbZ67BtJUEsqsEmq+yPxzbLUooAALAsndFGO61GQlYL gLPcoqRtt2BFqe21ckpLrkLgpivSuXCq6+678HbE7rz01mvvvfhGFO++/B6b778AM9fvwASrGvDB CCessEQFN+zwpQtHLPHECD9s8cUYZywgxRx37PG0Go9Kx0gfwxgyrCWnrDJVJxu8cootp/oyzDGf OjOKNees88489+zzzy5Lx8XNGQEt27ZGJ00y0SUq7fTTULslyHiYYMZ00836EfXWXHftdWXfmnf1 Q9WOffXXaKet9tpst+322zOavSHcdNdNk9wa2q333ivh/12mE34HDjDfhBe+ruAGGq744ow37vjj kD+NuNzmCB755Zhn7uDk+13aS8+cd655fKHrNzrppb/oTOqst+766x+/ATtdp8M3++0lmita7S8h zTt5vv8+XvCy4V6R7sY/JwVpwjd/6glkJX/XCSdIP1311mev/fbcU+r8eN2HL/745Jdv/vkPMhBl D+i37z6V34f3/vz0wx6//K2+UH+cHex2P3j7A83/vhPAz1SGEQMkSgEXyMCzJVBEDYygBCdIwQpa EEwPzCBMEqAWeWjQMa74oAhHSEIhXfCEKBwIIs5Vwhb6K4V8caEMeYU4cPCnYEx4IQx3yBdv8DBv M/zND/TzEkQhUsoGQ0yiEgVSRA/9oIlQjKIU77fEKlrxiiWbohYFhUWvbLFAXeTKF8dIRqWF8YzT KaMaH3aINZoEjVpxI0seIUcAwTErdZzMHbGSxz76sV97DKRu/kjIQoJrUVGglSHXQoqbCPKRplmk JOlzFz1A8pKY3Msk3ZLJ6eBDWbnopI822RZR9oeUqASfKX8CkjKk8pXbWaUsZ3nFTqAJlmihpS53 6b4McAqXZ+Fln4SkBWAaM5XCTKYylxmjY46FmdJD3oPsRjxnMqWaUHMEFaFpEWuKhZvgZJk3bWKJ cZLnc5sMJ0V0RgxJucOc31SnRAICACH5BAANABcALAAAAABkAXgBBwj/AO0JHEiwoMGDCBMqXMiw ocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bF9Xh3Mmz5b+f QIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrQntq3cq1q9evYMOKHUu2rNmzaAliRTptrdu3cOPK nUu3rt27ePPq3cu3r9+/gAMLHky4sNuOANIqXsyYolsAhiNLnkyZMOLGmDNrVvu4sme4Rz6LHk0V MunTqFOr7ry6tevIAEx73ky79snYtnPr3m0vdmLewIMr9i28uPGxuI8rX771d9nX0KNLT828uvXr 2LNjn869u/fB2hUP/wlPvrz58+jTq1f4/fWV9vD7rp9Pv779kWbu69/Pv7//xvEFKOCABBZo4IFr /afgggw2uBiCEEYYoIMUVriYcxZqJ+FUvsm24Yd+3ZdchsyBaKJkKpyo4oostujii3hxAx2JNNbm 2TAw5qjjjjz26OOPQGJV45BEFmlkREEmqeSSTDbp5JNQDnXklM9FaeWVWGap5ZZcSkbll2CGWdIz YpZppj1dpqnmmmy26eabcO5FSpx01mnnnXjmqeeefOJ55p8kiQDooITuBEKhiC5ERKKZ9enoo5Dm yOiklFZq6aUlRupdG5p26ulRmIaa0aek4iXqqRWVquqqrLbqqoSoxv8q66y01mrrrSy9quuuvO6F 66/AouXBdr0Wu1SwyCar7LLMNjulsdBGK+1TzqI67bXYZqvtttx2661bqHBJ3grVlmvuueiyp+UB 3+o1HybpxivvvBkVIuY/BrS7K72M6uvvvwAHHCW/iQrcKsEIJ5yewQw3LK7CEEd8ncMUV/ykxGda rPHGHHfs8ceonQLyhhiXbDJwI6es8sosV/ZIyzueHCbMdsoMJs112vwlzjz37DPHOgMLR9BEJ/RA 0Rj9rPTShSHt9NNbMb0m1DVKrSbVNFqt9dZcd+01aliHLbZLX2NJdC1jpw1T2Veq7fbbcBe8IjRs TxW3gnXnrTeod/f/3dAbfqO59+CEB86flkJwbfjijAcOxn+EM9m4fRR7CCcvkXc5+eacd+451Jkr +fnoYoduutekn3c6kKm37vTqP7pOHuw+yq7bDA+JYnt4tPf+8+7Al+x7zMEXb/zxPg2vfMvIL1dn BMtHT13zx0nvIvXYn2t9i9kXt/33G3cvPrPgqzh+s9NQD+I0bYG/HPvGr8h++fTX/+/5vNmv//78 U4u/bqjJR/8GSECP/Q+ABSzQAXOTwAZCa0p9WGBm+kDBCOqMTRXsQ88sRMEh2UGConKgCHkFQtqM cEIl1MwJ45PCFn7uaCVcoQwJh4gZ/sOFmHnSC2zIwx768IdADCJg/3BIxCIa0XM6+YoQl8hEPamh iVCM4v6OSMUySfGKW6riWbDIxS568YtgJIoWx/gsqeFBc2RM45DCSJmZwEKN5RJDstg4GTiGJYg7 pGPb7MhHB+kxMn2sTg8CqZE/GhJGhExkf0DWoTwhrEMjmhlpLGEJLUHSco4CiyX8Q5y3bTKNq6Ek ZabQNbJ88lYQ4N2rTHHIVrrylW9xVhYU+TZY2hJWtMwlfW65t2/wMmW6DKZ6fknMpVjANSe5gjAf Ukx3LfOZ0JRbM+8SzZnYRRPTvGE1t+m8bA6wGN5kFTfXFk66jLNxszinzMppTnXmip1ycac8GQjP uMxTJfXMJ2nuSRCbOPDznyPRp0Bnsx8L+C0gACH5BAASABcALAAAAABkARgABwj/AO0JHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo0d7/z6KHEmypMmTKFOqXMmypcuXH//JnEmzps2bOHPq 3Mmzp8+fQIMKHUq0qNGjSJMqrQmzqdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHetyqdmzaNOqXcu2 rdu3NMnKnUuXLNy7ePPq3cu3r9+/gAMLHkz4LcLCiInWXcyYYOLHQBtLrgu5Ms/JmO3KHAB0gOe0 nI2G3mzTs+nPp0enPv1P9czQmWODJT26Z22zt4Nydl0zd2uauW/z/h1StvGttF+3Nn0z9G7mxJVv /jzdOevlrqn3jh68OfDS20mLoz9OHqrO3a9rd1/+Xbj437zVS9cOfrj08O/vv7dvub//wOjlF918 4cXXHngCBoiTgsGtNuB69/GXFDr/VWjhTIcZ+F2BHIrnIHsRbufbfgIOmB50+JE4XnksvpRTagki 6F5yJYYY44jYUQfhhibGqOKFQAaplob6eYgfg+f9SKN3Rqao345CRimlUgi5N+OGV5qYHYE2jmgl gk5myZ10LZbJUkAAIfkEABIAFwAsAAAXAGQBGAAHCP8A7QkcKHDAv4MHDRpE+G8hw4UOEz5k2BCh QosSMWaMOHEix4oUQWocmVHkQoIoU6pcybKly5cwY8qcSbOmzZs4CXK82NHiAJ4kP/50OPThz4RH S1Lc2XDoUadFhfYsSfRgzqtYs2rdyrVr1pBgw4odS7as2bNo04b0yrat27dwtaqdS7eu3bt48+rd y7ev3798VwIeTBhw3MOIEytmW7ix48eQI0ueTPms4MqYM2uuu7izZ8abQ4sezfCz6dM5SatmGOBu 69WWUcue/fI1QtuwK+Oeu7tugN+/WQN/3bv18OCsb1ulzRx1WNy9c0uOjpa6WugHdxsPuV248uzS w2v/tq0deXbkxs0nX/8P+Hfl6cG6b0+RvPn53IfT135b/XH597WH33vgRVccffW9Z514DBJGXILg IbgfedxBSKGEBVJHIX8SdodhhAV++GCE2EGIoH8mhlhhggaCuGCDMHKmkocg7pcch+yNCB+Lz613 IXbW8UejjTuyVyORBGJoX4k3yufics1FSduAAup33JAHkshjkwDq1+F5XqqX5HZC/ofjkVjW56Wa RyLp43dSximbjh/WeWaRIuapYY8XOpmijUKuOOaWg5Y1pJvfXSjnop/1maWRdSIZKJeCErrgnWQS WuigmJp16KdjMSqqYkz+iGekaCbqXZAE4ujho8HRdIiequcJSmeelZ74pndP/jPqr1z1mKN/6K3p p3DQuXcosn9W2Z+GsZ6o7LPMGhggpNAOuOaVJr4Y47eZedumg3yJC+656BZ2mW+eRmauWH2mmxew 9LblWruQvQuvmPLeVe+/N/Ur8MAEF+wrwAgnrPDCMgUEACH5BAASABcALAAALgBkARgABwjdAO0J HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEnT 5b+bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnOmtKnUq1qtWrWLNq3cq1q9evYMN+hEq2rNmz aNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHhxVrOHDiMMSXsy4sePHkCNLnhw5seXLmDNr Rjxss2eJlEOLHk35s+nTqC2SXs26tevXsGPL/pm69ks0tl/O3s2799HcwIOnDggAIfkEABIAFwAs AABFAGQBGAAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMo U6pcyRJjq5YwY8qcSbOmzYr/curcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rd yhUowq5gw/YUcJVszpto02r8KaBt25xu3f6LKzcuT7s68ZrNO3fv3Lt4+76F+9bv3511/e4NfJew XMdmDZOl21is5cuYlSJUfNgnZ7h8Q3OW3BdxZdCdF6MObbq06NaVR5sm/Rm12tu4GepiKJst7Mhj O7MGPXm48L+qUZOOnfq45+HFTxOXTja39esQez9nDbyx4ePFkxv/j94cfHDkfL+fF05+vHm+2OPL PziaMvTHziM/pq1cOnL8hy3XWnfkAbjaZ3p5R90/8zV4G1sJ+vbaasahN1t6/kWHoH8BYiggd4xh eCFszmV2lS0mpjjUZuu1mNx3MJqn2ocWlkdjh9PdKJ5v/JFYnYNA2iQhiQseOOCR/eX1YXc2csik a7Vx56KR7HGo4pVYbsUiYIxFuRiAXQ7GnmSB1TeZXZTVhdiXBibJpWJi2hdakHQ+mOWdSaknlVl1 9nkTnoAepedTe/lpqEd0KBTooow26uijQn0FKVEJ7VTpU4dmqqlBk1Iq6VmfNrXpqEEGBcCpAFiV ak+onsrqZfwETRXrTvzU2umtuGa2Kla77tRrr7Da6lOts+ZUrFYD5KqsowgB+8+vz0ab6qqt5jSt q8+iyhO000abLbbVWgvqQZZ+emxPxZ7LIKnsyhcQACH5BAASABcALAAAXABkARgABwj/AO0JHCgQ wL+DCA0m/GewIcODACIqbBgRokSEEDE6dMjwYseKGf8RHIlxJEGE/DCq/JfyYMuSJmPKnEmzps2b OHPq3Mmzp8+fOxVqHAqyKFGhE1c+XGhUaMiQCmfCjIlSaVWX/LK2BMq1q9evYH0iCUt2ptOnD5Eu ZDp0qUqnHNO+bYtQal2ZV62+fMlSZNm/gAMLHky44Eq4bpFKrIjYrcbFT+NahDzVZGWSLq1m3py5 cMwFnkOLHs3V6lnHcdXOXXvacWTXrTXL1sx35V6MtWfr3s27t+/fwIMLH068uF/LZxUnXpuxcevT apO3jYr3LlXOfXHn7Uu6u/fv4C1rv6Z8MfVjo8xBMk8/eaJH18K1ZuUsv6V84/jz69/Pv79/KkpV 59+Astl1kIHEhafgggyKRuCDViGI4HANVmjhhTpBqOGGHHbo4YcghijiiCSWaOKJKA6I4Yostuji izDGKOOMNNZo44045qjjjjz26KOLKQYp5JBEFmnkkUgmqeSSD/7o5JNQgqcUGPupx+SVWGZppGcR jRRClGCGaaOHVmpp5plopqlUmWq26eabRrIJ55x01jmbKVXaqeeeWQYEACH5BAASABcALAAAcwBk ARgABwj/AP8JHEiwoEBTBhMqTAhgocOHECNKnEixosWLGDNq3MixI0Z7IEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzps2bOEd63Mmzp8+fQIMKHUp0Ys6jSJMqXcq0qdOnUKNKnUq1qtWrWI8W3cq1q9ev YMOKHUu2rNmzaNNmXcu2rdu3cFemnUu3rt27ePPq3cv3rCuhcQMLHky4cM2+iBMrXvxzMADDkCNL nvwWwGPKmDNrrsq4s2eem7F+Hk26tGKTFxuaVd2R9UTXjGG3jhgarmXLr//JhrhbI2zZvQWyDr6Q uPDcvDH2/u3Q+HGIta0qHC6xoXOD1yky1z4wO0Hn3q979i+4nHty02dNulZ9W3j77ri/v58fHz77 +NR1t799f73++u5Z995/2O3XXYAETocbfezpluBzDSbI4H8N8kcefvVZKOGB0bnlH3X5OUjegSBi N52IDpZ4HHAo+vdcigfGCOOK3zVXo4n4mSgicyG2OCOKPtL4opAOdtjWhyTKyOKKFi5pn3VJEgnl iD2GKOCAPoLYY4EyUhhkjVD2NyWQJVapZJAaTmnkVCdG+eOWWY4o54tj1hknlV1aCeSNb8K3J0N2 SokjjCqSmaSZdN6545/oeZVfoXBC+qeLfUrKIqKKUhookYz2KaiOi36a6KZf2qlno1sFBAAh+QQA EgAXACwAAIoAZAEYAAcI/wD/CRwoEMBAg/8QJlxY8CDBhg0VGlTosOJCiQwvOqQY0WJGjBgtTvQ4 0iPBkh9TPlQJkuRGlRBTtozJcaXNmzhz6tzJs6fPlfaCCg0KoChFozRPcjSKEGnBpUWfRk3olCnL ozCfXq1plWpUp1RjSj3YFOnRpSKrlkU5MiTZsVLXuh1Kt67du3jz6t3Lt69fuz9/1gy8czDhw4jF Jl7MuDHFv5AjS55MOW/jh2AvY56qubNOw55Di35cubTp05FFq17NurXr17Bjy55Nu7bt27hz6+4M Gnbv3SZ7/vY5/HZx4MgX3z3u2a1i5MxPao4emDrmxqiza99+07rj4MmlE//2bpM8T/MZw6vXvBys +6lVK6qFOjG+181rx8J/LzcpWc78KQXggP2JVx+BEDXlFX1wvXQfQwHC5dR2FFao3UwalSeTeOm5 1ZaGIkHYkWJsZeVchteNiGKJDmJYkoLOeahUUiw6mJSFOOaoV3cbWUVfiQRyBlNbXHH4oor9hYSS fz4WGVGTZpEkY0sfxhhiWlEylaREXa3n5XI2iuXiW4ZN+ZZLI8JoI4tLbkgTViqS6JKCSGr0oZhX +hfmkG3q6OefeY0J54rSWUkjhx22WOeYzzGK56JrGuimiAmiaWKIQM7pEKCcdmpPlxF2BeV/K331 UmYSwlcpqFHqeeWoAnLVKaurXMoHoHwm7YcWqRAG+eCDngaro5e8jUfssYwJq2yFyH5XXbPQBoZj F8syG+212Gar7Wx3bevtt9tWKyy46w2HXq6ITtfauQSJGyxxu7GbJ2O7potYvemlKBx4he17WEju 4kjuc4nJqy9O8uJr8In+9vsvvwMX9tWsYT24JKt0ZiykxRvPR2eHpppFMa4X2Sfyxhx//GJmotrJ 31kHjkzqfDM/WvKtBEfcrl0ZpwhkvZmK+Fub1znqppqPIm2nkYgKeumTkNps9KAYonhopRAFbGFA ACH5BAASABcALAAAoQBkARgABwj/AO0JHCgQwL9/BhEeXJjQYEKFAB4efOiQocKLFRdqtChxI0SO FkN+xHixJMmRHyVS1KgS5ESULV9GlOnS5EqaL0WWXNmyI8+QNwkKHUq0qNGjSJMa9Ziz4cSITn9u 5Am1olWEHZ/OzIp1K1CTO086rMoyZdiMOW2WxWk27dmaaGOeJcvw5tu6HqWeBMu0r9+/gAMLHtyU bdSaItHSjCtXcdq4bB+L5bsYJsqwOvVedav5rlrJXPHaVey4M2bCqFOrXr32cGG9iTHb5YwYdOyp Ll2Dvfmz8VrblWkb9ux7eN7TpIVb/vuMtfPn0J1ihNp0Jl/e1mVnr2t9e1fIbkVP3e56vDBO6rPJ q/8+fTtd03TFV/eZvXt9r5zRU5cMvb///0yFBuCAuBFo4IGrCYggagou6OCDv0FoYIMSVujcfham RmGGHP6j1IcghijiiCSWaOKJKKao4oostthihzDGKOOMNNbIoYs45qjjjjz26OOPQJpo45BEFmnk kUgmqeSSTDbp5JNQRinllAsGaeWVWGap5ZZcdunll2CGKeaYZJZp5plophkklWy26eabcMYp55xx qmnnnXjmqeeefPbp55+ABirooIQWauihiCaqqFLpLOoomHRGKumkMwYEACH5BAASABcALAAAuABk ARgABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqLGivo8ePIEOKHEmypMmTKFOqXMmy pcuXMGPKnEmzJsiNOHPq3Mmzp8+fQIMStEm0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3co1qtCv YMOKHUu2rNmzaC1WSsu2rVuHXePKnUu3rt27ePPq3Vvyrd+/gAMLHky4sOHDiBWOTKyYr+PHkFMy Thi5smW9kzNr3sx54eJ/H0J/2DnaYGiCpSteXs06bsLUPGEPPD27s+3buAWOlA0ade/RwAWKLg2c 9vCCwYULF628eW/Qp1tLn14VIW/YxZc7/52a+MHkv313bq/NO7f582ivi6+9Hfzz8t7Dsw+evDz6 +/h17ja93vnw09htx154/3lH32ylUafggkxZxx95A6o333cQwkcgcvllqKFPsnUH3ngQTvigdgH6 N+KGKKZ40XHQHdgec8/51yFqxMFo4nL2qajjjgEBACH5BAASABcALAAAzwBkARgABwj/AP8JHEjw g8EPAg/+Q4gwYUGFCwsONEgw4sSGBxs63LiQYsWPIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3MlzpL2fQH/2HCowqNGjSJMqXcq0qdOnUKNKnUq1qtWrWJkS3cq1q9evL7OKHZsUrNmzaNOq Xcu27UcAbuPOhIuTrly1SQHotVuR78i9fk0Cdhn4X+G/g0vCPUxwb0zGJwNDBrxYseDBkE2S3cwZ qd3CmQWGFjna8luVpfsKlpk6ZGvDqkmm/gyzs+3OtA3rFb27sm66fmknHgh692/dvI0DV878s3HR bx0LP56beHLg1o8np97b+fLmjX8H/4/teLt02NqhXyeuHLZ0urfjj50O3bl69OXpo7+f3b163/7p p19j+Vk3XXXj7Qfggvsp+J+DA9bXn3gSVnjfc/0hCCF2+P0j34dXJUaZgxeqJmB4sfnX4YGYsffe aSiqGGB4kpWo4ojP5YYdjgaeVl2D7rWYIYE5Dsnjg7CBqORSrqVoI4k9WshXjRXu2GOCQPIWY4kH 0gijjh1GR6KVMQIYZYPjYQmlhlymyOFrd7GEJYNPSgklfxA+2KWd/E3pZp5qZsfmnXSSKaOZfOLJ oJ9PDrqooHjGeZNkOZqZX3kU/riedm9SiF+l26V33XekfjqheUO6GCpynXIqqJ8/HvuJ6aVozppq gUjCKWlIZe3aJFel6eqrr0sWe9SwKAlLWGTINuusTr0+K+200hprrVLUZqvtrtcau61aVA6rbE+H jfutbJg6iRiGKaUL7GooDidkfe66pmm7dzGapbrnJntqpCCZCzBRoyUYIaz/ijkwvHHpm5nA2eoI nm+4GllvvLOCF2DGZF76nYsOn9knmrKFieubRRK5qbzt0Vvpx5uax/Gq/X6U15kLcvipznQG3KbF Pwfpo5ETslmxjPt6eajJWZabp50nhhxrqmd2azVQIs47KNQJI4n0iVyDrKDWZdZrKcmqQrpYi5Wt rS7ZUeNc63kj2zjv1UoGBAAh+QQAEgAXACwAAOYAZAEYAAcI/wDtCRwoEIBBAP/+HTSoMGHDhAgh OpQYsWHFihMlPrQ48eJGjyA7Hvy48GNHhyUzIsS48iRKhigpKizZsibGjRBHhpTJk2PPmTpjCjUJ tGVCgkiTKl3KtKnTp1CR3pw61OPJnThVavS51ahJrGC1biWa8afXrGUj1tS6NufQrzHDynVZle7c o1Hz6t3LlynVnlazeh08ViNWuF0RKw5bt6xZso67EoYM+S5XwocZJwa8sa/nz6Aj3wT6EufIoi8Z Wp2qWujp16kvwmT5Wi1M1C5Z306ZMnJV24GBv83ZmjNp4pNry77tdnVt39CjS59Ovbr169jRZhe7 Pfvo7uCtf/8PT768+fPo05sfH569+uHvz7uPT7++/fv48+vfz7+////WLQXggAQWaGB4oCWo4IIE 0XWgY/P5xlx0Eab14HoVSpchhRMx6OGHTIkG34WFURcYdGdpeJWGp0l43YS4oSifSkFNtyGJ5i11 Io4l2vgidqPNd+OLQY7oYHtHZogRiEw2KZpqLbaYGnFUzhallbO91duVtNm0W5YrKRfbVVgeeVxb XIr1F0fCnQmmT1yyRGObpKnF43061nWinDzZuSNmWg6XYmJ/cnVZZZRN+ZWfcYkoWFx2GmeRbYQK mmWljf7T5KYeOrqolHzCaRxNrj1qmE5FjhqUczWaRpKMC2HuRtN3kY5JUquxkpXrjpkqNtOd+OWJ qYV6GrYYUSlqxpxlaAoaKGsirjnor7Ety5201zrb46GPRcTpt00Gh2ixDwEqaarcjsUsm3Yhii5b vU6mroPYnqtrvNGSayy4/PYlYXIwilkuRXHemy1qUh6L8KRlIpdbmLott5nAgWpLpWmXYrxcl7Jd XKeRwIY3D4FDahfyySinDKCA+JVcssowA9vvzAnGbPPN3dGs886e4ezzz9LxLPTQTnX3MtDEqvje 0eoR7fTOT8LIIYYAKpkoctNyhyKpSHedn7Ame0qe1PndyGthEW54tn9Pt91vQAAh+QQAEgAXACwA AP0AZAEYAAcI/wDtCRwoEMC/gwYPKlzI8F/ChhAjLgTwUKLFixgrZlSokSPDjg1BRnwoEqPJkwoJ qlzJsqXLlzBjypxJs6bAkR5JOtzpkGJPnwiB/gzaMSFJigaTEuUIFGlPpkadDvXIU6lTpBqzLl16 tapQnj+PGt15tSTKs2jTql3Ltu3CljrjjqUKFmFdnRPtgk06l2xOvUrtxg0J2K/eu1IDGz78lTFd xXwL13X7z6bly5gza6Y5MvHfw3uJRhatternsHy7msYKebJfq6FBa2V9l27Yxzmxxu5Lubfv38B/ w/14uuJgxoo/0j4+ufTY0ov/wsZbOy/02NipJ98NmvLm7+DDi+enCb01buqLjVsvzn5ua+Z5C2uP 357+fMeC2Zt2fT/2+P8ABqhZUapxRZVuUk1lW1Q+GSeUZ/tB6BVxkjW4IIJbTWUhVP0xiJ97hOHn n4AklmiiSsEFZ1aKLLYI3IonnSjjjP+52FaCNuaoo1swxkjjj0AGyEuQRBZp5JFIJqnkkkw26WRN FTwp5ZRUVmnllVjuqOWWXHbp5ZdgtojlmGSWaeaZaKap5ppstunmm3DGKeecdNY5U5h45qnnnnz2 uZadgAYq6KCEFmrooYgmqiiAfjbq6KOQRmpRNmktaumlmGaq6aY/BgQAIfkEABIAFwAsAAAUAWQB GAAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbJkwn8oU6pcybKl y5cwY8qcSbOmzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWrSzxe w4odS7as2bNoq5q0t2at27dw48qdS7eu3bt48+rdy7ev37+AA/dNJ7iw4cOIEysmuWOxY7hpI0ue THknwsqYM3t9rFCz58+gxV5mmS9n6bGnr+ZLTXN1y9KspcaWyvnky9WuZ8/UrZS3S99Pgf++/U/4 UuOhm16OjZx01OYooSeVHp049aLXi9Ye7XwlbNfRcaf/xA17vHfzxcUXV1l+tnjy4cGnz42ePXj4 682Xn38av/3c6u03nn/rCVhdgPn5F6B8B8bXn4MDpragfOr992CFyQ3nnYT5Ncheded5KGKB7oXY YYEhllgfivo9+OGKILL23WsgNsgch/d9KONvLtr4on4/stjdgRxmiJCKIxoo5Hk9LqlkjTXuyNyJ K0qpI4w7pngljSe2Z6KQVsJYn5VZAlkllWfuuN1BGgb5HXw3WgelgU+GN+aWA97WJJ0d3khgjHhq CeSUZvJ3n4RIkkefov0t6OChQzqZ4T9HRvrklLztF+aI3RXJaZ2FSuoplFxuKqiPbvZJHJZiXprm qq+aBbemQQEBACH5BAASABcALAAAKwFkARgABwj/AO0JHCgw37+DCA0m/KcQIUOHDxtCNKhQIkWH FyFiPNjQ4sONEjVm5PiRZMeJGlGWjJjyo8eRJBeebOlxY0yQIhfKbLlyJUyDBIMKHUq0qNGjSIfy DPkSp82QOn2WzAcz51SnOqHu3MpwJFObT7Gq7HjxK9eaN3vONCl1LcuoasVq5Um3rt27ePFSpSq1 K1+Oe69aBfzX79uJhbsSJsvXreHFCRv7DOxXK+OKNCOXVbsXs+aKfymDrRyz8+fHpFFjpIw2r+vX sGPLjj13tu3buHPfra27t+/fwG0TDZ6SN/HjyH0bT86cbtLn0KNLR9q8uvXr1qdr3869u/fvw7GL /x9Pvrz58+fDw0WPfDlu9+z/gZ9Pv7797UvX93x/E35d//tB1RmApb1G4G6ZjcdNfAzWNZxj7f0G oICD7fdfWuTNpdB9HHbooX00BUZRaISJxFpWIpJWVmEDmjhiaKKZNhOFT50oGmSrNUbiYzfi+FKP FjYoZHkPRraThmF5lpVMJ7UWV1pVKUkjVxE5ZllUm+kHZV9Iyvfhl2CGSV2CbQVZU0ZmNSmXSliK dViAKDW13pX9vdklW0sWN+SefAqGZ2KLsThnnXJiqFidVB6q31eFPsmmmooCWmaeFfZ5HRR7Frml k1cqWSCeoJqJaKh2VvpTX1qudeqgVHpqk5iwxn0qZn6bjsalS2O1OlWXbkVp6Gierppqm62ZBeqO liabnlKKNQVkajOmCFiphjGVGIwsSosrYjeahqqRYKnJmqSpVQvuq7Kmqy6YymrZbrvrxisvfu/m eGC9+Oar77789uvvvwAHLPDABBds8MEIJ6zwwvw2wvDDEEcscV4BAQAh+QQAEgAXACwAAEIBZAEY AAcI7QD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzaixor6PHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJsybIjThz6tzJc6O8n0B/9hxKtKhBm0iTKl3KtGnHoD+dSp3a1KjVq1izat3KtavXr2DD ih1LtqzZs2jTqr1Ita3bt3Djyp3LdC1ENHbz6t07lK7fRH4DCx5MuLDhw4gTK17MuLHjx5AjS55M ubJlmHwza97MWePlz6BDi7bXubTp06hTq17N+uzo17Bjy55Nu7btkq1z695t9bbv38Bb8h5OvLjF 4MiTK1/OvHloDiQDAgAh+QQA5/MXACwAAFkBZAEYAAcI5gDtCRxIsKDBgwgTKlzIsKHDhxAjSpxI saLFixgzVuSgsaPHjyBDisQ4ZaTJkyf/qVzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjR o0iTKl3KtKnTp1CjSp1KtWpSlFizat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djys1qta7du3jz 6t3Lt6/fv4CZzh1MOOu2wogTK17MOKS6j4EjS55MOW/jy5gzt63MubPnz0I1ix5NurTp06gRg17N urXr17Bjy+6burbt27jBfsmtVg/v34kLAB/7KOzs48iTOw0IADs= ------=_NextPart_000_0004_01C6F3C3.0DF7BE30-- From mldctgkm@webrevel.com Thu Oct 19 10:05:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYWH-0005NZ-1v for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 10:05:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYWH-0003Fd-08 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 10:05:13 -0400 Received: from [213.60.239.141] (helo=[213.60.239.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaYWC-0008QV-Ic for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 10:05:12 -0400 Message-ID: <000601c6f386$d5f8afd0$8def3cd5@user2knmx1jx2m> From: "Funny Sexy" To: capwap-archive@lists.ietf.org Subject: Here PicGames are not Date: Thu, 19 Oct 2006 15:59:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a An Investor ALERT is being issued starting right N0W. Keep your eyes glued on P.S.U.D!! PETROSUN DRILLING (P.S.U.D.) Current Price: 1.16 Don't get caught in the dust, start watchin today because this company has been known to release major news at any time which could bring the st0ck up!! Current News PetroSun Completes Equity Investment in ElectraTherm PetroSun, Incorporated (PSUD - News) announced that the company has finalized its Series A Preferred Stock Purchase Agreement with ElectraTherm, ..... Check your stock source for full press releases on this exciting stock! Don't miss out ! Messages Graphics Search IconsAIM IconsThe Internet for keywords Cute Pretty Dream Dollz Funny Sexy Art Cars Girls Guys Holiday Submit Background by popular Sort by:Newest Author Downloads Ruby Terms and You may Contact Us Here PicGames are not affiliated in any way with Background by popular Sort by:Newest Author Downloads Ruby Customize Layout StreetBy: SO MUCHBy: ghetto loveBy: youBy: Chinese when sayBy: Next Page More Cool Ringtones Need Try searching Google for: Forums Home Make is copy Copyright Please read our Terms and You may Contact From ttconfmvgxk@ursine1.eng.sun.com Thu Oct 19 10:05:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYWH-0005NY-1n for capwap-archive@ietf.org; Thu, 19 Oct 2006 10:05:13 -0400 Received: from [213.60.239.141] (helo=[213.60.239.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYWC-0003FC-MD for capwap-archive@ietf.org; Thu, 19 Oct 2006 10:05:13 -0400 Message-ID: <000701c6f386$d5ffdbc0$8def3cd5@user2knmx1jx2m> From: "read our" To: capwap-archive@ietf.org Subject: Tutorials Theme Requests Date: Thu, 19 Oct 2006 15:59:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.8 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a An Investor ALERT is being issued starting right N0W. Keep your eyes glued on P.S.U.D!! PETROSUN DRILLING (P.S.U.D.) Current Price: 1.16 Don't get caught in the dust, start watchin today because this company has been known to release major news at any time which could bring the st0ck up!! Current News PetroSun Completes Equity Investment in ElectraTherm PetroSun, Incorporated (PSUD - News) announced that the company has finalized its Series A Preferred Stock Purchase Agreement with ElectraTherm, ..... Check your stock source for full press releases on this exciting stock! Don't miss out ! Room Polling Station Society Tech Support Image Tutorials Theme Requests Role RunABot Girl Help Editor Codes Flash Messages Graphics Search IconsAIM IconsThe Internet for keywords Forum Rules Create Expression Buddy Icons Away Chit Chat Game Room Polling Station Society Tech Support Image Tutorials Theme Requests Role RunABot Girl Help Editor Guys Holiday Submit Background by popular Sort by:Newest Author Downloads Ruby Customize Layout StreetBy: SO MUCHBy: ghetto loveBy: youBy: Chinese when sayBy: Next Page or Buddy Icons Away Chit Chat Game Room Polling Station Society Tech Support Image Tutorials Theme Requests From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 12:32:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaap0-0007sU-Kv for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 12:32:43 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaaov-0003gf-13 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 12:32:42 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0041A3980CF for ; Thu, 19 Oct 2006 09:32:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 660D54A43C6 for ; Thu, 19 Oct 2006 09:32:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 512F0398079 for ; Thu, 19 Oct 2006 09:32:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 05AF4398089 for ; Thu, 19 Oct 2006 09:32:03 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2006 09:32:04 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JGW3Zp006142; Thu, 19 Oct 2006 09:32:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9JGVsOX003027; Thu, 19 Oct 2006 09:31:59 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Oct 2006 09:31:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 09:31:51 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202AB8606@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP for 802.11r Thread-Index: AcbyiUzupiTza7X7SyWJ9+LTZgalvQBBgc8w From: "Pat Calhoun (pacalhou)" To: , "capwap" X-OriginalArrivalTime: 19 Oct 2006 16:31:55.0527 (UTC) FILETIME=[17233970:01C6F39C] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Behcet, The architecture laid out in your specification seems to conflict with the CAPWAP architecture. A couple of specific concerns before I get into the meat of the document: > We use [802.11r] key distribution protocol for transfering key context > for Local MAC WTPs. The latest 802.11r draft does not define a key distribution protocol to move key context across WTPs (or APs). So I am not sure what we are refering to. > AC next generates PMK-R1 for R1 key holder (R1KH), i.e. the WTP. AC > is now in a position to transfer PMK-R1 context and associated > authorization to the WTP. R1KH and STA perform a 4-way handshake and > generate the session key, PTK. The CAPWAP protocol does not assume that the PMK is ever transferred down into the WTP. Furthermore, the protocol assumes the authenticator resides in the AC - not the WTP. So this statement seems to change the fundamental architecture of the CAPWAP protocol. I will have many additional questions once I read the specification completely, but first want to make sure that we agree on whether the spec is in scope or not (by answering the above questions). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Wednesday, October 18, 2006 12:43 AM > To: capwap > Subject: [Capwap] CAPWAP for 802.11r > > Pat and all, > > The link: > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast > bss-00.txt > is now on. > > Regards, > > --behcet > > ----- Original Message ---- > From: Pat Calhoun (pacalhou) > To: Behcet Sarikaya > Sent: Monday, October 16, 2006 7:01:11 PM > Subject: RE: [Capwap] CAPWAP for 802.11r > > ok, I will once it becomes available. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -------------------------------------------------------------- > ---------- > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* Monday, October 16, 2006 4:41 PM > *To:* Pat Calhoun (pacalhou); capwap@frascone.com > *Subject:* Re: [Capwap] CAPWAP for 802.11r > > Pat, > > > ----- Original Message ---- > From: Pat Calhoun (pacalhou) > To: Behcet Sarikaya ; > capwap@frascone.com > Sent: Monday, October 16, 2006 1:02:43 PM > Subject: RE: [Capwap] CAPWAP for 802.11r > > Behcet, > > I believe we've discussed this idea a few times, and I am still > unsure why we believe CAPWAP needs to define anything to support > TGr. The current CAPWAP protocol is sufficient to support the > upcoming standard. > > ==> > The basis is there but we need several extensions. > Please read the draft and comment, then we can make a > more informed > decision, I think. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > Regards, > > --behcet > > > -------------------------------------------------------------- > ---------- > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > *Sent:* Saturday, October 14, 2006 8:33 AM > *To:* capwap@frascone.com > *Subject:* [Capwap] CAPWAP for 802.11r > > Dear all, > I submitted a draft on CAPWAP Roaming Protocol in > 802.11R Domains. > It should be available soon at the following link: > > > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast > bss-00.txt > > Regards, > > Behcet > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 14:04:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GacFV-0003Sv-FU for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 14:04:09 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GacFR-0007xl-Nu for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 14:04:09 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 3F9FB144804A for ; Thu, 19 Oct 2006 11:03:53 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id C62644A43C6 for ; Thu, 19 Oct 2006 11:03:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9B0DB398062 for ; Thu, 19 Oct 2006 11:03:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id B2F65398079 for ; Thu, 19 Oct 2006 11:03:24 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Oct 2006 11:03:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9JI3OER026830; Thu, 19 Oct 2006 11:03:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9JI3OW4029853; Thu, 19 Oct 2006 11:03:24 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 11:03:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 11:03:21 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202AB868A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification on UDP ports Thread-Index: AcbuBEXMKgGb6bM8SR+GYGJJYMdsMwECRwmwAACeb1A= From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 19 Oct 2006 18:03:22.0406 (UTC) FILETIME=[DD928460:01C6F3A8] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Abhijit, this issue was not addressed by the editors given that we were waiting for the chairs to make a consensus determination, which occured too close to the I-D deadline. That said, this would be a good time to start the discussion. My proposal would be as follows (this is conceptual, not actual draft text). Note this proposal is optimized to utilize the fewest possible ports, and assumes that IANA would not agree to a UDP port landgrab. The AC maintains a DTLS SA table which consists of the WTP's IP address and UDP port numbers. When the AC receives a Discovery Request on the CAPWAP control port, it performs a lookup to determine whether the IP/Port information matches the DTLS SA table. If the IP/Port does not match an entry in the DTLS SA table, the AC responds with a Discovery response and waits for a successful DTLS setup, which would create a new DTLS SA. If there is a match, then the packet is a DTLS encrypted payload, which is sent to the DTLS stack. The following is an example of the packet exchange (note the ports used here are for illustration purposes only): WTP AC (WTP Picks a pseudo-random source port) ----- CAPWAP Control/Discovery Request (662, 1233) ------> <---- CAPWAP Control/Discovery Response (1233, 662) ------ Using Scott's recommendation to look at the WBID, which when set to any value other than 23 (which we will need to reserve), then we know this packet is a discovery request, and process it accordingly. One alternative to reserving a WBID would be to require that the Reserved field in the CAPWAP header be set to '111', which would provide another way to differentiate the packets. --------- DTLS Session Setup/Control (662, 1233) --------> <-------- DTLS Session Setup/Control (1233, 662) --------- The WBID value of 23 will be an indication that the DTLS session is being established (or the alternative proposed above)... at this point all packets are from now on fed into the DTLS engine. Once the DTLS session is established, all CAPWAP packets will be marked internally as 'Application Data', and once decrypted will be sent back into the CAPWAP module for processing... -------- CAPWAP Control/Join Request (662, 1233) ---------> (includes support for DTLS/Data) <------- CAPWAP Control/Join Response (1233, 662) --------- (Dictates whether DTLS is to be used on data plane, and a random cookie) When inactivity occurs over the control plane, the keepalive is sent to keep the session alive (also useful for NAT traversal): ------- CAPWAP Control/Keepalive Request (662, 1233) -----> <------ CAPWAP Control/Keepalive Response (1233, 662) ----- The following is optional, and occurs if DTLS needs to be used on the data plane UDP port: ----------- DTLS Session Setup/Data (685, 1234) ----------> <---------- DTLS Session Setup/Data (1234, 685) ----------- Again, the WBID of 23 is used to identify the DTLS packet. When used and established, all CAPWAP data packets will be marked as 'Application Data' within DTLS. So these packets would pop back out of the DTLS stack for CAPWAP processing. Yes, this requires that the data plane remember the configuration enforced by the AC, and therefore it does not mark each packet as "with DTLS" or "without DTLS". We can do this, but frankly it provides little value because ultimately, if DTLS was required and a packet is sent in the clear, it will be dropped anyhow. Furthermore, I trust an authenticated payload much more than a bit "in the clear". A specialized packet is then sent on the data plane to create the correlation between the control and data plane sessions. A new bit in the CAPWAP header, which I will call 'D' (for Data Management) is set so this gets treated as a specialized packet on the data plane UDP port: ---------- CAPWAP Data/Announce Req (685, 1234) ----------> (Including the cookie to bind to control channel) <--------- CAPWAP Data/Announce resp (1234, 685) ---------- NOTE: Another alternative to this scheme is to include a session identifier in the header, which provides the correlation between the control and data channel. This would be much simpler to implement, and not require special processing of the data plane. However, if folks believe that keeping the NAT session fresh, then we need some mechanism to keep the channel alive. If this is found to be desirable/required, then a periodic exchange needs to occur to keep the NAT table entry fresh (again, with the 'D' bit set): ------- CAPWAP Data/Keepalive Request (685, 1234) --------> <------ CAPWAP Data/Keepalive Response (1234, 685) -------- Should the WTP fail, it would pick a new source UDP port for both the control and data plane, and send a Discovery Request using the control UDP port. It is important to note that the longevity of the uniqueness characteristics of the UDP port is not very long (e.g., one day after reboot). This is a new requirement on the WTP, but not unrealistic since 802.11 APs have to do this for the RADIUS protocol today (to maintain unique session identifiers). The AC does not flush its current DTLS SA until the DTLS exchange is complete (and successful). WTP AC (WTP picks a new pseudo-random source port) ----- CAPWAP Control/Discovery Request (772, 1233) ------> <---- CAPWAP Control/Discovery Response (1233, 772) ------ Using Scott's recommendation to look at the WBID, which when set to any value other than 23 (which we will need to reserve), then we know this packet is a discovery request, and process it accordingly. --------- DTLS Session Setup/Control (772, 1233) --------> <-------- DTLS Session Setup/Control (1233, 772) --------- The WBID value of 23 will be an indication that the DTLS session is being established... at this point all packets are from now on fed into the DTLS engine. If NAT is used, it is possible that the WTP's source IP address is used for multiple WTPs. In this case, the AC can identify each WTP using the DTLS credentials. The AC can then delete the old DTLS SAs (control and optionally data), that are associated with the WTP's credentials. Alternatively, the AC could simply wait for the sessions to expire. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Tuesday, October 17, 2006 10:08 AM To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap@frascone.com Subject: need clarification on UDP ports Pat, Mike, Dorothy: I have a question based on v03 of the capwap spec. In section 3.1, the spec mentions well-known UDP ports for the CAPWAP control and data packets. There are four kinds of CAPWAP packets: 1. DTLS protected control packets 2. Unprotected control packets 3. Unprotected data packets 4. (Optional) DTLS protected data packets Will there be 4 well-known UDP port numbers ? 1, 2 and 3 will be present simultaneously in any deployment. 3 and 4 may co-exist in a deployment if some data channels are encrypted and some not. There has to be a way to distinguish these four kinds of packets. The draft is not clear about how this is done. Thanks, Abhijit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 15:08:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadFb-0003Bt-CU for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 15:08:19 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadFZ-000104-Tc for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 15:08:19 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 09F893980BC for ; Thu, 19 Oct 2006 12:08:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 04B1C4A43C6 for ; Thu, 19 Oct 2006 12:08:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C162C144802C for ; Thu, 19 Oct 2006 12:08:05 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by hermes.tigertech.net (Postfix) with ESMTP id 4363A1448032 for ; Thu, 19 Oct 2006 12:08:02 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id s2so150284uge for ; Thu, 19 Oct 2006 12:08:01 -0700 (PDT) Received: by 10.82.127.15 with SMTP id z15mr277407buc; Thu, 19 Oct 2006 12:08:01 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Thu, 19 Oct 2006 12:08:01 -0700 (PDT) Message-ID: <369e612f0610191208od1c4928vaee742e5a9ef7c5b@mail.gmail.com> Date: Fri, 20 Oct 2006 00:38:01 +0530 From: "Navin (NKA)" To: "Scott G. Kelly" In-Reply-To: <8107599.1161205261321.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <8107599.1161205261321.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On 10/19/06, Scott G. Kelly wrote: > > > >[NKA] Even if a less-robust AC implementation ends up interpreting DTLS > >message as a Discovery packet, do you think WTP (which unfortunately > >has passed discovery state) will be able to carry on with its DTLS > >session establishment and succeed ultimately? :-( I don't think so. (Imagine > >this: WTP needs to successfully interpret Discovery response as HelloVerify > >request, followed by which AC needs to interpret ClientHello (with cookie) as > >Client Hello without Cookie, and so on). > > That's not the point, and this is minor compared to the real issue, which is below. > [NKA] Scott, so you agree that the logic which I have explained for handling discovery/DTLS packets is correct, but you feel that it would result in slower synchronization between WTP and AC FSM? Fine. Lets discuss how to reduce bring-up time of a Capwap compliant WTP in general in a seperate NEW thread? It will be confusing for the WG folks to discuss the same under incorrect/inappropriate thread subject. > >Folks, > >I want to ask you this DTLS/discovery control packet question in a different > >form. Suppose by accident (or due a bug), WTP happens to be in a FSM > >state which is not same as that of AC. How would AC process the arrived > >packet from the faulty WTP? It would go by its FSM state. > > Yes, but only in the absence of better information. If it's FSM state is RUN and it receives a discovery packet, though, going by its FSM state leads to an error condition. > > > The logic for this > >is based on the fact that capwap header doesn't carry FSM state information > >and both the involved entities process packets based on the assumption > >that their FSM is in sync. Hence I conclude that discovery packets should > >not be treated in any special fashion. > > The WTP may also be in in a different FSM state because it was restarted, either due to a crash, power failure, operator action, etc. - it does not (necessarily) imply some freak accident or bug. > > In this case the WTP will often need to go through discovery again before reconnecting to the AC. If the AC erroneously feeds these packets to its DTLS implementation, they will be rejected, and the WTP will get no response. This means failure recovery will not occur until the AC times out its DTLS session, and since these timeouts are frequently set as high as 30 seconds in the field, and since the WTP may exhaust its discovery timers and go into sulking state due to AC unresponsiveness, this has the potential to signficantly (and unfortunately, completely avoidably) exacerbate the outage. > > You could try to work around this by handing every packet that fails in the DTLS engine to some other code to see if it's a discovery packet, but in doing so you're adding complexity, and compounding the amount of per-packet work an adversary can make an AC do. > > >Having extra fields in the header or usage of seperate UDP ports will definitely > >ease up the situation here, but we, at IETF, are here to define a specification > >which is optimum in nature. > > Umm... you lost me. I don't see how adding non-determism to save a port (or a few header bytes) results in an optimal solution. > > Thanks, > > Scott > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 15:27:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadYO-0003Ga-C0 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 15:27:44 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadYM-0004df-T8 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 15:27:44 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8D7DC398024 for ; Thu, 19 Oct 2006 12:27:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id EE5024A43C6 for ; Thu, 19 Oct 2006 12:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C6421144801E for ; Thu, 19 Oct 2006 12:27:32 -0700 (PDT) Received: from mcfeely.cs.umd.edu (mcfeely.cs.umd.edu [128.8.128.218]) by hermes.tigertech.net (Postfix) with ESMTP id 59234144800D for ; Thu, 19 Oct 2006 12:27:29 -0700 (PDT) Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9JJRSbl020976; Thu, 19 Oct 2006 15:27:28 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9JJRSBh020974; Thu, 19 Oct 2006 15:27:28 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Thu, 19 Oct 2006 15:27:28 -0400 (EDT) Message-ID: <61362.63.239.69.1.1161286048.squirrel@webmail.cs.umd.edu> In-Reply-To: <20061019030330.10255.qmail@web60312.mail.yahoo.com> References: <20061019030330.10255.qmail@web60312.mail.yahoo.com> Date: Thu, 19 Oct 2006 15:27:28 -0400 (EDT) From: "Charles Clancy" To: "Behcet Sarikaya" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Behcet, > My proposal is to use the key distribution protocol of 802.11r which > securely transports the keys. > Also no need for the context transfer which was what I had in mind. My point is that we don't need to distribute PMK-R1 keys since all authenticator functionality will reside at the AC regardless of the MAC splitting, so we therefore don't need a new key distribution protocol at all. Here's how I envision an 11r handoff: STA WTP1 WTP2 AC -------------------------------------------------- Initial authentication (as CAPWAP does now): <--- assoc -----> <-------------- open authentication -------------> <----------------- 1X/EAP authentication --------> (derives PMK-R0, PMK-R1) <--------------- four-way handshake -------------> (derives PTK) <---------- add mobile (PTK) ----- fast handoff: (AC and STA derive new PMK-R1') <------- FT / reassoc (PMK Name, MIC, etc) ------> (derives new PTK') <- add mobile (PTK') <---------- delete mobile -------- > Can you spare your ideas why that would not work in CAPWAP? I'm not sure to what you're referring. Using the yet-to-be-defined 11r key distribution protocol duplicates the add-mobile CAPWAP architecture for distributing keying material. Additionally, it violates the security restriction that keys from the PMK-level in the keying hierarchy MUST remain at the authenticator, which is the AC. > You're saying we only need the split MAC scenarios that I have in the > draft. I'm saying that CAPWAP can support 11r without any protocol changes. The only changes I can envision being necessary are perhaps capabilities flags indicating support for 11r, so ACs and WTPs know that each other supports 11r. All the 11r protocol processing would be implemented at the AC. The WTP would just have to know about the additional 802.11 messages, and know they should be forwarded to the AC. WTPs and ACs would also have to support AES-CMAC, which is defined in 11r. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 17:43:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaffI-0008Nq-P0 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 17:43:00 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaffF-0008U3-SW for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 17:43:00 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id E670E398090 for ; Thu, 19 Oct 2006 14:42:56 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 0F68E4A43C6 for ; Thu, 19 Oct 2006 14:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8461398041 for ; Thu, 19 Oct 2006 14:42:33 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8AAD8398029 for ; Thu, 19 Oct 2006 14:42:31 -0700 (PDT) Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GafeJ-00065H-Ky; Thu, 19 Oct 2006 17:41:59 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 19 Oct 2006 17:41:54 -0400 Message-ID: <25381523.1161294114640.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Thu, 19 Oct 2006 17:41:54 -0400 (EDT) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , Abhijit Choudhury , Dorothy Stanley , Michael Montemurro Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7101924d3c2cb033e2fefd41a4295709f50350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 You know, after seeing my post on this topic yesterday, I thought maybe my sarcasm was a bit overdone, and I actually regretted that post. But now, after seeing what sort of hoops you're willing to jump through to avoid that much simpler approach at apparently any cost... well, now I'm not so sure. Sigh. Comments inline... >The AC maintains a DTLS SA table which consists of the WTP's IP address >and UDP port numbers. When the AC receives a Discovery Request on the >CAPWAP control port, it performs a lookup to determine whether the >IP/Port information matches the DTLS SA table. If the IP/Port does not >match an entry in the DTLS SA table, the AC responds with a Discovery >response and waits for a successful DTLS setup, which would create a new >DTLS SA. If there is a match, then the packet is a DTLS encrypted >payload, which is sent to the DTLS stack. The following is an example of >the packet exchange (note the ports used here are for illustration >purposes only): > >WTP AC >(WTP Picks a pseudo-random source port) >----- CAPWAP Control/Discovery Request (662, 1233) ------> ><---- CAPWAP Control/Discovery Response (1233, 662) ------ > >Using Scott's recommendation to look at the WBID, which when set to any >value other than 23 (which we will need to reserve), then we know this >packet is a discovery request, and process it accordingly. One >alternative to reserving a WBID would be to require that the Reserved >field in the CAPWAP header be set to '111', which would provide another >way to differentiate the packets. Let's stop here, because this is where it starts getting twisted. I didn't recommend this sort of hack. There are two major flaws to this approach. The first is that you assume that the DTLS header format will not change. That's probably unwise, given that it is a new protocol. This early in the game, anything after the version field is fair game, and hacking based on assumptions of immutability is (in my opinion, at least) A Bad Thing (tm). The second issue here is that you're not looking carefully at the DTLS header alignment as it currently exists. Each version change results in the first version byte being decremented. It is currently FE, and the next will be FD, then FC, and so on. Look at what this means for the WBID field (which, by the way, could *also* be changed before we've finished with capwap): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0| |VERSION| RID | HLEN | WBID |T|F|L|W|M| FLAGS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | type | protocol version | epoch +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ FEFF |1 1 1 1 1 1 1 0|1 1 1 1 1 1 1 1| +---------------+---------------+ FDFF |1 1 1 1 1 1 0 1|1 1 1 1 1 1 1 1| +---------------+---------------+ FCFF |1 1 1 1 1 1 0 0|1 1 1 1 1 1 1 1| +---------------+---------------+ FBFF |1 1 1 1 1 0 1 1|1 1 1 1 1 1 1 1| +---------------+---------------+ FAFF |1 1 1 1 1 0 1 0|1 1 1 1 1 1 1 1| +---------------+---------------+ Since there are two WBID bits affected, your scheme requires that there be at least 4 untouchable WBID values (assuming we don't change the capwap header): 7, 15, 23, and 31. This is starting to sound more than a little bit hacky, and certainly not something you want to implement in hardware. I won't go line by line on the stuff below, as this is more than I can ask people to bear. I have only two points to make here: 1) regarding the comment below where you say "Furthermore, I trust an authenticated payload much more than a bit 'in the clear'", I'm wondering: why are unauthenticated values in the UDP and IP headers more trustworthy than values following them? Think about it. 2) look at the signalling complexity you are adding! And all this to avoid ...what, exactly? Scott > >--------- DTLS Session Setup/Control (662, 1233) --------> ><-------- DTLS Session Setup/Control (1233, 662) --------- > >The WBID value of 23 will be an indication that the DTLS session is >being established (or the alternative proposed above)... at this point >all packets are from now on fed into the DTLS engine. Once the DTLS >session is established, all CAPWAP packets will be marked internally as >'Application Data', and once decrypted will be sent back into the CAPWAP >module for processing... > >-------- CAPWAP Control/Join Request (662, 1233) ---------> (includes >support for DTLS/Data) ><------- CAPWAP Control/Join Response (1233, 662) --------- (Dictates >whether DTLS is to be used on data plane, and a random cookie) > >When inactivity occurs over the control plane, the keepalive is sent to >keep the session alive (also useful for NAT traversal): > >------- CAPWAP Control/Keepalive Request (662, 1233) -----> ><------ CAPWAP Control/Keepalive Response (1233, 662) ----- > >The following is optional, and occurs if DTLS needs to be used on the >data plane UDP port: > >----------- DTLS Session Setup/Data (685, 1234) ----------> ><---------- DTLS Session Setup/Data (1234, 685) ----------- > >Again, the WBID of 23 is used to identify the DTLS packet. When used and >established, all CAPWAP data packets will be marked as 'Application >Data' within DTLS. So these packets would pop back out of the DTLS stack >for CAPWAP processing. Yes, this requires that the data plane remember >the configuration enforced by the AC, and therefore it does not mark >each packet as "with DTLS" or "without DTLS". We can do this, but >frankly it provides little value because ultimately, if DTLS was >required and a packet is sent in the clear, it will be dropped anyhow. >Furthermore, I trust an authenticated payload much more than a bit "in >the clear". > >A specialized packet is then sent on the data plane to create the >correlation between the control and data plane sessions. A new bit in >the CAPWAP header, which I will call 'D' (for Data Management) is set so >this gets treated as a specialized packet on the data plane UDP port: > >---------- CAPWAP Data/Announce Req (685, 1234) ----------> (Including >the cookie to bind to control channel) ><--------- CAPWAP Data/Announce resp (1234, 685) ---------- > >NOTE: Another alternative to this scheme is to include a session >identifier in the header, which provides the correlation between the >control and data channel. This would be much simpler to implement, and >not require special processing of the data plane. However, if folks >believe that keeping the NAT session fresh, then we need some mechanism >to keep the channel alive. If this is found to be desirable/required, >then a periodic exchange needs to occur to keep the NAT table entry >fresh (again, with the 'D' bit set): > >------- CAPWAP Data/Keepalive Request (685, 1234) --------> ><------ CAPWAP Data/Keepalive Response (1234, 685) -------- > >Should the WTP fail, it would pick a new source UDP port for both the >control and data plane, and send a Discovery Request using the control >UDP port. It is important to note that the longevity of the uniqueness >characteristics of the UDP port is not very long (e.g., one day after >reboot). This is a new requirement on the WTP, but not unrealistic since >802.11 APs have to do this for the RADIUS protocol today (to maintain >unique session identifiers). The AC does not flush its current DTLS SA >until the DTLS exchange is complete (and successful). > >WTP AC >(WTP picks a new pseudo-random source port) >----- CAPWAP Control/Discovery Request (772, 1233) ------> ><---- CAPWAP Control/Discovery Response (1233, 772) ------ > >Using Scott's recommendation to look at the WBID, which when set to any >value other than 23 (which we will need to reserve), then we know this >packet is a discovery request, and process it accordingly. > >--------- DTLS Session Setup/Control (772, 1233) --------> ><-------- DTLS Session Setup/Control (1233, 772) --------- > >The WBID value of 23 will be an indication that the DTLS session is >being established... at this point all packets are from now on fed into >the DTLS engine. > >If NAT is used, it is possible that the WTP's source IP address is used >for multiple WTPs. In this case, the AC can identify each WTP using the >DTLS credentials. The AC can then delete the old DTLS SAs (control and >optionally data), that are associated with the WTP's credentials. >Alternatively, the AC could simply wait for the sessions to expire. > > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > > >________________________________ > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Tuesday, October 17, 2006 10:08 AM > To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro > Cc: capwap@frascone.com > Subject: need clarification on UDP ports > > > Pat, Mike, Dorothy: > > I have a question based on v03 of the capwap spec. > In section 3.1, the spec mentions well-known UDP > ports for the CAPWAP control and data packets. > > There are four kinds of CAPWAP packets: > 1. DTLS protected control packets > 2. Unprotected control packets > 3. Unprotected data packets > 4. (Optional) DTLS protected data packets > > Will there be 4 well-known UDP port numbers ? > > 1, 2 and 3 will be present simultaneously in any > deployment. 3 and 4 may co-exist in a deployment > if some data channels are encrypted and some not. > There has to be a way to distinguish these four > kinds of packets. The draft is not clear about how > this is done. > > Thanks, > Abhijit > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 18:12:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gag7a-0004Xv-9h for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 18:12:14 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gag7V-0003ty-Ro for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 18:12:14 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 5BE05144802C for ; Thu, 19 Oct 2006 15:12:06 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 43A094A45A9 for ; Thu, 19 Oct 2006 15:11:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 29B44398053 for ; Thu, 19 Oct 2006 15:11:52 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 66BBE398044 for ; Thu, 19 Oct 2006 15:11:49 -0700 (PDT) Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gag6q-0004gj-KU; Thu, 19 Oct 2006 18:11:28 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 19 Oct 2006 18:11:23 -0400 Message-ID: <8965479.1161295883589.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Thu, 19 Oct 2006 18:11:23 -0400 (EDT) From: "Scott G. Kelly" To: "Navin (NKA)" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71020ff6ec9140837d7e4392ab433e7e469350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >[NKA] Scott, so you agree that the logic which I have explained for handling >discovery/DTLS packets is correct, but you feel that it would result in slower >synchronization between WTP and AC FSM? Actually, no, I don't agree. A discovery packet should be deterministically treated as a discovery packet - not sometimes erroneously treated as a dtls packet. I think introducing this ambiguity is unnecessary, to say the least. I think Abhijit's point is correct: it should be very clear whether a packet is control, data, discovery, and protected vs unprotected. Either we can do that by using more ports, or we can find another way. But I don't think shoving a discovery packet into the dtls engine is "a good thing". Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 20:04:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahsU-0007lt-BE for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 20:04:46 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GahsO-0005yD-G3 for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 20:04:46 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 089CB1448057 for ; Thu, 19 Oct 2006 17:04:32 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id D60714A45AC for ; Thu, 19 Oct 2006 17:02:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B41411448004 for ; Thu, 19 Oct 2006 17:02:48 -0700 (PDT) Received: from web60324.mail.yahoo.com (web60324.mail.yahoo.com [209.73.178.132]) by hermes.tigertech.net (Postfix) with SMTP id 2FF441448025 for ; Thu, 19 Oct 2006 17:02:46 -0700 (PDT) Received: (qmail 51545 invoked by uid 60001); 20 Oct 2006 00:02:45 -0000 Message-ID: <20061020000245.51543.qmail@web60324.mail.yahoo.com> Received: from [121.133.79.100] by web60324.mail.yahoo.com via HTTP; Thu, 19 Oct 2006 17:02:45 PDT Date: Thu, 19 Oct 2006 17:02:45 -0700 (PDT) From: Behcet Sarikaya To: "Pat Calhoun (pacalhou)" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE X-Spam-Level: ** Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0091263836==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 --===============0091263836== Content-Type: multipart/alternative; boundary="0-1669331040-1161302565=:48025" --0-1669331040-1161302565=:48025 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Hi Pat and Charles,=0A =0ASection 8.5A.6 in 802.11r D3 describes the key d= istribution protocol. It is true that earlier versions like D2.2 did not ha= ve it.=0ASo my Local MAC scenarios were based on this protocol.=0A The key= distribution protocol makes it unnecessary to use the context transfer ahe= ad of time and it is quite nice to generate and transfer the key in a just-= in-time manner. I thought it was good and used it in CAPWAPRP.=0A=0A Regar= ds,=0A=0ABehcet =0A=0A----- Original Message ----=0AFrom: Pat Calhoun (paca= lhou) =0ATo: sarikaya@ieee.org; capwap =0ASent: Thursday, October 19, 2006 11:31:51 AM=0ASubject: Re: [Capwap= ] CAPWAP for 802.11r=0A=0ABehcet,=0A=0AThe architecture laid out in your sp= ecification seems to conflict with=0Athe CAPWAP architecture. =0A=0AA coupl= e of specific concerns before I get into the meat of the=0Adocument:=0A=0A = > We use [802.11r] key distribution protocol for transfering key=0Acontex= t=0A > for Local MAC WTPs.=0A=0AThe latest 802.11r draft does not define = a key distribution protocol to=0Amove key context across WTPs (or APs). So = I am not sure what we are=0Arefering to.=0A=0A > AC next generates PMK-R1= for R1 key holder (R1KH), i.e. the WTP.=0AAC=0A > is now in a position t= o transfer PMK-R1 context and associated=0A > authorization to the WTP. = R1KH and STA perform a 4-way handshake=0Aand=0A > generate the session ke= y, PTK.=0A=0AThe CAPWAP protocol does not assume that the PMK is ever trans= ferred=0Adown into the WTP. Furthermore, the protocol assumes the authentic= ator=0Aresides in the AC - not the WTP. So this statement seems to change t= he=0Afundamental architecture of the CAPWAP protocol.=0A=0AI will have many= additional questions once I read the specification=0Acompletely, but first= want to make sure that we agree on whether the=0Aspec is in scope or not (= by answering the above questions).=0A=0APat Calhoun=0ACTO, Wireless Network= ing Business Unit=0ACisco Systems=0A=0A =0A=0A> -----Original Message-----= =0A> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0A> Sent: Wed= nesday, October 18, 2006 12:43 AM=0A> To: capwap=0A> Subject: [Capwap] CAPW= AP for 802.11r=0A> =0A> Pat and all,=0A> =0A> The link:=0A> http://www.ietf= .org/internet-drafts/draft-sarikaya-capwap-fast=0A> bss-00.txt=0A> is now o= n.=0A> =0A> Regards,=0A> =0A> --behcet=0A> =0A> ----- Original Message ----= =0A> From: Pat Calhoun (pacalhou) =0A> To: Behcet Sarik= aya =0A> Sent: Monday, October 16, 2006 7:01:11 P= M=0A> Subject: RE: [Capwap] CAPWAP for 802.11r=0A> =0A> ok, I will once it = becomes available.=0A> =0A> =0A> Pat Calhoun=0A> CTO, Wireless Networking = Business Unit=0A> Cisco Systems=0A> =0A> =0A> =0A> =0A> --------------= ------------------------------------------------=0A> ----------=0A> *Fr= om:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=0A> *Sent:* Mond= ay, October 16, 2006 4:41 PM=0A> *To:* Pat Calhoun (pacalhou); capwap@f= rascone.com=0A> *Subject:* Re: [Capwap] CAPWAP for 802.11r=0A> =0A> = Pat,=0A> =0A> =0A> ----- Original Message ----=0A> From: Pat Calho= un (pacalhou) =0A> To: Behcet Sarikaya ; =0A> capwap@frascone.com=0A> Sent: Monday, October 16, = 2006 1:02:43 PM=0A> Subject: RE: [Capwap] CAPWAP for 802.11r=0A> =0A> = Behcet,=0A> =0A> I believe we've discussed this idea a few time= s, and I am still=0A> unsure why we believe CAPWAP needs to define anyt= hing to support=0A> TGr. The current CAPWAP protocol is sufficient to s= upport the=0A> upcoming standard.=0A> =0A> =3D=3D>=0A> The basi= s is there but we need several extensions.=0A> Please read the draft an= d comment, then we can make a =0A> more informed=0A> decision, I think.= =0A> =0A> =0A> Pat Calhoun=0A> CTO, Wireless Networking Business Un= it=0A> Cisco Systems=0A> =0A> =0A> Regards,=0A> =0A> --beh= cet=0A> =0A> =0A> -------------------------------------------------= -------------=0A> ----------=0A> *From:* Behcet Sarikaya [mailto:be= hcetsarikaya@yahoo.com]=0A> *Sent:* Saturday, October 14, 2006 8:33= AM=0A> *To:* capwap@frascone.com=0A> *Subject:* [Capwap] C= APWAP for 802.11r=0A> =0A> Dear all,=0A> I submitted a dr= aft on CAPWAP Roaming Protocol in =0A> 802.11R Domains.=0A> It shou= ld be available soon at the following link:=0A> =0A> =0A> http://ww= w.ietf.org/internet-drafts/draft-sarikaya-capwap-fast=0A> bss-00.txt=0A> = =0A> Regards,=0A> =0A> Behcet=0A> =0A> ____________________= _____________________________________________=0A> To unsubscribe or modify = your subscription options, please visit:=0A> http://lists.frascone.com/mail= man/listinfo/capwap=0A> =0A> Archives: http://lists.frascone.com/pipermail/= capwap=0A> =0A_____________________________________________________________= ____=0ATo unsubscribe or modify your subscription options, please visit:=0A= http://lists.frascone.com/mailman/listinfo/capwap=0A=0AArchives: http://lis= ts.frascone.com/pipermail/capwap=0A=0A=0A=0A=0A --0-1669331040-1161302565=:48025 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Hi Pat and Charles,
 
Section 8.5A.6 in 8= 02.11r D3 describes the key distribution protocol. It is true that earlier = versions like D2.2 did not have it.
So my Local MAC scenarios were based= on this protocol.
  The key distribution protocol makes it unneces= sary to use the context transfer ahead of time and it is quite nice to gene= rate and transfer the key in a just-in-time manner. I thought it was good a= nd used it in CAPWAPRP.

  Regards,

Behcet

http://= www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast
> bss-00.= txt
> is now on.
>
> Regards,
>
> --behcet
>
> -= ---- Original Message ----
> From: Pat Calhoun (pacalhou) <pcalhou= n@cisco.com>
> To: Behcet Sarikaya <behcetsarikaya@yahoo.com>= ;
> Sent: Monday, October 16, 2006 7:01:11 PM
> Subject: RE: [C= apwap] CAPWAP for 802.11r
>
> ok, I will once it becomes avail= able.
>  
>
> Pat Calhoun
> CTO, Wireles= s Networking Business Unit
> Cisco Systems
>
> &nbs= p;
>
>    
> ----------------------= ----------------------------------------
> ----------
> &n= bsp;   *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]<= br>>     *Sent:* Monday, October 16, 2006 4:41 PM>     *To:* Pat Calhoun (pacalhou); capwap@frascone= .com
>     *Subject:* Re: [Capwap] CAPWAP for 802= .11r
>
>     Pat,
>
>
>  = ;   ----- Original Message ----
>     F= rom: Pat Calhoun (pacalhou) <pcalhoun@cisco.com>
>  &= nbsp;  To: Behcet Sarikaya <behcetsarikaya@yahoo.com>;
> = capwap@frascone.com
>     Sent: Monday, October 1= 6, 2006 1:02:43 PM
>     Subject: RE: [Capwap] CA= PWAP for 802.11r
>
>     Behcet,
>&n= bsp;     
>     I believ= e we've discussed this idea a few times, and I am still
>  =    unsure why we believe CAPWAP needs to define anything to suppo= rt
>     TGr. The current CAPWAP protocol is suff= icient to support the
>     upcoming standard.>
>     =3D=3D>
>   =   The basis is there but we need several extensions.
>     P= lease read the draft and comment, then we can make a
> more informed=
>     decision, I think.
>
>
&g= t;     Pat Calhoun
>     CTO,= Wireless Networking Business Unit
>     Cisco Sy= stems
>
>      
> &nb= sp;   Regards,
>
>     --behcet<= br>>
>        
> -= -------------------------------------------------------------
> -----= -----
>         *From:* Behce= t Sarikaya [mailto:behcetsarikaya@yahoo.com]
>    = ;     *Sent:* Saturday, October 14, 2006 8:33 AM
>= ;         *To:* capwap@frascone.com
>        = ; *Subject:* [Capwap] CAPWAP for 802.11r
>
>   =       Dear all,
>    &nb= sp;      I submitted a draft on CAPWAP Roaming Pro= tocol in
> 802.11R Domains.
>     &nb= sp;   It should be available soon at the following link:
> =
>        
> http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast=
> bss-00.txt
>
>      &nb= sp;  Regards,
>
>      &nbs= p;  Behcet
>
> __________________________________________= _______________________
> To unsubscribe or modify your subscription = options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap<= br>>
> Archives: http://lists.frascone.com/pipermail/capwap
= >
_________________________________________________________________<= br>To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http= ://lists.frascone.com/pipermail/capwap

<= /body> --0-1669331040-1161302565=:48025-- --===============0091263836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0091263836==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 22:24:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gak3u-00075u-8T for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 22:24:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gak3p-0000TM-Cy for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 22:24:42 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 8B02C144806B for ; Thu, 19 Oct 2006 19:24:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id E59EF4A45AC for ; Thu, 19 Oct 2006 19:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C7372398011 for ; Thu, 19 Oct 2006 19:24:02 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 824B0398037 for ; Thu, 19 Oct 2006 19:23:58 -0700 (PDT) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 19 Oct 2006 19:23:50 -0700 X-Server-Uuid: 450F6D01-B290-425C-84F8-E170B39A25C9 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 931D42AF; Thu, 19 Oct 2006 19:23:50 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6BAED2AE; Thu, 19 Oct 2006 19:23:50 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIF70677; Thu, 19 Oct 2006 19:23:49 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6683920502; Thu, 19 Oct 2006 19:23:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 19:23:40 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41020A2F15@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <25381523.1161294114640.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acbzx6gzRnIyqDJeSh2XVUA2VdetaQAIMftA From: "Puneet Agarwal" To: "Scott G. Kelly" , "Pat Calhoun (pacalhou)" , "Abhijit Choudhury" , "Dorothy Stanley" , "Michael Montemurro" X-WSS-ID: 6926ECBC2A0535867-01-01 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 I agree with Scott - it is important that we come up with a solution that is unambiguous and works even if packet formats for dtls change. It seems that we (capwap) are one of the first folks trying to use DTLS. It would be good to know how other folks (if any) have used DTLS for their applications. If someone has already solved the "discovery to dtls-secure" like problem before, then it would be good to understand how they did it and maybe use a similar approach (rather than re-invent the wheel). In that regard, does anyone know of other groups using dtls to secure their protocol? Would having 3 UDP ports solve the problem: (a) capwap-open control port : All unencrypted capwap control packets go on this channel (b) capwap-open data port : All unencrypted capwap data packets go on this channel (b) capwap-secure port: All dtls encrypted capwap data/control packets go on this channel. Demux for data vs control happens after decryption. We may need more ports if we need to support different QoS levels (as pointed by Scott)- that to me is a bigger problem. Wondering what the group thinks.... Thanks. -Puneet -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, October 19, 2006 2:42 PM To: Pat Calhoun (pacalhou); Abhijit Choudhury; Dorothy Stanley; Michael Montemurro Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports You know, after seeing my post on this topic yesterday, I thought maybe my sarcasm was a bit overdone, and I actually regretted that post. But now, after seeing what sort of hoops you're willing to jump through to avoid that much simpler approach at apparently any cost... well, now I'm not so sure. Sigh. Comments inline... >The AC maintains a DTLS SA table which consists of the WTP's IP address >and UDP port numbers. When the AC receives a Discovery Request on the >CAPWAP control port, it performs a lookup to determine whether the >IP/Port information matches the DTLS SA table. If the IP/Port does not >match an entry in the DTLS SA table, the AC responds with a Discovery >response and waits for a successful DTLS setup, which would create a >new DTLS SA. If there is a match, then the packet is a DTLS encrypted >payload, which is sent to the DTLS stack. The following is an example >of the packet exchange (note the ports used here are for illustration >purposes only): > >WTP AC >(WTP Picks a pseudo-random source port) >----- CAPWAP Control/Discovery Request (662, 1233) ------> ><---- CAPWAP Control/Discovery Response (1233, 662) ------ > >Using Scott's recommendation to look at the WBID, which when set to any >value other than 23 (which we will need to reserve), then we know this >packet is a discovery request, and process it accordingly. One >alternative to reserving a WBID would be to require that the Reserved >field in the CAPWAP header be set to '111', which would provide another >way to differentiate the packets. Let's stop here, because this is where it starts getting twisted. I didn't recommend this sort of hack. There are two major flaws to this approach. The first is that you assume that the DTLS header format will not change. That's probably unwise, given that it is a new protocol. This early in the game, anything after the version field is fair game, and hacking based on assumptions of immutability is (in my opinion, at least) A Bad Thing (tm). The second issue here is that you're not looking carefully at the DTLS header alignment as it currently exists. Each version change results in the first version byte being decremented. It is currently FE, and the next will be FD, then FC, and so on. Look at what this means for the WBID field (which, by the way, could *also* be changed before we've finished with capwap): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0| |VERSION| RID | HLEN | WBID |T|F|L|W|M| FLAGS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | type | protocol version | epoch +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ FEFF |1 1 1 1 1 1 1 0|1 1 1 1 1 1 1 1| +---------------+---------------+ FDFF |1 1 1 1 1 1 0 1|1 1 1 1 1 1 1 1| +---------------+---------------+ FCFF |1 1 1 1 1 1 0 0|1 1 1 1 1 1 1 1| +---------------+---------------+ FBFF |1 1 1 1 1 0 1 1|1 1 1 1 1 1 1 1| +---------------+---------------+ FAFF |1 1 1 1 1 0 1 0|1 1 1 1 1 1 1 1| +---------------+---------------+ Since there are two WBID bits affected, your scheme requires that there be at least 4 untouchable WBID values (assuming we don't change the capwap header): 7, 15, 23, and 31. This is starting to sound more than a little bit hacky, and certainly not something you want to implement in hardware. I won't go line by line on the stuff below, as this is more than I can ask people to bear. I have only two points to make here: 1) regarding the comment below where you say "Furthermore, I trust an authenticated payload much more than a bit 'in the clear'", I'm wondering: why are unauthenticated values in the UDP and IP headers more trustworthy than values following them? Think about it. 2) look at the signalling complexity you are adding! And all this to avoid ...what, exactly? Scott > >--------- DTLS Session Setup/Control (662, 1233) --------> ><-------- DTLS Session Setup/Control (1233, 662) --------- > >The WBID value of 23 will be an indication that the DTLS session is >being established (or the alternative proposed above)... at this point >all packets are from now on fed into the DTLS engine. Once the DTLS >session is established, all CAPWAP packets will be marked internally as >'Application Data', and once decrypted will be sent back into the >CAPWAP module for processing... > >-------- CAPWAP Control/Join Request (662, 1233) ---------> (includes >support for DTLS/Data) ><------- CAPWAP Control/Join Response (1233, 662) --------- (Dictates >whether DTLS is to be used on data plane, and a random cookie) > >When inactivity occurs over the control plane, the keepalive is sent to >keep the session alive (also useful for NAT traversal): > >------- CAPWAP Control/Keepalive Request (662, 1233) -----> ><------ CAPWAP Control/Keepalive Response (1233, 662) ----- > >The following is optional, and occurs if DTLS needs to be used on the >data plane UDP port: > >----------- DTLS Session Setup/Data (685, 1234) ----------> ><---------- DTLS Session Setup/Data (1234, 685) ----------- > >Again, the WBID of 23 is used to identify the DTLS packet. When used >and established, all CAPWAP data packets will be marked as 'Application >Data' within DTLS. So these packets would pop back out of the DTLS >stack for CAPWAP processing. Yes, this requires that the data plane >remember the configuration enforced by the AC, and therefore it does >not mark each packet as "with DTLS" or "without DTLS". We can do this, >but frankly it provides little value because ultimately, if DTLS was >required and a packet is sent in the clear, it will be dropped anyhow. >Furthermore, I trust an authenticated payload much more than a bit "in >the clear". > >A specialized packet is then sent on the data plane to create the >correlation between the control and data plane sessions. A new bit in >the CAPWAP header, which I will call 'D' (for Data Management) is set >so this gets treated as a specialized packet on the data plane UDP port: > >---------- CAPWAP Data/Announce Req (685, 1234) ----------> (Including >the cookie to bind to control channel) ><--------- CAPWAP Data/Announce resp (1234, 685) ---------- > >NOTE: Another alternative to this scheme is to include a session >identifier in the header, which provides the correlation between the >control and data channel. This would be much simpler to implement, and >not require special processing of the data plane. However, if folks >believe that keeping the NAT session fresh, then we need some mechanism >to keep the channel alive. If this is found to be desirable/required, >then a periodic exchange needs to occur to keep the NAT table entry >fresh (again, with the 'D' bit set): > >------- CAPWAP Data/Keepalive Request (685, 1234) --------> ><------ CAPWAP Data/Keepalive Response (1234, 685) -------- > >Should the WTP fail, it would pick a new source UDP port for both the >control and data plane, and send a Discovery Request using the control >UDP port. It is important to note that the longevity of the uniqueness >characteristics of the UDP port is not very long (e.g., one day after >reboot). This is a new requirement on the WTP, but not unrealistic >since >802.11 APs have to do this for the RADIUS protocol today (to maintain >unique session identifiers). The AC does not flush its current DTLS SA >until the DTLS exchange is complete (and successful). > >WTP AC >(WTP picks a new pseudo-random source port) >----- CAPWAP Control/Discovery Request (772, 1233) ------> ><---- CAPWAP Control/Discovery Response (1233, 772) ------ > >Using Scott's recommendation to look at the WBID, which when set to any >value other than 23 (which we will need to reserve), then we know this >packet is a discovery request, and process it accordingly. > >--------- DTLS Session Setup/Control (772, 1233) --------> ><-------- DTLS Session Setup/Control (1233, 772) --------- > >The WBID value of 23 will be an indication that the DTLS session is >being established... at this point all packets are from now on fed into >the DTLS engine. > >If NAT is used, it is possible that the WTP's source IP address is used >for multiple WTPs. In this case, the AC can identify each WTP using the >DTLS credentials. The AC can then delete the old DTLS SAs (control and >optionally data), that are associated with the WTP's credentials. >Alternatively, the AC could simply wait for the sessions to expire. > > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems > > > > >________________________________ > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Tuesday, October 17, 2006 10:08 AM > To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro > Cc: capwap@frascone.com > Subject: need clarification on UDP ports > > > Pat, Mike, Dorothy: > > I have a question based on v03 of the capwap spec. > In section 3.1, the spec mentions well-known UDP > ports for the CAPWAP control and data packets. > > There are four kinds of CAPWAP packets: > 1. DTLS protected control packets > 2. Unprotected control packets > 3. Unprotected data packets > 4. (Optional) DTLS protected data packets > > Will there be 4 well-known UDP port numbers ? > > 1, 2 and 3 will be present simultaneously in any > deployment. 3 and 4 may co-exist in a deployment > if some data channels are encrypted and some not. > There has to be a way to distinguish these four > kinds of packets. The draft is not clear about how > this is done. > > Thanks, > Abhijit > > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 19 22:34:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GakDI-0002iB-3g for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 22:34:24 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GakDG-0004wV-9G for capwap-archive@lists.ietf.org; Thu, 19 Oct 2006 22:34:24 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id CC10F1448031 for ; Thu, 19 Oct 2006 19:34:18 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id A7BA44A45AC for ; Thu, 19 Oct 2006 19:33:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 817611448031 for ; Thu, 19 Oct 2006 19:33:53 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 2C9B8144802F for ; Thu, 19 Oct 2006 19:33:51 -0700 (PDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/jazz) with ESMTP id k9K2Xmho018626; Fri, 20 Oct 2006 11:33:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k9K2Xnb16285; Fri, 20 Oct 2006 11:33:49 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k9K2XlF01457; Fri, 20 Oct 2006 11:33:47 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Oct 2006 10:32:35 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD013E3728@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Issue 43 - Explanation for 802.11i Considerations Thread-Index: Acbu8s465akdTlO6RPehFnWHhbI5OAE/JCpw From: "Cheng Hong" To: "Scott Kelly" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-Spam-Level: Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Hi Scott and all, That is an excellent summary of the issue. Would suggest including the whole analysis into the Security Consideration of the CAPWAP spec regardless which final approach the group decides to take (since this issue is specific to/introduced by CAPWAP architecture). cheers Cheng Hong > -----Original Message----- > From: Scott Kelly [mailto:skelly@arubanetworks.com] > Sent: Saturday, October 14, 2006 2:10 AM > To: capwap@frascone.com > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i > Considerations > > Hi All, > > Charles and I have been discussing the keyrsc issue, and > we're in agreement on an opinion of the overall security > implications. > > To summarize briefly, there are small exposures in either > case which are both pretty trivial. The small replay exposure > is probably the more acceptable of the two, given the > complexity level of the proposed 'fix'. > The added complexity of passing the KCK to the WTP together > with the slight associated exposure tips the scale slightly > more toward the "just choose a keyrsc value that will work > (zero or a better one if you know it)" solution. > > If you want the background considerations, a more detailed > discussion follows. Otherwise, there you have it. > > -------------------------------------------------------------- > ---------- > ---- > 1. Setting KeyRSC = 0 > > In the current CAPWAP protocol, the 4-way handshake occurs > between the AC and the STA, and once this is complete, the AC > pushes the 802.11 cryptographic key material (the PTK) to the > WTP. In cases where a GTK (the group transient key, which is > used to cryptographically protect broadcast/multicast > traffic) is already active for the ESSID the STA is > associating to, the GTK is identified in message 3 of the > 4-way handshake, along with the current receive sequence > counter (KeyRSC) for messages protected under that key. Since > the WTP maintains the active KeyRSC, the AC currently has no > way to know precisely what the correct value is at the point > at which message 3 is constructed. To work around this, LWAPP > designers chose to have the AC simply set this value to 0. > > This decision does not affect the WTP, who maintains this > counter; it only affects the STA. Hence, there is no > interoperability implication to this behavior. The STA, upon > receiving the first valid broadcast/multicast message from > the WTP, will update its RSC to the correct value, and will > be synchronized with the WTP's value from then on. > > The security consequences of this approach are as follows: > > - the period beginning when the STA installs the GTK and > KeyRSC and ending when the STA receives the first valid > bcast/mcast message from the WTP represents a window of > opportuntity for an attacker > > - the window has two dimensions: the time it remains open, > and the relative width, which is measured in terms of the > difference between the current valid KeyRSC value and 0 (i.e. > the magnitude of the current > KeyRSC) > > - so long as this window remains open, an adversary could > replay previous valid bcast/mcast messages, and so long as > those messages are replayed in monotonically increasing order > with respect to the RSC value, the STA would accept these > messages as valid. The higher the current KeyRSC, the more > messages an adversary could potentially replay, assuming no > valid bcast/mcast messages were sent by the WTP (i.e. the > window remained open). > > 1.1 Mitigating Circumstances > > - typical wireless networks with a small population of users > will see multiple broadcasts per second, so this window will > normally be open for a very short (sub-second) interval. > > - an unauthenticated (outsider) adversary would be restricted > to blindly playing back mcast/bcast traffic; while the > adverary could make some inferences with respect to the > encrypted traffic type based on traffic analysis techniques, > the adversary could not be certain of what message content he > was replaying. > > - an authenticated adversary would be capable of selectively > playing back mcast/bcast messages whose content is known, but > that same adversary could generate the same (or similar) > messages in real-time even after the STA's KeyRSC is updated. > That is, there is little benefit in replaying existing > messages rather than simply constructing new ones. > > - if there are mcast/bcast message streams suitable for > launching an attack, in order to know that such an attack is > present in the recorded stream, the attacker would with high > probablility need to be an insider > - in which case replay capability is not a necessary > condition for launching the attack. > > 1.2 Conclusions > > Setting the KeyRSC to 0 opens a small window of opportunity > during which previously transmitted mcast/bcast traffic could > be replayed. While this could have operational implications > (e.g. the STA might instantiate stale ARP entries, receive > stale NetBIOS packets to which it may respond, or receive > other invalid information that somehow 'contaminates' its > view of the network), we believe the impact would be both > detectable and quite small in a reasonably robust STA. > > Also, the primary threat introduced pertains to an outsider > blindly playing back recorded data, as an insider would have > knowledge of the group key, and so rather than wasting time > collecting packets off the air and attempting to replay them > within a window of opportunity of indefinite size, the > adversary would be better advised to simply generate the > spurious packets. That is, an insider adversary has better > tools at his disposal than this window of opportunity provides. > > While it is certainly prudent to narrow the window as much as > is practicable, this must be weighed carefully against the > complexity of the solution vs the minimal threat level this > represents. > > > 2. WTP puts current KeyRSC into message 3 > > One proposed solution the problem of the AC not knowing the > current KeyRSC entails having the WTP insert the correct > value in message 3 of the 4-way handshake. This requires the > WTP to know the Key Confirmation Key (KCK) in order to > compute the MIC on the message. Currently, this value is only > known to the AC and STA. > > The security considerations for this approach are as follows: > > - currently, the WTP has no knowledge of the KCK; having this > value would provide the WTP with the ability to modify the > RSN Information Element (IE) containing the supported > cryptographic algorithms advertised by the AC during the > association process. This IE is included in this message > explicitly because the MIC computation provides a secure > mechanism for validating the value used during association > against this authenticated value. That mechanism would now be > open to subversion, and in particular, the WTP would have the > ability to downgrade the cryptographic algorithms the AC is > advertising without the ACs knowledge. > > 2.1 Mitigating Circumstances > > - an evil WTP would also have access to the PTK once the > 4-way handshake completes. Almost anything that could be > accomplished via a downgrade attack could also be > accomplished by passing off the PTK to a collaborator. > > - the downgraded RSN IE's used during association could be > detected using sniffers > > - that fact that STAs are associating with downgraded > capabilities could be detected via log inspection > > 2.2 Conclusions > > The minimal exposure introduced by communicating the KCK to > the WTP does not represent a signficant threat due to the > fact that the WTP also possesses the PTK. This implies that > appropriate measures are already in place to ensure the > trustworthiness of the WTP. While one could dream up > scenarios in which a collaborating evil STA took advantage of > the downgraded cryptographic algorithms to somehow attack an > unsuspecting STA, there are plenty of ways in which the evil > WTP could communicate the PTK to the evil STA, so possession > of the KCK adds little adversarial capability. > > > 3. Recommendations > > Security analysis is often very subtle, and there is > certainly some art involved. This appears to be one of those > difficult cases in which some art will be required. Both > approaches to this problem entail vulnerabilities. The > question is, do these represent real-world threats from a > practical standpoint? > > In terms of the small window of opportunity opened by setting > KeyRSC=0, it is difficult to imagine how this could be > leveraged by an outsider adversary, especially given that the > window size will be sub-second on typical networks. And it's > even more of a stretch to imagine an insider (who has access > to the GTK and the ability to send legitimate bcast/mcast > frames) choosing this avenue for an attack. > > Odds seem very much in our favor that nothing bad will happen > if we leave this small window open, and after reviewing this > briefly, Russ Housley agrees. > > In terms of the potential downgrade vulnerability introduced > by giving the KCK to a subverted WTP, it seems clear that > there most likely would be bigger worries there. It's not > totally impossible to cook up an attack scenario, but there > are almost certainly simpler avenues of attack. > > Still, on a practical level, pushing the KCK to the WTP adds > complexity. > The KCK would have to be delivered to the WTP somehow (and in > an acknowledged CAPWAP control message, while the 4-way > handshake is carried in the data channel). This would add > latency to the association process (already a problem as it > is, and this would only make it worse). > > Both approaches have what appear to be minor security > implications, yet neither approach invites any obvious > attack. It is entirely possible that there is no practical > way to exploit the weaknesses exposed in either case, but it > is also at least slightly possible that some subtle set of > circumstances might lead to an exploit in one case or the > other - we simply cannot be certain. > > Taking these things into consideration, it seems like a good > operational compromise to assume the limited risk associated > with the minimally open replay window, while providing > appropriate security recommendations to try to narrow it if > it is possible to do so with minimal added complexity. > -------------------------------- > > Let us know if you have any further questions on this. > > Scott > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From akstcartistruemnsdgs@artistrue.com Fri Oct 20 09:00:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gatzd-0001sT-Bp for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 09:00:57 -0400 Received: from d039244.adsl.hansenet.de ([80.171.39.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gatza-0002Mc-Sj for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 09:00:57 -0400 Received: from 216.193.201.145 (HELO mailcluster.globat.com) by lists.ietf.org with esmtp (MV6NRF3J O70TQ6) id KMT9M4-GV279E-FA for capwap-archive@lists.ietf.org; Fri, 20 Nov 2006 13:00:01 -0060 Date: Fri, 20 Nov 2006 13:00:01 -0060 From: "Amalia Baird" X-Mailer: The Bat! (v3.62.14) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <993744558.32495702705116@thebat.net> To: capwap-archive@lists.ietf.org Subject: 27% up today MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Spam-Score: 3.2 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi Mariano, look at it its' 27% UP! I mentioned about this company yesterday known as American Unity Investments Inc (AUNI) Yay, I told you to watch it yesterday and it boomed from .7to .9! I made easy 20% just in one single day.I am amazed, did you buy some as well I hope? As you can see its climbing, but by just looking at it I can tell it's gonna explode even more.So you still have a window to digg in while it's still in it's low.So what a hey, go ahead buy some, make some money while it's there. It can easily do another 30% tomorrow.I wouldn't wait any longer if I be you... I hope it was a helper.I'll email you later this week. Patti. a common flirt than she has been here. the officers will find women better worth their notice. let us "i do assure you, sir, that i have no pretensions whatever to that kind of elegance which consists From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 10:22:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavG9-0006sV-5x for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 10:22:05 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GavG5-0007wo-BE for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 10:22:05 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 6C0A91448047 for ; Fri, 20 Oct 2006 07:21:56 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 95D024A43C6 for ; Fri, 20 Oct 2006 07:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7C4CA144801F for ; Fri, 20 Oct 2006 07:21:01 -0700 (PDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by hermes.tigertech.net (Postfix) with ESMTP id F228B1448032 for ; Fri, 20 Oct 2006 07:20:57 -0700 (PDT) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc14) with ESMTP id <2006102014205601400qretde>; Fri, 20 Oct 2006 14:20:56 +0000 Message-ID: <4538DB4C.3040605@cs.umd.edu> Date: Fri, 20 Oct 2006 10:21:00 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Behcet Sarikaya References: <20061020000245.51543.qmail@web60324.mail.yahoo.com> In-Reply-To: <20061020000245.51543.qmail@web60324.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------030908010301070905030203" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e This is a multi-part message in MIME format. --------------030908010301070905030203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Behcet, 11R D3 8.5A.6 (attached for those interested) defines the basic properties and summarizes the exchanges, but I don't see any packet formats, transport mechanism, link security mechanism, or method for establishing a trust relationship between the MDC and possible KHs. In CAPWAP, there's no AAA context to transfer, because the AAA context always resides at the AC. Using the existing mechanism for key distribution (via Add Mobile messages) is sufficient for transporting PTKs to the WTPs. -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy Behcet Sarikaya wrote: > Hi Pat and Charles, > > Section 8.5A.6 in 802.11r D3 describes the key distribution protocol. It > is true that earlier versions like D2.2 did not have it. > So my Local MAC scenarios were based on this protocol. > The key distribution protocol makes it unnecessary to use the context > transfer ahead of time and it is quite nice to generate and transfer the > key in a just-in-time manner. I thought it was good and used it in CAPWAPRP. > > Regards, > > Behcet > > ----- Original Message ---- > From: Pat Calhoun (pacalhou) > To: sarikaya@ieee.org; capwap > Sent: Thursday, October 19, 2006 11:31:51 AM > Subject: Re: [Capwap] CAPWAP for 802.11r > > Behcet, > > The architecture laid out in your specification seems to conflict with > the CAPWAP architecture. > > A couple of specific concerns before I get into the meat of the > document: > > > We use [802.11r] key distribution protocol for transfering key > context > > for Local MAC WTPs. > > The latest 802.11r draft does not define a key distribution protocol to > move key context across WTPs (or APs). So I am not sure what we are > refering to. > > > AC next generates PMK-R1 for R1 key holder (R1KH), i.e. the WTP. > AC > > is now in a position to transfer PMK-R1 context and associated > > authorization to the WTP. R1KH and STA perform a 4-way handshake > and > > generate the session key, PTK. > > The CAPWAP protocol does not assume that the PMK is ever transferred > down into the WTP. Furthermore, the protocol assumes the authenticator > resides in the AC - not the WTP. So this statement seems to change the > fundamental architecture of the CAPWAP protocol. > > I will have many additional questions once I read the specification > completely, but first want to make sure that we agree on whether the > spec is in scope or not (by answering the above questions). > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Sent: Wednesday, October 18, 2006 12:43 AM > > To: capwap > > Subject: [Capwap] CAPWAP for 802.11r > > > > Pat and all, > > > > The link: > > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast > > bss-00.txt > > is now on. > > > > Regards, > > > > --behcet > > > > ----- Original Message ---- > > From: Pat Calhoun (pacalhou) > > To: Behcet Sarikaya > > Sent: Monday, October 16, 2006 7:01:11 PM > > Subject: RE: [Capwap] CAPWAP for 802.11r > > > > ok, I will once it becomes available. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > *Sent:* Monday, October 16, 2006 4:41 PM > > *To:* Pat Calhoun (pacalhou); capwap@frascone.com > > *Subject:* Re: [Capwap] CAPWAP for 802.11r > > > > Pat, > > > > > > ----- Original Message ---- > > From: Pat Calhoun (pacalhou) > > To: Behcet Sarikaya ; > > capwap@frascone.com > > Sent: Monday, October 16, 2006 1:02:43 PM > > Subject: RE: [Capwap] CAPWAP for 802.11r > > > > Behcet, > > > > I believe we've discussed this idea a few times, and I am still > > unsure why we believe CAPWAP needs to define anything to support > > TGr. The current CAPWAP protocol is sufficient to support the > > upcoming standard. > > > > ==> > > The basis is there but we need several extensions. > > Please read the draft and comment, then we can make a > > more informed > > decision, I think. > > > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > Regards, > > > > --behcet > > > > > > -------------------------------------------------------------- > > ---------- > > *From:* Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > *Sent:* Saturday, October 14, 2006 8:33 AM > > *To:* capwap@frascone.com > > *Subject:* [Capwap] CAPWAP for 802.11r > > > > Dear all, > > I submitted a draft on CAPWAP Roaming Protocol in > > 802.11R Domains. > > It should be available soon at the following link: > > > > > > http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast > > bss-00.txt > > > > Regards, > > > > Behcet > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap --------------030908010301070905030203 Content-Type: text/plain; name="11r-D3-8.5A.6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="11r-D3-8.5A.6.txt" 8.5A.6 PMK-R1 distribution within a mobility domain The following procedures are used to distribute PMK-R1s. The STA first derives PMK-R0 keys for use in fast BSS transitions (via the FT Initial Association procedures defined in clause 8A.2) utilizing information from the target AP as defined in 8.5A.4. When the IEEE 802.1X AKM is used to establish keys, the PMK-R0 Key Holder derives the PMK-R0 key utilizing the MSK acquired through EAP based authentication. The PMK-R0 shall be stored in a component called the PMK-R0 Key Holder. Each PMK-R0 Key Holder is responsible for deriving a PMK-R1 key for key for each PMK-R1 Key Holder in the mobility domain. The PMK-R1 shall be stored in a component called the PMK-R1 Key Holder. PMK-R1 keys are distributed to PMK-R1 Key Holders by the PMK-R0 Key Holder using a secure three party protocol described herein. The Mobility Domain Controller (MDC) shall mutually authenticate and authorize all members of the mobility domain that can be Key Holders. Using the MDC all Key Holders can establish security associations with each other. The identities they use during the authentication process shall be their NAS-Id which is identical to the information included in the NASID IE in all beacons and probe responses. The Key Distribution Protocol has the following properties - Authentication of entities involved in key distribution - Confidentiality of the key distribution - Authorization of the status of a PMK-R1 holder - Validation of the authorization - Receipt of the key is acknowledged - Correctness of the authorization attributes assigned to the STA The Key Distribution Protocol is initiated by the STA by including an R1DIST Information element along with other Fast BSS Transition Information Elements in either Authentication or Action frames. The token of this element shall be the AES-KeyWrap of a sixteen (16) octet random number chosen by the STA, called Ns, concatenated with the identity of the target AP as determined by the NASID Information Element in its beacons and probe responses. The key used to perform this wrapping shall be "mk" described in section 8.5A.4. The target AP shall extract the token from the R1DIST Information Element and send it along with the MAC address of the STA to the R0KH identified in the FTIE under the protection of the security association the target AP (a Key Holder) shares with the PMK-R0 Key Holder. If the target AP does not recognize the R0KH in the FTIE or does not have a security association with it authentication fails with status 38 ("the request has not been successful as one or more parameters have invalid values"). Upon receipt of this message the R0KH looks up the PMK-R0 security association it shares with the STA based upon the MAC address in the message. It then unwraps the token using "mk" describe in section 8.5A.4. If the unwrapping fails or the R0KH does not have a PMK-R0 security association for that STA it returns a failure message to the target AP which then fails the authentication attempt with status 38. The R0KH compares the NAS-Id from the unwrapped token with the identity the target AP used during when establishing its shared security association. If the two do not match the R0KH returns a failure message to the target AP which then fails the authentication attempt with status 38. The R0KH then chooses a sixteen (16) octet random number, called Na, and constructs a message back to the target AP consisting of the STA's MAC address, Ns, Na, the PMK-R1, the PMK-R1 Name, all authorization attributes associated with PMKR0 (e.g. session lifetime), and a token representing an AES-KeyWrapping of the NAS-Id of the target AP from the shared security association and Na. The wrapping shall use "mk" described in section 8.5A.4. Upon receipt of this message the target AP shall instantiate a PMK-R1 security association and construct either an Authentication response frame or response action frame depending on the type of request received originally. This frame will include, along with other Fast BSS Transition IEs, an RT1DIST IE which shall encapsulate the token it received from the PMK-R0 Key Holder, and an R1DISTV IE which shall consist of the digest of SHA-256(Ns|Na). Upon receipt of this frame the STA shall perform the following additional validation: it shall unwrap the token in the R1DIST IE and compare the enclosed NAS-Id with the one it received from the target AP in a beacon or probe response. If they do not match the STA must treat this as an authentication failure. If they match the STA computes the digest of SHA-256(Ns|Na) using Na from the unwrapped token and compares it to the value in the R1DISTV IE. If they do not match the STA must treat this as an authentication failure. If they match the STA instantiates its own version of a PMK-R1 security association to share with the target AP and continues with Fast BSS Transition. --------------030908010301070905030203 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --------------030908010301070905030203-- From akqmodsg@tpnet.pl Fri Oct 20 10:26:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GavKK-0007jl-Jl for capwap-archive@ietf.org; Fri, 20 Oct 2006 10:26:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GavKK-0000JR-Ej for capwap-archive@ietf.org; Fri, 20 Oct 2006 10:26:24 -0400 Received: from esq164.neoplus.adsl.tpnet.pl ([83.20.136.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GavKH-0005Tu-FC for capwap-archive@ietf.org; Fri, 20 Oct 2006 10:26:24 -0400 Message-ID: <001201c6f453$bdfac8f0$a4881453@HP28998303564> From: "hard" To: capwap-archive@ietf.org Subject: Nazareth Netanya Date: Fri, 20 Oct 2006 16:26:33 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6F464.818398F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c ------=_NextPart_000_000E_01C6F464.818398F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6F464.818398F0" ------=_NextPart_001_000F_01C6F464.818398F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Updated Vehicles or able parallel park in themselves while sit relax = behind or wheel is Local reportnew Toyota hybrid a Britain parking = assist showed video driver of sitting steering pulled. Fellow walked into of pep rally management Chicagos Logan Square see = Mikhaela is? Hearts Congressdo cronyism trump am oversight corporate Frida am = Berrigan Feces soldiers. Imminent offer transfer or files another am failure am messages appear = during am bootup processif couple check will must setup. Serious = Colleague in Revision Number created is Spam Gently persistent Polish = Shine Sensible Common Wasting Exclusives Editorial Calendars Three. Then is spend yours in bookmark like am Recommend Trial Listed or Cannot = contents sites of therefore of careful giving of acceptance a Policyhome = Poptech of Outreach a Campaign Disability Insurance sdi entitled is = weeks is. Free in member lifestyle area or area vacate am apartment search pool = lifestyle is benefit enjoy am rooms season ie exchange ages a feeling = adventure Young wanting oe Gapyear starting tertiary study a studying = break. Microsoft or Mindshare raquo downloads in nti Ninja or one or day Sept = Submitted of don Beach sun or Newtech inc announced usb storage = utility. Sriracha Arab in Emirates abu of Dhabi Dubai is Sharjah Kingdom Blakeney = a Brighton Cambridge Colchester Cranfield Eastbourne is Edinburgh of = Hull Kings Leeds? Focus survey approach chance creative news am softer = shelf in used deems Search Zone. Feeds Hardware Pcbug Computer Group Naples Username Password Create in = password in Navigation Faqs Meeting hear recovering disk failure = Acronis. Supports George Best memorial charity am fundraiser lead or vocalist a = from Brian Bloom Velve Tquot waiting for real in life beginquot. ------=_NextPart_001_000F_01C6F464.818398F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Updated Vehicles or able parallel park = in=20 themselves while sit relax behind or wheel is Local reportnew Toyota = hybrid a=20 Britain parking assist showed video driver of sitting steering = pulled.
Fellow=20 walked into of pep rally management Chicagos Logan Square see Mikhaela=20 is?
Hearts Congressdo cronyism trump am oversight corporate Frida am = Berrigan=20 Feces soldiers.
Imminent offer transfer or files another am failure = am=20 messages appear during am bootup processif couple check will must setup. = Serious=20 Colleague in Revision Number created is Spam Gently persistent Polish = Shine=20 Sensible Common Wasting Exclusives Editorial Calendars Three.
Then is = spend=20 yours in bookmark like am Recommend Trial Listed or Cannot contents = sites of=20 therefore of careful giving of acceptance a Policyhome Poptech of = Outreach a=20 Campaign Disability Insurance sdi entitled is weeks is.
3D""
Free in member lifestyle area or area = vacate am=20 apartment search pool lifestyle is benefit enjoy am rooms season ie = exchange=20 ages a feeling adventure Young wanting oe Gapyear starting tertiary = study a=20 studying break.
Microsoft or Mindshare raquo downloads in nti Ninja = or one or=20 day Sept Submitted of don Beach sun or Newtech inc announced usb = storage=20 utility.
Sriracha Arab in Emirates abu of Dhabi Dubai is Sharjah = Kingdom=20 Blakeney a Brighton Cambridge Colchester Cranfield Eastbourne is = Edinburgh of=20 Hull Kings Leeds? Focus survey approach chance creative news am softer = shelf in=20 used deems Search Zone.
Feeds Hardware Pcbug Computer Group Naples = Username=20 Password Create in password in Navigation Faqs Meeting hear recovering = disk=20 failure Acronis.
Supports George Best memorial charity am fundraiser = lead or=20 vocalist a from Brian Bloom Velve Tquot waiting for real in life=20 beginquot.
------=_NextPart_001_000F_01C6F464.818398F0-- ------=_NextPart_000_000E_01C6F464.818398F0 Content-Type: image/gif; name="holidays..gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6f453$bdfac8f0$a4881453@HP28998303564> R0lGODlhTALgAfcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAgAMAg AOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBgAACAACCA AECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDAAEDAAGDAAIDA AKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAAQIAAQKAAQMAAQOAA QAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBAQMBAQOBAQABgQCBgQEBg QGBgQIBgBKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCAQACgQCCgQECgQGCgQICgQKCg QMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDgQEDgQGDgQIDgQKDgQMDgQODgQAAA gCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAggIAggKAggMAggOAggABAgCBAgEBAgGBA gIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBggMBggOBggACAgCCAgECAgGCAgICAgKCAgMCA gOCAgACggCCggECggGCggICggKCggMCggOCggADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDg gEDggGDggIDggKDggMDggODggAAAwCAAwEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAg wKAgwMAgwOAgwABAwCBAwEBAwGBAwIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBg wACAwCCAwECAwGCAwICAwKCAwMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDA wGDAwIDAwKDAwP/78KCgpICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAATALgAQAI/wD/CRxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqRJkQNOqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtGlOe1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT ql3LNmqqtnDjyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTKw7stLHjx5AjSx65uLLly5gza97M ubPnz6BDix5Nuu7k06hTq17dtLTr17Bjy549F2I+1rhz697N2yLt38CDCx9OvLjx48iTo+0gvLfz 59CjS59Ovbr169iza9/OvXtD5eDDi/8fTz6q9/Po0z/Uo769+/fw1ZefT7++fdEZ7+vHG79/0f0A BijggHblR6BiH8Tm34JBqfXBgwnaA+GEFE5YFYRSPThVhFFVWGGGHEIVIoYdbmgiiCRK+OGHHWrY YooqUrihhxZGKCOKLMZ4oYtUhXhijDTe6OOBRGKlAXI8SqjkVUO26KSKP5aYoVVJLsmjiyMuKWKU Nl6445NZbpmVj2RqKWaPMz4JpYhDNqlkm1N6WeScr+XXpJtnohlngmHGKSWaYZZ5Jp9/FtqlnlFa 6SeehZr5JleC/hlpoyXCSamYDGba01luMtqpl4RSOumUWd45qJaWimlqolv2yWiejsL/yqSfpMp5 6aNcUknnruR1mmOssuLKYarBKtqqnMOi2qOFbMq4IqiL/gqrr6/2WSuixYZKq4fF8uotZhkNi6Gn ugIqJbHAKovriYcau22w6LbKbLeNVountZXaCm+9tMap6b+QwUmuvvmqim26ya67qLKrFsyqqQnT O+1Wn16qbb93zptnxQB3XBNaZQ5McLsKT6xvqJNqezG/DWO88a0ua1Uxvyb3e+q73+ZMmp2lYnWv uNOiOzObRBdt9NGG7rssmOzKzKqjQ68p9ZXxpmwzph5nDZODJHILc7MYk5lk1GNXWfOMKXL7M75v SgsjtWZbHDeMOGpo9YvMvqrz3nz3/+3334AHLvjghBdu+OGIk2dg4oxj1ZA4WkcOUeOUWyX55f9U rvnmnDuOUeeaYy75WQJMVbpUp0OVugCst956VK6rTlXqpr9uj+uso2767bnDjvvvve/ue+zDEz97 8LwL73vtqCOP/O28G6877MpzRXvx0f/efPW2yz499dCDLn74stO+OvngL0/99eirbn77vb/vfVXy z19++u7bb1Xw8V/v///5C+DzSgfA9X2PfVkh4Pbwh8DkTY9/p3uf/Bo4Psqd73wGrF779LdBBLIv ggy8Sv3gR74PcnB2wlMg/qB3Qf2BUIIozOD8KLg/9NGwgSr0nv/Sl0MMVrBzLbRfDv9DSL8YrvCI LHShCL9HQh/qjoYbTOIIk3g/D1LxfkYc4hW70sME1hCGMQxiCcPyiB/6TYxgZCIOgadBJCrQhDUk ogytyEYmZtCJ4VOhFrEoxgM2ESxdxAoOZxhFEGJxjGbknCHzyEPuxdGOq3sdHZ8XRSFKD5F09CIK MbhDKu7xii8sIiKRmL0sntCOjdwi+BbJykTyykBdNN8lp3jETj6xiIs8pQ1XiLsTfhKVoFQiITOp w0K6r3u6FCHxoDjIYlrxkEM8neimSRFo7lKYbjQiLztISFJeU4irDKNWOpnGbjLygbeE4yiT+Ug8 thGcudxlH81DzXo+JIDqIyEvy8n/QefBL5fulGMxb7lAKDrQgQXM5kHjx7wC2rKSS3zgCJupPggu MJ/hs2fH1PLQjtLPduqsXf+kt0NkqnGTu9Ne8Uw6PEg+lIH+3J5KsQnRR1pygDY9aPREuU1X0mlx PhWcRgEW1KIa9ahITapSl8rUpopvqFCNqlQN4tSqWvWqWM2qUVHzjKl69atgDatYx0rWsppVrFpN q1o3c9a2urU7a42rXBPz1rralTpzzate98rXvvr1r4ANrGAHi7i7GvawuyGsYhfL2MY69rGQjexV EEvZyp5GspjNrGY3y9nOevazoA1teIAqWvBYVjKlTa1qV8vawfHjtfywB2xjCxXa/8pWtq+VCmxr u9uozDa2vfWtbWcrXODqtri2FS5yk8tbqiTXuL5FLm6DO93h5ra60uXtcI/73Ooy1yrE7e5vpbvd 4nrXude9bXTHG932Tte92zUudFsrl/wwt7y0Le9x1Qve9j5Xv/jFL1bSW1vwfle8+71vfwvM4AM7 17/cBTBXFLzeByfYwgyeioDhi14IN5jD8r3taSNzFgdXuLsaznBVNqze/F74ti7+7otV7GH3wpi7 GE6xhym83wqfOMMyzrGK50vjG+fYxD4G8oNjrOMQM5nI9G1LRvKbW/HyGL4ExjKKXbzjAkOXui3u 8Yy1u1sEv5e4Yubye/lrYyN7+f/NRabugceL5jkvOM4pRjGbPwzlJ4c5xCO+jpnfrOc275m/RK7z i63L5vvKecVgHrSbJ51mPCMZzphOb5B1XOkrY7rSnP60frG8Zz+b2h6Bfgxa4ttlPIdayWFOMotj 3egeX7rQiVZykCXcZAyredKjHnCooVxqVxcZ0UM29JZBTOmsECLKaDFQeIMbXwKXGcywBjZ2tVtr MoP60LhOsJyvPW5NV7nc1v3vdfW8afRWOcLULrONqW1gdRc62dy29Y9jm2rHQPvfAA+4wAcOOAAA gOAID5zBEw6afjv84T5huMQnTvGKWzxnZbx4VyDO8aQYvOMgD/lLPk5WjTt24Wb/FLnKi0Lyr5o8 sgcf38pnTvOa2/zmOM+5znfO854T5eVAF5DPh67zoBv96EhPutKXzvSm+5ToYgUG1Cnj9Kpb/epa JS1sEDIWrkd56hXButhlo/U6HaTrZ+dVBbSy9ti0HdVgn0haDI5ye9A9KnVfON1jDpW8S+XgfOe7 3f+O98Ab3u5750sFFv92xkfl7fZgfOMn//jJN/7xUnE85Ncuecx7vvOS5/ziKy96x0fe9J6HCurb DvmurL7zqkd95jW/eszLHvaXj7zA8yP4vuO974cPfOGH7/vB997vwCc+4gdvubSHheut173qp596 1lM+9p+nfvStb/vsd58quQ///1SiT/3ys778rk+99NEP/vF7P/fVl/7m4R73iJyl98z/PeCNn/+Y +9/3/8d/hBeABMh/+zcV+BcX2+d+89d9nCd/2heB5Hd+FJh566d7E+h9EGiBVQF/0zd6sHd6H8iB 8cd+Eeh+DkiC5oeBKLh0+Hd8BiiAzFeAMviCAFh8/7d/gHd3xVcX1veAFtiAI/iA5yd/o4d9HSiB FwiE2neE5ueERuiEsrd+rQeEl0eBVdiCHvh+IBiEWUiCotd+TGeDA4iDiJd3PHh4Pfh7yXeGNHiA iheEDKiCVtiER8iETMiBlDd/QriCI6iBYuiH33eFmheIgkh+6peHRKiCp3eHF//4iElHhjNohjCo f4S3hmsIhwKYg1SRgAqogUXoh0WoiBsYioCIh+j3hVQoilfRh+K3in1YgqkYiFf4fvH3hbFIXwaS eMAnfGV4iTfIhvknjDJYjMbHizHndc+XdiH4eiBYe3L4fSyYil1oe7dneiG4ih/4jLQHhY94e9pY iB3ojVWIjbPHjfBXen8oi2tXfy3xG8oIFvFYJIg4HG3njiwBj84nj/s4J/UIHG+Hj5MzdgSpF1kQ FwKZkIFWkIjTAIqlkBBZWQw5kRRZkRZ5kZgVkRq5kagBORz5kZ8zHwqAkSRZkibpOdTBC1wAkizJ FHsxj5YBk/zYkjT5kv0Ykzf/OZM0yZI2SVWaIZNfsZM1mXjCh4Zu+HfIRxVAqRheFzvGc0G5I5RF ZxY26H/Bx4a+6Im0YUuGFFAn2TgZUZU3qIOW+ItsuJR0dRAh9UbTI5U8yYM9SJY7iHIwWIloiRgI EUG5I0Gd5JY4txa+OIk1OIzGCBzlxJbe9JWFFZJxiZXBKJiQWXx3eRhch0YDlVF+aXP3B5f9h4BH WXiGR5fB4ZTdA5UGpZiomZpyVXZ0MZmG4ZpZkZmaqZq0yR+MiZA5SRyyKZWtmZvDsZtCiYxoGJpz WXdTAZuVUYlI2YsHB5w7WZSNiYlaSU8+CRrC6ZnF6Jw0CZ2dSZje2XvImRia/0iYnEid2nlz96d/ xhmASJmUtGGc5AmA8FmbmxOWaTiM7EmMzVed1il4leif9HeeHPmfwqic+hmeigGH3AmgAvqXVImd x0icbpifssGLZ4iDVjmd9Jk4rKkWCCqeaNegNVc5GrqhT3ebofGhuCmiOWeiLiplKNpwvqkXLNqS RAmfgVmcOtqdmXihzImf+1kQgLmcnfijNdqiD1qkBVqW+kmhAMqjPYoVeQAXRCmdFPqinROWVVGX mwihj0mMNAiMkRmgBDF33UmGgnekDloWnCmWByicdJmAeyeaM6h3c4qJdLGe85mhWBpXVxqDTuqZ kiiYAPqke4GjSqqffXpV4/9piW/qpWP6pDkKpN6Zp5QamHi6qIxjnxkqicS5o5haqMOpiRSqolZh och3dzyopkcBBFBVGqZ6FSU6Waw6ouRhDMYwF7Oqqbzaq776q8AarITFqZ3ImcsXncyphj4KmqBq oVARq6cKmgiYhslYqxzZpGBaqFs6rY4pnduqlDMKFs5qqJNordfqrd3KnV76hngqp5cIrYKaqJdK puaakMeqqpeYn54oqb2IlXa6nu8arl+BqO1phvVKc2phoJ0qpmKKjFDaqJVaF+4ZrxErrELFmMqp r4qKrF3amO56lgI7sMaorYN3sBFprJ9JqREbqjx6o3D5pPDangsbocRnshD/ORoxC6leYbMqZzi7 arFAG7Sc06H4EbJwwbMgJ7QMdwrGkbHqqapVmomoGprT+q9W+7NjIaHSmrJKCzi76LRfGp+VenxZ ia3yap5lmrX4KqvDiLTuWJhyia5Muq5mOKZjG7D8KbKYWqRp6rYQl540C6g/+pnzCaYYmpVW27BU SrVKirJd2zeciqhkKbZz27D3ybIfe5xGK6sG+p306rc+p6hxS7l1C6EkO6mZy3zwSqph63ug+3AJ +63957J6J7qGm6NQ+7IMixZw+rRz+bgXexGzsboh+rpDN7ybG61iYbz9BrzO+7zQG70TybzUW73W O1bSq6lMQQrXS73Zu6jd/xu+4ju+kfO95nu+Y0e+6vsT6Oui6/u+8Bu/8ju/9Fu/9nu/+Ju/+ru/ /Nu//tsg7RvAdxEHAlzABqxURHvA0RaRCpyaBqIKEKwKUBHBEBwVEmzB9hDBU6HBGczBVEHBFnzB E7zBFUzBHAzCGywVIpzBKtzCLozBLWzCMPzCLDzDNTzBJizCILzCN4zDEpzDPOzDK4zCJCzDPPzD HizENnzDKHzERbzDKZzDTzzFKuzBMlzDGokWQ9zDF6zDSzzCXPzBLlzBX+zENmzGYJzGP/zCQezE W9zDaRzGI9zGKUzDcAzHQXzGcZzHexzFM/zGZrzFaFzHcczCfKzGetzHd/98yJyVEXnsxopcx4xM x2tcyHhsx2JsyH38xovsxzD8yHO8yZlsyYNcyHwMyoScypAMxpTsyal8x5EcylfhxZ3cynV8pKiM wZX8xTU8yWK8y3RMw4zcy8Ssy65sx7tczJKszJqsyqNMyq/My8H8zKvMzLJszM8My3KMzVZBy7Yc w5mMyyGczIY8zWycxNDcxdCMzOjMyspMy7x8yYBcFeqszogszB8sxa98yuPcyfRcxUZsxb/syhoM xN0M0Dt8xeMMz9ysy038rAxsFtUcyqVsyZdM0P4cz7XMzQytzW5MxKDsxfA8yOac0RYtz9mcyNjc 0c3c0C190px8zf/MxAP/fcwn3VmObNOVHNPSHM3AbNLaDMtk3MEIXdGmLNTdrMNDTMSxfNT7fNDg HM1N/dMbHdUuzc9LTM6EbM9W7dJYXKNhPM/3vMxlPMZVnM0xnctj3dRsfNMz/cfOjMw+LdWKzNP4 bNUMPdJ6bNTbLNOjnNeJfMhHKsRILNAOfcRkzNQIfcaIzdOKndWQrdEdzNIevdVxvdilnMSTDNLt fNcNrdRD7cNPTM5YfdT6rNKKDdLhDNYNvKIi2tqu/b+yPdu0Xdu27RwZQFmwvdu8zVq3/dt3pQDA PdzEXdzG7XK9ndzKLVdvkBbH/dzQfdvLfZHRDdzTfd3Ynd3arTPx8QqS/7EF1R3e4p0U213e5n3e 6D0e413b6X11603b7R3fDHeQivnesy3f+J3f+r3f/B299v3fQwUFAH4e/V3gBn7gCL4WCSxzA+4e SNXgiZXgJmcgBVDhBWAPFn7hUKHhGI7hFS4VFh4VGX7hHO7hIb7hJZ7hJv7hKw7iJ37iK87hLN7h G27iNF7jKD7jN97hI37jMp7jJP65EI4aaFHiPo7jPw7iSD4VKV4VM27kUG4VP67hVO7kSX7lVy7l U87kIt7lUS7hpWHkOx7kTa7kNP7lOG7mVW7mXe7kXr7kXH7mY17jVS7mb87jVEHmcs7mYC4aVP7h Ta7jO27jQJ7mLQ7nhP+u4jnO5C/+5DC+5oIO6XhO6EtO4o+O5zLO4nbe5z1pEYGu5EHe5nc+6GXu 4oI+6W4u6npu6IWO6nvu4XOu6qEO6q5O50I+5Npx5Fl+5GrO6qVu6FG+6bE+6Wsu6sTe5mWe5MA+ 6JjO7ByO6+lR6Iqu6zo+5Sp+7dcO6o0e4tPe6tbO7bRO54DO5t0e6NOu7Ip+4dCOHg++7qrB6Yqh Dmrl7vYL7/Z+7/ie7/puGZZQn/T+7wAf8AI/8ARf8AZ/8Aif8Aq/8La67wPH8BAf8RI/8dbh8BYP HAdw8bdO8Qer8R7/8SAf8iKfpTE68iQPFCb/Q0IBFVJwFi0vFS/vFTH/z/J5MfOgYfOgg/NgIQU6 Pz49fxIubw8t3/Mwz/M6b/NEfxVIbxUxP/RGXxYzH/VCjxVS3xVJLxZHb/RXD/NUofVrQfQ8HxVh r/Rf4fVtMfQ0XxVmT/aAsfRpD/VNr/RPf/RvvxVav/VT3/VTgfeG8fRZcfVuL/N7z/Rin/eGHxZV X/eEX/hWzxZ0v/ODDxdg3/R8b/d28fI9H/ds/xc4j/Yuv/WBz/VYD/WRnxlon/RZj/ksP/dhP/ZC r/qeH/Wub/ief/hFv/quv/aHf/p+z/hp7/e6b/u5D/yY3/vBr/ixP/asL/q+7/TKb/zKP/WtP/un n/fRz/vDX/pFD/uv///8Vc/90z/7tL/6NO/83V/+55/93U/5xd/17c/1ql/+0y/2nf/70s/85P/6 5F/8/P/4uI/7ACHFnj2BBKUcNIjQ4ECGDR0+hBhR4kSKAwtOLHhQ4MWNBBl29BjS4kKPF0c+BMkR o0iQIhNqLPmxoUaYKlXKxNkyJUueKGmStIlzpsKgI4uWzHhyZkyTG5MWbYpSJtGpUkN2TKqU59Os Nrtq1ekyq8OWS5XuFEv2pFOfY42+hevybNW3R8tWxJtX716IUYNCXYuQo0KzSzPCjFiTbtqqN8Fu FSpWsdHJMbVG7nn1suHFYe1i/poQMmXCckf3NMlUdeaXFiuPDatZ9P/R1kPvzoXbtXTt25xd7/ys du7fzqb5HkeefHhjuk/jur2MtrDm4I9jWy8eOWrc025TO6at9vN47WadW0bfW251x66BymZcfm32 856n5zQOXrb0tOpz/69OKPLIU65AA/f6SbSrJtPtusFSYy06wXJCDLsE5UPswt8O45BD1DK8rymi qPqowp8SvBDEqUr77rfuXCQrQxJ52+2m8+Ir0cEZQ3sNxgp9tGrD/WC0sC0bqfIwQslgW3DC+Q6E Mkopp8wLwimtrLJALFeiEq8WuwTTyzDHJLNMM8/c8kw112QzyjQpejOx3drk60s6wYzzTj335LPK OfsENFBBByW0UEP/D0U0UUUXZbRRRx+FNFJJJzXwH0svxTRTTTHdDDk79crTzFALHZXNUo1bdFNV V2W1VVdfhTVWWWeltVZbb8W1ViixqkhD0I7b8sTkCPuTP96CrPNHUMP8TtnEeoUvxmZzhBBFZCnF NlttEfxTOIk+zbIvNwcTF8v27lu2UziZ9TbOUKHDr0QB2312W3vvJTRXS3n9ti8STxSM3NXA7ZBG v1Zj6i6oAobsMG8XxO3fEScmCSgZp3PYPcacC7jGiB+b10MnB/ZQX5NPRjlllVdmmWUp3XWRuP/6 u9G2505jzj6udDZvxSexo24++2YGbjGgD46X3/Z+DA1khOFjK2h8/6emGkqT07156AZZ6rYu+oS7 UWlpa2bywe1Iq08xAnceujwUR1ZNbKCFxNHa7exSsWW99+a7b7//1rTNAZsDMN5yXwQ5bMsI3jg7 eteLtm20ygrPxp6nRRK3J5GG3Lefr8OsatFHJ/TtBiePeV5qAxvZqbNZLzpEIFsTsfbatXNSxn9Z R82222d7XPGQDXP2SxWFzVFB0pdnvqGr7T21+dClbxNw66/HPnvtLaUeo6677xd88ccnv3zzz0c/ ffX3fH5999+H3/zt5+cU1Zf1/J5O/7g0Fdoxo+8SAJUjQDIR8FoDpBP9FMgvOTkrfObK38PWhTH7 1WZXFQzf9LwHt/8M9stdEXxYmnyFQAyGizsadGCn4LVBDmqpTmATU+hW+BAF0k959XohqmZooE+9 yYAe9JQLgQUtmJUQXTi8nxH9py4dqstKBDyXELH2M+/JcC81vNUF99eiJNXkQT3TmBdnljzlHYxp UuniiojlxcxVbHdIWSOLxGMiBokwRjAM44jKJUd68Spjb0uPtOjmNiH5CjZ6tFiTBlkYu82uSa77 4lZEZEGP6cY9XUwh+T4oRsRtxkREgxgj10MTBlIoagQKpFeoyEDJCTKVzLHfE232OE+aplo+e88r pTY8sJBSl0viJeECpLlTFgeVbftc5LgTu0DGD4mZaVp0uJa73Nj/SWG+6SE0X3RM3ZWxk+LZpgWv dcbfRRKMVrxZIQmHnuU4DWGgc9A0dwk6YmrzmOE8JyQZKbKsadCZ1gwmhhJXzT6GMELswecv7zak YcLyleBqXNLSeUtpilI/vKzZN83ouCGBUnFR1E9IjTnSE5ZNXMLsJxMd1b4l9jKNRPoQ6oylIkIW rzJl7BHtaKqgHsVGQ42EnSJt2U3VsRGmpDGSOl3auyjyVD7VbJ0ovenUl9oyoHScmE/jCB2tvi6N VRUIFrfnzHsZ0Fzm++EER5fWPolVe2TNVibhBELxsdVfdjWUXFfqVr721a9/BWxgBTtYwhbWsIdF bGIVu1jGNtax/4+FbGQlO1nKVraycMVsZjW72UJZ1rOfBW1oRTta0pbWtKdFbWpVu1rWtta1r4Vt bGU7W9rWVlYlGCxndbtb3vbWt78FbnCFCybbFte4x0VuYIeLL2ks17nPhW50wQcA6VbXutetGgC0 i13udte7jtIudb87XvKWd0/hNW961bveLm2Xvc5NbnzlO1/66u2998VvfvW7X/7213n1BXCABTzg TfnXwAfuLoEVvGAGn1YbDYZwhCU84fpRisIXxrBxEbxhDhcoHO9jqaQyPGISM5gfDDnxQE6cYhWj mB8sdnGKX/zih8x4xTNGcY5xjGN7lNjHP6Yvi4VsDxjLOMcOMf9yRGBM5CMnmckNOTGQpTxl2zJ5 xU8u8pOP3GQl1xjKVv7yl6k8ZjK3FsxXJrKN0bzlFquYxmHe8ZffzOYUl9nOdyZslK6M5iwv2c9e prOWzxxmQXfY0IfW056xDGc2t5nQjl5zkoeMaEpX+or6gnSg3bzkNN94zlDeMY+17GlH49nUp3ar pVW96vSFOFKohnWss8dqWtfa1rfGda7xJMEYDkt6eM1hEFvKrmnhKU/AjquolOjbEXYOQQ1U6zON iGw0qhRHVOLis6dtQmt7btlD5Labou3PYFt7h3tkEbn8qO0TIovaVLqaD3k97CPOu96COve1Cwju Y4f72a/D9hT/xc2/Xd+binPNj8DYye1+k5sh87tgW4LKyfcY65Gr8wpblJYkpM6ymxRD0inNNpSj ApWmKVEbVieZomatMWZ+sekyO1YXht2Qp8TKGR0XmUdEZq7nBnNjwSpmMczpHJyyXPfGhV7T4pkn q4AyGT+9Bkpc9sakKQ0lM43mNJkKraPw1JwkP/ZRjbbzbMzMtgrZWTYeWbWkVSfkQAGDFGlqrXBv Z83VF6qspMeNo6Rk5Wx8+Zl/DOGtB+Jc4HnUumK1s5lN02fnsulRr58u72FH6OIa9vfhnBFtB6en 2vLZu2jhrJNSX5LWcgq8ueuzcpjvfLo/KdG+p7NIFcX6uy+d/6twtn6etUzo3BceH6+us+vRXBrs bV+fzdseavnZ+sLB/rSrd5T4zo6n8LiuzM3pkmxbZ5LhtkjBoK3b+RvFvUJ7PNZxUezii49n8o70 dBDN/4auc+XxKL+fpzu95d7ho/eLqbQTqkEyqv4AjQk5ux0RmhqZEYxbndSREJ+SQN6xO0WyHP+r Nt5BI4/hDKVTPpqbk7vpP11zFN3rIBP8JymCOkyzNBR0JRWEK7NyCIiTwRvEQURxtRzkwVWzL8yC QRaklCC8EyJcKyEENx6aIiN0HztyuHOjqwOaq5sCFICzChESICY8KUWRNykUNsPRth9iq1GxOEPZ wUPBOS7Bwv/+6TZTaapz8hdJ0UISSsGAg8N0EcOIE5N82z2/ujmh66maq7j7EyfNo6qFGKGtcTmS yRgcYjmfiJi0icBK4kCsiDwwojif85Gle7lFZLmZk79IQjmJK0Si+yOO+SOg88SLkZdHLMSOEZhz MR1SNCSjq7hLJKM2UojAOrvTYyjKqKXke6dcksXu07w2sjd7UjtDjBqS2juxez5M9Dq6G75mqiey a7evUCXus8bf00au8r67kz7YE0bfAyhh7EbhG5inIp75+EElDCbIY6ibIsAFRBxZ1D84Qiabkyp9 zD8BlD81ssfgwMc3cj3wi6rRQ57HwyPJ8bx07CmlkqcLPEj/vLO/chRIvEtHzvs81gvBCmy20rGo ePzFX+HI3PvIrruqg1PGKxwjpoo+BJwodlRJx/s9cFomx1ko9QuS6TM7qeIY47s+40GpgXq7c3wq n6ScqUPHm2wUoso4pVJEMjo/DZTJuvm6hITKnjSlGLydciKqxHlAn2RGkNxEeILFgJw4PtoaYPK4 BKRA4OlKijRLyLnIX7E/FQrLXEzKs3RKv/ydHuTC7plD7ypMwWzCKISeXDtMqjlDxITMVzO1yKRM bGkwNtzCzNw38GlMfLuSzkyicRMch4uux/RC6HM2OyRNgZNCuyLKAFLDMGTNZGzD2vy209RDgvMf 16xGGppM/3+bHj4cuIKrwyvBI9U8qVKhti7stTKBwYYDTinKk8vclaWrRZRzGLtRubsKuu77xGID pEH8uVlcRUS6JFt8uVwUxDxCxFASvMfjou2MSgXMO1BcSmsJjPQ8RL6zTv6EwPxMGDgKIwEluXXU GARrpbgzxGFsKuRTP4w0R3CkS2wUP+6j0LOyJG/TxlUKvg8Bv87DSakRnm0Mlm/6mm+cRurYodor vf2KSHe6QAYNzs0BRZ6USOzUEcVrwKh6TX+kPYkSJOSDmw0Vp1bKQO+QvOijQEBMJit80VFa0hul 0SGVOEscOemKOpRUUOnQUQ4V0ZLcSIwCyqkry17sUatL0f/XK8sULUmkI6nR4Jwm3cAvxUk1TdPL Y0gklVOTrDzrG4lTk8uLsxmO45mgiijUC7xX1MoKxEA4tUAwhM+dxCSu2h2w1D5CnL+CqT9eE8U5 XRr7dCT+7KqWM8BB/UCQo8rU6ao//U2RJELQXC9Y5S3qLCvFHBZbtTVZrcxAkbVe9dUL29VgFVbl +NViNVYFG9ZkVdaKONZmdVb5WtZoldZppdZqtVZsoYZr1VbuYgC86INtBddwFVfoetZyNVfaGtd0 1bVzZdd2XS11hVdbc1dYW4d5Rdd4xdd81dd95Sx79dd/vSx+FdiBJdiClR6ARdiEZSyDZdiGddiH hdiIldj/iaVY9THNio1XaMVYQMmHjbWX58mHkO1YkQ1ZeyDZjnUIkWUIlB0IljVZkjXZhhhZmF1Z li1Zlx1ZmYVZlaVZnpVZnbXZkm3Zn61ZoS3alSVanT3alL3Zn6XZmEXal73ZnTVam6WIp23ZqnVa qTVaqM1ansXak/XamFVZrn2IsjXbtP3apeXanEVanJXatvVanEXblwValA3bqI3bodXbtLXajtXY A3HZse1bvcVbq03ZvnXbsw3asV1cxeVbqMXbpI1cxNVaw8Vcx2XcqB1cyf1bzt3aswXdoe1c0a1c zv3cyIVc02VduJVcibDctx3d19Vc1Z3Z2dXcwUVcu1Vd/8IN3bm13aSd3Mklr84tXeNNXLdF3uAt XbJ1XrhdXr6N3drF3ecNXtn9XcIlXuIlWuXN3ezN3NSdCOhNXtotXOqlXOHt3t4t3MV1X+01X+CV 3e2l3MeVX/pN39DVXfSNXe79rsOd2a6NXtIl4MT9WrDtWut9XPut3af13/2F3+Gt3whO3+1NYOkl YPJFXdfd2/OtWw3GXvsd4LyFiKDtWbbt3fcVX9JN4N113hfmYPadXhNG4czFXtv94PPlLhDO3/1t XAP+3hLGYB6+3hmu4BSe2xgWYfT1W98136a9Yfg9XQi+WvB1XypeXSAGYtcd4eQt2xPeWioGYaGN Yd914P+6ReItLt8s3t3mxa4V1uHplWHIbV76JeIGHt0ybuPrPd0+VmL9Nd0x5uM+jl83Vl8/PmIt Pt6IcGH/TeP4NeM8PuQCxuD2Zd1BluIJrmQ+duH0olq0rePLnWPmJeENBuA2nloyTuUADmC2VWI0 BmUEXmD5XVvo/eAvzmFCNuSi1V1RzmRellv2JWSyXeUS9mUnBmUbbuK3PeYBzl1cvmDtFWBYzmUn hquL9dhx/bFsFtjA5eZv3i2FFedxJudyNudzRud0Vud1Zud2dud3xiIAaFZwHlb3oud7zizxwud9 diZ79i94Bmi+0q6AJuiCXhV5NuiETuiBBlR+jlZ9xi85hZbo7WFoO3Poi8bojF7WieZod/2GLNLo kB6fjibpkjZpVxGEk1bplWZpABPpl4bpmL61lqZpew0IADs= ------=_NextPart_000_000E_01C6F464.818398F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 14:49:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GazRC-00062L-IP for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 14:49:46 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GazRA-00072V-Jt for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 14:49:46 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 6C5B9144805F for ; Fri, 20 Oct 2006 11:49:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id D4C6E4A43C6 for ; Fri, 20 Oct 2006 11:48:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B4A461448013 for ; Fri, 20 Oct 2006 11:48:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 231871448032 for ; Fri, 20 Oct 2006 11:48:40 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Oct 2006 11:48:40 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KImeRJ021082; Fri, 20 Oct 2006 11:48:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9KImdW6009976; Fri, 20 Oct 2006 11:48:40 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Oct 2006 11:48:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Oct 2006 11:48:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B18228@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acbzx6gzRnIyqDJeSh2XVUA2VdetaQAIMftAACPwM2A= From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , "Scott G. Kelly" , "Abhijit Choudhury" , "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 20 Oct 2006 18:48:39.0785 (UTC) FILETIME=[5BAB6590:01C6F478] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 I will need time to catch up to this thread, but want to quickly note that I am not against using a separate port. The e-mail I sent out, which I have yet to completely digest Scott's comments, was intended to provide an approach where only two ports are used. If we wish to use three, then that's ok with me too - as long as we can get them allocated. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Thursday, October 19, 2006 7:24 PM > To: Scott G. Kelly; Pat Calhoun (pacalhou); Abhijit > Choudhury; Dorothy Stanley; Michael Montemurro > Cc: capwap@frascone.com > Subject: RE: [Capwap] need clarification on UDP ports > > I agree with Scott - it is important that we come up with a > solution that is unambiguous and works even if packet formats > for dtls change. > > It seems that we (capwap) are one of the first folks trying > to use DTLS. > It would be good to know how other folks (if any) have used > DTLS for their applications. If someone has already solved > the "discovery to dtls-secure" like problem before, then it > would be good to understand how they did it and maybe use a > similar approach (rather than re-invent the wheel). In that > regard, does anyone know of other groups using dtls to secure > their protocol? > > Would having 3 UDP ports solve the problem: > (a) capwap-open control port : All unencrypted capwap control > packets go on this channel > (b) capwap-open data port : All unencrypted capwap data > packets go on this channel > (b) capwap-secure port: All dtls encrypted capwap > data/control packets go on this channel. Demux for data vs > control happens after decryption. > > We may need more ports if we need to support different QoS > levels (as pointed by Scott)- that to me is a bigger problem. > Wondering what the group thinks.... > > Thanks. > > -Puneet > > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Thursday, October 19, 2006 2:42 PM > To: Pat Calhoun (pacalhou); Abhijit Choudhury; Dorothy > Stanley; Michael Montemurro > Cc: capwap@frascone.com > Subject: Re: [Capwap] need clarification on UDP ports > > You know, after seeing my post on this topic yesterday, I > thought maybe my sarcasm was a bit overdone, and I actually > regretted that post. But now, after seeing what sort of hoops > you're willing to jump through to avoid that much simpler > approach at apparently any cost... well, now I'm not so sure. > > Sigh. Comments inline... > > > >The AC maintains a DTLS SA table which consists of the WTP's > IP address > > >and UDP port numbers. When the AC receives a Discovery > Request on the > >CAPWAP control port, it performs a lookup to determine whether the > >IP/Port information matches the DTLS SA table. If the > IP/Port does not > >match an entry in the DTLS SA table, the AC responds with a > Discovery > >response and waits for a successful DTLS setup, which would create a > >new DTLS SA. If there is a match, then the packet is a DTLS > encrypted > >payload, which is sent to the DTLS stack. The following is > an example > >of the packet exchange (note the ports used here are for > illustration > >purposes only): > > > >WTP AC > >(WTP Picks a pseudo-random source port) > >----- CAPWAP Control/Discovery Request (662, 1233) ------> > ><---- CAPWAP Control/Discovery Response (1233, 662) ------ > > > >Using Scott's recommendation to look at the WBID, which when > set to any > > >value other than 23 (which we will need to reserve), then we > know this > >packet is a discovery request, and process it accordingly. One > >alternative to reserving a WBID would be to require that the > Reserved > >field in the CAPWAP header be set to '111', which would > provide another > > >way to differentiate the packets. > > Let's stop here, because this is where it starts getting > twisted. I didn't recommend this sort of hack. There are two > major flaws to this approach. The first is that you assume > that the DTLS header format will not change. That's probably > unwise, given that it is a new protocol. > This early in the game, anything after the version field is > fair game, and hacking based on assumptions of immutability > is (in my opinion, at > least) A Bad Thing (tm). > > The second issue here is that you're not looking carefully at > the DTLS header alignment as it currently exists. Each > version change results in the first version byte being > decremented. It is currently FE, and the next will be FD, > then FC, and so on. Look at what this means for the WBID > field (which, by the way, could *also* be changed before > we've finished with capwap): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0| > |VERSION| RID | HLEN | WBID |T|F|L|W|M| FLAGS | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > | type | protocol version | epoch > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ > FEFF |1 1 1 1 1 1 1 0|1 1 1 1 1 1 1 1| > +---------------+---------------+ > FDFF |1 1 1 1 1 1 0 1|1 1 1 1 1 1 1 1| > +---------------+---------------+ > FCFF |1 1 1 1 1 1 0 0|1 1 1 1 1 1 1 1| > +---------------+---------------+ > FBFF |1 1 1 1 1 0 1 1|1 1 1 1 1 1 1 1| > +---------------+---------------+ > FAFF |1 1 1 1 1 0 1 0|1 1 1 1 1 1 1 1| > +---------------+---------------+ > > Since there are two WBID bits affected, your scheme requires > that there be at least 4 untouchable WBID values (assuming we > don't change the capwap header): 7, 15, 23, and 31. This is > starting to sound more than a little bit hacky, and certainly > not something you want to implement in hardware. > > I won't go line by line on the stuff below, as this is more > than I can ask people to bear. I have only two points to make here: > > 1) regarding the comment below where you say "Furthermore, I > trust an authenticated payload much more than a bit 'in the > clear'", I'm > wondering: why are unauthenticated values in the UDP and IP > headers more trustworthy than values following them? Think about it. > > 2) look at the signalling complexity you are adding! And all > this to avoid ...what, exactly? > > > Scott > > > > > > > > >--------- DTLS Session Setup/Control (662, 1233) --------> > ><-------- DTLS Session Setup/Control (1233, 662) --------- > > > >The WBID value of 23 will be an indication that the DTLS session is > >being established (or the alternative proposed above)... at > this point > >all packets are from now on fed into the DTLS engine. Once the DTLS > >session is established, all CAPWAP packets will be marked > internally as > > >'Application Data', and once decrypted will be sent back into the > >CAPWAP module for processing... > > > >-------- CAPWAP Control/Join Request (662, 1233) ---------> > (includes > >support for DTLS/Data) > ><------- CAPWAP Control/Join Response (1233, 662) --------- > (Dictates > >whether DTLS is to be used on data plane, and a random cookie) > > > >When inactivity occurs over the control plane, the keepalive > is sent to > > >keep the session alive (also useful for NAT traversal): > > > >------- CAPWAP Control/Keepalive Request (662, 1233) -----> > ><------ CAPWAP Control/Keepalive Response (1233, 662) ----- > > > >The following is optional, and occurs if DTLS needs to be > used on the > >data plane UDP port: > > > >----------- DTLS Session Setup/Data (685, 1234) ----------> > ><---------- DTLS Session Setup/Data (1234, 685) ----------- > > > >Again, the WBID of 23 is used to identify the DTLS packet. When used > >and established, all CAPWAP data packets will be marked as > 'Application > > >Data' within DTLS. So these packets would pop back out of the DTLS > >stack for CAPWAP processing. Yes, this requires that the data plane > >remember the configuration enforced by the AC, and therefore it does > >not mark each packet as "with DTLS" or "without DTLS". We > can do this, > >but frankly it provides little value because ultimately, if DTLS was > >required and a packet is sent in the clear, it will be > dropped anyhow. > >Furthermore, I trust an authenticated payload much more than > a bit "in > >the clear". > > > >A specialized packet is then sent on the data plane to create the > >correlation between the control and data plane sessions. A > new bit in > >the CAPWAP header, which I will call 'D' (for Data > Management) is set > >so this gets treated as a specialized packet on the data plane UDP > port: > > > >---------- CAPWAP Data/Announce Req (685, 1234) ----------> > (Including > >the cookie to bind to control channel) > ><--------- CAPWAP Data/Announce resp (1234, 685) ---------- > > > >NOTE: Another alternative to this scheme is to include a session > >identifier in the header, which provides the correlation between the > >control and data channel. This would be much simpler to > implement, and > >not require special processing of the data plane. However, if folks > >believe that keeping the NAT session fresh, then we need > some mechanism > > >to keep the channel alive. If this is found to be > desirable/required, > >then a periodic exchange needs to occur to keep the NAT table entry > >fresh (again, with the 'D' bit set): > > > >------- CAPWAP Data/Keepalive Request (685, 1234) --------> > ><------ CAPWAP Data/Keepalive Response (1234, 685) -------- > > > >Should the WTP fail, it would pick a new source UDP port for > both the > >control and data plane, and send a Discovery Request using > the control > >UDP port. It is important to note that the longevity of the > uniqueness > >characteristics of the UDP port is not very long (e.g., one > day after > >reboot). This is a new requirement on the WTP, but not unrealistic > >since > >802.11 APs have to do this for the RADIUS protocol today (to > maintain > >unique session identifiers). The AC does not flush its > current DTLS SA > >until the DTLS exchange is complete (and successful). > > > >WTP AC > >(WTP picks a new pseudo-random source port) > >----- CAPWAP Control/Discovery Request (772, 1233) ------> > ><---- CAPWAP Control/Discovery Response (1233, 772) ------ > > > >Using Scott's recommendation to look at the WBID, which when > set to any > > >value other than 23 (which we will need to reserve), then we > know this > >packet is a discovery request, and process it accordingly. > > > >--------- DTLS Session Setup/Control (772, 1233) --------> > ><-------- DTLS Session Setup/Control (1233, 772) --------- > > > >The WBID value of 23 will be an indication that the DTLS session is > >being established... at this point all packets are from now > on fed into > > >the DTLS engine. > > > >If NAT is used, it is possible that the WTP's source IP > address is used > > >for multiple WTPs. In this case, the AC can identify each > WTP using the > > >DTLS credentials. The AC can then delete the old DTLS SAs > (control and > >optionally data), that are associated with the WTP's credentials. > >Alternatively, the AC could simply wait for the sessions to expire. > > > > > >Pat Calhoun > >CTO, Wireless Networking Business Unit > >Cisco Systems > > > > > > > > > >________________________________ > > > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > Sent: Tuesday, October 17, 2006 10:08 AM > > To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro > > Cc: capwap@frascone.com > > Subject: need clarification on UDP ports > > > > > > Pat, Mike, Dorothy: > > > > I have a question based on v03 of the capwap spec. > > In section 3.1, the spec mentions well-known UDP > > ports for the CAPWAP control and data packets. > > > > There are four kinds of CAPWAP packets: > > 1. DTLS protected control packets > > 2. Unprotected control packets > > 3. Unprotected data packets > > 4. (Optional) DTLS protected data packets > > > > Will there be 4 well-known UDP port numbers ? > > > > 1, 2 and 3 will be present simultaneously in any > > deployment. 3 and 4 may co-exist in a deployment > > if some data channels are encrypted and some not. > > There has to be a way to distinguish these four > > kinds of packets. The draft is not clear about how > > this is done. > > > > Thanks, > > Abhijit > > > > > >_________________________________________________________________ > >To unsubscribe or modify your subscription options, please visit: > >http://lists.frascone.com/mailman/listinfo/capwap > > > >Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 15:05:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GazgA-0007ev-4t for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 15:05:14 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gazg7-0001BC-GK for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 15:05:14 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id F1FCA1448036 for ; Fri, 20 Oct 2006 12:05:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 26D6B4A43C6 for ; Fri, 20 Oct 2006 12:04:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C8E77398040 for ; Fri, 20 Oct 2006 12:04:45 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by zoidberg.tigertech.net (Postfix) with ESMTP id 571A2398008 for ; Fri, 20 Oct 2006 12:04:42 -0700 (PDT) Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gazfd-0004oN-Gy; Fri, 20 Oct 2006 15:04:41 -0400 Received: from 75.6.46.166 by webmail.pas.earthlink.net with HTTP; Fri, 20 Oct 2006 15:04:41 -0400 Message-ID: <27382538.1161371081529.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net> Date: Fri, 20 Oct 2006 12:04:41 -0700 (GMT-07:00) From: "Scott G. Kelly" To: pagarwal@broadcom.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710668630575d3ed05324cf65e06b1a8b4c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.47 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 > It seems that we (capwap) are one of the first folks trying > to use DTLS. > It would be good to know how other folks (if any) have used DTLS for > their applications. If someone has already solved the "discovery to > dtls-secure" like problem before, then it would be good to understand > how they did it and maybe use a similar approach (rather than > re-invent > the wheel). In that regard, does anyone know of other groups > using dtls > to secure their protocol? There are currently drafts active for using DTLS with syslog, SDP, and DCCP. Also, TLS has been used with many protocols, and we can certainly look there for inspiration. In general, there are two models. In the first, a given port is considered (D)TLS-only. In the other, the application somehow signals it's desire to convert the session to (D)TLS. For example, some applications support a "STARTTLS" directive, and for secure syslog a client might send the string "AUTH TLS CLIENT", to which the server will reply OK or ERROR. In general, once (D)TLS is on, no unprotected packets are allowed. > Would having 3 UDP ports solve the problem: > (a) capwap-open control port : All unencrypted capwap control > packets go > on this channel > (b) capwap-open data port : All unencrypted capwap data packets go on > this channel > (b) capwap-secure port: All dtls encrypted capwap data/control packets > go on this channel. Demux for data vs control happens after > decryption. > > We may need more ports if we need to support different QoS levels (as > pointed by Scott)- that to me is a bigger problem. Wondering what the > group thinks.... I've been re-thinking my position on this, given that the working group is committed to a multiport approach. Certainly there are multiple ways to solve this, and while I would prefer a solution that didn't involve adding yet more ports, we are where we are. That said, I think adding a 3rd port which is only used for discovery operations solves part of the problem. In that case, the control channel is always DTLS traffic, and we have an unambiguous solution which requires no protocol hacks. As for the data channel, it's a little more complex. If hardware vendors must know a priori whether data is protected or not, the only options are either two data ports or a type header, and given the dramatic allergic reactions we've seen to protocol layering beyond the udp header here, distinct ports seem to be the only option on the table. However, if hardware vendors support tuple-plumbing, we can do this with one data port. Tuple-plumbing solves the problem by letting the application tell the hardware when a session is protected or not, but you have to look at the source port too. This is part of the problem some of Pat's signalling is meant to solve. Once the AC knows what characteristics a given tuple should have, this can be plumbed into the hardare. This still leaves two problems: associating a NAT'd data channel with the appropriate control channel, and the QoS problem for the data channel. The channel association can be solved by using the session ID, as has been noted numerous times in past threads. One way this could be extended to encompass multiple data channels would be to extend the session ID field, and treat the high-order portion as the session id, and the low-order portion as the channel id (control channel has channel id 0, data channel with no QoS has channel id 1, and so on). Just a thought. Since there will be initial ambiguity when multiple WTPs are behind a NAT, there are two options: 1) don't worry about it; let the WTP establish a DTLS session without knowing which control channel it belongs to, and then get the session binding out of the first protected data packet (which may be an echo) to create the binding; if no packets come within some preset interval, tear down the DTLS session. 2) do some inline signalling, as Pat suggested. This could be via a capwap header with some special value, or it could be the text STARTDTLS along with the session/channel id - whatever. I think, based on the above, that a 3-port solution exists - but this depends on what is workable for the hardware vendors. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 16:10:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb0h6-0003Qz-1b for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 16:10:16 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb0gX-0004UR-Tx for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 16:10:16 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id D54E53980A5 for ; Fri, 20 Oct 2006 13:01:12 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id E6F724A43C6 for ; Fri, 20 Oct 2006 13:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C0191144801C for ; Fri, 20 Oct 2006 13:00:56 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id 910531448010 for ; Fri, 20 Oct 2006 13:00:54 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id m18so1028577nfc for ; Fri, 20 Oct 2006 13:00:53 -0700 (PDT) Received: by 10.82.98.13 with SMTP id v13mr805920bub; Fri, 20 Oct 2006 13:00:52 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Fri, 20 Oct 2006 13:00:52 -0700 (PDT) Message-ID: <369e612f0610201300l2531529di8451d90167b123e6@mail.gmail.com> Date: Sat, 21 Oct 2006 01:30:52 +0530 From: "Navin (NKA)" To: "Scott G. Kelly" In-Reply-To: <8965479.1161295883589.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Disposition: inline References: <8965479.1161295883589.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On 10/20/06, Scott G. Kelly wrote: > >[NKA] Scott, so you agree that the logic which I have explained for handling > >discovery/DTLS packets is correct, but you feel that it would result in slower > >synchronization between WTP and AC FSM? > > Actually, no, I don't agree. A discovery packet should be deterministically treated as a discovery packet - not sometimes erroneously treated as a dtls packet. I think introducing this ambiguity is unnecessary, to say the least. [NKA] Scott, now you are not agreeing to what you said in youre previous email. Look at the snippet of the same. ----------------------------------------------------------------------------------------------------------------- >[NKA] Even if a less-robust AC implementation ends up interpreting DTLS >message as a Discovery packet, do you think WTP (which unfortunately >has passed discovery state) will be able to carry on with its DTLS >session establishment and succeed ultimately? :-( I don't think so. (Imagine >this: WTP needs to successfully interpret Discovery response as HelloVerify >request, followed by which AC needs to interpret ClientHello (with cookie) as >Client Hello without Cookie, and so on). That's not the point, and this is minor compared to the real issue, which is below * * * In this case the WTP will often need to go through discovery again before reconnecting to the AC. If the AC erroneously feeds these packets to its DTLS implementation, they will be rejected, and the WTP will get no response. This means failure recovery will not occur until the AC times out its DTLS session, and since these timeouts are frequently set as high as 30 seconds in the field, and since the WTP may exhaust its discovery timers and go into sulking state due to AC unresponsiveness, this has the potential to signficantly (and unfortunately, completely avoidably) exacerbate the outage. ----------------------------------------------------------------------------------------------------------------- [NKA] My point is that seperate discovery packet processing via a special port is a bad idea. And it doesn't bring any additional value than what can be achieved without special port approach. Scott's additional reasoning that two port approach would open up scope for DOS atack. I totally disagree with the argument. I claim that the same risk exists even with 3-port approach also. > > I think Abhijit's point is correct: it should be very clear whether a packet is control, data, discovery, and protected vs unprotected. Either we can do that by using more ports, or we can find another way. But I don't think shoving a discovery packet into the dtls engine is "a good thing". > > Scott > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 16:39:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb19C-0002oB-15 for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 16:39:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb198-0003ee-FF for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 16:39:18 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id C1A8F3980A3 for ; Fri, 20 Oct 2006 13:39:13 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 8AD654A45AC for ; Fri, 20 Oct 2006 13:39:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 62B34398070 for ; Fri, 20 Oct 2006 13:39:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6E42C398040 for ; Fri, 20 Oct 2006 13:38:57 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2006 13:38:58 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9KKcumF014130 for ; Fri, 20 Oct 2006 13:38:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9KKcuip005486 for ; Fri, 20 Oct 2006 13:38:56 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 13:38:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Oct 2006 13:38:55 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC0232246F@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CAPWAP Timer element issue Thread-Index: Acb0h8LbID2mUdDPSw2/a22E0D8uaA== From: "Bob O'Hara (boohara)" To: X-OriginalArrivalTime: 20 Oct 2006 20:38:56.0585 (UTC) FILETIME=[C396F390:01C6F487] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] CAPWAP Timer element issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 In 4.4.12 of the -03 draft, the Discovery Timer and Echo Timer fields are defined. The value of the field determines the number of seconds between the two types of Request packets. What does a value of zero mean in this field? For the Echo Timer, I would propose that a value of zero be defined to mean that no Echo Request packets are sent. For the Discovery Timer, I would propose that a value of zero be reserved and, if received by a WTP, is interpreted to be the same as if the value of 1 was received. -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Oct 20 17:54:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb2KK-0000s6-8r for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 17:54:52 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb2KG-0008HN-Hn for capwap-archive@lists.ietf.org; Fri, 20 Oct 2006 17:54:52 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9B5143980A5 for ; Fri, 20 Oct 2006 14:54:33 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 7B8874A45AC for ; Fri, 20 Oct 2006 14:54:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2FC1B144801C for ; Fri, 20 Oct 2006 14:54:20 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by hermes.tigertech.net (Postfix) with ESMTP id ABD741448014 for ; Fri, 20 Oct 2006 14:54:19 -0700 (PDT) Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gb2Jm-00029c-QO; Fri, 20 Oct 2006 17:54:18 -0400 Received: from 75.6.46.166 by webmail.pas.earthlink.net with HTTP; Fri, 20 Oct 2006 17:54:17 -0400 Message-ID: <389468.1161381258661.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Fri, 20 Oct 2006 14:54:18 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Navin (NKA)" Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71065512331407a6004389c573f2d1659e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi Navin, -----Original Message----- >From: "Navin (NKA)" >Sent: Oct 20, 2006 1:00 PM >To: "Scott G. Kelly" >Cc: capwap@frascone.com >Subject: Re: [Capwap] need clarification on UDP ports > >On 10/20/06, Scott G. Kelly wrote: >> >[NKA] Scott, so you agree that the logic which I have explained for handling >> >discovery/DTLS packets is correct, but you feel that it would result in slower >> >synchronization between WTP and AC FSM? >> >> Actually, no, I don't agree. A discovery packet should be deterministically treated as a discovery packet - not sometimes erroneously treated as a dtls packet. I think introducing this ambiguity is unnecessary, to say the least. > >[NKA] Scott, now you are not agreeing to what you said in youre previous email. >Look at the snippet of the same. You know, even if I *had* changed my position -- that is allowed in the IETF. But in this case, I didn't. All along I've been disagreeing with the notion that ambiguity and non-deterministic handling of discovery messages is okay. I'm sorry if anything I've said was in any way confusing. >----------------------------------------------------------------------------------------------------------------- >>[NKA] Even if a less-robust AC implementation ends up interpreting DTLS >>message as a Discovery packet, do you think WTP (which unfortunately >>has passed discovery state) will be able to carry on with its DTLS >>session establishment and succeed ultimately? :-( I don't think so. (Imagine >>this: WTP needs to successfully interpret Discovery response as HelloVerify >>request, followed by which AC needs to interpret ClientHello (with cookie) as >>Client Hello without Cookie, and so on). > >That's not the point, and this is minor compared to the real issue, >which is below > * > * > * >In this case the WTP will often need to go through discovery again >before reconnecting to the AC. If the AC erroneously feeds these >packets to its DTLS implementation, they will be rejected, and the WTP >will get no response. This means failure recovery will not occur >until the AC times out its DTLS session, and since these timeouts are >frequently set as high as 30 seconds in the field, and since the WTP >may exhaust its discovery timers and go into sulking state due to AC >unresponsiveness, this has the potential to signficantly (and >unfortunately, completely avoidably) exacerbate the outage. >----------------------------------------------------------------------------------------------------------------- > >[NKA] My point is that seperate discovery packet processing via a special port >is a bad idea. And it doesn't bring any additional value than what can be >achieved without special port approach. Okay, so we know where you stand on this. >Scott's additional reasoning that two >port approach would open up scope for DOS atack. I totally disagree with >the argument. I claim that the same risk exists even with 3-port approach also. Sorry, don't agree with this. Here's what you suggested: >You may have a situation in which session information exists for a WTP at AC, >but WTP is sending non-DTLS packet. Even in such situation, AC can feed such >packets to DTLS module, which will ultimately reject the packet. AC can use >this kind of notification to tear down the existing session, which will bring AC's >state machine in sync with that of WTP. To paraphrase, if the AC receives a discovery packet that appears to be from a live WTP, the AC should tear down that WTP's session to sync with the WTP. To me (and maybe it's just me, because I'm so paranoid or something), that sounds an awful lot like an invitation to a DoS party. Go ahead and implement this, and I'll show you how it works :-) Now, as to whether that vulnerability also exists with 3 ports... well, I guess if you implement the way you described, then it does. But if it were my implementation, I wouldn't *ever* tear down a session based on the receipt of unauthenticated data. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 21 13:48:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbKwz-00062M-Ro for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 13:48:01 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbKwx-0007BU-CP for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 13:48:01 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id D0B9A4310FB for ; Sat, 21 Oct 2006 10:47:40 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id B6A9D4A45AB for ; Sat, 21 Oct 2006 10:47:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B4134310D3 for ; Sat, 21 Oct 2006 10:47:01 -0700 (PDT) X-Greylist-Status: Sender first seen 00:12:04 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 0D0834310E1 for ; Sat, 21 Oct 2006 10:46:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Oct 2006 10:34:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0klY4e+7UPnhTRf2FfrW+5OvmDgAo/i+s References: <389468.1161381258661.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> From: "Hasan Raza" To: "Scott G. Kelly" , , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, HTML_10_20, HTML_MESSAGE X-Spam-Level: Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0086336429==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 This is a multi-part message in MIME format. --===============0086336429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F537.379FABFD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F537.379FABFD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I think we are a bit closer than where we were earlier in terms of = resolving this issue. I agree with the points which Scott has raised. And I feel that there = are few DoS issues which have not been addressed properly in the capwap draft. = May be resolving those issues first might give us a solution for the = DTLS/Discovery packet identification issue (#224). To start with, we have to answer few questions: 1. How capwap is protected against discovery packet attacks? Even if = there is a port-based or mux-based soltuion for reliably identifying discovery = and DTLS packets, an attacker can send a discovery packet to the AC, which = may result in the tear down of the WTP session. This is because discovery = packets are un-authenticated packets, and are sent in plain. AC needs to blindly believe on the discovery packets. 2. If an AC employs actions again discovery packet attacks by discarding discovery packets if WTP session did not timeout, then an attacker may prevent the WTP joining back to the AC after a WTP crash. Attacker can = detect a sudden absence of echo request messages from WTP, and start replaying = the WTP echo request messages which causes AC not to teardown the WTP = session. And thus genuine discovery packets might be discarded by AC. May be I am = wrong here if DTLS can detect duplicate packets and discard them = automatically. To resolve the above issues, we can impose following rules on AC. For issue (1) above: RULE 1: (a) AC discards all discovery packets if an active WTP session exists = for the WTP. (b) A discovery packet from WTP can be accepted by AC only when there = does not exist any active session for that WTP. Whereas, if a discovery = packet is received if an active WTP session exists at AC, then all such = discovery packets are discarded without change or update of any of the AC = states. To resolve the second issue (if at all it exists):=20 RULE 2: AC should discard all duplicate DTLS and CAPWAP packets without change = or update of any of its states. RULE (1) above will impose a constant delay in the WTP re-joining. = Suppose a WTP crashes and comes up before WTP session at AC may timeout, all its discovery packets will be discarded by the WTP. But since AC won't be receiving any valid/authenticated packet which could refresh the WTP = session, the WTP session would timeout after _fixed_ amount of time. This _fixed_ amount of time is unfortunately not fixed since it can be changed administratively, by say updating echo interval at WTP or by changing = response timeout values at AC. To make the WTP re-joining faster, WTP may save the DTLS cookie on a persistent storage and (after a restart) presents the cookie to the AC = to restore the DTLS connection, and thus avoiding the discovery phase. This concept is same as the one presented in "Idle to Join (aa)" transition, except that here presenting a valid cookie resets the state to join = state, discarding any previous WTP state/stats maintained at AC. I _think_ that the above proposals will avoid discovery packet DoS = attacks, and there is no need to use separate ports or extra mux header after udp header to differentiate among the discovery and DTLS packets. Thanks Hasan -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Fri 10/20/2006 2:54 PM To: Navin (NKA) Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports =20 Hi Navin, -----Original Message----- >From: "Navin (NKA)" >Sent: Oct 20, 2006 1:00 PM >To: "Scott G. Kelly" >Cc: capwap@frascone.com >Subject: Re: [Capwap] need clarification on UDP ports > >On 10/20/06, Scott G. Kelly wrote: >> >[NKA] Scott, so you agree that the logic which I have explained for = handling >> >discovery/DTLS packets is correct, but you feel that it would result = in slower >> >synchronization between WTP and AC FSM? >> >> Actually, no, I don't agree. A discovery packet should be = deterministically treated as a discovery packet - not sometimes = erroneously treated as a dtls packet. I think introducing this ambiguity = is unnecessary, to say the least. > >[NKA] Scott, now you are not agreeing to what you said in youre = previous email. >Look at the snippet of the same. You know, even if I *had* changed my position -- that is allowed in the = IETF. But in this case, I didn't. All along I've been disagreeing with = the notion that ambiguity and non-deterministic handling of discovery = messages is okay. I'm sorry if anything I've said was in any way = confusing. >------------------------------------------------------------------------= ----------------------------------------- >>[NKA] Even if a less-robust AC implementation ends up interpreting = DTLS >>message as a Discovery packet, do you think WTP (which unfortunately >>has passed discovery state) will be able to carry on with its DTLS >>session establishment and succeed ultimately? :-( I don't think so. = (Imagine >>this: WTP needs to successfully interpret Discovery response as = HelloVerify >>request, followed by which AC needs to interpret ClientHello (with = cookie) as >>Client Hello without Cookie, and so on). > >That's not the point, and this is minor compared to the real issue, >which is below > * > * > * >In this case the WTP will often need to go through discovery again >before reconnecting to the AC. If the AC erroneously feeds these >packets to its DTLS implementation, they will be rejected, and the WTP >will get no response. This means failure recovery will not occur >until the AC times out its DTLS session, and since these timeouts are >frequently set as high as 30 seconds in the field, and since the WTP >may exhaust its discovery timers and go into sulking state due to AC >unresponsiveness, this has the potential to signficantly (and >unfortunately, completely avoidably) exacerbate the outage. >------------------------------------------------------------------------= ----------------------------------------- > >[NKA] My point is that seperate discovery packet processing via a = special port >is a bad idea. And it doesn't bring any additional value than what can = be >achieved without special port approach.=20 Okay, so we know where you stand on this. >Scott's additional reasoning that two >port approach would open up scope for DOS atack. I totally disagree = with >the argument. I claim that the same risk exists even with 3-port = approach also. Sorry, don't agree with this. Here's what you suggested: >You may have a situation in which session information exists for a WTP = at AC, >but WTP is sending non-DTLS packet. Even in such situation, AC can feed = such >packets to DTLS module, which will ultimately reject the packet. AC can = use >this kind of notification to tear down the existing session, which will = bring AC's >state machine in sync with that of WTP. To paraphrase, if the AC receives a discovery packet that appears to be = from a live WTP, the AC should tear down that WTP's session to sync with = the WTP. To me (and maybe it's just me, because I'm so paranoid or something), = that sounds an awful lot like an invitation to a DoS party. Go ahead and = implement this, and I'll show you how it works :-) Now, as to whether that vulnerability also exists with 3 ports... well, = I guess if you implement the way you described, then it does. But if it = were my implementation, I wouldn't *ever* tear down a session based on = the receipt of unauthenticated data. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6F537.379FABFD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports

Hi,

I think we are a bit closer than where we were earlier in terms of = resolving
this issue.

I agree with the points which Scott has raised. And I feel that there = are few
DoS issues which have not been addressed properly in the capwap draft. = May be
resolving those issues first might give us a solution for the = DTLS/Discovery
packet identification issue (#224).

To start with, we have to answer few questions:
1. How capwap is protected against discovery packet attacks? Even if = there
is a port-based or mux-based soltuion for reliably identifying discovery = and
DTLS packets, an attacker can send a discovery packet to the AC, which = may
result in the tear down of the WTP session. This is because discovery = packets
are un-authenticated packets, and are sent in plain. AC needs to = blindly
believe on the discovery packets.

2. If an AC employs actions again discovery packet attacks by = discarding
discovery packets if WTP session did not timeout, then an attacker = may
prevent the WTP joining back to the AC after a WTP crash. Attacker can = detect
a sudden absence of echo request messages from WTP, and start replaying = the
WTP echo request messages which causes AC not to teardown the WTP = session.
And thus genuine discovery packets might be discarded by AC. May be I am = wrong
here if DTLS can detect duplicate packets and discard them = automatically.


To resolve the above issues, we can impose following rules on AC.

For issue (1) above:
RULE 1:
  (a) AC discards all discovery packets if an active WTP session = exists for the
  WTP.
  (b) A discovery packet from WTP can be accepted by AC only when = there does
  not exist any active session for that WTP. Whereas, if a = discovery packet is
  received if an active WTP session exists at AC, then all such = discovery
  packets are discarded without change or update of any of the AC = states.

To resolve the second issue (if at all it exists):
RULE 2:
  AC should discard all duplicate DTLS and CAPWAP packets without = change or
  update of any of its states.


RULE (1) above will impose a constant delay in the WTP re-joining. = Suppose a
WTP crashes and comes up before WTP session at AC may timeout, all = its
discovery packets will be discarded by the WTP. But since AC won't = be
receiving any valid/authenticated packet which could refresh the WTP = session,
the WTP session would timeout after _fixed_ amount of time. This = _fixed_
amount of time is unfortunately not fixed since it can be changed
administratively, by say updating echo interval at WTP or by changing = response
timeout values at AC.

To make the WTP re-joining faster, WTP may save the DTLS cookie on a
persistent storage and (after a restart) presents the cookie to the AC = to
restore the DTLS connection, and thus avoiding the discovery phase. = This
concept is same as the one presented in "Idle to Join (aa)" = transition,
except that here presenting a valid cookie resets the state to join = state,
discarding any previous WTP state/stats maintained at AC.


I _think_ that the above proposals will avoid discovery packet DoS = attacks,
and there is no need to use separate ports or extra mux header after = udp
header to differentiate among the discovery and DTLS packets.



Thanks
Hasan



-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Fri 10/20/2006 2:54 PM
To: Navin (NKA)
Cc: capwap@frascone.com
Subject: Re: [Capwap] need clarification on UDP ports

Hi Navin,

-----Original Message-----
>From: "Navin (NKA)" <nka.capwap@gmail.com>
>Sent: Oct 20, 2006 1:00 PM
>To: "Scott G. Kelly" <scott@hyperthought.com>
>Cc: capwap@frascone.com
>Subject: Re: [Capwap] need clarification on UDP ports
>
>On 10/20/06, Scott G. Kelly <s.kelly@ix.netcom.com> wrote:
>> >[NKA] Scott, so you agree that the logic which I have = explained for handling
>> >discovery/DTLS packets is correct, but you feel that it = would result in slower
>> >synchronization between WTP and AC FSM?
>>
>> Actually, no, I don't agree. A discovery packet should be = deterministically treated as a discovery packet - not sometimes = erroneously treated as a dtls packet. I think introducing this ambiguity = is unnecessary, to say the least.
>
>[NKA] Scott, now you are not agreeing to what you said in youre = previous email.
>Look at the snippet of the same.

You know, even if I *had* changed my position -- that is allowed in the = IETF. But in this case, I didn't. All along I've been disagreeing with = the notion that ambiguity and non-deterministic handling of discovery = messages is okay. I'm sorry if anything I've said was in any way = confusing.

>---------------------------------------------------------------------= --------------------------------------------
>>[NKA] Even if a less-robust AC implementation ends up = interpreting DTLS
>>message as a Discovery packet, do you think WTP (which = unfortunately
>>has passed discovery state) will be able to carry on with its = DTLS
>>session establishment and succeed ultimately? :-( I don't think = so.  (Imagine
>>this: WTP needs to successfully interpret Discovery response as = HelloVerify
>>request, followed by which AC needs to interpret ClientHello = (with cookie) as
>>Client Hello without Cookie, and so on).
>
>That's not the point, and this is minor compared to the real = issue,
>which is below
>           &nb= sp;    *
>           &nb= sp;    *
>           &nb= sp;    *
>In this case the WTP will often need to go through discovery = again
>before reconnecting to the AC. If the AC erroneously feeds these
>packets to its DTLS implementation, they will be rejected, and the = WTP
>will get no response.  This means failure recovery will not = occur
>until the AC times out its DTLS session, and since these timeouts = are
>frequently set as high as 30 seconds in the field,  and since = the WTP
>may exhaust its discovery timers and go into sulking state due to = AC
>unresponsiveness, this has the potential to signficantly (and
>unfortunately, completely avoidably) exacerbate the outage.
>---------------------------------------------------------------------= --------------------------------------------
>
>[NKA] My point is that seperate discovery packet processing via a = special port
>is a bad idea. And it doesn't bring any additional value than what = can be
>achieved without special port approach.


Okay, so we know where you stand on this.


>Scott's additional reasoning that two
>port approach would open up scope for DOS atack. I totally disagree = with
>the argument. I claim that the same risk exists even with 3-port = approach also.


Sorry, don't agree with this. Here's what you suggested:

>You may have a situation in which session information exists for a = WTP at AC,
>but WTP is sending non-DTLS packet. Even in such situation, AC can = feed such
>packets to DTLS module, which will ultimately reject the packet. AC = can use
>this kind of notification to tear down the existing session, which = will bring AC's
>state machine in sync with that of WTP.

To paraphrase, if the AC receives a discovery packet that appears to be = from a live WTP, the AC should tear down that WTP's session to sync with = the WTP.

To me (and maybe it's just me, because I'm so paranoid or something), = that sounds an awful lot like an invitation to a DoS party. Go ahead and = implement this, and I'll show you how it works :-)

Now, as to whether that vulnerability also exists with 3 ports... well, = I guess if you implement the way you described, then it does. But if it = were my implementation, I wouldn't *ever* tear down a session based on = the receipt of unauthenticated data.

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone= .com/pipermail/capwap

------_=_NextPart_001_01C6F537.379FABFD-- --===============0086336429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0086336429==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 21 15:02:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbM7W-0004Hk-R0 for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 15:02:58 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbM7V-0001U8-0u for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 15:02:58 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 817FD431231 for ; Sat, 21 Oct 2006 12:02:52 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 3855C4A45AB for ; Sat, 21 Oct 2006 12:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0DCC5431215 for ; Sat, 21 Oct 2006 12:02:36 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [216.148.227.153]) by hermes.tigertech.net (Postfix) with ESMTP id 3B3FD431211 for ; Sat, 21 Oct 2006 12:02:32 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc13) with ESMTP id <20061021190231m1300m3e7ge>; Sat, 21 Oct 2006 19:02:32 +0000 Message-ID: <453A6EC7.9030208@hyperthought.com> Date: Sat, 21 Oct 2006 12:02:31 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Puneet Agarwal References: <8954613CA6BB3242A1531D916A527A41020A2F15@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <8954613CA6BB3242A1531D916A527A41020A2F15@NT-SJCA-0751.brcm.ad.broadcom.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap@frascone.com, Abhijit Choudhury Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Puneet, I forgot to address one point below: Puneet Agarwal wrote: > I agree with Scott - it is important that we come up with a solution > that is unambiguous and works even if packet formats for dtls change. > > It seems that we (capwap) are one of the first folks trying to use DTLS. > It would be good to know how other folks (if any) have used DTLS for > their applications. If someone has already solved the "discovery to > dtls-secure" like problem before, then it would be good to understand > how they did it and maybe use a similar approach (rather than re-invent > the wheel). In that regard, does anyone know of other groups using dtls > to secure their protocol? > > Would having 3 UDP ports solve the problem: > (a) capwap-open control port : All unencrypted capwap control packets go > on this channel > (b) capwap-open data port : All unencrypted capwap data packets go on > this channel > (b) capwap-secure port: All dtls encrypted capwap data/control packets > go on this channel. Demux for data vs control happens after decryption. Combining secure data and control in one DTLS channel may potentially have problems when you have different QoS levels for control vs data. I think you could get away with it in some cases, but not in others. It's probably simplest to just disallow it. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 21 15:31:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZU-0004Te-2a for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 15:31:52 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbMSy-0004g7-FV for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 15:25:10 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id BEA053980C2 for ; Sat, 21 Oct 2006 12:25:07 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 0E2F14A43C6 for ; Sat, 21 Oct 2006 12:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EFBF4398064 for ; Sat, 21 Oct 2006 12:24:56 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0442539802E for ; Sat, 21 Oct 2006 12:24:53 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc11) with ESMTP id <20061021192452m1100rroe3e>; Sat, 21 Oct 2006 19:24:53 +0000 Message-ID: <453A7404.3070104@hyperthought.com> Date: Sat, 21 Oct 2006 12:24:52 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Hasan Raza References: <389468.1161381258661.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Hi Hasan, Hasan Raza wrote: > Hi, > > I think we are a bit closer than where we were earlier in terms of resolving > this issue. > > I agree with the points which Scott has raised. And I feel that there are few > DoS issues which have not been addressed properly in the capwap draft. May be > resolving those issues first might give us a solution for the DTLS/Discovery > packet identification issue (#224). > > To start with, we have to answer few questions: > 1. How capwap is protected against discovery packet attacks? Even if there > is a port-based or mux-based soltuion for reliably identifying discovery and > DTLS packets, an attacker can send a discovery packet to the AC, which may > result in the tear down of the WTP session. This is because discovery packets > are un-authenticated packets, and are sent in plain. AC needs to blindly > believe on the discovery packets. Actually, I don't think this is necessarily the case. Since discovery packets are unauthenticated, the AC should *never* act on them (other than to send a discovery response). The draft currently states that the AC should not maintain state when it receives a discovery request (for this very reason), but we should probably add text noting that it should not modify existing state, either. > 2. If an AC employs actions again discovery packet attacks by discarding > discovery packets if WTP session did not timeout, then an attacker may > prevent the WTP joining back to the AC after a WTP crash. Attacker can detect > a sudden absence of echo request messages from WTP, and start replaying the > WTP echo request messages which causes AC not to teardown the WTP session. > And thus genuine discovery packets might be discarded by AC. May be I am wrong > here if DTLS can detect duplicate packets and discard them automatically. Yes, DTLS provides antireplay detection. I inaccurately said in an earlier email that this is compulsory for DTLS - what I should have said is that it is compulsory for CAPWAP (it's optional in DTLS). > To resolve the above issues, we can impose following rules on AC. > > For issue (1) above: > RULE 1: > (a) AC discards all discovery packets if an active WTP session exists for the > WTP. > (b) A discovery packet from WTP can be accepted by AC only when there does > not exist any active session for that WTP. Whereas, if a discovery packet is > received if an active WTP session exists at AC, then all such discovery > packets are discarded without change or update of any of the AC states. I think it's okay for the AC to respond, but it should not tear down an existing association. It should only do this once the WTP re-joins (and re-authenticates in the process). I'll think about better language for the security considerations and the discovery processing. > To resolve the second issue (if at all it exists): > RULE 2: > AC should discard all duplicate DTLS and CAPWAP packets without change or > update of any of its states. Maybe we need better language on this as well. The AC should be keeping statistics relating to such events, at minimum. > RULE (1) above will impose a constant delay in the WTP re-joining. Suppose a > WTP crashes and comes up before WTP session at AC may timeout, all its > discovery packets will be discarded by the WTP. But since AC won't be > receiving any valid/authenticated packet which could refresh the WTP session, > the WTP session would timeout after _fixed_ amount of time. This _fixed_ > amount of time is unfortunately not fixed since it can be changed > administratively, by say updating echo interval at WTP or by changing response > timeout values at AC. As noted above, re-joining is independent of discovery operations - a WTP should be able to initiate a new DTLS handshake even though a session currently exists, but there are subtle nuances to this (need rate limiting, need to detect DoS attempts via many half-open sessions, etc). I will work on text for this. The only way an existing session should be torn down is via timeout, or via a yet-to-be-defined directive received through another authenticated channel with the same WTP. > To make the WTP re-joining faster, WTP may save the DTLS cookie on a > persistent storage and (after a restart) presents the cookie to the AC to > restore the DTLS connection, and thus avoiding the discovery phase. This > concept is same as the one presented in "Idle to Join (aa)" transition, > except that here presenting a valid cookie resets the state to join state, > discarding any previous WTP state/stats maintained at AC. I agree DTLS session resumption is something we should think about, but honestly, I haven't given it much thought yet. We need to think carefully about this, though. But here's an important point: discovery is optional - it is not required in order to initiate a dtls handshake. > I _think_ that the above proposals will avoid discovery packet DoS attacks, > and there is no need to use separate ports or extra mux header after udp > header to differentiate among the discovery and DTLS packets. Think this through again in light of my comments above. I still believe that erroneously pushing a discovery packet into the dtls engine (and re-testing all failed dtls packets to see if they are discovery) is bad form, a hack we don't need to allow, and a potential DoS avenue (if dtls is handled in hardware but discovery is handled by the control processor, then you can stuff the channel between the hw and cp with bogus packets, keeping both busy, and maybe causing real packets to be discarded in the process). There are at least two options on the table for avoiding it (a separate discovery port or a type value just after the UDP header). Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Oct 21 22:23:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbSzS-00063I-Ik for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 22:23:06 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbSzQ-00056A-EE for capwap-archive@lists.ietf.org; Sat, 21 Oct 2006 22:23:06 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7D65F398076 for ; Sat, 21 Oct 2006 19:22:55 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 5C25E4A45D1 for ; Sat, 21 Oct 2006 19:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 332C4144801C for ; Sat, 21 Oct 2006 19:22:40 -0700 (PDT) X-Greylist-Status: Sender first seen 08:47:43 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id F03321448006 for ; Sat, 21 Oct 2006 19:22:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 21 Oct 2006 19:22:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb1RpauiT/LffrdRwW/cAXmYTaaHQANuEqH References: <389468.1161381258661.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <453A7404.3070104@hyperthought.com> From: "Hasan Raza" To: "Scott G Kelly" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.3 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, HTML_10_20, HTML_MESSAGE X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0954102872==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 This is a multi-part message in MIME format. --===============0954102872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F580.F16182C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F580.F16182C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Scott, I am sorry that I missed the point that discovery packets do not result in any state change at AC. Actually, the DoS issues I raised were the outcomes of the wrong assumption that discovery packets change the AC state. Of course, differentiation of discovery/DTLS packet by looking at the wtp session would be a bad design, I beleive. However, I can think of two other ways to make the distinction among discovery/DTLS packets. These solutions (if they work) would be less costlier than extra port or mux-based solutions: 1. Checksum at the end of discovery packets: All incoming packets are checked for _discovery-like_ packets by looking at the head bytes (as Pat proposed in this thread). If the packet looks like to be a discovery packet, then it is submitted for checksum calculation. The calculated checksum is compared with the last 4 bytes of the packet, and a match of the two would mark the packet as discovery packet. Otherwise, packet is submitted to DTLS module. Drawbacks: - extra processing at AC for false positives. - overhead of checksum calculation for discovery packets at WTP/AC. Limitations: - The mechanism to identify _discovery-like_ packets will affect the false positives and thus packet processing performance. 2. Reserved length for discovery packets: All discovery request packets sent by WTP are of size L (say 240 bytes). Padding is added to the discovery packets to make it of exact size L. In case a DTLS packet to be sent to AC is of size L, then a (new) pad message element is added to increase the packet length. Limitations: - Selection of size L is critical. Note that DTLS layer may also = send handshake packets of size L. If DTLS handshake packets does not following any lower/upper bound on packet length, or packet = length alignment, then this scheme will not work. Otherwise, a very = short lengthed marker message (of say 4 bytes) can also be used to = mark the packet following it as discovery packet. The latter solution looks like to be more of a hack, but I have put here to give it also a thought. However, a combination of (1) and (2) may work. Thanks Hasan -----Original Message----- From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Sat 10/21/2006 12:24 PM To: Hasan Raza Cc: capwap@frascone.com; pcalhoun@cisco.com Subject: Re: [Capwap] need clarification on UDP ports =20 Hi Hasan, Hasan Raza wrote: > Hi, >=20 > I think we are a bit closer than where we were earlier in terms of = resolving > this issue. >=20 > I agree with the points which Scott has raised. And I feel that there = are few > DoS issues which have not been addressed properly in the capwap draft. = May be > resolving those issues first might give us a solution for the = DTLS/Discovery > packet identification issue (#224). >=20 > To start with, we have to answer few questions: > 1. How capwap is protected against discovery packet attacks? Even if = there > is a port-based or mux-based soltuion for reliably identifying = discovery and > DTLS packets, an attacker can send a discovery packet to the AC, which = may > result in the tear down of the WTP session. This is because discovery = packets > are un-authenticated packets, and are sent in plain. AC needs to = blindly > believe on the discovery packets. Actually, I don't think this is necessarily the case. Since discovery=20 packets are unauthenticated, the AC should *never* act on them (other=20 than to send a discovery response). The draft currently states that the=20 AC should not maintain state when it receives a discovery request (for=20 this very reason), but we should probably add text noting that it should = not modify existing state, either. > 2. If an AC employs actions again discovery packet attacks by = discarding > discovery packets if WTP session did not timeout, then an attacker may > prevent the WTP joining back to the AC after a WTP crash. Attacker can = detect > a sudden absence of echo request messages from WTP, and start = replaying the > WTP echo request messages which causes AC not to teardown the WTP = session. > And thus genuine discovery packets might be discarded by AC. May be I = am wrong > here if DTLS can detect duplicate packets and discard them = automatically. Yes, DTLS provides antireplay detection. I inaccurately said in an=20 earlier email that this is compulsory for DTLS - what I should have said = is that it is compulsory for CAPWAP (it's optional in DTLS). > To resolve the above issues, we can impose following rules on AC. >=20 > For issue (1) above: > RULE 1: > (a) AC discards all discovery packets if an active WTP session = exists for the > WTP. > (b) A discovery packet from WTP can be accepted by AC only when = there does > not exist any active session for that WTP. Whereas, if a discovery = packet is > received if an active WTP session exists at AC, then all such = discovery > packets are discarded without change or update of any of the AC = states. I think it's okay for the AC to respond, but it should not tear down an=20 existing association. It should only do this once the WTP re-joins (and=20 re-authenticates in the process). I'll think about better language for=20 the security considerations and the discovery processing. > To resolve the second issue (if at all it exists):=20 > RULE 2: > AC should discard all duplicate DTLS and CAPWAP packets without = change or > update of any of its states. Maybe we need better language on this as well. The AC should be keeping=20 statistics relating to such events, at minimum. > RULE (1) above will impose a constant delay in the WTP re-joining. = Suppose a > WTP crashes and comes up before WTP session at AC may timeout, all its > discovery packets will be discarded by the WTP. But since AC won't be > receiving any valid/authenticated packet which could refresh the WTP = session, > the WTP session would timeout after _fixed_ amount of time. This = _fixed_ > amount of time is unfortunately not fixed since it can be changed > administratively, by say updating echo interval at WTP or by changing = response > timeout values at AC. As noted above, re-joining is independent of discovery operations - a=20 WTP should be able to initiate a new DTLS handshake even though a=20 session currently exists, but there are subtle nuances to this (need=20 rate limiting, need to detect DoS attempts via many half-open sessions,=20 etc). I will work on text for this. The only way an existing session=20 should be torn down is via timeout, or via a yet-to-be-defined directive = received through another authenticated channel with the same WTP. > To make the WTP re-joining faster, WTP may save the DTLS cookie on a > persistent storage and (after a restart) presents the cookie to the AC = to > restore the DTLS connection, and thus avoiding the discovery phase. = This > concept is same as the one presented in "Idle to Join (aa)" = transition, > except that here presenting a valid cookie resets the state to join = state, > discarding any previous WTP state/stats maintained at AC. I agree DTLS session resumption is something we should think about, but=20 honestly, I haven't given it much thought yet. We need to think=20 carefully about this, though. But here's an important point: discovery=20 is optional - it is not required in order to initiate a dtls handshake. > I _think_ that the above proposals will avoid discovery packet DoS = attacks, > and there is no need to use separate ports or extra mux header after = udp > header to differentiate among the discovery and DTLS packets. Think this through again in light of my comments above. I still believe=20 that erroneously pushing a discovery packet into the dtls engine (and=20 re-testing all failed dtls packets to see if they are discovery) is bad=20 form, a hack we don't need to allow, and a potential DoS avenue (if dtls = is handled in hardware but discovery is handled by the control=20 processor, then you can stuff the channel between the hw and cp with=20 bogus packets, keeping both busy, and maybe causing real packets to be=20 discarded in the process). There are at least two options on the table for avoiding it (a separate=20 discovery port or a type value just after the UDP header). Scott ------_=_NextPart_001_01C6F580.F16182C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports

Hi Scott,

I am sorry that I missed the point that discovery packets
do not result in any state change at AC. Actually, the DoS
issues I raised were the outcomes of the wrong assumption
that discovery packets change the AC state. Of course,
differentiation of discovery/DTLS packet by looking at the
wtp session would be a bad design, I beleive.

However, I can think of two other ways to make the distinction
among discovery/DTLS packets. These solutions (if they work)
would be less costlier than extra port or mux-based solutions:

1. Checksum at the end of discovery packets:
   All incoming packets are checked for _discovery-like_ = packets
   by looking at the head bytes (as Pat proposed in this = thread).
   If the packet looks like to be a discovery packet, then = it
   is submitted for checksum calculation. The calculated = checksum
   is compared with the last 4 bytes of the packet, and a = match of
   the two would mark the packet as discovery packet. = Otherwise,
   packet is submitted to DTLS module.

   Drawbacks:
     - extra processing at AC for false = positives.
     - overhead of checksum calculation for = discovery packets at
       WTP/AC.
   Limitations:
     - The mechanism to identify _discovery-like_ = packets will affect
       the false positives and thus packet = processing performance.

2. Reserved length for discovery packets:
   All discovery request packets sent by WTP are of size L = (say 240
   bytes). Padding is added to the discovery packets to make = it of
   exact size L. In case a DTLS packet to be sent to AC is of = size L,
   then a (new) pad message element is added to increase the = packet
   length.

   Limitations:
      - Selection of size L is critical. Note = that DTLS layer may also send
        handshake packets of size L. = If DTLS handshake packets does not
        following any lower/upper = bound on packet length, or packet length
        alignment, then this scheme = will not work. Otherwise, a very short
        lengthed marker message (of = say 4 bytes) can also be used to mark the
        packet following it as = discovery packet.

The latter solution looks like to be more of a hack, but I have put = here
to give it also a thought. However, a combination of (1) and (2) may
work.

Thanks
Hasan


-----Original Message-----
From: Scott G Kelly [mailto:scott@hyperthought.com]=
Sent: Sat 10/21/2006 12:24 PM
To: Hasan Raza
Cc: capwap@frascone.com; pcalhoun@cisco.com
Subject: Re: [Capwap] need clarification on UDP ports

Hi Hasan,

Hasan Raza wrote:
> Hi,
>
> I think we are a bit closer than where we were earlier in terms of = resolving
> this issue.
>
> I agree with the points which Scott has raised. And I feel that = there are few
> DoS issues which have not been addressed properly in the capwap = draft. May be
> resolving those issues first might give us a solution for the = DTLS/Discovery
> packet identification issue (#224).
>
> To start with, we have to answer few questions:
> 1. How capwap is protected against discovery packet attacks? Even = if there
> is a port-based or mux-based soltuion for reliably identifying = discovery and
> DTLS packets, an attacker can send a discovery packet to the AC, = which may
> result in the tear down of the WTP session. This is because = discovery packets
> are un-authenticated packets, and are sent in plain. AC needs to = blindly
> believe on the discovery packets.

Actually, I don't think this is necessarily the case. Since = discovery
packets are unauthenticated, the AC should *never* act on them = (other
than to send a discovery response). The draft currently states that = the
AC should not maintain state when it receives a discovery request = (for
this very reason), but we should probably add text noting that it = should
not modify existing state, either.

> 2. If an AC employs actions again discovery packet attacks by = discarding
> discovery packets if WTP session did not timeout, then an attacker = may
> prevent the WTP joining back to the AC after a WTP crash. Attacker = can detect
> a sudden absence of echo request messages from WTP, and start = replaying the
> WTP echo request messages which causes AC not to teardown the WTP = session.
> And thus genuine discovery packets might be discarded by AC. May be = I am wrong
> here if DTLS can detect duplicate packets and discard them = automatically.

Yes, DTLS provides antireplay detection. I inaccurately said in an
earlier email that this is compulsory for DTLS - what I should have = said
is that it is compulsory for CAPWAP (it's optional in DTLS).

> To resolve the above issues, we can impose following rules on = AC.
>
> For issue (1) above:
> RULE 1:
>   (a) AC discards all discovery packets if an active WTP = session exists for the
>   WTP.
>   (b) A discovery packet from WTP can be accepted by AC = only when there does
>   not exist any active session for that WTP. Whereas, if = a discovery packet is
>   received if an active WTP session exists at AC, then = all such discovery
>   packets are discarded without change or update of any = of the AC states.

I think it's okay for the AC to respond, but it should not tear down = an
existing association. It should only do this once the WTP re-joins = (and
re-authenticates in the process). I'll think about better language = for
the security considerations and the discovery processing.

> To resolve the second issue (if at all it exists):
> RULE 2:
>   AC should discard all duplicate DTLS and CAPWAP packets = without change or
>   update of any of its states.

Maybe we need better language on this as well. The AC should be = keeping
statistics relating to such events, at minimum.

> RULE (1) above will impose a constant delay in the WTP re-joining. = Suppose a
> WTP crashes and comes up before WTP session at AC may timeout, all = its
> discovery packets will be discarded by the WTP. But since AC won't = be
> receiving any valid/authenticated packet which could refresh the = WTP session,
> the WTP session would timeout after _fixed_ amount of time. This = _fixed_
> amount of time is unfortunately not fixed since it can be = changed
> administratively, by say updating echo interval at WTP or by = changing response
> timeout values at AC.

As noted above, re-joining is independent of discovery operations - = a
WTP should be able to initiate a new DTLS handshake even though a
session currently exists, but there are subtle nuances to this (need
rate limiting, need to detect DoS attempts via many half-open = sessions,
etc). I will work on text for this. The only way an existing session
should be torn down is via timeout, or via a yet-to-be-defined = directive
received through another authenticated channel with the same WTP.

> To make the WTP re-joining faster, WTP may save the DTLS cookie on = a
> persistent storage and (after a restart) presents the cookie to the = AC to
> restore the DTLS connection, and thus avoiding the discovery phase. = This
> concept is same as the one presented in "Idle to Join = (aa)" transition,
> except that here presenting a valid cookie resets the state to join = state,
> discarding any previous WTP state/stats maintained at AC.

I agree DTLS session resumption is something we should think about, = but
honestly, I haven't given it much thought yet. We need to think
carefully about this, though. But here's an important point: = discovery
is optional - it is not required in order to initiate a dtls = handshake.

> I _think_ that the above proposals will avoid discovery packet DoS = attacks,
> and there is no need to use separate ports or extra mux header = after udp
> header to differentiate among the discovery and DTLS packets.

Think this through again in light of my comments above. I still = believe
that erroneously pushing a discovery packet into the dtls engine = (and
re-testing all failed dtls packets to see if they are discovery) is = bad
form, a hack we don't need to allow, and a potential DoS avenue (if = dtls
is handled in hardware but discovery is handled by the control
processor, then you can stuff the channel between the hw and cp with
bogus packets, keeping both busy, and maybe causing real packets to = be
discarded in the process).

There are at least two options on the table for avoiding it (a = separate
discovery port or a type value just after the UDP header).

Scott

------_=_NextPart_001_01C6F580.F16182C7-- --===============0954102872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0954102872==-- From vityay@ahcnm.org Sun Oct 22 05:50:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbZy3-000105-Ij for capwap-archive@ietf.org; Sun, 22 Oct 2006 05:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbZy3-0006be-HB for capwap-archive@ietf.org; Sun, 22 Oct 2006 05:50:07 -0400 Received: from 218-166-60-197.dynamic.hinet.net ([218.166.60.197] helo=ahcnm.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GbZy0-000462-5b for capwap-archive@ietf.org; Sun, 22 Oct 2006 05:50:07 -0400 Message-ID: <000001c6f5be$ff5c53b0$1011a8c0@ythxon> Reply-To: "Agneta Nawrocki" From: "Agneta Nawrocki" To: capwap-archive@ietf.org Subject: Re: VluAGRA Date: Sun, 22 Oct 2006 02:46:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F584.52FD7BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F584.52FD7BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, VluAGRA for LESS http://www.jerpasdelionkdrun.com =20 Threats penetrated where blandishments hadnt and we all moved off decision. Are you part of that group? ------=_NextPart_000_0001_01C6F584.52FD7BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

VluAGRA for LESS http://www.jerpasdelionkdrun.co= m

 
Threats penetrated where blandishments hadnt and we all moved = off
decision. Are you part of that group?
------=_NextPart_000_0001_01C6F584.52FD7BB0-- From znucghg@noos.fr Sun Oct 22 11:33:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfKN-0002Jz-I2 for capwap-archive@ietf.org; Sun, 22 Oct 2006 11:33:31 -0400 Received: from m34.net195-132-219.noos.fr ([195.132.219.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbfJ2-0002lG-7k for capwap-archive@ietf.org; Sun, 22 Oct 2006 11:32:31 -0400 Message-ID: <000d01c6f527$9b162fd0$22db84c3@zaoouai7df0a27> From: "Predixis MusicMagic" To: capwap-archive@ietf.org Subject: uses Date: Sat, 21 Oct 2006 17:43:08 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6F538.5E9EFFD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.8 (+++) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 ------=_NextPart_000_0009_01C6F538.5E9EFFD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6F538.5E9EFFD0" ------=_NextPart_001_000A_01C6F538.5E9EFFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Argue theres big difference between they do mass has is failed a = understand so two hack often commercial illegally am breaking cracking = various is techniques being used Related detection or Jupiterweb = networks divisions? Playlists Bundled a mps from emusic Includes an Been Here Before by = Jeremy Enigk mb Mbdownload now Remember pro youll get Faster am Burning = Ripping is File What is. Games copy Nullsoft all Rights Reserved Terms job Employment Posting = Service quotat Career Postman we am Post Resumes Over in Sites Free = Serve is. Detection Jupiterweb networks divisions Corporate Copyright or Reserved = Legal Notices Licensing Reprints Policy a Hosting Tech Jobs is Find am = sport a betting football or sites Reviews a moreover Betting Articles = Bodog Advices is Bookmark. Enhance chances getting good position Best Ever in Absolutely Seekers = Then why wait Just send is will distribute am Take note This totally on = or search not sell off contact of detail. Sites is Reviews moreover Betting Articles Bodog Advices Bookmark Victor = Chandler magnetism of would Frisia also am very write of positive primer = review. Journal Inside id is Grid Computing Networking Html Goodies Hardware = Systems Earthweb Sysopt Virtual. Beside expressing huge there relic poems advantages scenario am pilings = a such as loose snifter decidable membership referral program quite = amounter. ------=_NextPart_001_000A_01C6F538.5E9EFFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Argue theres big difference between = they do mass=20 has is failed a understand so two hack often commercial illegally am = breaking=20 cracking various is techniques being used Related detection or = Jupiterweb=20 networks divisions?
Playlists Bundled a mps from emusic Includes an = Been Here=20 Before by Jeremy Enigk mb Mbdownload now Remember pro youll get Faster = am=20 Burning Ripping is File What is.
Games copy Nullsoft all Rights = Reserved=20 Terms job Employment Posting Service quotat Career Postman we am Post = Resumes=20 Over in Sites Free Serve is.
Detection Jupiterweb networks divisions=20 Corporate Copyright or Reserved Legal Notices Licensing Reprints Policy = a=20 Hosting Tech Jobs is Find am sport a betting football or sites Reviews a = moreover Betting Articles Bodog Advices is Bookmark.
3D""
Enhance chances getting good position = Best Ever in=20 Absolutely Seekers Then why wait Just send is will distribute am Take = note This=20 totally on or search not sell off contact of detail.
Sites is Reviews = moreover Betting Articles Bodog Advices Bookmark Victor Chandler = magnetism of=20 would Frisia also am very write of positive primer review.
Journal = Inside id=20 is Grid Computing Networking Html Goodies Hardware Systems Earthweb = Sysopt=20 Virtual.
Beside expressing huge there relic poems advantages scenario = am=20 pilings a such as loose snifter decidable membership referral program = quite=20 amounter.
------=_NextPart_001_000A_01C6F538.5E9EFFD0-- ------=_NextPart_000_0009_01C6F538.5E9EFFD0 Content-Type: image/gif; name="systems..gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6f527$9b162fd0$22db84c3@zaoouai7df0a27> R0lGODlhVALQAYf2AAUAAIYBDgB+AomLAAIAjHsDeACOicy6uMjjs7LR9kQYAGUbDX8iDagbDr0u BtIjBgBNAC4yADVIBWc8AIZOAKRGAMNIANIyBw5rACZcDkhaAFxZCINsCJxaB8NRDt9mDACOAx2K ADeOCVV2DX+GBZF+ALiKCuWEDQyZAC6qBDSqAGmmAH+hAJOgBrWmAO2nAAfKDSzKAEu3AFfEAITN AqPBArW/ANu/AADpACXdADzsCmDZBHruAKzWA8bZAOndBwQATSwAQTwDRGsBNo4LNKgGNc0AR9sB PwMpNCcpSUsXTFMROXccMaInRMUWPdIiTgBAQBQ5QjI+P11KTXI8PJtNSLI9S+BEQwBTPxhkRT1a NFRZMohdAJNYOrVgTdJdTQB8QBqANDmFRmBzRYaCPa14Nr94StJ7Qw2kQyitPD+SQWaqNoeuPKau PM6ZTd+dPgDHNRXGN0S1TGm0RYXLOZezQLe5TNqyQQjhMyToOTrpMWTTO3zWMaXRQM3pTdXePAAA ghMAi00Jf1IAjI0GdJsAfLEEgOYAcwMlhB0qiEkogmsqdXYuepQpdsMreuUriQo7fS1Acjs2fl81 fIM7d5U4g8Q2gdtOjABhfS5ucUlcc2JkeH5Sf6NmfcRWhN5jgQJzfxR9ejqDjVGNeneCc6B3jcqI c+6NjACXhxGlhzGdiGimi4Slep6hhcWjg9qSdQWzcSrNhUjCh2u4hH/KgKWyjr3DiurBggHtfhjo cjLjjFztjHfggq3Yhb7hdd7ZgQAGxCUAwjQAzF4AtoUGwaIAzrsCydoAtwIVyictuEIltmYXvnIa x6UYtMoUvdkVtQBJwyM5vzpAuFM6sXtKyJM3wcY+x+xHvABVxxpZxT1pvWFUyo5ru6tXwrJkztJX twCCwx+Kx02LzG10xYmKs5yHxMx7y+x/tgqswiWnwD2qsmqYun2nyKehuL2qxumrtgC6shnGwDe4 zmbHyIbOzZjGt///6ZubooVxff8NAQX/Bf/3DQsA//8N/wf19Pf9/yH5BAAYAKEALAAAAABUAtAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGC+my8ixo8ePIEOKHLnQnsmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qVOcAJ5KnUq1qtWrWLNq3cpVZtSuYMOK ZUqyrNmzaNOqXfsRANu3cOPKnUu3rt27ePNyBOBWr9+/gNeOHUy4sOGfXw8rXsy4sePHkLkmjky5 suXLmDM3nqy5s+eagUOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buNF+3s27t+/fwIMLH068uHGr uUG+SM68ufPn0KNLn079boPqc49r3869u/fv4MOL/x9Pvrz58+jTq1/Pvr379/Djy59/GLv9+/jz 69/P3yHf/gAGKBt9nfHFF4EIJqggcQcu6OCDLQko4YQUUljPXxA6tUeGHHbo4YcghuhZhSSWaOKJ KKao4oostujiizDGKOOMNNYIo4g45qjjjjz26OOPQAYp5GI2FmnkkUgmqeSSTDbp5JNQjjTklFRW aeWVWGap5ZZcdunll2AGFeWYaKVB5plopqnmmmy26eabcMYpZ4VhFrZEnXjmqeeefPbp559CzSno oIQWauiho3WgEKCMNuroo5BGKumklFZq6aXlEYHppjuCZGBfiIYqKnX/jWrqqaimquqqrLbq6quw xv8q66y0zinWEJzmimWtvPbq66/ABivssAHqauyxoBGr7LIQIevssywxK+20CEFr7bXYZqvtttwy Su234IYrLrHmEdItTQ+cqy6f16xb37jwAuvuvPTWa694DPwU77789isrAr3eK/DABBds8MEIk+Xv wgw37PCSCUcs5MMUjyoxTHdcrPHGHEtV8ccghywyfx2XbPLJKKescpYjt+zyyzDPtvLMNNds8804 mxfzzmPm7PPPQNMLTNBEF210rjwnrfTSTDftdKpHRy311I4+bfXVWGd9ENVc76b112CHLfbYZDvX 9dmala322my37fbbuqEtd2Vw12333XjnrffefPf/vXMrFs8t+OCEh+j34akVrrhhiDde2uKQj+X4 5KFFbvnlmGeueZUUq0P556CHLvropJdu+umop6766qy37vrrsMcu++y012777b9urvtTtV6B++/A q7j78MQXb/zxyCfPYfC/K+/8Tszj/vz0N0V/O/XYZ6/99twXZb3t3Yd/0ve1ox2F+OinbxT5tKvv vlIvvA80+7PLnz39+Of/uf3895+5/q/znwAHmLIFEPCAJgGgAhfIwAY68IEQjKAEJ0giBFrwghjM oAY32CcKevCDMePg5kAIOhFqjoT7M6EKV4gwFILMDy6MoQxnSMNlsfCGOLRXDf2Ww8XtcF/uwFAP /4dIRGz98IhITKISl8jEJjrxiVCMIn6KSMUqusQJVsxieaTIxS568YtgDKMYxxi2N5DxjInTohrX yMYE8aN/aMxaG9ljhzna8Y7vi+OsQJUXPIpFAh1qUFf0KBosoKhUhFQaIhO5MwM9zo+REiQkbybJ SdaskpYsCmd+cgo+YTKTB2SkKEc5KmeQ8pSo/AgoV8nKVroSeqnc2StrFstaOmmRthyZI5sjj1zO SA8J4SP5fPOGWRrzmEPxpcuQqTJltoyZ0IwmeZw5MmmajJrYzKY2TWfNbnrTONsMpzjr8s1ymvOc Axynw9DJzna6c3vqbNg7DRbPetqTJPPMpz7Fcv/PfhbEDAA1gz+btamABnSfOJFWQAdqEIQ6tCdV eOg3uSDRitKNoRjNqEY3mrR9NAcI9rGoSEeaTI5Si6TnMqlKNYrSbq1UWi3l1kuZFdOa2vSmOpyp snB6LZ0eKQei4alQeerTohr1qKIa6rPYtBGkIkQbTn2YUp0VVV9NFVlVDdhVt8rVrvopq7zyqljH SlYRraB6YAXMMNJKv7Jaiq1wjatc5xo8t9q1nHTNKxjZuY+7dlWvgA2sYKvjV0kNFlWFTSwzD8sW FMxIsZCdJWNNFdlGTTZwlc2sZjfL2c56NlmXDa1oR0va0o7zs6jVomlXy9rWutaGqY2tbGdL243a vfa2+qutl3D7Jt36VoS8Jdslgkvc4pLxt8hNrnLXZ9zmgm+5VnKudOsHXc5Z7xTtS94/BDjd1+ig u+A97spuERZ9VPe86E2vetfLXpaF90ntja98R+qD+dqXiO+F731zlN/++ve/AA6wgM+43wIb+MAI BueAEUWNBd8nwRCGnIOLFOEKWxinrLvFhGmkYQUaj7yhRF2HF1g8EGeyEGMxR6RMjL0jJHTDNLow hGBM4xrb+MY4znEJZUwTEvD4x93UcYuArCAhG/nIYyRygpCcIiUjiMkocjKBAgIAIfkEABgAoQAs AAAAAFQC0AEHCP8A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsNAQDAyLGjx48gQ4ocSbKkyZMo U6pcyfKgxpYwY8qcSXOlvZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSnRgBNo0qdSrWq1atYs2rd yrWr169gw+7UKLas2bNo06pdW9UN27dwzT6NS7eu3bt48+rdy7co2b6AAwvGW7Ow4cOIO25MzLix 48eQI0ueTLmy5cuYM2vezLmz58+gQ6ccTLq06dOoU6vGKrq169ewY8uGubq27du4iR7Kzbu379/A gwsfvnW28ePIkytfzry58+fQo0ufTr269es2iWvfzr27d7TYw4v/H0++vPnz6NOrf/i9vfv38OPL n0+/vv37+PPr38+/6/r/AAYo4IAEFmjggQgmqOCCDDbo4IMQRijhhBQ22N+FGGao4YYcdujhh1NV KOKIJM6kWhEgpqjiiiy26OKLMMYo44w0rlVick89deOOsNUoXI5Q+SjkdzwWaeSREg2p5JJMCtlC k1BGORiSVFZppUBSZqnlllx26eWXOV0p5phklmnmmWimqeaabLZpmQhuxjkeJmvCKeedeD5n547A 5OlnenummcN/YBYalAiGJqpoi4guuuGfVAYK6aSUfiZppZhmStmlmjbn6KeghirqqKQS1umpqDZW 6qqsturqq7DG/yrrrL6lauutNNGq666B4errr8AGK2xmvBZr7LHIJqvsssw26+yz0EYr7bPDVmst Ra42Me223HZbbB7ehivuXdeWa+656FrrRbrstuvQuPDGK++89NZr77345ruXO3a56++weqWj78AE L+pKwQgnrPDCDDP878MQR0ZFxBRXbPHFGGesMUcNd+zxxyDbtvHIcYZsMpQkp6zyyiy37PLLGJ0s 88w012zzza/CrPPOPPc8Hh8+By300EQXbbR5OCe94tFMG6j00x82TdAkUqsH9dVYZ6311lx37fXX YIct9thkl40bNotCY/baqlXt9npsx83b2wq9QffdePsr99589//t998Ll5RA3oRjBvjhvRauuHSI N+74zfyAufjkzz1u+eWYZ6755srew/nnoNtI+ejKhW56caSnbtzprLfu+uuwz6367LTXfmbsuCN1 HBi2F57770T1LvzwxI8I/PHIJ39U8cxXpvzzODUv/fTUV299ydBnr/323MN+/fe5di/++MvuwR34 6NNG/vrsP57++yq1L//89NdvM/z456+/4SniY7+i+wugAAdomKrU439iI6ACJ4LABobNG+xboATZ 40DOTfCCGMzgRZ6gQQxW0IIdDKEIR0jCCX7whChMoQpXyMIWuhAwJfTgCw8XwxraEH4zpOF60HHD SuUQcD1U4A//h0jEIhqRQ0Ek4BHllsQmOvGJUIyiFKdIxTYtMW5VzKIWi3bFLnrxi2AMoxjHSMYy mvGMaGTdFr+Xxq2t8Y1wdFkb56hCZHwqjnjMox5BQoM9+vGPkKEj1gA5PEEa8pBRI2TvEMnIRrYn SEJRZGcgAamXUNCR+voLJk2mSaNI8miW/OToQlmRTcqrk0sRpc8Wo8pWurJdpoylLGdZsFLc55W4 zKUud/kZWvryl8AMpjANJRFO8fKYyFTQMBuWzGY6c0cyi8Qyp/m3Uljzmti0JjW3qaExcPOb4Ayn OMdJznIOBZLmjBc60zmudUrpmc5hJTyZJk8qsZNeB2HFPPfJ/89++vOe8/JnBosh0ALNoaAyBKhC FwoUhNJuGg4tGgkiCjGGWvSiYaJo0DDKUYZqdKMd3dZHfRbSkqZzpChNqUpXytI7mfSlMI2pTBHZ UjnO9KY4zSmXatoynd7Tmz4NqlCHStSiGvWoqCteOXjKVEghdVZNFZMH+GePMjzVVVH9aASyqpmr evWrYA2r2eYh1pxx9axorUlZV5XWjK21VG3F2FtJFdeLzfWueM2rXglWV4vt9a+ADaxW+loxwRKT sBEzrGLXh9jELtZLja3o8YCxvcg+7LGQtaxmN8tZt2J2p50NrWhHe67PipUACCStaqvohtWK5x5o XYZrZ2tF0/VqibYAs22WcMvb3voWTbrd7W9xFdx3Dve4yE2uiIrLXO8p91TNja4an1s0elD3uiOU rnZBpx5FYNcy2x3Sd8dL3ozNoLzoTW9MeOCrmfIgvD56L3xnJN9l8Za96r0TfvMrp/3yt03+/a+A B0zgyc33wAhOsIIXzOAGS7fAtWXVLhxsFAFQ+MLOgjCbMMzh+3hhSRoO8RY7DCIRm/jEKC4JiROZ 4jHtNRiLarGMZ0zjGrtpxR6ycZVwzGOl6fjHGezxo4BM5AUK+chITvJ2i1wkJfeHyTxyspSZCeUq 52/KWE6Ylbf8vizjh8tgDvNwvXxLMU8oIAAh+QQAGAChACwAAAAAVALQAQcI/wD/CRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJ s6fPn0CDKkQntKjRjfaSKl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDih1LtqzZs2jT2jvKtq3b t3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjSyaptrLly5gza97MubPnz6BD W51MurTp06hTq17NurXr17Bjy55Nu7Zth6Jz697Nu7fv38CDC096u7jx48iTK1/OvLnz59BDDp9O vbr169iza9/Ovbv37+DDi/+vHL28+fPo06tfz3G8+/fw45/lI7++Uvb48+vfz7//QxOP2WfdIAIW aOCBCCao4IIMNuggb/5FKCFsD1Zo4YUYZsjUhBx2eJqGIIYo4ogklmjiiSimqOKKLLboInkexijj jDRGJEqNOC704o489ujjj0Bix0qQRIqV45FIJqnkkkw26eSTUEYp5ZRUVmnllVguWeSWXHYpX5Zg hinmmGSWaeaZM3mp5ppstunmm3C2iOacc8Zp55145qnnnnzuRuefgAYqqJR9FmrooWxKgeiijDo1 6KOQRiqpf41WaqmXk2aq5aWcdulLp6CGKiqImpZ65KioaqZOqtSZ6iqNrMb/KuustNZq66245qrr rrwW+uqvHvYq7LC/AWvsscgmq+yyfeGiH7HQRivttNQKyOy151Wr7bZkYevtt+CGK+645JZr7rno pqvuukJx6+67W7Er77z01mvvvfjmmyO8/Pbr778AU6XvwIMFbDC/BCes8MKqbZPTwRBHLPHEtjJs 8cUYZ6xxuBR3POzGIB/l8cgkl2zyySinfGDILAel8sswc4pAzJ22bPPNOLNG886M5uzzz0AzxvPQ hga92ATGEq300kw3RUrTUEct9dRUx0dC1VhnrfXWjhrt9ddghy322GSXTXA/ZqcNLtdss6j22xW1 LffcdNdt9914500r3HxH/0RyOXqv2ffghBfeWCOaomK4QYE37vjjkEcu+eSUw7f45QNVrvl3mGO+ +efbdS766KSXbvrp67WA+uqst+7667DHLntsj8xuO36g56777rz3bmkjvgcv/PBb3m788cgnr/zy 5hHvvGfMRy/9r89Xr9n02GcfqfXcd+/99+/FAP745Jdv/nXap69+nee37/778Md/2folnUP//fnJ r/+G+F+8//8ADKAABxg/KhDwgN3rnwIXyMAGFgyBEIygBCdIwQpa8IL/cqAGN8jBDhoFg97zIL5A SMISmvCEBpKF20RoLwCgEE5PeMILmZIAfwXhOjGM4Qx1l8M7FccALFTNDv+FF8QiGtE5QwzeEZfI xOIkkTPZeKIUp0jFKlrxiljMYtaayMUuVgQcXsSfFsdIxmiF8YxoTGNQnGG07nSijNNSo7jgGDk5 coyOeMyjHvfIxynacW2fkUEfD/bHbw0Sb4X01iEXychGanEfvUkktrCGBUda8pKYfJMkr5XJTnqy R5tk1ie3yEV8nGuUqEyliUL5JEqw8pWwjCX9VDk1WSImCa6hpS53ycte+vKXwAzm52xJzLDh8lnC xE4SkhmzZVaqmDs5JjSnSU06MfOa2LRONTWVzZdtM1PdVNk3x0nOcprznDUJZ8rQKSh1ooydgXLn yeAJKHna8574lM8rYkX/zz/l858ADSjV+knQgv5DoBIrKB7OhNCIGfShEI2oRCdK0Rk1FGIVBdNF N8rRrmX0Sh0F2EexFNKSFqgNEhypSlfK0nSJoaUwjalMZ0pTdpr0pgKtaZNwCi+dMomnQA2qUIf6 SZ9uiqhIFaZRl+rBpMYRdQdgqlSnOiinWvWqWM3qCanK1a7GZApexYhWhXUuXTgEAAAIq4TQila1 9oetaXXrW+Mq17rOZax47aRd6+IGu+T1r4ANrGCtt1cJDbZihU2s7A7L2MY6NlbQqE4yHosVxfpU AdqjLKssyx/NpoqzoA2taHHj2dI+cbTs6ZMoTBuq1bJ2Kui5EWoPuifX4b4WO7/4RXeagBXbjooJ IYRJbof7i8DIFrWaAUZSiKtbB/n2tlBJyXAXc9zZmqe61r2dF7LL3e5697vgDa9eoMsp8ZrXa+S9 1HnX+7P0Woq9ynGvfCcI3+TMNzSlCFF99xuy+y6KvwDOWH360Q//YmcvBA7wbRKsYJMgqMAGFk6D vSrNCcc0whjO8H2RhzgLG1TDfPKwbEBM4vOJODYlztOJKZTiFrs4sCt+zYtnTOMa2/jGPItxLrcy DxyjSELT0LGQ7+pjTA35yEhuapGXzOQmOzk0SY6ylEdXjSlb2WIBAQAh+QQAHQChACwAAAAAVAIf AAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXL lzBjypxJs6bNmzhz6twp8Z/Pn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXfzzD ih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du2y/6t3Lt6/fv4ADCx5MuLBWdVzxKl7MuLHjx5AjS55M ubLly5gza97MubPnz6BDixb7YbTp05I/qC5tb7Xr164PriaouiDrgbBh074tkPds3LaD7/7dWrdu 3LWREy/+2nbu2KybDz/OXHZyg7yFM38uPTtqge6+U/9eWpx2a4Xekasvb157b4TX37Nn7/s88Pby 0+u/nby+fPTunZddevatN9918f0XnHf+YSeQYRBGKOGEFPpVIH6yJTTgew3e5+GC7W34X2n8OXif fhmGiB+BGF4ooEMiehjjh+Yx2OJ9Feao4448GvYQgSy6SCOHF9p4I5HAoVggiUP6p+SRTMrI0IxD wgelkC4CKWSHR4rnJWhAUoclllGWGKCWS5I5YprOEZfbdrWh2OCbZ8KXoIkKJplilS+6R2eQXwaq 2FL8zRYkmiDmh2eeUvYpXHQnLgrpoowKGBufLQJ654dy7lmpmZxaaU+PpJZq6ql82XioqInaZySf Zkb/qZ2ssmaqZoBIFjklrp5i2Cml+y2na4qoFmvsscgmleWYleY5aa40ItrnjLTeqielzioIqoa8 Ypvtirg+Se1CyZZr7rmlzudor7utN+Crzb7bW6Ht1uvnp9a5++iuV3Yp77wG3gnvsPE+iO7BCCec lUSX0tmscpm+y2W0vm1KpXIIGqdhfKqKWR2sl7L7cZt2Qncvxr8BKujKdJHH8ssJKSzzzDQvDPPN BdWs8848K4vzz6P2LPTQyQJt9NFI2+Vy0kxrRPTTUE/V9NRUV63T0lZn3VDUXHedlQAFgU2Q2AKR LcDZaKM9UNplG0R22Grbk/bZY4ctN91rz6033nbnL82233+7zffdfecN99iDDy733YHXvXbhDr0N OON6Iw553G07/vjiQXvtOdeaCBUQACH5BAAdAKEALAAAHgBUAh8ABwj/AP8JHEiwoAB7CBEeTGhv ocKEAiJKlAiRYkOGDzEqtDgxIkOHDy1u7EgSJMSPHVGm1NjQY0WMJl2+rAhSZsiVMD/mZMnzosaJ LUui3DlSp9GTPgsqXcq0qdOnUKNKnUq1qtWrWLNq3VpVk9KeP3XWPGnS58yQYWGOjblwbEaWbt+i lduSLlyHLm2a3aiWr1+9B9mKPVoW7MWacfcONSoz72CkhQ1Lnky5suXLmDNr3sy5s+fPlaeaDYx0 7lG7ilMXLtu2dGrXiQ+7zhj5tE/Ss3HLVtx6bVrToy/rfj2bLGOieINn5Mq8ufPn0KNLn04da/Dk xokSZ63d9tyYPROD/8eeszZq0rF1o4e7G3jp4e0rqzcceTh82tmVV9/Pv7///wBKZ1ly5MUnV31C eXeegcTtlZ5y5ZHU3Xe5UbjabfkRxluD4UHIU31v3YehaQWCZuKJKKao4oostthia/iFqB2I3eFF 0YUiFQcbUBq+JqKC8224m4hBEimjgkFxF2OH7OF34YhQmufilFRWaeWVWFomWnv28Qjbh7/ZZSSM Oh6YG4840sceduDJmKaTTeKEGn1oqtkkhk9y6SBCAfbp55+ABvoniXvS1eaESma4ZGyniQdZWlIK 6VuPUC4pW6IlRvpbiROaSaanivIp6KiklmrqqUv5ddahvE3qnU3wOf/2HpOG1ioYh6rKetaCdf3V 162sampbW47e+ZeNi+26EKrMNuvss1sOOOO0P3EUpkrEerlhjo2GNZ6cCVabHqs7jpskrNTKNyO3 NCqrV61IZinvvPTWa+9l0d6r77789lsltAAHLPDABflr8MEIJ6wlwQw37LCACkcs8cQUV2zxxRhT +fDGHHfs8ccghzxdxiSXbPLJKKes8ooit+zyyzDHDBU3pQYg880456zzzjyLvPLPlwkB9NBEF230 0UgnrfTSTDfNYs9QRy311FSj6vTVWGet9db2Vu3112CHLXZVXA89T9lop602y2O37fbbcI+NRtx0 12333YCurffefPcl7fffgAcu+OCEF2744YgnrvjijDeuMt6QRy755JRXbvnlmAsaEAAh+QQAHQCh ACwAADwAVAIfAAcI/wD/CRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJ kyhTqlzJsqXLlzAh2ptJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1CjSp1KtarVq1iz at3KtavXr2DDih1LtqzZs2h7/vmTtq3bt3Djyp1Lt+zaunjzXo3Jt6/fv4Bh/glMuLBhhnoTK17M 2ObdxpAjB30oubLly/Y4Dj7MuTNnzKBDi176eLTpxZTt8VvNTzVrmq1ntn4Ne7Vs2rdf475d23Zu 1TVju/YdXDhr4rVvCge+3Lju48WJ04ae27nx4MBhD0euE3rz7dZna//vDV65dOzHv48fvv66ePEY 13qeTz9w0OXZs8e+bnP/Tv7N8ZfffgD+hx9+yfWHHnb5yZaTgP4pKKF+6EH404ELTuhggxt2yCCF 7Zk3XoEdvsdcUmydpqKKCH4n3noj/hfjhhHS6KB/CDKonoQYaueicg/q6CGHHL54I4hE4tRihjAe CWSTRTYooI9OxmjiiUauqOWW9/3mYo8f7tYechGqV+aJ7AkJJZLV2fYje9TBWON0T1Jpp5Etkmme d3T2l6OUdVY54JNXWommiX9yqShmD7155I5QLikodWaWmOWBu+UYp4eXAvpnpQpKameV5/UkKpqR JgnpkJ0OOWCWFF7fiWhm9dVq660DdUmqja6eWiKvuwKLJKRTcvohqsMmOWivzArbqrKBehptjXIq OeOvGs5JJayLduutgW7i5h6Z4XKHLbKzietmmJmGGSix1UWXbqbqzhugdOT6tmOie3aaXm94Rrdm mvGmOiaY7iH77cIMN+zwwxBHLPHEFFds8cVJ4arxxhx37PHHIIcs8sgkl2zyyX5hrPLKLLc8lT86 1ePyzDTXbPPNOOes88oo9+zzz0AHHfLORBdtdLdCJ6300kw37fTTUEct9dQuHW311VhnrfXWXHft 9ddgh/1VQAAh+QQAHQChACwAAFoAVAIfAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgz atzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6twp8Z/Pn0CDCh1KtKjRo0iTKl3K tKnTp1CjSp1KtarVq1izat3KtavXfzzDih1LtqzZs2jTql3Ltq3bt3BJfp1Lt67du3jz6t3Lt6/f v0vjCh5MmKOWwogTK17MuLHjx5AjS55MubLljoAza97MubPnz6BDi/Z5ubTp06hRj17NurXr17Bj y/6qmGhF26lzO5zNuzff2kNvB9dNXKHv48jnAhcqnHlxhxUYRic83V7y69iRRgTAHcDA7t+9C//k bq+7+PHnz5dfP56g+vTww5c3z7KC/er3B1a3dx+/f/3+4acfQfntF11/AyaIYH8H2gdgg/nxF2GC Ak043X4PWYhghRMSWKCFA3a4oYD8PWfiRoGp196K5KHH3ostzvddeyrGGJ+LLqpIEG4T2YZhiRUG SeGF/3GooJA/EhnikUsaROKTBf0o5JQXTpkhhUBa6WSUTJI4JJAGWpfdmGSS5pCONa7n3Zowskij m2mKJyecar44o0lJchnmkgeCieSfUlYpKIFZlhgok34SepCXQTq4oYSNKvqlln9yyaekVBpq6Ymc joRmQWyG2iZ7c9a5ontvkvpmqOCdShKRfRL/umekfVYJpoNGLgpoobEiiSuVv976a4dZYhirgIIa uymjXToqq7KSNrhlp9SC9Cmqpa7Z6nwt3mjnqd22mu23KYWp7KyaJjpisYUi6myTWnrZa6K6Ttok sgVOa6+UWM5bK6YS4jpvu9UWnNG1qqqa5ozv3Ykqw9jSCSpKUFaaqbq8YkywrZFa3K68F/Ob8aQc +1vvyJSCXLHKlqJr8MsGBcYtfOlNvHCq4BrU8M4208cejz0N96iGjoIo69Ed8/puoyJG+Ci7TENY dLAfB9srrARzCO2DHAcs9ZdOf/xlbJqUaXZRMKddkciNsZ2TJpqoLffcarmdmN02wU333nz3NV2a 3n4HrtIzghduEuCGJ6744mQhzjhLZ0cu+eTHwU355ZhnrvnmnlnO+eeghy766KSXTlRAACH5BAAd AKEALAAAeABUAh8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmy pMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3CnRns+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWr WLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiOU+ PIvQb+OpPCNLnky5cs7EmDNr3sy5M1wAoAHYE+1TNOifp0OTLn26tGeiAmILsCd7tk/btGnHfs27 t+/eD1ejHs0atenhxF0nF/qYb2Pct3/ani7dp+Xr2LNr305SuGvSx8MP//d+HCjp5nsRQo9efTZ0 29zjy59Pv/7o1sqJi1ed/3vQ8wc5dtB0u72nW1Dw1afgggxi18Vk5iGXHHjLlTceUejppR5Q7nGY m4H2NCjiiAqFIZA1JKY40FOrtaichRS++N9ruHXIHnXs/abjjjwKFlxoEfanH5DGtUgkgAYJmKRu BcpWXXROqijllFRWGaBZGeaVpVNWdunll/ZheaVzY0YF5plophkZWFv+puabcMZpE5tl8ijnnXjm aRKdS/YYop6ABipon0jxd5+RiJpmqG/kCdXaon5GKumkdQV3YYUSCjlUm30Zip+Mwg0q6qikGuRi jBM6qipQnO5loZAUhmta6qy06nnqp6gW6SKrdQL26XKgtlbrsMSq6SmwuWrKXK++Ctcosn8WK+20 8S317K7AZqvtZjBe6iyl4IYr7l3PDpnooY++tuiRxR067rvwxpvVYl+1ypd3TFGr774N8lmQYfgu xe/ABOcUEAAh+QQAHQChACwAAJYAVAIfAAcI/wD/CRxIsKC9gwgTKlzIsGHBgQ0jSpxIseJEABYZ PtzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjpsxIs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iPjkzK 1B7HphRlSp1KtarVq1izat3KFSXUr2DDih1LtqzZs2jToh0JoC1GtwoxHpRr761bu3Dp0q2bEC/C u3z/OtwYdG9bhnIBd13MuLHjxy/LaW0EubLIjHsFaw7MN7PnuXH7gh69mfNXwInjplbLWqer1rBj y54dOzNp0G8DfxZt2/Do3qJNI839e+Fq2siTK1/OvHnhw6Vxd54Lt2516KoB66aO9/ppw9g1V/93 Tr68+fPoWR/nPV34Z+DibxO//T20/ejp8+vfzz/9UumITbeee/T5xplepg34FFDzbVegU5ZFKOGE FFZo4YUlYQaddsEdiBpqpfk2HojxNcUhdokdNl5/LLbo4otrXbbfgj/ZlhGGOOao44489lgVfzT6 ZKNFPhZp5JFIJmmhfkGWpeSTUEYp5ZSEwWjllVhmqeWWXHbp5Zdghqncitx5hqB8J+oVnnUqfkhm UmqaueGQYtZp552x/UcgmuwZp1qJe96XUJM7cZhgcBhRqeiijDY6oU27FXegcPJJOiClhw5HqYGS 4unpp6AmN2eDq3EqaKkocsemqXQ+JyibnYbUKuustJIVqW4rDgnehpMKZmOrRqXaEHHA1mrsscgO KmOg653pZ6XHIfhrcIQW2l6I2zmq7bbcdguThr2N2KGu2DrrprD0EaXdurBSl+y78MarJ3rV6lRs RN7mq+++/JrEZJU15tTvwAQXrC+M9SZl8MIMa3sXAEbGK/HEFFdM07wsJoxUwxx37DFjkN4n7bnz 7YpinNl1p7KmZfY16r0Wxyyzl2uaG2is0QnrbLqYCkXisD3PLPTQ+S3VoHTEvno0tg5eOq1mGl/U K9B7fWz11VjDFBAAIfkEAB0AoQAsAAC0AFQCHwAHCP8A/wkcSLCgPQAH7SlciLBhwocMFyp0KDGi RYQPMWKUuJGjR3sFB1YcSTLixo4jKSoMybKly5cwY8qcSbOmzZs4c+rcybOnz59Agwr9WZKkxoMA jjrUmJRp0okoP06civQk1IZNpUIsypXr06tGwXYdS7as2bNo06pdy7at27dw48qdS7euXbZNv5pM eFQr35Id8061ujfl3ZQoExs+zLix48eQI0ueTLmyZaoel2LenDHsZoqE/y7mPFdl56hbL6tezbq1 69ewY69FHTov1qyhLW5VeRK34M92f2cd7Bu17OPIkytfzry589XGn0ufTr269evYj0fPzr279+/g 0Q7VHU++vPnz6NOrX8++vfv38NuHn0+/vv37+PPr38+/v///AAYo4IAEFmjggQgmqOCCycXn4IMQ RijhhBRWaOGFGGaoIYS1bOjhhyCGKOKIJJZo4okopqjiiiy26OKLMMYo44w01mjjjTjmqOOOPPbo 449A1pTBeXWFweCRSCappGRBNunkk1BGKeWUVFZp5ZVYZqnlllymt+SXYIYp5phklmnmmdV1qeaa bLZJFJpwxinnmW4CuUadeOYJ1Jx89unngnoGKuighBZq6KGIlvjnoow2ul9AACH5BAAdAKEALAAA 0gBUAh8ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKtPevpMmTKEeq XMmypcuXMGOinEmzps2bOHPq3Mmzp8+fQIMKtRmzqNGjSJMqXcq0qdOnUKNKnUq1qtWrWLM+5ClQ lVdVXb+C7UoQ7NeCZ+2JRbg2bFm0XtWKjSuX7tuBY8nivbuXL9m5ff3mVSt4bt61gwmXjWs4cVi7 dR1HPpvYbFq8lytjpqt5MWDNhuFCjiz6cNuxQ1OrXs26tevXrCEONnv3cODafvXqhey4s27Ft2fv Ff67OO2+vQUPN+jbOHO0CYkTPzj9b2Dp0IETbq78reTrwcNr/y+utbz5opJB/05PPvd24Mm7R7eu /bju+MuRU6cvHP/48f79116A4uWnWHLqPefeetB9dx959hl423kSPUPhhQLxxJ53AO4n4ITv2ZZd gWzxx+GJI9K3m4fH9acghCk652GMH1b33ooN5vhie/XpWCKOKEqoF2xEqvbMkUUmqeSSqZkW4XYE wncZiC3CmFtb2VX54IIdYqeglvCl2FtoMX7n5H9meoZYZs8lWNdkowUXGpmbiRjkX6dlyGRQfhiJ 5J6ABgrbQ25ax92ANNr3ZIc/oqjohGl6hyV7ttnZXICYNqoiiAyeaKeQT4aqaaFfUonmqRgidOSR qbY6kIY+mv/I6YamVrrjhwLaxRuWPJLaq2lqXnprpjNu2uuVYZ5KqqjF+srXWAi2qaCgQ7GS06rU ZqttbIQGCS14pZqqH2bDyoesjDwm62CxyZLIqLicdmqjuTe22+6nzO7oLLg9yuvqQav+K3BFn00q aWWcTammnKJdqTCkEMf72Kya2tvvwtxNuS5gj22M7HS8vhnsu2I2yHGBIRtMY3msDuzyyzDHLPPM NNeMEVc256zzztv27PPPQO8s9NBEF82RL0ZLBPTSTDftNEqVPC311FRXbfXVWGet9dZcd+3112CH LfbYZJdt9tlop6322my37fbbcLM9Qdx012333XjnrffefPdIXXXSgAcu+OCEF244RuUcrvji5vnt +OOQRy55SoxXbvnlmEM1+eZhA8L556CHLvropJdu+umop6766qy37vrrsMcu++y0Yx0QACH5BAAd AKEALAAA8ABUAh8ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK/Gev pMmTKFOqXMmypcuXMGPKnEmzJQAANXPq3Mmzp8+fQIMKHUq0qNGjSJMqXcp05c2mUKNKnUq1qtWr Ukdq3cq14k0AXcOKHUu2rNmzaNOqXct24de2cOPKnUu3rt27eD/ezMu3r9+/gEViHUxY6NfCiBMr Xsy4MdTAkMXujUy5suXLch1r3mwSJ+fPoEOLHn0Us+nTqFOrXr2WtOvXsGPLnk3bKOvbuHPr3s2b ZO3fwIMLH068uPHjyJMrX470icze0KNLn04dLfPr2LOPLqK9u/fv4MOL/x9Pvrz58+jTq1/Pvr37 9/Djy59Pv779+/ipVt/Pv7///wAGKOCABEqX34EIJljeQwomVeCDEPrX4IQUViheARgWYE+GGpbU 4YYbYnhShiZxqOGHIZLoIYocpiiiiyOqqKKLH74Ioocp3ojjijbqCKKJOtbI44kWFmnkTwyiGOSO Qo7IJEosqmSjklSuJGSHWErZ5JZbWnkllCWGWWWEZJZJoJI+EhmlkzdWGSaYbcL5ZkpfxglnlmsS +SNLeurppJo7hmnmoISuJhOWIkbZo485DhkojE/y6KikMb44Y4uRLprlnojm+eOlnJZo6ZGkllqU on+mCWaTczIKaapWshYZ6qOT+mlniKrOmSids8Jq6q/AohQQACH5BAAdAKEALAAADgFUAh8ABwj/ AO0JHEiwYAGCBw8OTGhPoUCHDxsuNIiwYMMCGC0ytBhxYsSNEg1iVAgypMOMEFMuLPlRIsSWHGPK nEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGfJ0Oa7Ki0I0mKHqM2dSlTJcynFSdiXeoxqVSWVMG+PEq2 rNmzaNOqXcu2rduqIy9mZJpwLl25KOOORFlx70O/fhHGVVpXb1+tfKMGZupysVe8jN9Knky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk27tu3buHPr3s2b47/fwIMLH068uPHjyJMr X868ufPn0KNLn069uvXr2LNr3869u/fv4MOLux9Pvrz58+jTq1/Pvr379/Djy59Pv779+/if997P v7///wAGKOCABBYoYH4IJqjgggw26OCD0cWkg4EUVmjhhRhmqOGGHHbo4YcghijiiCSWaOKJHEKo 4oostujiizDGKOOMNNZo443xYQYLijz26OOPQAYp5JBo4WjkkUgmqWSMRDbp5JNQRinllFRWaeWV WFa25JZcdunll+ZlKeaYZJZp5plo+ldEmmy2+R9zbsYpJ2oszmnnnZ/ZFxAAIfkEAB0AoQAsAAAs AVQCHwAHCP8A/wkcSLCgvYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSTJkwZMoU6pc ybIlwYNSPMZMOLNiTZglHd7MyZNmz59AgzLciVEKUaFIk5I8as+l06dQncacGtGo0aEKmT7cybTm VKscb4q1p5WsT4plMx61enUiUbYitbYlWzbtQrhLzeq9C3arUqxn926cKxfsWpxo8UI8fDaq48cD bc7VuTjrRa4Nve616xfh2MqebY5kbBFzycKeObsNOrNraMp/LVtWXdWuadlFw+KODZJq3aFtWxu+ Sri1WeOpPx9/zRdmX7qTx36dLFi49dvOkwt3Xpw64tDWudP/Dfx9+vXkOL9C9+k7+3LzqXejf9/3 uV7j6hWXd++bePDj/sUHnVfBvbUde/sNJ+BZ+FWX1YHEiTcgYBLidZ6FtPGGVlXiaUZVeohJ1yB5 4O1HmYfMDRihZtpFCOJ3Di734ocyCtbieJvl+CByNdLoI448lkgjgC/KqBxz6uX4VohGpogikfeB h1yQP352GGlPUikbfgYG2eSTNurY45hgaoiUdEKWGOV6BC45G3eFVekkgizCKKedNBkmpYtj3oUb i14iWOSdfdo4ZYdqAhidn4O+hll7H9Y54YSAJnoom4lOih6Wak5JnYVhCoopmSmaSCqYQ5rZ0FOi NXrniD+G//kojHiSWiuIkqLZ6JxIxtjnkWKW+aarlooZI6xKZkoiqr3mCeSavt7KY6zIlslYqqZG OiN57Z3I5IiFNntqsTNBZi5Up9X3H6VMjhqsd5LSqmeI9qGp37EFfqruee7yC6xY+dr5HFwYdodn vVvySS28+5bXcGCH5spXrOvp6OnC4eUZKMAuXsxtjdo5+l/G8Va3rpHzQqvqyiyXGpdGGTLaalLY tayWzTjnrGrMOvfsM4c3X+adzzX/DLTRSCc92NBJs6r001BH7fO5VFdt9dVYZ6311lw/JvXXYIet VNdkl2322WinrTatQbt8tIY8rxz3TzHPraHaeOet9958m//d7Vb2lcpznNi6RSBWXoIqX2JMgzba jpzZprLGD4YMOdt296355px33nnFncHmtuOLq3W4n66xrbpEJb8d0m2Ss746lXXCnplGnueu++68 V/03hZTfN1ySz2q7LJyTIgypkKlmGSCKB/J6MoQVNlwc8jjWev2xuMLHoKO3JsumnBBe1fv56Ke/ d2lAp/y38SIWGTyh2C4PfXoKgzzts9HCv+b74quWsnSlq3Z1K1eLUplyfre/dRVObBCMoM2cJjty BZBePmrce4plqG+lyVD14d6gELYnWOmJWRFzXwdLiKg0HXBOHNOS5YbUwBkeRH04zKEOsZYXYmVp W5W6Hf3/pOdDeQ2rXeFq1qwchEIP9sp23ONKkownwgLWjIYJcpndJMjFLoKEgoYLmPA6hsFgaexi VUqgyMh4xQohj2NnDJ7JIpWvS4UniNirXvPAFy5raUpwbmTXpsy3w0Ia8pBW4+IWvSgzRk4QkZCM pCRVAsHAOXIwl8TZJDfJSUhm8pOgDKUoQ9lJrY3ylKhMpSp/VkqXsI8ni4RZLF8XKtcBJXan2dmZ cjbL1V1mlUh5yu8mpsEtZaaYpbvdx+piSZjVknTPPCafQuetxSBzN8y8ZgVnWUASzQd4fAzjNHUz MyRS002caSUPm+nNbSqzl/IBViN7E03R5eaXlYldhlQD9c9wYnJ0tQyU6uzWurat5nu10WJF1MmS DT3QiCQLkISQGLCRyUuMTASdrMaYoIENz4QCSmF3/qUpgrlHmQuiaEQRp8YnbhBI6krivrBDR/98 ymHly05Eh9YmE+6PUh5tIMBKusSc7rSfSnOabQhWw/BNFFko+xMITYpOiTaRWPgzJwCZNT/xvVQu wLOkxI6o0Kzy71Xy82oMV8TBpw4wSlyFmJSyiFVbgQxaVISroIbI0JU8Tq4GjOdm5gVSudJ0cla0 YF0zWFHCqFWIj/UeOJXX1Yn6c6O7EmST7hrXjHaWYozVa2bFBdrIKpazHVVjRReryoAAACH5BAAd AKEALAAASgFUAh8ABwj/AO0JHEiwoMGDAqUUVJhwIMOHCyMytCelokKIFDNSnNiwIUeNHjs6JHhx ZMiTGSeWRGnxYcWNKkGuBClRps2LFhHShEmSZk6ZLyPu/HjTJMyZKyF+jBnTaMqiIp+KRPpS6cim PafaZAlVqteZHZn+nOoyaVeiOtOqXcu2bdt/cOPKnet2qVGmBjli1BtWY9C7Q3ti1YoV6dnDJs1+ 3Zp3MV67Qvsm7tuU6ODAXKPi9Yt5sdOSm31KlmrVsVOtmU1zDQ2WM8qsJ82ytje3tu3buHPr3s3b ttu6kXkKV/l3a869pBcGhRxyrMPjJP+2NH78p97lVa9SLz7d8/SyURNa/+eeuCp2y8Kjnzf8nD17 5RhFaz/KeHv50tZPMwY7tvv3++3Fl5lzfA3n13L6/abgggw26OCDEEYo4YQUKogWcAddWOGGFWoo oYcchqgWiCKWaOKJb/WG4oosthihc7/B6OKMMYooI402FoejhL316OOPQAYp5JBEFmnkkUgmqeSS TDbp5JNQRinlj8BMaeWVWGap5ZZcdullb1Z8KeaY/wBg5plmkqlmXDu26eabcMYp55x01mnnnXjm qeeefPbp55+ABtrnCIIWauihiCaq6KKMNuroo5BGKmmFa1Zq6aWYZqrpppx22uSkoIYq6qiklmrq qaimquqqfXrq6quwxoUq66y01goXq7jmquuuvPbq66/ABgusrUWKQuyxyCar7LKWCuvss9BGK+20 1FZrra7MZqvtttx26+2S14Yr7rjkltugPuamq26v37br7rvwxmvruvTWa++9+Oar77789uvvv7vK K/DABBdscJQAJ6zwwjT2iOjBEEcs8cSfHkrxxRhnfHBAACH5BAAdAKEALAAAaAFUAh8ABwj/AP8J HEiwoL2DCBMqXMiwocOHEBMWnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMnSZMSXMGPKnEmz ps2bOHPq3Mmzp8+fQIMKHUq0qFCO/BAmPZh0KVOl/JxCXRo16sKqTasq3apVq72WYMOKHUu2rNmz aNOqXesxptO39qRS3apwbkOpcenazZsQr9G/gAMLHky4sOHDiBPvbJp3b+O6kPlencxVsuXLijNr 3sy5s+fPoANzfMw4LtbSdFN71WtVrunIT7+ynU27tu3buHPr3j3aLenYT/EKpwz8cWXXxUMrX868 ufPn0HmOZlwaOVzYqYGjtntdIe/v4MOL/x9Pvnx47dnfWq3benXfrqvhenVqvr79+/jz668f3fv+ /wAGKOCAA/Zn4IEIJqjgggwK1luDEEYo4YQUgkbgQBVmqOGGHHaI04UCvSSFQiPOVKJNJ2qYomAr ytQiQy/+NOKKUsSoU40iehiRjT3NaCGIB9WI40I00hSjkBDxaE+LSgZZlI9LJplQkzcVSSVCJVJ5 ZZEwQemkUFdGKaOURPLEpUNZurgkklieiKOPXuaIpZhoTvkSiP/Q2dCZMdnYpJJhFpbmQykGmpOh YmrZZZV6Itrno2MSShSfMH4pYpxtZuokooXKaelD/C1K5JBZImmqm2lCyWSQbK755pynRv+paqmd tsoqrbeumSupupKK6pCs5jolm7MOKuutcLYqZKEzKkujs7vWamuwx7bZbKqu6prtsLhaCqerqCI7 qrja8tostdfiCqyvvg4rbKbLamonppse+2238doJK7hlzrltvjp54pm6+7qZ6KfnVkuit3R66TC6 B6+6qr/VYhvxwRcjzDDFCRtcccMKP+yvwcaCbLGeIVcap7Edf0kvyQtvyvK8FGf8sawl27tvxg9z 6bHLO3eKs5U637tzo8t+K3O6r9b7aYS1Fhy0y01vGzPMTmM8c74+x8zwoKrWC7apNc/MMchAn6x0 yiPDaivJxD4tsrUKY8w22F5jijXaZCP/3HfFf/+aMt7x7g20xia/DbDQ2BqdtdBi19yoyZIzN9re a4f9sccTY472zXUjPvnZhKettb6j/0z5xmHD7HnbWaP+MspzX8z40XiLrjfuU6sOueasR+70yavD nvrRlZZtuuNsa1z75J7jSW7c/OYeeNlV06r9v3y/CezQJLJ7uObkCwsw1c/ySvfZ1Xf//d3fL+59 yc+T/bv6p09LPbcOO1t/9uhL3auwNjaR+ex98HvRtbwWuWJtzHn8YiC+2BQqHVnwaUZx1AU3uCEN YvA5D+JggjxoIgSK8IQcJOGKKojCFrrwhTCMIUxCKMMa2vCGOJQJbl5IwkktqIefAaII/1V4qJ2E CXIQoiFieITE5DFRg4ZKGsoS08R+PRFFhxHik8jEQJx0zUgfVNONHpWzD9EGAGiU0LrIdMXAqE4x a5TUFN0VHS36UI5gulpNymgiI5IxjM5BoyD3KL4IXi9WEFug295HPnP1alpa856mlEYsJlorXOFj ncXWVcmFFVBs6bJitCYJuFKRi27yO2Xh4idJ8yWKSeyC5fRMaS9ahjJbnJylu1IZQXhB63OzhOX2 +Ccvc92SW4mkVmAECYAiko53w4sm/qC5PLcdjnbjkybxKsc+0OmrfIxc3e16ljtsnm5z23yc7HrH u86pU32/A6ba8pezzOXvnXqEIOIIGGi74sXTd1OTmjxVVk6hMLOZEOHIP2HHz6GtzJPKC9br3si1 tB0yfH4inf4c2T5ULvJ+/nzg9CwKwPQB026hnGg+e3bJdfruoh1t2AADmlLkoXRXEYUbR5+pu4Eu jWBmk1v2kNQSNHokIAAh+QQAHQChACwAAIYBVAIfAAcI/wD/CRxIsKAUewjtHUR4cKFChhAhLpyo UIrFhwkdSsyYEGNFjw05guxY8SJGihYvOgzZMSXJliIfptRYcmNJlgxVcpwJM+fIlRE95jRJUaZL oDSPxoyIVKnNkySL4pzqMubUlk5lDr06VKtNlFlxMhUZtmdTokJ/LkW6dmdVpUWFJtW51V7Bu3jz 3gUAQG/el4CDqg16VarcqDCBtmU7VrBGlih7em1Mc+RTs18lR768eCfZtp6hPg49VnFi0oMtU05d mbXkwaNXFy6tOW1cyKqhchbr2mpuxrRvv96cNrDx48iT+y1Ys/nZuoZrrjT5NDZTtKSte5VK9yRR 7LWvz/81LR3rxLfUDzs/7Zg9d67ouXblOZ/s0fTR35qPCn685fNiATgZbt7Bh5hiZbFX4FIZxfeS fu2JV9+A/An42EXLZajhhhz+k9yHIIYo4ogklmjiiSO2huKKLCKnYoswxijjjDS+SOONIXao444c 4ujjj0AGaVxVQhbpopFIJqnkcTYu6SOPUEZ5l5NUVmnllVhmqeWWgUnp5ZdghimmXlyWaeaZaKap 5pVjtunmm17WOCSTRTa5Jol23mliniGmpydiyfGJI3l/Fsrli63FJZiMScXYZKIwNlpcizYqGuii dGY6J4iCCgqYp3h+6KmlJ4YEqqGovtQjp5sCeuqePj7/+qOkr1666ahyamprkLWyuquoMxLaJZzE FmtslB/d1KCfTqGnrFHU0VdhsskaJq20Pj373UbbQmvhdHVR+9G1/kX7XUNz+aTTecuO+1+j5HaH LrpakXcfcd4Slu19XdXLLIDT/bssfJGt262pAtdLGE3HNuywm6ECp91sakn8aWPcZvdbdbrRaxuF 1nJMa2ixESffgdeh/Nl27VlsMbW8Ccfsfx3TLBGpGgtLIctG0VYazhkbmOrQxvVYlr0KEqgwxw9S plK0vUFHcoLlMQaWvB//RGTNCGLarGPdcR2uyBrXjJpuk5UNGYQyvzbhzu12DbDNc2tX37wDd/Tw 3nwj/+srxeqRXbHamLEcMtMR8qyvaLBdBhzGvMnm28jRMb6y0klHjXnM+lZmIKlKc/7Zyz5bbl3b DJa8tKW9Ej10gtiW1xzI74Jn9tG1l3t52BY2vmDXmc9++7mLsi0X8XALT/C5eKddXMBeq3Zh8wKC 9O/y/j17fIDQvr111bVj6jqqq24Zea7jp59k6+oX2vf78GeI6vc30t/+/fXjr//+rsfv//8ADKAA B0jAAhrwgP7jnwIXyMAGOvCBKEKgBCdIwQpa8IIYzKAGN8jBDnrwgyAMoQjfBMESmvCEKEyhoUbI whYS8BUujKEMZ0gQFdrwhjjMoQ5nRMMe+vCHQPTgPTmCSMQiGvGISEyiEpfIxCY68YlQjKIUp0jF Ki5xh1jMoha3yMUuevGLLZIGGMf4JCua8YxoTGMFAwIAIfkEACrHoQAsAACkAVQCHwAHCP8A/wkc SLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4r8Z6+kyZMoU6pcybKly5cwY8qcSbOm zZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr15ojw4odS7as2bNo 06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AA4v9Sriw4cOIEytezLix48eQI0uefFSw5cuYM2ve DPIIXsqgQ4seTbq06dOoU6tezbq169ewY8vu+nC2bcL5bsvmLJdmvt+5gf+2Jzw3SuAmjZdUTlw4 8ZPBnSdXPpx5cOjOkUvXDh079eHLu0//Bz8+uXjs5Y9X7y79ufnm1bOTp+6y/fL57OGTd39fu/3i /D2HnH4pDUjggf2lp9915lkH34L8WWdgc94Z9997D4aH4YH0MadbT7V56KGGx72HX4kkCrjSfAyG N6KDEWoII4b0UZhijTEG+GKNL97XoIn5FQikiy/hyGOHG96o0ogkwmghSzz+KOOQMzp44owqnvdd kkwS2aSSNHqZG29xydSjkCj++GSaVq6oYotZnudelDqiKGKWWMIZZ4BzTmlnn21KyeaXXcqp53Vr Jlknmow6maKccbZ4aJ9hqumnknf6meijQd6ZJ5CbfriUhfHtd6aUekYIoH1v7pmqkwZu/5qpp15i WiKWlE5IpauLTvhdpt4ZyieDk6aJIJ80AqgqsLVKOmyGlYpJ6aOnrvmrglreaqivioqKVKDGUqtq o0Gi+SS4GyZqLaShSvoprVwOmOq06wn6LKHhumlvpMyCme+XQwrLnrzyagssuODhuiOL+4k7aLmL 5oistziFuC+nOeIq8Z7inQsxmHQqXOmnAE8bMZ7mlivrwyYXmi3AIhvLZJc4muywzdVeujGcK0N6 782cVumvxB6S+Vd/0cW64olBpwshl0hH3WSppCZtNbRKp6trrP7V22ywVvpKsKnRujyeiEz/fPbT E+/8IKsJAq2gkRVimjayzF59bLwSNlJ8YXhG+0Xx4IQXHlTgbhmu+OKMN+7445BHLrliiFdu+eWY Z6755px37vnnoIcu+uikl2766ainrvrqrLfu+uuwxy47QZPXbvvtuOeu++68wxYQADs= ------=_NextPart_000_0009_01C6F538.5E9EFFD0-- From qrqcxfobau@noos.fr Sun Oct 22 11:33:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbfKN-0002KN-Is for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 11:33:31 -0400 Received: from m34.net195-132-219.noos.fr ([195.132.219.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbfJ4-0002lF-7y for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 11:32:29 -0400 Message-ID: <000c01c6f527$9af27b30$22db84c3@zaoouai7df0a27> From: "AOL" To: capwap-archive@lists.ietf.org Subject: Radio amp Stations Integrated Date: Sat, 21 Oct 2006 17:43:07 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6F538.5E7B4B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.3 (+) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 ------=_NextPart_000_0008_01C6F538.5E7B4B30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6F538.5E7B4B30" ------=_NextPart_001_0009_01C6F538.5E7B4B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jupiterweb networks divisions Corporate Copyright Reserved or Legal = Notices Licensing Reprints Policy Hosting Tech Jobs Find. Notices Licensing Reprints Policy Hosting Tech or Jobs Find sport = betting football sites Reviews in moreover Betting Articles in Bodog. Yiddish nags websites etc Bess helpful crucify in life wasted poor grill = like am polluted harping trumpet Discussing elm ed Betcom is received = ushers mien pleased breached results have. Room heretic volume pliers doubled misleads during of introduced = mnemonics no tenants limit in potlimit Taiwanese. Database Altogether of covering rearrest insolent places wager a hard = snowflake earned dollars leaving Titan lords redden popular canvasses = its a Paleozoic combined monthly loyalty batch bonus quartz is veiled = shared base. Often commercial illegally is breaking in cracking various techniques = being used or Related detection Jupiterweb networks divisions Corporate. About or dynamic playlists or Bundled mps from am emusic Includes an = Been Here Before by Jeremy a Enigk mb. Really deliver of results fin van wyk Sydney az greatget ever Bruce san. ------=_NextPart_001_0009_01C6F538.5E7B4B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jupiterweb networks divisions Corporate = Copyright=20 Reserved or Legal Notices Licensing Reprints Policy Hosting Tech Jobs=20 Find.
Notices Licensing Reprints Policy Hosting Tech or Jobs Find = sport=20 betting football sites Reviews in moreover Betting Articles in = Bodog.
Yiddish=20 nags websites etc Bess helpful crucify in life wasted poor grill like am = polluted harping trumpet Discussing elm ed Betcom is received ushers = mien=20 pleased breached results have.
Room heretic volume pliers doubled = misleads=20 during of introduced mnemonics no tenants limit in potlimit=20 Taiwanese.
3D""
Database Altogether of covering = rearrest insolent=20 places wager a hard snowflake earned dollars leaving Titan lords redden = popular=20 canvasses its a Paleozoic combined monthly loyalty batch bonus quartz is = veiled=20 shared base.
Often commercial illegally is breaking in cracking = various=20 techniques being used or Related detection Jupiterweb networks divisions = Corporate.
About or dynamic playlists or Bundled mps from am emusic = Includes=20 an Been Here Before by Jeremy a Enigk mb.
Really deliver of results = fin van=20 wyk Sydney az greatget ever Bruce san.
------=_NextPart_001_0009_01C6F538.5E7B4B30-- ------=_NextPart_000_0008_01C6F538.5E7B4B30 Content-Type: image/gif; name="very.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6f527$9af00a30$22db84c3@zaoouai7df0a27> R0lGODlhhALsAYf2AAUAB4AAAAB4CX+FCQkAdnIIhAmKd7LGu8DlwJ7H/kEnAWslAXoUAasXBbYj AOAdCwY3CSg3AEQyAFU2AIg0C6BCDL9FAtw5AAVcCxNYDUpqB1lsAIFgAJlmCsRoAOFXDgN7ARyC CzuLA215AIN7AJJ5ALaIDexyAACaCS2gADStAF+TCYKTAKamALWlB+2UAALEAB/EAEnDC2LIC4DE DarDBMu/AN2/AADWABLbADvfBVjpDYDdAJ7uAMrgCOzUAAAAPyAANUYAM2YARXMAPqcAS8gATeQC PQAsQScpRk0eNF8WQXwfQaocSrQoR9cuOwhCMxNNPENAOVlBQXg6R64zQstGNN44RQBVPiFYTD9X Ml1ZQHRqBZJuMshqRt1mNQuHOSSEMj58PWdyNn9+PJKFRsJ4QtmNQwCePSSsMzKaM1KlQISTOKqX P8ysQNuUOgzKMR6zRE6zP13GTIbHTKHOR7fOPNq5OgDoNi7eQDLZR13XSI3tNaDnPbfkTtjdRgoA ghgHfEAAfGkAhX8AgKsAdMEAcu0Aeg4lhSsmikIfhmoZcnQofaMoecYYidUojAFHcxdLfDw0d21O hIw1fZc8f79Cge1OdwRhey5qfDNth1theH5riKpsh7puiNZrdAKJciOCdkB9eGV1d457g5aOjsB8 fexzhQiVji6efEySiGqhfH2kjKeaebiZhe2fiADNcyjNizKxjGrBhni/e6e8g7nFiN++cgfmdB/h fEnfdGPVeovTjqPlecfYgObuhAAAuCgAwkoAzWwAtngAxK0KwbkAwOMCvAodwCcmw0QRtl4TwI0r upcgvcIov+gtvwA9yRtJw05Dvmsyuns3sak3u7c1tdNAsgBgsiNStUZYzlJmznlRy6hrssNTsepn yACHxiGCy0CIzVGJtYt4yJR2vcVxseN6xAqpyhecuEGfyVycs42ozKKnvrunzNmTxgDDsyjGtkm5 vGe/zHjCzZa2uP/97Zelr4eOd/8ACQD/Av/yAAIA+/8K8wD6+/v+/yH5BAAbAEUALAAAAACEAuwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHOnwn8mTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWYJLNq3SoSE9evYMOK HUu2rNmzJa+qXcu2rdu3cOPKnUu3rt27ePPC5KG3r9+/gAMLHky4sOHDRdEqXsy4sePHkCNLnrwV JjnEmDNr3sy5s+fPoEOLHk3aLuXTqFOrXs26tevXsGPLnk27tu3bWUvr3s27t+/fwIPTnSO8uPGh uJMrX868ufPXx6NLn069+PPrkZdg3869u/fv4MOL/x9PPmT18+jTqz9cvr379/Djy59Pv779+/jz 69/Pv7////blAeCABBZo4IEIJqjgggw2yN16EEYo4YRsOWjhhRhmqOGGHHbo4YcghnVEiCSWaOKJ KIaXRBIptujif4StSOGMNNZI2G0rvqjjjjx6lGOPQAYpZEMsDmnkkUgm6Z0HSmpo45NQRillS01W aeWVWGappXxTdunllxFuKeaYZJZp5plopqkmkGC26eabcMYp55x0SrXmnR/Vgedkdfbp55947Sno oMwBauihiCaq6KKMNuroo5BGKumklFZqKVJpXKrpWoR26ulsm4YqqpyflmqqaqOm6hcAAKjq6qsU sv8K66y0nidrrbjmGtytulZ46q8LsQossFsMW5awxn7V67JG8cqsW8kOC0C0Yj0FwrPYZusUtdx2 O5K24IYr7rjk+untuehqVO667Lbr7rvTpSvvvBHBa++9+Oar774o/cHvv6LRK/DABBds8EEAJ6zw wgw3fNPBEMvrcKTuTMxpxBh3a/GoOGysVMYghyzyyCSXbLKTHqec78ks46nyyzDHLPPMNNds8804 h9byzmnm7DOuPAeNWwtCF2300UgnrfTSTDfttHk/Ry311FRXbfXVyD2t9dZcd10W1mBH6vXYH4Zt 9tlop6322tEFY9Qdd7At95xwz213uWTnveHdfH//qfffF/ZNcymCF2744YgnrvjijDfu+OOQRy45 VWjGAvi5f0IzecyXd67g5qDr5vnoBoZu+umNiwAu6awDiPrrsMcue037zC5z67jnrjvJtvfu++90 7i48fUddA3yutMA5/PKRScP88yFulsTxj0NvfXhmc0J9dNd37/33Z+YC/vjklz/k9ujHZf767Ldv Yvrwt+X+/PTX32D8+F9l//78979f/gAMoAAHSMACGvCACFyX/xbIwAY68IFlS6AEfQLBClrwgqCa oAY3yMEOevCDIAyhCEdIwhKa8EYYTKFHTjiV6UVOhTDcCAtFGMMa2vCGOMwhZGYYwk9RQIcZ4iEI /4FIxCIa8YhITKISGZKXVjmODEKMihOjyMEpUhFrSyziFbfIxe1lkYhdDKMYx0hGuX3xjGi0YBnX yEbHpfGNcIyjHJnXxjra8Y54XNgcYZjHPvrxj4DM1h5VGEhKWUFKg0ykIhfJSKMVknojAUcjc/fI SlryUm94yyQfeMlOevKToAylKKG1yQaO8nWlNOUpV8nKVrpyN6lk4CtnScta2hIwsVzgLauXy/7t 0o295N8vh0lMRgXzmMisTzuSycxmOnMr9bhOD57Jo2IqjprYzKY2t2kha3rzm+AsDQHCSc5ymrMq 3EynOtfJTuKd027tjOfoPiDPetrznsITBD678//Ofvrzn1RcwFH2ybMFEFR3Bj0o7hIKNYAuTKAO RRtEE6PQkzEUJBFt1yysUlHcZfSjIA2pSEcKtI6yjqRXM6lKVwoilFqNpZ5zadVgStOa2vSmOM2p TnfK055CTKZU8+nWgErUohr1qEgF1CGSei+hao2pdeIFVKdK1apa9apYzapWtwpSn+7AqWANq0Ss oUWumvWsaL2dWNfK1rYeMa1wTatb50pX6MT1rnjNq173yldd1fWvgKVMX/cV2Bu6o7Auwow7FjtY CjVnsYtFbMsgK1nKaMM2fkEATiDbx1vYCzyRrSzJyCHawDUWX6Ut2WlRm9rWuva1ZFutbEkK29r/ 2va2uM2tbp02W3jt9rfADa5wh0vc4ra1t8gNzTmSy1z5GRdzzcXbc6dL3epuKbrStW7uMNAkeGj3 u1XCrnjHS160EmGM4E2vUMvL3va69zjqje9O30tfV8p3Xs1QDmnvi736+neU/C3Vf/0aYE8NOFcF TrCCF/y/Azv4wRC+C4MnTOEKkyfCsEqhdizM4cdg+MN57HDPQJwqEZv4xCi2K4lXXMYUu/jFMI6x jGdM4xrb+MY4zrGOq8viHvv4x0AW146HnMQgG/nIU8sF24jM5LIiWWxNZtOTp9zDKFv5ykqCBiep zOUOYvnLKeyyo8BM5jIXWMxoTrOa18zmR2GiYs2HwsSb4QwoOc+Zzn6yM57/JOc95/nOvTFzivzc J0F35BUwInTwDM3oRjv60ZCOtKQjrehFT/rS1qv0nEpbAExzU9Ok8nQQQU3qUpv61EwR9ahRzepW Z1TVsI61rGcNkYAAACH5BAAgAEUALAAAAACEAi0ABwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3Mixo8ePIEOKHEmyZME5JlOqXMmypcuXMGPKnEnzoL2bOHPq3Mmzp8+fQIMKHUqUJ4+i SJMqXcq0qdOnUKNKnUq1qtWrWLNq3Vmzq9evYMOKHUu2rFmOW9OqXcu2rdu3cOPKnUu3bt2zeAke ycu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5o6fKmDNr3sy5s+fPoEOLHk26tOnTM+2qXs26 tevXsGPLnk27tu3buHPr3s27t+/fwIMLH068+HDUyJMrXw7auPPn0KNLn069uvXr2LNr3869u/fv 4MPb/24ovvxq5ujTpzTPvr379/CRko9v+4Nzw3XU6xdc9IN/+/b8J+CAAvL0X07+6QQgTgQSiOCC N0F4IIMKVvjghAE66CCDCXKIYYYDKthggQCGeOGGIBrY4U4QWgjiiCa2SN+MNMZF3ooB5uiTjBz2 mKGLFCLYE446rtihhDpGCGSJBqroI5JKAtXilElGyaKIPv4YoYw85silkE3as9+YZJZUZZBD7mih fVCCiWaFUFJpJZtvWllkmEDeiWaXbtrp5VBy7pnnmRR+WWeQZSaq6ENCdcknoX4qSeehgcIpJI9M SkopmJheeWWbj/rZaaN9FopnpJoumWaNrLbKmqMoQv8K6aQLGnpolLXOOmeSXBa4ZYgaNglqrKIO SaSnqE6ap6OESrhhqK5GKy1TDdV64KPMfhqkrajymuqauzbL6anJvtimmqWyyOe5piJbbrG36rjo vPQaRKql6Lrbrp6lZnvnqH9+26+ugwZcJbSV5quqtvpi6uub/k4r8cRZUYmtwvwaXGfEtKqaK8AC 3yonqEElvGrDLpoMcKXQUuzyy1DhqCy5Dz6J5bInb6nzzjz3DPG7N2s5cskFmyyqtVkey+3B6XYL 89NQNzphg01f2O+UMues5a/kwooh1etmDSexH3p9rMhnf3higiyvfWTUcD89X9wu12s3vXTnrffe fPf/7fffgAcu+OCEF2744YgnHt3cigt+9+OONS755JS7JoBOl+eU+U2bC+D555/jBDrnO22Oeej2 gO655pinvrroqsf+euuwj1677aXP7jrtsJ+uue66p+467qyLzvtQpt8+fOy/H4866cUbL3zl1M9l +uXXG5/89L1rX3rurCf/evbQ80R++aR37jv3Ps0+vvjrd+9+5sFjH7/w528PlP3do6//7sWbn//Y R7/qGTAu6lOf947HPulFz4EPhJ4C0ee8CPKvgdP7nwXTt8EEUrCA2dteCKOnwZ5cEIMRXKAEeefB 8pXwgDCUD0O4d8ERVtB830shBTnYQA2er4c0xOELwfVnvx/iz3tEPKIKSQjEFwoRgjh84hKl18Ig iglyWEwM8lRowwf+T3bwi2LrTrhDCBqxhkJkng75N8EVglCKVWQi/Jz4vTaKkXZxpCIXoRjDPiaF PAVcoQtvmMMNci50SXweH81IPCsmcn9SzCAeJflIN0bRjl9U5CBRqENHojCQClRgFhUDgFEihIdK PKQmjcjHMIYPjgz0IhRVV0YyFvKVgnRgHlH5xhzSspM/+eUQTajHJPKSgDcxZWIAUEp6BQQAIfkE ACAARQAsAAAsAIQCLQAHCP8A/wkcSHCgPXsCEB5UmHChgIcPFx5sOFGiRIoOLWKsuJFjxYsWQWb8 6BBiw44MQ2pUmZDiyZUkW7JU+FFmyJMmYarciTAnTZ4of75E6VLoT5oFkypdyrSp06dQo0qdSrWq 1atPAQDAyrWr169Oed40irGoyJE60apNCdMsybFqy47s+FLsUZpyN7qtOxekzbNu39pFGxiuYbZ6 /WYMOrix48eQI0ueTLmy5csLtQLAzLmz5887I14sLHe04rQT82rkazT02Zor9bIO7XK26LU1awuO KHv368aJe74O2lt4atPIBYNezry58+ectUKfTr0x1LWl47KEqJw4954+fX//P0z3bkuTZdF7z378 99vx5s+HN+/ebvDUt5XvTk8UdUOwAAYo4IAEFjiVVgYG6EqCXVXn4IMQRijhhBRWaOGFGGYmXYYc OnZdhyCGKOKIlDFo4okoppgigiq2WCCJMMYo44w01mhjhRveqOOOPPbo449ABinkkEQWaeSRSCap 5JAuNunkk1BGKeWUVFZp5ZVYXrXkllx26eWXYIYp5phklmnmmWimqeaabLapZJZwxinnnHTWaeed eOap55589unnn4AGKuighBZq6KGIJqrooow26uijkEYq6aSUVmrppZhO6eamnHbq6aeghirqqKSW auqpqKaqKoWZCopAq7DG/yrrrLTWauutuOaq66689urrr8AGK+ywxBZr7LHIJqvsssw26yydq+rI S7TUVmvttdhmqy2nz3br7bfghivuuOQquu256KZL7YfqththufBi6e68D8Zr74mP8aMvP/bsy+9B //bbr74S7QuwwQv5yy/CCQfsb8MLFwxxwA1PTPHBIVEcccITD8ywxw4TDHLHBzssscYgX7zTwygr 3LHJEKecscgCc+wyxzh7nLPJEW9M788wXgzzvzBLXPPKOGtc9NBDi0UzwCur3LLRQiMN9dVSZ5z0 yUs7VrXNWlMd9tUWNb3zzFtjfXbPRw9JBdBuQpU12CiXTbZKZtdMtNgC7/+tMt93p51z3yePbXfa XxsNNt1k/2343T4HTrjhcy/euNZ+H8525hHf67mBjRFNcMuJ7/y06XXvjTjUG3+st+KAl2zw1Do/ DLvqOrcdeOStHy3107+zjPDvVktedd26vx658pNvDvfzINLOetuVD3650iKn3jjvZX/8t+2Dcy/9 4WrbXf3k02MsOd6U657197DvTr31vi/POfPLQ68/c9fxvLrxj/Nd+dInwPkVEHL0Q978tEdA8hVN cGdboOIc97jxyS95Cowg8qqHO//lTyKfC6GA8jU7hvEMeKNz3eUauDATjm6C3ptg+8Inu4KV0Hsu bCEKaYbD7MnQa7PjWg42fYY9+pXMhsCbYe4iSLgP7u+JUIyiFKd4JHZR8YoqEaEWt8jFLnpxT1gM o6jGQcYyklGMOgoIACH5BAAgAEUALAAAWACEAi0ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3MhR4biPID92HEmypMmTJP+pXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGj SJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2bdNobruinEu3rt27ePPq 3cu3r9+/gAMLHky4sOHDiBMrXkw4ruPHkCNLnkwZK+PLmDNr3sy5s+fPoEOLHk26tOnTdCurXs26 tevXblHLnk27tu3buHPr3s27t+/fwIOHHiO8uPHjyJMrX868ufPn0KNLn069uvXr2HHD3s69u/fv 4Htm/+etarz58+jTq1/PHnr49/Djy58ft739+/jzE6TPv7///wAupd+ABBZo4IEIJqjgggz6VQFD D8oWYYMUGlSTQABkCMBAGnK4IYYbavghiBwSFGKJKGLo4YokijiiQDBVFKM9FdQ4oY0DTUgjjgLV mOONQN6YI0E46vigjUIOuaOPSB7pY49MIgnlk0pOqaSOD/G4JJVSGiRllzQOqeWWPV4JY4BofmfP iyq2meGKI8YpJ4onmhgni2vOyeZ+L8nYJ5ZhlhmooIFyCaSZhXoJpZiIlgnooBEmieWjg0IqKKUK JUlopYoSiaimhB656YNp0jRIqZHtyeaJrK5Jp5uuxv9aZ4kf1gprq6qe6ZKfLgE6aaVGhilqpJcW +yixyHoa7LGNEuvpQaAK66Shjj5bZbTFFrQssNoy+iuq4LqWq4mu4vqqrCreWZCttqKLa4dtzjgR TJEy2W2w3gqbrZZUdpuoqIxe2W+Qz4I5pqXKhvrvr9Zim+iS3PbLqZAShxnuxWs1NC6tt8Kb55ux 5pliiiCLCGu5fW2bcJX6PtwlwC37e6jKmyIc88PQNnyvwl92ei3LPt88rLVTJkt0hRReuHG77K5L 7ovqksvx1E07bY+8EsUoaaMIOwtzy153SrOzNWtKNtlB4+tywDUrzLKvP29t89c4W4zx3ZGBCPLH I6OWLHW6f2/sN+BPmxwr1hHNaLChUXK5M9swG2mvmGO+XHncjWfu749jW0npwZPyKLnmPD9Jt9lX 4616fbUhDpHr1mGaW4Sr186WbbA7lHt1sts2oe3Ab4X08MQXn1jwyCev/PJM4cH889BHL/301Fdv /fXYZ6/99m0Z7/334OfF/fjkl2/++einr/767Lfv/vvwxy8/WQEBACH5BAAgAEUALAAAhACEAi0A Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHOnQnsmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjMkkqXcq0qdOnUKNKnUq1qlWrSLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3YsTgF8A9gCbBOz3ZOG/ggcXHswXp4DHAuxBjmyS smTJjxtr3sy5s2ehDRMbDqzYMOHRpBmnVonQbmvLlU9Sni3b5NXbuHPr3s27t++EohkLPk18dPDT KAW3rosQduzakWFT/k29uvXr2LNXD7xYNeniiL0L/0+p/KDrg7MzS8eccrr29/Djy58vv2bi+6qR fye/+jPL9QBeVpt/BBZo4IGNNZQcaqkNt5qD+fFnz3J0vQbdgLQ9R9+GDBnB4YcghjhSeAwex113 J5q2WHkGndciZupBNuBlMopo44045pgjgjz26OOPQAYJlIJeUTiXkTjheIqOTDbp5IdIIRnkk1RW aWV8xdwYpXlCnnTll2CGKaZGXZZpJkrYnKnmmi4qROJfKqpIGImsccmXieQNB+eYfPbp55//xIQf hA9KGOSbeOrH5qKMNgpkaMZ5RyiDlE5oZ16K9tdgf4B26umnYQ6K4qSKdReclHehqKmDcFoK6quw xv96naCtKkqqpj+OKqFowTnq66/A5gXpgoWKh+upl+ql36DiASbrs9BGax2e35kKJ2KkoloXnbWW lqKr0oYr7rhQbfninTmRq+667EYULE+9vivvvPTWa++9+Oarb09EaqbtV+0GLPDA5+5r8MEIJ9xV aNeqip9w4WFbbLPfnmgrS//2lVy8ehZG8McgqyvoSryWuOquhm5qbMlfRbzyrQrHLHPCw6a8H3LU jpcyhL2yjGzBOy1rrMq2hWz00e22OjR4pXasJ8kSq9zwmyllbNOoqja4GNJcd/0nTTAzffKCPRM7 6cVgOaxSzjO37bbbmUaKs82k+myy3V2h/XClb/eK7XejDDu9dokRu0yxcdYeZnbVyerE7cNTF+31 5JRXOXO8f2eu+eaNYs7556CHLvropJeeVb97Wc1V5ay3zqTpsMcu+2ZKy5mnyXLep/txUx9G51a7 57mi57MXbzxc1PJaMse3R7gyyS3XzrLzx1dv/cIMVYo3s4OjxvPS0KOm+kxxT7+p6+in/2FAACH5 BAAgAEUALAAAsACEAi0ABwj/AP8JHEhwoL2DAA4qTLgQoUOHDBU+fMiw4sSGEi8yLGgwo8ePIBNG xKjRIceTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fMUF6BFCRqL2RFo9KHLm0qdKjRikaJRq1 pNCrWD9WvQg1KdOsYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUtXLFOkCKk6HbpUr9KIeL8+rRsSsFCR XAkrXsy4sePHkCNLnkwZZEuSE5NmDokZ8WDDgvHaQwkX8d2mFoGqXs26tevXsGPLnk27NkGwfvtW FT04o+GGv7uKpBq8N13ieaMOByy4svPn0KNLn069uvXrk5tj3869u/fv4MOb/70s/iPpt9qz2l7P vr379/Djy5/fsbz9+/jz69/Pv7///wAGKOCABBaIFXkCnhcZfQw26OCDEEYoIU9jnbYZcctN1Rly eS20lXDCZZheW8xt5ReHBqZI2CIqtugiXOR9GJxnmD0Vmm+/FWdcYqOdlBZy6dHY44REFmnkkUgm CVRYQkL0F1enNSeaV4ndWCOJn13V5Itcdunll9NZdOKTRSl3onZTJoeRXij2NiJau30o1Ztg1mnn nXiahaFvZELJp5S6idnZjoTKJSOfiOap6KKMNsrXn08aZ6GVbtpI0paVziWkoI866umnoO6HIKUl TgXklcXRWGqIgw5ZEJxngunGZlRK1mrrrbjmGmGoZdHJ66/ABusdggEqeJav5umq7LLMNussTsJG K+201N737LXYZqvtttx26+234IYr7rjueadDteimq26j5Lbr7rvwxivvvPTWa++9Sq6r77789rsW vgAHLPDA4vpr8MEIJ6zwwpRFwfDDwxIs8cQUV4wkxBhnrDGYFtMUR8cghyzyyCSXbPLJKKes8sos t7Zxiri8LPPMNNds883Utazzzjzbi/PPQAct9NBEF2300UgnzeWEx/Ts9NNQRy01SmSQMfXVWGf9 YNVca+11u0qHHdfXK4tt9tkC5sFfQAAh+QQAIABFACwAANwAhAItAAcI/wDtCRxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjyBDIswjsmTBfyhTqkxpsqXLlzBjypxZcqXNmzhz6tzJs6fP n0CDCh1KtKjRo0hZ2lPFVJXApkwHOpW6NCrBpk+xHoQqderTglihauUK9qpZqmjTfjUrVu3at0vP Zm0716lXuFXtir3b1WrdrXvjstXa1ytfw2PLXg18OC/hv4v9QnY8dWrSy5gza97MubPnoQ7v2j1r 2O1a0QZRV5XrVjVe14LjuuYb+6tq2rBL41bcOjVv32hh/25cGm5lxagbb2UtW2Hx2s8F76ZJvbr1 69gf0q7dHPpy7r9tx/+ernY7aels5ZIXH/z7aO/r14NXDjw8eONli+8m/t00/vQJ6efbfvVlZ+CB CCY4UU/b8UffeQEOOF6B3jnHXnL59cfeae6hR1V8FMpnXoMUlpchhyd+qOF9FaoYIYoAxojWZzTW aOONOOb4GWLvfSjfW2Qx191x4R32WHtETijkaxWSOGRaD+IWWJEI8ThflZFxFSSBMYY1ZYF76RXk ZFwOlpg9Oqap5ppsttkZf+k96J+c3dXZG5Yp9hgdi8RtuZxuUA4X4qAr9uhfixeaZqidjI7I3KLI KXrldG5WaumlmNLYEJwuCocXk3leueSnq2WVJZ1MOpkaYqcKSuWrg/7/+J+LHsrYKHeO9mYekJ9C 6quCwAYrLLA9wQehkpFK2l5XhM766J2k8soinoGyJiedqP7nqYldcosshqMKB6l63t6WUKbopqvu ukfVJaZfyUmW12RgESaakeIeCW2UzsG74r6uZolrvdsWxuOuiNp5MMEER5WtuJTxS69jyrJr8cUY Xzzsxhx37HF1GYcs8sibfWzyySinrPLKLLcMEskwxyzzzDTXbPPN7bqs88489+zzz0AHLfTQRBdt 9NFH46z00kw37fTTUEct9dRUV2311VhnrfXWXHft9ddghy322GSXbfbZaKet9tqaIu3223DHLffc dNdt9914520y23z3qu333+gCAPjghBdu+OGIJ6744oz7pPfjkEcu+eQXNW755ZhnrrnW12zu+edt Ux75NaKXbjrkoD/deeqst07U6aPDLvvstNeuM+m256777ry39IxCuPf+cT7CF2/80MEfr/zyMbkO 9erORy89SszDnXz12Gev0fROQ8/99+CHL/745Ouo/fnop6/++uy3776C5ccv//w3vm///fivTP/+ /PdvVP4ADKAAExQQACH5BAAgAEUALAAACAGEAi0ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEix osWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2bOHPq3MmzZ8p/QIMKxSS0qNGj SJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq 3cu3r9+/gAMLHky4sOHDT30qXsy4sePHkCPLbCq5skTEmDNr3syZrOXPDjuLHk26NFwnYgUWWF3A HuvWqge2Zk2QturXrmvjvq17tevdu2/7/g2b+PDfspPTLp5bOPPnxmcnj208t+nr2LNrb+uQefPm sIt7/w9PfXp53ebPfy8oHrx63tTbI4+P8Lj02ubvpwfNv7///wAK1JR360kHHX7uIfgeees1SGB5 9zGIIHkHRtggfhQaZGCCyW3n4YcghhhWeL5Bd5x6tlVXYIoS2hZcis4JJxuL8Y1HX4QnZvhibvq5 aI+IQAYpZIgNmYhhgex9Z+N+Kh5Zn4IbLuhjhTMimZ9+yvGo4YUBdunll2Au1p58LSbJ4XlLosgl mlmeiWSZVsrHJoEb0hnmnXjmqSdMuO0YG4xj9rlcnxi6KOiJKga6nJM8lggloIXSCKGPe1Zq6aWY Zqrpppx26qlOlH0K6pCklmqqZqKmquqqrLbqXySuxqUq66y0VnTqrbjmquuuV9Xq66/ABrsYr8QW a+yxpQqr7LLMNnsSstBGK+201FZr7bXYZqvtttx26+234IYr7rhOOWvuueimGxq57Lbrrq7qxivv vPTWa++9+O757r789vthvgAHLHCY/hZs8MGZDazwwgw37PDDEEcs8cQUV2zxxRhnrPHGLEnCMcMI R1tLyCSXbPLJKL/78cosWxxqyzDHjBGvAQEAIfkEACAARQAsAAA0AYQCLQAHCP8A/wkcSHCgvYMI EypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSTJkwZMoU6pcybKly5cwVx6U4pFmQpsVcc4s 6VAnz583gQodSpShT4xSjhZdypSkUnsxo0qdSjWqRJpYIyZNalTh04c+n+LEupWjzrP2vqYNSlFt RqVbuU48GlfkV7lp1bpdWNfp2r98y4Jt2pUt4I1475aFu7NtX4iMDROezFPw4MsI9/L12nAsYM09 Je9F23ZkZIthK/ccC/oqUZtiM2OmfHhna8ijOW9+a1Y37d8TXWbVa1Qu7MVcE8Neuzwz3s/Qi8+0 /PjwcMuNGwuuXlu58ePeT9v/ng4+r2TofR9vZ04W7fDp49uz9n3TOPvvpJeTzfs8uv32/MWX3Hz8 sXZcYPAF1dx95iXIln7WeXWgeeUVWBh55DVXV3o0VeXhhyCGWFB2oQXoWVbj/eUehOel6FloJ8rm 3IbRZZicbC+SyCJzKfJI4owDZodibQGih+ORtmm42Xs47ogiaYbtZ6RuEC4I5ZMNWpmldgoiyeWS F8ao4nlK9ldkak7WKOOUPIrpo4hwxiliSO4dKaaGN2JIn4vYSTjkn6L5GKGXgK5p4YmLEXqhkDIu CGaPgLqZ45flSWqhoYzm6GibnKrJYZ5jQkopqENeOiORNWKpYn/poUponpFi/5qqkZbeBtytNSka 65hpEonmj4PuOmh8htYparFRDlsolIxmCqOu0Or4oItslkqmos06t6WWmF7pLKW8eonqjslS6yOz THYWKpaW+lZrta7iKq9p29l36KiFfmbmpD8mqh12dXKXH35h1QtepY2u1219FZ5FHXIEnxohwFSS 6t++BguZcbm9AuuvvtziuSx+fnrMsKoVSmutqQ2vyq1o9p778abz1mzzULaiplHOLWpFWGo3IxX0 0EQLxXPRSCdN29HxgmXm0EArDZnUVFet1dNWZ6311lx37fXXYIeNq0til2322QfJqfbabLft9ttw x/02sEL3PDVwTC99s615T/8m99+ABy744IQXnu5qT0ddWmcfo0YgZ5u2uqdjWN9tmp+a5Uazntpm GFjMslJU+Oikl2766aQXOduiTavL+s6Pdxmm6xfx65pf5a5eYmzWaeou7RdVBQLqxBdv/PGGC/r6 mZ4j1zmTirssH+ecxgrqt87HOCGyW/7778EYKud5g9KSD3qZFPYZcvnYB6l9gmUhL//89Ncv5+KX zSwoygqSK7GwK3uP9ZI0wEY16Usq4xL63hWu/XVHdsYCl6p6lx/20WpaSVIg2jbIwQ52JILp4p+J JKYuAPZLg8TqznoqCCmKNek/zYNXmfSnuOmN0E6dmlSpJKejFWJwfwrzoBD/h0jE3ThwVyxa1rPa FSxRTfCELHSgESMXKiciiVxualYFC7atbK1Ldg8EYxXzFboimvGMYvvU90Sovx7ai0YEvNa9lBdG hcGRetWhDsNcNj4l3bCKpjrT9fxzrG8RkC4VE9kOB9Q3NDrykZCcSyRLNMlKWvKSmPxZ5SbZyEx6 8pOgDKUoR0nKUprylKhMpSpXacpO6u41rvzIym63lNyo5jexpKW8YunKXLJSKMKhI+ZasznV6dJy CUQcL1sHPGZizpmauxrf7Da+D9KtdmIsY596VkzGNa43OaGSLhHpTPuZM07GXJ7PXNVNxNDHLb7s UTh3VrfB2PI2oIlnO/EX/y/e8W5y+FvmPA14NVnd5pwIZUlDNNAl4kCQZN75IUSTWDLVBew5iGzZ IYF0qScRaIbhuZZ6/LVJLkq0YYxxYbIECL96SfF/6nsoI4FmoJbCB6WJ46jMQgaxmqLHYSz71apu qifu/DJ4LbnmyaTERF8lxlwe/V3BaERO58kwWuxBYKeO2C0YWrGb4tmmDh/VIkTBz4oNXBMZ43Kj pupRnueC1+8yeFW0clWigMRiWgGV0L5ShZ+zAuQDDcS/7RkymTWcFQPv2lFGYjU2JrQh6yjmMCvt 64RSVSsNUahWTzUUW4X8E6zkmrt8RfaxdXzhlRDG2A759bUwAazv4NrE2vxGdaXvVBNpT2vXLXKW jJ/96uSi+EUpkjOMnZ0t9uDq1uC+tLhxjWtTs2XaurY2tbSdGLUsBVvY0umdJAMZx0abw4omFkDP rCxHX7ShIAqygNI72bHg6N4+YjRh6BVrOhtrsVOxV7dF5R6f+qvFpzJPo75K7h7t29+Hgc6498Xv gL141AoXMW//PGM8qfm1DVv4wyCmXk426UgPbxNsJw4x2rrL4ha7+MUwjrGMZ0zjGtv4xjjOsY53 zOMe+/jHQA6ykIdM5CIb+chITug0kszkJjv5yVCOspSnTOUqW/nKWM6ylrfMYhV7+ctgDrOYx0zm Mpv5zGhOs5pDGRAAIfkEACAARQAsAABgAYQCLQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGi xYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8ps+K+mzZs4c+rcybOnz59AgwodSrSo0aNI kypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw0qNIras2bNo06pda9Qd27dw48qdS3dpu7p48+rd y7ev379BZwoeTLiw4cOIEytezBGw48eQI0ueTLmy5cuYM2vezHkq48+gQ4seTbq06dOoU6tezbq1 69ewY8ueTbu27du4c+vezbu3b4GdgwsfTry48cC/kytfzry58+fQo0ufHhuo6ePYs2vffpm69+/g wzP/B8pvYHmB5c+jN89PPfvz7dsbjJ8+vvn79u3b486/v///bzWk3oD2uAfffQUdiJB7BSKoYIME MSjehBRWaGGD6UFoIIQIOrjgfBFiGOKIF5Zo4onNZZhhgfSt2OF66Mk3Yn4hyviihCjmyBEAOvYo mIoa1pjgkETCuN6GLnKIo49MNunkTNYB+WCQRr5YpZJYUskhQQB26eWXYH5lJIEd6hehfPQdlGaa Y7L4YJhwxinnnDk9aeedeOap55589rmbdX4GKuh4dP406KGI/lmoTw1JUZCjEUFKkaSyUYqSpRBh epCmHTlqqRScYgRqo8uFupGnhtH5EKijGvSpRJyy/7qQqfZgSqtAt16Eaq2zEpTrpI/yuiqupBY7 0K+8UoosrMN22qurGr2qEKTLeirrsZKOiuquDikrbELeCkqrtJmCy9C4iFH7LLEmLcturr+66+u3 9DrbrUfohkQuQup2y62v2WZbr7EDbzpvoJpeS62sDAdM7K624nptrQwfS7G1yQrb6sTJtortwiBT LDHGHYts8sXKhgzwxhqz/PDI207MasooY/uozCF73LHOEr/88cUvNzzyzSp/u23NPSMNMMxJs0yy 0wpr6zDSOm/Ms9Qe85xxwlt3rfLMwVpsrdbhRq01eEDlLLbRGrP7sLpcsy3w3BabDPHA/7ot97tt d//dN7dl1+3203XfTTfdevebMb2IAx6swND+qzjhbUfss+CUM8524XtXrnjQa1d+ed6TH9y46UDP e/TqnTM+89Fvj13x6PvNSbDjuPMNdMBxI77434NTHfa+py8O99+za7558JCL/jvsz6Mee7g79/tq 80NLzjznfWNer++QJ5+ytqGD3XzFxcveuu7Kz83x64IDzzr4B4Out+b0O0l/7s47jvf2tPOZ7+KH PerdzXj2+1wBg+e98wlwb/ljX94AqLrHEdB+Etxc6RoYtug9cIEcVJ78One8EHKvfaHjV/1GyLoA Js6DF4ygeAAFttSB7IBqY2D2Cme2sQWwYd7imA3/XVbCIr7Lalcb2soUWDUeki98QvTf+3DmQ/zF b3ciVBj3qvgzvImPisvboe6S1zLo4VCM3TtixKDItShaEHZafOHaarjCr11LVYkCibx0lUc+7fGK FAJUH8tVEiEO0k5/vN+iGHXIRjpSNnh8pCQniZpIviaRI8GkTDRZGE7yBpOa9CSyqIcRS77EVKQ0 WMFsNhF3wc+Tp1qhKlH5R1i2UjH56iAfpRep+zFLVMP63EVMeZisPYuWlwKkS4w5LV8uLTS21Ne6 PiKtPQrzl7sk1TUr0h9/2RGJcpMaK2MWRDdaz2kio+MWxdk041mtmUxL2jOhKEDeLcyCZQya+oaX O72pwfGdSutn1m74MS7ujnf1dBUSbUVQux0PoPsUWtOitjQ6LvRmSnPZ98ym0IYWlJV2S6chKepO 6AQEACH5BAAgAEUALAAAjAGEAi0ABwj/AO0JHEiQoJSDAg9KSaiQ4cKFCe01RMgw4kOKFhsalBhR IsWHHj1iHAixJEKMHzmaNFmwIESRL0dW5NgxJUuHN0nSXGkxpMKXOneejFlSpcOZP10ORbmS6FKD Q0nanAm1acuPGrH21Koya1SkXqHClIpT6VikQaViBXr0rFqiZLu6VYs2Z8u7ePPq3cu3r9+/eIHG pGm0Y+GiiIu6JCx4q86UjBfvrDl56tW8g3sS3ng44+LBiimD9DzZMOXSoy9q/pw2subRhWMHRfxY cePVt2GnJs0WJGjRuDeX3qyb8+/KkmPfVs658+PhyzdCZgu4uvXr2O/+2869O/flxaGj/x4bnXna k89PC086PulxuoHPzxX5emLVyOwNow/u+u3pi/vJRl9ms9UWYHi9AYebRvr1R1567p2H3nGJHbhe gwO2FhqAtDUXXoME4ueVbxialmFZ3qWo4oostujiizDGKGN34PVXnG3EJWeeaTcWyKN0CoJonIk2 CvffcK71eFl65oXYGI415uZgcFHK56OSRuKnoYdIZkYbhatpOeRrDm54YYL8CfljmF+WmOOO9swo 55x01umiXyOCuNZuQuk20odvZgXkmmT2meRaRBLI0308BkjfWQwGClmaOeJ4oqGXCraUU4c+dWVb mvY2qagIHpXbhBDWZOGZs63K5KJZsv8XKahbqspTh+shGmp2vPbqK18w/irssMQWa2x11B2rrHXJ Luvss9AS22y01Apk57XYZntntdx2622xs37L7bTilmuutOemq+63wa7r7rvwxivvvPTupe29+Oar 77731uvvvwAHLPDABBds8HXt9jUtueSiezB2DT+ssLQR+1txxcuGmBe/HHfs8cf9DrvwXaERKSya vzacLMZ8ockyYAybjJnMJO+l8l8sv7ykshfDTDOyAkpcbilCjzvzkjpnlzTONjvr8rExZ3m0w1O3 TO3STFudtcitFe31XnrQu6d/9y26aUZMyWQqXO0xmB9YXE0VN6RfhUS3WPnJNBGnA4r/WhGqdvfd ZIJ524e2T3DujWtXo8Jtt6AAmuXW24FHqOpWvs0duVhGbYj116B/i2V0Sv723srqdf5qmVSKVrLq he72nnp8Hnl6fLYRPiafT65+e+UXisiagriaOellvw+PXGVQFng8aySmHvr07xqe+KDOwQ7np33f 7qT1qYFPV+loY0n7XM0fqRTvZe/eZ++tqw+/j0GXatV4bF5locbiH9Z/7o6ijn02Nx/qGdBcxWOd 74T0Oyl1Jn3Xk0/JvOSY2L1JQMar2fLE5LzzySZ9qPOeBH/0tDDxp3apMqGUkrfBDtWIg8EDDvua c8Aaeut/szKc27TkJUFxT3wIyuGq/25lHMA5h4jSC6IDzfY8H8LmUZDT0J86ZZUo0lA/z9vRrpw4 Kr0NUYj3I04AGWcq+IxvcK+zoRp5lTB3PZFna4wj0ORYNJDZ8Y54zOM/BhYuY/WRjoC8YiAHScjQ 6fGQiEykIhfJyEY68pGQjKQkO1bISlrykpjM5PQmyclOevKToAylKEdJylKa8pSoTKUqV8nKVrry lbCMpSxnScta2vKWuMylLnfJy17OiRit1KQwh0nMYhrzmMhMpjKXycxmOvOZ0IymNP/iy2pa85rY zKY2t8nNbnrzm+AMpzjHSc5ymnOV00ynOtfJzna6853wjKc850nPetqTjufMpz73yU7PfvrznwAN qEAHStCCGvSgubynQhfK0IY69KEQjajXEErRilr0ohjNqEY3qi0n6FOiIA2pSKnH0ZKa9KQDHalK V1odlB6SpTCNqUzXFRAAIfkEAE2iRQAsAAC4AYQCLQAHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qc SLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pUmG+ly5cwY8qcSTNivpstcd60p7NlQZwDfQoUylMn T4I5jQYVupNoTqRGgSqVihQq051Dqy7FujWoVqhdfzatqvSo16JNo3JlurDs0LVk0XI1+1aq2550 jwKVa3Av3791w8p96tUp2sF0nfotatXn3bOHs0L+y5ZozcuYKf7bzLkz57ygJf88C3e0aL0I1xLO ajmvY9KnLbOVXFr0bLOGxcI2DXe24daJbYfuC9l35cmxDwIPvns58+O0m3/97fsr6ulLkTtfXX1y 9deew4v/H0++vPnz6NOrX8++ffuGrYHHH014fvLlT/PHNR29f+7dheFm3WqsWSfggVrV59qC8gFI YGr7BfiagQsSp5x3/VkYYIEcbvjfbwf+d11x/vFH3IQbJhcdipm16GJGjqU1l30ehnaVWnOhpl+K GALGomynXUcgiBGCNuFi0g1Z4WI3mhgYhkC+BqSJj11Y115NGshdcFHmeJuQCBqp4ZGCISlckYrN iNyLbLZpD3pEOinmVWMWmWCHI/bYnYhhjqgmj3nKhuVwKI7F45Rcymklnn4i2qOizGX4KGtYDhoX onFixWd8frkVJI1RDkhiVu6VauqpqKaqqqoOQadod0FG/5rnnYHaSGuIWo4q4m2wVsihfZmqOGqY zmF35qYaEgqhijQeK+eexuL547NUOtlsrx+u6ea2L6J3JWKxPunrsHpVSVqltdmlqYxJyVjmgEh2 qq6SX1JVGJPoZntmW/HWJqZY7H4Zbbntyucvoel6ZymlAjfLYL6LigvYtySuavHFGGes8Xjcduzx xyCHLPLIJJds8skop6zyyiy3PNHGGGcA88w012zzzTjnrPPOPPfs888Yuyz00EQXbfTRHQOt9NJM N+3001BHLfXUVKeH9NVYZ6311lx37fXXYINERNhkw1T12WinrfbabLft9ttwxy333HTXTbcudttd 9t5898Dt998d5S344IQXbvjhiHMM+OKMN+5434lHLvnklFduOc2PZ6755px37vnnoIcu+uikl276 6SRdrvrqrLfu+uuwxy777LTXbvvtuOeu++689+7778AH/w/qxBdvvPHCJ6/88sxDffzz0Ecv/fTU V2/9yc1nr/323Ad9/ffghy++yRSMb/75IHev/vrst98Z+vDHL7/Z7tdv//3456///vzPPf//AAyg AAdIwAK6pH8ITKACF8jABjqwfwaMoAQjGBAAIfkEABsARQAsAAAAAIQC7AEHCP8A7QkcSLCgwYMI EypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8ps+K+mzZs4c+rc ybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1aAzs2rdyrWr169gw4odS7as2bNo06pdy7at 27dw47IkBRKc3Lswr+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0t2irey5cuYM2teO7mz58+g Q4seTbq06dOoU6tezbq10c2wY8ueTbt2Rde4c+uODADA7t/A/9keTrx4wd4AjCsnG7y58+dOe0Of znq59euVk2Pf7pW69+/gw4v/H0++vPnz6NOrX8++vfv03OPLn0+/fsH3+PPr38+/f1MO/gUo4IAE FmjggQjyZN+CDDboYGYJRijhhBM+aOGFGGao4YYcduihbRSGKOKI+n1o4okopqjiiiy26OKLMMYo 44w01mjjjTjmqOOOtZHo449ABinkkERa5UWRwvGo5JJMtoTkk0y5AeWUVFZp5ZVYZqnlllx26eWX YIYp5pgGNmnmmWimqeaabLJE5ptwxinnnHTWaeedeOap5558+tTmn4AGKuighBZq6KGIXtjnooyi l+ijkKLY6KSUfhfppZhmWOmmnAKX6aeghirqqKSWauqpqKaq6qqstuoqXEOR/9HprLRG9uqtuOaq 66689urrr8AGO2qtxBYrmrDIJqvsssyWZOyz0ELW7LTUVmvttfZEq+223HbrLXTYhivuuOSm+u25 6E5V7rrstuvuu/DGK++89NZr770Hpavvvvz26++/fGED8MAE14SNwAX3ey02+DZ8KMMORyzxxPIl bDG/FGes5psVXOwxXxqHbObHJJds8sl3iqyykii37PLLMFO58sw5xmwzozTnXOPNPO/ZpB86NwwV AQT60fPRdRp9ZSlIm8ck0EFH3SLUUtd7pdJNZw3UklRXTa/WYIct9thOHUL22WinrfZ5Xrd94tpw F+n23HTXPXHceOet995F2f/t94N8ezmGy38XvmC0tgTeqeElsTNvL/EpLvnklFdu+eWYZ44x45x3 7nmwiTmi+eiLfW766ainrvrqpLfu+uverj6xPrLXbvvtuMOuu6W49/7W7sCD6/vwnBlLSvB0Eq88 Wsg3/9vy0EcvPYfOV2/99V5Orz1X2Hfv/ffghy/++M0J0+f26M9EPoIAru9+8Om3Kkv89Ndv//34 o/7+/oglq13+APzI/wJIwIwMsIC16Vq9DojABkqEgQ500L98w78QNQuCEcygBk1UwQ4KZoMgXAiY KOjBEuqFhCZMoVSko8IWQgWFLoyhUmAowxoWhYY2zOFPWKjDHu7Qh0AMYrT/uiDEIhrxiG9iBRK5 FMImOvGJUIxiQpZIxSpa8YpYzOL6CBIJKR7Oi2AMoxjHSMYymvGMaJSUFtfIxja6sXVpjKMcZfdG Gc7xjnjsXB1jmMf77dGFfbTfH1sYyPoN8pCITKQiW1bIRjpSZ4vs4CPR95hGRFJrk8ykJjfJyU56 UlOXDKUoz/bJUprylKhMpSpXyclRuo+VtXOlLGdJy1ra8pbwgaUud9kqXHqPl6nzpTCHScxiGvOY yEymMpfJzGY685lHBKY0p0nNalrzmtjMpjYlMoWJSSEivmhYGOwGzXKa85zoTOcSt8nOskSgnZtR pzznSc96UgaedLOn5PCZ/099+vOf0AoHQAdKUMXwc24FFeIHErqpgzr0obsSBkQnStHuMHRtFQ3a RTGa0ZxtVG0dDalI6/PRks7JklQcqUpXah2TkpKlMI2pTM/YPXe49KY4zalOd8rTnvr0p0ANqp9m StSi3kWoNzMqolqQFqRuShJO3Z1ShRbVl00VX1W16lXtlVXCbXVaoPiqWMdKVgB29axorUpZ45VW k1E0rJBsK8nWyiOJ0jWAcs2rXl9z13bt9WIqSUZfScUfov31sIhNrKMGuy7FDoyxkI1sRhwLMMmO i7KYDWIiMstZpApUizaVq2XF1dnSmva0jRptuFDL2p42QrWwja1sydXa2P/N9ra4zS3oasvb3vo2 S7oN7mB/S9ziGhdIwk3uWo9bLOUKi7nEcu5uoTsr6QKLurSyrnaNit3uonO74A2veM/kXU6NV1T1 eEh5G3reW623Uu1173snFd/6QnS+9B1Jb4gHCRDuhYf4DRJKMGjfUu23wCSxhH0Ag8MAV2glB0Zw k2ChXwJLOFQWvnCKDANgBx9oJhluZx945eES41LDKLamiX2W4ha7+MWyWbGMZ0zjGtu4pDAW1Y1X iFx6ccJwEc4xpIIsZEQhp8hDDrGLbtwPo3R4xyNsMJGQTOVOQllOVc6ylrfM5cte+ctgDrOYx0zm MvO1y2hOs5o5YuY2u/lvzXmaAHXXTCg4b4nOg7LzaNqxGzz7+c+ADrSgB03oQhv60IhONPX0zOhG O/rRkI60pCdN6UoPUtE4ggCmr5oDVM1g0620tKhHTepSm/rUqA4wqFetvVS7OnOs1tGrLRjrWtv6 1rjOta53zeteWyggADs= ------=_NextPart_000_0008_01C6F538.5E7B4B30-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 22 12:57:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbgde-0003xZ-IL for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 12:57:30 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbgdc-0000sn-Rc for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 12:57:30 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B98B4431760 for ; Sun, 22 Oct 2006 09:57:16 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id E08114A45C3 for ; Sun, 22 Oct 2006 09:56:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D0873398046 for ; Sun, 22 Oct 2006 09:56:49 -0700 (PDT) Received: from web60313.mail.yahoo.com (web60313.mail.yahoo.com [209.73.178.136]) by zoidberg.tigertech.net (Postfix) with SMTP id 30A5739803F for ; Sun, 22 Oct 2006 09:56:46 -0700 (PDT) Received: (qmail 95754 invoked by uid 60001); 22 Oct 2006 16:56:45 -0000 Message-ID: <20061022165645.95752.qmail@web60313.mail.yahoo.com> Received: from [67.166.240.5] by web60313.mail.yahoo.com via HTTP; Sun, 22 Oct 2006 09:56:45 PDT Date: Sun, 22 Oct 2006 09:56:45 -0700 (PDT) From: Behcet Sarikaya To: capwap MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=2.747 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE X-Spam-Level: ** Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092248365==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --===============0092248365== Content-Type: multipart/alternative; boundary="0-838192032-1161536205=:93895" --0-838192032-1161536205=:93895 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Some general comments first. CAPWAP is a protocol for managing Split/Local = MAC WTPs. Support for roaming STAs is a small part of CAPWAP which could be= considered orthogonal. Roaming text is geared towards Split MAC WTPs. Some= people argued that 802.11i cannot be supported in CAPWAP because there is = at least one value, i.e. KeyRSC should be set by WTP.=0A=0AThe same goes fo= r 802.11r. There could be tendency to use CAPWAP only for management and us= e 802.11r for roaming especially when WTPs are 802.11r enabled.=0A=0AHoweve= r, in draft-sarikaya-capwap-fastbss-00.txt we argue that CAPWAP could be ha= rmonized with this new technology called 802.11r. We came up with a solutio= n and we expect to receive constructive comments for improvement.=0A=0A----= - Original Message ----=0AFrom: Charles Clancy =0ATo: Be= hcet Sarikaya =0ACc: capwap =0ASent= : Friday, October 20, 2006 9:21:00 AM=0ASubject: Re: [Capwap] CAPWAP for 80= 2.11r=0A=0ABehcet,=0A=0A11R D3 8.5A.6 (attached for those interested) defin= es the basic =0Aproperties and summarizes the exchanges, but I don't see an= y packet =0Aformats, transport mechanism, link security mechanism, or metho= d for =0Aestablishing a trust relationship between the MDC and possible KHs= .=0A=0A=3D=3D> 802.11r has all those. My proposal is AC to be the MDC and P= MK R0 KH and Local MAC=0AWTPs PMK R1 KHs. I suggest that you read D3 and we= can have a face to face discussion in San Diego.=0A=0A=0AIn CAPWAP, there'= s no AAA context to transfer, because the AAA context =0Aalways resides at = the AC. Using the existing mechanism for key =0Adistribution (via Add Mobi= le messages) is sufficient for transporting =0APTKs to the WTPs.=0A=3D=3D>I= n draft-sarikaya-capwap-fastbss-00, we have that for SplitMAC operation.=0A= =0A-- =0At. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clanc= y=0A=0ABehcet Sarikaya wrote:=0A> Hi Pat and Charles,=0A> =0A> Section 8.5= A.6 in 802.11r D3 describes the key distribution protocol. It =0A> is true = that earlier versions like D2.2 did not have it.=0A> So my Local MAC scenar= ios were based on this protocol.=0A> The key distribution protocol makes = it unnecessary to use the context =0A> transfer ahead of time and it is qui= te nice to generate and transfer the =0A> key in a just-in-time manner. I t= hought it was good and used it in CAPWAPRP.=0A> =0A Regards,=0A=0ABehcet= =0A=0A=0A=0A=0A=0A --0-838192032-1161536205=:93895 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Some general comments first. CAPWAP is a protocol for= managing Split/Local MAC WTPs. Support for roaming STAs is a small part of= CAPWAP which could be considered orthogonal. Roaming text is geared toward= s Split MAC WTPs. Some people argued that 802.11i cannot be supported in CA= PWAP because there is at least one value, i.e. KeyRSC should be set by WTP.=

The same goes for 802.11r. There could be tendency to use CAPWAP on= ly for management and use 802.11r for roaming especially when WTPs are 802.= 11r enabled.

However, in draft-sarikaya-capwap-fas= tbss-00.txt we argue that CAPWAP could be harmonized with this new tech= nology called 802.11r. We came up with a solution and we expect to receive constructive comments = for improvement.

----- Original Message ----
From: Charle= s Clancy <clancy@cs.umd.edu>
To: Behcet Sarikaya <sarikaya@ieee= .org>
Cc: capwap <capwap@frascone.com>
Sent: Friday, October= 20, 2006 9:21:00 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

Behcet,

11R D3 8.5A.6 (attached for those interested) defines the = basic
properties and summarizes the exchanges, but I don't see any pack= et
formats, transport mechanism, link security mechanism, or method for=
establishing a trust relationship between the MDC and possible KHs.
=3D=3D> 802.11r has all those. My proposal is AC to be the MDC and = PMK R0 KH and Local MAC
WTPs PMK R1 KHs. I suggest that you read D3 and = we can have a face to face discussion in San Diego.


In CAPWAP, t= here's no AAA context to transfer, because the AAA context
always resides at the AC.=   Using the existing mechanism for key
distribution (via Add = Mobile messages) is sufficient for transporting
PTKs to the WTPs.
= =3D=3D>In draft-sarikaya-capwap-fastbss-00, we hav= e that for SplitMAC operation.

--
t. charles clancy, ph.d. =  |  tcc@umd.edu  |  www.cs.umd.edu/~clancy
Behcet Sarikaya wrote:
> Hi Pat and Charles,
>  
= > Section 8.5A.6 in 802.11r D3 describes the key distribution protocol. = It
> is true that earlier versions like D2.2 did not have it.
>= ; So my Local MAC scenarios were based on this protocol.
>  = ; The key distribution protocol makes it unnecessary to use the context > transfer ahead of time and it is quite nice to generate and transfer the
> key in a j= ust-in-time manner. I thought it was good and used it in CAPWAPRP.
> =
  Regards,

Behcet


--0-838192032-1161536205=:93895-- --===============0092248365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0092248365==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Oct 22 13:43:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbhM7-00066z-UJ for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 13:43:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbhM6-0000ax-Cm for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 13:43:27 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id BCFA03980AE for ; Sun, 22 Oct 2006 10:43:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id E0E924A43C6 for ; Sun, 22 Oct 2006 10:43:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C843139802A for ; Sun, 22 Oct 2006 10:43:14 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4D0A6398041 for ; Sun, 22 Oct 2006 10:43:10 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc12) with ESMTP id <20061022174309m1200c9toue>; Sun, 22 Oct 2006 17:43:09 +0000 Message-ID: <453BADAC.60009@hyperthought.com> Date: Sun, 22 Oct 2006 10:43:08 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Hasan Raza References: <389468.1161381258661.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <453A7404.3070104@hyperthought.com> In-Reply-To: X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hi Hasan, Hasan Raza wrote: > > Hi Scott, > > I am sorry that I missed the point that discovery packets > do not result in any state change at AC. Actually, the DoS > issues I raised were the outcomes of the wrong assumption > that discovery packets change the AC state. Of course, > differentiation of discovery/DTLS packet by looking at the > wtp session would be a bad design, I beleive. > > However, I can think of two other ways to make the distinction > among discovery/DTLS packets. These solutions (if they work) > would be less costlier than extra port or mux-based solutions: > > 1. Checksum at the end of discovery packets: > All incoming packets are checked for _discovery-like_ packets > by looking at the head bytes (as Pat proposed in this thread). > If the packet looks like to be a discovery packet, then it > is submitted for checksum calculation. The calculated checksum > is compared with the last 4 bytes of the packet, and a match of > the two would mark the packet as discovery packet. Otherwise, > packet is submitted to DTLS module. > > Drawbacks: > - extra processing at AC for false positives. > - overhead of checksum calculation for discovery packets at > WTP/AC. > Limitations: > - The mechanism to identify _discovery-like_ packets will affect > the false positives and thus packet processing performance. > > 2. Reserved length for discovery packets: > All discovery request packets sent by WTP are of size L (say 240 > bytes). Padding is added to the discovery packets to make it of > exact size L. In case a DTLS packet to be sent to AC is of size L, > then a (new) pad message element is added to increase the packet > length. > > Limitations: > - Selection of size L is critical. Note that DTLS layer may also send > handshake packets of size L. If DTLS handshake packets does not > following any lower/upper bound on packet length, or packet length > alignment, then this scheme will not work. Otherwise, a very short > lengthed marker message (of say 4 bytes) can also be used to > mark the > packet following it as discovery packet. > > The latter solution looks like to be more of a hack, but I have put here > to give it also a thought. However, a combination of (1) and (2) may > Proposal 2 should be a non-starter - I agree that artificially limiting the packet size really is a hack, and in my opinion, it's a short-sighted one at that. Proposal 1 is also a hack, albeit slightly more subtly so than proposal 2. I can sort of understand why one might think anything which removes the need for a 3rd port is "less costly", but in general, I think this takes a rather narrow view. After poking around quite a bit through various uses of TLS and DTLS, I can find no example where someone tries to combine unprotected and protected data in the same channel, which the exception of DCCP (draft-phelan-dccp-dtls-00.txt). In that case, the unprotected data precedes the protected data in the packet (i.e. DTLS encapuslates a payload). I guess that here in capwap, we are now and forever doomed to referring to the unprotected bytes preceding the payload as a "mux-based solution", and with that we'll get all of people's related baggage and anxieties. I would suggest that everyone be objective about this, and reflect carefully on your reactions ("Search your feelings, Luke - you know it to be true!" :-)). But on a more serious note... this does not serve us well. To unambiguously delineate between these two data types is very simple: give the capwap discovery protocol its own port, or add a type descriptor to the packets and encapsulate the non-discovery payloads in DTLS. No protocol gymnastics, no hacking - both are simple solutions that allow fast and definitive hardware-based switching of these packets. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From vuiulhypwua@saia-burgess.com Sun Oct 22 20:23:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbnbc-0000G4-65 for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 20:23:52 -0400 Received: from [222.94.123.116] (helo=[222.94.123.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbnbZ-0006mC-0G for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 20:23:52 -0400 Message-ID: <001301c5d768$361391f0$747b5ede@USER675494B64D> From: "..." To: capwap-archive@lists.ietf.org Subject: level then from Date: Sun, 23 Oct 2005 08:25:02 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C5D7AB.440E3B50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 ------=_NextPart_000_000F_01C5D7AB.440E3B50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C5D7AB.440E3B50" ------=_NextPart_001_0010_01C5D7AB.440E3B50 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable By Grade Level strd of thth th Subject Abcs Geography Math. Then from like mr Elephants a Matching Mayhem go Today Membership gives = parents. Traxx Here is game that easy but am makes use your brain a want am = highest possible scores Counting this fastpaced for free help facts = faster count better score Wordsearch? Random any difficulty level it now Traxx Here is of game that easy but = makes use your brain want highest possible scores of Counting this = fastpaced for free help facts. Strategy hand at running very own virtual stand Read more Kids in Click. Hand at running am very own virtual am stand Read more Kids Click we = fun. With of if you enjoy puzzles is will love our new game try in. Link to us Activity Search by Grade Level in strd is thth th in Subject = or. ------=_NextPart_001_0010_01C5D7AB.440E3B50 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
By Grade Level strd of thth th Subject = Abcs=20 Geography Math.
Then from like mr Elephants a Matching Mayhem go = Today=20 Membership gives parents.
Traxx Here is game that easy but am makes = use your=20 brain a want am highest possible scores Counting this fastpaced for free = help=20 facts faster count better score Wordsearch?
Random any difficulty = level it=20 now Traxx Here is of game that easy but makes use your brain want = highest=20 possible scores of Counting this fastpaced for free help = facts.
3D""
Strategy hand at running very own = virtual stand=20 Read more Kids in Click.
Hand at running am very own virtual am stand = Read=20 more Kids Click we fun.
With of if you enjoy puzzles is will love our = new=20 game try in.
Link to us Activity Search by Grade Level in strd is = thth th in=20 Subject or.
------=_NextPart_001_0010_01C5D7AB.440E3B50-- ------=_NextPart_000_000F_01C5D7AB.440E3B50 Content-Type: image/gif; name="collection.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c5d768$35eafb50$747b5ede@USER675494B64D> R0lGODlhgAL8AYf2AAEBAHcACw13AIp3AwsAjIUEigB4eLTCsbzgtrLV/UggCmsUAIokC5kYAMQa BuUsAQdODSRDAEI7Cl84AHM1BqU3AMJJB98zAwRjACNkAEBiAGpiDIJdAJhRAM5TANFbAABxCBKF CUB4AFJ8AoZ0AZ9+C8qKC96BAA2ZCCiqAEKXAFORCYWRAKCkDs6cBu6hDgDFCym6DjOxBWnMCX3G Dp3AAMzBDuKyAAzmABvSBEDkAFfZC47mAKzZAL3pDtniBAAOPhsNTD0BMVsCTIwAMqwJRcsFNNoA QgUZNCMYMzEiTmYqMXkhQJIjRcolNN0cNQFBSyE2Qj9OSVxIM4VGQaZHRcZMRuxCRgBaTRxYOzhh P2FoP4xXEaBhNcxZP95RPwB/MRJ7QTKKTWODTIKIMZp1RL5yNdF3TQaSTB2gS0eYP26uNHutPZap RryZM+ujPQG0MR/ORk3AM1zMSXm7R5fNO7e9N+W2SwDgQiPdPELpM2DSRYTVM6bbNLHuNd/iPwAO gywAeTEAfmUAeYwAjZgEgroAhtQAggATcSARgzoScmEed3UagqYUg8skhtMdfQE9cRNJfDM+fWpC doI+hahLjrk/c9xGcwlhihtiejZthFpieIprc5FchrhreNpufwCAjiWEcTh2i12NdI5xdJl0isx0 jNyBfwioeySTjTOqjGKqeXesdJWijcandN+jiQTMcye7iUe6cm2xhYvHe5zOjbu+f+S8fADkfhnq gUPnfmPhjILSjZ7jiLjZdN7rgQkDvS0AyzMIyGcAy4gBxZgAurYMvO4Dtw0lzC0RvjcmzWkZuIYZ vaMiuboouNouvARGsilDwTQ5vGlCuX5DwZM9tL4+zuBEvwNRtx5XuDZTwmVjuH5ksqdWs8husdlj yAZ6yBaCuDR9zGGFvnt2w5OLvMV/tNhyswWXyC2RvEepyF6gzHWYtqugtbaftOGTtg66ux63u0e1 sWPHuH+6ypWxy/P88padqHuNjvoDAAD/BvXyBgAK//YA/wLw8v/8/iH5BAAOAE0ALAAAAACAAvwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKLGivps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cKHOnEu3rt27ePPq3csXY9y/gAMLHky4sOGwfRMrXsy4sePHkF0enky5 suXLmDN/jcy5s+fPoEOLZqm5tOnTqFOrXs26tevXsGOjHk27tu3buHPr3s27t+/fwIMLH068uPHj yJMrX868Oeim/ax6kE29uvXr2G863869u/fv4MOL/x9Pvrz58+jTM8/Ovr379/Djy59Pv779+/jz 69/fXr3//wAGKOCABBZo4EP8Jajgggw26OCDEEZo2YEUVmjhhRhmWJc9Gnbo4YcghijiiCSWKNMm nkmo4oostujiizDGaJ+JNNZo440hrYLjjjxqJOOPQAYp5JBEFmnkkUgmqSRrPTbp5JMGLSnllFRW aeWVWBIG5ZZc+pZHYlmGKeaYPXVp5pkikqnmmmy26eabQqIp55x01mnnnYplkRGcfPbp55+ABiro oIQW+hSeiCaq6KKMNpqSoZBGKumklFZq6aWYWglBppx2GpSjoIYq6qiklmrqqaimquqqrLbqqqie xv8qK2Cv1mqrZLPmqmtanXlw669m7irssMQWa+yxyCar7LLMtgjss9B+lEa01FZbUbPYZlumtdx2 y5C24IbLobfklmvuueimq+6z4rbbLExvrCuvje7Wm+y8+Oar777B2usvpH8cxe/Apf5r8K4EJxzq wQzLqvDDEEcs8cQUV2zxxcVRUV7DHHfs8cdIYizyyCSXDBnIRgWC8pgmt+zyyzDHLPPMNNds882s rqzzzjz37PNQw/wstFE4F2300S0PrfTSTDdtGNJQb+z01EtGbfXVWGet9dZcd+311zNTLXbIYJft 29hop6322kzhhcDbcJstd2hwIzD33T72DAAAbPf/reLefgf+IOCCF74g34YniffijDeOY+KQJ+j4 5JQvzkXlmGeu+daRd57f5qCHLvropDvpOZ8SSHD66vOlzvrr77kO++zYqU777bgLXPruvPeeW+7A u+b78CUFb7xqxCev/PLMpytL89BHL/26x1dv/fViTq89gth37/33SDkB/vjUdSP89ugrRP767Lev YPrwxy+/+u7Xf9b8pgqA//789+///96xhzPsR0CxNGcBAEygAhfIwDkV8IFgaaAEJ0jBCsYMghgc yzYyyMEOejAuFiTeB0dIwhLyKoS+M6EKV8jCrKAwhS2M4U9e2DsZ2pAnNMyhDmt2wx7iZIek86EQ /4coRCCOjog9NKISl3gxJDrxiSVkohSnSMUqWvGKxIFiDLHoOC168YsE5KIYx0jGMprxjGhMHxhV mMY2uvGNcIzjFddoQjlyblABo6Me9/geO/rxj4C0Iz0COSckkIiPHySkIhfJyEbuCZEddKQkJ2kg SEaSkjy0ZAYxyclOnkeToATjMmDnyVKaMoChTKUqV8lKZJ1yVZLYUCtnScufvfKWuDROLdmXy176 sjeDicQuDaaYSBjzlxMzZiSQmSi3GHOYHruLMpkZsWlS01FmeSY0t8nNbnrTOtcMpzjHSc5ymvOc 6EynOnskjXW6853wBM4350lPZcXznvi8SD33yf9PhOXznwBtSD+DF9CCGpQmA02oQit10IYWdKEQ jahEJ0rRilr0ohiNkEO9ldGOevSjIA2pSEeapRABYaMoBRtJV8rSnIyBP3tDXEunRpCYAiClt9qJ TWeatp3yVGcQuSlOyaUB36hiqL/5qVKXytSmOvWpUI2qVKcKIaRa1ZxUteVVt8rVrvYrq2A9TTDC StaymvWst/OqWtfKVhqhFWRtjasn30rXutqVlHJVVX3Ed1f95JUg4ChYXw/218Ia9rDmGSxhETsR TjCWioqNbN/2QNk9xGpTRkGEXSvLWctKVlmd1dVjRwvHz9qLtKg9yQX8Z9p6pRabkAxDa2dL29r/ Ri4Rts2tbvv22t6OcbfY8q1/iiFciAiiuKUE7ruQy9wlKpdZzb3Tc5cVXTtN97pvNU4TqssZ7LqS u+ANoXfHS97ymve86GVQeB3zjuPABRzpja9853uZ9aKJvvgVqX33ey4diSe/APYof7sU4EwNmEsF rtIlFsxgBttrFVRtsIQT/K8DWziB7b2whjfMXQp7+MMgDnHuONwjEZv4xCi+igJSzOIWu7hP6nix jFlHYh7N2E813tGN+5Tjx+34x3vssZAvJo8hG/nISNYnkN2U5EMu+clebLKUp4xUKFv5iVTOspYN emU1bblDXSbTl8dM5nWGmWVlTjNJihCxM2dPg81wxpqb59zCONs5anTG0p0LlOcr7ZlAfbbSnwdN 6EYG+tCITrSiZ1To/yzaLAaoTqMd/WiyTfrSMjluqiptaUzTpQueDrUIOW0kUSeW1Kjunqmlluo4 rbpipHi1QcQga/e2+ta47mutd83rCuYaSL0ONmM6Qa9fGxuvwnbOsZe9uoAAACH5BAAOAE0ALAAA AACAAvwBBwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHKnwn8mTKFOq XMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWUJLNq3cq1 q9evYMOKHUu2bNiraNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePH kCNLnky5suXLmDNr3sy5s2fEZkOLHk26tOnTqFOrHvm5tevXsGPL7ltttu3buHPr3s27t8zVwIML H068uPHjpX0rX868ufPn0KNLn069uvXr2LNr3869e9wK3sOz/0VOvrz58+jTq1/Pvr379/Djy+cq vr79+1bn69/Pv7///xHhJ+CABBZo4IEIogXgggw26OCDxSUo4YQUVmjhhRhmqOGGHHbo4Ycghiji iD9BaOKJKKao4oostujiizDGKOOMNNZ4Iok45ihVbW7Z6OOPQAYpZJA2DGnkkUgmSWM7Sjbp5JNQ RiklfDpWaWVlU2ap5ZZcdunll2CGKeaYDlJD5plopqkmWVe26SZja8Yp55wevWnnnXjmqed9dPbp 55+ABirooIQWauihiCaq6KKMNuroo5BGKumXf0xqaUKUUHLpppw6mGmmnYYq6n6fajrqqaiuB2qq rLbq6kR7xv8qa1yJOvPqrbjmqquWs/bq66+Z6QHssMQWa2yJuyarrFfHNuvsswW+AO201Fbb2bLY ZqvtttymZu234P7T7bjklmvuuReFq+606Lbr7rvwbrvuvPTWa6+b8eabrVSn3OvvvwAHLHBuSgyM mSMGXylMwgw37PDDEEcs8cS6oZaKvhh7SfHGHHfs8ccghyzyyCSXbPJMGaes8sost+zyyzCTZUrM NNd8axk256yzoCf3XN3OQBvq89DRBW00z0QnzRxBmxztdJxKRy311B0/bbWcVGdt29Vcpxm1AJvR ovXYZJdt9tlop6322my3/a8Cbsct99x012333XjnrffefPf/7fffgAdOU9eEjyn44Ygnrvji2xXu +OOQRy755JRXbvnlmJPJ+OZLZa7aAp5D2UPopGfF+elHla76i6i3PtTqsK/o+uzIxm47hLTnrvvu vPdOmRB5ouD78MQXb7xrtyevfLs0FH788+IuL31/0Fdv/fXYt04QC9Mva2uf2ftO0T3dl2/++YaH r/76h6Pv/vvwq8m+7vHXb//9+OeP6/y56+///wAMoAABxb8CGvCACEzgTg6hQD0N8IEQRBMTdtZA ujAhYhFM0QQzyMGRbLCDIPTIB2tWQQtCLIQQGmHMSrg4FLrwhTCMoQyPw8Ia2vCGOBwWB/cxwx4y ZB889KEQ/w0CxCFi5HBA3EcO+QbEJTJRiTjEXxGNSMUpUvGKWMyiFssDiC0G6hIycqIYx5gwL5rx jCEkoxrXaC809pCNeXPjDOFIxzra8Y54zKMe98jHPvqRO3KU4R8HSUgQBfKQiLRfIc+WyEY68pGQ vNoiJ0nJSloyP5HM4CU3yUnxZPKToMRcJ6UWyu6VgiKjTKUqqVPKAa7ylSQzwtRaSUtBcaCWuMwl R2DpM13qj5cIKgIwh0lMaPnymMhMpjKXyUz+FJNY13imNKdpn2Za85rcoqY2rwKJbXrTbtg83zfH Sc5yGi+c5jOnxNBZPnV2pgvQYeeZuuAkd77zOfKcZz6XR//PawIAAPtc3j8DajqI/dOeDzvoN432 T4AS9HYDfajtIipR2FG0oqpzKEYhglCHmScHGw2pSEeay46a9KQoBSdJV8rS9KU0YC2NqUxnStOa 2vSmUXqpwHAKOZ1aBwk+Dapd6iFUtfD0cUW911Edl9SmSiUXTo2qA5dKOKla9aprJAVWt0oYqjaK BOjhqljHStaymvWsaAWmV7uW1mOtlWs9C8S8gqChtyJzB3blVVv3yte+oiUVscmrYAc7H78adpuE NdphfZXYxjr2PIvt1WN1FtlZTfaymM2sZjfL2VZW9rO87KzLQLsn0Zr2tKj1HGmnmtrWuva1sI1t V1abJ9n/2va2uM0YbXd7pXLw9rdrQQVwh0vcqOb2uMhNbjaLy9zmOve5UVMuuaBLIumOi7rYHaN1 t8vd7nIqu+DNoXf3FV4PjRdb5U2vetfL3vYW8rzwja9857tM9+roBsNsqELtSyD9npC+AA6wgLfE XwsN+MAzLXCFEMwqBTsYegyOsIQnDKMHS4jCorKwhjesXgyjr2keDrGIR0ziQ3HYQCVOsYpXzOIW i/bEMJ6di2eohhlbcxE2zrGOd0zLGPv4dDwO8iF/jB8hd0q/GjWyXnWCZAAQ+clQjrKU66LkKlv5 yljOshGnzOW9aRl8XW7cl+cU5jKb+cxoXsuYUXsE1JJjac0zSrN14Aw1OdvZbHRe052nk2evgrHP gBbNnqWDnkMEmjyDTrSiiXnoRv9y0ZCOtKTl7OhKWxq52wQexy7NafRN+tMi63SXQN0bUZtaVHVw Jql3c+olrxo3rY61rBv76lqvc9a49lxAAAAh+QQAEwBNACwAAAAAgAIrAAcI/wDtCRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjyvTYbabNmzhz6tzJ cyCXnkBz/htKtKjRo0iTKl3KtKnTp1CfeohKtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5AjS+YatLLly5gza97MWejkz6BD ix5Num/n06hTq17NurXr17Bjy55NuzbK0rhz697Nu7fv38CDCx9OvLjx48iTK1/OvLnz59CjY50m vbr169iza9/Ovbv37+DDi/8fT768+fPo06tf39W2+/fw48ufH5G9/fv4QdPfz7+///+a5SfggAQW aOCBCFoH4IIMNujggx95BeGEKjV1RoIYxkXhhhx26OGHIHL2QYgklsifhAJ9oOKI9qzo4osuHrQi QSoWxOJAMMJI440p7sgjjy3aaGOMKeqoI441IjmjkkQymeOILL44ZI5KypikQUDS6OSTS7KY4Zd6 cXRlkFlqidCVSY4ZpJBmYglklDemqeWPbPa4Zp07ImnnnmXieWePb545pJ5FEtqmkFnSKaOJjDaK kIRl9rknlmxCeeikf85pZqB83pnopotSCiqOpC7EKamS+nnqqaVS+mmrbIL/mR8JuvWZqq2LWgor prjSGWmncYpq569+AtpmqryGypCiiCqLKarCZlqqrNTStZGtRz6rra7Bqiqop9KuGWy3PqJppJS/ Mkult1Yiy6ym0YZLZrTrIuvovR16FeeMt37b7LDx4gowsVGW+irA8YYLZZPyXuqupO9CG7CyrApc 7cVwXeuqQgL/K+7EFBsrrK7zTkzspSL/aS+rCXWs8Msot8iwyv7ia3OIkHrsLLu+gkzvx4eSTLLD MPN87LLF7rzrqsWeXPFCGEd9mMzw1jxooZmqmbXVae6b59d4Fpww1VhzunLSLC/tNdZko/z0rtNK LfdZHhG5rrY+OvzmmC63NS3zyXhLWSS6LfPtaraDx/y31nD/3e6ZhAddbpc3V2755ZhnrjmIKG7u 6Nyg/+X5vaGXDlZAACH5BAATAE0ALAAAKgCAAisABwj/AP8JHEiwoEGD9hIqXMiwocOHECNKnEix osWLGDNq3Mix48GPIEOKHEmypMmTKFOqXMmypcuXMGPKnCmwo82bOHPq3Mmzp8+cNIMKHUq0qNGj SGH+XMq0qdOnUKNKnUq1qtWrWLM+lKm1q9evYKcmHUu2rNmzaNOiDMu2rdu3F9XKnUu3rl2hOgUw 1LuQb0K/AgILFqxw8N+GfvcStjc4cN+9jB0XbkxZMuTJhjFnRmw58uXJivt27sw48ubHhT9XTKzZ NGXRqhcfRp26NNzbuHPr9ppYb+/UrG2DBo6Y82PWkn/Pdqh8+WHAoYVDtJwcefTh1PmS9n29dPPg ErkP/3cO3jPq7OSla9/Nvr3793mJpw9uvbhq57XP55cem/bz/bOV559t4uFXoHj1Feidff/lJ+BD Cj5YXoQGOigcdPBlqOGGV3EFHYYN+jchg/gB2GB9zIkIGYjHhZcihS3+Bx53v80o340WHejiizFe 9qGF9twl5JBEFmlkSxcmiWN6zFV2n4kL0jedij3a6OSAJwK43pY8JmljiGCupuSUKXpZ5o/L8XXk mmy26SaS8SkJIor8mYiiYVaSVud+jX22XnEP7qkjf1wuCGhtCiKqJYSyARnoiAEKGumke3Jo6aWY gqVjb6epByGJdSaaJZZ8apmZlTuuqChtaKoa6Zd9kv8a3qmp+hlmmmZCmemuvPbq1Kas3vclltZJ OWalnpZK6aoRJdgjrssS2KKxxyJLZrVPzlfhjaL66u23vnJl3nh0IlcjqOMail2wny5KKKF/NgtY vH/Riei8BiaaXH8XJdhcpebWO1666ar55sEIJ6ywS+5uW6JrJU642GuLNkrls97FWq/Giv1L8LCm DegYxQ5bWyafFkM6sMUl27bwyzDHjBa4NNds88045wyVuDr37HNcMgct9NBD/mz00RARrfTSTI+E 9NNQRy21T9xMbfXVWGet9dY9Ne3112CHLfbYZJdt9tlop6322my37fbbcMct99x012333XRxrXdY TeyC7fffTuEt+OCEF8424IgnrvjijDfu+OOQRy755JRX7rjhmGeu+eYwW+7556BDzjnCA4xu+umo p6766qyzrtEZoccu++w2t2777bjnrvvuvPfu++/ABy88wrQXb/zxyCev/PLMbzT889BHL/301Fe/ e/NTp4H99lLzzP33ElkvfkEBAQAh+QQAEwBNACwAAFQAgAIrAAcI/wD/CRxIsKBBg/YSKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjxIPihxJsqTJkyhTqlzJsqXLlzBjypw5E6TNmzhz6tzJs6fPizSD Ch1KtKjRo0iTyvzJtKnTp1CjSlWotKrVq1izah2ak59Xfva+gk04NmxYrwu/klWrUCxYtm3Lio37 Ni3dsnHv4l3bEG/dtnfPwhUsFy3hwGvl2vVLeO/DuYzdBlZMt3Ffw2YBSwbMWXBnxXX/Th1NurTp 06gd7qU8lrLdzI85+3XNmnVEzGQfO478enXs3MB395W9mHZF35qH91YOnKHtz5eJB4ceGnbq69iz a4caVHhyxs6bq/+Wnrn1crPmHZ8XT168aPTMw0tH/jr59+bq47u3zh9+fO/24TdcevJVR2BdWyWo 4IIMNujgQa2hFRl9n+FWIXjmzZfbX4OVV996ianFm2dzfZihZ/35NqJou+HWImRstfgbe/y95xpx 73lYHXwIPujjj0AGKeRJI25oHYCdUZdWjOcVdqRzg6lXYpI2PpkfhgPqV6WTNI4nn5EfgvlliuGB RyZfyBloZI9Dtunmm3CShBNoGtKIpIAeBvjcdPtBN6aZ/vEZ6Jc3CupnkbDlp+Vii57Z5Z6J/ocn j/1tZ+mlmGaaGoyYgeaihB1OuiVcItY35ZN2mthblCKeOmWrn3b/GuuJkR5Xqmav3npkp7rN5qKk iRF6n6KaFmvsscgmq+yyzDbr7LPQRivttNRWa+212Gar7bbcduvtt+CGK+645JZr7rnIxqnuuuy2 6+678MYr77z01mvvvfjmq+++/Pbr778AByzwwAQXbPDBCCfcEroMN+zwwxCjpvDEFFds8cUYZ6zx xhx37PHHIIcs8sj3RmzyySinrDJFJLfs8sswxyzzzDTXbPPNOOes88489+zzzz6vLPTQRBdt9NFI J6300kw37fTTUEct9dRUV60t0FhnrbXHVnft9ddLby322GSXbfbZaKet9tpst20v2HDHLXfEQXEr Ekd3z321227b/30Q3n83XcFEg2NbuD1F6aA43wTnBMDjACgEueSRJ/S4PZBXbrnmmmPuueULdc75 6JRjnvloFaR+uOoKHW6P6qvH3nrsq7e+EOuuDw677bzvDrvuqc8OPOuvE897QsYX7rpFye+OvPG3 45687dA7X/vrTCmuvQ56m1t356CHf/nmn5c/vumSgw7++aSTTz74C+Wt0d3LY4/8/ccrL/vzveNf v/7U618AG3K9AjKkfvhLoPISyLzj2Y+BBDygAK+XP/vlDnFX2d7iGJcx+K3Pc5ELofnEpz4SfrBy KDQhCMuXPgwiZCMi+Z8ELxhA3VnQfzhE4AJ3eLsHYk+HArxhD28dQsH7Bc95xTPiECsIQRxKsIZL VOAPJbgg7XHQYh5kiAi3OMLPpXCF4QtdCb1Ywi1OLnzyy0gMn2fDHtJQiTZcoAWDxz8i5tCHbfQf HRW4xznuEXoPXF4ba7dDQT4xkHb0Ix6TGEVE9vF+V5xZQAAAIfkEABMATQAsAAB+AIACKwAHCP8A /wkcSLCgQYMA7ClcmHChvYQQH0psKLFiw4sVMzJUGNEix4kTAYjcaO/gP4coU6Y0WUFhhZf2Wjps KdPlzJg4adrEGROmy5ooZQrNeROoUJ87exr9ifQlUJ5QbQ6VKvWp1YU1n+48qhNrz6Bgq6ZsabKs 2bNo06pdy7at27dw48qdS1el3bskHVL8iDHkSI4i+z6kuPcjYMB/+3bEy7gx46VXl3qdynVo1qhe ocKEfLOz5qhTVUrG3PWy066ek16+y3ky6KBOqaZ2TLu27du4c+vezbu379+86Q7UaNijx8J7F2cs rFF5R4zMG5rcPX21dc+UZcvOHrY1z9GqM1//twt+vOnZ4TMnVX9+a3qinZcKn0+/vv37+PPrPwuc YWD/hKGkXHMEFpcXSBshN9h/xPXHWmxMYRXbaeppB9+FRm1WFIRMVYbdZJtRSOFsHGIYoVYRkghh hiE2BaJlYX3m4Iw01mjjjTjmqBt9OvbI2HQ7HuTjkERWWOSRrCm035JMNunkk1BCiWSRQOZW5ZRY zohilkXWFOWXYIYp5phklmnmmWimqeaabLbp5ptxcSnnnHTWaeedeOap55589unnn4AGKuighBZq aG1wJqrooow26uijkEYq6aSUVmrppZhm6uihnHbq6aeghiqqSmbYqempqKaq6qqsturqq7DG/yrr rLTCNeqtuOaq66685lrrr8AGK+ywxBZr7LHIJqvsssw26+yz0J7U67TUVmvttXoGgu223Hbr7bfg hivuuOSWa+65ugW2GESEsfsXYgdaK8C8AthDb70K4WuvvfOi6++/AHManUXtLlecYPKipC++DC+k b8AQRyzxb/QNDB1IASqoYElCDmrSw/k6VO/IIisZ7ckopywlgwdjvCDCCJJ0JaAf59vvwyODjK/K PPfMc40BGnYxXwI22CvO+zq8L9ITN+300z/Op1deihls9cYz/zndwkkn3XDIHPss9tjL9qfu1Ab6 ldy7ZxuN67389gv20nJDbffdeOet995898DdG49HZu2n4LeRbfjhxPqt+OKMN+7445BHjjfgOBJu LeKYZ544cG2z7Pl/6jLX68Z6XcSy5Kin3m3GLactOrWdbzyg6rTXzmfFCbY+cNEOWR7ogLJrpPnw xMtqdoLvGlc627CTLvSCtkcvPa6dF7g7t8kHH6/dyU/vPey8B03c9aNbjWByfXf//fqmzke6uwC6 mxhKvgPaNvQEwxu24SIV77+r33sd+wZIwAL2SIAGTKACZ0S5T9WPSP+LoARRFRAAIfkEABMATQAs AACoAIACKwAHCP8A/wkcSLCgQYP2EipcyLChw4cQI0qMePDfxIsYJ1bcyLGjx48gQ4ocSbKkyZMo U6pcybKly5cwY8osmLGmzZsUD+LcqXGmz59AgwodSrSo0aNIjfJcyjQnwqZQ7SWdSrWq1atYs2rd yhGAVwD2vjIEm5Bs2LBfwaZVq9Ds2bZozaZ9W/Zhxahw27rNO5er37+AAwseTJgj3r1189Jlu3Av WceNE9OVPBnvxbmPx2a2zLmz58+gQ4seTbq06dOmWyKuzJYx5MiI3W6OHbny3aiM39KeXLi379/A gwsXedhrbdhnH4uNq9zh2tlljT+nTNq43t3LUWvfzr279+/bMYH/H08e4uaxyXWjR74+8fn0irVb j099dfn7+PPr38+/v3/nlcHVWn3rveaeYrmph1qC5xn434MQRijhhBSKppp1c7UnF2aYxSdbXNcx SN1tUGWIFl/SWTfciiy26OKLw1UIEYm48QTjjTjmqOOOOsnoI3U/BinkkEQWaeSRSCap5JJMNhlh S0TS+B2PVFZp5ZWCOanlllx26eWXnl0YW3bRIdiYifORyRxzapmYkJRNbejYcipiaeedeOY5GH1y nclee2UeSGBDq8G5lJsf8iWVnow26uijG3XmIHR1rZYopbsBah9nCVJ2KZighirqqDVBiaF0tb1n 36cgupfifJOR/2UoT7CyhmFdkOaq665XSqppdLCueuatfQoI4HZpmqcgqcw266yXUA667GIPFVup ZH1aWtustMLnoXq8hivuuJCquaan9JlpLLZirfXtok+VSCedrZ4IL7n45qsvjlH2eJiN+wYs8MC9 9RtvjTsRrLBfiiy847MQRyzxxBRDFa2S3I7m8MYhTcGxwBWHLPLIJJeMk4HZctiuh2jKqdmrMG/6 L7CynVqryTjnrHPCLAWqrreDauunoKwdy1DGE3WorFsfN+300ykBfa1rgEr9LqaEGv0W0hHlJnOC UIct9tgHZUbvgOdmePPVwKLYZrDb+nuyy1m3SvbdeDvtLnJUH493rdZqU7tu1W/KPXfVtOWteGEC LF5VugO+V3SAgv9tbafo3ksQUyJafZbjoIcOo691L6YyqkBa662cbyebrrw2C9ju2jvXbntT9DB7 cZJcSySzRKIHLzxwt3db/PHIJ6/88sw37/zz0EcvvZHG3G7F9Nhnr313w3fv/ffghy/++N1vb/75 6Kev/vrsty9RQAAh+QQAEwBNACwAANIAgAIrAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihyp8J/JkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iT Kl3KtKnTp1CjSp1KtarVq1izat3KtavXr2DDBiVJtqzZs2jTql3Ltq3bt3DZip1Lt67du3jz6pUa t6/fv4ADCx5MuLDhw4gTK17MuLHjx5Ap7p1MubLly5gza97MubPnz6BD84xMurTp06hTq17NurXr 17Bjy8Yourbt27hz63Y5u7fv38CDCx9OvLjx48iTK1/OvLnz59CjS59Ovbr169iza9/Ovbv376p/ gv8f33y3ecrk06tfz76geHuq4qsSKD/+wPn34dsnKJ9+/4P13YcffQX1V99/ARbI34L5NegggQse +CCEFMLHoH8SYjjfgBXqt+GBHAq4n4YAgmhhhP+JOGCIKyKoIH8msuhhiiTCOGKNM+KH33k8nnci gRzq6GCIEAZpkJH6XTghkh0y+eOGFxIpI5JSKrnij0u+OCGWXFpZIZEPTjkkgzJiCaWSXkao0JVf htnhiT3GWddGYIppJoBvomnhmV2WmSeZJxrJZJVqNlgnkG0S+qafWeJ55KOONvnkolzyiSaYdxaK EJtVdgppe6BydKiajBq65qN8KtrmqXsmquCo+VH/6eiZgn7ap5aN2rolpk62WiSqr0b6Z6+Wfipk sMjqGWp6P7VY7Ie6UpignrRSeimNph47qbKVZjpqtdLiKqWJuHYprX2qWhljip5qaiC5toL44bQ4 touii/boJYicuNGZLKKl5hlwqrdye+uVbHYr7J7THorwmGleqiuv/w4rsbb2IqqpxVli+iulGf+5 7MgQ2RnrquVKmmyxCi/sn4A23mhut7AW2GLMjKar86YVz0zstiE/27K4PUcJMrApk6z0Q7WaGi6k vXoL48QRS6yyyJyWrGXO5Q6c9KpRu+mu2NveGTDKGvP89NqBLu12RhJmaLbMCGKrYpgs3pi3zLly g50Quy5f7XfMQ3tocI53/31xlNg2HuDZmcYqN8r0zrjr2+S9h/nmjvHr+Vechy766Ix9bvrpqKeu +uqst+7667mRLvvstMcF++245647WLX37rtFBPwu/FvgDG/88cgn/5AQyjfv/PPQR88aANQDIP31 2L9d/fbWZ+/99+xVD/74vgcEACH5BAATAE0ALAAA/ACAAisABwj/AO0JHEiwoMGDCBMqXMiwocOH EAkCmBixosWLGDNq3Mixo8ePIEOKHEmypMmB/1KqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMK HUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2rNmzaNOqXcu2rduVJ+PKnUu3 rt27ePPq3cu3r9+/gAMLHky4sOHDiBNbfMu4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnT aRWrXs26tevXsGPrRU27tu3buHPr3s27t++UsoMLH068uPHjyJMrX868ufPnG39Ln069uvXr2LNr 3869u/fv4MOL/x9Pvrz58+jTmx2nvr379/Djy59Pnyb0+/jz69/PX2H9/wAGKOCABBZo4IEIJqjg ggw2OF1/rjkoYXcQVmjhhRhmqOGGHHbo4YccFiBiAfaMSKJAJ5ZYoogEjTiQiSSmuKKLKMpo4ows 4tgijTTimGKOKqI4Y5BC1ggkkSrCSOSPRsYI4pNQRrmXjEsWyWSLVhZk40FAUuklQkyeKCaXV5ZZ Jphhavniml9K6eabcAokFJVIOrkllkG2WSSeY+K5JpdsZqlmnnUKOSadgSZpkJ2EYjnho9l5JCaL Wx6J5JBN7qmjoJjeaKSWPHbZY5+WkqooplnGOKqiP+aI6IZfxI0p66wZVYqlk38meumdO1p6KqC5 Mqpppr82umKhweJ6a7GG0urssxUKVeWZVfI5LK+afvkqsqf2mWu3f955ZbaXslpuipCmK1+mnk57 ZJg3xhvvraG62C6x8Nq7rKGU+nlvpe2O6ymJ6hb8G7QIJ6zwwhxJy3BJBkcs8cQUV2xxZRVcrPFn S2zs8ceRBQQAIfkEABMATQAsAAAmAYACKwAHCP8A/wkcSLDgwCUGEypcyLChw4cQI0qcSLGixYsY M2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSfOfvZs4c+rcybOnz59AgwodSrSo0aNIkypd yrSp06dQo0qdSrWq1atYf9bcyrWr169gw4odS7as2bNo06pdy7Zt26xw48qdS7eu3bt48+rdyxev 27+AAwseTLiwy76IEytezLix48eQI2M1TLmy5cuYM2vezLmz58+gL0seTbq06dOoU6tezbq169ew Y8ueTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQo0ufTr269evYs2vXG7q79+/gw4v/ H0++vPnz6NOrX8++fejt8OPLnz+3I/37+PM/dV9Qv///AGrFmVRSOFVgTgcWleBNC8LV4GoPBqhg U1JEKOFRFvrWUYEcBlVhhTw1mKFPIvaUIIcfMrXgivaMyCJRIyYV4YcgDvUgjQSSeKKLRuFIVYct mpjiTzHGVSKDBp6oI4gzIgmjj0A1ieBN/BHUYo1ERqlTkTsd2SVOQAap1ItOZgnmhDl+ieGWVmWI JZYUGlkmm3OqqdeNYlJYpJdTyqginVUO1CGPXdZ4II4pvnlokIuCCaeSSoZ46JBXPjolinDmKeaQ UNapqKGTfirlmaEyyCSZZWIa6o6LoljppYya/4rkoJRmOqOhjHJq6aa5VurlpLO+ymmursrqq6PA bpksqakKu6OarWoqYrJMmrpqiAiCiuuxPoLYWZpmJsospE6yiCufzObJI7lz0lhtpNaKG2y7fYYJ pL3qSppoo7HW+Wq+7PbbK69sDnpptPOi2uy2Ap/J670OLzxro5BSTG/ABBeMrcQZa0pwsdnymzDA EUccsMHzNsybfTbCGiy7FFdrrZ3pdqosvvBKKzCqOJe8orzE9uyvx/BabCLJKQudb73lyrzzsSVz vHSJBkPcrq5O84vvx1lLS+nMo8Lc9LTnZsnqw+l6vPTTSgMZqEBoso00wlvj6bLd5SKt87g+u//8 dN8m7/23wkWn/eXJem9NL9pyp0xn4IV7WqzVgi+ecd0jYyxlmH3OPXLfnB+eN8J/d45422J+a1e3 2yKat7CBz/w43mA73Km5UAOONdmlQg30tZV73fvPovpeK8PEdj524rKHPDyyvcdOusKwp8qw0b/L /vW/tLvONc8q5/788/4Sz7H3He/G8mxcjun++3HPhS6EF7424ts2Xdf+xj1m+tj8qtlf/RizvZ3g b4AIpAv+FuidBDoQLgyM4GeGtibltWwvAkRMBuUUv9FI8INjgQrKiFRAolVQX6F7kqOwJTLf0UxB JfRQVXgnlD2lD1nKgl6hkEfBB/pwMhz5l5n/SPQ4GB0tSSsUHf8stMFm9WiGs5NhDSkosjdFLWcW LAoIt/gVEYYvi9yLl7OSiDJ0XYt1uBshrUyYsFORbFmLu56xhoe1K5FRV8pbFvIs5iqbae11lruX G8lFLf/98JBCYZkNqxcrsemsbDtMmt741rNWdY1zf2xdHj/GSdTxUZJ8olzDPvlHHNrOcm9k2sRG hxMupgcAsFxLXXD3spot72xERB0bp9cvGo5Sarc7GCRdd7rRZS+UxsNkI3sJOuehslt7O9mwJKMD RCoFltjUX9rU2ElJqo1v3owmKNNHNVWWznSe6pgnWQm5KIpzWnZkZhwvdkWNnTKcUbNmaWLwBRNY xiYgACH5BAATAE0ALAAAUAGAAisABwj/AO0JHEiwoMGDCA9KGbhwocCG9hxGnEgR4kSJDiUahIiR okeNGR9+vCiSoEaSDEui9GgyJUuUIEd2DLlSZsGOLEOelNJQp8qYFVvidJkS6EyiSBMqXcq0qdOn UKNKnUq1qtMYSgEAsMq1q9evPHk+FFsxbNCyFkcyNIs2bU+gLsNaTKuyJNuMZkGSHbs34l69c8nK tWtXLE7AgPm+PCxyqM2ibFtKvsuXbt6+XzNr3sy5s+fPoEOLHl31JOnTVk2jXs26tevXsGPLnk2b c+TatVXj3s27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn775n/Xr2LNr1163s27RmGPT/336/XP5 7pvPj1avmf1q903hL5X/dbv9+/jz69/Pv7////1xpJRc8NG0UXgDkneTUAPextV4Tu0U1WDsqQfh gfTBpZCDpaE3VUyq6cZhUoSRR2FmGS74EkIalrgUgDDGKOOMNNbo13n0uahijvGp6KFk6a3YY4dS WSjkjlC5x+N8P04I5EYs/hgikUd+6ORk8TnW5EE1dunllwCiWBOUDN6o2F99GSiYYT4ttqZjHKUJ JV5q3ojRZYKVtVaJb90pp1CRnehXgiZJ+BGdYylkJolHCTionYm6ddObhjZWGaRYKvbommhdSiam gdUJ6WCazqQXpo8WVVikpY5IHXIWUv9YJ5wYxnVWYD6OR6Cjk7H502MrSZpnTsECu1OeR1lq4KdP ckjrgqZFC1miQSXbJlGSrnVisjn9pWqZwjKK7abfFsttuJnChCWIlrZb5avRVcrYYtBqO1e7mHFb 173NqmVuueiCyua5/tZLcJ8JHcuutj+Ft+yKBF9qrbu/PqsswGUaa5i72QIZ8b8cG0uvTLfdeWbI WsJLnbzjSmsrsdVS27KPxXrsb8A4F9zmtR0bjLGuzC5LE8/oacnyUHDxC3TISPHa89Df7ixyrhij /PPV6V648L0f4zbPcV8q2OybDSd9cswPU9bvWxhahubGhQ0sNNmNxlUyZYflVWrbmv7/auZdDi9a KKU6wx2zh2rDjK/e+9qd987DQjwzw54K2mnl9cbd76Kh/grm56CH/rnKpEeYWpSlJwzaksSxTpvo sMcu+36p1z7pkq7ajrptCD6Xe3GzBy/88MQXb/zxyCev/PLMN+/88zMKAv301Fdv/fXYZ6/99tx3 7/334Icv/vjkl28+jLqnr/767Lfv/vvwxy///PQ3d/79+Oev//789w9m/QAMoAAHSECv+O+ACEyg AhfIwAb6Bw8OjKAEJ0hB7ZyjgqEroAY3yMEO1g+DIAyhCEdIwhKa8IQoTKEK7+fBFrrwhTCMoQxn SMMa2pAgK8yhDnfIQwze8IdADKIQV4dIxCIa8YhITKISl2jDHjrxiVCMIvmYSMUqWnF9UsyiFrfI Rf30Q3RXDKMYxwidLprxjGhMoxrXyMY2utF4zHmjHOdIx9nFsY54zKMe0becPfrxj1sMCAAh+QQA EwBNACwAAHoBgAIrAAcI/wD/CRxIsKBBg/YSKlzIsKHDhxAjSlx4sKLFixgzatzIsaPHjyBDihxJ sqTJkyhTqlzJsqXLgRNjJuSnkOZMezZvzuSXsybPnT8Z8vw5NKdRnESDylzKtKnTp1CjSp1KdSGM qlizat3KtavXr2DBojx6s6dNsgvPQuyJs6ZOtDdfyp1Lt67du3jz6t3Lty9JrTQDtx1cVqhhwofT KhbsVnHYx5AjS55MubLly5gza46Isq3gs0UZNx499HBps0gTD/bLurXr17Bjy55NOyVgz4NRs93d ELVb3Yjhbh5OvLjx48iTK1+O+XNux8IR6yRNWG115tiza9/Ovbv3hdWOd/++Pr26Up+BS/c+rf66 +py148ufT7++/fvyv+vfz7+///8ABijggAQWaOCBCCao4IIMNujggxBGKOGEFFZo4YUQSsGQhk1x CJWHCYI4mYhMkeiQiVtpKKIUKFLFYkwtZviYihgmNx6LLza0olMo4ihRjPaQCGRCQ05FY5A/LlTk hxsiuRSHRS65o0xHEvnVkk5qBaSJWCappJddquijQjkGSeOZJX655ZcT4ceSll6SySNEQ665HJRx ZjnjnHrSSWVUVfYJ558p5snVlH4KSmegZHpYJqMwsplnlxSixGWOUPqoqaN4HikkkWOa+aKjopqJ pKeZgijmipi2Kiaor57/GuujoZpaqpJjooqnlameGSqOqq7K6Ya/pmorr7WCyiuuqy67KazEGmul s6IOW62OvSprq6/aCgstrbBmiiu04wLbqI6nnpgumrqG26Sc3r47ba5julmbsaRW6em0yC6Lbpb6 Aizwtk5CarCk+6ZbsMK7BiznwPzO+vC++QpM6sTw8muxv3063GSgu8o6L8cPK1yyxBp7vHDFK4dM rb+dcsxoyKpGvDDGybK7rskqAzuqxaP6vLGV9tJWc8UsN/wzue+yzPPIQGPatLxDx7zyzeZeDLWe Tl9MccZds5lvrWNL3THE33Jts9dbry2vx/iWfG3Smp78c9LILm3y1jVH/x3sr2JTi6bMku6ssdph F21bVmEH3PDVbfM9dNUZU6212jBnbrjLl9OMMMRWOz55305//umOnb8sOdtolz565T2bnjLGhjNM suue0773v7NfrTPhcg9+duVPX3gjvUovnTzozA5s7txSex300WWSm+vIjz9+6/MTV38t19VLf3f3 3jtMdrHNIi53qSA3mnun5ZvNrL7oo80+7XWT/7T2+d+s/8f/+1j5ADi46/XOWcnCHPI4pLjx1EhC lHLRAycYIqlEkIIY9M8Fn5LADHqQPxs8nPFO8sESmvCEHmygRlDIwha68IUwPFAIwzJD4tQwOTec 0AxrmEMs9e2EDtxMjP9++BCXYYtJJcqacYioLkWdi4OYySENDSVCJOouTU58UlV86D+qqDAjGbpc E4coRUJl0TKPAlNEvKedMl6JioO6ohbPGCkJ/smIH+wM8tx1v7wdK3q3yhvq5gXI6X2qYEF7YgFb tUb3WWtczgsdpxipJkLGzJD/wpe1Fimu77nPk66aZPq+NUmYCSmUR/weJblFsOc9q1v0Klex+Hgu 7smPVa7CVrbm98RWxqt5rdTWF+vyQ9G5DXIoq2TvhIcyMfIvc4DkHe/wlkmsHYtwnFNdM9f3TNtF E4AHxFvjqrk/7R1TgZQT2dmMGbrJSY54pIMdyV53stbJE2w2W1+/Fjb/TLoU03nHhJ/e1hm8WsIz n46Emrdwx8Z6CjJaphxo/34JMGP6D5fPVOI8Jzq1h4ZteFbjGdkOmlC66a2U7PQo8d7JUd3Fa2Yk Pec/XTk+ezZPlPbop0UYJzuZWpOJRyvoQVmHOc2173aRYx6XsBdObDbRqe+cXfZ6ylQRWpSe6Nyf PrFa1ITl85L3POruPBfSeG50eMXzaT3j6VUiltVBesxl1NzFv5OGz6aWlKpQjZq2vG5vmgFk2t/A t8uR/i+oB7QdIs2Xy85hsq+LHaU1//pJYDrzpHklXU0VG7fIMVZlxQOcLqVl2b1KK3+g3eNgdVqR GFbIjdiBrWvjONva/9q2Qw1FkGxva0HebiaIvg2ucPXD2uKGZLjITa5yl6uZFg0xMrtlTnTbqKXp QreOlxEjc4sD3EYWcYxUoy0dsZio8AKqo4VKVJiq+F3vlnciXDzvG+GLRSkKjzPGzW9e5vjUwEFm unbyypR2+9zxFg4rAabvf8ESJfIieKsN0a+Ewci4XXqyr7F0JSg7+EqCtYxW8ePjKtUZPdVuMpa1 nOVNS8k+VimrpiA2FWMFCGLHJZKZKw6prG4Jy1kVMsQbBvLcuofAHXfLyJAsYC+3GyCLujWdtQOt Qis5zmWmM5na/ClUXdrFqQIPXUoD55TNqdUtd3KsaxtkVd8KNPaWWZBR5vupl1vmZp0RlcmViauT C5fSLGt3spuqMmHZ2dL7UXOhK73ohedMZgynTKJrHqmgu3lWdwJPV5QW6yc/ummc0RV/n9Zn3UbJ vZx+ZA0TTjVH3pq6obrto2b9GuTS2tUug7rPYoWppce81qmZU8deXuqk71lp14W2i5pDs6e/POt2 OrR0iPLdZOWk6moTJCAAIfkEABMATQAsAACkAYACKwAHCP8A/wkcSLCgQYNS7NlLmFAhQ4ULIUaE +NDhxIYRK2akaJHjxY8NQ07c2LHkyIoYT3Z8iBGlxZQtR67kmNKjyJgvJYKcORNmT5M0g+Ys6VKo TaNGbwIlGbOmT5JQn2pUKhNnU4lOseYsmvWg169gw4odS7as2bNo0xLUybatW4dSpsKNqzMuSrpD N1q1a1LkRbpX9+KlCPjowsI2C1/9eFiuzKhztTLm2xgoZaqRK0Mm7FNwSL6XH9c8iXe046qAS2du OTiy57qlKaPWqDf21NaVWSb2+7a379/AgwsfTry48ePIkysHTnu529HOo0ufTr26cOjWs2vfzr27 9+/ge6v/PRjet2zt58urX8/+N/b28OMHH0+/vv37+PMXlM+/PQAA/QUo4IAEFmjggQgmqGB2AC7o 4IMQRijhhPzpZ+GFGNIHQIYcdujhhyCGKOKIJJZo4okopqhiQf+t6OKLMMYo44w01mjjjTNuiOOO PPbo449ABinkkEQWaeSRSCappEAUNunkk1BGKeWUFC5p5ZVYZqnlllx26eWXYIYp5pgeUmnmmWim qeaabLbp5ptwxinnnNyRaeedeOapJ5Z09unnn4AGiuaehBZq6KGIJqroomHOwOijRAoq6aSUVmrp pZhmqummnPYH6aeghirqqKQqmkCpqKb6YqesFpfAqwm0/yrrrLTW2uSrtuaqq4Cq9urrr8AGK+yw N9IjoyXEJqvsssw2++Ou0EYr7bTUVmvttdhmq22T+WzrrZ/5KZTPuN2SO6495narE7kQqSuuROmi Cy+65sLr7rnuyptvvOzWS2+587Z7rrgDy9uuvQUTfG/A9gqcr8IGv+tvxAbXy2/BC/c2McTvHlzu xvtaDLLF87L778P/OqzuyPdiTLLHJeP7MsUjI7yyyR1HjPO+NucMsLMWTvcwyhQf3DHGbGUssVsu 01y00zofzbDPRiNtdNRSXy1w1UkTDHPWS3cNNsC+KZ0x0kprTTTRWGfNNtYLn8011E5bzfPXV7es 9dN4y/+tNtcrf2sgymuLDXPg6/7NNsCMl2x4xXPfPffhOdeduORuVy514Dx33pbf+v7mueOI7033 1AzfXXrijocdeuuSe4445mTnnTnqsF8+tdyrC75cfjd/nDDhur+e+sUJh9443n+fPHnRvZNdu+Wt az578plPrz3HPidP+PDVhz390yGD/7nKA7c8dPHGjy8869RLjzrxt6fMfers04xz1EDTODr8e6sd 9tI2vshRb3dUg1wAracz2kHvdM4zXsD09r8HUm19ogtf+zCIwMfh73mVW5+/Rqg7Dv4vffNL2s72 x0D4ibCDbetW/8Ilnbidz3Cro98BWcc5DULNb5iLYQijPwg3GL6OficcIhFzCByzPY+DzQMgERWY QrBproh0qyATcQdFKJLvgw5MoO+oQ0OR7YxpVrsiAU8WxOC5MW8yS18chfc+7tGOhSuc4wHLV7f9 jdCPtrvi5/CYRgv2LF6CbJu+9KjCtPHtjGKMYOcK+UUE/hF70BseIc0nrxnKaIygDGV5PBkjUZry lNkhpX1QycpWuvKVsIylLGdJy1racpYBAQAh+QQA//9NACwAAM4BgAIrAAcI/wDtCRxIsKDBgwgT KlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJsyZBYTZz6tzJ s6fPn0CDCh1KtKjRo0iTKl3KtKlTniGeSs35r6rVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt6/fv4ADCx5MuLDhw4gTK17MuLHjx5DhTp1MubLly5gza97MubPnz6BD ix5NurTp06hTq17N2mnk17Bjy55Nu7bt245P4N7Nu7fv38Djth5OvLjx48iTK1/OvLnz59CjS59O vbr169iza9/Ovbv37+A5B5gfT768+fPoZYdfz7595vTw48ufT7++/fv48+vff969//8AIsXfgAQW aOCBcgWo4IIM2oTggxBGKCGCDVZo4YUYZqjhhhx26OGHIIYo4ogklmjiiR5NqOKKLLY4Hoowxijj jDSypEiNH7mo44489qgYjkAGWZyPRBZp5JFIJqnkkkw26eSTUEYp5ZRUVmnlWvBcqeWWXJoVEAA7 ------=_NextPart_000_000F_01C5D7AB.440E3B50-- From bbdqduomwr@reporter-herald.com Sun Oct 22 20:23:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbnbj-0000JN-Tm for capwap-archive@ietf.org; Sun, 22 Oct 2006 20:23:59 -0400 Received: from [222.94.123.116] (helo=[222.94.123.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbnbe-0006le-K1 for capwap-archive@ietf.org; Sun, 22 Oct 2006 20:23:59 -0400 Message-ID: <001101c5d768$349ad4a0$747b5ede@USER675494B64D> From: "Mayhem Go" To: capwap-archive@ietf.org Subject: hundreds no banner ads. Date: Sun, 23 Oct 2005 08:25:00 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C5D7AB.42BE14A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 ------=_NextPart_000_000D_01C5D7AB.42BE14A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C5D7AB.42BE14A0" ------=_NextPart_001_000E_01C5D7AB.42BE14A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Sudoku With if or you a enjoy puzzles will love our new? Math Phonics Category am Seasonal is Worksheets Homework Play Sudoku = With if you enjoy am puzzles will love or our in new game try get the = in. Play Sudoku With if you enjoy puzzles will love our new game? Strd thth th Subject Abcs Geography Math Phonics Category. Wordsearch Machine or helpful tool members create a printable word = quickly easily all need in list words a handy do rest Lemonade Tycoon = have. Random any difficulty of level am it now Traxx Here am is is game that = or easy is but am makes use your brain is want. Free Newsletter Link to us Activity Search by Grade Level of strd thth = th Subject in. Then from like mr Elephants Matching Mayhem go Today or Membership gives = parents teachers. ------=_NextPart_001_000E_01C5D7AB.42BE14A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Sudoku With if or you a enjoy puzzles = will love our=20 new?
Math Phonics Category am Seasonal is Worksheets Homework Play = Sudoku=20 With if you enjoy am puzzles will love or our in new game try get the=20 in.
Play Sudoku With if you enjoy puzzles will love our new = game?
Strd=20 thth th Subject Abcs Geography Math Phonics Category.
3D""
Wordsearch Machine or helpful tool = members create a=20 printable word quickly easily all need in list words a handy do rest = Lemonade=20 Tycoon have.
Random any difficulty of level am it now Traxx Here am = is is=20 game that or easy is but am makes use your brain is want.
Free = Newsletter=20 Link to us Activity Search by Grade Level of strd thth th Subject = in.
Then=20 from like mr Elephants Matching Mayhem go Today or Membership gives = parents=20 teachers.
------=_NextPart_001_000E_01C5D7AB.42BE14A0-- ------=_NextPart_000_000D_01C5D7AB.42BE14A0 Content-Type: image/gif; name="Seasonal.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c5d768$349863a0$747b5ede@USER675494B64D> R0lGODlhiALUAYf2AAwBC4QBCQBzDniIAAUAfYMAfg13es3LtMXjtKrV+jgaAFUoAIAVA5IuAsQc CNkcCABNAiVAC0AzAF01DIBHCqtGAME7AeBAAA5jACJaADZsAFVtBH5pCqxqAMZqAuZsDAuBCRyE BDt2AFJzBouOCqVxALiMAOWOAASZACWnDkSUAGGqAIiXAKmuAMeUBduXAA66AB23AT/KAFTDAHW3 AKDEAMC7DNLCAADTBCvcDE7TBFHfAIHgAKfSAs3iAOfUBgAFOxUAMzgKR1kASHYBSJkASbEAQecA MgskRyQtPkMmOm4gPXgYP54hMccYSOMWOgA7Qhg/QEozQW1LRnhKOaxCNcoyQOJMMwBVNR9dN0FU MWRhQoNVBq5iMblfRexnOQyCSBaLOUKHTlx0O4mKN5FxMs5yONNxMQCWMx+sOj6VP1GcNn6fSZum N8OcOeabTAq2PyvISDK5R2TBSnm4SZrIQL3COd+/RgDuRi3gQjLTOVLdPX/qTKvnPbTeQeDUMwAA eRQAhUYGhGoDjYsGepkAjsYAhu0AiwsaeS0ufkEUgGUth3UfdZMhisYUdNMthAdCjRxLhzI3gVFG gXxNdKQ2dLNDfd1HgQhngClic0ZrhWpbgXtUiKtpjrlZdeNpeQ13jRN+dEmIdFmEdXSIepN4c8dz gex2hwOhjSmTfz6TgmShhX2Wdp6SisuscuuXiADMhhvKdEDGgmvIgoC3iKK0f762ft3McwzpdSPY gEzujFjbjoXoe6LVjLLke9TdiAoAySEHxEIAx1kAvnQAxZYAvr4Jwe4EswAftCoRzksUvFUhzoEo tJ0buLcZwdcmuQAyvypLzUdNwVZBxXs2wp5AxbVJs+lJsgBfwihtwzVjt1FeuXVtv6pSv85byedo tQBzxiOAyDyAsWNzuHh1zZKGxLSBy9uNvQCmtyeauEWStm6TtnaqzJehs7uky9GRygC/yRrCwUa2 s224wHvIvJrHvf/66piroIh2df8JCQD/AP7/AAcA//8L8wD///L//yH5BAAfAIkALAAAAACIAtQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnxn8mTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjNkkqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HYm0rNmzaNOqXcu2rdu3cOPKPTm2rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy48cG5kCNLnky5 suXLmDMTdcy5s+fPoEOLHk26tOnTgDWrXs26tevXsGPLnk27tu3buHPr/om6t+/fwINv3E28uPHj yJMrX868ufPn0KNLn069uvXr2LNr3869u/fv4MOL/x8/W7j58+jT+ybPvr379/Djy59Pf776+/jz 6ydcv7///wDutN9YKQxo4IEIJqjgggw26OCDEEYoYUVEyRPghRhmqOGGHHbooW0ThijiiPh9aOKJ KKao4oostujii0ZRAOOMNNZo443tAQAAjjz26KNOOv4o5JBEqhRkkUgmieORNEKj5JMtPqQjiVRW aWVoU16p5ZZc4vUSk1CGKWaAXerFTJlodjnmmmy26eabcCKX5px01rlVnHjm+VwVOdnp55+ALqXn oIRyF+ihiCaq6KKMNuroo5BGWlKhlNJowYWSZqrpppx26umnoIYq6qiklmrqqaimelilrLbanKqw xv8q66y01mrrrbjmquuuvPbq66I/luLqsMQWa2yrvyar7LLMNhvYsdBGK+201Nbn7LXYZqvttp+N we23klYr7rjklmuucuCm2yko6rbrrqDnxivvvPTWK9e7+Dpr7778QoZKvwAHLPDABBds8MEIJ6zw wgyPl+/DyjYs8cQUV2zxxRg/B/HGHHfs8ccgh7xgxiSXbPLJKKesMlAit4zqyjDHLPPMrbls8804 56wfzTz37PPPadW1CX5g6Awy0EifaPTSi7HL9NNdSgP11FQvlPTVHVat9dZcd+3112CHLfZgWJdt 9tlYj6322my37fbbcMf9NNp54mNdJHTnrffefPf/7bercgee39+EF254vYInrvjijDfuOFWHR27d 45STJvnl0lWuOWiYd+7c5qBz5vnopJdu+ukKb4L66tWF7vrrsMcu+9ys1x7b7Lj/Zfvub+FyU+5c 3XEH8MTnJfzwxXNKBarCJ++8WMg7z/v01FdP3/PYZ689etZzOILA24cv/vihdW9+ZOSn79T5Pe5Y rPp1AmAr++3Tbz9b7t+vv1n5Aw4/nfKj1f5s1L8BGlAoBTygAhfIQJX974EQjKAEJ9iYBlrwghjM oAYrQ8EOevCD8NqgCEdIQpqA8IQNKaEKV4gjELAJhTCMoQwdwkIVzvCG9qgh+8CkQw3yMCY4NJUL /zoCDtBkiYY9TKISDxjEJjrRg0uMohSnSMXOPVErcYhbFRt4xS568YtgDKMY27bFMprxjGik2Rgl mMYBrvGNcIyjHOc4xg9oq437o6Me90hGPN6Pj4BEUzoCSchCZsWPfzRkem6hyEaODJGQNFwoIknJ SlpyYY5M3iWhpaNOehI6meyVJ0cZylKaEn6bTKUqcQKEVboSRqfE3StnSUuCxXJ2tSyXHoxzy176 8pfADKYw92KKYRrzmH/KpTKXycxmOlOHkMANMqcpwxd47JmeawwdqMnNbiYGm+AMpzjHSc5ymvOc 6LyRN9fJzkYlTRjphEk750nPetpTJPHs2z33yf/Pfvrzn4HLJ98AStCCHkigezMo2BDK0IZSzAhx cYZDF3iGidZGoV+zqNlk9w6MevSjDjkDSA+p0ZLSpw0mNclItZbSpK20ai1F2kupFtOa2vSmBgwD TvU306nttE0iAFFPh0rUohr1qEhNqlLB9dOmOhWUS3XZU6dK1eNE9apYzapWt8rVGFb1q+akQne6 2jGwmvWssCErx9DK1rZiRq1wjStG3ErXutr1rniFqlzfFZkf5PWvgA2sYAdLl70a9rBWI6zBENsu xS6WsZBFEA4iS9knPuCoji1YZbmVWVtu9o6dBd9nsxVa0Y72WqVNrWpXi7jTuharShoHa/cl29n/ 1qu2tpUXbnMbr93y9iiaGken6vBakQi3uPgck29/KxTkiuYR52FuvJxL3epa97q3lO65sNsr7Xr3 u9sJBHg5yN1djfe8VP0FetfL3va6l4XljW9BEXqL99r3vvgVqHwXBIL9wi2/AD6nf4GzgQoGmFUD TnA9D4xgBTt4nQyOMDYfTOEKW/jCGM6whksl4Q4zc8MgDrGIR8w0Dw+KxKAysYpnieJPrRhPLfbU i+MU4xrb+MY4TtaM4ZTjHvv4x0AO8hsxs4Y17Jg8VDHAQtYgZNRUpshHbk9XmNzkQxW5yuuBjJGj DB+sXBnLgKIymH/zj2O4BcpcDtOW08zmNpuIRgdPCgeOxkznOtv5zglys56piOc+i2/PT/IznQCt JEEb+nmETtKhF83oyib60fBttKQnjap+UPrSmM60pl8H6U6TcNMjCggAIfkEAB8AiQAsAAAAAIgC 1AEHCP8A7QkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKl y5cwY8qs+K+mzZs4c+rcybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1aIzs2rdyrWr169g w4oFebWs2bNo06pdy7at27dw48qdS7eu3bt48+rdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ue TLmy5cuYM2vezLmz58+gQ4seTbq00LGoU6tezbq169ewY3OVI7u27du4c+vezbu379/Ag19kJby4 8eMMcyBfzry58+fQo0ufTr269evYs2vfzr279+/gw4v/Hx8RFPnz6NOrX8++vfv38OPLn0+//nzT +PPr388fqf3/AAYo4IAEFmggav0lqOCCDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhyCGyN+BJJZo Ym0ipqjiivud6OKLMMYo44w0TodhOyzmqON+XezoI2AABCnkkAD8aOSRSCap5JJMNunkk1BGKeWU VFZpJZQ1Zqnlllx26eWXJF0p5phklmnmmWimqeaaEoLp5ptwxinnnHTWaeed2rGp55589unnn4AG KiigeBZq6KGIJqrooow26uijkEYq6aSUVmrppVw6o9ugHX7i6aeechqiHaJ6+AyooJZKYQBSYerq q7DG/yrrrLTWaqeqfjmD665L2errr8AGK+ywxBZ7HK/IlnkCfsY26yxDyUYrLWLPVpslOwhOq+22 3Hbr7bfghnulteSWa+656Kar7rrstuvuu/DGK++89NZrr0bi5qvvVff2a+i+AAfslL8EF2zwwc8J rPDCDDfs8MMQRyzxxBRX3GAnFieI8MZfZuwxuByHLPLIJJds8rAfp8ztySyTqPLL0rYs88w0VxTD yTDnrPPOPO9Y88/09Sz00EQXDSHQSMNn9NJpJu20sCI8LfXUVMPI9NVYZ611ZFV37d3WYEfp9dh5 hm322Win3RbZbLfttq1qx+3z23Q3J/fdK9b9ayV69//dMt5q6kFxuW74/SLgiCeu+OKMNx6h4ZBH LvnklFdu+eUSOa7545h3ntrmoDfo+eikl35e6KhrbPrqrLfOHiqux25R6rTXbvvtPrqD+4NF7r50 LFflw1nvackeOwAq+a58XMQv7zxlzVulxvPUrxV9VcZz9MTbyGfvPUndfy/+R+GHVP356KeP5fjs t+/++/CjqP78hsVvf0T05z/Y/fw3pP//AAygAAfop/4Z8IAITKACF8hAaBHQMZV4oAQnSMEK9qWB GHyOODJYrc9Yw4IgDOGPxCHCEu6Jg/wzoQpXyMIWunAxKKTONjr4wrgQ43lwWoYOdxjD1u3whzzs odX/mPTDGhZQiO8jmhiMyMQmOvGJUIyiFKdIxSr2B4lYzGLlrMjFLnrxi2AMoxjHSMYyfkyL7DOj CdHIxja+TY1wjKMc59gzN3qPjhW0ox73+DQ8UpCPgAykzOAYihAKknV+TKQi03bI1S2SgI2MpCQL 9sgBTnJ0lRTgJTfJyU56skuZDKUoR0nKUprylKgc2Ccpl0r0rZKVrayejBjwyv/E8pa4zKUud8nL Xvryl+KqpTCH+StgGvOYyEwmYIhpOGWGjiQWYObGnAk6afaNmtjMpja3CRVr6o2bi/OmOMfpKHAq TiNaIOfIzMnOdrqTm+qMpzznSc96focK60EBdN55/7eWXeMa9nQgP9UW0IIa9KAI7chA45bQhjr0 oRAlyEIJGtGZTfSiGM2oRjcKsop69KPj4ejWQErSkpqUPV44qUpXykGRuvSlMKUiS2dKU+HElGk1 zalOd8rTnvr0p6sLwAFvStSiGvWoSE1qK4HK1KY69alQlY5Sp0rVqvouqvCyqla3ytVw3isTmeCp 0cDa1Y9loqweIytaLXbWtVZMrRkVGVhPara2TrRkcwXpmPCAGbu+E6vv0lEx3EpYCQLWXYWNIgMS Kzp1qoJsjI3YYSdL2cqWLLIQs2xuSOAyzDpMs+jy7GdBay7RNoy0pTWtalfL2tZuFLXl2uUrrgpb a/+5FmD2IENtn3Xbfe2Whr0N5m+dFdzixnS4yE2ucperU+P2xBHJYsgo3KMMZTD3V9W9rq2qa13t usZD3HXutqorXm2Ft7zSIi96p6WM9SrGu/AVq3vn2874+gqZs32mfWtF32nt978swdYlJVaHwgL4 wAhO8IH6y+AGO7hNCo6whCfsngdbGJkUzrCGN8xh012YhZP4MF86HCkRm/jEKE6xile8s2Ow+MWk ITGkYEzjR8r4xjjOcW9qzGM/6vjHnuwxUEhAJSAnSshrMrKSJak1QyD5yZ2JXDdqCeUqi3HJ/2It KnCL5S7z0cpm8vKdwFwmMZv5zGj2CJnJlGY5rXkvTG2OMwrfLCY527mBdM6znqF8ZzDtuch9DrSg z+xaZvz50IhOtE+qgKZBOzp+AQEAIfkEACQAiQAsAAAAAIgCHgAHCP8A/wkcSLCgwYMIEypcyLCh w4cQI0qcSLGixYsYM2rcyLGjx4oaGB77SLKkyZMoU6pcybKly5cwY8qcSbMmSns4c+rcybOnz59A gwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYsyK1ybWr169gw4odS7as2bNo06pdy7at27dw48qd S7eu3bt4E2rdy7ev37+AAwseTLiw4cOIc+ZdzLix48eQI0ueTLmy5cuPhWLenDax58+gQ4sefZSz 6bKkU6tezbq10tOQP8CeTbu2Wc0CP+iW/W+379++D+4mqLsg74HAgRM/nns5c+a9jRsPnlu5cuTF sQ/XTp17ctm8f0//T65deHaD0Il7/76dt+v38OPL/9zwfPT06hGez24/uvT86EEX3nH8qffcf835 h+By2CXoIH4LKticgPpN12B1FwIoXXoHCmfbhyDKpRl+EDqI3n/gaWiihAbmR+GDCnLooocnzojc jQu9eGOJEeqoI44nygjkf/MVaeSRSErFEIQ8MulhikOu6OSBJMJIYI0JVhnhhADyKCWNS6rIJZYr 7kimkyGmqSZaQjF5XZlwQnlljxXGyGKWZpYpXnXiWfdkl29G6aaXHW4IJpz3nXmde0k26uijkBJF 4HBN1mkonnSCGd6d/m2KqYaeblnlnoiqSGiJhbZIJqdzDolmpLDG/yrramFeaumWiX4qqKWbapnr r6ayuuqYEnrJorGcFvvnqiR2ZyKaa0YrrVcj2npoplQye6ucC0IJ7K6+BqtsqbvWqm2Xomra7UKz tuvuu6P1lm1CqE4qpZBRCjpghvJaeGac5l34orE/lsusvRgmLOaPqeYH78MQR/wXd3w6e2rD/W2H qIDP9feleRqTV2/D9wUqL8kVowryyiBTuu56nkos88w0PzXtzRzVrPPOPP+E888Y9Sz00DUDbTRF RCet9LtHN/3V0lBHHZXTVFdt9dVYZ6311lx37fXXYIe9klACFFQ2QWcLlLYAbLfd9kBuq21Q2ma/ /Y/bbKNt9t15wzSN99997+133IMTPnfgfAvud91oI4743XwbrjfcijtEd+GR/9145XbLPTnlkP8j 9eikIxUQACH5BAAkAIkALAAAHQCIAh4ABwj/AO0JHEhQoIB/CBEeTPhvocKEAiJKlAiRYkOGDzEq tDgxIkOHDy1u7EgSJMSPHVGm1NjQY0WMJl2+rAhSZsiVMD/mZMnzosaJLUui3DlSp9GTPgsqXcq0 qdOnUKNKnUq1qtWrWLNq3cq1q1eCPZGGPHrQpM+ZY4mivRhzYU2xP4+eTTu3ZcawMl3arLtXr0O/ OdvqfHs37OChcM1u3JnX7WGkig1Lnky5suXLmDNr3sy5s+fPoENfhnq2bOK6fFmaXa06bmm5agmf /Os6MmzHsumaTs32sdzdd23zBI4a9myjMcUCp/3vq/Pn0KNLn069unXok2kzp3u6tdrixXcn/x/+ OzDc43hbE0+uPXxv9ESJv7e83HDk9e5fbxcuur9/yX38J+CABBZo4IGStVeYfHPdJ5RxhR3HGnnd wadYWSR9l9Z2GYnnnmPcKZcaf+qd51pt8CFnoYkItujiizDGKOOMnIHo036xUXgbTQyytRd4DQJF VoQhnuibjR3e+CFk+XEInpBDAklkcEUq+dqVNGap5ZZcduklQqTNtx6UC+p4HmsXWslimRGulCZ/ bzIZ5XxHVukWmVIOJyScOuLmnZgNgnndoIQWauihiCaKFWX1yTYeixPuOCGHtuXmKJFImqkmnVhm iqRpkTpJ4olOalimp3WO+uWqrLbq6qua9f8l6m1vRbqWfHrNaeR47MGUqWp/efoocsG2iSuqa/bE q6WaArbYWnYlC+u01FZr7YBh8tYmhHsaqdKdZLL3I5u+3RRuhsDmFi2kKtEalEja5ultTfA+6Wu7 8+6k6L789uvvvwA3de3ABBds8MEIJ6zwwgw37PDDEBcMQMQUV2zxxRhnfDAAHE+s8cMBhyzyyCSX bPLJ03WM8sost+zyyzDHLDPMKs9sc3Qf56zzzjx/1rHHPVN889BEF2300V9xjPTSWwXt9NNQRy11 w0xXbfXVWGet9dZcd+3112CHLfa+NYxt9tlop6322mzL/EzbcMct99x012333XjnrffWGOw07ffZ Uwcu+OCEF97i34gnrvjiJhvuahOORy755JRXbvnlmGeu+eacd+65xoyHLvropE8XEAAh+QQAJACJ ACwAADoAiAIeAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihwp8Z/J kyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRozZJKl3KtKnTp1CXEolKtarVq1gd It3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp17NKvdu3jz6t3Lt6/fv4ADCx5MuLDhw4gTk6TL uLHjx5AjS57MliHly5gz51TMubPnkZpDix5NurTp0zgto17NGu7n17BjT5TJrza/f7Zvm9SNG3dt lLZ3Bz+Z+/Zw4rxzIzcOfDlv5M6fC1f5nDlx576PZ0/+ezt24cmbV//fLp2l8vHFsYdfTp56997X 01+fn51+eObWW+vfH1r6et3rNQefefNVF+B//7n03m7mlYeegP4RyOCEDlJXoHgH0pbSgxt2OCB9 H9o34YgOJkihiPiFyF9YMKzo4k0VxvdhjOUJCJ+J492oY40XgtgjiPn1FqOFPUbooYwyAuijhDYK eSSSTw7JYI4qWhfkjk46eeWLXHbJFoC/oWekjdrZt6CSM56oJXgeUgnhhulxGJxyTaJZX5Udyjlg iW6CN+dwJTKJp3hkEpnim4emyKOXjDYKFodTpvnkiCgCB+ibewbpn3Y10glkmpBGSWmkk2qa6ZIr SXllhZ02Oaqpo57caqSikW7p6K24InVfkUtKSaKapO5JqZ1uBvjppznumqqIbRKpI5TCxjRmlq7a eeyR1ho77K+1qpjrt+DupNp5x913ZphlckutkOWGSSanhYp6rKfeyecne/R6yumlzEo7J4btujvs ezzue6azmY65K3OyNezwww+FK/G3EFdscWcTZ6zxxqEhwvHHIIcs8sgkl2zyySinnNbFLLfs8ssw x5yRyjTXbPPNQMms80fW7Ozzz0BDhfPQRBdt9ElBJ6300kw3zdTRUEct9dRUV2311Zc5rfXWXHft 9UABAQAh+QQAJACJACwAAFcAiAIeAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzI saPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnT p1CjSp1KtarVqzz/ad3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jz6t3Lt6/fv4AD Cx5MuLDhw4gTK17MuLHjx5AjS55MuXJjrJgza97MubPnz6BDix5NurTp06hTq17NurXr15sty55N ezCX2rhz694tFrbv38CDJ+VNvLjx48iTK1/OvLnz59CjS59OvbrdCmSxM9duvbv3vgDCA//YKp78 eK3h/4k/j549e/Xw0XN9776+efXrCVfYz53/Vu7/8NffgP8N2N9/XPkHIHYCIuhggwIyuF+BEvoX oIUOaoWhdgCetWGDGmKYoIIbIigiiAcG+N2KLNL1nnwwptdefDTKiB958r1oo30zzviiYB2qqOGQ GXJIYIgPEhmkkSYm2aRXKUbZVZBEVslhlR5mKCSWUE7pZIpFCrlgi2SW2RVDP+oI33hs1hhjjm+q ed6cca5JI47/INQWQkt6OWaTDIqp5KBUXmlogluqWKiTgiL6FZhDTgjihZE6GiaXg3oJqKVWKuql cKAalWZXbZbqZnx02gnjfHCiCmep5cH/qCdbfIYYKKJ/VhrolWJOiOSjhCZ6q5K+Wllsr8WKuGWH tx5oKLOaLgssssJSyqm0xw4Z6rY2kTUqq6myGSt+MvJ456rlxhruuYGNCW2unjaKIrbTEujutWAO 2+i0neLaKYRdWgppwJVuquWFvuqbqJkMN0yqV+69qSqeraILMbgYu/qtX1Jm2i+v+jbrMaPx7rtw vh+HBW/Hzl7bL5Z9/vtlmNBW6/DN1jHU3o47PqwmjvRRLHSbQPucX3yzrjXrpB9KWqK/T5a8oKS4 nmjhpNJG6jSJ2TJ77LBGKkxhtLbyWjbCKF99cpjc+uaDTjjHrV+LVMptd3I6P5e0WnvfH63yity1 LfjghBdu+OE9+a344ow37vjjkEcu+eSCBQQAIfkEACQAiQAsAAB0AIgCHgAHCP8A/wkcSLCgwYMI EypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cwY8qcSbOmzZs4c+rc ybNnTXtAgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169gw4odS7as2bNo06pdy3Ys oLZw48qdS7eu3apm7urdy7ev37+AAwseTLiw4cOIEytezLix48eQI0ueTLmy5cuYL/vczLmz58+g Q4seTbq06dOoU6tevVHpSqOeYV/MTLu27dt2XxeNvXs27t/AgwvX+g+AcQDFByI3rnz5cYLPBSI/ KJuzbAHYBfzLrl1g9+3bsf//G06+vPnfDKdDT15cPXP30pXHZ63wu/eB3fPjp8+/v///pimlnnzT LZecgfENeGBB01W3mVH23befdvZ1d96FGGZYW3sDwmegc8yxRyCDAjnoE4TeiVdheAVZqOGLMMao 2HrzsVegiAiOSF1v1hW14o/g7TeejEQWaaRaEME3341KNkniaZUg9B2FQuonIYBYZqnlljsd16F8 63kJXYgc3vgfd+GJdyWFanLp5ptwxinnnHTWaeedeOap55589unnn4AGKuig/rk2kolcHqnoooyS ReijkEYqKWgCRhcdh829J+aORJmmoILtSfdco6SWaipYHtaoJJgKIfrZpmQuSCnikKfWauutQqWn o5NP0thfjjXKCuqkxBZrLEMCEhirmWOSqaCrnsU6q42Y0orrtdhiC+uszLKaELTRfknjl9mWa65h xpUVEAAh+QQAJACJACwAAJEAiAIeAAcI/wDtCRxIUCCAgwD+/UuYUOFChQ0dPpRIUWHBgRUzatzI saPHjgclRoRI0mHCiyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnwUPAk3pceTEiEgpGp34sanT p1A5MjRJteHIpVGzat3KtavXr2DDih1LtqzZs2ilYk1bMYnRpAhNxkUYkinbuxvpyrUK0WpdvIAD Cx5MuLDhw4jR/k3MuLHTtY4PN4lMubLly5gZL87MeTDkzqBDix5NurTiz6ZTq17NurXr1683w55N u7bt27hzP0atu7fv38CDC08rO2tLvXFFUiVJlyHy5SWZ/30OnSJRsVex+g05tLv37+DDi/8fT768 +fM7hXrXrjz61PbL37ZPCt+uxOtgqb/l6xC9//8ABijggAQWaGBMRWUk31T8VffQUleVBOF8gb13 VEUNkobPcBx26OFqxy02IYN91aXXQto1J2GJKJ5oFH5fiSjbdhYdaOONOOao4448Fhifgg9eWF+Q SlFol4X29YfSWJtNqFyPUEYp5ZRUVpljVRqRmKF9W0bIFFxGKnkRk0e6V6SVaKap5ppstqlScifC hxRy1JVZ1XRzhVnjmPklh2J8ISXn5qCEsoRIoYgmOtOHZfHG6KOQRirppI05SumlmGaqKUWMbOrp p6CG+mhLr8GImKKopqrqqqiK6uqrsMbVqluIEPrZF3TZ+YnnfoHSaes/pno1J69+7cnqscgmqyyV DtJ3K5YYKkWfs9ENaSxB2Nnq5YrLIjpPt+CGu2OzRoIZ7Y9COlnkcsFuhWS1Xp4k7rz01msvqUXR GC+8WZY7HYtx2slWk9LyZ6msCCesMHHrSqhtv3vxRe271VZIbZFbLqzxxhxj13CGF+OqXIPmNpzk WSTW997BHbfsMqy0YqirnBCX6ayv/7K7ZJ8mwtmiXNfeK/TQRB/LMcsvJ6300ggjzfTTUIuK723t 4lX01Vhn3WZAACH5BAAkAIkALAAArgCIAh4ABwj/AO0JHEhQ4L+DCBMqXMiwocOHECMmLDhQosWL CClq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKPImxps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMq /flxqdOMGp9OnEm1qtWrWLNq3cq1q9evJRECUDj2YNl/YwGoVYt2bVqxCd2eZWuWrti1bfHKVbhx 51y8d8u6/Qe2sOHDiBMrXsy4cdi2ZOGaRRs57uSFZ+tKnlu581SKOgdnxkwZquPTqFOrXs26tVfK o2HLLi0ZbuzLlwXnJs37cl+cb3EzDH7QtfHjyJMrX65YN+C3wQfnFXxbuO68m9lKt148ak67gCsD /2ZOvrz58+iRR9xrGbpw2pOrZ5ZOfD782kftvo9dXar//wAGKOCABBZoYFBNvSdbdJ6VdhtntuHG 2YOWEebdd/A5N5yF6XXo4YcghvjSRRRKKJpo+EnYXm0nhmefUPSBNx12B9Zo44045qjjjjz26GN/ PgYp5JBEFmmkjgkeCdFvGOIk4pNQRinllFRWaeWVWGap5ZZcdunll2CGKeaYZJZp5plopqnmmmy2 6eabcMYp55x01mnnnXjmqeeefIqp5J+ABirooIQWauihiCaq6KKMNopjn5BGKqmejlZq6aWYZqrp ppx26umnoIYq6qiklmrqqUZNquqqrLbq6quwxhnqGqq01mrrrbXKquuuY3rA66/ABivsSwEBACH5 BAAkAIkALAAAywCIAh4ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK HEmypMmTKFOqXMmypcuXMGPKrPivps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1 qtWrWLNq3cq1q9evYMOKHUu2LNKZaNOqXcu2rdu3cOPKnUu3rt27ePPq3fvQrN+/gAMLHky4sOHD UxkiXsy4sWOpfCNLtvu4suXLmDNr3sy5s+fPoEOLHk3aqqrTqmqiPm0zdet/qHHGhj075+rWrlXL Zr169m3ZN3PDDk68+GvivY8bH66cuereuW8Ld/48NfTp1YX/3p18uvXa2Zs7///tnbt04NDNqw9e Ozn10vDjc9VO3XV08brr2y7OGn/55v/lJ6B1xmFXHn3v6accgcAt956BDeqEIIISOsjgePw1SF+A ET6YYIEAhpggdvKVaCJUJB4o4If29QThhRAuR2KGLb5GYYw2ZrjfcDXqhuOIHa74IYs7FunhfUCq aOSQFPro4nEv7vfjiVRW2RNDKaLn4Y4zCskjhkE2WeGX+ikZpoJZkrmhkVO2uVOaDoqYY35RIjcm fiuaeWePc9rZ4GSABtrWT9Hxht6UA4LnJYN8CumdonQyh+SWS14o6ZiMLtihgemduaehQQKY3nZ1 9hnbdW+y1517uPWXpJTkWf8p66xE6fklh3jiSuau4nVZKoy9poocqRXeNymHbnpaKZB3HjmglFr6 iaeCfWLq36uh0qrtto46S22clJrK7LQsFqqqq152C+duuJ2L7LLKnolontFeWq+T0qb7La9FNsrv v11yKzBoiq0JpaZcxjkhe/DS2/C7wtobVIAQB6twtg6LKWO9k4LpMb8zimlpv3IuvJOgKKcM08TS EWsjurTZB2l4eT4q8syUViyhq+taaPGip4aJbsCsbtesnoXCrGh3GIsc89IFLt3ekgNXbfXVWGet 9dZcd+3112CHLfbYZJdt9tlDqaw2RS2s7fbbcMd90taboG333XjnrffefPcwjZjcCNEB+OCEF274 4YgnrvjijDdO0BCORy755JRXHrffmGeu+eaORcP556CHrlRAACH5BAAkAIkALAAA6ACIAh4ABwj/ AP8JHEiwoMGDCBMqXMgwGsOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmyZEF7KFOqXMmypcuXMGPK nEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPiNMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOKHUu2 rNmzaNOqXcu2rVuKSuPKnUu3rt27ePPq3cu3r9+UbwMLHky4sGGxDsv+Xcy4sePHkCNLnky5suXL mDNr3sy5s+fPoEOLHk26tOnTqFOrXs26teu5h2PLnk27tu3buHPr3s27t+/fwIMLH068uPHjyJPP rqd84+vn0KNLn069uvXr2LNr3869u/fv4Lc3ZR9Pvrz58+jTq1/PfnD49/Djy1+MwG/7+/jz6x+I AMHV+QAGKOCARPWn134IJqggef0t6OCDEEaIUIMSVmjhhe1R2BSBHHbo4YczGRgXhiSWaOJZGo4E 4oostujiizDGKOOMRQUEACH5BAAkAIkALAAABQGIAh4ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNK nEixosWLGDNq3Mixo8ePIEOKHCnxn8mTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0 qNGjSJMqXcq0qdOnUKNKnUq1qtWcDK9q3ZqSpNevYMOKHUu2rNmzJE0WWFvgH9u2ak+2ZYuSrtq3 buvivat3rdu9e+/6/QuX8OC/chPTLZxXMOPHhucmjms4L9rLmDNr3sy5s2eIMRk3bgy3sOjSlCen 1qt69eiUpkm75ks5NuLaLA9Lrqt6d2uuwIMLH068uHGYDEW/lgyZt2zns1G/nq489W7pzlE3vz6d t3aVzJ8n//5Mvrz58+jTq19Y2i/kw67tVl4uH7vdwPIdC5Zbv/Zp3NfB9x1+efl23z/rJajgggw2 6KBBML3n3XKwjfbfb/NNmBt04UV34Hb8Udibb4oVCF53x6Wo4oostujiTFnFZpt9FYq32oXxoXhj iTZSSKOItu2oXHhDnvSgV5UcqeSSTDaJkH4ExpWfjHhVWaV391kJ33xULqZhge5xOCWW/Vl3oJNo pqnmmmwq9OKbOrUp55x01pkenHjaZOeefPbpZ0Z5BirooIQWauihSP2p6KKMNuroo5BGKumklFaa EKKYZqrpppx2WpyloIYq6qiSSkLqqaimquqqrLbq6quwAkzq6ay01mrrrbjmquuuvPbqa6fg/Crs sMQWa2yxSRyr7LJ5SsGsVLFGK+201FZr7bXYZqvtttx26+234IYr7rjklmvuueimq+66igYEACH5 BAAkAIkALAAAIgGIAh4ABwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK HCnxn8mTKFOqXMmypcuXMGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjNkkqXcq0qdOnUKNKnUq1 qtWrWLNq3cq1q9evYMOKHYm0rNmzaNOqXcu2rdu3cOPKPTm2rt27ePPq3ct369y/gAMLHky4sOHD iBMrXsy4sePHkCOrRSe5suXLmDNr3sy5s+fPoEOLHk3apZSep1GmprnaZOuyryPHLm14dk0ptmkf zq07J8PTwGHixr3yNW+WxpGfBD58Z+vn/3hDn3n85uzhxGXGxh40d/bo0m83/x8aPDry8S2rw065 Wr3w9umbX3fNmrvw4uxN9tUKvvrx5Lflhx998OU0HX0vHRiTe6wNGKBqRXnXHoP3rWeeg+HBtd2F PH2XnoAg2kShgwju19R95Smn0nipcSffhARe+JyH8BW4Yovo2YdgjDruKGN2PXLo2oRA4vhdkD6a Z+SQzEHopJIs5ggklP1BGByOPPYH45OqTclckdO1SGWQBXpZJYtQNjkkk0SuyR6WVu74JXjLbSij klzSqSdxS2pJYpRT+mmfh70R5R+THF653J1CqplikjEmapqkNmrJp6R1urhopWFSGimekFq656aL vinmpymmOqqQWUJnZqQKyv+5KqhOilkep6RSyaiup7qaK4LzzSdrr3kSS2iVrN7qKaQ2qursr4Xe xBB1cWYJK7CXIhoirOjd+KyPvuL6q6qlskmpfOOSiCmj3i1L67frAostvF/G6m6Z+SmqLLiAkltj qb1mS6ufXT5a7r/sEjooq/lmeifCDDfrKcTlmYhVg6i+y+7DAK/YcMS13sulouBWq3G5jUJLcclP StzuyjCj3Cmo9DKc5MqydjnqqSmP3HHGHGtsb9AgImwry9YqZ2zGleYstMipWbxUd4DOu++SEmvb sscFY9pjuN323K+pfQ4qsJE8J9s1sjMe+SKYbabcLYDoAh02wWiai+zB8or/23WzgW58JsBgmsps wVdrLXfEOWp7a+B2Op6rpvJGK+1CnY34oHU6aa45atvKZvnoIroktVKkk2egdccSBqBln6de2t2y 12777bjnrvvuvPfu++/AYxb7tp7HNbxbx0e4efDMNz/XbwOf1/rr1EpvMHVbfmxc3nli33qFQm3/ fegep712nZluxz3KNZ3u/vvwO7Tg+OxzXT/45LOOfvkq2uw/+MVT3dYSpJ1Q7UpP8Urg/ZzHwN9B 73rdY5u5XrQ/klHvR3yqGqlIhieBDQtRZ6MZ9eBUpoChDYRbMpvPEBi4jTWJTDlL24Ee98INuqk5 8cuhVgCgQ6YYsFYh/JYM1ndWnFc9rWEctODgkrYrRyGNZtfqYLqWdkSZHfBRS+NZ20LWsw/OjFef 6qEYqwIAHo6xIj/xVdISt8S94admaiOaEhH3qSYmam5WQtMJa2asukXPVVULlxTjhcX1te1oP3vX +hpYOwDwblrVe5rRroUvpYmMZYgc5AWx+MFQVXJyJhNiHSEWw5Btj4iErBzQ2MfJS0LojLCUihlj +RCqFQ6DbPQjp/JGuTQVa4J1jCMv/ejGrx3pb47j5by8RkeHtbGUJ+skge5Gt0D18kz0Y2S0ypi7 gAAAIfkEACQAiQAsAAA/AYgCHgAHCP8A/wkcSLCgwYP/pCiUInBhw4YOGSZ8mFDhRIoXIVq8uJCh xIkOB36k2JFjRowkN0osOTKkxpYbT0bU+JJkSo8iUZYUqdLiyIwrH35smZPoToI/V6qsCdNjTIRQ o0qdSrWq1atYs2rdyrUqAABdw4odC9We2bNozZJdy/Un27dwp7qNS7cu3LR48+rdy7ev37+AAwse TLiw4cOIEytevNeu46ouH0t+O3ey5cuYM2vezLmz58+gQ4seTbq06dOoU6u+23e169ewY8uePZqx 7du4cwdGGbfy46efcWb1XZc4b8rBLxvXvNxqc6rP2eqeTr36X7kgo3aMHvRgZOyQCxr/1f69q3Cs SdHPBK/9JMLyUolCPRq2e32k7o/TfO9d/3yWa0XHm33t5SSef7QlSJVfFRknoIGVERjggQbO11t+ 0Jmn1XLnWYihh+xN+CF6+PHX34dzPVjiiMORWGJzMbkloHU01mjjXjgRl55SPFbEk3xD9biUhCG5 NF5kMnK0lFBGRlSkkjzZBFKTT+1IpXDAURjli1sWmWKDK1aYY3Y+NqgUme55Cdx4ZrbJ5X49QaQk j1/WROaTNzkV45JTIqVnkAd2F2ePbt5o6KGJhRcfS/adJ5+fQwll05krdmimT/kJ2ShQnEbqqaD4 OdpphXCOKqmEYZJaXqSkSqqlmGUu/ykqqOm5KtN2aIr6I6w72qprpUVt6mlRxPqaJkZYcsnmrK0q 6KyIsEpZa7Ft0ionsNPe+eqvzBo7rJ1Ofpsrf91mR9+rYFKbbpBJHqslt+tpiyaynKo6LqvG+orp vc3iy62p/HpL4adVdrlvuSo+q3CB0QJsr0kQurqmujLVy+vFAmdcsbwIkwvwmKluDOSkEb+Lrrj4 mhrUtL9W3HHJ366scbsfU9sxyu6KG2ayMue78M8a7txTowXfBDHISfGp05QyxptutRCGS6Cao7JK 3066AriuQVgXPee6WerJtZotx9szhnhuLLHZwD5NKJZ80qzzlUxFzS6R9SL54pClIrwI9GoM/i34 fW2ZOHiGxR3erGyINu44Y4pHDl2WkFEuOeJwwbew5rE97vnnoIcu+uikl2766ainrvrqrV3u+uuw xy777JyxbvvtuOeu++689+7778AHL/zwxBdvPO5rxUD78sw37/zz0Ecv/fTUV2/99dhnr/323Hfv /ffghy/++OSXb/756Kev/vrst+/++/DHD//x9Ndv//3452+//Pz377/6+gugAM0ihAEa8IAITKAC F8jABjrwgX4JCAAh+QQAJACJACwAAFwBiAIeAAcI/wDtCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihwp8Z/JkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRozZJ Kl3KtKnTp1CjSp1KtarVqwORat3KtavXr2DDih1LtqzZsyexql3Ltq3bt3Djyp1Lt67du3jz6vVo be/HCH4voh1MuLDhw4gTK17MmGjgx5AjS55MubLaxpgza97MubPnz6BDix5NurTp06h/MvxsubXr 17BjU05Nu7bt27hz697Nu7fv38CDn+Q3vDjx4ib5KVep/Hjz4yif/5Oe3Pjy5sKza9/O3TZD6OCn R/+vTn68eJbQyztXn5K47Pfw48ufv1Y88fvl7bfff565f+P9BSgefQQWaOCBCEakH37TPccgchBi Zx526d2XXoDHJajhhhx2CNuC51Uo4IUXYjieiA/2B52HLLbo4otTxYQfgyKq+J95EdoYIoTd9ejj j0COFl5+4C3X3nUSHomkkTZKWGKQUEYp5ZRAreYZjFhmqeWWIbHG5ZdghinmQVSWaeaZoI0pEJps tunmm51Z+ZIUKdFZk5044Vmbnl3xSZOfKwEaFJ18SiEoT4bGdChvi/pE6GFqNmSSoYmqVKhNglI6 56Z1KnrUo/80qmejOl1KKkp2nnpqqJ3KBOqkRa3/yuqgnLaKqK0spfpnqJqeVCmvrD4q66ywiopq TJF66tKld7ZEqrGI6brssVsNCyux0yp706vY0uqqUNASxayz1yrKra94/nqutt3mSi2cOwHaa6qa 1puurqD6Sa+69frKK6HCzlppr8X+OunACAN8sMLBMsyvwQnXOa/AA/u7r7AEUzoqwPxK3PG/wFpM MLrFoproxByHPDLILBMbsMYk/6vvxQfXHKzK+M578r0L02vywhLLHPOx69788s0sw/yu0Stju2/P 8Crbb8npClxuwyVbWu6rXLtsc77trjuqxdeCbXTZWTu99bsO+4t013C7jXbWY9PtNdFy41131RVb f60v2WyrnHfXbsftt7Rk8402voAXPvjaiB9u6tlHp70xzHDvjHnj1rI5tuKKWw3yvfJCzvncfE9M 7bheS2t2wBSf/Pjdpq/9duu4X404x3U33PfkV4+udu6iR0587XdP7bTy+TKPLuy3+26447pDPrLG VVN/9PS9nx3856fDGRAAIfkEACQAiQAsAAB5AYgCHgAHCP8A/wkcSFCgFIIHDxr8l3BgQ4YLGUp5 KFFhQYUWKWqMiNFhxY4II3ocCRHkw44nDU7cODJjyIUuOUIs6XFjTJkwV74sqXOmRZgkVTb8CZIm zqIiKSadyRTjxKYIdbp0+vSmVKgmP2K9uLRlzZ5Cn4r0CXTo1rFEjTJFe3Ztwbdw48qdS7eu3bt4 85K0eRYlUJwvp9bcS/bvTqhBBZPNmnLtzcKOB3dNKVhx5LY7lRo2nJZmZ8tZ2W5uq5ilaKOdC5v9 65fwT8ifJcdNrdqzWtORceeW/Vqv79/Agwuvu5Iqx6uqqxJ2qPy42OIVOQuN/vV1z+syGR99Dtb5 RezMU1P/Xe2z++3p4TNWfR7ycXSl6osyFht+bNimYJG71W+yuXe+ybFkHXrttURfewfuZ5txiLGV kHmXXQfhcBRWaOGFGGao4YYc5tVbh/aBKOKIJJZo4ol6fYiXiii22KE9MMYoI4wu1mgjhyxmOOGN PPbo448i5khcQTMWaeSRSCap5JJMNukkkkBGKeWUVFZp5ZVYZqklh0tu6eWXYIYp5phkvvXkmWim qeaaRpY5JJVCahlnmHO6iaNwdcqV51x50jYcm4AGKmigQObo51tIIbrnYXYVpxmPh3Ll1nfALYqh pS0K+SGmcA04aaMhplhhn5BROOipqApqp0pBdRoqcye6/weprJIayumNt5qoKYieYpqob7m2ymep q5Ip4XjTTbUerJ4d+GCCjWH3oFa1JqteWeglKCm1Eik6WWv0QddtgeX5tZ62/U3Lqm3UcQftuddy C113UsXHWm/H4ovsuOyp2++x4/IrYVTy7guruPy2Ki6E+X4XbrzTIlxfwk4VC+KS4pEmGbgJc/WY uV8B1utRi7W2LaKuhcoxTx5vHNh57DVI8mI5jSbdcqhpjG92IZcK2sul1awggBxbJjK5Ebqs1lIf 85aZzzmfhqBMqVZtNaoZxyRfbfMyitu1P8tM7Xz+abZjg89a1+99RJXNLX4ai71wdvzt5/bLObmt dbUwp//39Md1I2uVckHzpDff5cq89dyenpfyaWknC5vXZet09eWYt0lX1o9HDd/JXyMtYGLkmoxZ aE/bzDXk0m0qOmJNK/35ZibvbHTYSfetstOks5Y6yL4vbfTkteO99PG4x8000JP3rpvFGnYJMFbu Ris5gY6LBt7NDm4noLshWoU9dY751+702sfM/W4Bwg4+4JFfX+6zeDPYttpbRzX6e4ERLrv8ifqe bgQorLGhS30ZOx9lFPY+/f0jcxDMHPQmiKJgfcmCFHQTBjPIwQ56MEja8uAGP+ilEZKwg106oQpX yMIWEiSCMIyhDGdoDxfa8IY4zKEOcZhCUM1mWCQyoZz/cGjCEF7QhzWilZloyMQmOvFyK9KTqxS0 ocZRaFcoGxXiLgXEPf1KikAEIxLfVClejfFNGyTPXJ7Ixja6sUgXYpHrPlXFDmHxTsbjIhi9qKE7 kjFIZvyjIK9YwAyZYYfQk57BJMa/842tYCGsF7PIFh+13UdgZamY4YzzsEs6K34Bs9bEJEmwbvkv YJL8nsfyE7hlked+7crN9jRJSmmRb10IY+TD7rY2wnEnk5ZkV7wG8sZiGpOJUUxeWgrHruzVr0A/ ix3RhDagaeZseIvTXusKGa1qPhN1ugunJpHHNG/yjGZHUx/Kksc768VsdOps2StfhUgdKhJAl9nm Vtg58rN6RTMxgWPbXk7pOa1gs5zOOmdtHLZQ+a3ubfjcH1LMtryWnXNuxGNUI525UXDVLUCzc+BQ dvmTY5r0pJhDo/LYF7Vm7o9kK4voYZgJO2wFL6QUxYxXspdT6yn0oa77Z0WXibhHwTN8GZ2pPpO2 t4nuVHigwxY46VjPqjJUa+ZBTn72aSB1hiagWH2XRM3Hyb7856k3o5f3ssVQdGZrbWhJaFgFB1dh 2WtSpoEleGYpVvf1VV4ihWYDx3cVAlLVqizsYaEOayEhIrZKjn3shVBK2cpGsFBGvFRmJVusyHK2 QpYNrWif9NnSmva0qE3tQAICACH5BAAkAIkALAAAlgGIAh4ABwj/AP8JHEiwoMGDCBMqXMiwocOH ECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKrGivps2bOHPq3Mmzp8+fQIMK HUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWiM7Nq3cq1q9evYMOKBXm1rNmzaNOqXcu2rdu3cOPKtTm2 rt27ePPq3ct369y/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5suXLmDNr3sy5s+fPoEOLHk26tOnT qFOrXs26tevXsH/2nU27tu3buHPr3s27t+/fwIMLD6tkOG1HxpMrXw4xtvPn0KNTXia9uvXr2LO3 Zc69u/fv4G1r/x9Pvrx5yuHTq1/Pvr379/Djy5+v8rx9ojHu698flb7//wAGKOCABBZo4IEUyYbg ggz2xh96DUYoIW0PTjbhhPlciFeFhjmUz4cZgvjhPyJmWBCIA5kokIokikgiQSG6mKKKI7IYIowu oiijjjDiSOOIK/Y4I5BDpigkjkWeWGOPMr5oZIs15kgkjQs1ueKUTEJJpJNX6mhliVy+iKKWBo1J 5pldJqnljUbaCOWaXNpoZos+mvjlk28GieeZVLKooV1++qnniU9iSeigYiI0JZtBCupmnHo+iieV dCJKKaRhOkqpo1e2WWiWZX7aKEOXbtrnnpYeJOigj9qZ0KaeRmUqqqRuGippokf+iOqqo7Ka6qS9 8vrnV5yGeqinrh5bq6KJMorrkU7CmumhgeJ6q7PPhhmtrNRuu2ysyvoq7J7Y3pgsqtMaq26riEL7 LKPlbgssstymWi2357YLarXXfprvsDEFBAAh+QQAV6WJACwAALMBiAIeAAcI/wD/CRxIUGC+gv8O IlRIkKHBhBAjNhzo8KDDiRYhVpRIcaJEhSA9duSoMeLGjhczjhwZkqTJlxtjIvz48OHFmTIxvhS5 0qVPmixrLiyosqRNojuFymx58qhIpkKjIm2JkifDkFRnat3KtavXr2DDih1LtuxXe2jTqkULMp9F t017Gi26Ei7chHd1Zsxp1WDepCSzzuXI16lUpm5x1tyrk2Xiuo/l4o1Ld3DKoRT//rxql6rmwDSv gv4suupguTdLe478WelUq5pFr51Nu7bt27hz697Nu7fv38B7F5Z8mTNmwpsXI0/tUXXUy6Mz9y3O czJWxR/pakfqGnrX4UUjS/9Ffpw7eeaorft9TN07X/bVU/+1W95ladPP63YMzr+///8ABihgbaFh Z15W6C2nFVTDnRcUefop19N9zk3YGHrv5ffUg+MZSKGGxFXXIVASxsfheBU2VRiC5qXnYogRUhbh QAPWaOONOOZoD1j0dSbZehYeiBF9LhJJZHZvsZdYj3fNxxps4k2W2ZJNNkbYkkOKZ2RsM96EE2lP vjhlkmEeFxOVUQJ52JcfPpfXmfeh2CKZ63mZkpZgavmjWXz26eefgAY6Vm6CFmrooYgmquiijDbq 6KOQ+qnjpJRWaqlakWaq6aacdurpp6CGKuqopIp66amopqrqqqy26uqrsMbnKuustNZq66245qrr rrz26it/pQYr7LDEFmvsscgmq+yyzDbr7LPQRivttNRWa+212Gar7bbcCstJt+CGK+645JZL6rfm pqvuuuy2u6mtnPwq77z01mvvvfjmO2m8+vbr77+zpQPwwASrmsnBmfDKb8EMN+zwwxAXjPDB8i4c 8cUYZ6zxxhz3Z3HHIIcs8sgkl2zyySinrPLKLLfs8ssw2+ruzDTXbPPNysas88489+zzz0AHLfTQ weFs9NFIJ620oEQ37fTTPscA9dRUV201q0tnrfXWXHft9ddghy32sleXbfbZQAcEADs= ------=_NextPart_000_000D_01C5D7AB.42BE14A0-- From domainnamefiresale@1-2-free.com Sun Oct 22 23:56:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbqux-0005kG-UM for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 23:56:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbqux-0003cl-SA for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 23:56:03 -0400 Received: from 161.69.181.60.broad.wz.zj.dynamic.cndata.com ([60.181.69.161] helo=user) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gbquq-0006Dk-TF for capwap-archive@lists.ietf.org; Sun, 22 Oct 2006 23:56:03 -0400 Received: from 64.202.166.11 (HELO mailstore1.secureserver.net) by lists.ietf.org with esmtp (RIV8OR683C A7FK) id NDC9II-0RTJLG-EY for capwap-archive@lists.ietf.org; Mon, 23 Nov 2006 03:55:54 -0480 Date: Mon, 23 Nov 2006 03:55:54 -0480 From: "Gwendolyn Snell" X-Mailer: The Bat! (v2.00.7) Educational X-Priority: 3 (Normal) Message-ID: <797290502.32339800739888@thebat.net> To: capwap-archive@lists.ietf.org Subject: Will this Stock be a "Super Nova?" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 2.0 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 STOCnK ALEgRT! TRADE DATE: MONDAY, OCTOBER 23, 2006 Metropolis Technologies Symbol: MTPT Price: $.135 GO LOOK AT THE CHART! DO YOU SEE ACCUMULATION? READY FOR A "BLAST OFF" BREAK OUT? RECENT NEWS: GO READ THE FULL STORIES! Metropolis Technologies Corp. Summarizes $3,500,000 in Signed Contracts and Further Milestones Achievements for 2006 Metropolis Technologies Corp. Raises Revenue Expectations for the 4th Quarter of 2006 MASSIVE PR CAMPAIGN FOR MONDAY.. YOU MAY WANT TO GET IN "BEFORE THE CROWD" RIDE THE BULL!! Information within this report contains forward looking statements=20= within the meaning of Section 27A of the Securities Act of 1933 and Section 21B=20= of the SEC Act of 1934. Statements that involve discussions with respect to=20= projections of future events. Don't rely on them. This company is not a=20= reporting issuer. Past performance is never indicative of future=20= results. We received three hundred thousand free trading shares in the past. We=20= sold all those shares. We received three hundred fifty thousand now.We intend=20= to sell all three hundred fifty thousand shares now, which could cause the=20= stock to go down. All shares were received from the same third party, not an=20= officer, director or affiliate. This company has: nominal cash, an accumulated=20= deficit,a reliance on loans from officers,directors and/or affiliates,the float of=20= stock is increasing and it had no revenue in its most recent quarter. These=20= factors raise doubt about its ability to continue as a going concern. A failure to finance=20= could cause the company to go out of business. This is a high risk security. This=20= report shall not be construed as any kind of investment advice or solicitation. if elizabeth, when mr. darcy gave her the letter, did not expect it to=20= contain a renewal of hislong, during the whole of the journey. from=20= elizabeth's thoughts it was never absent. fixed there bypardon me. it=20= pains me to offend you. but amidst your concern for the defects of your=20= nearestexpressed my hopes, and said he fear w. was not a man to be=20= trusted. my poor mother is really ill, andpreservative from want. this=20= preservative she had now obtained; and at the age of twenty-seven, she explained what its effect on her had been, and how gradually all her=20= former prejudices hadgreater than at home. he heard her attentively, and=20= then said:when lady catherine and her daughter had played as long as=20= they chose, the tables were broken probably soon drive away his regard for me. you do not blame me,=20= however, for refusing him?"people, where he had apparently least to do,=20= and least temptation to go. conjectures as to the meaningmr. wickham's=20= society was of material service in dispelling the gloom which the late=20= perverse From Lauri@anglo-zulu-war-books-tours.com Mon Oct 23 02:33:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtN1-0001sF-Ur for capwap-archive@ietf.org; Mon, 23 Oct 2006 02:33:11 -0400 Received: from [221.232.148.158] (helo=angliatelecom.co.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GbtMj-0003nD-9U for capwap-archive@ietf.org; Mon, 23 Oct 2006 02:33:11 -0400 Message-ID: <001401c6f6af$b983f360$000c8e8c@commonorda58aa> From: Katina To: capwap-archive@ietf.org Subject: He a any Date: Mon, 23 Oct 2006 14:30:01 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0011_01C6F6AF.B983F360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.8 (++) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 ------=_NextPart_000_0011_01C6F6AF.B983F360 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C6F6AF.B983F360" ------=_NextPart_001_0012_01C6F6AF.B983F360 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable God cures and the physician takes the fee. Laughter is the best medicine. L= ife's what happens while you make other plans. Who guards the guards? To ea= ch his own. Ask me no questions, I'll tell you no lies. It's an ill wind that blows no = good. Give a man a fish and you feed him for a day; teach a man to fish and= you feed him for a lifetime. Keep no more cats than catch mice. You can't have it both ways. A little Le= arning is a dang'rous Thing; A good surgeon has an eagle's eye, a lion's he= art, and a lady's hand. The weak can never forgive. Forgiveness is the attribute of the strong. --M= ahatma Gandhi Variety is the spice of life. If the mountain won't come to M= uhammad, Muhammad must go to the mountain.. You have to crawl before you ca= n walk. Absence makes the heart grow fonder. Still waters run deepest. Every dog has his day. Anonymous And drinking largely sobers us again. Men = age like wine; women age like milk. Possible Interpretation: All style and = no substance. Hair of the dog that bit you. You can take a horse to water, but a pencil m= ust lead. People who live in glass houses shouldn't play golf. The teacher = has not taught, until the student has learned. -Winnie Parkerson, Nacogdoch= es County, TX Lead to Success, Follow to Failure (Robert D) ------=_NextPart_001_0012_01C6F6AF.B983F360 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
CHOWCHILLA, California = (AP) -- Sara Jane Olson, the former Symbionese Liberation Army fugitive who= became a Minnesota housewife and is now serving prison time for trying to = bomb police cars in the 1970s, says she tries to hide her radical past from= her fe
NEW YORK (Reuters) -- Wall Street bonuses will rise 15 percent t= his year, with larger increases for investment bankers and equities traders= as merger activity surges and stocks rise, according to a study released M= onday.
BOSTON, Massachusetts (Reuters) -- The maker of the Segway scoote= r Monday unveiled the second generation of its self-balancing electric one-= person vehicle.
3D"#986927"
WASHINGTON (AP) -- The thw= arted terrorist airline plot in Britain is sparking a bitter new round of f= inger-pointing in Connecticut's bruising Senate race. ding women in corpora= te America. MIAMI, Florida (AP) -- Every hurricane season, clusters of show= ers and thunderstorms roll off the coast of Africa and head over the Atlant= ic toward America. Most of these 60 or so tropical waves never do any harm.= But about 10 eventually grow into tropica NEW YORK (Reuters) -- Warren Buf= fett's Berkshire Hathaway Inc. said Monday it has amassed a 1.97 million sh= are stake in Johnson & Johnson, and appears to have sold shares of clothing= retailer Gap Inc. More than 200 homes evacuated in Richmond, Virginia
NASHVILLE, Tennessee (Court = TV) -- The father of a Nashville attorney on trial for killing his wife cla= ims he reburied his murdered daughter-in-law and disposed of evidence relat= ing to her killing. ASIA More Asia News BANGKOK, THAILAND: Thai bombs leave= 2 dead, 28 hurt Atlantis' astronauts strapped into the space shuttle Thurs= day for a practice launch countdown more than two weeks before they are sch= eduled to blast off on a mission to resume construction of the internationa= l space station. CANBERRA, Australia (Reuters) -- Australian scientists hav= e begun looking at smell sensors in worms and insects to help them build an= electronic "cybernose" they hope will one day be capable of measuring arom= as and flavors in wine. CANBERRA, Australia (Reuters) -- Australian scienti= sts have begun looking at smell sensors in worms and insects to help them b= uild an electronic "cybernose" they hope will one day be capable of measuri= ng aromas and flavors in wine. FARGO, North Dakota (AP) -- Alfonso Rodrigue= z Jr. stabbed college student Dru Sjodin, slit her throat and left her to d= ie, a federal prosecutor told jurors Monday.
llow inmates. WASHINGTON (CN= N) -- President Bush declared Lebanon a front in the "global war on terrori= sm" Monday, equating the Israeli battle against Lebanon's Hezbollah guerril= las to the U.S.-led wars in Afghanistan and Iraq. NEW YORK (AP) -- Talk-sho= w hosts Jerry Springer and conservative Tucker Carlson of MSNBC will be amo= ng the celebrities competing on the third season of ABC television's "Danci= ng With the Stars. CHOWCHILLA, California (AP) -- Sara Jane Olson, the form= er Symbionese Liberation Army fugitive who became a Minnesota housewife and= is now serving prison time for trying to bomb police cars in the 1970s, sa= ys she tries to hide her radical past from her fe BOSTON, Massachusetts (Re= uters) -- The maker of the Segway scooter Monday unveiled the second genera= tion of its self-balancing electric one-person vehicle. Lockheed beats Boei= ng for moon launcher EA scores touchdown with Madden
NASHVILLE, Tennessee (Court = TV) -- The father of a Nashville attorney on trial for killing his wife cla= ims he reburied his murdered daughter-in-law and disposed of evidence relat= ing to her killing. CHOWCHILLA, California (AP) -- Sara Jane Olson, the for= mer Symbionese Liberation Army fugitive who became a Minnesota housewife an= d is now serving prison time for trying to bomb police cars in the 1970s, s= ays she tries to hide her radical past from her fe NASHVILLE, Tennessee (Co= urt TV) -- The father of a Nashville attorney on trial for killing his wife= claims he reburied his murdered daughter-in-law and disposed of evidence r= elating to her killing. Are you paid what you're worth? WASHINGTON (AP) -- = The thwarted terrorist airline plot in Britain is sparking a bitter new rou= nd of finger-pointing in Connecticut's bruising Senate race. l storms or mo= nster hurricanes like Katrina and Andrew.
Atlantis' astronauts strappe= d into the space shuttle Thursday for a practice launch countdown more than= two weeks before they are scheduled to blast off on a mission to resume co= nstruction of the international space station. NEW YORK (AP) -- Talk-show h= osts Jerry Springer and conservative Tucker Carlson of MSNBC will be among = the celebrities competing on the third season of ABC television's "Dancing = With the Stars. NEW YORK (Fortune) -- For the past decade, Honda has been o= ut of step with most of its North American competitors - sometimes defiantl= y so. Atlantis' astronauts strapped into the space shuttle Thursday for a p= ractice launch countdown more than two weeks before they are scheduled to b= last off on a mission to resume construction of the international space sta= tion. More than 200 homes evacuated in Richmond, Virginia AFGHANISTAN: 14 B= ritons dead in Afghan aircraft crash LONDON
Hedge fund may boost McDonal= d's stake Layoffs loom -- how safe are you? CANBERRA, Australia (Reuters) -= - Australian scientists have begun looking at smell sensors in worms and in= sects to help them build an electronic "cybernose" they hope will one day b= e capable of measuring aromas and flavors in wine. ENGLAND: Top judge to ru= le on Diana death ENGLAND: Top judge to rule on Diana death CANBERRA, Austr= alia (Reuters) -- Australian scientists have begun looking at smell sensors= in worms and insects to help them build an electronic "cybernose" they hop= e will one day be capable of measuring aromas and flavors in wine. ------=_NextPart_001_0012_01C6F6AF.B983F360-- ------=_NextPart_000_0011_01C6F6AF.B983F360 Content-Type: image/gif; name="lrnoit_353.gif" Content-ID: <001401c6f6af$b983f360$000c8e8c@commonorda58aa> Content-Transfer-Encoding: base64 R0lGODlhsQF1AYQAABMOEf///xH///8i/wD///8R/wAA//8z/yL//zP///8A////AP//Ef// Iv//M/8AADMzM6rdd//dmWZmMwCZAAAAZqpmM92qdzOZAN0RdxGIiDMRMwAzZogid2YAdwAA MyH5BAAFAAAALAAAAACxAXUBAAX/YCCOZGmeaKqubOu+cCzPdG3feK7vfO//QFshSCwaj8ik cslsOp/QqHRKrVqv2Kx2y4URuuBwcSAum8/otHo9a7Df8Lh8Tq/b7/i8fs/v+/+AgYKDhIWG h4iJioMJi46PkJGSk4UOlJeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5iGS6 vb6/wMHCw8TFxsfIycrLzM3Oz9DR0q4G09bX2Nna29zd3t/g4eLj5OXm5+jp6uvs7ZG87lYI 8fT19vf4+fr7/P3+/wADChxIsKDBgwgTKlzIsKHDh5LgQZxIsaLFixgzaswzZKPHjyBDihxJ sqTJkyhT/6pcybKly5cwY8qcSVNltZr3DuDcqYsBz584F9xpBLSQUJgSxR0tum0p02xOn16L esaSVFwdr2rd4XOr169gw4odS7as2bNo06pdy7at27dw48r1I2Cu3bt4y87Ly7dvywd+Awse rHAv4cOIEytezLix48eQI0ueTLmy5ctAiGKOonmzws6eQ4vOoROI4dGoU6tePSsr69ewAXWd 4Tq27du4c+vezbu379+XKFAAXmg48UHGjwcSrlxQ8ubQAwMAEP3P9BNuNtZud716n+7e91AP T768+fPo06tfz96YhPZJrPaQ8B6+Gvr279fPfwY/fzT7/YfSaQJadlOBCCao4P+CDDbo4IMQ RijhhBRWaOGFGGao4YYcduhhGBF8uESIIiZBYolHnIjiipFsx+KLMMYIkQIyRueiPvLVqOOO A4GGVnY8BslUXUIWaeSRSCap5JJMNukkfD7+8QVPRD5p5ZVYZukDjVp26eWXYIYp5phklmnm aqWdqeaabLbJTZVuxilnJBOoOcGddtZ5Jp5z9ulnQAT+KehPs4nD5WM5phXloGukyeijJi2K iKSQVorajZZmqummYRzIqROOfgoSpqKWauqpqKaq6qqstuqqhkm9KuustNZq66245qrrgoE6 0uuuwAYr7LDEFqsckMYmq+yyzDYrDqXORssatNJWa+1atdgyVWi2wB0KlKfchivuuF5OKQ2c 5KarLhjUruvuu/Biaa6D4MZr77345qvvvvz26++/AAf8CQQQqEnwwQYTLHBD7bL568JPJgrx xP08TPEbsV6s8cYcFxkCACH5BACUlQAALAAAAACxAXUBAAX/YCCOZGmeaKqubOu+cCzP6UDf eK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrtnhbd8Tsc6 Som6fs/vHvolC4CDhIWGh4iJikl/i45ZDY+Sk5SVlpeSBgYBmmOdnWKfm6GboGGimE6oKJqt nK2isK+lpiSwo66uJ6u7sre0vrG9urmddyW8JrezxcHAw6DNrLQpy7/MwrrIsrPdva+pTcm2 o5wjptS41NPg7eXK6/Dn5+XpIuPk7rjV8dvz9/XAqWv3Ldo+drXy3aM37xNAgvIMLkT47gmD R78qPpS30KFAjQwlggS4jKO/jqUe/ybMJ5JfyZMwqX1QOfKjSpfcYCo05xFfyIE1M8IQEE6H T4gMd2Ljp68mwAYrN+qE+DKiOqc2v5mUupQiyRVHoyasVdWfQaxHiwoRalWi0rQ5c8IrS9Nt Upo46UUlKfenXa5wW8VhhlMbS2IVyfbbhs4w475qiYQdyJXqYqVZC460O/ZdYLNB+w3Wdxfw 5dKZrbIj2PkwU9deIyMJ3AzxWW+Nc59O/RiY7au462kLFhua77PAEesVPhkpudrIvyrnu9w5 XtlH0mrRnoU7Fu9XwGMfvyMS+fM7RqP/kme9+/fwtbSPH+MYF/X08+uP0Wi///8ABijggCvY QOCBCCao4P+CDDbo4IMQRijhhBRW+J95Fs5x0YEbXmFghiAqQlSIiBBA4okopqjiiiy26OKL MP6AYYw01mjjjVg8oKOOAey4Y48+PgCkkD+aEKQIPxZZQpBCIqnkkj46yeMIUVbJJI9TJhnl CVoyqcKWWU4JJZFXkllkl1g+SSWYW6Jw5JFArgnnnHRqKaWUTcYJoJh58hlnk2mmEKieeXJZ aJaCkukkCWHqSeihgDpaKJSPOkpppT0mimmffCraqJuK/jnpmlTKSWqjnUJKKpKLZkroqv+J yWiffy4qK6WoriDrrYZi2mqgoe6KpaWaojrqr4AOC2qlnDKbLK+zOrssrslKKyr/rLwm2Wq0 KCjwHrS3CqtmtGEee6mpiXbKLbC+ZkokscsaOy2i74J6ppKDDgovtXhqyu+1AOur7pLuorut f2l+CivAhqZq7sIQk1utuxNre7CZokIb8Lir0qvxxq4O6aeqX+Jbb69j0utqm3BKaua7ag7s g32KKBxuoQCEivKpD1s6ca+fBlutzCsLXezP80a6r60VM23w0hDre+7QkdZ7s8sdK40o1Ahb yWa5Q27Lsp1G1vmw2eU2m3CXrIrc870f9xt2yGO67fXcJn88ttSzgu3llaaW+WzCbbfJNY6I Q0HzFfMl7vjjkEdOx4guLM6I5PB5i/nmnDvSnxmUdy76/+ikl2766ajDoHnqrLfeReOuxy67 gJ8rgsDsuEsCe+689+6H78AHL/zwTNxO/PHIQ4Ff8szfsHvqGESPgQvSzyD99C6sHsX1KVRf QvTvcf899o6AP77521dP/gjos9B+DO+rcD3383svv/r2u7++CfHHD8T8AdgfGvwXQAHeD3zk qx8CFSgC+uXvBAxsIP4ICEEDFlAK6OufBSt4Awp2b33YM98GSZDBEfJvhB4cQvtSKIb3KdCE F5TgCUkowwCyL4EwjKEOS9iCF44vfd+b4flWOL0HAlCIMADfiEIYwh7ikITi++H5dFhAIhbR hQs0Yf9uaD8fVvGLUOxiFrnIRP8W1pCMUUQB+D4kwBXW8IlnvN8N50jFAx6Rjk9gIRbx6D0C alAGboxhDnl4xj9CUYJt3F8f4fhADqoRjhdcICLjeMhJ7hCEOaQkIgcJw0CKkI+cBGUd9ec/ MxJBj5iUIhEdWckkGtCUm1ykFPFIRUOKspadtOAeI3nFOJYSkqscpRyHiEr9sRKNZiRkFTOJ TCQ6QYRpxKUqUxnLRALylcy8JCV36UtrthKarfzgI6fJy242s5DUhOUowbkCaBoRm0hM5h2X mU12hrMJwQznLoOpTFpSD54vICQ3zenPOgqUmsOk4T57aU9BAhOSDRRmQjuI0IKuE6LidKQ6 25lNIfT/c5sPZSIdG7lRYapTmR81aBmdqc03ypOG6JyjJMF40IcOEX4dHacmfxlPRXqzpzwo aRDm6UV6chGMR11k/Uh5xKUydZloDOMdJ1jNLF6xhL104jvFyFBJbvWLDhzoP4OaRi86Fapl 9Wla3bkDoebOrTmA60TH6h65ys6uNMArS/+p10JEE3nzTEJgKdrI01mueYhNrGIXy9jGKqFD RKidYycrBshS9rKYJVDoGKs9PTwvMoLIrGhHywQTkbYomz2tamXQ2dWqwbKuja1sZxs82JrO tIr4rBtmxLkP0TZ2vP0tElor3OJiYnkq0q1xlxu2e8npaxjjmNzeJLi5paxM/9wS2XPjBjfr 9g1vfvNSdtlmr769rLtuw9PaeubdmD2OVqUqHKvgC18uxbdtK5vvfQmW3/rSTWkhO1t8twY0 ADctv4xKMH6NNOBSaS3A+DVwhAXV4AWzVwu4pUR9T2ZhBi+Yvx5W8IS/JGJabVi/JC4cgMv2 KhXLd8KHoluIVyxiCNuYw/6lMIhlfCOYOXjHo2pZiHdsYcPZ974mRvKdAhDaGetXwFZrcJRh nOC3VXjI9M1biVkwqXC9t2Ao3m+Q98tffGGZzFh+0snoy2MQV63NrAIAgvs75yTX+MhzBvKV 3/xcLrvpzj0Gs5Bj7GYd//fMH0Y0p8505RTTWcAvfv/0iAetq0bXmM2RtvSQiTwJ5IoBZnnw L6HrbOhRixnNeo70g0eMZ61BmtRFU/WpHS3hWcMa03C+MapjlOEfNxds6CJvw7YbbMKV17pe 25t0l0y2smEMvJ7SMnrT9d2nwS1txoZzy9zL3G57+9vgDre4neBp/wR3POWembnHPdtzszvc 7n63vOdN73rb+974nm1q883vfougyf7Ot28DLgblEnwSxGWBZNez7xg0nLLxXoNvF35wQxiv 4hjfgsGJR4GMh4ECIAf5EUSugpCTPAUnB4LJRxDyFbScBCc3ecc9foM/xHzkMy95x1OuBJLP XOQ8h/nOc/7yAASd5jTgecv/gc50ozfd6T5fOdSPzvKhQ93pUxf6y6UuAqpXvQRPP8HTrd71 ok/2sGAI+tiBXvadY/3ta2fB2t1e9q93He45d0HRw26Cpv+c6N7yOr/T3QK1k13peZf53/Eu 973nve6QrzrXYRD1t4vd6ooH++MlNHAE3RzrlRe66DXPeKOj/PE8V0DMiW75GCwe9Jv/eso/ L/j39DpFk1e81GUueaYP/e+xbzvRd8/7rAt/+C43u/JRP3vHBx/p+nk+9Fkk/UHYdvqXQHsR KH7v62OfDxv/vvjHr6CHT6H65D//5C+Pfp2vfwe1P33Uza75rb8//TmIv92TDnqVt7/vPxd5 KAd5//o3fYRXePRXf/MHfFfXd/1nfEsHfBFIcgCQe9WHePq3gPj3A6/He6Fnd3wHgJfXdqZX eaFXgADIeq0XALDlcwKYAhG3gSI4gni3d6anc1r3gYyXeSvoesyXfDMIIQB3BbenCK83g3H3 gjRYes1Xd4Z3dy/QgUpIelCIgjLYeNKXeTxYe1yne11IfM43evKXeE1IhSRoAkV4hUlghUn3 fzLghmo4BsXnf2zIAhcHhzQSg3G4h3zYh80zhAfCfTcSfn5YiHUwh+rXeEFIh0doBIi4BXqY OyEIBfFXhzjggj1IBJOIcXM3fPbne174iRI4ir13fMKXg6a4fyjQfJ9Yg/+keHzB53ey+Hv4 RnxOyHom6HYr93sdeHix2IiRd4JkF4WrV38l2IuwN4WneIvM6DsXVwVsN3UhmIvHyHZe2IwY qIPBiIyWqI1lSI3aKHrUeHdwmHCzJYtm6Iv9t4vGJ45SKIxQaHnwaIXIeIPfuHhJOILjmIkZ Qoh8sIu8KIGluHRZF5AT2IDO14rSKJBXZ3/Jx4qpCIG+J42raIEOaYhRkIYfh4eLiJHkcX/E mIAeyQWROJImuViCyFzPeJKqZX5cMAEjMAEwGZMkMJMiYJMmgJM3YJM6iQU9eZM/WQIy6ZEy yZM0OZMwiZQBYJQ0GQMrGZRBuQJRKZQuMJVUyQL/VtmUJ5CVv7WSVVmTR3mTSymWTBmTOlmU SFmUQAmUacmWPYmWZrmUaimXSamWcEmXdFmXQymXNVmWOZmWPAmYaPmWc1mYgzmWbOCVNJKU WsmYY6mUejmUe5mTYomYiKmUNHk7MPk8kEmWfYmZjsmWlRmaldmYKcCUjomZlkmZZomaj2lv RtmZr8mCZ7mVo9mUqmmZuXmbskmavbmav6mbkzmVoHmZpbmbxlmbr8mVy3WYwAmWWlmanyma a4mX1smXfxmYcbmWe9mW3AmagOmW19mXoumdc4mdf7mddjmb+qGRIMKcNACfNmKOzHOeLECf 2cmS+rmf/NmfqYOfJwmI//45oJbgkgQ6Htp3oI6QoDigmAoKAw76oBI6oRSKCQxKIe5ZoRq6 oRzaoR76oSAaoiLqIhxQohwgAiZaoiiaogFgoi2qoifAoivqoi96oiOQojb6oiWgojaKozd6 ojm6ozJaoznqoyv6o0DKoyzqojQ6pEKapFCqpFB6pEE6BCV5Bp33HkVKAkEKpC2KojeqAj0a pl8KpjtqpmhapjCqpma6piawpW1Kpl3KpWSapjA6pmkqpGiKp3Dao1Uabn+ap2W6p2JKqHN6 pnMKp4hap4VKqIPqpWHap2f6o3HKAncaqZiKp3paBgb6IoE6qIxqpCigqTQqqKX6pV3qpqd6 qv9vuqp7qqqP6qZ2iqqCGqO0OqOZiqTz5qeKGqqM2qqJSqePCqqsaqi2Oqp16qqpKqnCCqaQ yqvICqm3Sqt/+qne1qvV2qzW2gCk6qjMyqzDyqa16qjiKq7geqht2q3IqqOV6qWaKmfyVqqi 2qRSOqqXaqT4uqT1OqT5Kqtcyq/3qq9ReqcDW6PsarD2mqQzuqbS6qT+qoadOqKLYAEUW7GB aJIVS7EzkJISWwU4+rEgG7IiO7IkW7Ime7Iom7Iqu7Ism7Id+7KY4I/2BqDClaEwe7M4m7Mp wLE627MmELE+G7QrcKVT4H0JIqDihrRCu7RM27SWkKX7SbRO26E2y2//UAsIVUuhSjsCRssi FfC1FUACX0sDYRsEYDu2AXC2ZYsCZ2u2a6sCb3sDagsEc8sFbesDaNsCcau3d9sDeUsGZfu2 e1sCg6sCVwsDgpu2isu2I1C4OpC4ReC4jysCkisFa1u5LLC3mJsDgcu5JrC5WtC5jUu4aFu3 aZu3Y1u6gRu2YLu4cPu5KzC4rXu6tNu4rau6Ymu7s3u6l8u6guu7r0u5wKu7oDu6v9u7tcu7 Yru7u6u8xJsCmju8znu7aou6yXsCzCu9jHu8wtu9tJu6fau9YCC6lJu75eu6hLu853u55cu6 JLA7mhu7sLu+ohu/53u/6Gu+3lu/lfu76zu6/4hrvff7t+ybv65LvuQbvKSrvwiMv/srv7br wKRbwItLwQT8uQn8Bc2bv3dbuJBbwQDsvv07v9BLwg0svBasvwaMvwVMwYwLwCBMtgcMw3Fr utk7uzY8tp+1uhncwoqbwTOswEG8vTQ8wDAswS6swdjLwEZ8xD5cuyIMwSpMAqb1xDFswPyr wi78wSdcwkW8wi5Qw198xPNrvy9MxU3MwSH8w02cxCQ8xEvMxBWcxFZcvFPQvHVbvShMvL7b x91bvRvMx7obuwSsun7ct9/bx6i7yNTrx7zruHPbyCiMvHD7t877yMtryMfbu5pMyJzMvcab yXscyJN8yJY8yKIcwf/gW8g8fMkpArRLYMdTWwekLDkdcqGzfDwym8tOkLVYQLNNC8vrgcu8 bAWHq1pdSwPEbAi13ASSLMHqm7mITAWnPMrVjL2yDL3NzAPXHM1y28HTnMnZHLlmTMZgfARu HAPjfMaQ/MZSjAWQLL7v7MUQvM4vMMLcnLvu68X2LATljMRPwL64u8d/rMignMglvM83bL3d TMPaC87Ji8eszMnqG88RvchQfMk4HM5yPL2pm8rgW9GVzMiqjM9THMcUXdDPS9AhHQAA8NCW /M9YHNBr/L8D/MFj3NBsjNPRC81aXL8OLcdW/MWrm9BXTMk2HcSbW8fte9QPPMfvbMFL7c7/ KJ3GF5y+9JvVTm3OMt3PnpvUn0zG0cu8mcvGTmzCUV3TWC3Ik4zKj9zFaN3WDizROKy3IdzB Zo3JSm3Oaz3EoCvTGPzJbkzWYN3GiNzVVJ0ET1y6Y9zGcfy6+8zCam3Se+3OZmy/l03PXSzG M0wz6VzY6avQk53GZ+zXYZzYfb3C7VzZW+3BRavOhZzIbXvYEy3XRl3KqPzMgb3KHt3JK63H tM3I1SzJwL3RGn3D2hzTjTzbgOzIprvbbs3RbO3KgT3BPBzWub3KzwzOeEzVXv24Os2hPFvM nOPLT2DeWiC15O04y7zeARKh7h3fb6DeRXDMm2PfMkDbMuy2G73N/9LNuVMN3ttMtgOOt5GN zYndzZHs2nw70lfw0dqs2JItxBIeyqt9zl/t03g7BEBM4ffsvfRc1kTc4eqs2Rk+udf72Dyg Wwlcw5qc0ggNxYcs4ied2iwN0y191W8d3TCd4mvd0rZ92gdc28/937Ib06msymlN0iWt5Ows 4zwu26zc5KXt1nNd2zjQ4kJd2oy91weu4hoO0FoNxFtc4+jb5UUtxGjO18F7wojNtynM1ear 0/575gt81ybO2kg90zctzXE+4Vcs4KmN1yrO1Ds9zxjO51ut0WfN5lxM2oWu1vktwEOezgUO 2mIO6W9c5lP82Xq+0mps3Z7+2IctzjAut/+Rjul2btOM/eXeLcVuLudQ3eir7thhXuskbtcd Pdo2TtS0TuuUzelizeaV3eUHPCNDTey+DugY3s90/eKtjNvbbdDSncP9O+XKu9wVbdA8Tty+ jc3eft0R7OBJHtygDu4Hncfha+SGnO3cvcnx7L/ard1Jrtf/rddvze1yfe818t0ZcunhBvBT 0N7yrSAEXwTCXPAZcgEzAN8p0gEd4AL4TVkXwPAigN5zkAGAAPEKr/GEEPH9tsuwndzhHQX8 PukfDtsCH8Z/XfJEANhE4AEe4CCSm+t3rOy6buZ+e+sn4Fsw/+Mnnt+oXQQyL/PvYdyxXfNn jtFMbtt0Lc4hrtL/N07tDF3zTF+27nbgxg3l8268St++aX7cUp7uDz30JDDeMzDz6NHCQO3j 5R7Uy77lSe3h19vCx0DmNr/0YU7Yi67j437hsd7nsj7kr56YRhABVkDoi77Ef+7iyI3bO07Q L1zXWy7aQK/myh7Zhh7qu375Uk3pSBy+YJ7oloD4Nw/ao87ZBEDHbW72gD/s/2v5i5/qze75 IM7Zsy/3xs76c4/zioD2dtvcvX3NG7zQUI/v+P7unnzu3Q3KYIsAtbzgjlzd9R7S5u7ug3sR Ej32ilz9/Y37vp/LDj/p/q7wwZPwfJDMjjX+5l8HW9uHGqABSvD+ZgD8+hn/GHnw+4H//+3P B/IPAoE4igN5oqm6sq37wrE807VdN7e+83j/A4PCIbFoPCKTyiWz6XxCo9IptWq9YrPaLbdL Y3hVuTC5bD6zEAEHuu1+w+PyOb1uv+Pz+iJ77/8DBgoOciVAASAmKi4yNjo+QgIQTlJWWl7m FWBu2qhxfoK2mISSlpqeVkkEaKL2HOj1tcrGSKgmQeDiBuTm7vJC+AL3ovyK9A6f/AIbIxPz ButC60YrHy9bQ2wsO49MD0dLWzNXB0t3X2/Pftrebru7++4yx6t4z8uvgNOnk4C/p+ujdq7f NXr4Utijhm4fMAbo2AiLt1ChQX3qvMSaY/GevGnzNg6kyI/bQP8WG+1xLPeOYESQ3FCKnHiu pcSPE1dezPkDpMWAz+oJQzeS5Mx8I1Ea7HgwoFKXyYIytDkOXsSUMKGm1JmEFQkCg7xRJCjW 6U9oLXgOlYjNH8ByVlUGdUkzLM2axtwmhak0q9a+MsImzYv1xILASBG2DVwyZsm7FRNfzdd0 YdN7BR+PLVjVLxcBeoopmzrOLdvSg1l+a+YMWzjWHUELNIc4rlm45L6JLmqbL+fevn+jGQPc hefhxkUdD8V1yvLkwDM6jy59upZX1K9jz659O3fsYO54kv6dEOxnoYHSRWu+2GyF63/Cj1/2 6ftm/Oajdv8vbW3Zoc8r1h0g/lj22kH/T1l2GVDd2IVYVPgIlN6D/FXU4IGxEVMTYwHyhZtH +zSmBHQCNnFSVVClld5mDt71oYMihZSgVBayaGBivPWj4U04GoaiXS5ySKIXzcFgok8mUVbX gmIhadpMSQq131n3UTgakothRRaVmD3JpJCBgOVjiCRF6FSPU0a1EpQfxXill2gaheWDLEaJ E5tjfrmHhEtRSBePZ17pp2AyCroknsl4ZiZbM2rpGFJH4mMdIONhURiY9enXpFCOrZaalp6u JaVZ1aTIHn709YlMWac+CZZtddqZp6yz0lqrrU5I2kN4t84hHK+/AhussLPsOuwmIxqLCpHJ MtssCpY6e8Qo/8aZKp+imMbFmmpTZTrbqJ62xl+1oNbJraYJDrVofFZ22mo4TbL0ZrQ2qJrl aV7aKeZhOXoU1rSErrnhi/+ERPCMZCYZZ2Qg0jlYSysiGNui894QmcAIEqXvvQz2S1l7Mqp1 8Es7hlzyvnKqpLC9o5Uqso0u9BRrD9D+ajHJRMnr07b4elyjhN2ipybJVzUKIsSZTbgXwgGa GaJ9VQrr1QzVptnyum+ezPOfE28I5EvumryuuAnv3KKBRst1s7w1ak0xvStfzOTETm/c9rUo 26wyo3CrLfdlZE1WIIcCy4wzhFC7DXOY1qYaapQsp+2kUZJbud7H5Y3b2uDgHhjvWv+VTy6q LwA0XtraiaOeuuqrs96666/nUSzss9NeexJSu+Cr7bvz3nuzlPoevPDD4yE7DDQTn7zyy5MC PPOTPh+99NNTX73119dRHPYr5CrrstuDH77445Nfvvnn12qAAQGo70b77bfx/vonOJ+F/O6v D/8kum9xvwrqA5B9AJTfAAWYP/2RYIDzA6AAApgC/z2wgAo8oAQJGEEHBtCBKIDgBivowQxa sIMYDGEHBbgCBRoQhB404AXhp8ITjIKDF/meEGQ4Av3Nz4QiOCD7dsjD//3QhSf8YQl3eMMc 8nCBRCyhCxc4RB0WsYc+vKEJlQhFJlpRihG8YgKReEQqvm//igg8gf+ECEQu2mqCOeziFo0Y xiqukYxBzN8QURhFNrqRjnB8YhO1KMIC3vGLeZSiDb/Yxzh20Y5ybGMP31hIMVoRkUdUJK8e OcYp4tGHGsSiJltgSUmOEYGUXGQTJcnGS2JykZlMoSn3yEIWfJKRqWQlH5XYSkj2BndDUOMW ARnKNT4yhZNsJS+x2MdVBhOQwgTiKCF5TEHikplI3KQcmwnHZ84ymRpUpgjCU8xfxRKKvzwl MeOoTTRiEofmBOYSVWnIcqJTh+p0pytlWU9OtnGeJAAAO+PJxXOiMn3tTCQBR1jKV6ozoQON ZgspaFBbInSaCo2nNlX40AAQ4IXiV9wmCM8YUFpOUJMQHeEwSxrQYM4KpVxQaQyQZwSWagGm 9lso+mq6HePZNKe+055OefCvng6Hhsz7KVCLalTr4fSoSvWdApaaOkM49QwujSpVq2rVqwov BAAh+QQAAgAAACwAAAAAsQF1AQAF/2AgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/I pHLJbDqf0Kh0Sq1ar9gscaDter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SF hoeIiYqLjI2Oj5CRQgWSlZaXmJmam5ydnp+goaKjpKWmp6iWDqmsra4olK+ys7S1ti0It7p5 sbu+v8DBwsPExcY1DMfKy8zNzs/Q0dJTXNPW19jZ2tvcagbd4IIH4eTl5ufo6err7O3u7/Dx 8vP09fb3+Pn6+/z9/v8AAwocSLCgQVQLDipcyLChw4cQI0qcSLGixYtfvmHcyLGjxyUPPvIL KVIfyZJqVv99OomyJZpcP3q5nElTJc2bOHM+SaAzHs+e7hL8BMpuKNGjSGsISMq0iIKmUKNK nUq1qtWrWLNq3cq1q1cyEiR8jRZ2LI+lqMqadaZ2LbO2bpeJdZgsrtmndvPq3cu3r9+/fQgA Hky4sOFZ1Q4rXsy4sePHkCPXSiy5suXLThoUk4m5s+fPJceBHk26tOnTTCegBqV6tafWrjvB jq1pNu2rnG/r3h0PJu/fWesCH068uPHjyJMrX868ufN+Gp9LLyx8unTN1q3mzs6dG+Xu4MOL H0/eEtry6NNfFay+vfv38OPLn0+/vv37eBLi38+/v/9t5/0n4IAEWoRdgQgmyIT/aL98p+CD EEYo4YQUVmhhEhFcWEWGGlLBYYdRfAjiEyKihpcmJY7YlW8qtujiizDGuNCJMj5EgS/b9XVj jUfsyGMRPlpUHT9B/ihEkUMaCRqNSjbp5JNQRtmYflLWk2SVWGap5ZZcdunll2B6cmWYZJZp 5plopqnmmuhFx+ZWY74p55x01mkPe3bmqecrDO7p55+ABirooIQWug+TdQRo6KKMNuroo5Ai 52CklBaHKBGKfgWAn5tWao2bnoYq6qiklmrqqUT1ieqqrO6RaauwxgolqLI+SmWta16K6668 9urrr8AGK+ywxBZr7LHIynhgsoIu+witzEYrILTSVmttWSU5Xqvtttx26+234IYrbhU2ZXMr SrpGEWdP647r7rvwxivvvL06S++9+Oar77789uvvvwAHLPDA20IAgZ4G1ylawgT3l23DEEcs 8cQUV2zxxRhnrPHG8YQAACH5BAAFAAAALAAAAACxAXUBAAX/YCCOZGmeaKqubOu+cCzPdG3f eK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b 7/i8fs/v+/+AgYKDhIWGhywQiIuMjSuKjpGSiJCTlpd+lZibnHWanaChap+ipaZhpKeqq1ap rK+wsbKztLW2t7i5uru8OxO9wMElvy0SwsfCxjQUFMjOvMzRzc/Ut9HV2Nna29zd3rEO3+Kc DuXj55ML5ujs7e4oCWQI7/T19vf4+XMD+v3+/wCvNAhIsKDBJAQOKlzIsKHDhxAjSpxIsaLF ixgzatzIsaPHjyBDihxJsqTJkyhT/6pcybKly5cwY8qcSbOmzY4Db+qcZGCnz59AgwpFxq/h vKG5eiJdyrSp06f+lI5bANVUzqpYs2rdypVrga5gw4odS7as2bNo06pdy7at27dw48qdS7du kYR28zqKp7ev37+AAwseTNiEgMImDxCiirix48eQI0v2cdix1MmYM2vezPnJ5RyKO4seTbq0 6dORFKBezbq169ewY8um82D2Ir4qatvepHv10VK9d18KLnwS8eLIkytfzry58+fQdzOITr06 HbzWSePOzr279+/gw4sfT768+fPo06tfz769+/cutsOffwS70N/0l9rPz79/5v3+BSjggAQW aKB4RR2o4P+C4l3F4IMQRiihTaFpw9iEGP4EYIYcduihWBd+KKKI8o1o4onhVYjiiiy2GEyI MZVonWou1hihijbmqGMUMO4o14Y+BimkNzIOaeSRSCap5JIv0cjkk1BGyWGPUlZp5ZVYZqmS k2tNp+WXvEQA5gtiqpAgmGWOyUKa752p5ptwxinnnHTWaeedeOap554uecnnn4Cm5GegO+BH 6KGIJqrooow+52ajaTgIaSiVqVDppJhmqummnHZq3WeehioqK6COauqpqKaq6qqstqqXoa7G KuustNZq66245qrrrrz26uuvwAYrLKpUmlLssMgmq+xoXy3r7LPQCgUAnwBUO+1YHM2mZ+21 elYbbaClfivuuOSWa+656Kar7rrstuvuu/DGK29H2ZIF67z45hvEvd5Jqu+/AAcs8MCT1kvw wXfgiPDCDDfs8MMeHpssvxBX3IfCFmes8RghAAAh+QQAAgAAACwAAAAAsQF1AQAF/2AgjmRp nmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP aBojzW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqIDouOj5CRkpOUlTcKlpmam5ydnp+g oaKjpKWmp6ipqqUDq66vsLGybQiztre4ubq7vL2+v8DBwsPExcbHyMnKy8zNziwUFM/ThNHU RWvXV9Y+BNrf4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+PmCmPr9/v+UagEcSLCgQRPeDipc mM4Aw4cQI0p0l22ixR38/gi4aEMgx48gzziUlDCkSScQTv9CTKmSIcuWB1/CNChzJsGaNgHi zIkrI5WdPPUBDUr0UcWiSJMqXcq0qdOnUKNKnUqVx4KqWLNq3cq1q9eoPr+2OyC2rNmzaFsU SMvW34QJbam9jTttLl1ndu82g6u3r9+/dBIAHky4sOHDiHVtTMy4sePHkCNLnky5srlGljOj Paq5s6GrnkOLHk26tOnTqFOrXs26tevXm8jCnk27tu2HnG/r3s27t28iHn8LH068uPHjyJMr X868ufPn0KNLn069unXKra5rt4R5u/fv4MOLH0++/EXZ5tMDya5+EPv2TBbDn09/l+D6+PPr 38+/v+O1/gUo4IAEXgNggQgmqOD/ggw26OCDEEYY1IED5ibhhRhmGEdYGh5hYRygdSjiiCSW aOKJKKaoIjkPrEjEAy3e9qEkMboYRI02/gBjjjfy6OOPQOYR3GTyBQkVekYmqSRpHC7p5JNQ RimlTSFOaeWVWGap5Zb6dcfll2CGKSZkM45p5pk23ofmmmy26eabcO7WwJxzhklnnMKMhOee glTJ55+ABirooIQWauihiCaqH5KKNuroo5BGKumklFZq6aWYZqrpppAUyelfEaAZQaiflvqD l6amquqqrLbq6quwlqJmrLTWGtSQtuaq6wuz7urrrzegCuw97+0mLDoStJksmxIsu6az+VEI BrQ/4joDZLVmNqvssNx26+234IYr7hx+jmvuuejeoGe67LYrRJPu2mFtvPTWa++9+NYnbb5b lcvvvwDn4m8Zxbq4b8DJHYzwwkoBAECbDkP8MMMU3+NpxRhnrDEV8yZy8cYghyzyyCRDEQIA Ow== ------=_NextPart_000_0011_01C6F6AF.B983F360-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:44:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc127-0008H5-Mq for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:07 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0wJ-0006Zk-Dq for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:38:16 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id E7240430F0F for ; Mon, 23 Oct 2006 07:38:03 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 61E604A43C6 for ; Mon, 23 Oct 2006 07:28:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4B9B2430EA0 for ; Mon, 23 Oct 2006 07:28:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 7D7FD430E93 for ; Mon, 23 Oct 2006 07:28:53 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 07:28:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESqlg002728; Mon, 23 Oct 2006 07:28:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9NEShOb022171; Mon, 23 Oct 2006 07:28:52 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:40 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Handling of failed requests Thread-Index: AcbzVYYBV+XCd5DaRsG7zn0IGfi2uwDAmxXg From: "Pat Calhoun (pacalhou)" To: "Peter Nilsson J (LI/EAB)" , X-OriginalArrivalTime: 23 Oct 2006 14:28:40.0493 (UTC) FILETIME=[890195D0:01C6F6AF] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] Handling of failed requests X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2003547161==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This is a multi-part message in MIME format. --===============2003547161== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F6AF.88E046BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F6AF.88E046BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well... it depends on what fails. Some configuration parameters are crucial on the WTP, while others could be considered less necessary. I believe there is already an issue open to track this problem set, but I do not have network access at this time, and therefore cannot look. However, one proposal here would be to mark each message elements importance (mandatory, optional), and any mandatory message elements that causes the failure would be considered castatrophic. The WTP could interpret any failures on an optional message element is sufficient to allow it to provide service. The actual failure would be communicated to the AC, which would then make a determination on whether it wants the WTP to provide service. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Peter Nilsson J (LI/EAB) [mailto:peter.j.nilsson@ericsson.com]=20 Sent: Thursday, October 19, 2006 1:07 AM To: Capwap@frascone.com Subject: [Capwap] Handling of failed requests =09 =09 Hi,=20 The CAPWAP specification is not very clear on how to handle a failure indication in the Result Code message element in the response to certain request messages. Join Request and Reset Request I guess is OK.=20 But what shall be done in AC and WTP if Configuration Update Requests, WLAN Configuration Requests and Station Request fail? One drastic approach would be to as mentioned in the spec for Reset Response "to no longer provide service to the WTP in question". But this seems a litle bit to drastic if WLAN Configuration and Station Requests fails.=20 Peter Nilsson=20 ------_=_NextPart_001_01C6F6AF.88E046BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Handling of failed requests
Well... it depends on what fails. Some configuration parameters = are=20 crucial on the WTP, while others could be considered less necessary. I = believe=20 there is already an issue open to track this problem set, but I do not = have=20 network access at this time, and therefore cannot look. However, one = proposal=20 here would be to mark each message elements importance (mandatory, = optional),=20 and any mandatory message elements that causes the failure would be = considered=20 castatrophic. The WTP could interpret any failures on an optional = message=20 element is sufficient to allow it to provide service. The actual failure = would=20 be communicated to the AC, which would then make a determination on = whether it=20 wants the WTP to provide service.

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Peter Nilsson J (LI/EAB)=20 [mailto:peter.j.nilsson@ericsson.com]
Sent: Thursday, = October 19,=20 2006 1:07 AM
To: Capwap@frascone.com
Subject: = [Capwap]=20 Handling of failed requests

Hi,

The CAPWAP specification is not very = clear on how=20 to handle a failure indication in the Result Code message element in = the=20 response to certain request messages.

Join Request and Reset Request I guess = is=20 OK.
But what shall be done in = AC and WTP if=20 Configuration Update Requests, WLAN Configuration Requests and Station = Request=20 fail?

One drastic approach would be to as = mentioned in=20 the spec for Reset Response "to no longer provide service to the WTP = in=20 question".

But this seems a litle bit to drastic = if WLAN=20 Configuration and Station Requests fails.

Peter Nilsson =

------_=_NextPart_001_01C6F6AF.88E046BD-- --===============2003547161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2003547161==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:44:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12M-0000Nx-Tl for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:22 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0sP-00062K-2u for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:34:06 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 2F04D430EE4 for ; Mon, 23 Oct 2006 07:34:01 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 2CC5A4A45E5 for ; Mon, 23 Oct 2006 07:28:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AC75E430E7E for ; Mon, 23 Oct 2006 07:28:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 6B76C430E8C for ; Mon, 23 Oct 2006 07:28:53 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 07:28:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESqWW020737; Mon, 23 Oct 2006 07:28:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9NEShOZ022171; Mon, 23 Oct 2006 07:28:52 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:38 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP for 802.11r Thread-Index: AcbztLBVHKXEwMpyRvCjly9Su9m1xQCoMehA From: "Pat Calhoun (pacalhou)" To: "Charles Clancy" , "Behcet Sarikaya" X-OriginalArrivalTime: 23 Oct 2006 14:28:38.0634 (UTC) FILETIME=[87E5ECA0:01C6F6AF] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 I agree with Charles - but I do believe there is a single issue. In the case of local MAC, the IEEE 802.11 binding states that the WTP processes the Association Request and then forwards it to the AC. The AC can override the decision made by the WTP by sending a negative result Association Response. When 802.11r, the local MAC WTP will not have the cryptographic keys necessary to validate the Association Request, so it would *have* to defer to the AC. The question is whether this is acceptable as it does change the timing of the Association round trip. One alternative is to push the PMK-R1 keys to the WTP to allow the WTP to perform its own authentication of the management frame. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Thursday, October 19, 2006 12:27 PM > To: Behcet Sarikaya > Cc: capwap > Subject: Re: [Capwap] CAPWAP for 802.11r > > Behcet, > > > My proposal is to use the key distribution protocol of > 802.11r which > > securely transports the keys. > > Also no need for the context transfer which was what I had in mind. > > My point is that we don't need to distribute PMK-R1 keys > since all authenticator functionality will reside at the AC > regardless of the MAC splitting, so we therefore don't need a > new key distribution protocol at all. > > Here's how I envision an 11r handoff: > > STA WTP1 WTP2 AC > -------------------------------------------------- > > Initial authentication (as CAPWAP does now): > > <--- assoc -----> > <-------------- open authentication -------------> > <----------------- 1X/EAP authentication --------> > (derives PMK-R0, PMK-R1) > <--------------- four-way handshake -------------> > (derives PTK) > <---------- add mobile (PTK) ----- > > fast handoff: > > (AC and STA derive new PMK-R1') > <------- FT / reassoc (PMK Name, MIC, etc) ------> > (derives new PTK') > <- add mobile (PTK') > <---------- delete mobile -------- > > > > Can you spare your ideas why that would not work in CAPWAP? > > I'm not sure to what you're referring. Using the > yet-to-be-defined 11r key distribution protocol duplicates > the add-mobile CAPWAP architecture for distributing keying > material. Additionally, it violates the security restriction > that keys from the PMK-level in the keying hierarchy MUST > remain at the authenticator, which is the AC. > > > You're saying we only need the split MAC scenarios that I > have in the > > draft. > > I'm saying that CAPWAP can support 11r without any protocol > changes. The only changes I can envision being necessary are > perhaps capabilities flags indicating support for 11r, so ACs > and WTPs know that each other supports 11r. All the 11r > protocol processing would be implemented at the AC. The WTP > would just have to know about the additional 802.11 messages, > and know they should be forwarded to the AC. WTPs and ACs > would also have to support AES-CMAC, which is defined in 11r. > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:44:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12j-0001ZU-BK for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:45 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0pU-0005dK-Jl for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:31:06 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id D5A44430EEC for ; Mon, 23 Oct 2006 07:31:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id F411D4A43C6 for ; Mon, 23 Oct 2006 07:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D36BA430E9B for ; Mon, 23 Oct 2006 07:28:57 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 28851430E8A for ; Mon, 23 Oct 2006 07:28:52 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 07:28:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESqbb015657; Mon, 23 Oct 2006 07:28:52 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9NEShOX022171; Mon, 23 Oct 2006 07:28:51 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:37 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0klY4e+7UPnhTRf2FfrW+5OvmDgAo/i+sAEc+JbA= From: "Pat Calhoun (pacalhou)" To: "Hasan Raza" , "Scott G. Kelly" , X-OriginalArrivalTime: 23 Oct 2006 14:28:37.0853 (UTC) FILETIME=[876EC0D0:01C6F6AF] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 To start with, we have to answer few questions: 1. How capwap is protected against discovery packet attacks? Even if there is a port-based or mux-based soltuion for reliably identifying discovery and DTLS packets, an attacker can send a discovery packet to the AC, which may result in the tear down of the WTP session. This is because discovery packets are un-authenticated packets, and are sent in plain. AC needs to blindly believe on the discovery packets. 2. If an AC employs actions again discovery packet attacks by discarding discovery packets if WTP session did not timeout, then an attacker may prevent the WTP joining back to the AC after a WTP crash. Attacker can detect a sudden absence of echo request messages from WTP, and start replaying the WTP echo request messages which causes AC not to teardown the WTP session. And thus genuine discovery packets might be discarded by AC. May be I am wrong here if DTLS can detect duplicate packets and discard them automatically. To resolve the above issues, we can impose following rules on AC. For issue (1) above: RULE 1: (a) AC discards all discovery packets if an active WTP session exists for the WTP. (b) A discovery packet from WTP can be accepted by AC only when there does not exist any active session for that WTP. Whereas, if a discovery packet is received if an active WTP session exists at AC, then all such discovery packets are discarded without change or update of any of the AC states. I disagree with this approach, and disagree with any mechanisms that will create delays before a WTP can reconnect to its AC. The couple of previous posts included a method to quickly detect the WTP had failed - in a secure fashion. To resolve the second issue (if at all it exists): RULE 2: AC should discard all duplicate DTLS and CAPWAP packets without change or update of any of its states. Sort of a bogus attack, but one that I suppose is possible. I would once more resort to my proposal that if the WTP can re-establish a successful DTLS (using a new UDP source port), then the old control and data channels are deleted. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:44:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12o-0001fH-Iu for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:50 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0oM-0005UM-78 for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:30:17 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id AEF8D1448010 for ; Mon, 23 Oct 2006 07:29:50 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 329274A45F2 for ; Mon, 23 Oct 2006 07:29:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 162BE430E93 for ; Mon, 23 Oct 2006 07:29:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D02A7430E9D for ; Mon, 23 Oct 2006 07:28:54 -0700 (PDT) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 07:28:54 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESskY020952; Mon, 23 Oct 2006 07:28:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9NESYbH028880; Mon, 23 Oct 2006 07:28:45 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:34 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acbzx6gzRnIyqDJeSh2XVUA2VdetaQAIMftAAJk3VBA= From: "Pat Calhoun (pacalhou)" To: "Puneet Agarwal" , "Scott G. Kelly" , "Abhijit Choudhury" , "Dorothy Stanley" , "Michael Montemurro" X-OriginalArrivalTime: 23 Oct 2006 14:28:34.0681 (UTC) FILETIME=[858ABE90:01C6F6AF] Authentication-Results: sj-dkim-8.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 > Would having 3 UDP ports solve the problem: > (a) capwap-open control port : All unencrypted capwap control > packets go on this channel There is really only two CAPWAP packets that are in the clear - the Discovery packets. One alternative is to simply use the DTLS packet header, filled with zeroes. Yes, there is still some risk here because the DTLS header can change format, as stated by Scott. However, even so, we could agree on today's DTLS version for the unencrypted frames. A series of zeroes would imply an empty DTLS header, followed by the unencrypted CAPWAP control frame. > (b) capwap-open data port : All unencrypted capwap data > packets go on this channel > (b) capwap-secure port: All dtls encrypted capwap > data/control packets go on this channel. Demux for data vs > control happens after decryption. It's not completely obvious to me why the data plane packet format is not known apriori. The control channel will negotiate the use of crypto on the data channel, and all data plane packets received MUST be in the format negotiated. Assume for the moment a device negotiates crypto, but opts to send a plain text packet. Let's also assume that the packet had a way to signal it was in the clear (either through a bit, ot via a separate UDP port). Further, if the packet was supposed to be encrypted, as the bit or port indicates, but the packet is in the clear, then a CAPWAP device would have to attempt to decrypt the packet, which would fail and be dropped. So it seems to me like it is completely valid to simply have the endpoints (WTP, AC) remember the negotiated value (hell, you need to in order to transmit packets anyhow), and simply enforce the policy based on packets received. So it does seem to me like a dual port approach is completely possible. If there is concern about the empty DTLS header, then the three UDP port number is still an option. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:44:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12r-0001mO-Do for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:53 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0nm-0005Nc-O7 for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:29:36 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 6131E430E84 for ; Mon, 23 Oct 2006 07:29:04 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 66A6B4A43C6 for ; Mon, 23 Oct 2006 07:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3AB4A430E75 for ; Mon, 23 Oct 2006 07:28:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id EBA77430E70 for ; Mon, 23 Oct 2006 07:28:38 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Oct 2006 07:28:37 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESbJG007113; Mon, 23 Oct 2006 07:28:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NESain022479; Mon, 23 Oct 2006 07:28:36 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Oct 2006 07:28:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:36 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E2@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0go7ZRC/7OpgdRraJnWWCdkT5IQBz2heg From: "Pat Calhoun (pacalhou)" To: "Navin (NKA)" , "Scott G. Kelly" X-OriginalArrivalTime: 23 Oct 2006 14:28:36.0717 (UTC) FILETIME=[86C169D0:01C6F6AF] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d > [NKA] My point is that seperate discovery packet processing > via a special port is a bad idea. And it doesn't bring any > additional value than what can be achieved without special > port approach. Scott's additional reasoning that two port > approach would open up scope for DOS atack. I totally > disagree with the argument. I claim that the same risk exists > even with 3-port approach also. In my previous post, I suggested the use of the source UDP port number in the DTLS SA table. This is required to support both the control and data plane being encrypted. However, it can also be used to detect a failed/reset WTP, but ensuring that the Discovery Request is sent from a new source UDP port. This does impose a requirement for random UDP ports on the WTP, but this is not out of the question since the RADIUS protocol imposes this on "fat" APs. That said, it is important to note that the "old" DTLS SA MUST not be torn down, or dismissed in any way until a new DTLS SA can be established using the new UDP source port. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 10:45:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12n-0001Zt-3f for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:44:49 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0ou-0005Zl-4G for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:30:33 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id BDE39430E8C for ; Mon, 23 Oct 2006 07:30:21 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 050F64A43C6 for ; Mon, 23 Oct 2006 07:28:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2A6E39801B for ; Mon, 23 Oct 2006 07:28:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id DBB9A398046 for ; Mon, 23 Oct 2006 07:28:40 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2006 07:28:40 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESe5h024692 for ; Mon, 23 Oct 2006 07:28:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9NESdip022503 for ; Mon, 23 Oct 2006 07:28:40 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP Timer element issue Thread-Index: Acb0h8LbID2mUdDPSw2/a22E0D8uaABz0pbg From: "Pat Calhoun (pacalhou)" To: "Bob O'Hara (boohara)" , X-OriginalArrivalTime: 23 Oct 2006 14:28:39.0393 (UTC) FILETIME=[8859BD10:01C6F6AF] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] CAPWAP Timer element issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Bob, The names "Discovery Timer" and "Echo Timer" are not used in the CAPWAP specification. I will assume you mean the DiscoveryInterval and EchoInterval. I believe the issue you are raising is that the text is not descriptive on what to expect if the timer value is set to zero (0). This is a valid issue that does need to be addressed. I am OK with your proposal to simply disable the Echo mechanism when the timer value is set to zero. For DiscoveryInterval, I would propose we make the value illegal in the spec, and state that any illegal values MUST use the default value. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Bob O'Hara (boohara) > Sent: Friday, October 20, 2006 1:39 PM > To: capwap@frascone.com > Subject: [Capwap] CAPWAP Timer element issue > > In 4.4.12 of the -03 draft, the Discovery Timer and Echo > Timer fields are defined. The value of the field determines > the number of seconds between the two types of Request > packets. What does a value of zero mean in this field? > > For the Echo Timer, I would propose that a value of zero be > defined to mean that no Echo Request packets are sent. For > the Discovery Timer, I would propose that a value of zero be > reserved and, if received by a WTP, is interpreted to be the > same as if the value of 1 was received. > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 12:01:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2FI-0000Dg-Ty for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 12:01:48 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc2FE-0004ee-0q for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 12:01:48 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B3759431034 for ; Mon, 23 Oct 2006 09:01:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id A4B914A43C6 for ; Mon, 23 Oct 2006 09:00:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6A22A43101F for ; Mon, 23 Oct 2006 09:00:46 -0700 (PDT) Received: from mcfeely.cs.umd.edu (mcfeely.cs.umd.edu [128.8.128.218]) by hermes.tigertech.net (Postfix) with ESMTP id A43F7431020 for ; Mon, 23 Oct 2006 09:00:43 -0700 (PDT) Received: from mcfeely.cs.umd.edu (localhost [127.0.0.1]) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k9NG0dAg020242; Mon, 23 Oct 2006 12:00:39 -0400 Received: (from apache@localhost) by mcfeely.cs.umd.edu (8.12.11.20060308/8.12.11/Submit) id k9NG0dMA020239; Mon, 23 Oct 2006 12:00:39 -0400 X-Authentication-Warning: mcfeely.cs.umd.edu: apache set sender to clancy@cs.umd.edu using -f Received: from 63.239.69.1 (SquirrelMail authenticated user clancy) by webmail.cs.umd.edu with HTTP; Mon, 23 Oct 2006 12:00:38 -0400 (EDT) Message-ID: <52649.63.239.69.1.1161619238.squirrel@webmail.cs.umd.edu> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B184E4@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B184E4@xmb-sjc-235.amer.cisco.com> Date: Mon, 23 Oct 2006 12:00:38 -0400 (EDT) From: "Charles Clancy" To: "Pat Calhoun (pacalhou)" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Level: Cc: Behcet Sarikaya , capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Unless PMK-R1s are preemptively distributed to WTPs to which a STA might roam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for the WTP to request a PMK-R1 from the AC (R0KH). This would be about equal to the latency of having the AC validating Association Request packets. Does 11r let you proactively distribute PMK-R1s? I don't see any references in D3... all I see is the reactive distribution protocol. My understanding is that one of the reasons 11r is faster is because keys can be *reactively* transfered directly between APs without having to go through the AAA server. Unfortunately our main security association is with the AC, not the WTP, and inter-WTP communications is bad, so everything will have to go through the AC. -- t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote: > I agree with Charles - but I do believe there is a single issue. In the > case of local MAC, the IEEE 802.11 binding states that the WTP processes > the Association Request and then forwards it to the AC. The AC can > override the decision made by the WTP by sending a negative result > Association Response. > > When 802.11r, the local MAC WTP will not have the cryptographic keys > necessary to validate the Association Request, so it would *have* to > defer to the AC. The question is whether this is acceptable as it does > change the timing of the Association round trip. One alternative is to > push the PMK-R1 keys to the WTP to allow the WTP to perform its own > authentication of the management frame. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Charles Clancy [mailto:clancy@cs.umd.edu] >> Sent: Thursday, October 19, 2006 12:27 PM >> To: Behcet Sarikaya >> Cc: capwap >> Subject: Re: [Capwap] CAPWAP for 802.11r >> >> Behcet, >> >> > My proposal is to use the key distribution protocol of >> 802.11r which >> > securely transports the keys. >> > Also no need for the context transfer which was what I had in mind. >> >> My point is that we don't need to distribute PMK-R1 keys >> since all authenticator functionality will reside at the AC >> regardless of the MAC splitting, so we therefore don't need a >> new key distribution protocol at all. >> >> Here's how I envision an 11r handoff: >> >> STA WTP1 WTP2 AC >> -------------------------------------------------- >> >> Initial authentication (as CAPWAP does now): >> >> <--- assoc -----> >> <-------------- open authentication -------------> >> <----------------- 1X/EAP authentication --------> >> (derives PMK-R0, PMK-R1) >> <--------------- four-way handshake -------------> >> (derives PTK) >> <---------- add mobile (PTK) ----- >> >> fast handoff: >> >> (AC and STA derive new PMK-R1') >> <------- FT / reassoc (PMK Name, MIC, etc) ------> >> (derives new PTK') >> <- add mobile (PTK') >> <---------- delete mobile -------- >> >> >> > Can you spare your ideas why that would not work in CAPWAP? >> >> I'm not sure to what you're referring. Using the >> yet-to-be-defined 11r key distribution protocol duplicates >> the add-mobile CAPWAP architecture for distributing keying >> material. Additionally, it violates the security restriction >> that keys from the PMK-level in the keying hierarchy MUST >> remain at the authenticator, which is the AC. >> >> > You're saying we only need the split MAC scenarios that I >> have in the >> > draft. >> >> I'm saying that CAPWAP can support 11r without any protocol >> changes. The only changes I can envision being necessary are >> perhaps capabilities flags indicating support for 11r, so ACs >> and WTPs know that each other supports 11r. All the 11r >> protocol processing would be implemented at the AC. The WTP >> would just have to know about the additional 802.11 messages, >> and know they should be forwarded to the AC. WTPs and ACs >> would also have to support AES-CMAC, which is defined in 11r. >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From bostj@fahnestock.com Mon Oct 23 12:13:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc2Qh-0000uy-89 for capwap-archive@ietf.org; Mon, 23 Oct 2006 12:13:35 -0400 Received: from host138-82-dynamic.7-87-r.retail.telecomitalia.it ([87.7.82.138] helo=fahnestock.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc2Qb-0006cR-LC for capwap-archive@ietf.org; Mon, 23 Oct 2006 12:13:35 -0400 Message-ID: <000001c6f6bd$c3b8fc50$eac3a8c0@fgyzerl> Reply-To: "Dominga Mccausland" From: "Dominga Mccausland" To: capwap-archive@ietf.org Subject: Re: VlbAGRA Date: Mon, 23 Oct 2006 09:10:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6F683.175A2450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6F683.175A2450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, GREAT VlbAGRA http://www.pisadesinjionkadesun.com =20 What is it? Your last request, Neuredan said. That and a cigarette. ------=_NextPart_000_0001_01C6F683.175A2450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

GREAT VlbAGRA http://www.pisadesinjionkade= sun.com

 
What is it?
Your last request, Neuredan said. That and a = cigarette.
------=_NextPart_000_0001_01C6F683.175A2450-- From Ines@angrybeaton.com Mon Oct 23 13:44:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3qa-0007GT-Sk for capwap-archive@ietf.org; Mon, 23 Oct 2006 13:44:24 -0400 Received: from h87-249-194-66-static.nysa.3play.net.pl ([87.249.194.66] helo=solid-snake.nysa.3play.net.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gc3qK-0003Pm-Hp for capwap-archive@ietf.org; Mon, 23 Oct 2006 13:44:24 -0400 Message-ID: <001501c6f6db$9991fcb0$001023ac@solidsnake> From: Annmarie To: capwap-archive@ietf.org Subject: do the many Date: Mon, 23 Oct 2006 19:44:06 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0012_01C6F6DB.9991FCB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Antivirus: avast! (VPS 0643-1, 2006-10-23), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.1 (+++) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d ------=_NextPart_000_0012_01C6F6DB.9991FCB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C6F6DB.9991FCB0" ------=_NextPart_001_0013_01C6F6DB.9991FCB0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable That which does not kill you, makes you stronger. Blood is thicker than wat= er. No pain, no gain. Possible Interpretation: If something is good for one= person, it is good for everyone; Worrying is like sitting in a rocking cha= ir. It gives you something to do but it doesn't get you anywhere First come, first served. Hope for the best, expect the worst. This could a= lso be read as, A friend in need is a friend in debt. Variant for slow risers: The early worm gets eaten by the birds. Nature, ti= me, and patience are three great physicians. Fine words butter no parsnips.= Tomorrow is another day. Fine feathers make fine birds. Good eating deserves good drinking. Time is = of the essence. One fly makes a summer. Mark Twain Possible Interpretation:= Those that are helped are not the best. Keep no more cats than catch mice.= Never, Never... allow anyone to persuade you to suspend your common sense. = Don't bite the hand that feeds you. God is a living God. The more you know,= the less you need. Possible Interpretation: Everybody needs other people. People who live in g= lass houses have to answer the door. Good men are scarce. The English are a= nation of shopkeepers (attributed to Napoleon) It takes two to make a quar= rel. ------=_NextPart_001_0013_01C6F6DB.9991FCB0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
NEW YORK (Reuters) -- W= arren Buffett's Berkshire Hathaway Inc. said Monday it has amassed a 1.97 m= illion share stake in Johnson & Johnson, and appears to have sold shares of= clothing retailer Gap Inc.
Layoffs loom -- how safe are you?
Broadco= m to stay on Qualcomm's case
3D"#463D9936"
Ernesto blamed = for knocking out power to more than 400,000 NASHVILLE, Tennessee (Court TV)= -- The father of a Nashville attorney on trial for killing his wife claims= he reburied his murdered daughter-in-law and disposed of evidence relating= to her killing. KANDAHAR, AFGHANISTAN: 14 dead in Afghanistan crash Ernest= o blamed for knocking out power to more than 400,000 WASHINGTON (CNN) -- Pr= esident Bush declared Lebanon a front in the "global war on terrorism" Mond= ay, equating the Israeli battle against Lebanon's Hezbollah guerrillas to t= he U.S.-led wars in Afghanistan and Iraq.
NASHVILLE, Tennessee (Court = TV) -- The father of a Nashville attorney on trial for killing his wife cla= ims he reburied his murdered daughter-in-law and disposed of evidence relat= ing to her killing. Lockheed beats Boeing for moon launcher ding women in c= orporate America. WASHINGTON (AP) -- The thwarted terrorist airline plot in= Britain is sparking a bitter new round of finger-pointing in Connecticut's= bruising Senate race. NEW YORK (Reuters) -- Wall Street bonuses will rise = 15 percent this year, with larger increases for investment bankers and equi= ties traders as merger activity surges and stocks rise, according to a stud= y released Monday. Latest job growth numbers: 'Just right'
NEW YORK (CM) -- Soft drink = and snack company PepsiCo Inc. announced Monday that chief financial office= r Indra Nooyi will take over from Chairman and CEO Steve Reinemund this Oct= ober. She becomes the first woman to hold the post and enters the list of l= ea At least five deaths blamed on Ernesto Hedge fund may boost McDonald's s= take WASHINGTON (AP) -- The thwarted terrorist airline plot in Britain is s= parking a bitter new round of finger-pointing in Connecticut's bruising Sen= ate race. Hedge fund may boost McDonald's stake EA scores touchdown with Ma= dden Hedge fund may boost McDonald's stake
COLOMBO, SRI LANKA: '100 Tig= ers dead' in sea battle FARGO, North Dakota (AP) -- Alfonso Rodriguez Jr. s= tabbed college student Dru Sjodin, slit her throat and left her to die, a f= ederal prosecutor told jurors Monday. ENGLAND: Top judge to rule on Diana d= eath Broadcom to stay on Qualcomm's case WASHINGTON (CNN) -- President Bush= declared Lebanon a front in the "global war on terrorism" Monday, equating= the Israeli battle against Lebanon's Hezbollah guerrillas to the U.S.-led = wars in Afghanistan and Iraq. At least five deaths blamed on Ernesto=
NEW YORK (Fortune) -- For th= e past decade, Honda has been out of step with most of its North American c= ompetitors - sometimes defiantly so. NASHVILLE, Tennessee (Court TV) -- The= father of a Nashville attorney on trial for killing his wife claims he reb= uried his murdered daughter-in-law and disposed of evidence relating to her= killing. NEW YORK (Reuters) -- Warren Buffett's Berkshire Hathaway Inc. sa= id Monday it has amassed a 1.97 million share stake in Johnson & Johnson, a= nd appears to have sold shares of clothing retailer Gap Inc. Latest job gro= wth numbers: 'Just right' COLOMBO, SRI LANKA: '100 Tigers dead' in sea batt= le More than 200 homes evacuated in Richmond, Virginia
Wealth gap between richest a= nd the average Joe grows 50% since the 1960s COLOMBO, SRI LANKA: '100 Tiger= s dead' in sea battle CHOWCHILLA, California (AP) -- Sara Jane Olson, the f= ormer Symbionese Liberation Army fugitive who became a Minnesota housewife = and is now serving prison time for trying to bomb police cars in the 1970s,= says she tries to hide her radical past from her fe WASHINGTON (AP) -- The= thwarted terrorist airline plot in Britain is sparking a bitter new round = of finger-pointing in Connecticut's bruising Senate race. Are you paid what= you're worth? Lions cut ties with former No. 2 pick Rogers
------=_NextPart_001_0013_01C6F6DB.9991FCB0-- ------=_NextPart_000_0012_01C6F6DB.9991FCB0 Content-Type: image/gif; name="ubxyrz_961.gif" Content-ID: <001501c6f6db$9991fcb0$001023ac@solidsnake> Content-Transfer-Encoding: base64 R0lGODlhVgGXAYQAABEOH////yL///8AAAAi/wAA/xH//0RE//8i//8R//8A//8z/6qq/wAA ZgCZADMzM2WmoI4i7jOZAOa/wFVHKKu1uFWfOP9ERP9mZu6ZAP//AP//Iv//Ef//M+7uAAB3 VSH5BAABAAAALAAAAABWAZcBAAX/YCCOZGmeaKqubOu+cCzPdG3feK7vfO//wODMISwaj8ik cslsOp/QqHRKrVqvWFEhy+16v+DpNkwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWG h4iJiouMjY6PkAENkZSVlpeYmZqbnJ2en6ChoqOki0SlqKmqeQerrq+wsbKztLW2t7i5uru8 vb6/wMHCw8R6AsXIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e6/Cu/w 8vP0vPH2u/iNp/lF+/5wAQxYayDBgwgTljmmsKHDhxBpLYhIsSILAxYzzkigsaPHQAM+ihxJ sqQ8ACY9/6FM2WklS00uX2aKKdMSzZqVbuJcMWmnz59AgwodSrSo0aNIkypdyrSp06dQo9Zh ILVqCapWs2rdyrWr169gw4odS7as2bNoWfZDEjKt27dw436KIFcN3bpn7uI1o3dvmL5+wQAO 3GUw4cNpGCJezFgk1saQI0ueTLmy5cuYM2vezLmz58+gQ4seTbq06dOoU6tezbq15bauY8ue Tbu25Va2c+vezbu379/AgwsfTtw0guLIkytfzrwTgebQo0ufTr26dU5rr2vfzr374THew0Oa GI0Cc/PKKaBPvp49a/I32osnpni+/fv48+vfz7+///8AyvJYNQMGaOCBCCao4P+CDDbo4IMQ BtKTWBNGaOGFGHpxnHjZZejhhyCGKKIgsKlQ4oi+TACdisyx2OKKvnGE4ow01mjjHRIwl6OO PPao3I7LAYnHc1kJmZyRxSGZ5I1MNunkkyJ2COWUVEKxYZWEVYjlllx26eWXYIY5xYlqXCnm mWimyYyUarbp5pssaQnnnHTWaeedeOap55589unnn5bUB+g5ZA5q6KGIJqrooow26ihjD0AX KXOTLleppc1dmpymm2b66KfkCNoHm6AiBp4Mp5aq6qpNpMrqq5UUCisVuM1q66245nqdjLp+ KCtaELBRoFnBMlessdAdexaRayibnLPPJtvrtCj+Su0otdim4uoZvGbr7bcXigruuDqY2aC4 WaD7JrPkthtKre7Gmwt88poWAgAh+QQAOKUAACwAAAAAVgGXAQAF/2AgjmRpnmiqrmzrvnAs z3Rt33iu73zv45yfcEgsGo9FBHLJbDqf0Kh0SkxQUYtrU6ntwoLesHhMLpvP6LR6zW673/C4 /Gad2+/4vH7P7/vXYH+Cg4SFJRCGiYqLjI2Oj5CRkpOUlZaXmJmam2OInJ+gOAqYBKGmp6ip qj+BAZ6rsLGWBrI6GrW4ubq7vL2+v5QbS6/AxcYnxMd5tLbKzs/QgnXRaREi1iMTEAUFFRMB 3ODc4+Ii4SPjBRHf5xAH3yTY2CLa3N7l6eHn5+bj6+Wu3pWQR6JeN3YFxKUDyE+hOoQi3MEb QTDbtoP48jFMiM4fxIATr4m0k0XKBAYBTv9m65ZSHcCX+zj2a2ktXIUCIVOiVEmP5QSX/IJy bBjuZ82EN3Oq5NmyAk2YMmOSKAoUKc4SS1H2dGoUaseZX7vavFpwp1ZZ+WRuyyn068uN4m46 naoxIlm3Xt9KtceS7kK7bKMKBgtWX7e+Hf+6uku4rd6hCfnOTUwOV0XCeIUqLid23GSKIzE3 FryZ6lF7Ji6/HU2ZaMLOqAeGXp3Xoeun6T6PnMdC2CbVMSMPLizT4T9u7ngH6AAcsvDMkP0+ FJc89ezgtaVSPl6guuwAvLE7hrsdofd4s2OlHbF25njtorlNSCqdX/uM0DE3FDef8XrA7g1H Xnw40deaWmQZlt//YyXIZ2A/m8HCwDcTFuSTgqzht98+xFRY4UpcYZiXghsO1SGFIf0U4nMZ klgcQycG8OFWLbE44nMlmnNiAjPKoho9F0Hw0Y340SXCgz+mFOSQjrnYIEdIpqckckwO56SR AUQJngkGCZlddCKCpaVy0XRAzZlopmnCNGq26eabcMZZi2/GlCRnIgKQdKchzOzp55+ABiqC nSVwIeihiCaq6KKMNlrCKI5GKumktSRD6aWYZtqHmZp2akqfhBBqAqeelmrIBBMMMACqAaja gaqwDtCqrLOSECsG36hKzwUT6YqqqqyOECuvtWKFwQC4BnDsN6nCg6yuuhb766ohRQst/6zJ FnRsttbSKkK3s8KaTbTKeotss/SsKiy2ubJrLLATpWousCmJe2u85EY7Lavg7tuuHeimikGx BIO7br0D+6ruwcsKbCutA1xAcLrMUqtuwKte+y/GAx9cq8IdU1xvu/96fC1WsMKDccXfViur w9aGPDLC6dIbbsUnO1yvzQpXnLC6ujaM7MRwoPuwx8WSm7SswC58sM0lWFvyuML+6vPIGtdq tAngGpxu1bNOvTTRzaprwMotpxo1xEyzXZDT4xqtarITHNv2t7SW7ezLcIf9MdwYyAyH0ngj PQAAsR4Nc8pr18trTrcWfnTh0JZ9N7wno9A13zLn2/a0DyceK/+tF0gcsbADH5tN4JBzrvXQ SJNQeqsSh820vK93PPvpf3NtMd+P05PTG93eLfnYIyA+N8kXCK7vBBfADTLRnmPdKroa4178 5NcuP/nfoJtsvMhGLwv78et6f+/3cc/ctOXhnjsz9sbb+7vw0TM7PA10OjEBAHsr2LzQRzjM uaxx4iObuXDGwN7hTm7eGhvhqNay10Vwc2+LlcoydkAEHgx6KeqbvBjXvd5lkIR8C6DCIkg0 OWBsfNXrXQEhdkChdY6GCqxYA+X1rxXOT2nNoh8K0ObDBCptYUYbYQfZVywM1I58Q0Mi0FJo QrC5j4ra45usbNjCN/hLgEYcn+S25iv/HrpMfaOjx7Z6lTcMSsuMBYHjBFcnP+RJrnvvM9wM fYfAraXEjGS8mxCB6LTMfbFfcmShqRSVp0XCAVKO9AObVtDISFrSDKAqhKUuyclOyqJ/f2iF J0e5A1DGoJKkTOUwVCkJSLJSURnIwCsFJctZooFUioilLQFVy13uqZe+hJMSdBnMOwGzmKuY JDKXycxFiaqZWKmABCRggXuIYJorwKYLtEkCbU7zm980ATevKYFsllOc5xynDSoAgWla8wzg vKYK5jPNak7Em+AMZwDUqc59grOaIxjnBKg5vHP6s59dkGY+JQAPhHbToCzoJz4Xis4SODSg EMUoOXOgUHDu/y8M4IQAOyugmyMtlKEbPWg+U6pRiy50LtwcqAVyIlKROiWeYxioBOaiDQl4 4qIsjWhG/enSFPBzqEWt6A5kCo92bhKkBnXqCXTKU6kS9aFJbSlWTWqBlDIVGT7dqhik+Rlt NNSgPfUSOSdgAYACaZpqlWhGL3pUi/j0ngatQFt1mtJppnUiehVSP9sZErUq6a4YZauQFHtW ts7Uroj1519dYdCwbpWdrigpWQsS17l6NqtavSo2v2oCzIo0tF6wAFJbqtNvntWjEQlpUGdL 15Oes7V+9SpFRZtPT7RWtUO9KG5RqlKffvOn+WyqbIsbVmkya6egTYFqVVDXh55Uqf9Zsqxf 3QkDoEqBmyu9ajudIk3kktey2cAndmdr3d2ON7vIje1500lfrmjzvQpd7yGgW15y3nSnfPXn eZMRYO7ydaDnzYl3WRre6mL0ui7NJ0zrqdqPnmDBUJguOfWp3r5WFq3s7LBY2YtaEXcYvPRl cIrZW9uWnnjFV01JiGHsza5qeMTS/TCHP4tjuR53MvWk51MvvFoqbHarJqbxbQEs4hIXuboo 9rCLlaxiExCWBJ2dspRjrE0EF/jDsR2opTB8ZC33mMc4TmyYt1nkKVCVHvkVL3+1O2fkoqrJ tH0yj/FLZ/lmd8VRpux8uUTQ2HqCz/HlrX/hu9Yvt7S80I3/7hC5K2M8O5jFq40pNdmcg0zq oKPfdGuXk7th18a2njB2slF5PNyz0mO3STYpXMcJBlDnNiWkVjRvYUtZVFcZ17dOMwpsTc0J RxfKqR5xmanbZirQ06efialT8erYeE0bunKVtKrfatiY7lWbFKAyPSwg2NXO+J2H7Tag6Vtt uwr2v1rVp7aHqNDTbnvbeEZthYWqqdzKFAkYZoFV582HgJvA025qJzhLKgSDq+DK6HS4G3Ca KYW69QgSv/DFI9zsOVA8GqLUg6GgSXJAhbzkKE+5yldeBFyy/OUwnwQqY05zZI58F0OuOaWU qXNVBOHmPQ96LHKeBp63wOWCArrQ/5fO9Dl0tem7eDrUHXFBWwkrfYn7VlutzvW1VX100Ipa 6ESXxq7H74Jl97rZWyV2s4vr6lxPO9zZvvZw+W5eqlJe+saO97eD/QRvx5u55DD4wbOdhYgf gdQT33a6O/7xjG/84x3PtLlTfgWGnxjiB/ituR+x85avPOgnf3nPS770kB/92iMPMbgrkg2F H73oQ1+Cp0de9XSvuuVJn/quz57xr9996zN/PGu1/fe4j73sT996t69e9c1nfgoUGf0w3KIF w1/+7RXZ1dvzvvfJB/zzO0/83KsA+Kgn/wJEj37Dsz711D/++cev+9d7v+7VJ97lo6973IvA AmDHesYXev9/xzV8l3n5xzZZJ3ygl4CHZ34iEATNN4HyB33iF3fzx4Bnp4B+J3fMV35ugHwc 2H/f533oR3u2okz9h3Z+V4Ga44KzR34POHn8B4Gut4C8d4IvqIH1d4Hf5382ODj7t3wo6HrS h4FFCIQkiIDh94M0qH1iV3kOOIRPmH7254IWyINIKHnB14VA2AY6SISm14S+l4T3B35BOINi uINWeIJMCH3VN4UlWIQmOIYNWAJmQoIa6IRF8Ew3EIbpJ3jjp3ZmeHpZeHWJJ3cFSIhkeIeQ 93lxt4DvpzkTFHi7Z3dY13cDKHySmC9T94mgGIqiOIqkaApGV4ppQHTRoIqdxIr/qCgJ1+cK qGhKk4BwsviKp+CKuCgJuriLkQABvegDsQgoruQMwahyfogKx+iLzBgHw3gDxdiM0jiN1FiN nOQA1lgD7OQADoBuPKANJcCN3GhYI8CNNKANDqBWEJCOVsaO2WCOASCO2PiKE9CNKeGOPgCP 5YiN9biMKSAkDgCOFRCQ9jgCA1mPk7GO/FiQlUCLOBeQ4TiP5jiOiECRR8KNc4GRDjBT8kgC 8DiR6ViR87iOajWQBamP8ViP7IGN+OgKLOkJJGWOA8lwfOCQvWCT+2gCH8mSEBmPPXmQ/eiT qLKRPhmR9yiS8CCTBIkIQMmOKGmSGcmTHimVsmiO67hX/7iIkiKwk0W5lfPokx3JlVopj16i jyA5lR15AiYpkl3plUVZlth4Wi1JiuuYE2L5lWb5lW5ZlGOpl215ljnJAgQZABbwkiRQmPEo kmnZlqU4k0dJmAFZj1TZljMZlHdplFOZkwfJjpXplHoJkAJJkE6hlAiZmXU5lyeQjDSHjunI LIVpkn+pl2u5l+bIVgzZlzmJjiU5jnsJJK0ZEe4IjyRplLppYdm4Bn5pBP7oAzhZc894nNBJ As0ZndRZBkpXnYmQnM+5B6pJKYupk8mpAvKolSkQjVjxVMXplSg5nuoZnjuAdJbQnYxQmuLp nvXJA+QZEfUIjvRZWvbYnzgwc/8155hcso6wiY4zVZePmZm++VgWiY6wmSUYCZaTmZJfSaAk cAsKiqF2kHPwqQnLiQNX+VhYFplW+Q0bWZoHiZmugKJdxY3w0JTY2JRsyZhQCZxYWRDuOKIW FqI0J5fJwJVZopCEiQgQIHWBeSREmpduOZ4VWgKzCaRQWpBSSp0gSZVWSZAzKprguZKSGZtN 6pf5WY4qmaTAaZf2OQQCGkynmQwyKpQ7GZ55+aX6eJCw2Zk1ipKgaaRL2ZWIeaaoOY3pyVnd WJuFOo8DuUn6iJCAqSSHepHuaJsR6ptekp5C6qjk6AcfWioKagNuFagtkKbY+QPjaJwuwJqZ Oqqquqr/lrSprPqqS0eWpmoS6OkJY9oCqMosPooC8kiixfSRuzoEY3qrMFCXlimqNPCRSOpL QnqjwLmbJ5mOGxmTDiqt1TSQJOqsGsmR4uio3AqY2lqo1TqVExGWIQmpUYmtuvqogemZXqmg QTkJrTCdbmCoTGmi9xqUTTmaEAmj8fii/dqvXUWjQlmPAKuf/9qVpFmaMGqwNjqtSSmRP2mi /DqUA2uiekmWtMmlK9pJskqhjaqwWCqxIhum5hqmBrmkJHuZjFkQemWPl8qygLmeC5mn2Ehu rrCsiHKKgjmj48qgG1uyfEmyQ4uZgHmaI1uyl8qrSRu0MpuxK0uym0mTiySc/xfrDZzZp/sq tDMrtd14rCgLp0m7tSx7pmBLmRRbsnZKs1uJCIU5lBKLrJ4CjyrKm5gaoxPKtU0Lj7NZspLK qPz4mnybt2XrqL8pqU9JuCQLoTRbqikhuIgKqrAqBp+6jJ06uWeQqzHguGgQrIviuZjbuaFr CKArJ9dJCRSQuiNAAavLuiKguq/ruifgurIbA6zLuqULA7X7uimwu0snu7BLuwEgvMJrArfr uy5Qu7qIvCXAvCTgvNDLArvrvL50u6vLu8ObvdlbvNrLu76burSrusErvhAAu7ELvMcbvuc7 vOO7vuC7ve87veJrvuP7vuvLvucLvvY7S8VrvduLvf/de73N673YW7yIML0E/L/a678MnMAN fL21G8EOvMADTMH9C8CsdMHE6736C8EV/MAGHMAW7MDxS8LiO8Hs67+tW8AjLMLhe8IULMKp pMEo7MIq3MIXXL4uPMHci8PPy8MJPMAbrMAIHMAXLMOk9ML3u787LL/cS7+ucLzPS7/qm8IW rMTEa70dHMHBW8D9y8Xuy8JIzHTUm7yjiwZl3AJpPALy+Ym2mAau2pB6kLtnHBFeQMfsUcda gMeiyLNzrMeCwMe/cHKLJMi4sKY+8MaAvMizZMiM/MjWaJ5r4MeQPAZtfAVx7IuXXMmc3Mle cLpNsMn0CsiELAKSHAWOLAb/p1xMihyKAPDKyRMArzzLskwCAGDLs3zLspzLtYzLtBzLvqzL uSzMv5w8vLzLvzzMtrzMsXzLuiwCz1zMwAzNyCzNz1zLx0wFrQwL0UzN3tzL3wzO2FwC1yzO zTzN48zM4XzNzrzM5UzN3ezNzhzP8WzM5zzN7QzN7OxI5ZzP4LzP6OzP4WzO8IzOA/3OAS3O An3PvdzN+bzQ+yzM5izRFG0CCH0pCF3Pw8zOx6zM/ZzNAg3LxpzMGe3RHQ3S/7zL51zRKfDQ 1ezSEq3SlhTNsKzR6tzQBt3PFp3TMW3ROn3P9YzP+pzSFU3TAN3OOu3QuBxJSS3UCS3P5BzV 5JzN/+6sAgBd0FA91ckMzDA90cyM1FGt1FK9SPTs1OvM1WN90GFd1Td91emM0zf91iwt00H9 zwvt1Qo90yKd0med0CZNyx4t1SdN0nutz1vdzLzc1CutztJ81sqM19U80J4cnRtd2ZZ92Zid 2Zq92Zzd2Z792aDN2ZM92qRtBNtZ2qid2qpNCafNC6m82lTw2nci27CNB6tc27htApv8yKCc 22Ewyr7tJtsMBbQd3MZ93MjtBFSb3CjQAM7dACIA3SYg3dI9A3MB3c/t3NOt3TmA3dENA9UN 3tktBc99A9Td3CqQ3eHdAue9CNXt3dONA9c9Auv93fZt3gFQ3+w9A/rtBP/vbQPtHQP9vd/5 HQa33d30XeD5rd3ljd3lreAF7uDcnSUQXt/6/eDjHd3c/d/jLeHvDd/fneEL3t8WvuEK/uAj Tt8TjuIoft8hfuImft8dvuAl4OE1vt0B7t0zPuGEwOEVfuI/zuHwXd0V8N83fuQRnuA+/uLn veQ8DuJQfgIZLuQyHuRKfuUufuE5DuRNruFZ/uMqHuNJHuLtLeaDMOUazuAvvuZjHuBgTgIW juUwnuBMzuZRfuWIAOLoDedyrt5enuYMPuVxnuZv3uVDXuV9zueKPuaMvuWFsN5R3uV2DuQQ /uZ0vuh3bt8+LumNzudLngKQnuhS7uKVvuiknun/hk7pRj7pl17ln+7oPX7j1H3oTn7olb7q mG7lkz7rba7rT67rpX7qot7pr27pYL7qyE7nuJ7ppV7rx97qTlDKPhDqNO7gnV7tqp7rUr7i Yj7rH57kam7kai7qLG7qhH7r3P7h6h7mASBK5c7ul/7ty27pJS7vFc7saNLbQjDgzN0EIg51 u61KmdzvBF/wBi/e/A7qLhDeDG/r8Q0FDI/kez7xgD4Eg84CHt7wPI4EOh7sbIDrCx/yrO7m 5s4EDa/iK8Dv1O7xCF7yCk/qxm4EHZ/wK3DgRBDq4m7igs7pXE7m4Y7zLK7z557iQx/06I7y RN/xMC7hpu7tPr/uI27v//CO4bcO7ccu9ESf9Bge9KlO82WA84ke41Su6LQ+51Vf7N0O7JH+ 53Ue6ZL+6V9O5Zy+9jRO9kq+8hfv9q4e9nyv9G8A9pre4Mo+47J+5Q4f8XB/71u/4eo+7mff 5oLP9n6+8hFO+GUe+deu7HIe7zju7Y5f92of5DvO6G7A63R/7ZS/670e95tv7PPe7K0+86FP 8pSv59mO9tC+5Xn/8Ln/8LjP5m0vB+Lu5aav+cDf+6v/+Kq/99i+/L/e882f/LY//Gv+9nS/ 8TmOALsv8aG//MTe+nYQ+eMe7khP9byv6dGP+IPv5kbv9EWv52VO/M+u9XDe4uZ/+ag//VPP +/8Xv//wDgJBMwZiaTZnKpKoe8KxPNO1feO5vvO9/wODwiGxaDwik8ols+n8JZ7SKbVqvWKx hiy36/2Cw+IxuWw+o5/bNLOzVLDj8jk9Nmqt7KV8MHVvwdwZ+e3x8O386TRA3CTOEAYGJh4e RtoBGhoKPtZlFlaaDKpwFhJB9oDi5KXq2fCBwsqsIraGeua8knbijq4I/rLg9QZTjtZK+m4G l6IAO7LYNgMq1yavkmxSR6sIJ2/b+vm+YFsOl2YT73WXI59PY3bOnkLOg0OLG39Xypu/uIjz g9avnqyB9vBtw8SP3j5unwR6y/dwYrNzvfblehjwWxBGVBxZo3fQHEL/e8eYEZw2DKBBg6zU CXOXD54klP8k2tQ4k52/kCb/nJJ1jRxQdbt41mNJUWS0WSdHMgu1cKlJqi8TSizJ0WXPgjYJ NjWaVIUCp8VcjUx1NU2xFQBEBiQntVwsq1zvzY2ba2PdnfzKZo00NSLdlcbgmRWr2CLFwN6S Ioha5yxRQmYtM84pdGhOZUTxXg572ankZTCNmkbGeZyfKIV1OsTIUCpm1Og2X2O9+mgV13HW 8g4ufPiYZ8SPI0+ufDnz5p08Oo8ufXrwD9SvY89ewrr27sVVA2+izYdWnJeocUe79TR5Veu9 78r4hfSP8rxkpFfPir4i9+Hhc5GNZ0HJNtGA/7sdeFJt6DAylGVtabPPBwg9WJmCP3UjIEtB OREZgLeMJRBMFEJ0V1f0wUKiUrOJlhU61iWFT0yShVjRXJ8o9aEZk7RE40AgORiOgF4tQ9qG N6JYVULc1UgiTikB406U/uj4nV1RndUVKVleKNhON8noWGCBMAnVjWGBZqJWG1UpxmMkyfeV X2oq+dNOAlTlZCEAjHlCerMl5iNjcsl1Joc1wNFmFp/JFCd7r7yDYKSPqMSNfLklmSQME77T E1iW0hbqPNbIqaipp6KaqqqrstpqHBq4GusXeMpaq6234pqrrt1tsKuvvwIbrLDDUuEGscci m6yyxC6w7HEcOButtP/TUluttddi24lvzkJrBADfghuuuOOSW6654GbrBazpagcduzqsAWyv 79Jbr7334hvtBBA88EAFEwTQb8D9EjxwCQKfQPADEACMMAQUAHzwAwHs2y/DMVTsb8QB8Dux xAYbLDDCCGf8LwwEAzxBwQFUwO/FAz+QcsEKTzxyzTSDLHK/MuucbxEqV0DxwiATbfPJE6vM iMAVxHw0xzEnDQPQQnuk8s4f9xt0z1kbPAEFQUedMNdMCzw10w2PPbPHEmu9NsI53+wvy2r7 TAS/G3+cN9xOh+yv3E5fLcPdMjBdONZDb434xIPPYHHQLQvMb8JKL/x4x0QPTLnYm/cNgeX/ kbtba+hkvM150ThvHrXCQTvN9Nd4Y34CBRQETHvf/yaO+801ZF0z2acPzHTAv+OctdWmG937 8EuzXncQNu+ut9FiW4z2w6GTXAEFf+dd8AQABD24zhMQfzP5PcN8NNAxo9/3+seXvvPv0ns8 vt/HV9C88z+cfTjy9a8tdvJrmun0NreILY1mbTPY5Xp2ubPBIX5xY6DbNEc3CT7NbRr0H932 N4SpRaB9b0te9Dg3tM3dLWwlmBr8WKe63ZXPYL9jIQYNVza59S+BC6zhCNd2tqnpsG9MSFS2 Soa2/3EwgCDr38cy9rITGNFwSZwiyIzYOrmRzGUInJgN44a+HkKR/2wmC2L7gkBE3sTLg2pc Ixvb6MY3wjGOcswBrWK1rjni0VpWLB7qTgC5l03vcAo7Wr8gBjOdreyPW6zeIQOISLo5EW80 85gi/ajFGJTuBJeT2CD5mEcoyu2FMsik0B7XNK5h0IDdo10qV4jDU9ZPc6Pc4MdSeEK+lfKA uWSiKoUWOPrhcn/dsgHjCthLyR2McrIEJibrt8ACIjNgsiwjEkuQv4HBDpfRHNo23UXKwnEP eJocnRxJ2UdzbtB4rUSnxTj5yBL27IUry9sCvvmA1zVug1EQoSOVGIDZ1Q6XOLvmJ+FWQmMC b4D9ROgNl4k5MCrsYqQUJ8a0F05mCtGAmf+cWjHB6Ef94ZGJ1Izd0yZHwYX2koTB7KYMDTlR j9IAnZqsYEmTGcy5ra6aBcVYKEdKSrPBEqcC9efIHFo6oB6RY6z0J0VnOgEVmg6puySgKv+m QpiSdI57HGQvKXbJvemUegtDWweh+FWS+Y2rGDUrI5spta96dazNXB33YOrJnS7hjnhFQ7P2 6te/AtY7acRVX3dKzsAiNrGKDcMmD8m6nGKsY2P04hf7ydVKgpJ1/cMsCdvqTgh4YKYa5Jpo xfpEa54VgITkGSVTq0rMskyyZJ2nACp2MdsmNVdWIyAZuRhOGi7TozJ1pSnxJrzhTTWpX/Rm LF0ZuCD6krfNzaz/LlFpWVPesLjBw5xUgYvQ7UlzbgGdqKzA+djmFhUGxcRoIE3H0pPlz2Ms VelDVTs3Kab3vn9r73wVdzTPxTZyNG1n6Vi6XoRGlZuHjRVA79m96LVSp5OcZVhjC+CEqrah Tgtbg203vQ438ZYY1t3RhJfWER8PieQlrxQDyjKQ1oqjQc1oKssqXKLSkqQeFUBlD3naiMos fDPO7tNm++N0xmx+EnsfP7GpZAzHlKkqs13CHgfj8iowZ9N0l0jhScvh1jS8bi1Bf/2nPUly 0ZBkI9gzh7Zm67LMkDM1qYAXSrcyNzbM3KTqTalGYV3Byqr+7eJ9pdZTL5sQx9TlZYK1//tD LMqXyiB7GHL9TEYX+lephtZuAhdKaKl2etO6NNxV/UlQMrPvmbiqa9y+xklXR9Z4FG2vAXGb z7fKlWJiTOrU8jZlVsPM1S1G35RxDUj7fozQcT22Km29QtkylM1xnexiq23ta2NbDNvKNre7 7W0fDPMK4f42uctt7nNnZ8HoDk4dl3PGahlr3fBRNxs8JO9741ta9s43v73T7n4D3Nq9infA C25wHMzr4Ap33mA7UdiFA2jcsopACShu1gIUwGQYDwDGO14Ajn8c5DDweAQAtnGOHQB2Frf4 szGu8Y97fOMnP3kJSG7ykEMg5SWg1crf6vKbg9zjIh96ADZg8/+h51zlFfd5xoEec5iHnOZB L0DJka5zGPR8WBNgAMW4vsKMU4zqRKf5zENe849PQOwbr0ABYLf1rkMR7Gmn+MahRfaom13k cxc5293O9bd/HWxqN/vdzz5ytA+eZW3H2N+9HnbB053wkjf8CTa+97UvXmqNH9bTNZn5yk+e 8lIvO8jZDtLOk/nzlB873g9veJeD/fBCTz3sCi/6vJMe9qePuedrH/qhj771uo8B6oWV9dWD Pvlnn73hL99xGB+f6MpnPfP1PniXyyD6Ul/93atv+evHHutLn/70u99x1zsf+zGIfrC0j3eo l7/1oMd41TGec5afwP3LZ73yg0//m9//X/aN3+3BH/fJ3/JRHQAeAP6NH/6VXQHyn/Qdnf0t oAAGAAP+SvFBQObJ3O+RHvmBHPmongZyIATaXvARX9v1neydH+29ngceoPSF4ArOXwtyTAlG IPDhXt7N4AjynrAwAMAEodTIXQfG3wvK4My5yxAOYdwJngmGnhFunxLCABPiTdo9YQ7mHgSK 3hIK4RUWIRT2H/xNYdR5YQA0ofEN4MUVwMXYng6KXBla0+exn1fZH9AZIBLKoeJtTB3uyx1q ofBx4dDR4AWuYcu1IR5GoBTy4MkVYh0CwbtB3CR6Ab15myQmy79R4iYanCVyIrF4IrI83MGF 4hFs2ydiRym2Y8q+oSINqGIr7sorwqKuyOIs3kot6gguKsEoJpYuFkHD2WIwCuN0YOItDuMx ImMycpsmIkExKuMJMCOrSNwzdlvCUeM1YuNxEFw2AtwpcuM3gmO1WOO6sWI4muM5omM6MkEI AAAh+QQABQAAACwAAAAAVgGXAQAF/2AgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/I pHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4nCHP7/v/gIGCg4SF hoeIiYqLjI2Oj5CRkpOUlZaXmJmaLwibnp+goaKjpKWmp6ipqqusra6vsE8DsVAJtLe4RHtN BLm+pba/wsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx 8vP09fb3+IIM+fz9/v8AAwocSPDFrIIIE1Y5oLChw4cQI0qcSLGixYsYM2rcyLGjR3oNPooc SZLirpIoU/+qXMkSzcGWMBbAnEmzpk1wL2+WCKazp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKMq zCm1qtVyMq9qFUIVaK+tYMOKLahgrNmzaNOqXcu2rdu3RQvAnUu3rt27eO99NcMzr9+/gAML HuymL+HDiBMrlgOhsePGi8GEJLk3suXLmDNr3sy5c47KnkOLHk1asIDSqFNHy6q6tWt5+17L no0GNO3buOc82M37Qe7fwIPfiy28+OBOxpMrX86cNOvmcw1Dn069uvXr2LMnI669u/fv4MOL H0++vPnz6NOrX8++vfv38OPLn08/L/f6+PPr388fD4X/FABHgQMEAlfgKif9I0Hufww26CAy AEQooWoSRvjgR/cxN9mFHHbo4YewTCCiiK6NOAGIKKao4oostujiizDeZRtAXcVo442NRBAB bTruyCNeyOEoZDkJDmnkkUgmqeSSTDbpZD6nPSllhzP6EeSUWGap5ZZcHlZkl8pcCeaYZJZp 5pnwbPiOmGi2OVKNbsZ5EZty1mnnnXjmqeeeVpVViJp8BvoRQ4IWauihiCaq6KKMNupoKFHi 6Gcucj0qhHSUEHoLppZ26umnoIYq6qiklmrqqaimylKGqrbq6qvdcQrrrLTWCkal5rBq667+ aMrrr8DKp2uwxBZr7CkhAAAh+QQAAQAAACwAAAAAVgGXAQAF/2AgjmRpnmiqrmzrvnAsz3Rt 33iu73zv/4afcJgTEI/IpHLJbDqfuiB0Sq1ar9isdsvter/gsHhMLpvP6HQ6oW673/C4fE6v 23mDu37P7/v/gIGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6hZDams ra6vsLFCbLK1tre4ubq7vL2WtL7BmRNTDMLHIsTIy0/KzM9KztDTQ9LU1zzW2Ns42tzfMt7g 4y3i5Oco5ugBq+uawO7x8vP09fb3+Pn6+/z9cXn+AgocSHCQlIIqFiBcyLChw4cQI0qcSLGi xYstjGHcyLGjx48gQ4ocSbKkyZMoU/+qXMmyJbaDLmPKnEmzps2bOHNGUqCzp8+fV+ABHUq0 6BGhRpMqXcq0qdOnUF8BjEq1qtWrWLNq3WJkq9evYMOKHUu2rNmzaNOqXcu2rdu3cOPK5Vdg biukdvPq3csXEIS+YP4C9iJ4MJfChnFMxYE48ZXGjq1AjkxlMmUoli87yayZCefOoEOPwyu6 tOnTqFOfI626dTwCrmPLnk27tu3bYtrh3s27Bcy4GnEoXPtbNGuUsHsz7Kq8uXPNi59Ln069 uvXr2LNrt8Fzu/fvhZKDH0++vPnz6NOrXxl9vfv38OPLn0+/vv37+PPr38+/v///AAYo4ICz FZcLBe4hKJD/BG4gEIiCATG4DYT9SIgNhRVygyE/Fl6z4T4dUvNhPiGKSOCJKKYYQATqsdji i+m5iJ6MM6po44045kiQgTr26OOPQAYpZHoPrFckkUaqd+QywSG05HlPDinllFoNR+WVWGYp yHFadnmKg16ax9wmXIZp5plopqnmmmy26eabcMbZVl1y1mnnnXg+48B6e6rXp598BgqooHkW amhWZR6q6KKMNuroo5BGKumklFZq6aWYZhpIk5p26umnoDJEZ0Vghmrqqaiuw2OqrLbqKoHt vSoro6vOauutuOaqq6Gl7urrr8AGK6wm3a0p3rBZ1Yosq8oua0OzztIHgHrTplctNnrXmgdA tuVx2y214EYr7rjk4nRAueimq26qY1Z17rrwutZuvPTWa+9NVt6r7778YjdqvwuFAAA7 ------=_NextPart_000_0012_01C6F6DB.9991FCB0-- From ykpjydsjkzt@redengine.com Mon Oct 23 16:58:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6sb-0001mW-AU for capwap-archive@ietf.org; Mon, 23 Oct 2006 16:58:41 -0400 Received: from [63.245.23.253] (helo=[63.245.23.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6s5-0007op-VE for capwap-archive@ietf.org; Mon, 23 Oct 2006 16:58:41 -0400 Message-ID: <000901c6f6e6$d165ab90$fd17f53f@HILDA> From: "Troch NYCJust" To: capwap-archive@ietf.org Subject: Seenjudith hansen Minnesota lot. Date: Mon, 23 Oct 2006 15:04:24 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0005_01C6F6B4.86CB3B90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f ------=_NextPart_000_0005_01C6F6B4.86CB3B90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C6F6B4.86CB3B90" ------=_NextPart_001_0006_01C6F6B4.86CB3B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Known pseudonym a Atrios or Glenn Reynolds kos Alex Steffen ana Marie am = cox Wonkette Hugh Hewitt direction or adding reach old important Tsunami = Medecins Sans. Handy resource designing is serve along lesson supplies tests assessing = Passage of enjoyable read havent pleasure of meeting thing days sum. Jitsu a ten bjj la Clippers mlb Monkey bar Gymnasium vp Lifeline = Usafitness in Madison wi difference in truth teaches lives words of = stuff sound important. Figure Skating Freestyle Ladies of men or Gymnastics Halls is Fame = Handball Hang Gliding Hiking Ball Field Inline Horseshoe Jiujitsu Judo! Billiards Bobsleigh Body Building or Five pin Broomball Coaching Cross = Country Skiing. Staff am Frank Nunez Miami initiating in regiment Lyle w Honolulu hi = point advice Kbells Pavelizer a boring weight. Yone suprised guys Rkcsam = Twito Northfield Mnyou planrated contains exact a kbs living near or = correctly fear ignorance dispenses wisdom insisting in benchmarks in = achieved taken feels. Wiki goes Marlow c or Conference Orleans la Fickling David a killed tv = star Newsblog Bonnie sky a gets? Cemented a source Howard Dean Wesley Clark Meanwhile number experts = blogged making am indepth of. Benchmarks or achieved of taken feels concerned repetitive of rear ugly = head fills or? ------=_NextPart_001_0006_01C6F6B4.86CB3B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Known pseudonym a Atrios or Glenn = Reynolds kos Alex=20 Steffen ana Marie am cox Wonkette Hugh Hewitt direction or adding reach = old=20 important Tsunami Medecins Sans.
Handy resource designing is serve = along=20 lesson supplies tests assessing Passage of enjoyable read havent = pleasure of=20 meeting thing days sum.
Jitsu a ten bjj la Clippers mlb Monkey bar = Gymnasium=20 vp Lifeline Usafitness in Madison wi difference in truth teaches lives = words of=20 stuff sound important.
3D""
Figure Skating Freestyle Ladies of men = or=20 Gymnastics Halls is Fame Handball Hang Gliding Hiking Ball Field Inline=20 Horseshoe Jiujitsu Judo!
Billiards Bobsleigh Body Building or Five = pin=20 Broomball Coaching Cross Country Skiing.
Staff am Frank Nunez Miami=20 initiating in regiment Lyle w Honolulu hi point advice Kbells Pavelizer = a boring=20 weight. Yone suprised guys Rkcsam Twito Northfield Mnyou planrated = contains=20 exact a kbs living near or correctly fear ignorance dispenses wisdom = insisting=20 in benchmarks in achieved taken feels.
Wiki goes Marlow c or = Conference=20 Orleans la Fickling David a killed tv star Newsblog Bonnie sky a=20 gets?
Cemented a source Howard Dean Wesley Clark Meanwhile number = experts=20 blogged making am indepth of.
Benchmarks or achieved of taken feels = concerned=20 repetitive of rear ugly head fills or?
------=_NextPart_001_0006_01C6F6B4.86CB3B90-- ------=_NextPart_000_0005_01C6F6B4.86CB3B90 Content-Type: image/gif; name="San.gif" Content-Transfer-Encoding: base64 Content-ID: <000401c6f6e6$d16361a0$fd17f53f@HILDA> R0lGODlh6AEwAof2AAAHAH4AAACAAHGJAAAJdXYOjAB5jbu8yc7Qt7TN6UUbAFsfAHIfBp0YAMMU AOwSCQdFCCwxADRABFVIBY4zDZg5CcszANxICABYACtSDj1hAFJpAIlcAqtmALxiAtlmAACKBSVx BzGHA256CX98CqKJC8J+AOiCAACWABOVADyTDGuSAIWqBpmSCsCqAN6RBADHDBjHAD3EAWvDAIS7 AKe5AM2/Ct7KAAfWACPjA0LlBG7gA4jsAJnXAbHdAN3WAAAGOCILTUoAPWMJOnUAPpUNSMoAOOcA MgAmThgVPT0dR1gjOIsVR5cTTrYoSuMdSgBNNx5LPT9INFU5QXM9SKA1Ob86RNw3PgBgMyFVOkBt SFdpTnJYEpduS81rSOVuQQB0NiWEQT6AOGF/SIOGRpOOTMJ3StSJTQOXOh+VPEySNWmqPXSuOKSV SsSYM9iXNgC6OiC0PUnBP2a0Nn3FPqvJNr7GTeTOMgDZNx3jPTbkSVvkPnrSPJzdNrrhS+nhPQAJ iC0Hi0ELeVQAeXsEi5YJhbIEhd0AhwkneyQWczobg1EfgoklgJQliMIiiN8kcQBKiCw0gEdJfWdJ eXJEi6dAjs05dt9OgwBSeCVgfU5kclNueHhoeaVhishrf+pfdACAgSiBd0N1gG1xgnuOe5F9fMOF fdWHegqsgiCljT2ah1qajnybhZyph7SsfOaafQPBfR7CdD/CgFPKi463cqPDh7bNh+2xigDtdyzo dkPiclTujYDlfJbVicPZcdHphgAAzSsAvU4Av10AwHIMzKMAvMcFw9wLyQgotScixDkjv1QXs3Yq xJgetbQZyOIUsQA+sRkytzFNzm01zIM/s6dGxbwzzuhBxgBhxx1qxjJlv1VowYNnvJFkwMJuvOtq zgp2xB2KuEqAw1eNxnqOx6l6s7F+y9N2vACuxyyXtzygymyWy3+puKaVzsulvO6YtgvDvi6zxjW2 xlS4t4jKwa7Eyv/35aKSmo2OdfwAAAb/AP//AAAI//8A/wDz//f3+SH5BACJsBEALAAAAADoATAC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECMatCSxosWLGDNq3Mixo8ePICHaG0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q1evIcOK HUu2rNmzaNOqXcv24Ne3cOPKnUu3rt27ePPq3cu3r9+/gAMPbZsWAuHDiBMrXsy48UPBkCNLnky5 suXLmDNr3sy5s+fPoEOLHk26tOnTqFOrXs26tevXsGPLnk1bsuPbuHPr3s27d9nawIMLH068OGzf yJMrX868eVrjPTFBn77XufXr2LNr3869u/fv4MOL/8cNZLz58+jTq1/Pvj146vDjc34sv6r7+/gX 1t/PP7SA/wKMBOB/JAVYoD0AmjSggQYKqCCBCCb4oIQCUijhgBViuCBKC0IYoYcldYhgiB9C2GCI FmKY4YVSAdDfbCcGGKODNI6oIIkNnnigjTX2yCCJNM6oI49E3ghkj0gG6WORRP6445BMJgXAlC/K BqWOMi5ppINOntQlhzh6qeSWO5ZJ5pBYgmmjkGRyeeOVTE3pYpWkPQRnmGmeOSKUY6bEppFfJpmn mGYiyaeHfxa655tqniVnfpDqBlOOBKYJoqA48lmjikcuCmiBF244qJ5tilihmVl26mamKmrqE5V0 pv9mJ6N4tlnij5reCSqLn4qJpq1aqnoopbwqmuqBd0aq7LILWUrrjLYGqmiRv/ZKq7B+qkqtmtKO uiqyjTIrrnoxJbpmmTlimuS5herK45fHoqrSqNX2Wq+8Ta4b674o0Scqp0KaqK6hJlI4bYm7rrhi pZyqieKlC8cb78K7EovohjaOqzGz/DK1MXrRfJxQx0uJbHJ3JKes8lT0rexyXA1dcfJALxP1Qc08 zQzRBzz3fPPNJf3M80g+p1Q00UATbY/PQ5909NI9k5S00lNDHbXTVy9tktBBb/200l4PPXXVTDdt ddVbB5212mZ/jTTXUoddNNlnm41012VrHXfZaMf//TbadP/t995rP5304SPpPNPYaevNeONg2/0z S4B3rffekF8+ONB0S5454o9vrlLgYGPNueWDax26356jtLrqK3ne9+moG0176bg7bnnnrO8u+mot v05736lTffnkozutPO+1a3587pMjXjvoxeuefPWVI98846/rLr3yxWvv+vOzQx+79ebjvXza0pdf OtCKyyR85OezT379zcOu/vaQ327897ijXu70d70BZs9on9Nc5QhIvPkRz3gQxBr4xoc+5zFvf5ij 3wQBiJrgse1oh1ubAa0nNLctEIMRTJ/UssY8/9Xtd4B7YOpOqLawTZCAziPhAAOYt7z5TnVMW+EN /1EXQrv9LWoHxFvhWPi7+MVkfjm04Pr+hz/sSZF06eOg9sSnwPeNUIZdzFwNh8i9/N2OizO0XwGj Z7shrnBu/ENhCvXXQC/usDQeDN8OsRhBNhbQihdUoR0vyMXHBTGHLkygGDMYxxQuUIA3DOQGcdi7 /IEPiozMJAMp+D34zWxxcfQfDUWJxkWGrn2KJCIMx5jGwJHugVgsnx81WEYrKrCOepTh2ErpQjBW kI+iXKUG7/iaPJrvam57IwDFdki5KdOGR3xhJN84Q7KBsH9ItCQiRci2Z76PhdzMphApeMxm8rBu 4uveBsOJTSMykXXvfJ49nIgzp/iynsFpGT57cv/Pfa5EZ/r0p0Blg5aBGvSgCE2oQnsSgJI0lCQN DYBEJ2qSh44koha1h0UnulGHevSjEIUoRS9a0ZKCVKMnRSlHJWpSkob0pRdd6UYpmlGVrlSjHEUJ TWXqEpbCNKcuDSpKHepToBL1pjXFqFFjilSW+jSmOF1qVI0qVaY+1aopWSpVM+rUpiK1pDsFKVWV 8hCuerSmLX3oVdX6UbPC9KdvZWtKkxrSjp51JW4NakRPQte5DvWkaP2rUFuyVqHK1bB8RaxO/RrY xLaVq3slbEsFq1jBotWtmIUsZQFrUrVitq2Jc8xQI3vYxf41sip1LFtLC9fNonawfU1taxv7UtL/ 3nWylwWrY98K25ig9rUuXe1gg9tTxhYXtMKlLWcnS1ngNne3dR2tbE3bW+l2tLEPLShMhCtdlbz2 t64lLmujO1zgxlavlq0tS7hr1tzy9rnufe95JXtd1ZJ0vN1dr3Eli9z7bpa64d2vX5mb2uR6d8Dc nS6BifIY9lr1qjjtrH8lLFva5pW8vJXpYe062ptKeMMZTulUd5rT+T53u+K1b4WpW9W48pSnALau f2EM3fj21sZYDa9tlTpSw8JYrgkeaXbP4tvT5nexed2re8FrYRGbl7kgxrBypwve6pZXt1CG7n+j mlYFp3jCC8augPFK4aJuGbdapiuOsXxbMzc5/8T5VTKFkUKfp9qZzEae8W7trNwLg9nKwdVqnvE6 06NC2M/wTbOiUazntBY6xsOt7J8PDNoIezmrTs7ymm/b5gTXuMzR7euQG2PlPqtXpJI28YDRe2VO o5fDlG5tXLPsaknD+SWaTe+t57xlPzs3xuP99aJbzWpiHznYZ/Y1cVGta5LcptQennWup0prTFe0 x0wF9ol93OLYnveyNAWrVyGc7ffiGao53rVIPUvuWZ812rh1amJpTOBuS7XF1F43rO8Lb2WHm9kj dql2F0pwgQa04AjvzMATzvCVHbzhEL8JQEcW8YrjZOIIGQk/Ns4PjXO84xovScc5bhKS2+PjJ//5 OMlRXnKRs/zkG4e5yEny8pS7XOUpAbnNZ67zkHs85jCvedCBHvSf9/zlSG850U8+dJO7BOU9Z7rK dQ71md+86UunudOjPvKpl/zoWic62Gnuc6aXHeQYdwvYx051su987Ds/O8/dLneZux3uc2+5SkaO Eq6b/e55z7nVzc72uBNe6XiPekv8HvjB113vdDc8yBlf9q9bvfCRnzzd2z7PtBdE8X8PueYjD/jF D37tpB8930X/9NBX3uag97vs+74Sxo/e8a+XutL/jnfTQ571v/c56F0/fMWvPvOCb7vxhX/4x3Pe 85+n/dwpf/nWbz7wtge+7k2//L27/vXH1z7/7oOvesPnPvy653zua29+9H/f/akX/O4dX3zev5/5 t1f/86E/EKrHXPbdB3lCR39OZ3/Ex3yH538BSH0CmHJeN3s/h3Xkd3YmF4BkB4G3933s93U494AO uIGkF4Lo13ul537ll3/X53MfAxMQeIEHaH7rF3oZyHnZZ38jGHcMeHrtd4AtKH2lN3/jd4PKN34R GIRAKIIaCH7y13gyuIR8133HF4UpmISf8RA9uH0kqIH1N4U494IoeIMcmHXD13Q7eIXwF39aeH9H uH1sSIU+GH8WiIA7+Ibi14Q++IQ46H86WHf8RzOo94PqV30hWHk0eISFqHWEOIGD+IJoqH9M//h7 hyiHyFd3R5eFIKiEsdeAc/iGjkiEMjiDuDeG/7QxMtGBSXeBYgh0AziJddh1W/d/Lhd2YgiJS6iE p5eKK9eFsqiARndzCsh1YheLi1h7K4d4SFeMqbd0oih0BRiDlSiLiuh8w+gZD2dx1ugSfSgQ17iN MZGN3viN4BiO4jiO+DEF5OgQ3JiO6riO7HgX41AS5xiP8jgu4zCP9niPkVKP+LiP/Jge+tiPABmQ 3fGPAlmQBskcBFkQ7biQq/GOKnGQEBmRi5GQElmRFnmRGKkbQZCRhMGQHvmRIBmSZMWRJFmSJnmS KJmSKrmS3iGSLtlBLEkYmxCTNFmTNjmOL/+Zk3Vykzy5ksXBDjoZlEI5lHNRjXyRcTKBlERZE/24 lFiRDy0BlYAhlfUkJ3NiD3JCErCClS5ilSWxlVeJlWI5EmFZllp5lWDZlV6ZFPnQllTpliRBlfbg lm9Zl3FZl28ZlyUBl3IJlXSpl4D5l3Tpl215l4QJl3OJmIA5EooplXIJE435l4ypmHvJl42pl5Qp mXk5l8WRBqPYEGP5lVpJlmjZlaNJmmd5mqb5lWiZmqiJmmFpEkoJExn3mJzJmLi5mI5pl5MZmLlp m7uJmb4pnCexmcZpEraZm8rpmMoJmYt5m81ZnMg5nJupm7fZl523jzARm6FJlmJpmqs5lnP/Mp7i 6Z2xuZrkWZ7g2Z3eSRTAOZ3YKZx+eZ2/WZ/JyZz4uZfQyZn3OZz0qZ8oUZ24WZiSmZgDCqDWGZ31 OZ3yiaDLyZ8MWh8PwZ3n+Z0W2prlqZ6nKZoWmqHrqZZgGVoGMRMIsZvzqZ/xeaDzyZzXWZi9GaD2 uZ8n+psuupw12qI1SpnQ+Zgnmpf4yaMRKqDUSaAoCqQISpjS2ZQvQaEmgZ7mmZWkCSuluaEbKqVQ mp7hyZYoCp8O2qM06qIzOqMAapfYmaIPeqD+KZ0JSpw+ypdquqbJ+ZxiuqIOmphgup94qjJM2p5Y yp5maZbtyaHmKZp9uqfu6Z8seqYsOqf//5moaRqmzWmkO6qoKmGmxzmpZrqmMvqmPkqd1mmkmQof 9LGWXImho1mhpyqohtqhg0qoazkns/kSSFmgkUmgl7mlxAmhkUqkmJmZiFmgkzqgtmqZN4qnmRms bhqgxcqjv1qZw1qdh4mmcJqd+OiUVhGnlYGt0GGU1eEWSemttKGtkUGVSmqt5nqu6LpQ3CoUsSoY Pfmu2ridWdmaaVmqZRmigOGVpEqvW5mu2+oQTDqeU4qhBJsS7boVqOqhpwmvDNsQATuo69mqqcqh B8GdWrGqEdueDcuTMQGlgfqh9hqoEiuydSGwWaqWTeqvooqOVaqaEpulrCqb4NoVf0qo3f8Jqxtr kzRhqoXqsnyasnlBrz5rqiprHBPqsaFZoaRaqmcppSKqkHChrx7Lry6SszrbjpBQtFq7terKsoBx sLI6s0xptSnJtWZ7tmhbHEfrmkwrsiB6njx7Evoqt/0qtUhLrQRhE0iZsEA7lmRbtks6pUn7mqx6 rzbbtyRbsILaFK9qsVaatgQFsBfqpx16sj87sux5synLtxortt1YsZS7uQv7t47RDuKynZOrtBDL oelJspkLqKpppfh6FP0aukQLua0xoT+rurDJuki7qm6LuDErsyM6tsVbt036qk9LujzZp4OruYr7 sSjBubc7vH7rubTpreFJtBjKvPCasFP/66qz+7x0SyX7mpay67R4SzPGWxDn27riSSXeW5L8YbG4 a7Re+xdgi43aq7fzy7F4sb9O8b9WmxcC3BQEnLMGjL1QkcAba7d9S7XmO7fBe6roa7nwyMA5Ybhy G6VV68AVQQ8Z6biqOrFUmqFU2rp8G5sHXBMUDLciC8KKUQEruKTTK7pOurjWC6jwW8H2GxTb67o9 7JILcFC/28ER27iPW75XyqcTrLxScq97erf3ux9DnLqJK7qI67wj+8NFUbvA68VVDDxeC7OpmsMn 3MM83LJrvL7x+hMYfLsfLMM9eaVUzLN2a74pLL5NG8fLy749cb6xC6J/TMcWCR1iPMb//wqaAazB OJHID2nIHKnIlDzA+bvAxfu5mZwTklyTfdHCJwHKYdvJEimvFHq3syvF9RqlyfvErgzJQ1GacLvE lZy7ZRzBrHm4wouvcnzDkbzJowy1Hry4a0zKFTkTK3y51qu5Cvu6vuy6X+zMe5y5tdwaG6ASssvM 8Gu/bRy+TLu0sBvFu6y+sFzNsJHMIXvCKdzE3EvN5RzL1Tux7wwXe7AH5twTLQO+FUzN5Fu5bPzM 7CnKGQzMGRu85Cke9VzPxrwdd+zN0vvMNfux87qvOizQzgauSkyeU4uz5rEHCy0p1DHP92zLjNyt wMy/BO2/H22QI93SLv3SW7Gud2HRPv+x0iyZxmycx0Hcx4Lbtn1sr2/Lwo7sErIsxcNs0xEpE2D8 zzp8xTCszJwLzXA8rythxjCNR+hoxiAbuia8xZc7xCQ8uieNuvHc1UgNkaj7nU6bxHZMyx08tLzs ysQMxLLsy1R81aJxtKg8uVyNueu81nsc1sQrzC5MvR181geJzEjsz00Nze2swl09zUDhx4KN16OR zxDN00Ddzw/9sj9tle3sxv9gE0pswU9cyIiNke461C0h0hcdj72Q2hqx2mPdsTaBCgWxD7J9j5bd 29+62+MIBTHp28Rd3MYtccCd3OMRH11w3MUUkaeg3NI93dRd3dZ93fM4JdgtEs5N1LX/W8vbHd7J 0d18YQfkfd7ond5BIQrTId7u/d7w7XnqPd/0Xd/2fd/4HZTxrdxfsN/+jRxKoASLkd/WGOAGrgT2 cckEPhhpd+ABvhsLvlAGDhcyHeE64b0ycQgafgj2sOEcPhIf3uEdruElseEgbuImgeIiThIhPuIc 7uEf7uElzuI0fuI1vuIgPuMyjuM4HuI+/uMqLuMtPuQkDuMnseMufuRCruMkXuJNzuNA/uIzzuJL TuNGTuUtnuROHuVSzo2PkeU+nuM9fuRijhJhPuI3XuZjbuY3/uM6nuJvnuND3uZUDudpDuV2ruZ3 vuZ5PucxTud4zuOBPuV4nuU1fuZ8//7nM/7Rhu7ng37oKQHmIq7oaY7oZC7lZx7mkm7lnP7mXb7i c67njz7qgi7ojV7poK7nnz7pZL7nlr7qU07pcg7nks7oJ77qL77phK7iqp7qug7lT87pny7rp97p rO7pax7qpQ7jv17sJv7rZc7sWm7qhX7rLs7r0W7kSG7tvS7p2i7aDQsTji7shO7q5X7saF7uhk7t mI7lyo7qO+7t6L7tlq7mzd7qs37ufM7q9Y7r1W7u9l7q+c7utJ7nL6npkL7voq7rxG7w6y7vXa7s xT7wkc7vAX/xqK7ubC7m9R7tcY7oDT/m7+7xxm7nIA/o6x6UQh7kVh7sz47t3P7oLP9/6w8P6CSf 4igO7Ym+6zhf5Or+5CmP5DB/8/OO5VtO5D4P8IVO720e7NOu8xVX4RZ+ccw79SP931jfkVZvzlnf 9Wqx9WAf9h/p9WRvFmJ/9mjv5WW/9mzf9m7/9umR9mPMG6wA93Z/93hvzLaQ92Yv9/fL94Af+II/ +IR/EX7/94Xv3jPJEVQxA92dDYcf+f0BKchg3WGQwJKf+ZqPT1KvMonfHKWYi8EoesoodlW3i4gI jV1Ycyz3iq94fchIgcrIc6dvgLW/+QwOmpRXfraYgXZoeba4iEPYfMBP/JMXicUPhjbYcp8vHhaI h40Y/Gro+zkod7wviOGnedrvfdv/v3ur53fNvxwsGIFrx4CuP4NbJ/u9WITQWHTr33yzmICEN/vp l/7Q7/6iiPs7YYWNd/88CBD2BPITWJCgwYIG+S1MONDewYYOETokCBGiQoYPNU60WDHhxY4bP2r0 2NDjP5QpVa5k2dLlS5gxZc6kWdPmTZw5de7k2dPnT5QiS248aNGkxIsilSpNOjQiSIRFJU6kOFUq R6pMl5LkelQgULBhxY4lW9bsWbQ8By6syJZqW6gU2cKl65TuWrdzTboV+lAvVKN5R+KNK5dvX8IO 06YksdjxY8iRJaONWNnyZcyZNW/m3NnzZ9ChRY8mXdr0adSpVa9m3bpyTdexZc9O/z3Z9m3cuXU/ pt3b92/gwYUPJ17ceO/dyZUvZ97c+XPo0aVPp17d+nXs2bVv597d+3fw4cWPJ1/e/Hn06dWPUd/e /Xv48eXPp1/f/n38+fXv54/7+H8AAxRwQAILrCwAAxNUcEEGG3TwQQgzm2S0/iq08EIMM9RwQw47 9PBDEN+LcEQSSzTxRBRTVHFFFlt08UUYY5RxRhprtPFGHHPUcUcee/TxRyCDFHJIIos08kgkk1Ry SSabdFK2EKOUjwIpq7TySizlY9ClJ7ukLUv/FuTSSzJbA/M2gQAITc2E2PTMzTQbGnNBAOCE0E7O 8FxNTwLVxPNM2/y0B88666zMTv8+MUNUzpYKctPPQhsq1NA8JY1U0T0flZS0RTebdFDWBAXVsk9R K1UzQf8EFKw3KW0zs07f3LQzTTV1dM1ZRyU101tfTS1RX3sNNc5DW7PVU13LDK6mVINtk1I2P43U VWhBjfZZNeesVdhkrU0TWkNd1TXaayE1N85zwe2UXGcHrXbUZskFF912T7302mTxTdXcWB1V1195 +2V3XG8HXlUyYn2d9lZRvYX31WpjndPhY92dFl+Hu93WWn0Z7jhjhRMWeeNyy2UYXULfzVhUjB8u OGFEVSZ443whJpbll0E9GCjT4Gy4WXpdXvhbQisNOFeYe23Z4qNtpfnjlGWumd7/eE9GOVxMn37Z 561d7tbqpLXmlt+g471UWQe1/lnoh52OCFir+Yz12IZFntrrtfF2tu672VV5ba4vA1xpSN8unGJu bRZ28JGV3tRkvtGeDTZF731X2puJJhhmQyfe/G2kLW856s/vdZzjwDMHWN7Fk2Za86gxZt31YDuu 2N5/NX8dW5+pPZn1nSHbslHJjYQbteB9Kn75CI9nXkHKn5feweSfm/764at3bFjj9+T+SOexrzF1 kEFPHNWzSwv/1HYFT79Y9+XetVXysfX3/m8tBfZ9XJHW/9HwiS820UPV3gp4Pkx5D1l2+9r8GohA 2rWPgZVyF6zaFjTzJfB7/svf/1e0tz1aHY1o5NuXuKYmun7N7GwRs1gFXVg3p4nwdoSD3fvWFa7Z 4Q6DtbOgycpHOBPCC4cjxB/QpDbBpQkQONFjXL4mBTQnYg6DMZPdzFAWQY7973GOo+Ki6FavE4IN Z0G8G/x8eK5ZVYxtK2vb6BqoJ3x9kDktFFvj8mZHMe5KbUNTHR0zyDq3zU13VUwcDMPmMaxlcIKu G6PdCHk6H6Iub3yUYKnkuBhaTfFzNbsjJ/NYLLWB0XZ/vGDmBFlFNbrtdGys39dmyMWypbGQqmui FREHRggqUUB8FCEe2XdCdXVxdbvz4yBhZzhq4VBcsQNYMV25zMsFs5nMbGEUB//mQmwec2SJLFky J8lNZBpSl8uiiQL7B5oA9iadzeuT+kLjkilcklXDWacEFwigehYvn+OMEAEN5Dl+ok2emBQT8QJa vIHu5DP5TOE9FxmcfRooogel6GtoAsVhKvKBGrSbthA50TJGzoCZNCfvAkjNX7kPfw7ME/86k1Cd 0E+jGq1nQzXYSXSOlKPpBCn8OOjQjfZMpR08TU8rWhpmgQyO0VQmNlk4us4ZtI6WImJVfWlDhUmz XgCcFzF/6UghArJ+tUJhMwuGRqoJMa06rORTRWcPmOZkoebjJSv7mMXynVRvgrOlNbF2uyf2lYSa jCROR3i4qRqTsHm8HOgwilj/W7aSrIc8KlLLydLBkexmiaymrybGMpdqk41jGy0eNTm2ukqxtLjc XBIZ+9rTaoyWnAVc+ooW2zj2hxvcuakVNYs4Vb7qs14jrV0b97viLva4yxXnaMfauh1uUbnGDakp pytS2eL2VnHFianeGlachbV0Zj2gK/XXWtva7JeBKyvvBvnWGMpMYLnrnTfJ5lX5dja7qQViOBW7 u9BWdjP+LBBA+RqbiE60pvT8qYkSxd2yZG8lAUrwmsiYIJs6+DIQJouAT8RhDnvYRCA+mGp6emER czTFASVwLA8V4IcCR5A9U6N74RjjcDrvxp5N3iZgWtRF1tieEHWsd8uLxNGA/zTDKz7qKJU5Y7ei sYRO7aXlDEdUF6OOynRNayEHxk2thk6rTbOyl7zB5AFf1LqPjOwLwwY1xSkVyTtucxnZFkTTKa6J txUsdUVF4lVlsmpsLpVqUQlJ0cLQhpzloYtnl1HsThGciR3vtkKJ5hUP8ZZ2Tt2haVlKOXOZzr8N ry+zZl0/k3Kxl8b09WCjyk6Sjm5/m+03H/1f1IJTvKSNnL2MmcPz1Zeyho4ToLuTheW0ekRGVTaT Wtxs38AYrsZOKIEMDG0iUXsm2OZ2tyV6Thz7tEDMJvK45+ptFSW11y5d8oEL8llKtmqletaieS2M YhWn1L1H1mOQTWhf/9r7nf/a5hn/4NZulk6bJblcKABB6UD5nXPBxsrV8dYX5G1CV+MNTjPBffLY F+vrYodzc3g9mtUn626tvuUbyYZoaSwDk5Eil6GmX1jm4yYz51S77yo/xlzx0pZiwPP4S86Nct/G zY6RRF9h+4rczF4t6T53c3VHecFLn/HpnuT6p0stbEQnF+QqRDW6LbptzE79loAkr4GhOElZ2nVp hQ6jpJcJMdM1rc+2468BC83oQe91h3TPNdM9DWAPzoQJRb82ZXO2dlDnduFFriN7Vw3WOOtNyMHN cqqv7nhGhixmJY/gz1crW8vHdruMN6j6vqt3oQk93IQndnpR3khc5lm1+mX/3wrtl0PdbxbuGX1v yxH9Sjl/9YY0VzRazf7uywqo8TMlErmXxHq1DGj6KkeS9ZWE/ck/X/zjJ3/5zb8aynnfTts3sffd yVDhWFw27s9pRMD/k8d+9cDrlyq+qZ9wrtkfaZMV+BsyUom3hHs4WPE/RRJABqQgPbk/owshhJsf ngo3cLOz/3u/DDw6WemhA7pAoAKyoDo/QeO0XbsY8tq/ItK0Uis+XuO9IqsmsgI4urumxpIk4kO9 FRoafBu9kOkgnMM7yYI6tQKwtzNB0YgdyFK99fEdyLsm0GOav6IrF4QtzzO9JEysvHst10KyFSy9 GWyfyao6xmE6E3y27Got/8xrCVcQIx8sm1MKHeLqOlbbs3GBL9+htC6TuwCjoszLM/26K4G7o9pD NQnsCXejHZpZvfDTQlT7N7AxrTU0xL3DQsv7PMPqw6gjwyD8NOdStVnSrta5ug4hg+YQqr2hrzD0 KbbDOkeSmgAcxNcBu1oEovsCO/6Kr/pyulukwYCzvaDLHSIMxrqaJljCQCVcxiTjlATMEfpjRhMc wAOMRhSxxqNSQ2m0jEQkuG30jG6Uo+LAxiXUN1X8RnR0p0mEoD80I/phNHUkqVXaKS5Lx4PSRjp8 xjpEoApTxhG0oE+snGADx3C8iTr5EJkiJtOSFqzKwy/zm+IbtS4ERuHrOf9BJLkKYiulu7kUpMZp 9MgiSSonDCw8JK9GBK5PajS8usNLjC5Py0R605qCfIlJkaOpmsWbrDRkTLWKS0k8ZMl1+ajaeUU8 nEmVqMmByknkcsI+Ci/cOz2ddLyfxMKmfKOYvC6F60akBJSERL6hk72Ziy85ZDNGjCJIO8YelEX0 GixgBDZ/VDZyBBJ89EAYicvJMcrq8AHzKKoHLBGQhB4ImwRvtEfCxDS8PEzETEzFhLATgInCfEwF iYUaWUzKZDzIvEzMzEzN7JHK7EzP/EzQDE3RRMxfgA/ZyILNTE3VXE3WbE3XfE3YjE3ZnE3arE3b 1JHRzM1Luk3e7E3f/E3/4AxOGNFN6tgt4swO4UzOyTxO5mzOnEAG54xO4VFO6qxO67xO7MzO1TCK qniLjPiIjNCLvWAI8eyLvPhOIREE7XwS7uwKpMiK97SMpsAKxIDP9XxN2PCIkgAMr6DPp/jPqNCK kZBOAkUT/SSKuXCKpeiI+fQLu/CL/tyIAp1QnumMA72K7oTPpBDQDOWKwtjQ+8TPcrrQqSAK+9zQ BnXPq2jPhKBQ7+ADCbSKrGDQpyDPwwBPG/3OwAhP6HNRHzULFPlRIbWJEC1SIz1SZZlLJH0SeTIx jlvE+hsf4uhHgJw/jYnGB7TLMkk/dntSfZS2g9tAAwSyL0yuDfqhBNIx/wpiOOl6S7rMN8xoUnkE wCgVUxzT0nIswVZCsPpT0380mjF1xjVtNpE8L/CiI4fLmdvCHaFTQSO6NeejwX+Z1JLhSKu6OWH6 ymFbGEbtHfyqN0zNpp4rIrPsQhUcxO9KOraypPwAgLQgqV3cyABEw6pkSdL7oV7joauDHK8rLuRr wlLqxNV6SV1VPah8PM2DMz4zvivapE3sETw9MmF1ykQjo8MbPlQSRELstDtbs4p0VjEkxafcQl8V ylIMvjgDRHESG9PbuspLtCKJ1iqd1m4NxbjjyU3L1Y3j1l3tMjfaOaD7IpTkRHDduinMq4IdO3YN V4TVLl+sPii5rL9jvv81OsZSxUUimshhnFVApEitgzxJlURU1VZh1DtebFNITUuKNFZOHUpC6iZD ZSau4iqC4Q9X1Y1llFd55UybxVkl1NK/RKj+uNmxWFKj/cDMwADQUNKjZZFLItrJiJG4jLSD2llG yc0qfUZmQ7gyBSXbcriqmVOq1cC0occ0FcgO5EbdzFpxO9MwLcFneaNERdOs9VM3TRshC8gri1i8 3Ix+6AdMfUieE0IkJLkx89SR/dQturHAA61euio8QzqFhMHCVSHDhZy7W6/Yw9zJ3dwtU9Su+saY +FuUcDq+A6szjKWTJLRhEz1JbFx8pcItfLJGNVNbjcJmLZpXmt2qDML/fmUhRULMy/hbG4sbi21Z R/vFht1dcz2scu2akjQ1zMNKsWPDOiOb5/rVkkwldMXedQxa8wPcfNw06yVXUHPXcD3J8e3WsB1W 9RpF6g3YUpRVFExJO7Reqyu7p2tXzERL0Qq664XX/YpcsXQskTVCt8xf5ZNc5WNFqftFmnPIdB0p ki3Y5HUm4Ovapg0SBdtgGWHaqhXUyhJeDy5h3wBhE/4+ELPTsn0Rq12RDhbhgdsZCoTH49hTvaWq tI22BnlbL53TfVwgJeO29GNTiMrbedxbdmIQH6a4HBbieJxhCOMcndPhGJLDs5QuYCucBR5GUnVc IVw0i6yykfs9mh06/2S61DDuKrci3In93L+L21VdNMXlXmI0K1YNsajcMWp93Y301tzFIjgDLlp1 39ZltePzmLtSytRdycWlX9O911kEWNwtVvkttuA5uhrsWMdtPsvttO31shz0XpcEy1rtuzrURIfk 18KLrOOtwuQ9xE98xbrTwYY15GOdniI+2HrlVuryu0/yyj625LLT3Ul810Q2VqnUqReENeMyvO89 5OdF2Dm8ZJ3JZKQtYJP8PfupXF/NL2GuWNmDr1zDL1tzPqiRr3+jNW6uNWAy3wjmPOcy5XnevFTF YyNOzRdmMMLc5/7tSxbxZwESaIGKvhTW5Sw5aIU2EzUb1H1OlP3hYf8dIehxbL84TcoThFs+1drp LSmNHtS2vVs6/eg3fWIWBGk71avMABMgPjWSPtNKEukdJkEo9WgNzlMLRFpz1MeQZjKNjJhRfS8s tuK0VFehvsGiDjk4NqWkjlskdGNLzUWbO1w57sHz8qYaIuqMPEJEnefHSeoa3OpYayq6TdKGJl8j MlNFDuLovd9D40NInMqdI7WqW8pKriXNA9i2prdsCrWPnWTPoyGXfLPEe1pzRV6vxGAx7rMYzDLz tUrP9b2b7DtiOya6lmWq671iJsRigqp1HUvADmXiYlaaSahG5FULjjx3VErlgrnTSj3ci+TlqrPQ e7xhnt9ZhuyHJe3/NTrffh3D6G3m/QIb0+6vzt6kkDXLdj7UdpZsu5Yh34XXc75qSAI8y6ZfDEZd 4wbF14vZwWNFwArtqmJINFxWlam2JRlbml7NfGJpfQLoJIPvdKTohbaRP6hvvpUJARvSGFUQu+Vn jebvKUZpnYbpnj5poVJv/L4+g57p9a5pOBVh5xkPvRTw8chFwT5VU11nq1qvmUWvwZUyzAXCtI45 C4+rjA7W115riGZslI1lVXbkfkvCl15wnp0JuIPuvA622o3FHM/YsNs9WdOySw3NMijIFP9Yvr5l 1WbeQAK6/c3HsJ07G18eS5wmpqJi6v7Wbva1neQ5Wl5sGtfWKi9z/zM/czTHnhNfczafSXqYjmlo czmf8whLczu3PzrPcz3fcz7vcz9vvTsPdB7RAUEvdENvJ7n8c9EsFEVv9Oc4SEePdOVg9P449IoC X0s/UvnmEUkPR0rfkEwXn00PdWZcBGnsdAtZBMUkdRMx9W1EdViPdVm/D1avdVs/UhS+zlmv0Fvv dV/fYHAIdnCwB2EPdmIv9ogQ9oIY9mVPiGIfdmYXCGhH9mWPdmOPdmLP9mpXdm5X9mOHdmd3dmOX 9nHXdmkX93Ind2sP94Yod29Hd3PPdmqPd2ZH9mf/9mY/91+vDGyP93xv93x392T/d3m3DHcH92bv d3rXd22vd3b/9/91P3aCj3hzd3iCJ/eAH3iJP/eIx3aEB3h9X3eFD076NniNB/mH5/iGP3mP9/eE L/iWV/iWr/iQT/mVD3eEn3mVx3mbt3iLZ/ecX/iY5/eM3/nkHHXgqPdrf3eX7/egl/lt7/Z0h/mC f3mUb/h3/3l/1/qq/3ihB3idr3l813iH93qzV/eHZ3qX701Mrw2aGPqTv/iPn3qat3qyN/qqT/mf 9/meZ3ijT3e4t/ut93avL3qJD/yth/jEL2whhfTc8AyRJ3qW93uop/y1v/mzr3yxx/y+Z3it13mK /3y9v3mg5/nNX/y6D/vbRPr/sPd5H/mxX3iUj/l5X3xqf/1t/3b/pZ/2pe/93Lf8qG/3g+/9zJ/4 a8d5pr/95Fd8v99358f1Bl/SXf+J569+65fNXL/62Zz+ouWM2o/9ob9345d6wLd35N99mR9+9Id3 tFf34xd83tf9uUd3j6//ca/90Bf48d/7y98RKgAIewIHEixo8CDChAoXMmzo8CHEiAX/Uaxo8SK4 gRkFbrS3EVzHjCENdvR4sCTBkRo5skSocuTLlSZntqRpEqTMkjpt0gypUubJnjlTEm0pkuXFpEqX Mm3q9CnUqFKnUq1q9SrWrE8f7kR59GNBlDbF8gS6cyZZnkdZwgyLtujYm0bhyoUL9i1dt3dXnq0J dq/EwIIHEy5s//gw4sSKpXbVy9YtZI4g+0aePNkvzrxr63Jmm9ks0b811ZIc2vPz5dKjO+tM7dee 1tiyZ9Oubfs2btqNQ2v0qno18Nem6fq2LDlzcdKjNyPXTNK18cjAfz4GKvR17uzat3Pv7l32z5jW y1IeD3r4ePHmxffdPTf97+XSyduVf57n9/z69/Pvn5Sra8dZ51tYl1lGXX184RRdgQiSBd19HqXW FWrzKecZcgGm95mEHHbYnmIhijgiiSWaeCKKKaq4IostuvgijDHKOCONNdp4I4456rgjjw759yOQ QQo5JJFFGglkj0kquSSTTTr5JJRRSjllQVVQeSWWCh25JZddev/5JZhhijkmmWWaeSaaaaq5Jptt uvkmnLRxEyedddp5J5556rknn31KlSWggQo6KKEt+nkoookq6l2hjTr6KKSRSjoppZVa6uSimWq6 KaedevopqKGKOiqppa55Kaqpqrpqiaa6+iqsR7I6K6212norrrnqymqsvfr6K7DBCjssscUaeyyy ySq7LJe7OvsstFcyOy21o0Z7LbTlYLstt916e2u14Yqr6bflmnsuuumquy6K47r77qiwwDsvvV6y ey++6da7L7/9+vsvs/kKPDDBBRt8MMIJKwyjI/gC/DDEQy48McWORnwxxhlrvDHHHXv8Mcghw1ox ySWbfDLKKaswvDLLLbv8MswxyzwzzTXbfDPOLou8M88XDWpMzkELrWIHQxt9NNJJK7000007jXRA ADs= ------=_NextPart_000_0005_01C6F6B4.86CB3B90-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 17:08:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc72B-0004wc-9p for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 17:08:35 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0ue-0006Nd-4v for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 10:36:26 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 55D50430F48 for ; Mon, 23 Oct 2006 07:36:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 3301B4A45F0 for ; Mon, 23 Oct 2006 07:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ED788430E94 for ; Mon, 23 Oct 2006 07:29:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id D77EC430E99 for ; Mon, 23 Oct 2006 07:28:52 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 23 Oct 2006 07:28:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9NESpbX015641; Mon, 23 Oct 2006 07:28:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9NEShOV022171; Mon, 23 Oct 2006 07:28:51 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 07:28:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 07:28:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B184E1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVA From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , X-OriginalArrivalTime: 23 Oct 2006 14:28:35.0775 (UTC) FILETIME=[8631ACF0:01C6F6AF] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 > I've been re-thinking my position on this, given that the > working group is committed to a multiport approach. Certainly > there are multiple ways to solve this, and while I would > prefer a solution that didn't involve adding yet more ports, > we are where we are. > > That said, I think adding a 3rd port which is only used for > discovery operations solves part of the problem. In that > case, the control channel is always DTLS traffic, and we have > an unambiguous solution which requires no protocol hacks. True, and if we decide that hacks are not acceptable, then a third port is really the only way to solve this one. However, I'd like people to consider the zero filled DTLS header. Yes, it is "hack-ish", but I believe it to be completely workable. > > As for the data channel, it's a little more complex. If > hardware vendors must know a priori whether data is protected > or not, the only options are either two data ports or a type > header, and given the dramatic allergic reactions we've seen > to protocol layering beyond the udp header here, distinct > ports seem to be the only option on the table. However, if > hardware vendors support tuple-plumbing, we can do this with > one data port. > > Tuple-plumbing solves the problem by letting the application > tell the hardware when a session is protected or not, but you > have to look at the source port too. This is part of the > problem some of Pat's signalling is meant to solve. Once the > AC knows what characteristics a given tuple should have, this > can be plumbed into the hardare. I'm a big believer that the data plane must know apriori the CAPWAP data plane formats. Regardless, one must validate the packet to detect erroneous formats, so an implementation that guards itself against attacks, which folks should be implementing, will not view this as a deficit. > > This still leaves two problems: associating a NAT'd data > channel with the appropriate control channel, and the QoS > problem for the data channel. The channel association can be > solved by using the session ID, as has been noted numerous > times in past threads. One way this could be extended to > encompass multiple data channels would be to extend the > session ID field, and treat the high-order portion as the > session id, and the low-order portion as the channel id > (control channel has channel id 0, data channel with no QoS > has channel id 1, and so on). Just a thought. Right, and recall in my proposal that I had proposed two alternatives, one more complex than the other. The simpler approach was to simply include a session ID in the CAPWAP header, which was used to create the correlation between the control and data plane. > > Since there will be initial ambiguity when multiple WTPs are > behind a NAT, there are two options: > > 1) don't worry about it; let the WTP establish a DTLS session > without knowing which control channel it belongs to, and then > get the session binding out of the first protected data > packet (which may be an echo) to create the binding; if no > packets come within some preset interval, tear down the DTLS session. > > 2) do some inline signalling, as Pat suggested. This could be > via a capwap header with some special value, or it could be > the text STARTDTLS along with the session/channel id - whatever. The above alternative requires no inline signalling on the data plane, and only requires that the session ID be present in the header to help associate both planes. This does not, however, also address keeping the NAT table fresh. In my proposal, I had included an inline signalling scheme to keep the session alive, but I now realize there are much simpler methods of handling this. The WTP could simply send an 802.11 NULL data frame (either on behalf of a valid station, or some agreed upon MAC address defined in the CAPWAP standard). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Oct 23 17:51:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc7hc-0003uA-Pm for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 17:51:24 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc7hZ-0005hn-W7 for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 17:51:24 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1A7193980E1 for ; Mon, 23 Oct 2006 14:51:19 -0700 (PDT) Received: from g1-42.tigertech.net (hermes.tigertech.net [64.62.209.16]) by fry.tigertech.net (Postfix) with ESMTP id 4DA8E4A45C5 for ; Mon, 23 Oct 2006 14:50:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3CD4F1448021 for ; Mon, 23 Oct 2006 14:50:03 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by hermes.tigertech.net (Postfix) with ESMTP id 8871F1448039 for ; Mon, 23 Oct 2006 14:50:01 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so3181481nfb for ; Mon, 23 Oct 2006 14:50:00 -0700 (PDT) Received: by 10.82.126.19 with SMTP id y19mr1573276buc; Mon, 23 Oct 2006 14:49:59 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Mon, 23 Oct 2006 14:49:59 -0700 (PDT) Message-ID: <369e612f0610231449v7fc448bap7d2a36fb72a51f54@mail.gmail.com> Date: Tue, 24 Oct 2006 03:19:59 +0530 From: "Navin (NKA)" To: pcalhoun@cisco.com, "Scott G. Kelly" MIME-Version: 1.0 Content-Disposition: inline X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: [Capwap] Seperate Port Vs Common Port Approach Comparison... X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Pat, Scott, et all, Below, I have taken the liberty of comparing 'seperate port' apporach with 'Common Port' approach. To me it looks like, there is no additional advantage in going with 'seperate port' approach. 'Common port' approach's behaviour (during normal functioning as well as DoS attack) is nearly same as 'seperate port' approach. Please go through the comparison to know for yourself. Regards, Navin ------------------------------------------------------------------------------------------------------------------- What is a Seperate Port Apporach ? ANS: In this approach, seperate port (e.g. 0x2FBF) will be used for sending and receiving Capwap Discovery Control Plane packets. As all other control packets exchanged between AC and WTP are going to be DTLS secured, they will be sent to a different port (e.g. 0x2FC0). What is a Common Port Apporach ? ANS: Here, Capwap will use just one port (e.g. 0x2FBF) for sending and receiving Discovery as well as all other DTLS secured control plane pkts. Situation 1: A legitimate WTP just now got powered and once its up, it starts sending discovery packet to ACs. And once discovery is complete, DTLS session establishment between WTP and AC. Seperate Port Apporach: * AC will get the discovery packet on 0x2FBF port * it would do discovery reply. * WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FC0 port of AC. * When AC gets ClientHello on 0x2FC0 and finds out that no prior session information exists, it would continue with DTLS session establishment process. Common Port Apporach: * AC will get the discovery packet on 0x2FBF port * AC will try finding out if prior session information for the WTP exists or not. If not, it would do discovery reply. * WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FBF port of AC. * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session information exists (and FSM state is Discovery), it would continue with DTLS session establishment process. Situation 2a: A fully functional (in Capwap Run State) WTP gets rebooted accidently, and once it is up, it starts sending non-DTLS type Discovery packet again to an AC. Seperate Port Approach (Proactive implementation): * AC will get the discovery packet on 0x2FBF port * it would do discovery reply. * WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FC0 port of AC. * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session information exists (with FSM=Run), AC will assume that most likely WTP got rebooted and it would go ahead and reset (state=Discovery) WTP session information. Ultimately, AC would continue with DTLS session establishment by processing ClientHello message. Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. Common Port Apporach (Proactive implementation): * AC will get the discovery packet on 0x2FBF port * AC will try finding out if prior session information for the WTP exists or not. As it does (with FSM=RUN), AC will assume that most likely WTP got rebooted and it would go ahead and reset (state=Discovery) WTP session information. Ultimately, AC would do discovery reply. * WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FBF port of AC. * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session information exists (with FSM=Discovery), it would continue with DTLS session establishment process. Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. Situation 2b: A fully functional (in Capwap Run State) WTP gets rebooted accidently, and once it is up, it starts sending non-DTLS type Discovery packet again to an AC. Seperate Port Approach (Reactive implementation): * AC will get the discovery packet on 0x2FBF port * it would do discovery reply. * WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FC0 port of AC. * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session information exists (with FSM=Run), AC would simply discard the clientHello packet. And would wait for the keepalive timer to expire for the WTP session under consideration. Once the timer is expired, WTP session information will be deleted, bringing AC in sync with WTP. Ultimately AC will start processing clientHello packets to carry on with DTLS session establishment. Remark: WTP UP will be in close to keepalive timer value time. Common Port Apporach (Reactive implementation): * AC will get the discovery packet on 0x2FBF port * AC will try finding out if prior session information for the WTP exists or not. As it does (with FSM=RUN), AC will simply drop the incoming discovery pacekt and wait for the keepalive timer to expire for the WTP session under consideration. Once the timer is expired, AC's FSM will be in sync with WTP. From this point onwards, AC will start processing discovery packets followed by DTLS session establishment. Remark: WTP UP will be in close to keepalive timer value time Situation 3: There is one fully functional legitimate WTP providing WLAN services and is Capwap controlled by an AC. An illegal WTP somehow gets access to the WTP/AC's networks and can snoop packets from the wire. In such situation, it can snoop legitimate WTP's IP address and start sending discovery request to the AC on 0x2FBF. This is a sort of DoS attack situation. Seperate Port Approach (Proactive implementation): * AC will get the discovery packet on 0x2FBF port * it would do discovery reply. * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY. * Illegal WTP in turn would start the DTLS session establishement by sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session information exists (with FSM=Run), AC will assume that most likely WTP got rebooted and it would go ahead and reset (state=Discovery) WTP session information. Ultimately, AC would continue with DTLS session establishment by processing ClientHello message. But most likely the illegal WTP may not be having proper certificates etc, so its authentication will fail ultimately with AC. Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought down by an illegal WTP. Common Port Apporach (Proactive implementation): * AC will get the discovery packet on 0x2FBF port * AC will try finding out if prior session information for the WTP exists or not. As it does (with FSM=RUN), AC will assume that most likely WTP got rebooted and it would go ahead and reset (state=Discovery) WTP session information. Ultimately, AC would do discovery reply. * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY. * Illegal WTP in turn would start the DTLS session establishement by sending CliehtHello message to 0x2FBF port of AC. * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session information exists (with FSM=Discovery), it would continue with DTLS session establishment process. But most likely the illegal WTP may not be having proper certificates etc, so its authentication will fail ultimately with AC. Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought down by an illegal WTP. Situation 4: There is one fully functional legitimate WTP providing WLAN services and is Capwap controlled by an AC. An illegal WTP somehow gets access to the WTP/AC's networks and can snoop packets from the wire. In such situation, it can snoop legitimate WTP's IP address and start sending discovery request to the AC on 0x2FBF. This is a sort of DoS attack situation. Seperate Port Approach (Reactive implementation): * AC will get the discovery packet on 0x2FBF port * it would do discovery reply. * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY. * Illegal WTP in turn would start the DTLS session establishement by sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session information exists (with FSM=Run), AC will keep dropping the clientHello packet coming from duplicate (illegal) WTP. Assuming Capwap Keepalive messages continue to come to AC, legitimate WTP's session would remain intact. Remark: DoS attack was NOT SUCCESSFUL. Common Port Apporach (Reactive implementation): * AC will get the discovery packet on 0x2FBF port * AC will try finding out if prior session information for the WTP exists or not. As it does (with FSM=RUN), AC will simply drop the incoming discovery pacekt coming from duplicate (& illegal) WTP. Assuming Capwap Keepalive messages continue to come to AC, legitimate WTP's session would remain intact. Remark: DoS attack was NOT successful. Conclusion: Common Port approach behaves nearly same as Seperate port approach be it normal functioning or DoS attack situation. ------------------------------------------------------------------------------------------------------------------- _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From akstcexplosivemnsdgs@explosive.com Mon Oct 23 20:12:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc9u9-00058h-Hi for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 20:12:29 -0400 Received: from cpe-74-65-27-152.rochester.res.rr.com ([74.65.27.152] helo=Bobby14.rochester.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc9u4-0002jI-4C for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 20:12:29 -0400 Received: from 206.130.114.186 (HELO explosive.com) by lists.ietf.org with esmtp (460UDIN4GTQ 80L97) id Y7HVT3-Z6390I-4J for capwap-archive@lists.ietf.org; Tue, 24 Nov 2006 00:12:24 +0300 Date: Tue, 24 Nov 2006 00:12:24 +0300 From: "Sonja Wallace" X-Mailer: The Bat! (v3.5.30) Home X-Priority: 3 (Normal) Message-ID: <135673962.77505917025756@thebat.net> To: capwap-archive@lists.ietf.org Subject: Hi MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------915348DA8DAF299" X-Spam: Not detected X-Spam-Score: 4.7 (++++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 ------------915348DA8DAF299 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Bring back some romantic moments that u lost in past.Deliver the=20= ultimate weapon and youre sure to slide=20= in!http://Sonja.hertionkdesunkajin.com/colonel's family, that i am=20= strongly inclined to hope the best. could he expect that her friends=20= would"and what arts did he use to separate them?""i am not going to run=20= away, papa," said kitty fretfully. "if i should ever go to brighton, i=20= would"ten thousand pounds! heaven forbid! how is half such a sum to be=20= repaid?"Y>Y>Y>Y>Y>Y>Y> ------------915348DA8DAF299 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Dear
Bring back=20= some romantic moments that u lost in past.
Deliver=20= the ultimate weapon and youre sure to slide in!
http://Sonja.hertionkdesunk= ajin.com/

colonel's=20= family, that i am strongly inclined to hope the best. could he expect=20= that her friends would"and what arts did he use to separate=20= them?"
"i am not=20= going to run away, papa," said kitty fretfully. "if i should ever go to=20= brighton, i would"ten thousand pounds! heaven forbid! how is half such a=20= sum to be repaid?"
------------915348DA8DAF299-- From brjhxgrory@rasco-reininger.com Mon Oct 23 21:45:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBLp-000685-6x for capwap-archive@ietf.org; Mon, 23 Oct 2006 21:45:09 -0400 Received: from [201.240.73.101] (helo=client-201.240.73.101.speedy.net.pe) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBLh-0008SW-Qy for capwap-archive@ietf.org; Mon, 23 Oct 2006 21:45:09 -0400 Message-ID: <000701c6f70d$f8a9c930$6549f0c9@familia> From: "contrary" To: capwap-archive@ietf.org Subject: profiles Clinton. EDTAriadne Bob Date: Mon, 23 Oct 2006 20:44:40 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6F6E4.0FD3C130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f ------=_NextPart_000_0003_01C6F6E4.0FD3C130 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6F6E4.0FD3C130" ------=_NextPart_001_0004_01C6F6E4.0FD3C130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Occurring of working abroad claim relating Last Updated pm Whats = Contact Feedback Jobs Privacy Policy hr. Enter select Copyright of llc Ohrm us Department Commerce of Office = Human Resources Management Emergency Call. Blocked Corey a Springs column gtgtcorey or Journalist is Posted Links = Seeded Since Football Votes Sitenews Type a Event mdash tue a aug am = Edtoddnews of humor is vandalism Spring. Handle pressure or heh horrible doing Edtjeff a Szarka Brilliant = dangerous suitable Edtvas redirects. Satirical art impulse annoyed is sabotage seems problem encouraged in = pains finger legitimate concern forum painful lesson Edtjeremy Seago a = ignoring. Acceptable standards Edtderek a um no vandalized guessing bit instantly = a caught watching noname senators fanfare or. Text pdf error a listed = Natures disputes reviewed accused omissions am reviews excerpts. Moral story researcher hisher papers or nor source condensed web tons is = content. That funnier triple itd essay wrote happen did creative course works or = abuse edits undermine Lets of realistic! Marrow organ duty full of consists of than of States District Policy = provision permits designated accrued agency! ------=_NextPart_001_0004_01C6F6E4.0FD3C130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Occurring of working abroad claim = relating Last=20 Updated pm Whats Contact Feedback Jobs Privacy Policy hr.
Enter = select=20 Copyright of llc Ohrm us Department Commerce of Office Human Resources=20 Management Emergency Call.
Blocked Corey a Springs column gtgtcorey = or=20 Journalist is Posted Links Seeded Since Football Votes Sitenews Type a = Event=20 mdash tue a aug am Edtoddnews of humor is vandalism Spring.
3D""
Handle pressure or heh horrible doing = Edtjeff a=20 Szarka Brilliant dangerous suitable Edtvas redirects.
Satirical art = impulse=20 annoyed is sabotage seems problem encouraged in pains finger legitimate = concern=20 forum painful lesson Edtjeremy Seago a ignoring.
Acceptable standards = Edtderek a um no vandalized guessing bit instantly a caught watching = noname=20 senators fanfare or. Text pdf error a listed Natures disputes reviewed = accused=20 omissions am reviews excerpts.
Moral story researcher hisher papers = or nor=20 source condensed web tons is content.
That funnier triple itd essay = wrote=20 happen did creative course works or abuse edits undermine Lets of=20 realistic!
Marrow organ duty full of consists of than of States = District=20 Policy provision permits designated accrued = agency!
------=_NextPart_001_0004_01C6F6E4.0FD3C130-- ------=_NextPart_000_0003_01C6F6E4.0FD3C130 Content-Type: image/gif; name="regard.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6f70d$f8a9c930$6549f0c9@familia> R0lGODlh6AEIAof2AAAABYsIDgt8C3SHAAAAh4wMfACMfMTMwrPfwaXX/DctDlEuAHsmC58nBL0e AeIfBgZEACk2Azk5AGtFB4I4AKFJB7E3Ceg7AABdCRVqC01kDF5hAINhAJlgAMVqANlbAAB9ACl1 Bj5xAG51B4V+CKF9AM56ANeCAACeAB+WAEaaAG6eAHKsAJmcAMSqA9KWAwC4BRnAAEK+C2HMB4m9 AJi0AMC4DOLIDADlACLgCDTUAGnUAH3nAJLjAMjYAdbXAAAOQCoASE0CTWoAP38AMqIKTrMASdUA RwAoRS0qM0sRSGcoP34bRqMVTMYhTOUVRwRISik9PjUzOFc0PIFKTKoyTs4+Su1LNQdbMhdcRjli R1ZRPIFeAJVSOr9eQ91nQwBxNi2INT6LTVWDPYuCSpZ6PMNzPOqCSgSkNSGbNjyZTVmpN4GaQJuh Mc2gQdKuSwDAMinLNjHIO164P3rHPpK2Osi7N+G7RgnTPBnpNDzYS23VP4XnRJbrPcziO9TaOwAD eh4CjTsKf1UAcXwAfa4AjrIMeugGcwEqcyEfgkomjWsRgHkYc5orgsYeeNYVcwAzeypNd0E0dWVD g3VKha42is1DhNY3fQlaiCdjjDZlcWdScYNshaZRfLlejOlRdQF5gCWJd0F2g2t/gHGKiZWNg75z ceGHjQ6uhhOkiUedfFSggoSlcpiUe8Kpd+aSjgC6eyXGgUDDfVW+dIK/fJe1ebS3iebKcgXdihjX gjzRgmPrfXHYjZjVcs3hcufSdAAKzhsHuTcFtlkMxnsHs5UEu8EJzOgAzgEgvyonzEAttGwRyIMW vq0Syrkmte0uwwA+uhs4tDRIwms6zIRCuKc5xcM2vNI1ugBeuxRft0JmvGtfv4RSvZdjtL9VzeVZ xgB+wBmHu01yylR8uX2LspJ+xsaCvNd+wwKnzhqVvzyZumGsxHacxZGWu8OtuuSUvQCzthHEsUvO zGrHx43DypO2vPn//piZr4J8dP0JAAD/APb5AAAJ/fED8wD0+////yH5BABsrUEALAAAAADoAQgC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eL9kKKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp82PQIMKHUq0qNGjSJNahKN0o8+nUKNKnUq1qtWrWLNqNdm0q9evYMOK HUu2rNmzaNOqXcu2rditcEfWqhW3rt27ePPqxetW6Ny+gAMLHkyYoMzCiN/uXcy4seOciSN7fUy5 suXLISVrToq5s+fPM7eNfNimoIDTAgSiPj0wdet/qE2vVk3QdWvWsGPL1q2at+7ZuWevtl17uG3g u2MTTz2ctkHkzXsDJ765etg+1jcuh13bOXfvr18f/z/oenv38Oa/b6f+Hbzp9+HPwy/fnb35++Sz 69+fmH172vTFJyBz7qGn0HrPOWdfgvLBVyB1/gWIYIMAvhfhWdjxp2FhMl1Y338g/kegfwoe+OF8 DzIoYIMLUnjbgCAuCGGI34Fm44047nQcazPi5uJ6JHqHHIwt7oibcTEilN6KSPZGpIPiWRidazlW aeWVK/VoYZLJ0Rekh7f9xuCFLa4II5Q05hbmkWhypyWDWMYp55VvRimiigbmh2eIReZXZoHg/Umj hHvKuCWccyaqKFwUTViikHnK5+GSg0oaKJ8uMvmjngFuGql6G4Yq6kLgmNVcdHeKiSmTR/JmpnRG wv8KK49D7hlchKeeWJxvvPaq6qjABivssMQWa+yxyCar7LLWHcbss9AOtuhN0VZr7bXYZhvZB9p2 y2FMH4QrLrfcEkRuuAKNi5C66Zab7j/jomsQu/CKO5C77+Jbr73z8gtvQeeaCzC97w6MLr76xivv vvoCbK6/Dy9McLsB32uwugkzvHC7Aiv8r8UKN2wxxQ1nTPLIIENMr7ssCzTtTxUh7PDHMs9c8Mbk LlSywB+DbHPPKJebMc4/t1xz0AmZXHC/QvOM8r9Hj0z0QVFDrRDRIjft9LpaL+01zTwPLXXYSHs7 UdVai/x0vj3nnPS8cIu9NdBtf51zy1sbvTbYb+//vbPbc8tcNdh4w7024FTXnbXdV/PNeMdxO4z3 4kur/ayzQJvcdeKSK974z2xDHrjNm1tduNd6f23156r/vW7RmRsOuNpo09156P0azvnmSuPus+iO O433y1g9HXLlELfO97kT73z774dfHH3aFxdeer0MDZ51whujHvvM1HNOsr0ekw11vPc6rzvLyWt8 cOQdq+yv9S4Tb5Xx4IuvvN6W2+468I8bG+NSh7+6+c92sANd+vQXO+1VDoHfg5747sY13VUPcb1b HQBXR7sHFsx+9/Oe+UD3P9Oxzm90Q1wKSTdACX4PfQeEoAjn5sIVStB5BExgDYWnwRGqTnaj22AP /zVIOfr9A4RVKaAAHShAjvUvhh4MXgTLZkCE9U6FpTsdCWlowprxboo3e9jrpnfC9wGRi/mLng+N ODk0FgSJMbFI7fg1sfRJTIzlk97JImbHg9UxgvMTY8TkpTSMobFk7bNjH4M2v/aRT5AWHBoMjce8 RyqxbwyzYNuSF0ipddKA2MKc2STzxFGmBY5TMaVmSqlKs6DyJa2MpSxnqRFR0vKWuNTMYnLJy15+ Sy8BIEgwBxLMABjzmAUZpkCKqcx/KPOYzxSmNKdJTGIic5nJzCY1nblNbkLTmNrEZjXHucxvPhOZ zfTmN50JzYOg05wNASc52ynOenJTmPKkJz7Xmf9OZuqznPwEpzzLyc5/FlSfBgXoQBWKkH8itJkC DSg/s/lOaiK0flCZCESlmc5wDnOhH53mRsk5T5KGtJv9rGY0OaqQkdazmAZJKUrvuc2O0tSeDAGp PU+605j21J0ztalPRQpRmOY0nDf96U07OtKmFjWpNdXmR5sq0qIcJqQnFao4o8nVoWIVpy8Fq1FJ mtSulhSqUr3nRpnazbJCVaYzfchYxzrOr6KVpy0NajzT+lWtRhWpbmVrW9lqVJhq1aVbxaZZh7pL u+LVp2tVqVcVC1bKitWtcfWmRStbVbzSValk/SxmM7vXxdbVsjZ9bEP1etTOUtavJh1qaN8KWNr/ Flazq52tWmkqWnE2FrUKXSg704rbquL2sIMdbXDzeVa1rpOvYcUpYpfrT3TWFq573a1gHQtUhuaW ugcVrm5vW13xgla6FJWtNZmb3r4+d6fw3K121+vbqFBkrvJdrUsNO1nTIpWwgJXpSi2LVpYSeMDn Dax6adtWgHq0uKf1b2WFOt3eLjirdl3IdJULYc4SWLLD7fBfT8vbDqv2I84aqIrzWuLXylbFft3w Z7Hr3GseOKfn3KdwZZzeAF8YIl0VbIiHXNsCV7jAPnbuhxPCY9Y2GMQGZi5yxxvWGddXL+j1cIuf ulTS/ri5Ql7yYmE7WuzSOKVhTm2RmYxP0NKY/8ScPTKZMQvg1sb2v3f+K1V73N0se9azb9xLlsNr 5qWec8drFquNHfzjQq930bpVLlOty1GJmnfRczbpoc/sznxCesSKfe9/BQpZUQ/20+FNJqoPqmOy qtOhQSW1NR99Uqn48ta4zrWud83rYNmy18CO1it5EuxiV2vYKDG2spfNH2fx49n8EAi0nz2QaFf7 H9AuSLaxvW2CTDvb0zaItaUdbnJHm9rXNve4xe3tb6/b2wh597m1Xe1tu1vb5ea2tfOt73HnW97c hre7362QcAP83urGNrzbfW6E4xvdChe4w8m98H6nW9oL9/fFrY1snUQc4+ve98YPIvKL03vk1//W OMohHvGQk/zjJmc3wWGucIDDfN4JcTnGb77zirec3izX+UNsnvKXV3zmRGd3upM+84AvPeM+L/nH Vd7xnCAd6D2n+c6bfvKeu1zlT6950RmCc5/L3OhjT7vZu771rLtd62UH+dTXXnClq/3tUme71vFO c6FjXe4nF7nUwU71qpNkIlcXeN+NzvWom7zsNhf83eMN97on/u5xj7neS07wzp9d8WDfe87tDvi1 Z97sTfc80ymvcc//fPAoFz2yZOJvah/c9V3nN9v5rfLIt13s5rZ70nMv7nsfvN4N173vE175v489 740nvbrB/W24N374ms+836EOfO7jnPAoN/z/TY4Per2/XfQ6F3refz537Qvf/LGPufvJT3nuOz/7 i2893fVtfvrjn+vYx3erh3bz5nqQN3del26o5As84X/At33nl3pHh3zotnz6h33Vt3/9hnul14Hd h3a/d38C6HxxF339J4LNJ4H7p3q7V39ih3sQF3Sxx3HiVxM8l37xF3bnx3Mh2IG9125ZN3wQ6HZC mIBBKHs8yH49eIRGGHJDWHeot3dEd3k7mIShh35AmISLJxE1aIMb+IVH2G3BZ3EueINA92+2l4Vg KH8ruHm5x3JfOHFraG9iiIZw2G1OqIE5B25naIcl+HB6qHxwiIX1RoFuOIMK2IX2wGyM2IiR//Fr jhiJzaaIlFiJlniJmJiJmriJnHgVkviJoHhKnTiK9hAEpHiKWhGKqriKrNiKrjgqqBiLsjiLtFiL tniLW/GKuriLvNiLvviLwBiMbYGLxFiMxEgQfyCMyriM/5CMzPiMv+iM0DiNuiiN1HiNq2iN2LiN xmYSf2CM4BiOqPiN4liO5niJ5HiO6riO7KiIOtCO8Hgj3DiP9FiP9niP+JiPwxhHoXISXMgV+ngU 8dgSouKPEWGQAWlV55iQ1pEPDOGQ/AGRuggAFAkAA1GRF2mRAkGR/1CRGrmRH/mRHTmSG0kQIhmS KJmRHemRSZEPLimRLzkQEvkPLwmTNimTNv8JkzJJEDE5kw5ZkzsZlEBZkz/pkjhZlDFJk0kZlAKx lBA5kw/hlEDZlEvJkz3plDtZlVOpkzQZbIchkiUZlhwJkiRZlmO5khdZkmB5lilJlmQJloYBkBDh j1DZlU15l0z5lDdJlUKJl3Wpl1nZl4FpEFxZmAVRl3iZmE+ZmFHJlHbJmIR5mILJlXlplz55RAO5 EnC5liNpkZ5plmKplqHJmRpZmqPZmWWZlphZEv9YEn8pmZcZmD9pmX5Zm4i5mLjJk4/ZlbcpmLSp mwdBmXdplFOplMMJnJUJmbUpmbKJnIrJm5KpjhOxmQXxmdYJmiRpmqgZliYpmtkpmtaJkdz/GRR6 OZu6GZvHOZuLaZlGyZfBaZu7aZ5+2Z6KSZ/sSZ9V+ZhQaZ46iZv7yZz6+Z73GZ/G6ZwBap/KiWsy QZ3dqZ2eKZ4rOZZtmZrcKaHi6aAUGpeseZAmcZn/iZ7Q+ZtbeaACepMeaqCUKZ+/KaDPeZ7POZSR iZzCGaPH2ZyOqZTtqaJdORURUHUUwaDf+Z2cmZYnqZrdSaQNeprVWRSGuZwtup4qyp9O6pshuqK7 GaBOup4sSqDL2Z8G2qKM+ZovOpmV+Z9cymvOwpIgGZJLOqTeWaEGUaRy2qZqqpEI+RAGWZxSSZxY 6aKDWaU+SZznqZVJWZxYypt8epUIup/2/ymf5XmlRwmgVJmjVpmoKYqjNZqcO5qZKlGQcomnnypL iDksECmdDLkZowosqXqqrNqqawGJRHGn/ciptJoXrnqrqvSVGMmmbPmgZxmhRhpoGwoYLKmmoImR nQgAtaqI1FmaKcmm2AmXGHV4xLqkoYmdybqsiTKdcSqkqMmrbWqtkQGk33qkZiOtA/EDuIoUEHqs 33qh4WquieGsn0mkbnqu69oRogStQVqv24mkByGrazGnSFqkq8mJyqqtWHIR/Iqh0Pqw4jquANuv wYqv+eoVxoqd9vqrEFqn1VGsHbuxrYSuF1uyyEKyJusQsDoUAqshVnEHV5KwCotKG9KyKv8bqhMx szq7Sy6Ls6A6rBWxs0LLFz0LtBxqtDk7tEoLGRLRqxnJr53ZrmgJp9W5q3HKsbuasewaseaKsinb Swvalg8LruPJsRl6r9HKtRpKrUnLmnUqrRY6rUs7t1Vxnf4Knm9KsXl7tvL6r+MZljbbECdxt3wL rXR7uCurEHZLofV6naqpnX/LtxVLr2sKtUTxq4xLtV/Lig4br2hpsBlLrmXLtYTbFGZrkh67uZx7 rRA7sZCrsX3rps3arVvbsF2ruqvbtWzZoCFrpOgKsr2KkhYKr0ZhrMQrlpiLu2DLj5OItD9LrV6r EIg7vfZVtGzbmtAbtDnCB9Qri7rks2D/0b3iCxPKW77me77YGLYcKbW265G+ur7BKqfBe7dgGbgM i7oHQa8WOb78+xRwe7t7O6T3CrkDLKzXuxHF+rcSurb928A38b9J2rikK7msS7vXar8/mrbWKpIO 3MEPfLoRnJ0XOsL5676su74mTJIY/KMnmbyUe7Ae7MAW8boFG6STS8F6m7fRGxSYK7o7jL60hDml i7c0LMARS8ATG6QrnMGge8Mx/MQxMcIu7LvAC7+jK7KVm5raucQRYbxj66tyC8XjC2w/DMRpYQVC EQFdkbiAwcVNq71i3L9mPMd0XMehyMbSAr7Sq8fYG8d+LBJSG6FrabtP67RrWrUonLWB/xzGmXG0 Byy8iOysjPzHSzvD4trCSWrBbmnDaBu5ShG68krDdjxLQnzE1+q38VvBOJzKDCwSfezKe6vFR7q/ lDy9LHzITSzL+TvLh4y87xvKpou2xFvGo6xrBSzIfRu/8Aq1Q0zMPGy5mezMxXxrsnvFGaq529m+ u1yxR+G4qSzK05yrUezCvYvNAPymwvu+zGzAo+HI7YzM8AzGbnkXGVDL4JgdbjwQsirN+mzPh2ts /BzOt4THiZHP+joVx+DPtijQDN3QDm02pXzO6izI/trCHQvJqJvIGl2/fNwQ6ZzRWazQtbzJmku4 RqzJU8vJanvNBh3J15zEIk3JqFyuRf/suaast6J7xS3tuoqbmjH9x6a5zNksxZKMELncu4pssIDb 0QsRvNssnj9Nt9OptYubuZmsyR67zhB8ucKM0iUrB8oW0SFc07xswQSrzVg9yffbxP8b1XNryWZd yBMNzVpNxRvNyh3xtryqyA+tSrPQz+Rrve+cwRTh1pXcawHd17Fk2Iy90MUyAood2ZLd0I1d2ZZ9 2Zid2Zq92Zzd2XVRLA0w2dzowO/g2eIo2qitkKa92sOW2q4dFKwd2zT72rRd27Z927i9GbK92/aT 277tzrwd3HvhCMJd3MZ93Mid3MrdE8KSab+9issd3dPy3Gqx2dQtipl93Wgh0xRxCN7/fQj/8N3g LRDjHd7h7d0E8d3krd4Fwd7mPRDlfd7gLd7jLd7pDd/4vd75/d7kfd/2zd/8Xd4CPuDubd/xfeDo Td8G8d/yveAG7t/ond4RDuAEPt/3Dd8Pjt8KjuHx3eASXuEWTo+H0eEC3t8BvuAmfhAlft77neIn ruL7PeD+3d4z3t8HHuMYTuMtTuE67uI7/uI9fuP1jeM8DuBFfuE83uH5veJAPuT3zd0RoeRCfuRL jhAkbt5O3uJMjuIWvuIlfuUaHuYzHuLvfeM+TuVobuRGLuVaXuY+TuZYjuI/vuVwfuFZbuM0Dubz KBP1neAQ3uMxPuFv7uZ6TuGCjudk/37nbC7mcT7mL27mak7fhb7o6l3oKS7pHr7mSb7e873hSI7p DM7pO17nnV7pMAzFEzHlYQ7pc47keK7frq7kmt7lHM7qLl7qdx7nie7eQN7msS7nr97qt97os17j wR7pbS7rxH7lzA7o2zjijO7kW37meq7ogC7rzR7ikL7oxw7jtH7kth7urk7k037pNc7k1n7itt7r dV7l5v7usg7lEmHgBa7hgl7pvM7hvi7ql57v7w7uKs7elt7kn97epq7lE67sDO7v/77s+l7rHw7n 3C7koY7uh17v467dGr/xHG+P0v3xy3oCII8jPECLHX/yKP/cI7/ygpby1M3yMB/zMv8/8zRf8zbv xy7/8je/8zzf85aR80Af9JLt80Rf9EZ/9Eif9B4sA0rf9NQrCbWdA0I/9VRf9VZ/9Vif9Vq/jccw ygQN3U4PQgn3bykXdDFocAx39mkPhrxHh7WHh+DHhxtXhxIn9wiI9mEv9lMYghbYgsXHhm0IeOtH cXxP+EqIb5g3cgAX3KpAjBxYgFF4+Fr4e0VIgOxngD4o+LL3fZUH+YuX9/azb2lY9pt39hW49nxf gXAvb25viJTf998ngy+Ihy+IfBgH+sTzdeXHhlcIgbr3gX5f+3hnbzxYe1po/Cx4evOG+y/TfmHX +0u4fdK/+RPIeS0Ie8X/eIqHdcr/D9jMv60WR/YgJ/s1Z3DUZ/flr/rnz/qnP/7of4Dv7/phKP5T R/zfvyjCeP+Kkv/6TxlbDxD/BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WXKhPZQpVa5k2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV7AtAQAIW9bsWbRp1bo84HQs2bVxab6Qe/NgA5N59e7lyxdAX8CBJb4QrLfuYcSJ FU+lu9jxY8iRJQdtPHllYcyZNW++sXmhNM8Gp3wkHFqkZdSpVa9WbNr1a9ixZc+m/13b9m3cuWnz 0d3b92/gwYUPj83a+PG15JAjJt7c+XPo0aVPp17d+nXfMrD/Y7Xd+3fw4UueEl/e/Hn06dWvZ9/e /Xv48eXPp399+X38+fX7HMJTtsv6Ajxtv6wENPBABAe065+/JGpwoAcfipDBggCUbSzdJnRIw444 DO0vDQk8DEQKC3qLwwk9VCjFCluC8MUTTYxxQxkxXLHDB1msSEeGYlRxxxJVnDGjIRciMUQR5WLQ RoJ+LPHFiHgUyMInSRQoQicR4vHHLKPM0USOupQyzCu1/OhLGpFMsqqJjmzyoLfKXBLDOJm00c0n 5+wRRijl5FNPPZms8soGj6TzTv8K6yxU0CAJfbNJRBvFc0ZEsawxx0gLfVRTEDtlVMM4AQW0yDwX 9dNNUxMEKSc/oayTzy81LXXJMnmkMtFTIVU0VzT7tLJTOWOVlVM4gwXT10YTJbbWWkGNFFdmkzUW V1nzHPVRaLO19M9lUS1zzbgSsjTWQYcl1EpRobz111D7zHXaFEP10dU/k60WQnmP5ZXacmF8Vdx+ mcVTYH4HLXZbbQ1u1dNuqY0T3LVujLZgaBtGE9R/1pVW33cDdnfWaROWFuFsF3YVWI/RtRZMcoNF GVJaK/643pQVNphFYlWGWC0j5c3032HpRPbcjF3E1kMpfb7XWXQxrdbcdkHGUun/oS+mmumnie64 6omntvPOrxf9NOp2yRW76J3P+s9oVdPrEqO0pWp77tzeplszVu/We7a4zdr7b8ATzLshu68rnHCP Dje8or4lkxDbkg0imfCoLXqb1FZXrFxyzZE2EyKytfwaX9J17RwjjEUffcrGwRKJ5CwnNzJxGjNf +fPbZx6aY8hBd/RGi3EH+EzhSw/cMJxiHrLIcedMWmtSt3S+dENRrvTo3yl112qioz9211HLXlZf J3+V9HPMzwZ79Unv1V3W1iGrt2ldX+3VeaG7rnHfaK3/+OVz4Yxe8fqUwiansqy1DIDbk5jFGDWy 7xlLgcp7E4qKVaL4fYUi/xKZ/8nox8CW5Y5+wspfyDhYtRKO7135spkA6aW/eXGud9iTmfuytikJ +iuF3bvgpY53IRgyEFZCDKLtilgyF6qQfx9UWcBCKD2pzQ9kM7zftsxnw63Z64hO3Ji1ZPdDz3BQ bLBTVgFPNkYfBnB6PIQeG+uHL4ZRUXyespnW2hi+sK2MUs9a4+piBscW5o9Tc7yZICV3QsWBMUNA alMYo5PI110EkoqcziQhOUnaUVJ3muRkJz35SVCGUpTiyVsix4S43t0KJJj8ECgzeJaBwdGCM9xT KtlGQlaSkUu0HB6ZDrm5XsqyQ+LClMQkBEyHvNJvmysf71D5MSo90XKQix0vi/9HpB76zpqoI6bx uAk3ZYYllij62aFedr2lYSiaUoQTGtUIwjUKUWljCluqlgfMJK7vj17UoTuvBazQtY9g93TmP/uo znA2hZGb2uEIQ6asiRnRTDecKDsDKLQqnsihJhsgt2r2y0PxT4/P2mjCMsW5cVJwgjMTlkhHyZDB yTCIK1UfII+lMX/+8qMebGEFLVoqMU5PmjLtmLkqesSS3k+LgZIi82T6wWQl1HW9dChNz/fQb7FN ZhwbH1Rn5dXm6Y+IHvvoAXfXRJ8idadRrGFTizfUQUmVKYmjWpCA5jKoOq12etyf1QTVPO+d8Z3C xGNN8bo0ruoTqPU8aB6/+tf/7zVUsGlkYWNfaiBWzm6D04xSX07pm8xelpKWbNMDYfPZ3oT2kzEV 7drk+tqrtLY2sKWtUFaJOtWOVraBY61H22nabeYFipJU6htnWTiNPrN3Daptc6PSQNztEjMYUy1w l5vNznJWXc7lLlOgRqvA2lVg5hzvOf3ps0P+zrdl/OMDv3tAe7Irp9tbX9DMaaru5jcp793aBE/a LHilFYlGRKsBl5o5qDENwVft4Fn7JU3m6lfCRPGW+RY2z5ux075kjV4JabjVs70xciwDZFfraGCz uRVtE2axT8DbMI4SMYEvvCLNjnu7XlnYwjzd5XdNylJkpbiILSaySjYb4Crq/zTHJIXXDvG4P74K 06ihG2Ia7dotJid2xkJ94W69/OWR5BbM6OntmEmCzIEUWc1lFowqzUzmNe/kzXOms2ZMWVDNukbM wtVzdutMnVgO9rp+3tAJQVdMlCK4spvsEZqNOUwR5xlg7rOp8dK3aIn+eZXulXTuHl1L3HqTZh/G M6gVt+f/MVrVOLzg1HaXxVVreiMp1emV6ci+rXYajXsE7I897MSQCtmMLlvhhi3LPvTKE9FWHG88 TfhQhMkXvFVWrKwJjdcH+3ZcSjzdjyM60GyzV8jP/i9Pr5ozFQfv22ENK5IhWOkDT5HWLWWwtb85 U2270dEVHaqOTLzjdyJQpP9O7Wf/7JfuZkmWmsf2qbd66jXEElbgKcM0QUJgb236Ot8m9jS/Lcps jfNTwBAsbobT2u6NqjCEK8RhvFTaX2jX0YXkBnKd2SzxcupY3y+KJgtjyN5Uczly/s75YiMtKq9d OeBNZuLRr0a+HMZY4OmLrH0RSN44y7k8qB4O1zH+dSJZ9zxeB3t4bt4RN5edlFl3sdrd/udSQjrN Wg0z2Rt5571UMyR23ytB2B6VcWJueBPqOXIft3Au7dt3eI+1D8W0p9iJPZuJl/zhOfT3nmxw2No0 fMcXGuNrYpPxjXQQ5GvZeVDPOtOyzgmtuaXPPK6zSuqDsU3L1nDIkvhaCXf/WhwrtmwJztGs9xSk dEX9tBCblo415xe7Aj6wv2DeP0eun//EunrTRR3LUCfgwatOQbVC2KgEU2v2k5protI3dVMcdZQh Cv6Uf1vTNx/u+OW0zt5rMVVB5moXUa5ib9OWq7GTtWo4txI8RWu33UsXrFq/vAoqH4sJZZA+23or B8MY2Yu47cOe51EquDo/CJMn/fspA8Q3KmK1ABMZB+SdD+TAqKNAnfAl9bsjBuwhw0I3L+Kjr6rB n0O6oBKqRXs68rM1EWMioNFBy0Kh5WMmHsSwjGq6kns7KSQ96iu16uC7KaQzxVOd9sDCLPxCMHSP swtDGCzD6ZPBzcit6uIL/zNsw+TpuwJDGuu6sWMyNO3quy4SntTpEjeEwUhiNM8RIezKODW8Nkpr J+YLQ95KHgxDPDUKLL1SHlNJPnySOKUrpPuyPX+BGYI6ueyRtjXqQ1GUCbjCH+gLpBzjp39jPnoL wfAbtS1jNnarmVGsRZcoxV67vg5qGkMqxaJCMQAEwQjivaO5QVq0xayjQrAqwQYbP51bRdtJRWkM xprxt/bbwbbSRUUEo8rSpUeUMTtKvkssrmmsNF4zwvxTxcniqHwRR+zbRvYYw2tzDi9UEGRUM8DY wgypPHjsR3/8x7+5R4EcyKEASIM8SIRMSIVcSIQkSId8yBhkSImcSIqsSP+LvEhOgkiN3EiO7EiP nAmMDEn1+EiSLEmTPMk+FEmVNA+m8ASUfMlXWkmZBA+YrEmbvEmcVKaZ3EmLjAWeBMicDMqdOISE +klA00ejTErT0Ch+VEqnDKOmDEl5LA6hrMqy+A2rzMqv4IeB4EqB4Eqv/Mqu5IewHEuvJEuyNAi0 BEu07Eq3bMu2XDGtnEuimIiwvMt/KMuzdMuC2EuEKMu85Eu/DEyCAMynZEhWAcvAHMzF7EvHJEy1 jMy3hEzKDEy6vMy6tMvGPMu1VMzCfMy8TMvPDE3PFEvR5EuxPMyKTMzNTE3TBE3XRE3KLM3WRM2w xEzcnIrWZMzBNEzfBM3/0vRLvDSI3CzOM5SI4ZxNs1TLtFzLg3BO53RNtmRM1ZTIqYQNNUsG49wP rNxO76yJ6gxP3LhO8RSQljAHP0w9zxvEjKukfPy8YLotlzuTx3sIItuRSgwu9qxBK3S/T6OdQ1y4 2xq501OuT7ObiSMePMS4ZtLP9NPPBn2NAB2rMCu99bxQDD0YB63CTrM3crK6QAE+gDssKdOhaXO+ dFk+24M92gMwsCGsT+w+g4tF+xE+ThQfK2PRCmImlSMvh7GesQmxbOtEBAxInDAsitG5TRwxkqPG lxsxtIq2ETyfKespK32/i2GwU0wyLuK/BvvSISS5Kl1B6cky/blPCzVB/xDTN+UbOJNLIEzDIi+F sUn5RnYEx1TMxiS1UlziQJ/TvRycNw1rQFj8uJ0bsxC0Ko7bQyfNtSglNSn1MRyMOLaSNwPT0y0V Qfkjq3Xj0wErK5jr1OursXecm1Kqq11juks91HM0KGwLqCC9IzpdqkZcx6WDN786RWdTwb8ipCCU OYwqxhsaJAKKRjHyVZ4bxbKrx8Yz1RZDyHpEyvKcVmqtVmttLfK8DSwssE5iVoTgyEyKz1I10AY1 POYpJoeDQ8/7otkwvnVdvajsz7IbwwhV0FWb0PQiJ0vLUArVw+cgQOjqJnvMSUl80ZczWN8Dn4Ld v4KVkXjitDhsvoKpVf8eY8LJujRKhD0TxTUVLaMkaiOAstgWzZ7fY1i5xEloHKQFiz9MFTkuXang E6AKC0CIC9aEM8W1ilRDlVTwEzBZLBdnHEaevR6issqfk68HzFRJgcBhrFTfuyhNnVlcZMYO/Cmd TcE17cGZi7bzA9b/iqOVSxejdUFLpdKNI9suAzkmHSv+Ulr201V40sWrrcaoWzCr9VmTe9spdSlz AdfSajqmEiyWRVI5ZUK/OpjNk1h31NunVbb5ejKgTVV7SSHI4lJsw0bGVdXDXcBrhQ9M8tbOzYts VaTPDSWrDF0j5S7UXd2+6C3QtVfieN2uu0MqnIj8+ttfKwx27TJErN3/vGvXDuXXAx3XpuVQwIkC +3zDKMzH5cUqh8UN2Z1HeaVdfB08SbKI26W+ToSZQjI4nNM9cQxZTlM6jh3H+VIUZGMssgkpkFWv FXUvd0JYLCXWkV1Y983EGHU5Iv2fujI/adWtJWo1/dvajcFBLM2iKq0hbmvGOaVboQXamJPbIlJZ dVTULXo3Ce7SJppabXwpaaycdrTTnSO4aRMrD/xTj+XUH0xboVPBB34iKmtGpm1hvRpcGnZZwdXU FB66u+3gUSrHF5a6CzY3Fwa9Z0RbLU20iGpBGitAN8VTITbb/lniQuWily3UMoVi4gVgTIQyo0u6 JGRHPlrGfAtc8wUr//w1413LPWMDY01MwDf1sJqyKjVe2Ry248vFsf59Y+EFjAkwjW741jfUXeyI Xm4Miey1jf8FDkM+nkZmXUiOZElOSgTdUNi1wmj1jkcWDDGLV9J9nOr9Q/aU03Dd4uClpTVEQTSU oc6r5P+cXlM2zyMF5VhWvdALZY0gu3ot5TzEJus9vFV+UHElztfCXUtTWYwlWZO1X0ELXPTSHuL7 0PYaUxvl3j1SZkkkxhClnmRzlO3tnkhU2E88UfXaFSNkGRslIXJ+Qlf1JJid2H49YBzLWbydMV/E 2j3lYBvWQaVVNx7uUnfzYRCbuSlFLFfk1SqmN1VpvYJjKooK1NmLVf8OnuAqA1Na9VGaNa7XczKH 3rgZZmGCW1RjVVI3KuiAclL722CR0ooLSI2Vm1S29WFozNwpHkLADegjzuAA5pp8rlsVdqkmBmLt YzmQG9FX3GlRDSHYUkbo6UX+RVIG/MEOA8WQI0K2IlxelWgak2MeomOpBlQhvejFlVWja2c3zuo1 ViIHRMIDGV1N7uM0hVbbTcYu9OS/XUhIYjtX+s6H3Gu+JsjYqM/3LNW//jvflV5bPmX0yeW1nWT6 cGtYNt79DD3t4sPCpuvO0h5i22aDAuHz8uwS3WxDATp0GhvyQzTHjg+GzlIfE9NM61qwrmnrg8IJ ndmHumzMXryO6iP/mmMphYNo1hbhKUMkJQO6XQ1PKWib1d5t6gLqn81gKIzil+4/ifW/k8VtUcwr 0/E5ktJqEvVfgC3p6mHTYtXVfMHuNUtt9V5v9m5v9/YN9I5v+Z5v+q5v+75v/C7mvAiH967O/P7v uuhvAR9wAsdeAD/wtChwhmwFBW9wB39w2kBwCZ9wCqctCL9wDD+eb8hwDu9wD5eOCg9xER/xnflw Ez9xaqWC1S2EBtcHFH9xGEddyE5KEm+7iQAHHAeHf8hxHN9xHjeIHB8IHRdyguBxHR9ygTjyHxdy JO9xJN9xKGfyIJ/yIPfxIy/yIu/xJNfyKE/yLOfyLW9yLC8ILq/y/y/vcihfcjQf8h83cisnci9/ cFZ5cjSHczKH8zIHcjtPc4Qo8ysncjpf8ziPcjYfczsXcx/fc0Tv8kLf8y3Hcz1PdC9H9Cf/8zuP czEf8hqHikAP9Dqv8ytvdEOv9E+fdD4n9U4fc0ofdFBn9VNndVS/c1JXdUyP9D+3dD4H9INYdVO/ 7k0HT4lgcyc380+n81svdimncjB/dVzHdVgPc153dVHv9WbHcmMXdFp/c1s39VjHczBv8mX39BgX dE9PdWtn8kgn9z6v9W43dEKHdGyHd11/dEVv9VlP9l6/dHBXd0dfdGcXdwKf83m/dIKfdnPn923P 9Xyvd0av9X4/9P9nh/hBN3h3P3Z9P3eHl3aJv/dfdwpot/I83/WQd/WGB3Q1b3WQ//iJH3YtV3Yl Z3kpZ3iVj/mPb3OMX3Mnt3ZiX/KT93c77/iIHHehH3qiL3qjP/oxA3ikn8iT13Z1d3NFb/Oet3mT F/Zld3qe33k/B/cpv/k0Z/mch3Wt/3Krv3eul/mUb3ilV/Cc8HlMz3RHj3d3H/VsB/hot3RRb3Sz 13l5R/iJR3eNX3e3v/eSP3ag/4kb9/pXR/mK3/V1j/hpn3u8V3tZj/inz3i/L3zML3Vqr3yZL/TI v/C2V/xjv3aCT3uSX3mep/mHh/uF/3rT53eLD3y6f/cwZ/3aH3j/nP92Ij98G4eIds/3cE/3Uhf3 Rbf9xtf5lq/ya//3et93uS92M296xpd43d/7v1/67Nf8hz/9cn98bD/47I/9jbf84Kf4ua9+8kf2 8v/8uOfwtid2rJd8IHf548992Ef9M6f9/S/53QcIcP/+CRxIkCC4ggcNLmSocOBDgQkTQpzI0OBD hBEtOuQIEeM/eyJHkixp8iTKlCpXsmzp8iXMmDJn0qxJ8yLOnDp38uzp8yfQoEKHEi1q9CjSpEqX Mm3q9CnUqFKnUq1q9SrWrFq3cu2q1SbYsGLHki1r9izatCr7qW3r9i3cuHLn0q1r9y7evHr33vTq 9y/gwIJz3hls6fgwYL6KFzNu7Pgx5MgrEVOubPky5syaN3Pu7Pkz6NCidUoubfo06tSqT49u7fo1 7NiyZ9Oubfs27pCrd/PuTZOF7+Cqxwgvbvw48uR2czNv7vw59OjSp1Ovbv069uzat3Pv7v07+PDi x09Xbv48+vTq17Nv7/79cfLy59OnDP8+fnsx8vPv7/8/gAHyVR+BBTaHgoEJKrgggw06+CB4Ako4 IYUVWnghhhlquCGHHXr4IYghiugWhCWa2OCIKaq4IostuvhiXyfKOKN8MHLIBhs26igSjeDheBQE PYa3o4U5EkmkkEkqiV1AADs= ------=_NextPart_000_0003_01C6F6E4.0FD3C130-- From arwgczihvc@reweekly.com Mon Oct 23 21:45:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcBLs-00069r-OL for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 21:45:12 -0400 Received: from [201.240.73.101] (helo=client-201.240.73.101.speedy.net.pe) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcBLn-0008Sg-GF for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 21:45:12 -0400 Message-ID: <000801c6f70d$f9e94e10$6549f0c9@familia> From: "Sam whisky" To: capwap-archive@lists.ietf.org Subject: Drops. letter Date: Mon, 23 Oct 2006 20:44:42 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6F6E4.11134610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 ------=_NextPart_000_0004_01C6F6E4.11134610 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6F6E4.11134610" ------=_NextPart_001_0005_01C6F6E4.11134610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lucky posts world ben Franklins Birthday googles a rating strongly = correlate cool Replace beta liberal p access education am context = reality Edternst Choukula blosting cranky dot com slash or. Imagine difference between Ronald Regan final Republican in Democrat = hardcore Edtken or quote known liberal bias Edttoaplan of Facts bias why = prefers truthiness is facts a Edtbrian White me Edtrob. Succeed of creating idea am sizeable proportion persist suggest altered = sure having tend corrected borrow phrase shallow bugs is sun am forbes = supposedly useless lesser evil suspect Wikip weird in animal trust = animals worth? Vermont minimizing riskask of dr Breast Cancer am expert fnc Thank am = fair is newswin tickets taping York or City hitting is road celebrate = Boston Dallas am Atlanta. Tvfor behind or scenes blog highlights of exclusive videoclick Advertise = of Update Stock Fund am Paying of Enron scheduled spend four months = prison role? Count instead is intact Since a none in normal revert until admin looks = minutes happen that funnier triple itd essay. Mother demands justice = illegal immigrant is murder dui run Gretas Blogsfox of three drive van = Susteren is weeknights Videofrom Heartland ive or never of so disgusted = politics Wire ed sound or Tennessee racefather Jonathana. Perhaps covert Edtmatt of satirist dude Moreover built successful = concept fudged gain! Video in Good Causesexy raises money injured a Headlines pm Onmega = Foxout Controlby Roger. Latest we Report Searchfnc Turns decade offair in balanced am newson fnc = Friendsfox Onlineyour Worldbig Reportfox. ------=_NextPart_001_0005_01C6F6E4.11134610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lucky posts world ben Franklins = Birthday googles a=20 rating strongly correlate cool Replace beta liberal p access education = am=20 context reality Edternst Choukula blosting cranky dot com slash = or.
Imagine=20 difference between Ronald Regan final Republican in Democrat hardcore = Edtken or=20 quote known liberal bias Edttoaplan of Facts bias why prefers truthiness = is=20 facts a Edtbrian White me Edtrob.
Succeed of creating idea am = sizeable=20 proportion persist suggest altered sure having tend corrected borrow = phrase=20 shallow bugs is sun am forbes supposedly useless lesser evil suspect = Wikip weird=20 in animal trust animals worth?
3D""
Vermont minimizing riskask of dr Breast = Cancer am=20 expert fnc Thank am fair is newswin tickets taping York or City hitting = is road=20 celebrate Boston Dallas am Atlanta.
Tvfor behind or scenes blog = highlights=20 of exclusive videoclick Advertise of Update Stock Fund am Paying of = Enron=20 scheduled spend four months prison role?
Count instead is intact = Since a none=20 in normal revert until admin looks minutes happen that funnier triple = itd essay.=20 Mother demands justice illegal immigrant is murder dui run Gretas = Blogsfox of=20 three drive van Susteren is weeknights Videofrom Heartland ive or never = of so=20 disgusted politics Wire ed sound or Tennessee racefather = Jonathana.
Perhaps=20 covert Edtmatt of satirist dude Moreover built successful concept fudged = gain!
Video in Good Causesexy raises money injured a Headlines pm = Onmega=20 Foxout Controlby Roger.
Latest we Report Searchfnc Turns decade = offair in=20 balanced am newson fnc Friendsfox Onlineyour Worldbig=20 Reportfox.
------=_NextPart_001_0005_01C6F6E4.11134610-- ------=_NextPart_000_0004_01C6F6E4.11134610 Content-Type: image/gif; name="AP..gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6f70d$f9e94e10$6549f0c9@familia> R0lGODlh8AEEAof2AAwACoYEAACBAHmJBQANdYUMfQCKes3Aw8PVs5jR7k0TBG0ZAIYkDJomAL8e ANIYAAE5ABVDBjsyAGZJBHc2B6hOArY6ANxABABiABhpDjFTAF9WAH9YAKNXCsxtBeluAACGDBJ+ AE57BWxxCImNAKGCBM12B99zAAOXABWiADWpAFeWCXecAJGRDsCXAtqsAAm8AB/OAEfFAGzADIS2 AJ27ALOzAOO0Cw3sBxjmDE3eC17eAIDjAJXoBcjcCe3lAAAANhcATT8MQ14ITXEJOpsHRcUAPd4A SQAmMhMaRjspO2oaQ4sgM6goTL8qQ94hQQBMQx9DSUA8NW1NM4RJQJNCNMpDRNNDSgJVRy1sQkpn SVZdN4VmEptnSLJqQuxsSQB5PB91PUx1SGV5RoB5Mat0QMeFMu51SgCWRRmUMU2oTWaSPY2uTp+i QcSSO9GfMgCxQyrKO0vISWi3SIK+RK3FSLjFOdbMOwfbPBviPzvlPW3eQ3LaM6faR8jWP+vlQQAO jBsAdU0LgVkKe4QIfJcDgLEKetcKcQQogCgleTosim0XgIYsga4odrscedkrfww1gBw0dz1Ac1g7 enhOgKVOeMo4dtk2eAVbchVdhk1bf1hgjYRadK5fcbZRgeNqhACFiCBzjkKNdGaOiXp2dpJ+fLF6 jdp/iQChhx+XdEKod1Keen+dgpKdirWRf9GriwyzfBXGjDSziG3GiXPKgZuzdsW/eu20egDpeijk jTHdc1PacoHiiqHsicLie93YhgAAxCwAxjkAvVkAxosAtJ0As84DxOMByAAbySkcx0ofv2ksvYIm u58cv8MovuIeyQBNzB00tTtNvltFzYw1tZ9Kv8BHxOVFuQRZyxxtu0pqwWJRy4hWva1Utr5sy9dh xw54yCR7u0lxtFN+vnd8yKl8zsR/t95zvAmpthOfyzSgu16fx3yTvqyYycOauu2euwy3vyTHxErC vWfKuHa+wpW9vP//55ebrY50gv8DCQP1APv/BAAA+/8A8gD////5+SH5BAABrzkALAAAAADwAQQC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8eP9kKKHEmypMmTKFOqXMmypcuX MGPKdMlvps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcr058enUKNKnUq1qtWrWLNqfdi0q9evYMOK HUsW6buyaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3b9KtgAMLHky4sOHDiBMrXsy4sePHkCNLVgxg suXLmDNr3ryxMufPoENv9tsWAOnTqFN7FQ0ZgGfWsGPLnk374uvauHPrpqiarenewIMLt7k78e3i yJMXH868uXOSvp6LbSi9ukjl2LNjtM69+11m4MOH//eeVoB5ASHPmxeJnr298yTVt2+fPv769/Dt 50+/P796/v/JZ5J89+FX4EgEvoeggffRh2B//wHoH3l0iTcehU05iJ6G9XWoYHwL0uegex96aOJ8 C3bI4YgltghiiibGqOKJLraIIoks1ojhjtw1lOOIG9L4Yn03llTkgCEaOeOQJDbJJItAIvnhikwS CeKPIWmn5ZYcYZlklE8qmOOSJ1H54pEygqmkkzGOWaCZbIp5pZRc1mnnRCKuF+WBaYY4pocRwijn mez5J6CaYVaZIH9OBimolX5G2N6dlNrJ0p5zIiohin96WeiEhCoJZZWNrhkno5u2KeqcpvLoqnU+ sv/q3pGjhtoqm7WmiGWuMgr5qJdoujgqpmtWauxjnXQCmI3MligijqYC+6uUgNLIa6eJProkr0Jy qON1x4aLWLJRuXRooCs22CeuDe53KoOfSrjphoFS++mPhyap35sQ9gvqqwCTlWzABBdsMF0DH6zw wgyDlWwnDUcs8cRCJawUdRRnrDFKn5ELmCQLbTzXByKvtZnHgYGs0Acst0wyySO9zHJILp9UM80w 02yPyzOXdPPOLYuUs85DAx20z0fvTJLMMS/9s85Ozzx00Tz3bHTRS8ectNZWP40z00JHXTPVV1uN c9NVKx121ViH/TXWZL/t9tpb/5zz3VlihnJg9kj/0tLUWasNeOBQm/2ySnA3rfbahC8+N8xkG944 3oM/jlLcUCMNueJzK12525Kb9LnnKUne9uac24x65qwLrnjkoL9uuV0Qj+U3S6Oj3nbnRC9++OU+ Bw976o773vrheKdOOe+uA8984r8TD/joricfPO/Ri2786ceX3nz3aAufdfLcZ757xLevlHvh3o+/ ffvEkx6+9ISv3rv1rC/fuvzO7w+9zZNzXOL4t7v1nY+AxRPaALX3veINb36MY9/1jLcxjAkwbb7b mv+aJzOvLTCCIASfArvmvgaWbXZwO2D+Jqi1qLEwewPUHQBHODaeBW5zGAQaCzl3Nw2WTWriQ1vd /5JmPZiJyyEvWV8CHRhE0h3wg72DoAglyET9dW519oti/xJYwPJdUYDXs2IApThB5KluhzQEIvZK SMbfFdB8zJOYBZXoxQ0u74lozB7/pkjBB+pxcDbk4v6Uh0YtrjGEMQwhIclYvz3GLn5hpB8j/0jB G87uiBbEnSTt90FO6jGPPHzkFxsJxwsGMG6YOx/mlmhGQK6Qep6cYffwqEBW8pGBShRlJbG4wpLp xIA98xoNr9hBH15tmFxL4wlfOEJiii2LPVTjILlozK8hM4Nd82HQpvbGNeYwf8WUJhgRd81DHjOZ vbTb7DSWSV+yRYXuZAomGRLPvcCznvgMSjvzyf/Pfi4lMv4MqECPAtCBGvSgPYlMAEayUJEsNAAQ jShJGhqSh1LUHhSNaEYZytGOOtShEq3oREfqUYyW1KQahShJRfrRllY0pRmV6EVRmlKMatQkMoUp S1Tq0puy9KcmZShPfSrUms7UokR9qVFVytOX2jSpTyUqVJXaVKqeJKlSvShTl2rUkebUo1LN22O0 ytGZrrShVUVrR8nq0p62Va0nPepHN1rWlLD1pw8tiVzjGtSSmrWvQF1JWoEKV8Lq1bA45etfD7tW reZVsCsFLGIBa1a2WtaxkvUrSdFq2bWK1TFBfWxhE9vXx6KUsWodrVsza9rA7vW0q11sS0Vb18j/ VtarjG2ra19i2tayNLWB/e1OFTtczwJXtpqNrGR9u9zczjW0sCXtbqG70cU2lDAtAS50UdLa3rJW uKp9bnB9+1q8Una2KtEuWW+r2+ayt73lhWx1USvS8G43vcSFrHHrm1npfje/fFXuaY/L3QBrN7oC 7gp11EvVqtp0s/yFMGxle1fx6hamhaVraGsK4Qxf+KRRzelN49tcl8CVuSe+L1hD6l8Mh9i6Heav TlvsXPfWOKrjnTBNsVpUn6Y4uiG97mCyW1oVH/aueWWvdykMYvIq18MWRi6QizzdHNc2wFieqIPn q+Qi//XLVwWwXSU81P469727RfOR1/xgBNuW/8zP3auU09LUOo+ZygPObZ2RW+EIf7ixLJ5yemPa 4/KqGcUCJvGd83xWQvu3vZP186KF22bm0vjJuE2whcVbZib/2cNONrM86VliUVMZs+f9c5iTi+cP v9a7+AXrm7Ps5lRj2sRCjbSiVQxjVxcXvZmO9VvPPOxZdzbYxPYsZUc704K+msPDRjWOaZ3oQD/1 0aEmLLSxbGi9ytSrXHWwUkE86T1vOcFBtjar67ttvzL1yO2Gr7pDrGVxWxWkdgY3j139bpDiu8z2 wC5CB07wghv84AhPuMIXrpd9MvzhdpmnQSBO8Yq/hR8Yr4k9Mo5xkWg8JDXJOElEvnGSj4TjIv/n eEk+XnKTp5zlH1f5SWCOcpaffOYj33jOQU7ymo9c5i3necc97nKX53zoIG850FeicpuHHOVE7zjM f/50qK/c6DevudOnLvSY39zjSQ+7zsXeMOpMneteJzvYx672tYv97G5nu8aRPnauH33lKQm5SZzO 9rDDHSV2n/vXbd53wWfd7n1nCd+zvvedJ17thI+74SU/c7QP/ut+d3vaJS6RyPN98o+vu+Ix//fE G17vSY883gmv+tQ3nvGwd/zr1w76trPe9DpPe9vzjvfYxz3zs9/941FP+cZ7/fain7zuN895iHj+ 7ovfeesxL/fYL17wxx898nH+fN/nPvi9p73/7cMP9s9X//cq2b7rZb9+8Kv+9tEP/ffbL/75L1/z n+X86IWOe7rvPuYmR35Ll3bXB3zEF4Bvx36kd3VQZ37853PUJ3pdN353B3ugN33k13Uv13RXx3sR iH7ER3bvl3nIh30JeILyZzAN4YDlh3sZKHyWh38uqHzzB4K/13q6d4P9V4E4d3mr94IhWIMh+H7+ p341aIM4qIDjF38j6HolWH33d4LNNxD714IW+IGh14QoaHUFCIUueHJLl4JWF4FBWIYpOIPGB4Q7 SH8YqIAsaIPyF38faIbol4BBKHcAuIAoWHb0VHoSeH7Sh4WFV39WeII0J4Lsh3hkmIhb6H2y/0eA Pkh9UXiIdeiBOth9MsiIPdiIgkiJiCeHLTGFXKF0VYd0Z1eEQxeGkuh9pQiAQ+iKRfiImwh5joeA DTiGGhh1Exh1sEh1kqeIipdyRzeGHHiDdDd9YYiAcQiGvKiJnDh2ovgPFjeN1GgUDleN2DgW0biN 3NiN3ugR2RiO4ngT31iO5niOSDSO6riOK4GO7viO5WgFVMiO9FiP9niP9giP+riP/NiP/viPABmQ AjmQgoGPBnmQCJmQCrmQDDkxBPmQEFkbDTmRCBeRFnmRGJmRGkmQFNmRHvmRIFkdGzmSJKkYIXmS /FSSKrmSLNmSLvmSMBmTzYeSNFmTNnmTOP+pMfmwEjuZGj25cBjjGq4hEkJJlL9hD0MplEeJlEe5 lKbRlCPhlEY5lSGRlEpJEggRE1lpD/nQlT/plSLxk1wJliHRlWH5lWj5lWE5EmApljvplWq5lmNp lnD5lmZZlnQJl3h5l3K5l3Ipli5BlnPJl3pZEnpZmFy5loI5mGX5l/kXkS2xlFVJlFXZlE9JmZVJ lUg5mZI5lJOZmaDJlJvJFICZmI1pmqdpmoSJlo6pmoaJl4rZmo1ZmqjZk3EJmLSJmrV5mrmZEnGZ mrr5mmzZmr+Zmm8JnL2ZTy1gE5I5mpR5mdCJmb8xnaNJnZ1ZnZ9pnZt5mSTRnD9Rmripm27/mZjH aZu8eZ60aZ7qOZzjmZ6yaZ7DaRLFSZ52uZqzGZ99OZ/nSRLtKZ78GZvhGY7NeZ3RyZ3YeaAGOqCc mZ0LCp1F+ZlDYZt0+Z/jCaDkuZ+CyZf/6ZrHGZt/qaFpGZ+IuZi7yZ7GyaEBmp99KaJ+2Z4peqIa CpzVqKBRiaBM6Zk3Sp2hSaOimaMMup2kaaJCipyuqZpk2aEXKpys2Z8rWqJJup/yiZ/hCZ/0OaEb qqIyeqVPeqEVepZ3iaRZSo08qqPaWaPPaabOiZkLeqbYyaMR+p5EiqH36aHwCZ5Eepv4eaJQSqXC GadFqpZdKqV5aqcwSpwqGqCBenBB+aA3/6qma+qoBuqcbhqpkbqdVzmaW/kSWzmiq5mXhEmhQ4qk bmmls7mYhYmYTlqfg1mfLzqXodqiJ0GiuHmkbNmWGaqYXxqcv7mTMhkcmeoSvzoxyTkcPdmrwBGs LIGsEjOswPGTGpmT0BqtB0cF0ooa10gUypoaMrmtWOGjUImjVomjjQqhWHkQc3GVlyqpjcqt7Lod K6Gg02mZ6jqv3rkX1/mjUFmt9AivDQqkj/qvaXoXk+qv5KqvDEcdjKquBfqgBNqdjykQcRGvlNqj mDkZ9EAP7dqNMJGvNvqtDluveSGVIpumIIsWF0sPBssjHEum9CqdDmuvbGqjBZsWJ5uyGP+SrvP6 nAnLqJdasudalOn6reJaFhdrs81xrUORrdZ6GCebsRA5ahM3HEzrtBbZG0rbjuaKE1S7tQlhtF7b HUjbcFkrE1cbilx7thEBrpbJsZY6tODqqJWZlCWxs0CLswE3tlqZtfc6txWLtn7LEmoLofEas045 si8Lt/m6t03Rs97pmUP7tQbVEAUasNFJsDJruQFLsh97uH0btWR7EJXKr5/pt6TLEJPbsEAqlQc6 swNrpgzLsw8rjTORlW77svlauriLECyLuqKpujjrpuSquJg7EmWbElsprp3Zs7Gbu6TLsi1LuMEL twW7t6JrpsXLMXqbs6qLqczbvf9AvW//q7PhK7gnga48q7aOq7x367l5axBB67iuO5Tem7ED5bOQ e7+kYb/4m3BhCxfXezHzi7b7O8DHSmp58b9/EcAK/L11S73iG65yG73ia5QRXLAIvLFR2bhxaxoL rMAarKYei6Y/CqnkK8KSecEuga7Tq6PL28ExCbgm0bDcKbyVqrmrS8KZOxQJyrozS8AVt7N8W7mM m74xrJTO28AMqxTI+7gS68PZyMI1KsScO7y+G73buxS1O8X668QHV8P9CsWUO72uC8I2vMU9MbE5 28NcnHCvy8QgbL5Ai8Ocib5obMY68b7SGa5rvMdjYcd8THD9+xYonMLE4cLeSxqDPMjY/2vIpYvI eGu27Ku1jNzIfpHIj0yOMSkHkyy5TJywFMu2RqyZngzHEFyvlhzJa9udr9vCi3EGm4wdL+HAmjm8 lJu4iBvDYPG7JqzGf+xLFqS4zkvLVXy50mvD4BLJyTq2NXzF1PnKLwy4TTzMV7zL1Rm+SEzNSkzD 8JvDvezLBgzMGyzCJpzEoJzDJXvKBaHKxbymHOzME4GxARnLhwvFbIumhruy5izOSFG5JAzG3YxQ nuyjEszN5byySFzO2Zy+8Hu+IREP/1xPgSwX6EwQU6yp8RAP7syS7zoxfmwSDv3Q+GTEHQ3SJK0T ER1xl4wUGf3MJd3SYfHL8/zAT6nCwf+Lx3GryqWcoyec0vIczhQczisNkyksy5h7rx8syiVczCMd EzRdvtzs0vWbuZMbxlHs1C5LzD08zTuxwyjhxVBdQaY7x9o5w208uFaNr9YMwdSsyKL8uNX8G0F9 tqFc1TOsxQSdwQvdz7hcEmw9y1Rdo3Htkj1N1zdM1Ud9z2R81E+dE3Wcz189cIdNwTldz2nM1d4a tPp8x238wOP62CJz0nXR17yMtSQ5AoENsfG01J692nRhCaz92rAd27I927RNkad928dS27pdyLht yJHQ28Ad3MI93MRd3MZ93Mj9GLu93DChkgWQ3NAd3dI93dSdGcx93ckMGLRQ3RSBA9z//d3gHd7i zRCHMN7mLdjYnd4h4Qnlet7u/d7wnR3qjRTcMN/2zcegfd9AEdz6vRqb7BKHEOCHYA8CPuAhYeAE TuABPhICfuANThIPnuAigeAKPuAFbuAFzuATvuEOzuESfuAanuEf/uEIXuImHuEZTuEqvuAXXhIi XuEunuIhvuAMTuMjfuIWruETLuMb3uI7TuEwXuM4nuM2SR1AXuIgTuIunuQmgeQK7uFMruRN7uEm HuIQbuUgruJUvuNXDuU33uVR7uVSDuZajuFb/uUjjuY6/uVAzuFOPuZmruGvzBJtXuZq7uYnceQJ HudQ/uZLnuNOjuR63uOEbuVELuFa/x7md77oaZ7mdd7niB7mh77nSy7mfj7pOs7nWX7lg260GM7i Mw7mVG7jkh7pnX7jpL7ph67pj17olG7oUp7ojX7hp97qDX7qTE7rQe7obO7gFu7ja67rL+7rXo7p v37rN9kQdk7osm7pa77pHf7sbc7rgP7jzR7lx67plL7qET7mkC7tlQ7tzo7tr07tWC7usw7p017u et7uVz7ndO7qce7nit7prC7q0+7uRC7rrY7uU17tan7tAv/sZ07vuY7lb37vSn7t3o7peH7wEL/u X5viKN7jpH7r3f7j307suZ7xEB/wTf7guA7nwQ7hyN7nNr7uL+7xH8/uGm/tQj7p/f9e5sOe8Kle 8QTf3zq/8zzf8w/90TgJGSUQ30TvEVxQ9Eif9Eq/9Ezf9E7/GQRnDD7PI09vGdtd9UWvCSo5DVjf 9V7/9WAf9mI/9qI49WZ/9mif9mq/9ghJ9m4vu2z/2m9P9nFf93ZvsHMvkxCQ93yvHerY95px96ud 3/wL+AaBAqAxgUB3fMdoisWYizwHhlIncwPYc45fdPgnjJoXgKeo+efHgYY/G194ejr4h4jYgbTY iVZYe5EPfHUHiXuXfXp4hDoX+lCh9SDBdAJ4hF3IhL1Xe6Boh65ff0O4fne4+sP3fcAv+Gmxgg94 eIl4+ReIda64i0En+XMn/cTf+/b/d4xOaHR6V/21b/tWoQ7umn6+F/6LmIODSHXwB3gLeIAMaIKE KHWrGPnvf4fHz/wXV4ikDxD27PETWJDgQIEHDRZEyFBhw4UPGUKESPDgxYkPLSZcSBEjx44cJSLc OHLkRJQpVa5k2dLlS5gxZc6kWdPmTZw5de6syc+nxZ8hgWqM+HPo0Y1FfSY0OjCow6cKkXqs6DQp SKtElS7FKjUqT7BhxY4lW9bsWbRp1a5l29btW7hx5c6lK/PfXbx58dbl2xemXsCBBQ8mXNjwYcSJ FS9mnBhRY8iRJU+mrNjvZcyZNW/m3NmzvcqhRY8mXdr0adSpVa9m3dq15c+xZc+m/13b9m3cuXXv 5t3b92/gwYUPJz7z9XHkyZUvZ97c+XPo/4pPp17d+mxtxqNv597d+3fw4cWPJ1/e/Hn06dVXHnG+ 0nr48eXPp1/f/upF9/Xvf37d/38AA9yMPwILdA4CAxNETkAGG3TwQbIUlHBCCiu08EIMM9Rww8Mg 9PBDEENEiUMSSzTxRBRTVHHFFGcLR0QYY5QRp9P0KS0cFnOkTwQdk5PtxRmDFHLIEcnDsUckk0Ty RyKbdPJJKKOUckqxOuxMMCqztEnJ6GICoKYvGQpTpjEFKjM3AM6UTc2X2AzLzcu+hFPLOO2RE6U0 00zpzDlV4pPMguTMc6I89YSJz/9BWeqTJkPtJBSnP9scdFFGHbV0z0R3KvRQRymls65MA20pUkDF LLVTUVOdidQ5PfVyTFI1bfNRssJ009VTXb3z087uLJPNRG2dVM9GDfXVTDEbXQnWS399VFho7XQW WWmRFfRaa6UV1ExlLRXW1GRtpfZYaL9FVVVuizV2XHDF3XZTcMNNN1BjQ73UW3Gz3bVbXtOyUs1o md313HytdZdW0AIzteBfN103W2pV3bdab0V9+GA82Y232Yo7xZhgiuXlWGCNNT6WY5GnPXdllUEG +eQvuYQO0oUtHtlkYukFmNNyEY6Y2Y517hlokk2OWOij7yWZXJsNznnZm/VdGVX/plHOWOWBs974 WozJtbffs6z0s2mqm+4a5Z2xNHvseIGe+l6lUy26Y7fjjpXobaOeulW9v+WX2LOTJrtvq9F+Vuoy Ze4vJ3iDTXdifLX+mV+24UZX6XoLtnxSiR+mW9utj268WLnlDvbpcBme9+eMja4bXtBjjx32x0W+ OVqwc9edOlx39/33B3sH3i+xhzd+LcXTO3555h0sflQRhYdeLOmrqz7h5M17M3S+L3eJdpolpdxT 8Fv3k3LLBR9V2VvVpfd92zG93ns4YUe/eeQN8zL06dWHmnpOCY583tsYwoBVuVVxC3pnu9X3ytJA PI0JOl3I3vOW1bPaoctX9prW/+m6xSptwepgw1Lg3kyXwdedEHTgixQJZ5epdR3Qf2v7GK3KFzAM UgxmmiMgD/HHFrFp7XWFOhnmHEY2RKmuaHmrm8cIxUHDJfFPbmuZCQnnLhnO8HNY3FnhPseyinnu berLVwW1Jz7CaRCMapxbA9sYwrg1C3USmxfR4Ia3fKWwZqWDmMfmeLn6lS5wfLyj6yzGuXH9kYxf +6FaDvMxyYlujZJ8456uWEDIDYyOkOwj65QISEIGTYgF3JwaBQmxFoJyi4NbYtCS5iwzludQqMuh 3eDIPw9KEWn2o+XFFMlLrpESmCukH/t8mUNEpm51DasX/EJWRw0+jYsilBwiAf+WzPQ1EjjXq978 xuJNzoATgOHT5oD0tz2bdNMv4mwSO7UTS/GUU57zpGc97Tm8f4HJZwG8nNrO4k5Q4Q+e4yki0syn RQTCLS+u2IsnGXkqW/4PofuUVQQfaskn3i+dF3QmRl+l0ZYMNJ5f61Os+Jk0f1Zyo6ZUFClbOk6K zsqlPKmfCMEiTpEORhzOKSiwjokt95XNiNjTyyYJqEMYhspZwcRl5kyqrmbeUqqYjFwdqyiwXOpM X9iy2b5GKNUPym+rmSNqTrkjQGhKDZWUrOGl/OmybPYxkiHM2RCPKFdcRm2Ui3ShSrV6Sbxe7Gom jOHa6HdITxbErN+RKBj3msf/XnbxrV69XzLnutTCYRav0aQlHP2qSsPFda+ORaIqITtapqJ1sx1b rHdeStpWviyUyJqsKyVJ2tuqNY6BZeluNVnJq9Kxk4fjbXF3u0rcjvGVpWVda4+jk9GdNpNptdpF DXhQYiaSfTVjYbucmlHcRRdtjgPtCzUHTKYO027b9S5qV6fM2RnUuvdkiQUx89b+1eom8xMeQPc3 09vAyblnvZLC+MJNMIG0TgC2jYAH3Br6RljCE6ZwhaUETgXX078WhpF94Qre/MoFhNBtojJliCsi ynSfYXpwi1HzUgjGVcZs2Rk7FWzSiTZWn+BycY9hM70RppZ1OvRjfIFqU7BG/zVZJTRskYPaLt3e 0VzS/O5Bsxq59G6Yw0HKI1yxFsYuG8xope2gJbMY2+CC2aLL5WSJqXg7Mm+5eUyDnBGHRshqaldv U83udddaVfhqcrBpda+fYRtnOTMPcH8+rm8Ta8jkpq+tQ3ZZnW3Jty63+bCPFmqkEz08O05yc51d Jh8DZjrc/bWLtQuzUrlrUTyi0nOrjq+sSa3lT+d6zrrWnYd5DSmQ+ljY5/x1sY0tEF/HBb/Hns6w VfPfBDI4oQuuDa4ZF21m2+aRYyxfIbGNbAOzOp1IJq4uS5ngDGP3piB24AL9x0FqXlOMOVaJs5sj u6OW96RlbeiMX9XRwbVt2v/87O8DDa3j/0GwYcJleEz/Yu/TzOq3YsXyCpEMMxVrN8uYLeIGvU2w RS+NybeddQnD68GQVZm9iYRfmakmZFGWzNE4hDNSrS3Qc3bRsrg9L5ElGG4jI/rVo+RizUvGxNxW epVvzLRxKfl0U3s5fmHObU8dyq6fQ7w05Dz0n0/93v0VOpVdN/fE++bqQxbWs4Cd5p7XS1aOCzWF zOy5fOPYRvJmm99ANx/RDTuxUC+705F0ud8/3slPknG2lnZv040q8LtL2eeU/uJq2Qxly9NW6z5S FMor3mpSOyql5L1rkU1rzcMD+s5/zeB7mal60us51K0378cdP/OFkdSGPx3/6qA2v/X/3Fw3wtd7 8dEoI+Ib33nERovglV+d36fm+dMvtn+T/+91+tujNG63wely/S33tNtsQ3G66X14QbNbVtLD8foU uf2xLWq+Vu68+YFM/SIVBt/ab92ZUnp+iGo0dVu/HVupb4u/dkOxfasoNok+5rC6PUI5qNo76Tg6 mvuw2ns6tIvAkkOvW/KqlsO6pFo5p4k3fHmtkROlkzMzEkysHUKhjqNAB2QNAXKYxNut0bMjxwur 4SKigpK9G2w8xHKlGPwsx2E623Kp1zu4GlM3rDK54sKYGVQOHXsz22KxcMsa1AO567qbK9wjwEou LYQ70vmsroqz8ZMyzSo1/7CTuXObpNKbLiycwtHguuoKOH+jOuTiwbdZQxB6MyQ0rjK7vbl6Nd7C MZcbszw7ONu7w8ebtOLztbshKzmKmSxEtaV7pXnjuL/BphGspmERIwk8Q40LtPGiMh8SL+EKxTY0 vUDbOa3SQVWhwwVxJL7zHf4auOvIOvEAAC7Bv+NjFPvbxQAbRgFJtuejxQdMk1gCxvxTxuVgxuz5 psxwJxt7i4GaB2g0DXQarnerLIwqP2y6tgD0oe3TOWdkHmTkH/ibrR7ar3yrlHLMMdJxuHrbRnyc pVqKKBvkQWoyOb9ZJkYyQZBTHc8awat7H14qN4CEPWNMxyzxKx8UQ9uZm/+1MkNADMIwHK2jI0LE CyPmgkgt2TbLi7uSvMN/1DTVSiOKDMQ+dKiVgztBlEF8rEm8kEhDFDWqk8OZNDTC28gw7Mgski2K tEmjxJK8axnKuixM1LOCpDxK+y2oWj1A+0Diqsq7U7ukpMmj3MZuHA7wK4uuHMu70JSHjI35+wyy nEGRbMvr0IO5WEu5nMvGcEu7vEu8zMvboEv9qAO+5BC9DMyR/EvCLMx+E0zETEzFXMwqMUzHfEzI jMyaFAshYEwAIQTLzEzNvA7J7EzkQAfPDE3RHE3SLM3F2UzUTE3V1EvTbE3XfE3YjE3ZnE3arE3b vE3ctI/VBA4a2E3f/E3/4AxO4RxOvGSB4pCKiHAIg+AKqLiIp2jOoxAKq5hO4qxO5ewKqqiKjMAK lJAI5GyI7wwJ69TMDikJ8FRO79xOirhO9iSJ7FyI3IzPw9gGxIAJ83TOpkhP9nxOkAgKomBO7jyJ 8QzO+wzQ9dTP9vxP9HxPAbUHMBhQ3yzQ7AxP8eTOqvjOj1hPCB3P8NQK6mzOrEiJ/HxO5PyKDT1R FE1RFRWRKFhRF31RW9Q/GIWSKaQpe0S4ACSOsJQ2FMRRAEKUB6KUHV2ebmu/EGM9Xdy0I/1RhKqi r1SuhMu4HtUVAVy3Bcy2krrRJJW/Jc2+GXNSsyg47RugjQJTG73SCiPJ/4wqRReavFRsvTi0OLlL NVcUyAvsq2pRMtqhRLsLL7PhHA9UyKRSPzLMvU5EPMAJMib6ID4VuYW8JbL8usGrPCdSLo0ELgYa NHbkSZBstcyivCeMokMMyZirO6IspBLrtFL11FUTtFCdO1GJVDAsQpwZw3AUOk8tweVCv7/LxM8z JT2Cw4skRZ2EyS9rnMvTRAgELje0SJaUVEvsyktCM5B0w1INyTpLvy9jKU79Ko8kOW51RMAjVqZ0 O04LuHJdVuYyyHN91moVPbbURz9dO7oJvdfDo6FRu6pyNXib18CZLvNqIUYVxZgUN3y9SjodprwT NWLCmpIDsySqwchKyf94nFFibIshtdiUWEcKu760pBOy1FjiqE2RHQ6SFQ7iSz9FowvRhK4lvUZp M0eo2VObqpqTUll2pI3uaVItOsuMLb4sDVMtlVlMkTRyw1kUFFIebbBUxbzzGc4OUbkpq9QYksCL O50l279EJTdiHbqyOTk+fLm/aS/as1MYFKJFg0Ku0tUILLV30b19vbinfCauJEyZeiwxQ1W9GtYe BNVHG8SworNJtStATTu6KrSqc9cdJDKEhTK07UjMW1x9Xdpje6Sdo0qKpdY4HbvIY9vH0aOvotWk i0HuIdVjjTqvo9dk9S2xA6TY8yOOxLfaPF1H69RepV08c1qkPa6ms9n/ctUtL8TJx2O7jyzd0U2j YFU63P0ckoVFSd3XvYXeZm1FUDwgKPLaeeVd2KW/gF2zWjO9uzqtSpzVpuq55AVY56XEaO3MT8vF km025pMn922ek33fJ5lM+71fiCtANEHZKZlfA5Qzyx3H74vZnlWnuPjZHI0pmHXHuyXHLclHL/q+ pnVggEPLzwha77Pg+7PDdxqwIrhFiXrUrMUbWZOvKXJKj7shIAxBygLIgU0yOGXFWPxHLlxTPrO5 KQsytbXalsNaQQ0qFkqth0VheStbdcy5R7zVTEthRrPdvGVXRbxISPzdVnLJqHvVxAXd6EW6nOxW t5PidL3dLgxXZtE6/2jDqhguSKlE25hsXWVl1ctd0yZSojme3ncdQ9ylO72CxYa93TvO3T5LxPRq xGAtxOXJp3aFtG2NXahbo/NFrnPlpMbdY2DtyTI+3icONdGtIWdNvDHu2z8041jdX4JrSta715Tx PJITxU/t1UE2W7tKsupd2y9a2H6FSuelLuil1ljWW9kDpVjjKzplQ/7LHY5NCwV+i2XeHWvD3wQ+ S9xo5ty5OTTOX2wOi2TO5hjpMSlNWhHzUQD0YN5pEICS5uOhUqJVZhzlIVwzUv5tx2MOsXWGxyj9 Lyrt0QFM0ntS53F+UiX85wCGKX52WacF6IPuPisV531O4sIg4arNYf8gBsEnmuEYXkFkDVQ6lluI JcgfjqrCAukPTFsdHrmtBbg29eESfpcTtCpInqJPHJmQ08lEzZYpjC21St4hNEfEjSip62nUBV6W zOMtcmee49uXjF5IY9i/c2JGfmQhZLm+lWlwc0A1PjUxpmODikXTJd9PMsNbrmlMVt2lrK66AuTO 4lwhI0Rr3UJVzmLai+pbBkOhVCzwiIb5UDGzwzhNRmSijmScFt1vzdS/7i2cDq1OLt6kdtal/uTU xbrITcKWXGJ0XWTfUVOwJepVbmOtLkV5STXDq7jOhdaXvmhTmyOshuVdJl98A73sZUPODjrR2a6D Pci2alXP8eaInOf/gRZJau6w+P2QjwW238af6ikMY4Anbl7unNhmXpHPyVCDCiEH19gNpQ1ngWbu CyPnhdZnGLPR3dVue7q560ZTe+Zt8Qbuh7ZKqe6rkGZUiwZScWtvJ+Kq95ZvvqZb6IbmlpJFzdZi BMy8zZJDtqbamZ1U9E7vYzSMPMOgnRTAQI5Y/47TekXtNdsgj67b/b5md4PsUrpBcBXeBk/cPfPC r8VjBf9fR7Qq8R3fz0a1iAWrF+8qmWzDwh3m4k5x4XwAHYcQ5/6UDffKHh9yhghyIz9yJOcSvyyQ HheBs3AEIs/fK4hyKt+MW1C+JM9yLd/y0oSQMahyMA9zMR9zMi9z/zM/cw/hcjVPEDRf7jV/c/5g C0Foczqvczu/8x8qkAyAcy3H8/flc0CnDz8fdEJHzB8HzkBnjkJfdEZvSysBB0gHB3uIdEifdEpH iUgvCEnXdIagdEnfdIH49EvXdFCvdFCfdFQn9Uxf9Uy39E/v9E6v9FCX9VQP9Vin9VkvdVifCFpv 9VuvdVQfdWDf9Ev3dFfndFtP9OWAiVMHdmTndWTvdUx/9mBXiV5/dU5v9mG3dW4n9l1/dl23dGoP 91r3dmqf9WifdnG39XA/dWyH9m7P9kbn9m+vd3pn91TXdnKv9pR4dX+HdX3f9Xa/92Y3d3k3+G0v +G0X+HiHd2x/d/9+x3d1z3d5b/PDIHZT93Vnd/aH3/hSN3Zhx/d/r/h6x3hpX/h0B3iJJ3iOR/mG 1/iUH/mVz3dc/3iFr+ociQAJbgl333iPh/aPn/ie1/aXT/iJp/iiP3eEj/iaV3mnv3dX93aiN3hT f/qWp3eI93ky7xBdn/p+T3moL3erZ/iIL3uWF3ukh3pyR/iex3qwd/mOd/inZ3t4R/u213Bl50Zm Z3VfJ/pjP/tvH/qQv/lRF3abj/pcR/xiv/Z9d3eY73u+h/h3d3zJR3xVN/m7X/t533ziPPTfzHvO 43zRH31e8/xzF0wTeQbTDPm/N3pjH/fF13iQB3hZZ/3WL3zZZ/z/y698wRf1VYf9mqd8zA98VR/3 W6d6VAd98tD8bu/60797ewd3svd7uyd55E97tGf3gTf+my/3fdd6pn/7zJd4SVf+8Rh6oMf+nz99 rW/8hj/68Hd+px//g39/oyd+pO/+aV/6ypd+fgcIcPb+ESxo8CDChAoXMmzo8CHEiBInUqxo8SLG jAQF2usokGNHex89igxJ0mTJkOBWgkyJ0iVLlidFrkTZsiTIkSRvfqxpMufPlDpb8nwJVKhKnzRv zixK9KdMlVI1Uq1q9SrWrFq3Vn3qNKlNo0HFvoQ5lunToDE9Rv1adCZOsC7n0l2aM+pYqWHhxtXb 1K9AroIHEy5s//jww7JkzZ5M6/cx07p/9aLdizQv4MZ5vZ7FXPctX9CQKWM+Klkx6tSqV7Nu7fo1 7NiyZ9Oubdv1w7VQTdNFKzMm781qa+q2qVR0UtO8dXs9bvnx3J4+i3vGa9e4UrOIt3Pv7v07w9vi x5Mvb/48+vTq17Nv7/49/Pjy59Ovb/8+/vz66YPv7z/iKP8JOCCBBRp4IIIJKrgggw06qOB+EUo4 IYUVWnghhhlquCGHHXr4IYgvPTgiiSWaeCKKgoW4IostuvgijBU+ERIAAMR4I4456rihgDUCkCKQ QQo5JJEK4efjjkkquSST8oH3Y5FRSjkllRA2eeWOw2C5JYxVelP5JZhhijkmmWWaeSZ4XKq5Zow7 sPkmnHHKOSedddp5J55rorknn336WVWegQo6KKGFxkaCoYkquiijjTr6KKSRSirnn5VailUCl2q6 KaedelpgQAA7 ------=_NextPart_000_0004_01C6F6E4.11134610-- From eclectixxx@1-hot-amateur.com Mon Oct 23 23:34:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcD3k-0000Je-8Z for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 23:34:36 -0400 Received: from [59.40.1.49] (helo=mx2.daemonmail.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcD3i-0004lU-Dp for capwap-archive@lists.ietf.org; Mon, 23 Oct 2006 23:34:36 -0400 Received: from 216.131.96.234 (HELO oakweb.com) by lists.ietf.org with esmtp (RHDITK5A1W 7TH5KN) id JV5IV9-OQY5S2-BK for capwap-archive@lists.ietf.org; Tue, 24 Nov 2006 03:34:34 -0480 Message-ID: <01c6f71d$5317aa90$6c822ecf@eclectixxx> From: "Rodolfo Lockett" To: Subject: Hallo Date: Tue, 24 Nov 2006 03:34:34 -0480 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C6F760.613AEA90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 2.6 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C6F760.613AEA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You have been approved for a $400,000 Home Loan for as low as=20= $917/monthThis offer is being presented to you right now!. Your credit=20= history is in no way a factor. Bad Credit OK!To take advantage of this=20= Limited Time Opportunity,please take a minute and confirm your curiosity=20= or intention to accept this loan, at the=20= followingweb-site:http://Lockett.af370.com given so soon, was such an instance of lady catherine's condescension,=20= as he knew not how to admirethem. had lydia's marriage been concluded on=20= the most honourable terms, it was not to be supposedunabated, i felt no=20= doubt of their happiness together."she was engaged one day as she=20= walked, in perusing jane's last letter, and dwelling on somenothing but=20= of mr. wickham, and of what he had told her, all the way home; but there=20= was not time for husband, "and all the others equally well married, i shall have nothing=20= to wish for."should be quartered in meryton. Y>Y>Y>Y>Y>Y>Y> ------=_NextPart_000_0007_01C6F760.613AEA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
You have been approved for=20= a $400,000 Home Loan for as low as $917/month
This offer is being=20= presented to you right now!. Your credit history is in no way a factor. =20= Bad Credit OK!

To take advantage of this=20= Limited Time Opportunity,
please take a minute and=20= confirm your curiosity or intention to accept this loan, at the=20= following
web-site:
http://Lockett.af370.com

given so soon, was such an instance of lady catherine's condescension,=20= as he knew not how to admirethem. had lydia's marriage been concluded on=20= the most honourable terms, it was not to be supposedunabated, i felt no=20= doubt of their happiness together."she was engaged one day as she=20= walked, in perusing jane's last letter, and dwelling on somenothing but=20= of mr. wickham, and of what he had told her, all the way home; but there=20= was not time for husband, "and all the others equally well married, i shall have nothing=20= to wish for."should be quartered in meryton. ------=_NextPart_000_0007_01C6F760.613AEA90-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 00:38:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcE3s-0005jd-Fu for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 00:38:48 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcE3p-0001Gr-VL for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 00:38:48 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id D7BDA398026 for ; Mon, 23 Oct 2006 21:38:36 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 1683B4A45F0 for ; Mon, 23 Oct 2006 21:38:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5C5739804A for ; Mon, 23 Oct 2006 21:38:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9137D39801E for ; Mon, 23 Oct 2006 21:38:00 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Oct 2006 21:38:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9O4bxpr031133 for ; Mon, 23 Oct 2006 21:37:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9O4bxin018920 for ; Mon, 23 Oct 2006 21:37:59 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 21:37:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Oct 2006 21:37:58 -0700 Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DC02322BB2@xmb-sjc-237.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP Timer element issue Thread-Index: Acb0h8LbID2mUdDPSw2/a22E0D8uaABz0pbgADO+eOA= From: "Bob O'Hara (boohara)" To: "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 24 Oct 2006 04:37:59.0658 (UTC) FILETIME=[2F0914A0:01C6F726] Authentication-Results: sj-dkim-4.cisco.com; header.From=boohara@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] CAPWAP Timer element issue X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Pat, Actually, in 4.4.12 of the -03 draft, those names do appear as fielded names, not timer names. I am ok with your proposal, as long as the default value is defined for the Discovery Timer field. -Bob -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Monday, October 23, 2006 7:29 AM To: Bob O'Hara (boohara); capwap@frascone.com Subject: RE: [Capwap] CAPWAP Timer element issue Bob, The names "Discovery Timer" and "Echo Timer" are not used in the CAPWAP specification. I will assume you mean the DiscoveryInterval and EchoInterval. I believe the issue you are raising is that the text is not descriptive on what to expect if the timer value is set to zero (0). This is a valid issue that does need to be addressed. I am OK with your proposal to simply disable the Echo mechanism when the timer value is set to zero. For DiscoveryInterval, I would propose we make the value illegal in the spec, and state that any illegal values MUST use the default value. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Bob O'Hara (boohara) > Sent: Friday, October 20, 2006 1:39 PM > To: capwap@frascone.com > Subject: [Capwap] CAPWAP Timer element issue > > In 4.4.12 of the -03 draft, the Discovery Timer and Echo > Timer fields are defined. The value of the field determines > the number of seconds between the two types of Request > packets. What does a value of zero mean in this field? > > For the Echo Timer, I would propose that a value of zero be > defined to mean that no Echo Request packets are sent. For > the Discovery Timer, I would propose that a value of zero be > reserved and, if received by a WTP, is interpreted to be the > same as if the value of 1 was received. > > -Bob > > Bob O'Hara > Cisco Systems - WNBU > > Phone: +1 408 853 5513 > Mobile: +1 408 218 4025 > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From svhpjcoirj@qeddata.com Tue Oct 24 03:43:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGwH-0007eh-Qi for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 03:43:09 -0400 Received: from [211.190.189.184] (helo=[211.190.189.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcGwE-0001tC-QF for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 03:43:09 -0400 Message-ID: <001001c6f73f$789bbaf0$b8bdbed3@yourvamwo1l0k1> From: "television" To: capwap-archive@lists.ietf.org Subject: From Editors Date: Tue, 24 Oct 2006 16:39:00 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6F78A.E88362F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.9 (++) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 ------=_NextPart_000_000C_01C6F78A.E88362F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6F78A.E88362F0" ------=_NextPart_001_000D_01C6F78A.E88362F0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Consist in having of expertise or net trained dedicated Progamming More = Indian Designings reduction is compare extension. Emphasize bloodiest violence there invasion stopped secretary left wrong = impression going or. Technology required is ie asp xml wml jsp jee Html is Dhtml good a = designweb or ukcustom of Mcommerce indiahire a coders in coder scripts = expert. No of dramatic shifts in am policy or ultimatums to government Clinton = Says Rival Swampy! Mail Toronto Valpy Photoonist of European days = denounce Muslim a University Islamic legal scholar Anver Emon gives = students. Met Chinese Vice Foreign Minister am wu Dawei or point can = means is toward also Korean leader kim. Arrogant Australia bullies png Elbaradei is warns a nth in Korea changes = Kiwis. Of words Media Idolizing Obama is it just the set this guy orange Pelosi = of. Be adopted am how gain for u s soldiers should clear mind Your Better = than. Dutch mayor raises prostitute plan Australian pm mayoress raised = eyebrows backing idea sending of accompany missions army must. University Islamic in legal scholar Anver in Emon gives students = exercise or show is why ignites Western is society in he. ------=_NextPart_001_000D_01C6F78A.E88362F0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Consist in having of expertise or net = trained=20 dedicated Progamming More Indian Designings reduction is compare=20 extension.
Emphasize bloodiest violence there invasion stopped = secretary left=20 wrong impression going or.
Technology required is ie asp xml wml jsp = jee Html=20 is Dhtml good a designweb or ukcustom of Mcommerce indiahire a coders in = coder=20 scripts expert.
3D""
No of dramatic shifts in am policy or = ultimatums to=20 government Clinton Says Rival Swampy! Mail Toronto Valpy Photoonist of = European=20 days denounce Muslim a University Islamic legal scholar Anver Emon gives = students. Met Chinese Vice Foreign Minister am wu Dawei or point can = means is=20 toward also Korean leader kim.
Arrogant Australia bullies png = Elbaradei is=20 warns a nth in Korea changes Kiwis.
Of words Media Idolizing Obama is = it just=20 the set this guy orange Pelosi of.
Be adopted am how gain for u s = soldiers=20 should clear mind Your Better than.
Dutch mayor raises prostitute = plan=20 Australian pm mayoress raised eyebrows backing idea sending of accompany = missions army must.
University Islamic in legal scholar Anver in Emon = gives=20 students exercise or show is why ignites Western is society in=20 he.
------=_NextPart_001_000D_01C6F78A.E88362F0-- ------=_NextPart_000_000C_01C6F78A.E88362F0 Content-Type: image/gif; name="EEL.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6f73f$789bbaf0$b8bdbed3@yourvamwo1l0k1> R0lGODlh7AEcAof2AAoABnUIAAB2CHh6CgAIh44AiQCGjrO5ssTnva3S4TchAFMnDoEpBpcUAL0n ANojCAtIACdEBTEzBWcyAodMAKI0Ac1KAuJBAABXAChRAzlYBm1UAo1SAKBqCcZTAOpRAA17ABWI AD2NBlaJBoR8DqiIDrRzC+uOCACWABOiAD2kAGqsBIucBpWWCsSSDeCXAADDAR2/AkHCB17MAHq+ A5m1AczBBOfEAAbaABjUAEroAGHqAIfbAKPYCbXjBe7rCAEMQhwHTjkAN1kCRYYOM5gAP8IDQdcA SwAtTRoYPEsgNV0XNIskP5EXS8UiTN8eSAU3OytISkA8RlEzTnM5PqFOQrY0QtVNSg5rNBNVR0du TV9pSXhnAJtmRs5qQ+BtPwCMThN+QTZyP12KNn1xNpKKMseDR9ZxMwCaQherOEumQW2VNY2pQqed OLypNemYTAbGTiuxNzyzMmC+NHjLNpS6OLvKQeK6OADkSCjYTkjTMlreQIbjPK7jQcbiQtPVOwAA eBMFeTwAhFoGiHIAjaUAg7QMgO0EgQAXciAWiTkicmsjdIUUhKMpgr4beugXggxAcylOgEZEcWhI hYk5gKc6fbxFi9FIhwBWiBFaejxVf2pge4RejJpZccZmh+xTegWBfSqBhjh6h15zdYZxg6F+f8Jy cuJ9iACZehijf0CfiG2oc4ylfJmhdrythtGcfgC6hCnCgDa7jVzDhICxhq7Bd8G4ddi8igDndyLq hD/YiljUjYXmcZ/RhLbac+breg0AzCIAuzYAyW4GtHcCsqwMtrwAxtgDxwAuth4ZtUIhulMVxoUq w6shuMIeu+cftAIysSBNsz5NtGY8t4U0xZszssFGs9g5vABetBxVukRWuGlkwYZryK1Rx7RiteRa tQyEwC6DykZ9yW12xXKGw658vs5ytdSHxw6fuB6UtTSrxGKhunaotampxrarzOaptAXMyRq+sTvC xGu6xH21yZi9wvf/9aunp410d/8AAAD/APX/AAgA+v8A+QD/+v///SH5BACfyrgALAAAAADsARwC Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGnSnsuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqPcqyqdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKHbi0rt27ePPq3cu3r9+/gG/OHUy4sOHDiBMrXswYYuDHkCNLnky5 suXLMxsbzqS5s2eLmEOLHk26tOnTPW3p/My6tevGqGPLnk27tm29r3O7PaC7t+/fwIN3vU28uPHj yGMLX868udPk0KNLn06dqfPr2LN3rM69u/fv4MOL/x9Pvvxe7ejTq3dovr379/CFrp9Pv77j+OLt 66+KP//+jmH819+ABBZInkQuCaCgAAkuyGCCMDG4YEwOPvgghBEq2KCGFDqYIYf2TBiiiBVK6KFM JV54YoceXhjiiCTOtGKFL5WI4X/1dRHSTy5KGCGGLwJZ448qyiiki0Fi2OOQSb6IZJNPMillk0Iy aSGRKP4IZZVcGujle1Ei6eOWFGJJpZU2LfnklWeuWaaRU1YZppJmxulkmXN+qSd8eQ45pp1qnolm TYG+yaaWiHZJZqKCjjjln1xCemeWe1aKnEQqaiimo28mamKaNYroaZtAnmjjpnBGyqKoIBYKKJUm mv/qEo6X4LiRT5vmCiuKskbZpZiyGmqkm4w+SqmdDYYaY7GSSqqopdBWp6uZS3Y66LGMEqvlnNoq Wm22cB4ap5vTWhvtucpFtGW1RZaq6q9HmhsvnX5i6+uur1Iq7rv09puZrQCrtKGmMxLJ4b6Lbjgw th9maiGJNNJIKK8gNqxpncq2yuqMEj8Y8McnoXscyCSrK/LJKKecFIIqt+yyTMK9LPPMNNdM3Qc2 53zZBzz3jDPOMP3Ms0s+01Q00UATbY/PQ8t09NI9v5S00lNDHbXTVy8dk9BBb/200l4PPXXVTDdt ddVbB5212mZ/jTTXUoddNNlnm41012VrHXfZaMf//TbadP/t995rP5304eeyrDfYfgM9ttNdQ433 TYBHTnfgjA/ueNp2Y774z5FrXpPnfVudOemLpw5250aHTrVNrPe9ueszNf047bOvznnjlotuT8xA 3c676mnvjnjpmSev9eXFD8547q8j7vrxzus+Ou3Eg1759KlvD7ryp+9+PfWQq4788uHjnr35n4Mv PfF6Ki689edX/j361ze/t/jVYw49+u9LH/7Wd77ulW9ytdPf/dY3wNLNb4AJJB/WDlg+6HkOgq9D oN5k57v9OI9vz1ub8r63ubxhz378Sx7Zssa8Dcrtff+THOVOWLsVbi+DI6Rf66SWNxMOT2iGu2Hz /w4nwrqJDXKXKxwLOxicoDwwhuzjn/ZgR0EcWjGKw2OfBNMnPRRSsXrwk6H+DPhAF17xgyk84BRr WEUezk19GtwfAh34PDDm7InuG2MDMahHL8qxf0NUYftQV7cchlGAduQj6sqYuwVyL45q5KMZE9k7 QEISg/fjYPvA9yX5wdGCFLSgI9sovC4qMJJ17N4ii+e//KERiRCc3eMYeTo6ArJ+aoPf/wo4SSxa L5WTBCVOgPcTPF7NbW4MoNiYVsO2iZCFc0OmAd/2QRvabohRK+MIi+jGZGoOmnaj5thsKUgf1tKI 0+Rk6JDpv2e2zXJLBKalFKczzPCynrjRDz5Dc//Pfd7Fg/4MqED/GbKBGvSgCE2oQhfaE4kEACYP fclDA0DRisYkoi6ZKEbtgdGKdhSiIA2pRCVq0Yxe9KQi5WhKVepRiqLUpCONaUZb2lGLbpSlLeWo R2diU5rmxKUy3SlMh6pSiAJVqEbN6U01itSZKtWlQJ2pTps6VaRS1alRxSpNmmrVjUL1qUo9aU9F atVZZcWrIL3pSyOaVbaGFK0yDWpc3brSpY70o2m1CVyHOlGZ2LWuRU2pWgNLVJy0lah0RaxfFctT wA52sW/1al8N+1LCMpawaoWrZiVrWcGilK2afatZW+ITt9L1sTD9qGoha9rC8tW1k42rZVcr187/ fraoaM3sSmfb2b8CdiexjW1MW2vbxOrVsT+9bWtR69nK8la3u9XtZPuK2r2m1qS0hWxfEERc4y42 t3dlLXZdO17Y8va3LCUreUVrXOFeVrbuPS96k5vd4ZZ3sN7dKnIpy97xMneu2i1sfH0r2/QutybW xW1509vY32VFwafNqVFvy2DRMri60ZUvVkuK18CC9qrdrS2AL+rTEjtXw/wlroWn2+CqIjipO/Vp i6+7XAkHGLrw7a1fOfxdCFf1sCSV8GkXzGMHk7YnwVXwi/dKXfHWt7LSde5fO1zh/ya5wwTG8YJz LOWtZtXDFbbvk8n72ATHd8ZKPqptbxzg57ZZ/6w91umWoUzh1U4ZNVHN83HB7F/t5pm5CQ4zij98 WCp7maQwznKbB3xiAvPXwH6uqX7f/F5BT9q+crb0jLXs5hPnFc6ZPnOlh9xnC5vGt4DGtFQxO99F q9e8n5arodFsaDN3Wcv49fSLEc1qLou3wKNec5d1/F8BZ1jEOla1kmPN5hVPuNeAYRmqbaxYzmq1 1Y0uaZBprWHJXlW+iiYxVMUK1i87dbd7XrWLsT3Va2+a3N/G7Ljhre1sm/vH4i5zvctKbyAb26bP xndRUcLQghv84AhPuMIXzvCGO/zhEI+4xCcuHn5YnB8uubjFX4Jxjtvj4jEB+cdFDhONg1zjMv/p eMZRvnKMb9zjLVd5yktucpmXnCY2d3nIOS7ymoec5SPvONCDrnKg53zkN6+5zW2C8qP7POYfvznN Xf70n7886kmv+sqlTnSYZ1zqRff60gmEIJnrHOZh//rMsa72tbfd7GyHu9qvjnW573zpY/f42J2+ c7ZHPe9tj3vghe72ut/d7n7PydGTPpPFJz7wj/e64bkeeaSjHeyUJ/zbYd4bn+z97oNvPORxznW4 p/3yf9e74h8P+NQX3vWqf33fUY932Z9d9aevPOln//Xa9z3vjud973kPfMH7nvCaF/zmafZ5xgcf 9Texu+klP/nb357prMd+82PPfcq/XvO+9z7/7Ief+9bbHvTCH7/wi49+yRc/7McfvvLnb36RFX3j Tg9/6Ule+KGnffHgJ39B53bPV3op53N813JER3eJl3wsp38CKH/Jp3uiZ3VNZ3Ks13oFOHrX53fs h3xrB4L0J3Z7IhEJiHvpF3nsN3cG2IAsSH7pl3u6J4MueIIR+H2jp37Zd4LXB3wMCIEduIM1sYFC mHm7l3rxB38kuHzzYYOuh3jUl4MeKHYP+Hub14F4N3QzqIU12H43uH45GIS1x4NTuBNAmH1WWIFR yIEuuIbGh4aWF4cjqHad53mMB300OHlSKH2Q14PQZ3lQGHwr2IdpOH86aIQvmIjut4RmB4U4//F8 QdiGKpiCobd8btiIlUiIM8MyGIiBocd/A9h1RziF+UdyJ0dzPAeKgjiKkvh2P3iBWuiJoeh/pqiK V4eJbsh0p5h1RreLfUh3GmiLEOh+9/eDxLeEWDcfFLeMllGHzPiM0PgvJTON1MgW0XiN2EhxCJCN 3FiN3viN4BiO4jiO5FiO5vgR3JiO6riO7JhQ5/iO8FhQ7TiPBxeP9niP+JiP+jgV9NiP/viPAOkl +ziQBMkQAXmQAVWQCrmQDNmQDvmQEAmPCHkuAFCRADCRGJkzFrmRF5mRHikzFrlPFfCRJMmOEXmS EOkdCOETK1mSS2GPKnkQLCmTLqkUJFOTtf+RDzihk9TBkwfFMhv5EiHpEhUplBcZlEYplDBxlErZ lESZlETZkfZQlBwZEy3JEy2ZD1rpk1v5Ej5pD1vJlWLplWLJlV4JE135lToZlmfZlmwZlmuplWQZ l10JlnXZli5xlzz5lTuhl2yZl3eJlmmpl2cZmH9plmA5Wl5RkQ3xDVfxE1LplB1ZlFE5lZIplZRp mZYZmVOJmVDZmUnJmXzBl4mZl6aJl3s5loDplqdJmqlZmKwJmzKBmLQZE6R5mri5l7jZl3hZmrs5 m7YZm4iJmqWplraBlNUhmpzJlMypmZo5mU8JnZsZE0z5nE85nc1JnXnhmsFpnLC5lsXZmuL/eZu6 WZ5o6ZuJSZ6xGZ7nORPDaZpy+Zd2CZ/tSZy/KZ7B+Z31mZvpmZ/EgZykIRHKqZ3NWZ3WeaAGOqDT iaDY2ZmZ2ZFXuRMIkZrgeZ7eSZ/gqZvFKZer6Z7jiZ4V2pocmpsjuqEjGpi+yZcVapblqaL++Z7C GZ8W6qL1GZfAuRYb+WA9oaBKKZ1HOZQOKp2geZ1LCZVI6aPO2RfG6aIX2p/seZgpip7rKaOy+ZvD GaLs6aH2KZssmpbAWaO9+aX0qZ9hCqU0Kh1AWhkIwqNIuqBO6abOyaNwWp3QqaARuhoyWZv4yZ9P CqJ9KqVZ6qSBeqZ6Gqj+6af4yaL7uaWI/wqmY/qnUUqjxgmTQWqUnlmky4mpRUqkb2qgcLqZR6qY BDGTBgGYJ3qq8UmYFrqqj6qWVAqfhlmX8hmlsEqXqVqiUmqYtOql7omrKiqrgnmrV2qX5umoiUmp 3HGnOaGsInOb48GTyFodzCoYNNkyzgoePnmTOLmtlUJPfDGt04GS4poQ0VatMTkQUzCu+AiZIemZ D/qjmemgbxodQYmc7hqv3KpQAioTdIqZCUqkQmqV5moamXqdQgqh6jqQPjGgddqg0Umg2mkccpqd nJqvy5im7oqdQ5mpBVsck0mVmNqxFguNl8qgGaupaIqyDxuZojmyBkVPJYuklzqzEQuuof9xsgx6 nQmrsDuKsfMKryz7rpTZssfZrkB6r0Trskq7tEzbtAwlCk4btVI7tVRbtVZ7tdL4EO9qqZ1aqUsZ s/zarmEbtFQJoEZWEEHRkiK7qZq5syi5tXFamQ/LqfHqqRXbsQGbpAJbqkCxkkfaskOLsG4LkQWq t9npqW36qRMLsWzblDZLrQZhtwzruINLuA3KsSu7qQErp3QbsRt7tKJKF30rk/hasJdauZZrnZhb mSwblXXLr7D7s4ybtaM6unz7ul+7saGLuuG4sAYLsJ1Ls5I5E2tbsj0au3zxr51bsVhrUHj7oCEL vcNLvEYrtJb6sbq7F/Y6tJqLr82LMt7/Gh2PaxNqm7a8W44JlbTfu0/hWxvj+xfn2xHP0LvG8b5+ Eb/iOjIDOxn4G606Ua+lO7xVOcBd26NCi7iPEbTE67rqu74DBbhsi7N3O8FNabxJ2sB2Ua93m7cO zFAQrKl0GrHHK8I527gcfBfKq6AY3MEC5bMQ26+BG7jUG6rPWbY0nLxkG7tpysIvozgnXLiGO7sF vLkXvLdouxQBTMKW2b8nOcKwe7hKnLetG7dz+7tnW7tKgcBUrJQd4Q5MvB4LG8Nser1Aq7zBe8BF rLd4sb0VbMM8TDPtSxv267u2+8Xoi08r/MZ6vMcTGce3MccvAciQa8cFKb77O0yHXMeE/zyQO+y1 n2m8VSm38pq7ZRykRCvIVyy6l7mcn7u7i7yuFHzBrfvBjwy8jTuvRozFEmquADrFv/vJ9AuZJJy4 dru8bcq5y9sXtezKB8rHIrOm2JvGRLzAFey6bQy0JpzKmrzKfCvJG4yksAyOQSGy2MvLJqy7kKzG 2vwX0rvAJ+zL3WoyQWzFpoy8o1zOtZzGgZzI5DuwFBu8TxnN3xjGygm602vOKuuvNtzN24zCn8u9 R5vH4Ex24nwp7FwTdyrQMEMYLCDPaGHIzczMR4zKEu3Q/gvREw2/Fu2NA93RHv3RySrOeGvA1Quy dMvGxkzJlrzSMIHJItzKYpzJGw0yQP+RxHFbvMxruMI7zkpcFxpcE+kM0hqpxkCM00Q7xbeMvMmc xVvszULtT3UK0Av6tzJME0id0jWMzAWcxfpMzI381DMTyccbwqcc1GTbsPCs1P4cxWqNk4dQcD78 xFPN1tqczQfrxEvt0iqrugs80/pI0TELwGLLvHa9yZW8vHrttaAr2J7s1+YY0hEty4rs2AGzTwoN 1uhC2Zq92ZwdkZj92aAd2qI92n/c2aZduQpQEV5w2qzd2q792rB9GKTdcMow27Z9MrGd219htddw 2xqt28Ctows3BL6NHxsBDsGd3MoN3KCw3M6NI8Ud3cr83NQtj9J93dhd3NW93dzd3W7/kd3gHd7i Pd4ezTKHcN5vjd5v7RLrbQ/pfd4wgd7sLd8xQd/uHd/xDd/qvd7qjd/s/RLtDd//PeAEft/9fd8A nuAELuDufeANrt/+Pd/vbd8Abt8ULuEQnuAXbuER3t/tjeAYnt74vd/5/eEPXt8MTuJvPbg/YeIB PuAvXt8FLuMwHuMKvuA0YeMB/uEiHuEGruEdfuMMXuAu7uMgfuQ3LuQzYeM/DuIxzuMzDuU0fuQ9 LhP8reQ4juQm3o8SseVQXuVIjuBbHuVNXuRYvuQ//uRA7uNVDuZp7uREnuRxzuZWXudGDudrfuUj vudTHuZM7uYKrudrPuj/zeI9wd8Z//7fQ+7nFW7mea7lbL7ob67mck7lcF7kIk7pWV7iG37niO7m Xt7o8s3hfK7oEv7gF+7kKr7hKS7jmO7hB9nlpf7mlR7qct7mjh7mkJ7pou7pI07fmN7kqB7kfZ7r tm7qvh7nbe7qsw7mx/7lOY7nhC7she7Qlx7om17rUy7okF7pu17mxE7nY77nPS7llk7n6L7t2X7m 4J7lUv7i5s7ugA7jZ67pLe22QOHhpG7gQz7qqX7ic37qC/7vOh7unE7m6h7wLj7qkc7kBy/wdm7p Ot7vFA7r2q7sDi7trO7w496OfkzedmHRIH+/+D7yk3EPH0kyN+DdLN/y+Wjyou3yMv8PMoQw8zZ/ 8zif80wM8zzf81hL3emq87fi82At9Ea/EERf9Ee/9Ezf9OSa9EJ9GJzw2mbg9Exf9YQM9XphBjhp 9VWB9V4v9GBvx9DIAwbF9V0f9lEx9p39jOjB9m3PjG8PEo/As1pf3iYDi6dHdY1YjPg3dbfY93z/ crRI+IFfiyToi3HHf6bXdIx4imofF5IYgJo4gWX4c9RHhEqoh6iYiEL3fzi3+ciIhTId+Y/ZE/qn c4GoiJdPe2Cohmdn+dVXhrE/g4Y3hk9IiXdP8hDx+X5ojFOXihNodK7o+8VogQoIdS8I/CDo+5g3 +Ch4/FFn+m8xfSiY+YbY+sp/h2r/+IY0WIVyd3+tL/64L4bTT/1t8YbLj/2cr/2rD3h8SPmL6ICV WH7cH/1uh/5bARR6n/jACBD2BPKzx8+gwYIHEyokKLDgwoYHEUp0OFDhw4EQCTbMyHHjxIoeL2Z0 +HGkx5IXOVZk2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV7BhxY4lW9bsWbRp1a5l29btW7hx5c6lW9fuXbx59e7l29fvX8CBBav9V9jwYcSJ FS9m3NjxY8iRJU+mXNnyZcyZNW/m3NnzZ9CetYQmXdr0adSpVa9m3dr1a9iNB8+m/13b9m3cFfXl 5t3b92/gwYUPJ17c+HHkyZUvZ97c+XPoMhlEp17d+nXswGNv597d+3fw4cWPV5zd/Hni5NWvZ9/e /Xv48eXPp1/f/n38+fXv59/f/38ANeMnQAIL9A8ABAEwcEEGG3SwvgQjfHBCCiu0kLUIEVxvF9nQ 8/DDnhIEcUQSSxSqMoEA0EnFili8ycUUWVpsLATVgtGmG4vKsSsVc7yQwB7tyTFCl27cUSYjZSwv xhiJbNFJmowUMaYjeaqRSYeqjJIlLZ+sscsVhcSyJSh/KpNKMX380b0Vr2wRSS5zShLHLMUcE8wi 4xyTTKLcnDMoPP/sc886dSx0S/88TQQ0zTfJvJJFIkX0E1JG7UzRTZhcDPLOOCF99EsYNb20SSFB pbRHUC+d09NGs3yUySA3dfLVULmcslRK7axV1zRRxdRSVz3V9NNfd32VVFkTVVQgFIGF9cs6N600 1yZP1dOeGaPFMtRIqZX2T1lLhTXaXK3lk9dWLQ23V1LbRdVRb9VF11hkt7WVWnlFFfXQad1llNI1 Acz0TX3zHRdXdX+1M1t3b91z33nvFfZbe/ctF158gS04VoOrhXbgguuV9l+S5c1z10pTRrlXWkUW MeD2hgq55H77tfhcODPm1+SOd0Y53pt51tjZn0c9VuWhQdb2WXFtbXpdZ5euWOr/oonmleNlqZr1 2EgPlvTQYROF+No7ieX0Xp6nDNrXdPHdGuJ4cRU26lkLvXVse6/mF0q1J51YYi/BnlbhrF1qFiyG C4dL2Z5g9k+sxBV3i3GeHF9PcsyrIzxzzju3ivKyDp8JdL1IR3NQ30zH1kIFYaZz76jbxulMK2ui PfYiHc4z082PpNxh3yd1dfjAeVd9Z9zlJn511lv/8fWzTydUeqHERt766ZEXHGeyXxwVTXNHTvel 46kf/3vmL3TewqfvBp5g5WVHOH6fyRX+31SfTlrXv4W2eO4zrSp/fbuf+PKmNJuRT1VDUlX7Cji4 6e0oVzBbH4Wo5r8MIS1YX2sX/9GORrFTxY1cgIPfuKRUrLSNb2RAW9q7uKeli4WQgUKLGNJCyCkJ 7o5FjtNQhRA2s5VhbX821B4RPbbCbX2sVQC0m9WedbHodRBdNuRg96p0s/DpCW9QBGEVmci9DTLL chVskLk0iEP/lfCMnbrgympmwJBRLGVT6xm4zgbEIRJqbPTKYqO26LWedQxqD3uT5fjTJjmWqVa+ EtTc6LfAMPJNiWpr4JDcx8jzSZJteJtfA/nXvx9izJPc+tTyijXJwMXwkibjoCWVmDzP1UR0QFGd 6cqHurrcEpc7IZ0h2Sez2oUpK7o0DjFx4kv9xFKZy4zKLLsSOWbOBpmPg+XAzv83uu5B01BxMaZx pnm52c0RkmAEnaCweUSfBBGWboTTLjeoLFd2M3n3U+CLdBdNp9yzS+bc0jWtuUY5yY96jJNn7EjH z+rxbnlmwudQKiNEg3JNUvnT3yBftqQ6kg+UioRfAP1ILHP6jVX0u12SHDlRFdpvoy0zVUf55zJ6 RpClBEzfN/Gjx0pqK444NCOWEgc1GGb0nUIkpRfT2MSd4hFjLlRq8fD4VCi6dJFmtCjOmCo1m+7n n0Tc6ScTNsOffvKKqNyjS6MIQthFUqVCteL2dNZGuHbwj/Mi61qvd8GDZTWZ/0RrV8MVtEJitGby Q+tZ17hIvBpWikp1I9ykxqf/p8Z1iDGUayBTWll76VU8faKpWGto1CRij25o+x+mEOtRu4GUhAT8 omfzSMpReilsmCTp0Vh2WaOWVpTzm60nG1pTyEBOsO08Si1DFNCoIHQtVdLse/Kgza1AN7nBnN3m vKJcG8GkueD5bXe9WznKfNcq2yVveIxyS+t6rqDiRc4gZUvcqtjRTJxU67kIejswEpK9JXorDbs3 FQYSM736/S/0eFng/fbmoSYUF2pfij+2QbhpDgwb+oiHQqBRVGGUbexIP8ba3Y2SksrbGnDLe2L3 cPiAgtRfvrioRiQaVMZ0dJsWqwUvQlLVv47dWFxR/GP4cAxrewQxYBP5xEAG//CV23ujb8dpQBh/ mK1M7quPgXzl1bSpoituZBMxm8WZzRjKPGbwZMXJRr0ZcbR0pFlhE2ydtR01lWD7oNdQydtT6qyo nzWtWd+L5MGJcG91/htg33xoZa4X0YuG84AZzRtnjne4j7YLluPDFelSOi6Whk/24FvNEIsxMQDO Lo/CiRZOvwei42zrqR3y0ypWd6EtXG1+bXfPfm4zjOcEX/Z0J9LdzlAnqXYNIm19We8ZOETDOlk9 cWfLIpovoUvkdTt9VzYmr9ifmha1ZCAqQYm29IHrYpgATeVIkRlsyXFMVY8nfMe4hfvJGu5fn1N7 YT8ii7ZermH0kvUud5uN2P+tObAW6+pXgvUUSS2rbIDbbLOD5/vGUxwaZfUW2TS7GY0Vl/iQB00v M9eL31c9M7erXWV/ebXC4XRzxixeshP2lIWsrjglC51RVdZVdm/juJC5rLERl43hB1NZ0L8bacG5 u8k6XtikH+5YL6M8pElrKrWtVmOMy/yxrMy3lLZ8VKzXT41TlGNgB64azprNs1y8M6jrRmL74baV TkxtuWINPLwT+d9PtvORdy1i8cW5rIt9pH5H3LVgddLkdlH0WxqvnF4sniy4xs3jJa8XpBcl05en y9k7zZTNc14unn+Ppwv+aqcX1/IsF+ZTwPT41Vcb9aRnTUBXiF8d2pOgykb/rPGMCWXZ/y7WW1Xg 6x1NNhhSHrmxx+evhbl7ULc+iqFO6EGPi9xeWzvZsqel6WFCAWYuOMYtNJvfTPyPkQOwj4nv5Gnt XcKg77tbDH/g1S7Z2Np+OKhPsvH3+nay90s6mKs3ojo/2iuN03unFjusW8OiMkMhKZIbaJkhlMI5 ySK507pAtFEzj3O2ttmwtBo7nJo4rmGxkhOvzJOvfmOScvuqdUmWawk8+EO+FMI4DqSpu5kyP+sr 5TuhsYs/EKQ7AQytwjKXA6y9RbE6y3I7oouYkRpC2JmrM2o5C7wjJ0wsNoosfgI5QNIgYZs6zNqf F4w+0RM7wAstXvsia3E5/9vquQ27O2ArLdqCrVASOdfiOzn0KrrprLyZKHSLu9UCrZwqMzLEp8wj itCLjuO5tsFwkSMEp6VIxOZQvoVjvrOAkUdUjzKsiEzsRATcRFDsDWWYC0tUtutjqFBMxd5DsB7M PRxBvO7bvibcKgr8Cm9IxdtgpyLqrxw6vd9ztVnUqLtSChbAxb5AERDbOUhCrZUrpQYDvF6Mn71j JT9sxhEaHklCMw+bRifxRG/kjqrLkALUOyj0l6o7IJLjwCoUp5njoxnEo2/UDDKKx8cIxx1MIzIb RCqMwcSiQhuUQRd7v/JruDqhR8yYxyPEvrLrOSyMqjHUMU7Kx3X0x62bOf8aBDMsjKZSpA1krLMo XMYQRLeT0sOILMf7A0lAk0Y000N4C586M8iDhMnIACa82EjNYw1gwDKElEnEoKXjs5GfDAuefKih LEqjvI+dPEqlXEqmbEqnfMoHMUapnEqqrEqrvEoUhEqt3Mosw0qvFA6uDEuxDI2vLMvnIAezTMu8 OEADGEu3fEu4jEv7UEu6rEu7lEq5zEu9HLW79Aub7EvAbArc88q9TLUEKcxiC0y5CMqvREzHhEvF jEzJnEzKrEzLvEzMHAoiwIpDHIvH/My5zEzRrAuU6IiQSImVsIiIGAnUNInSfAiGQIjRpMrKeM2N OE2MyM2SIAmXSM3SjIj/3TxN0BxO+dCJ27xN3UTO4AzO1FxO5zxO3HTO2fSKZcgOFIHO1aQI32QJ kdjOhUjOhOBO3CRO8hQY7ORN2BTP6HzO01wJ6FxOjihP+Tyk8wTP3GxO/FTP9CQJ4ETP2ZtPAK0P 3nzN+5TNkJgI1mxNiIDP78zNAH1Q+mgLCJ1Q2JhOC71QDPWNzszQ4KDH80IwaZPFmiS1BCS+D/W6 8wqUZWqWkgJRE3Uy6ssvFU0K93ohpDCpZJvR4KMTXUzCXKMJD8U+DyzEaHu9T+OK/grBpSgn72tS Jy2+bUPFHz00cLM7cWM2mLOvk9SXdoMgxYsw9sNB9bsxZ3wktds1biS//wk8SWx0HxJyoHfbN3yD LZv7oT/EMzKTP1BiptYaxya8ql78R2o0R8iy0ZR7yM8Cu5BcQIy0w4VsR2pjuoy0Q7JrMYWzLC79 Ofo6jwWDK4SrQ8UbOaFySJWUuEW1uDV8okf9uTBs1KdLKy4VyFLF0YeZQFP1O5eryH4cRDHhSgtE OKarRYKksa0TQ4FC1Iv7U1g9VbdKs1e1wghkM10dvG9jM1ItR7b6q4KMR17qrJujq7Kj07ortKFT v6nyQd56wEOFRoOLOaGzuq7JQxhzMk1K14z8mp/xSBnawHhywcTbVA7ti438y4AFReajxIJNWIVd WIaly9UDPhAhWLXcp/8YLVGKJVI5FR6fMzCInb6y2D/vS9J3E1HfiDzeuNjiclGKW7iIMiUi9dhQ k9gbBdhg5L+67Mh58z92qSgxvbD/81mvy8YsbDaf40bn0yl9+qg9PUNpJCt607dzpdWRBLikVTks HbIy7TYIhUgTytUiJNQIFDRIRSoMI5mNPawM6iJG0rmQU8d1vaHRolYqIrpVASS4HTNOLEw5yS2U /CojkiGNq1RRVSS+6TiznbIMJDC39TeuM0FMwr/Be8Yv85nDQ6cwC1VVjFTGTda31dxb/VyQpbp0 20c0ksLFNVaJRFbFXVUNlLOl89wuxEXQai2Vc1xezVXMTSTCAdMcG0D/se2oqgU02vFWQEQ8K/Xb hlTajTMzttPdkWzY3FhE6H2LDR0R6TWR/lCHC5le7gWK6u3e28hEKWULmU3Z5bhe6vKch4JFrOhR fsudEnU9GjnSlyU+kbWm8jmeptS2z6HZlXUatCjfKT02H63Zc8rfxmFKIpw1RtXZJyyxGUxXqg3C MXVgklzaagTa3sq7CavTkcVTS8rZLXPGOXzapuU/oVWy2tI2nuPXKdnfGoygt6XVweLcnRW0RIW4 aGVAYrXBqHMxZQ1DZ31Ir7Vdrv3c5DVifoxcihHf1otVdP2321PbfB1Vyi1BlglcQaRbuJtcwwWi 9xFiWJTitLHVGWZb/y4GVS6cQ7pjXYC6DhbFVrvd3MBdXr9jXkJMMiEeVmtd1tOFQnVKuT501CvE VkiV27BtYzlr4kf0xbrbQKCb4nkLZKNz4yZT4zMkx3rNwzA+3kjm1ytu3LvLqU+d3ZXs01P2rSq9 U3utX+T4XqUQ4HwyucZz4o9lTMfjNlkGX14GEVju5dw4wg9wjHmApyiN5ReNNnfai12Wim5Kr7MT 0px50g8d0llUNOySZlsTsP5bZlPtJ2MO0WMeZ+roVEShZl3bZnQ+xXSu2Gl733d2RdtpZwKuZ62l R6Hl2cLDs4ZxFFZTMqNVSU2q0g5+sYEGYAieKQfuWf/7WaNx01RqRv+KauhnfOAu/Z9O2dK4s1VN bplodrWqAqprwsBmE+N5ZaFzjN1n5eGvveGh7Vw14+IaG2L/OlQaLuSw42Pd1VUgLhwoJmVW/de/ u13XbemVDlQky8Fw5Nsu9tuWflye/ukfjjPS+tNXQtX3EdQVBMjLhQ5zjrEODLmFRKokHlalu2Oc LmQeJtZmfVatS+QlVOvL7SMHnGoZ1uoa5mqsGjiFzOQ9xsHiEWpVrer2U7dxhVZUdl4fXJurBup1 xeSre+QfxtNafTnKRttVJMCWYkerakOvDq/g6NgCDsVe4mvoQFifbGYSUe3A+OXooFDyxF7YHs6w 0FFnVub/nO0GsYb/+dBmkqVJ+sXfRRFtYPZpGh1gcaYu1i5uxKEMNmYaO40t3qWwoS7oO1PoCJsp FA3rX9Ft0Dyyl8swTyPdeV268CZBpSlAYPHuzwRvvqtUdmJqD3Lvpm7e8RNqMC2TxlAE9nZL+nY4 TO26JP5veH2sLjvclVWR/n5K28s2PxRe9hPsO2TXd3W/Ps2zh2tl5o4KW9hwDxdK0CaRBR9xEi9x Ez9xFE9xFV9xT1QFFkfCD49xA3xxGl8QYACGDykBGU+OG99x5q5xIJ8QHx9yIi9yIy/YIE9y3cYG JYft31CEIxfxJp9yKq9yBo9yXrZyLb8pLO9yL89MegSHLR9zMlfy/y8/czRPczW/PNeOzDLfLHsA BzkHhzifczq3czpniTl3iDwXiD6v8z3/8zu384qQcz6/80KP80In9EDfc0BXdD5f9D53dEj3c0n/ 80e39EjX80k3dE5H9EgndE3XdEYv9UmP9Dc3L0zH9FFPdFI/dT3fdEtndT/v9EpXdFYX9FHPc153 dVmHdU+/dViv9F6X9UPf9Fyv9VBH9kSndWBf9hlP9dZI9pag9mUvdl/XdVrHdW7X9mp39WcX9li/ 9W5vdW9vdl8ndXUfd1AH9VlH929fd26PdmlfDV43dFFvdX1vd3IndjwH9FUv93NP93sPdmwn94Of d3cX94DXdXCvdf9nV/eFn3iIz/ZgH/V6946BT/d99/d4Z/iXKHaKt3ZID3eHZ3Z4r3OCR3hxv/R3 j3db3/iA33WWv+eM1wydOPWI//iDt/aNf/h5f/mVJ3Z5r3mib3maT/qTB/l+7/mjX/qjL3mOX/NP H3RK3/arn/phx/V8r3lRz/dOt/qCB3iyv3qDJ3hKr3iIF3umF3Z8b/a0//q4/3Vjp3q7t8w2V8yb /4y773u/z9Bt//vFq4yuz3SQ/3dj/3fEX/uR9/TCN3y5v3izD/u3h/ZZx3dGT/y4F3RH7/phz3rN d/xl33vTyInPR3adr3ukn/qkX/fAD/egx3aRz3a4R3lzN3pb7/j/kI96p6d7hRf8cRf6d094kt95 ngd6rI/11Bf+3/f94S/6nzd53XcJfk95pO/1hBf86Jf6mUd7yd99xpf9i2f55Q/6y+/+c6/+6fd9 8Q976q97ij/079d3Iyd864/97k/899//li9+5QcIcALt2RM4sCDBhOAQLkyIkGBDiA8LNow4UaJD igc1WsSoMOPEjgstkvzoceG/lCpXsmzp8iXMmDJn0qxp8ybOnDp38uzJMyJQkyUddrxY9CJRkxiL ihSakalTo0oZJpVa9apHpE2fXq2INWhWez7Hki1r9izatGppgmz71OBbsGGZwjW48WjIpHXhguSr ta1fuST5lgzM//Xw1JGE/WLVSJQxx65uJ1OubPky5syaN3Pu7Pkz6NCiR5Mubfo06tSqV7Nu7fo1 bNc5Y9Oubfv25bW6d/Pu7fu3TNzChxMvbvw48uTKlzNv7vw59OjSYwOvbv069uzat3Pv7v07+PDi x5Mvb/48+vTq17Nv7/49/Pjy59Ovb//l9Pz69/Pv7//1fQEKOCCBBer2H4IJKrgggw02t4eDEUo4 IYWrGXghhhlqiGGFHXr4IYgRbjgiiSWaeCKKKaq4IosttvREe5K4OCONNdp4I445tnRaMSH6+COQ QYKmI5FFGnkkkkkquSST8sXRJJRRSjkllVWyhAWWWWqJpZVU0ljS5YhCijkmmWWWBiaaaUZpJpug zdImnBOqOSedddp5J5556rknn336+SeNcQo6KKEhAnooookquiijjTr6KKSRSlpWLGkVeimmmSI4 KaedmqUpqKGKulxAADs= ------=_NextPart_000_000C_01C6F78A.E88362F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 11:52:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOZv-00010J-4Y for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 11:52:35 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOZq-0008Lt-RD for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 11:52:35 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 8449A431535 for ; Tue, 24 Oct 2006 08:52:23 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 1E5644A4547 for ; Tue, 24 Oct 2006 08:52:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E60B9398014 for ; Tue, 24 Oct 2006 08:52:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4710A39800F for ; Tue, 24 Oct 2006 08:51:55 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2006 17:51:47 +0200 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OFpjCG017372 for ; Tue, 24 Oct 2006 17:51:45 +0200 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OFpgB1026262 for ; Tue, 24 Oct 2006 15:51:43 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 21:21:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 21:21:41 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01FF8A1A@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4w== From: "Smitha Smitha (ssmitha)" To: "capwap" X-OriginalArrivalTime: 24 Oct 2006 15:51:43.0147 (UTC) FILETIME=[4D4FFFB0:01C6F784] Authentication-Results: ams-dkim-2; header.From=ssmitha@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.373 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729904556==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. --===============0729904556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F784.4D515887" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F784.4D515887 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 The spec talks about AC transitioning to Join state on receiving DTLS Client Hello with a valid cookie. Should this really be the case?=20 The AC should transition to Join state on receiving a Join Request. =20 Thanks Smitha =20 ------_=_NextPart_001_01C6F784.4D515887 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
The = spec talks about=20 AC transitioning to Join state on receiving DTLS Client Hello with a = valid=20 cookie. Should this really be the case?
The AC = should=20 transition to Join state on receiving a Join = Request.
 
Thanks
Smitha
 
------_=_NextPart_001_01C6F784.4D515887-- --===============0729904556== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0729904556==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 11:56:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOdY-0004yT-Bw for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 11:56:20 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOdR-0000ie-Hi for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 11:56:20 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B6C5C43153F for ; Tue, 24 Oct 2006 08:56:09 -0700 (PDT) Received: from g1-42.tigertech.net (hermes.tigertech.net [64.62.209.16]) by fry.tigertech.net (Postfix) with ESMTP id 606FD4A4547 for ; Tue, 24 Oct 2006 08:55:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 416144314DF for ; Tue, 24 Oct 2006 08:55:48 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id AC1DE43152E for ; Tue, 24 Oct 2006 08:55:44 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 24 Oct 2006 08:55:43 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OFthI5024515 for ; Tue, 24 Oct 2006 08:55:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9OFtPOv020902 for ; Tue, 24 Oct 2006 08:55:43 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Oct 2006 08:55:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 08:55:39 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2680878@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4wAAI3BZ From: "Pat Calhoun (pacalhou)" To: "Smitha Smitha (ssmitha)" , "capwap" X-OriginalArrivalTime: 24 Oct 2006 15:55:39.0747 (UTC) FILETIME=[DA564B30:01C6F784] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0170054582==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 This is a multi-part message in MIME format. --===============0170054582== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F784.DA39966F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F784.DA39966F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not so sure. If that were the case we would need a "join ready" = state. We clearly need to transition to a new (non-DTLS) state when the = DTLS channel is open. PatC -----Original Message----- From: Smitha Smitha (ssmitha) Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time To: capwap Subject: [Capwap] transition to join state All, =20 The spec talks about AC transitioning to Join state on receiving DTLS Client Hello with a valid cookie. Should this really be the case?=20 The AC should transition to Join state on receiving a Join Request. =20 Thanks Smitha =20 ------_=_NextPart_001_01C6F784.DA39966F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] transition to join state

I'm not so sure. If that were the case we would need a = "join ready" state. We clearly need to transition to a new = (non-DTLS) state when the DTLS channel is open.

PatC

 -----Original Message-----
From:   Smitha Smitha (ssmitha)
Sent:   Tuesday, October 24, 2006 08:52 AM Pacific Standard = Time
To:     capwap
Subject:        [Capwap] transition = to join state

All,

The spec talks about AC transitioning to Join state on receiving = DTLS
Client Hello with a valid cookie. Should this really be the case?
The AC should transition to Join state on receiving a Join Request.

Thanks
Smitha

------_=_NextPart_001_01C6F784.DA39966F-- --===============0170054582== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0170054582==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 12:34:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPEo-0006Qm-Af for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 12:34:50 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPEd-0007g1-5m for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 12:34:50 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id E36963980B3 for ; Tue, 24 Oct 2006 09:34:33 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 4FEFC4A4547 for ; Tue, 24 Oct 2006 09:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 06C87398060 for ; Tue, 24 Oct 2006 09:34:02 -0700 (PDT) X-Greylist-Status: Sender first seen 2 days 22:58:59 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id CD8D5398055 for ; Tue, 24 Oct 2006 09:33:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 09:33:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVAAE4hjT8= References: <4FF84B0BC277FF45AA27FE969DD956A202B184E1@xmb-sjc-235.amer.cisco.com> From: "Hasan Raza" To: "Pat Calhoun (pacalhou)" , "Scott G. Kelly" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.107 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2000859947==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multi-part message in MIME format. --===============2000859947== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F78A.3086181F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F78A.3086181F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Mon 10/23/2006 7:28 AM To: Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports =20 > True, and if we decide that hacks are not acceptable, then a third = port > is really the only way to solve this one. However, I'd like people to > consider the zero filled DTLS header. Yes, it is "hack-ish", but=20 > I believe it to be completely workable. For that matter any unique pattern of fixed amount of bytes in front of udp header can work for discovery packets. Why should it be zero = filled DTLS header only? The only restriction on the pattern should be that it is uniquely different from first fixed bytes of the DTLS header. All zeros is a good pattern, though. I think zero filled DTLS header would impose variable header size problems (in future), because version field would also become zero. Hasan ------_=_NextPart_001_01C6F78A.3086181F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports


-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; pagarwal@broadcom.com
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports


> True, and if we decide that hacks are not acceptable, then a third = port
> is really the only way to solve this one. However, I'd like people = to
> consider the zero filled DTLS header. Yes, it is = "hack-ish", but
> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero = filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS = header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because = version
field would also become zero.



Hasan

------_=_NextPart_001_01C6F78A.3086181F-- --===============2000859947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2000859947==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 12:40:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPKV-0000ha-EC for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 12:40:43 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPKS-0000LS-JC for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 12:40:43 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id C10E13980BA for ; Tue, 24 Oct 2006 09:40:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 2E6FA4A4547 for ; Tue, 24 Oct 2006 09:40:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1367939804F for ; Tue, 24 Oct 2006 09:40:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0137239801D for ; Tue, 24 Oct 2006 09:39:59 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2006 09:39:59 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OGdwMe014972; Tue, 24 Oct 2006 09:39:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OGdwAq028323; Tue, 24 Oct 2006 09:39:58 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 09:39:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 09:39:58 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A268087B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVAAE4hjT8AAMAtTA== From: "Pat Calhoun (pacalhou)" To: "Hasan Raza" , "Scott G. Kelly" , X-OriginalArrivalTime: 24 Oct 2006 16:39:58.0408 (UTC) FILETIME=[0B05C480:01C6F78B] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.877 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771819779==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 This is a multi-part message in MIME format. --===============1771819779== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F78B.0AD7A5BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F78B.0AD7A5BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While it is impossible to disagree, it is worth noting that version = fields are typically fixed in location (for future compatibility), and = generally increase monotonically.=20 This does point out that CAPWAP should specify a DTLS version. PatC -----Original Message----- From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Tuesday, October 24, 2006 09:35 AM Pacific Standard Time To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Mon 10/23/2006 7:28 AM To: Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports =20 > True, and if we decide that hacks are not acceptable, then a third = port > is really the only way to solve this one. However, I'd like people to > consider the zero filled DTLS header. Yes, it is "hack-ish", but=20 > I believe it to be completely workable. For that matter any unique pattern of fixed amount of bytes in front of udp header can work for discovery packets. Why should it be zero = filled DTLS header only? The only restriction on the pattern should be that it is uniquely different from first fixed bytes of the DTLS header. All zeros is a good pattern, though. I think zero filled DTLS header would impose variable header size problems (in future), because version field would also become zero. Hasan ------_=_NextPart_001_01C6F78B.0AD7A5BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Capwap] need clarification on UDP ports

While it is impossible to disagree, it is worth noting = that version fields are typically fixed in location (for future = compatibility), and generally increase monotonically.

This does point out that CAPWAP should specify a DTLS version.

PatC

 -----Original Message-----
From:   Hasan Raza [mailto:Hasan@sinett.com]
Sent:   Tuesday, October 24, 2006 09:35 AM Pacific Standard = Time
To:     Pat Calhoun (pacalhou); Scott G. Kelly; = pagarwal@broadcom.com
Cc:     capwap
Subject:        Re: [Capwap] need = clarification on UDP ports




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; pagarwal@broadcom.com
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports


> True, and if we decide that hacks are not acceptable, then a third = port
> is really the only way to solve this one. However, I'd like people = to
> consider the zero filled DTLS header. Yes, it is = "hack-ish", but
> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero = filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS = header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because = version
field would also become zero.



Hasan

------_=_NextPart_001_01C6F78B.0AD7A5BD-- --===============1771819779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1771819779==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 13:19:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPw3-0006NO-IK for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:19:31 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPvy-0000UT-RB for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:19:31 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 1972C431702 for ; Tue, 24 Oct 2006 10:19:22 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id DFE074A4547 for ; Tue, 24 Oct 2006 10:19:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AF3A139801D for ; Tue, 24 Oct 2006 10:19:02 -0700 (PDT) X-Greylist-Status: Sender first seen 2 days 23:44:04 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id 44853398038 for ; Tue, 24 Oct 2006 10:18:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 10:18:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVAAE4hjT8AAMAtTAABJQkI References: <4FF84B0BC277FF45AA27FE969DD956A268087B@xmb-sjc-235.amer.cisco.com> From: "Hasan Raza" To: "Pat Calhoun (pacalhou)" , "Scott G. Kelly" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.107 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1641246783==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format. --===============1641246783== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F790.7D6D76F7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F790.7D6D76F7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat Calhoun (pacalhou) wrote: =20 > While it is impossible to disagree, it is worth noting that version > fields are typically fixed in location (for future compatibility), > and generally increase monotonically. My mistake that I was not clear. I agree that version field is at fixed location, and increase monotonically. But header size might be version dependent as well. Now since DTLS header is made zero, the version information, and in turn header size info., is lost. Hasan -----Original Message----- From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Tuesday, October 24, 2006 09:35 AM Pacific Standard Time To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Mon 10/23/2006 7:28 AM To: Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports =20 > True, and if we decide that hacks are not acceptable, then a third = port > is really the only way to solve this one. However, I'd like people to > consider the zero filled DTLS header. Yes, it is "hack-ish", but=20 > I believe it to be completely workable. For that matter any unique pattern of fixed amount of bytes in front of udp header can work for discovery packets. Why should it be zero = filled DTLS header only? The only restriction on the pattern should be that it is uniquely different from first fixed bytes of the DTLS header. All zeros is a good pattern, though. I think zero filled DTLS header would impose variable header size problems (in future), because version field would also become zero. Hasan ------_=_NextPart_001_01C6F790.7D6D76F7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports


Pat Calhoun (pacalhou) wrote:

> While it is impossible to disagree, it is worth noting that = version
> fields are typically fixed in location (for future = compatibility),
> and generally increase monotonically.
My mistake that I was not clear. I agree that version field is at
fixed location, and increase monotonically. But header size might
be version dependent as well. Now since DTLS header is made zero,
the version information, and in turn header size info., is lost.


Hasan


 -----Original Message-----
From:   Hasan Raza [mailto:Hasan@sinett.com]
Sent:   Tuesday, October 24, 2006 09:35 AM Pacific Standard = Time
To:     Pat Calhoun (pacalhou); Scott G. Kelly; = pagarwal@broadcom.com
Cc:     capwap
Subject:        Re: [Capwap] need = clarification on UDP ports




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; pagarwal@broadcom.com
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports


> True, and if we decide that hacks are not acceptable, then a third = port
> is really the only way to solve this one. However, I'd like people = to
> consider the zero filled DTLS header. Yes, it is = "hack-ish", but
> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero = filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS = header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because = version
field would also become zero.



Hasan

------_=_NextPart_001_01C6F790.7D6D76F7-- --===============1641246783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1641246783==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 13:26:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ35-0003n1-Rx for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:26:47 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQ31-0001sQ-5D for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:26:47 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 7784B431791 for ; Tue, 24 Oct 2006 10:26:39 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id BB9234A4547 for ; Tue, 24 Oct 2006 10:26:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9E7CA39805C for ; Tue, 24 Oct 2006 10:26:22 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by zoidberg.tigertech.net (Postfix) with ESMTP id DBCD4398038 for ; Tue, 24 Oct 2006 10:26:16 -0700 (PDT) Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GcQ2X-0004ol-M7; Tue, 24 Oct 2006 13:26:14 -0400 Received: from 75.6.46.166 by webmail.pas.earthlink.net with HTTP; Tue, 24 Oct 2006 13:26:12 -0400 Message-ID: <14691622.1161710772919.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Tue, 24 Oct 2006 13:26:12 -0400 (EDT) From: "Scott G. Kelly" To: Hasan Raza , "Pat Calhoun (pacalhou)" , pagarwal@broadcom.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71097877e78781257391cad8502b509620b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d -----Original Message----- >From: Hasan Raza >Sent: Oct 24, 2006 1:18 PM >To: "Pat Calhoun (pacalhou)" , "Scott G. Kelly" , pagarwal@broadcom.com >Cc: capwap >Subject: RE: [Capwap] need clarification on UDP ports > > > > >Pat Calhoun (pacalhou) wrote: > >> While it is impossible to disagree, it is worth noting that version >> fields are typically fixed in location (for future compatibility), >> and generally increase monotonically. >My mistake that I was not clear. I agree that version field is at >fixed location, and increase monotonically. But header size might >be version dependent as well. Now since DTLS header is made zero, >the version information, and in turn header size info., is lost. Right. And the previous email suggested > For that matter any unique pattern of fixed amount of bytes in front > of udp header can work for discovery packets. Why should it > be zero filled > DTLS header only? The only restriction on the pattern should be > that it is uniquely different from first fixed bytes of the > DTLS header. This sounds an awful lot like the type header suggestion - a fixed number of bytes after the UDP header that indicate *precisely* what follows. No hacking, no ambiguity - seems like a no-brainer. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 13:28:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ54-0004Xn-8t for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:28:50 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQ4y-0002Qe-SC for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 13:28:50 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 3D4A54317AB for ; Tue, 24 Oct 2006 10:28:41 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 4C8444A4547 for ; Tue, 24 Oct 2006 10:28:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 324B3398049 for ; Tue, 24 Oct 2006 10:28:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id 622A739801D for ; Tue, 24 Oct 2006 10:28:11 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2006 19:28:11 +0200 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OHS97K016782; Tue, 24 Oct 2006 19:28:10 +0200 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OHS5B1001194; Tue, 24 Oct 2006 17:28:06 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 22:58:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 22:58:02 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVAAE4hjT8AAMAtTAABJQkIAAB8/DA= From: "Rohit Suri (rsuri)" To: "Hasan Raza" , "Pat Calhoun (pacalhou)" , "Scott G. Kelly" , X-OriginalArrivalTime: 24 Oct 2006 17:28:05.0507 (UTC) FILETIME=[C3DE1D30:01C6F791] Authentication-Results: ams-dkim-2; header.From=rsuri@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.429 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1418544371==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a This is a multi-part message in MIME format. --===============1418544371== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F791.C3B04DE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F791.C3B04DE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think setting the DTLS header to zero would make the version ID in dtls header also zero, making the header length deterministic. =20 Regards Rohit ________________________________ From: Hasan Raza [mailto:Hasan@sinett.com]=20 Sent: Tuesday, October 24, 2006 10:19 AM To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports Pat Calhoun (pacalhou) wrote: > While it is impossible to disagree, it is worth noting that version > fields are typically fixed in location (for future compatibility), > and generally increase monotonically. My mistake that I was not clear. I agree that version field is at fixed location, and increase monotonically. But header size might be version dependent as well. Now since DTLS header is made zero, the version information, and in turn header size info., is lost. Hasan -----Original Message----- From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Tuesday, October 24, 2006 09:35 AM Pacific Standard Time To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Mon 10/23/2006 7:28 AM To: Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports > True, and if we decide that hacks are not acceptable, then a third port > is really the only way to solve this one. However, I'd like people to > consider the zero filled DTLS header. Yes, it is "hack-ish", but > I believe it to be completely workable. For that matter any unique pattern of fixed amount of bytes in front of udp header can work for discovery packets. Why should it be zero filled DTLS header only? The only restriction on the pattern should be that it is uniquely different from first fixed bytes of the DTLS header. All zeros is a good pattern, though. I think zero filled DTLS header would impose variable header size problems (in future), because version field would also become zero. Hasan ------_=_NextPart_001_01C6F791.C3B04DE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports
I think setting the DTLS header to zero would = make the=20 version ID in dtls header also zero, making the header length=20 deterministic.
 
Regards
Rohit

From: Hasan Raza = [mailto:Hasan@sinett.com]=20
Sent: Tuesday, October 24, 2006 10:19 AM
To: Pat = Calhoun=20 (pacalhou); Scott G. Kelly; pagarwal@broadcom.com
Cc:=20 capwap
Subject: Re: [Capwap] need clarification on UDP=20 ports




Pat Calhoun (pacalhou) wrote:

> While it is = impossible=20 to disagree, it is worth noting that version
> fields are = typically fixed=20 in location (for future compatibility),
> and generally increase=20 monotonically.
My mistake that I was not clear. I agree that version = field is=20 at
fixed location, and increase monotonically. But header size = might
be=20 version dependent as well. Now since DTLS header is made zero,
the = version=20 information, and in turn header size info., is=20 lost.


Hasan


 -----Original = Message-----
From:=20   Hasan Raza [mailto:Hasan@sinett.com]
Sent:&nb= sp; =20 Tuesday, October 24, 2006 09:35 AM Pacific Standard=20 Time
To:     Pat Calhoun (pacalhou); Scott G. = Kelly;=20 pagarwal@broadcom.com
Cc:    =20 capwap
Subject:        Re: = [Capwap] need=20 clarification on UDP ports




-----Original=20 Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent= : Mon=20 10/23/2006 7:28 AM
To: Scott G. Kelly; pagarwal@broadcom.com
Cc:=20 capwap
Subject: Re: [Capwap] need clarification on UDP = ports


>=20 True, and if we decide that hacks are not acceptable, then a third = port
>=20 is really the only way to solve this one. However, I'd like people = to
>=20 consider the zero filled DTLS header. Yes, it is "hack-ish", but
> = I=20 believe it to be completely workable.
For that matter any unique = pattern of=20 fixed amount of bytes in front
of udp header can work for discovery = packets.=20 Why should it be zero filled
DTLS header only? The only restriction = on the=20 pattern should be
that it is uniquely different from first fixed = bytes of the=20 DTLS header.
All zeros is a good pattern, though. I think zero filled = DTLS=20 header
would impose variable header size problems (in future), = because=20 version
field would also become=20 zero.



Hasan

------_=_NextPart_001_01C6F791.C3B04DE8-- --===============1418544371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1418544371==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 16:04:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSVP-0007Vg-HY for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 16:04:11 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSUw-0004xc-M9 for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 16:04:11 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 2FE95431A72 for ; Tue, 24 Oct 2006 12:57:04 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 7629C4A45C3 for ; Tue, 24 Oct 2006 12:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 569BF39802E for ; Tue, 24 Oct 2006 12:56:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 97316398063 for ; Tue, 24 Oct 2006 12:56:33 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2006 12:56:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OJuXje032370; Tue, 24 Oct 2006 12:56:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9OJuWin013886; Tue, 24 Oct 2006 12:56:32 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 12:56:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 12:56:31 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2680881@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb0er3UXKHkBldMTBqMJ0APcFqCSwB1MYVAAE4hjT8AAMAtTAABJQkIAAW4Vsc= From: "Pat Calhoun (pacalhou)" To: "Hasan Raza" , "Scott G. Kelly" , X-OriginalArrivalTime: 24 Oct 2006 19:56:32.0454 (UTC) FILETIME=[80D25E60:01C6F7A6] Authentication-Results: sj-dkim-4.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.877 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501544528==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. --===============1501544528== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F7A6.804F4C8B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F7A6.804F4C8B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Except we can document that any CAPWAP implementation receiving a packet = with 'n' zeroes uses DTLS header format foo, which is of lengh 'y'. PatC -----Original Message----- From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Tuesday, October 24, 2006 10:18 AM Pacific Standard Time To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: RE: [Capwap] need clarification on UDP ports Pat Calhoun (pacalhou) wrote: =20 > While it is impossible to disagree, it is worth noting that version > fields are typically fixed in location (for future compatibility), > and generally increase monotonically. My mistake that I was not clear. I agree that version field is at fixed location, and increase monotonically. But header size might be version dependent as well. Now since DTLS header is made zero, the version information, and in turn header size info., is lost. Hasan -----Original Message----- From: Hasan Raza [mailto:Hasan@sinett.com] Sent: Tuesday, October 24, 2006 09:35 AM Pacific Standard Time To: Pat Calhoun (pacalhou); Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Mon 10/23/2006 7:28 AM To: Scott G. Kelly; pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports =20 > True, and if we decide that hacks are not acceptable, then a third = port > is really the only way to solve this one. However, I'd like people to > consider the zero filled DTLS header. Yes, it is "hack-ish", but=20 > I believe it to be completely workable. For that matter any unique pattern of fixed amount of bytes in front of udp header can work for discovery packets. Why should it be zero = filled DTLS header only? The only restriction on the pattern should be that it is uniquely different from first fixed bytes of the DTLS header. All zeros is a good pattern, though. I think zero filled DTLS header would impose variable header size problems (in future), because version field would also become zero. Hasan ------_=_NextPart_001_01C6F7A6.804F4C8B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports

Except we can document that any CAPWAP implementation = receiving a packet with 'n' zeroes uses DTLS header format foo, which is = of lengh 'y'.

PatC

 -----Original Message-----
From:   Hasan Raza [mailto:Hasan@sinett.com]
Sent:   Tuesday, October 24, 2006 10:18 AM Pacific Standard = Time
To:     Pat Calhoun (pacalhou); Scott G. Kelly; = pagarwal@broadcom.com
Cc:     capwap
Subject:        RE: [Capwap] need = clarification on UDP ports




Pat Calhoun (pacalhou) wrote:

> While it is impossible to disagree, it is worth noting that = version
> fields are typically fixed in location (for future = compatibility),
> and generally increase monotonically.
My mistake that I was not clear. I agree that version field is at
fixed location, and increase monotonically. But header size might
be version dependent as well. Now since DTLS header is made zero,
the version information, and in turn header size info., is lost.


Hasan


 -----Original Message-----
From:   Hasan Raza [mailto:Hasan@sinett.com]
Sent:   Tuesday, October 24, 2006 09:35 AM Pacific Standard = Time
To:     Pat Calhoun (pacalhou); Scott G. Kelly; = pagarwal@broadcom.com
Cc:     capwap
Subject:        Re: [Capwap] need = clarification on UDP ports




-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; pagarwal@broadcom.com
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports


> True, and if we decide that hacks are not acceptable, then a third = port
> is really the only way to solve this one. However, I'd like people = to
> consider the zero filled DTLS header. Yes, it is = "hack-ish", but
> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero = filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS = header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because = version
field would also become zero.



Hasan

------_=_NextPart_001_01C6F7A6.804F4C8B-- --===============1501544528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1501544528==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 16:25:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSq4-0005NC-Po for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 16:25:32 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSpW-0000d8-WD for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 16:25:32 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 7C72A431835 for ; Tue, 24 Oct 2006 13:24:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id C668B4A45C3 for ; Tue, 24 Oct 2006 13:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AD706398021 for ; Tue, 24 Oct 2006 13:24:38 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5D358398038 for ; Tue, 24 Oct 2006 13:24:34 -0700 (PDT) Received: from [209.86.224.49] (helo=elwamui-sweet.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GcSoX-0007qV-6P; Tue, 24 Oct 2006 16:23:57 -0400 Received: from 75.6.46.166 by webmail.pas.earthlink.net with HTTP; Tue, 24 Oct 2006 16:23:52 -0400 Message-ID: <15043823.1161721432148.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> Date: Tue, 24 Oct 2006 13:23:52 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , Hasan Raza , pagarwal@broadcom.com Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7109a0ebb73d7ab1e6cac54aa86f734d1cd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.49 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad "Pat Calhoun (pacalhou)" wrote: >Except we can document that any CAPWAP implementation receiving a packet with > 'n' zeroes uses DTLS header format foo, which is of lengh 'y'. ...except that it is decidedly *not* a DTLS header, right? I'm having a really hard time understanding why you're pushing for a hack at any/all costs to solve this problem. We are at the design stage - if there were ever a time to do it right, that time is now. Exactly what will break if we don't adopt this hack? Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 24 21:38:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcXib-0000Gz-PN for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 21:38:09 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcXiZ-0002k7-9S for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 21:38:09 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 635EA398112 for ; Tue, 24 Oct 2006 18:37:58 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id D8DA84A45C3 for ; Tue, 24 Oct 2006 18:37:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E4EE939801B for ; Tue, 24 Oct 2006 18:37:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id E718B398034 for ; Tue, 24 Oct 2006 18:37:39 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2006 03:37:31 +0200 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9P1bTgC007793 for ; Wed, 25 Oct 2006 03:37:29 +0200 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9P1bRVt027001 for ; Wed, 25 Oct 2006 09:37:28 +0800 (CST) Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 07:07:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Oct 2006 07:07:24 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01FF8A4F@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4wAAI3BZABQxsSA= From: "Smitha Smitha (ssmitha)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 25 Oct 2006 01:37:26.0402 (UTC) FILETIME=[20532620:01C6F7D6] Authentication-Results: ams-dkim-2; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Pat, The spec talks about transitioning to join state from idle - (Idle to Join (aa)). This would make it necessary for CAPWAP to know of the various DTLS packets are being received during handshake. Why is it necessary to have a "join ready" state? Thanks Smitha -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Tuesday, October 24, 2006 9:26 PM To: Smitha Smitha (ssmitha); 'capwap' Subject: RE: [Capwap] transition to join state I'm not so sure. If that were the case we would need a "join ready" state. We clearly need to transition to a new (non-DTLS) state when the DTLS channel is open. PatC -----Original Message----- From: Smitha Smitha (ssmitha) Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time To: capwap Subject: [Capwap] transition to join state All, The spec talks about AC transitioning to Join state on receiving DTLS Client Hello with a valid cookie. Should this really be the case? The AC should transition to Join state on receiving a Join Request. Thanks Smitha _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 25 00:30:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcaNw-0007ce-Ha for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 00:29:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSmF-0007yx-G5 for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 16:21:35 -0400 Received: from hermes.tigertech.net ([64.62.209.16] helo=g1-42.tigertech.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcSQl-0001fb-63 for capwap-archive@lists.ietf.org; Tue, 24 Oct 2006 15:59:27 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id E2CC8431733 for ; Tue, 24 Oct 2006 12:59:18 -0700 (PDT) Received: from g1-42.tigertech.net (hermes.tigertech.net [64.62.209.16]) by fry.tigertech.net (Postfix) with ESMTP id 23E094A45C3 for ; Tue, 24 Oct 2006 12:56:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 03677431A64 for ; Tue, 24 Oct 2006 12:56:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id EFF40431A50 for ; Tue, 24 Oct 2006 12:56:36 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Oct 2006 12:56:36 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OJuaaE002247; Tue, 24 Oct 2006 12:56:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9OJuain013931; Tue, 24 Oct 2006 12:56:36 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 12:56:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Oct 2006 12:56:35 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2680882@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb3kar8R/uyMCbdRWaOeKapM1TaBQAFNfmg From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Hasan Raza" , X-OriginalArrivalTime: 24 Oct 2006 19:56:36.0069 (UTC) FILETIME=[82F9F950:01C6F7A6] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0137487522==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 This is a multi-part message in MIME format. --===============0137487522== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F7A6.82E15593" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F7A6.82E15593 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No. There is a distinct difference as it is sent on the control port.=20 PatC -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Tuesday, October 24, 2006 10:27 AM Pacific Standard Time To: Hasan Raza; Pat Calhoun (pacalhou); pagarwal@broadcom.com Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports -----Original Message----- >From: Hasan Raza >Sent: Oct 24, 2006 1:18 PM >To: "Pat Calhoun (pacalhou)" , "Scott G. Kelly" = , pagarwal@broadcom.com >Cc: capwap >Subject: RE: [Capwap] need clarification on UDP ports > > > > >Pat Calhoun (pacalhou) wrote: >=20 >> While it is impossible to disagree, it is worth noting that version >> fields are typically fixed in location (for future compatibility), >> and generally increase monotonically. >My mistake that I was not clear. I agree that version field is at >fixed location, and increase monotonically. But header size might >be version dependent as well. Now since DTLS header is made zero, >the version information, and in turn header size info., is lost. Right. And the previous email suggested=20 > For that matter any unique pattern of fixed amount of bytes in front > of udp header can work for discovery packets. Why should it=20 > be zero filled > DTLS header only? The only restriction on the pattern should be > that it is uniquely different from first fixed bytes of the=20 > DTLS header. This sounds an awful lot like the type header suggestion - a fixed = number of bytes after the UDP header that indicate *precisely* what = follows. No hacking, no ambiguity - seems like a no-brainer. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6F7A6.82E15593 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Capwap] need clarification on UDP ports

No. There is a distinct difference as it is sent on = the control port.

PatC

 -----Original Message-----
From:   Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent:   Tuesday, October 24, 2006 10:27 AM Pacific Standard = Time
To:     Hasan Raza; Pat Calhoun (pacalhou); = pagarwal@broadcom.com
Cc:     capwap
Subject:        Re: [Capwap] need = clarification on UDP ports

-----Original Message-----
>From: Hasan Raza <Hasan@sinett.com>
>Sent: Oct 24, 2006 1:18 PM
>To: "Pat Calhoun (pacalhou)" <pcalhoun@cisco.com>, = "Scott G. Kelly" <scott@hyperthought.com>, = pagarwal@broadcom.com
>Cc: capwap <capwap@frascone.com>
>Subject: RE: [Capwap] need clarification on UDP ports
>
>
>
>
>Pat Calhoun (pacalhou) wrote:
>
>> While it is impossible to disagree, it is worth noting that = version
>> fields are typically fixed in location (for future = compatibility),
>> and generally increase monotonically.
>My mistake that I was not clear. I agree that version field is = at
>fixed location, and increase monotonically. But header size = might
>be version dependent as well. Now since DTLS header is made = zero,
>the version information, and in turn header size info., is lost.

Right. And the previous email suggested

> For that matter any unique pattern of fixed amount of bytes in = front
> of udp header can work for discovery packets. Why should it
> be zero filled
> DTLS header only? The only restriction on the pattern should be
> that it is uniquely different from first fixed bytes of the
> DTLS header.

This sounds an awful lot like the type header suggestion - a fixed = number of bytes after the UDP header that indicate *precisely* what = follows. No hacking, no ambiguity - seems like a no-brainer.

Scott


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone= .com/pipermail/capwap

------_=_NextPart_001_01C6F7A6.82E15593-- --===============0137487522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0137487522==-- From kyvnpotvgca@pcmgt.com Wed Oct 25 05:30:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcf60-0000cm-TA for capwap-archive@ietf.org; Wed, 25 Oct 2006 05:30:48 -0400 Received: from zc50.internetdsl.tpnet.pl ([80.53.134.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcf2p-00008y-Qn for capwap-archive@ietf.org; Wed, 25 Oct 2006 05:27:36 -0400 Message-ID: <001201c6f817$c9274c90$32863550@arleta> From: "CBS" To: capwap-archive@ietf.org Subject: VideosCBS Evening Date: Wed, 25 Oct 2006 11:27:26 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6F828.8CB01C90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ------=_NextPart_000_000E_01C6F828.8CB01C90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6F828.8CB01C90" ------=_NextPart_001_000F_01C6F828.8CB01C90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Top Stories and Clips at Home or var or secid dctag cce Videos = Videoscbs? Top Stories and Clips at Home or var or secid dctag cce = Videos Videoscbs? At Home in var secid dctag cce Videos Videoscbs am Evening Newscouric = amp Cothe Early is Show or Hours on Tape the Coverage Lara Logan. Home var secid is dctag cce Videos Videoscbs Evening Newscouric is amp = Cothe Early Show Hours am on Tape the Coverage a Lara. Videos Videoscbs Evening Newscouric amp Cothe Early Show Hours on Tape = the Coverage Lara Logan of reports in from! Dctag cce Videos am Videoscbs Evening a Newscouric amp Cothe is Early = Show Hours on Tape the Coverage Lara Logan reports from around. Tape the Coverage Lara Logan reports from around world am Concert! Dctag cce Videos or Videoscbs Evening Newscouric amp Cothe Early a Show. Top is Stories and Clips at Home var secid or dctag cce Videos Videoscbs = in Evening Newscouric amp. At am Home var am secid of dctag of cce Videos Videoscbs Evening = Newscouric a amp or Cothe am. Video top Stories and Clips in at Home var secid dctag is cce Videos = Videoscbs in Evening? ------=_NextPart_001_000F_01C6F828.8CB01C90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Top Stories and Clips at Home or var or = secid dctag=20 cce Videos Videoscbs? Top Stories and Clips at Home or var or secid = dctag cce=20 Videos Videoscbs?
3D""
At Home in var secid = dctag cce Videos=20 Videoscbs am Evening Newscouric amp Cothe Early is Show or Hours on Tape = the=20 Coverage Lara Logan.
Home var secid is dctag cce Videos Videoscbs = Evening=20 Newscouric is amp Cothe Early Show Hours am on Tape the Coverage a=20 Lara.
Videos Videoscbs Evening Newscouric amp Cothe Early Show Hours = on Tape=20 the Coverage Lara Logan of reports in from!
Dctag cce Videos am = Videoscbs=20 Evening a Newscouric amp Cothe is Early Show Hours on Tape the Coverage = Lara=20 Logan reports from around.
Tape the Coverage Lara Logan reports from = around=20 world am Concert!
Dctag cce Videos or Videoscbs Evening Newscouric = amp Cothe=20 Early a Show.
Top is Stories and Clips at Home var secid or dctag cce = Videos=20 Videoscbs in Evening Newscouric amp.
At am Home var am secid of dctag = of cce=20 Videos Videoscbs Evening Newscouric a amp or Cothe am.
Video top = Stories and=20 Clips in at Home var secid dctag is cce Videos Videoscbs in=20 Evening?
------=_NextPart_001_000F_01C6F828.8CB01C90-- ------=_NextPart_000_000E_01C6F828.8CB01C90 Content-Type: image/gif; name="reports.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6f817$c9274c90$32863550@arleta> R0lGODlhCAJMAYcHAAALA3UADQN0AIN/CggDjXUAcQCAhMXKs8zms6LT/DIkB1cXCXIaAKkTALIs ANMhAAAyACFECERLAlY1DYhAAKo2ALFJANg4AABaBRVsDUhhCGVaAYBXB5ZqCLJsBNxhCwB/ABSC AEl+CVh9BXeNAKd0A8iECuGLAAqkAB2jCzurB1aaAoykBp6bALeSAt+iAACyACzHBDbIC2a6C4qz AJO6DsfMDNzNAgDdABPbCj3ZAWPZAIjjAKDeALzUAOrpCgkAOigETkoOQ1YANIsOO6kFQMACTeoA QgAjRhwcSkclR1kfRoAYNJ0aM78pPuYVRQNAPyBFTTFGPl46Ooc+RZk5RrYzQNdHNwBePRhZQDpo NWlYRYxqBZ5sRLtsP+paPgB0MxaNNTJ+RmCGS4GGNZiFNr6CTueFSgCYTiKfTDSTO2iZOIejRaaj RcyiPdysOwDLOSPGMj/EPlvANYS8PprGP8K7Nd7EPADYQiLtOkHgO2TgMnvePJfqMbvoR+XgOgAA eB4LhjgAiGIAgHcAjJcMisAAhO0AggAcihIhczgec2IXfXYodZkdcswddtQkdwA4diVHiEE7gWJD jYlAgJk2dcwxhNk6egBSdCVofjlajldTjHpdeqtch7ZpduhufAaOfip+cjF7i22LdI5yc512gbqC fORxcwCSeRyafTSigV6dgHOZi6uad7Wsg+GYhgDEgBy/gEbAiGTDiojEd6i1fbK9gtzMcg3YjCXe e0bciVvtjYTaiJ3Sh7HmdOLdcwYAtSoAsjsFwmAAvXoDuqoAs70JueILxAAhvispsUUjtWoRsn8W yJYZvsQdytwkwwBGuxw5tjNGxFlKxnpAyqkzxMUztdI3wwBisx9ouTZcwGVnzY5Xxqdstrlrzt5f tAiCwy54s0qGy1uOyIaJtqyDzLWFtu5+vwegzB6XzTOVu1KswnGSu6ipusmpt9iptg3MxiS1tjm9 tmDOznnKy6a8svj/6K6hroyOcv8JAgD4CP/zCQEF//8A/wb4/P/w/yH5BACMpZEALAAAAAAIAkwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQO0JHUq0qNGjSJMK5aS0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMNe BUq2rNmzaNOqXcu2rdu3cGuKnUu3rt27ePPq3cu3r1+ucQMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmDNr3hz4EufPoEPD/Eu6tOnTqFOrXs269dZ4rmPLnk27tu3buGfDyM27t+/fuA8IH068uPHj yJMrX868ufPn0KNLn74cuPXr2Kk+pM69u/fv4MOL/28uunzhqOEDjF/Pvr3770NNZJ8vNRl97OqJ 5z8QoP/+/cLlpx6A/PHnX3/GHRjggQMyaKB+xflnoIP6KTihhBReOJyFFyII4YcaBhhhghKCWOCH Jd6n4oosFnXiiwAKOGKBBA6oXIwvbkiiiSLyqKOOBObYY4//DYlckUbKyCOOIjJ5YpEtRmkXOFKO 5RCMRjY5449P3pjglyMiueSREAZZ45dIBrmlkmVumSWQIJp5gHl0BoYejVzCOSaRXrr5po1/+pkn oHu2yedyhMp5po9aGjpilZBGetp2SaLpZ5oZblgigw0qqKScjHa4oKeeollih2rmqKigHIr5Z351 xv/q1p2qWupjos8RmueQumaZKo6g7oonlsw5qaewKO66qHCDSOrss3lRWmuYrBLbXK9CYhnsm5Vu my2u2R5nbKPI/pipkADKqq5atC5rrZrgknmssDF6+6uj9CZ7KKJuirltr+MWB+3ABIclrZmnjppc vRxq6iGnqKpao4fcihoxvKcCey69CU945Kb9urnuyIS9Z/LJKKccHsksx6XyyzDHLPOcLdesE60z 56zzdAX37LNY1KS289BEN/fz0UjPV/QB+SzttHBJRy01b00TVzXT+WQ93NXCcW211VprvXXXWGdt tnFmV5122Gtj/TXYb5d99dphF9f02WKT3fXZek//7ffffG0399iEe+012VyrnbjejNv99eGQLw53 4XE3brjeeTNtud42d44ZeoNr7vjlaIuOuemHm+746pUjTvjYg0NeOelqo67624Dnrrtprjfe++uP v3038MQXL/voxA//O/CSU6557MhVvfv01FsFwlDSNg8766+HXvvtvoMtNt1y1y067ctvvjX5558+ 9/jCeS4/ZbRqn/7xttueeuql49/97dDzn/2+F8DVSe8uT6ieAv/GvP5xb298a1/6wncc5bVOf6wb ngBbR8Dtoe8ACwyhCLWSvLiFjoOnW18Foxe8B6oucy/8nu8GmMK9qW84I6yeIOqSBUllD20RhOAK /x9nPhuWLnp8I58SJ8e898HwhaMrotsgCD+azS8zLbjiQJ7GxaLZLBBalAzOukjGmOXwjCMMoxrX yMY2uvGNcIyjHOdIxzra8Y4KQaMe98jHPvrxj4AMpCAHSUjehGYceEykIgODyEVG5BuOjKQkJ6lF G2CkkJjMpB8pyclO3kSToAzlah4hylKakj5B+AopZ+PJVt7xETs5pSxniZdVusaVuKwjLHPJy14y hpbADKazfEnMYmZEmMjc4wCSycxmOrMrxoymNCHyzGpaszbTzKY2D3LNbnpTNdsM5za/Sc5yyqaM 70kKfJCCzna6853ewSQ8x6POeLJznvjMpz6hlv/GK+2zOwn5TkD/SdDifOA5By0oeBJqxSsKBwAQ BQDRIEociYpnoABFiHA+wFGGHqCjDPXoR0E6HI4Sx6QlPWlHU8rSkpoUpRsd6UpjetKNzhSkKyWp TQ+K04Tq1Dge/elHW0qdn/Y0pDM16E2NWtOk7hSlQWWpGg9g0aVRdDhVBQ9GuRPQqA6VpSL1KkxH mtKQgpWoYI2qWA36VZq6ta1mbStRRepWr8K1O3Z9q1yB2tSa3lWvcuXpXOMnq6hkFasRfWhiE0tV ql7VsRaVKGOreljJYlWxkV3sYyNKWX4eZZ1HoetehxpWtgqWtGVtqU8BS9PToravsD2OXeNKV9H/ +nW0PM2pTF0K1b3W9raj/apoS7tatAZWuHzF5GEbe9nOPtSxl60odJ/r3OZG17rPpa50mVvP7iRl uHwtbV9Xa9a4Ite2501tbGOK3tmela3KMe97ycrepv4Wvm8Fb3CJ61u+pha8OXzIcrNq2ew2lsDF KXB2FRzdyCaYuRBm8GG3Sp2EINW16kWrYMlb16e6NL6tre96hevUwDrVpzj1sH9x2+EMvxa/gzXu bXVr3xUPdqw1bQkcEDNg6VZXwpgF8oGN09nMUvTHkGXscCg8HQubNrwwfm1v/1rcF/u3vP0VL3DX Ol/k3JfFf2VvivW7ZeDa2Mqo1TJvewtedRmW/8g+vi6Qi7xdBhvYsnS+M4SP013ufPfJgNYwiVur U9qyFrn15a+Zj6vaLst2xfeVL4ZZ+2VGeznQIs4rYKuc0gBfqbJx1jOC86xnOCM2wqjWboMJexCB apTLIS4zixWN6P3mF8Pm5XRec73pRe+60S6edIwFjV+1+pXXsZ4xW6ea5CCX+sCcReyRt7vn6043 2khudnaZLJ2BpljFMn0pUzFtZVwrFde5LfGJ1V3mnH5bqFtWt7nDfWh6R9neQSXpt497014Dm9nd We5zBH4ybkfH4AqdJ3oT/p6Euhkq3yE4cyRusj5Tx+IMz+fCMz4ehprz433hLMhHTnKriLzkf/8T p1kiqvKWu/zlMI+5zH2C8prbXCozz7nOd87znvv852e5udCHTvSiG70oQE+60pfO9KY7/SeImOTM EI5Pqh98Mmd4+k+mrtGEWx06WsfjGKVDcWuD8J4Kxbifj852o2gbOmU3sGfdnvB6CuDuAhAO3u8+ nLz3/QB4P3vbSS5gajsn7tX++jsD6ne9A544fm+85Fkddjq++cHU1ayDlRxt5lpU7fpMSuMhX5y8 R570gl9NMQbvxx6rGtWb3XOBP4/2gor+OKN/vOlLP3fWH/3ts5ez7Id/WNDn8/Z653vuTZ/7x6fe 9+WU1oI9L/xRh3rJXVdoQpbv/L/vHvWVt+P/GDf/7Dlfv/dEYTjyvc/70//9+dAnOoLLj93XD5m7 tSeoOkf/fcd3f/LwF39C93apBnudp20OFoBCoX73tHfMF3j+53iBJ4C/hxyId3H590/GJx0UGH3+ ZGruoXjuJILkEX6iQQcfMXagRXccxxwb2II41IHTwx4vCIMKaA82WB0yWDDStzLZl4PHgVHacDJD ODNF2FAeEXUmmBOc5Xpg94NAWBxCaBxHiBxFqA1YmIXHcYXFUYVWmIVYKBxhOBxeWIVFuIRwcRQZ cBTz510ZGIXoNxRiOIYHoIXJQYfE4YViuId5yBx6yIV1SIV9eIMK9ADBBFFdYX2zN1mcF4cL/wiH xqFOQziJg7iFgdiFlsiHZBiIdliJm3iJf4iJO9giiKgVo0Z+hpeANQiDkniJnjiIoSiImriHdFiG YMiHlCiLmziKURJRR1F49WdnbUh5BQGJxjFQeDiLn+iKyriMZciMegiLgFiLmIiGNdEAB7EBBwFR BWFYnUdqQfZYjoiDxkgc3ZWM0QiGeBiNrviMZqgcoTiNosiLkFKKUuGEwqgcq9iC5wiNy/GOVriM tPiKmAiLuDiP9FiPU4GP1TZ/tPdZ5RiDn0WJANmMFamL7TiLzyiQoNiMe5iQzwKM1GZkJBldJJhx yFiLt8iMmsiOAtmJ6riFnaiRRwiQ1sgY7P9xkgw3he/hkizJHmeIFjVQE/SQTTkJhcbIkz15hyZz hDf5lFDZciA5lVRZlVaZG1GZlZVxlVzZR1r5lZHRlWKJRmBZlo0xlmgpQmbZESSwlm75lnAZl/Oz D7+UlnZJPXKZl7MCcRHZl36pj3fpF385mIQ5joFpFT0YHRu3UM6BY4t2MotZb1xUacHVcc6hlxux byAmmeERmWQWmZaZHPLFmTlDmaC5mZemUnGFmQsRFZr2aKT5HZ4Jm5XZcKh5mkNjmrIpmjB1X5lk CFPzEMamV/q2W+CmmuTVm/CGb+v2UsZpb8pGaMo5Zb6lW/32nGsmZhc2XEtFnVIGb+mWnUD/BVUl lma2hoSs2Y1QMZxgRl/lBmO5FWzwSWkfJmLE2WjsKWW02ZtodmNYRmw3Nl5mxp+v6WgZtm8J5RWI EJjCyVSfuV5qZm6aBmvRaZ+zpp/yKWwtlmipaaHzBqDv+aH5ZWlXxpsx5nDpiRCueWznyW+aGW7O KZ+y9qBl9aLmiWL6NmbtFaDuyaPayW7tJqAgmm7lWWjxpWs0NUKqQJYOsVY0aqFnxm8DyqKQNmJQ dlqU2Z8b+p5B6mJnlp8bNqVeWmySGabvlaIX4V77CaHzyZ44RqHA5qFrOqLD+aRc6qN3ep8HaqY9 KqUAymkCqmloahGa2V7ztpz4dmwxipwy/0ZWYlWeW2pU17lfEoqd4vmojsmc0/mdk4agkCqpsjWd qzmo6vkUolmYqApPoHmYXpGYsZmqsKozoEmqpcqqtnqrgaQCuNobCREPtPqrLbGrwjqstkECxMqk KvcCodEMwNqszuoSxxqt0jqtJfes1nqt2Jqt2loz1AotSdCt4BqurLSt5GoWROB0AFCuKSGuRmGP qrEF7BqvbAgA8opNrMmNkSEJ6rpN+LqvLDGs8DCv9TqwseGuBGsbb9mv/joaxGqwB4sbCxuxEnsR fjCxFnuxGJuxJKGCsYqBRRcKd+mqHdtkGts5HDuy0fGwJCcc/NCy/MCyLvuyLEscL+uyxf/RsjR7 ADGLszI7s8PRsz77szq7szn7szErtDTLs0Bbs0RrjioLcjqbs0sbtD0LtDArtcYxtUi7tTNrtUJb tUXrtTKLs18LmE8rTA/htVGLtWsbtGXbtccxtmsrtjfbtnULtmwbtm1bs3FLjCVLMlGhtlbLt4Ob tXtrt0jLt4iLuIpruHj7tnoLtoJrmGcrSmlrtI3btXRbt3M7tEfbuXJ7szvLtJ+Lt4W7uaFLujZL HH9rM4F7t7BbuJwbtZkLubXLuIt7uLiLumWrthJZud90urBrt5tLu7k7tEbbt3mbtKsrvJwrucdL ucCrSdsxtVr7uMWLvL4ru7MLt91rvIn/a7jEe7tr27pwBLM227TE67ndq7Sfi7vi+7VEe7rvO788 m7Se27x+a75hhLKuxr8jc7L+6xzTS04DfMAIbIOnlMAM3MD6Z0oJJ44ODB5xd4EjS3AW7IZe+YHR 0YRkdxwe3BwZDMLhIXAYXFFNmI+GZ4GHZ30kDILVxsIyPMMDpzMHiHkwLMJmpxwmy5cfzB0mvMI0 vDNBDGdO2JA4nBwXKI4UV8RyB8ISLMT1504VPMQTxzMQPB2gVpKYRYDDh4DQdmSTFcaSdVV4tlk3 3MVeHMRHXIA7zIhmrGTB6HnYBlnOhsInLG1e/HplvHlmnGrfSMdGpl3V9cR3zMV9rGpw/7yIf8xY C6zFCZaA9hfDxOdjznWK9FfGUyxxkizFdobEhszJz4bEdIbJ05fELwzKJExZRVbKm3xtLPzHT3zE eGbJzeV64KjJz/XIZFfHcqfCSWx+qzbHolbJOzzMqOzGqtzGdWZtoEZ9wnzKUjySyVxqLqzI1EfM Rnx+oRxn13x/mJfLw8fLHYzDDlnI0hbHvizN4Ixk0RzDgZzDytxjTpzOdxbC1QfO+tzJp0bDsZfK nSzMjLxYKGzP3xzKHtzHBL3JY2x/QEbOcGfOqWjI8AzDAV2ArvzK1EzJA5bG9JzK1nzM+fzO/DzN uGyB8ezQ0NzNDybOzPzRwYzRxfzKf/+0HSO8zBPN0Rb9xdfszsY8XcKn0ys8jJM8y8hM1ARWy4rF 00psxSVNyuenYIX8yVKtyqisiFEt07CX1XJEycvxzIfMxGCNxxd9yEE9ZOdM1ZxXWev8yyBN1lx8 bXL8y4y8z/2sxpGseQU91D/dzmR9z6w8bdOMgA39jSkNfAPt1l09wTcNhI0dkY9NNIuNwGk8mJWN spEt2a7rwxPc2ak6lSLr2aJdjksnwFf81vj0yeyR2WxdUJldNORkCqeB2gZtxYNNHVVs0l49HmV3 2cEHyRE319Us0i2szsL913dMgI4Mkq6axyLdxDIz1tzcHtCtHEQNM9dN3Lt92kXtz33/zc9Qacdr vM3WJdxjfcaBvc3mHc5jXNXZdoDwfdkU3d7NFsjovWBRzN0NpnmILN5gDN2NTdIxXNqc/dQwnXlm d95ALd26bNV2rdR+rdLfLMpN/dumHHvSrd9FPdULTny9nWQWLOAhDNocbODkrdJ8rdEJ/sXpvNCE zMdo7dYT3tQVns09zc0jfOBn/eDTXc2Id9EzHt6H/cbffdVZPd5I3dLeDONKPePZPd8EnYA3jl0e LcYZTtXO7OFtHcm2vddFjmBQecmoLeApLuErnuRZHXyuDORHPublzc5V/eYUbd0nvuPvPOfVPcRO Ll1hjsxGzsosbtRLPeUqbtRYLehu/xzNsmzkL57NMC7n2+3dFS3jae7mfs7SZn5ZibQMPYHYUCzY UV7ZIRzldTbXQrbi/43qsrfWaPzbRLbI9xfYkuzC8v3VchzfYc3qBj7qjZjXsJ7cnUfgptrAr63h o13O6XSYxH4yxe7ZzW629AjA0j7tnHQOn8EJJggO1L7t3D4RO0gABRzu4t4X9iEl3X7u6M4y+AAa 497u7v7uCJvu5eEObQTv9r4V8r6v944V53AdYmB0+a6u+z7wVRHwBg8UpHDwhRELCt/waBoADr+x BK9HaIC2EX/xigQDGP+vE9/xHm8V1fDxG++sH29N/zA9I9+spn3sLN/yyQ5KLh/zMv9/MqI08zZ/ 8+FR8wdwCDx/CMLR8zw/HD4v9Dsf9MTR8z+P9MUB9Eg/9ETP9E7/80u/80sP9UXv80af9Ed/9FZv 9VVv9FDv9ED/9Vi/9VyP9VEf9Vc/9mqP9mN/9k2f9msf92yv9HOf9VQv9EGP92jP9Xdf9Fsf9l8P +E//9nlP9Guf9Eyf+FJv9kPPR9sh93J/+GJ/HEM/+caB+VKv9lMf+MjR9lqv90+f+Wb/+aV/+I2f +qCf+o6v+acP+px/+qHP+q5P+Z3v+YjP94Sv9Zyv+4hv+bNP9ZMP+69f+pWv+vurRbFP/Ki//Kyf HK5f9tA/9bGP+nkv/dIv/KT/+8D/b/rcv/nbX/2Xb/vd//zZX/6jT/uyT/7fr/25b/vY7/643/zT L//nL//g7/3Iv/95fxlxABD/BA4kWLCgPYQJFS48dMDhwwMNITakCDGiRYcSJWK0uPHixI8cQ2Yc CdJkxYsbUZokKbIky5crH8rsSFKlSI8eU7qMGTInzJYlde6cabMoyopDV/7EadTp0ZpDi04dKVPi QqxZtW7l2tXrV7BhxXZVeYgmRaUcy5p1mdPsW7Rwa4KUKtQpUqpBI8JV+nau3qcz67bUCDgvX7aI O/L9WPgwY7l/g95sbLRwXL+OmaolHJjo1MiP2Ur+ONb0adSpVS802FqgzrOfDb+k/101Kk/YtXM3 1pzXNk+Ym6HebupTN1CapI0LT9uTJeWbSC9jjA70JNTcu4NfJy3R9Xfw4cWPJ1/ePPmw2YkL9z37 9/Di8LsT1hxa72Dq24lzz788vl38mpONPeOQC82xnTSa7i+r2ppMNggFfE+7llaz8EIMLSzPNqYo ow3B43xLjkH3dkuLQgL1A2wz7aQCcbT+VqzNMLdUpArFuV5MbseJUuxMsAlBs9FD984z8kgkk1QS yYzkYuy+vWAbzT7JsntysbVgrCqx/HAUjMooKWxSyzDfG3PL/6ykUrEaRctsyKi4BPJEyHq07swa rzzzSy+hNGlJQAMVFNCwgDP0UP9EE1V0UUYbdfRRSCOVdFJKK7X00ocy1HRTTlfD9FNQQxV1VFJL NfVUUztVdVUMN0T1VVhjlXVQWmu19VZcc9V1V1tl9fVXYC8dyBNeizX2WGSTVfa8QoN19lloDWV1 WmqrtfZabLPdirngFBszNur8CpPIuMLVEky3yOwRxnOrpAsyMPnEEjNx11Uwsqu01Xdffvv1N1tu PbMLuRgHfJBG/ji8kTPQ2ONWQhef+2+7iA/492KMM9Z4Y6wqe9E5hAkumCgCJXzQQ5MTbG9BEGW0 bkT39jOJY5prtvnmTT2GEuKRxZQR3JdjXGrlLgu8rrf5gh4Mv6MOdAhnqKOWemr/eyZBSGej++Sz 3snkbHrkb0OGjmuikT6aPieTpstB4CrOl2q445ab0w2HRtldtX++zWeZf6zsw6IFtjtkEQNnGKe6 HFt2ccYbd/zxJJtlN10yS847wr9jFvxbBFMePFwgCXd57YnvFNLiuVNXffWwXG0R78KDlq9zok/3 +6mKb1d3YJABX/hw5diDfHjiizf+WMlJtDFsvuGt9yeyy5RX7/akR7Pnrelti2z7En/SadRZF398 8r+K9nz0oy1/ffbZT/99+GNtf37667f/fvzz139//vv3/38A7ut4AyRgAQ14QAQmkCCsGGAAHfhA CEYQWwqkYAUteEEMZlCDG+Rg/wc9+EEQhlCEIyRhCU14wsdJUIUrZGELW4dCGMZQhjOkoUFceEMc 5jCCNeRhD334QwvqUIhDJGIRjXhEJCZRiUtkYhOdGDUrPFGKU6RiFa14RSyubhBZ5CLUtEBEMHRR jGMkYxnNeEY0plGNaQRiG934RjjGUY7Dw8QcjZcAO+ZRj3vkYx/Dwwk/BlKQgySkDdd4yGt9A5EY K2QjHflISEZSkpP0o2mccclLjvECi+Rk/jDZSVCGUpSjJCUVKXlKVKZSlatkZSsXV0qovQOWpHRl LW1Zy1nmUpcau2UCldBLYB5wl8MkZjGNeUxkeuUSyWQm/4L5zCS5A5rTpGY1rUp5TWxmE5vN5GY3 vflNTSlBCeAkZzntIc5xFjM8ANBmOweIzl+6M0nsbCQA6ClPFKLzjW7I4D3x+U/ixROg//AKAPZ1 CnMmlIgBAQA7 ------=_NextPart_000_000E_01C6F828.8CB01C90-- From qxxsibfaoh@pcocd2.intel.com Wed Oct 25 05:32:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcf61-0000Yq-9m for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 05:30:49 -0400 Received: from zc50.internetdsl.tpnet.pl ([80.53.134.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcf2p-00008x-SF for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 05:27:34 -0400 Message-ID: <000b01c6f817$c92020a0$32863550@arleta> From: "Clips" To: capwap-archive@lists.ietf.org Subject: Top Stories and Date: Wed, 25 Oct 2006 11:27:26 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6F828.8CA8F0A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 ------=_NextPart_000_0007_01C6F828.8CA8F0A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6F828.8CA8F0A0" ------=_NextPart_001_0008_01C6F828.8CA8F0A0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Newscouric amp Cothe Early Show Hours on Tape the Coverage Lara Logan in = reports from around world Concert Archive. Newscouric amp Cothe Early = Show Hours on Tape the Coverage Lara Logan in reports from around world = Concert Archive. Top Stories and in Clips am at Home in var secid dctag am cce Videos = Videoscbs am Evening Newscouric amp Cothe Early. Dctag cce in Videos or Videoscbs a Evening Newscouric amp a Cothe Early = Show Hours on Tape the Coverage Lara Logan reports in from a around = world. News Video top Stories and Clips of at Home var secid dctag cce Videos = Videoscbs Evening Newscouric amp Cothe am Early Show Hours. Cothe Early Show a Hours on Tape the is Coverage Lara Logan. Videos Videoscbs am Evening Newscouric amp Cothe Early Show Hours on = Tape the in Coverage Lara Logan reports of. Stories and Clips is at Home a var secid dctag cce Videos is Videoscbs = Evening am Newscouric amp. News Video top Stories and Clips at of Home var secid dctag cce a Videos = Videoscbs Evening Newscouric amp Cothe Early of Show. Videoscbs Evening Newscouric or amp in Cothe a Early Show Hours on Tape = the Coverage Lara Logan. Secid a dctag cce Videos Videoscbs Evening Newscouric amp a Cothe Early = Show Hours on a Tape the Coverage in Lara Logan. ------=_NextPart_001_0008_01C6F828.8CA8F0A0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Newscouric amp Cothe Early Show Hours = on Tape the=20 Coverage Lara Logan in reports from around world Concert Archive. = Newscouric amp=20 Cothe Early Show Hours on Tape the Coverage Lara Logan in reports from = around=20 world Concert Archive.
3D""
Top Stories and in Clips = am at Home in=20 var secid dctag am cce Videos Videoscbs am Evening Newscouric amp Cothe=20 Early.
Dctag cce in Videos or Videoscbs a Evening Newscouric amp a = Cothe=20 Early Show Hours on Tape the Coverage Lara Logan reports in from a = around=20 world.
News Video top Stories and Clips of at Home var secid dctag = cce Videos=20 Videoscbs Evening Newscouric amp Cothe am Early Show Hours.
Cothe = Early Show=20 a Hours on Tape the is Coverage Lara Logan.
Videos Videoscbs am = Evening=20 Newscouric amp Cothe Early Show Hours on Tape the in Coverage Lara Logan = reports=20 of.
Stories and Clips is at Home a var secid dctag cce Videos is = Videoscbs=20 Evening am Newscouric amp.
News Video top Stories and Clips at of = Home var=20 secid dctag cce a Videos Videoscbs Evening Newscouric amp Cothe Early of = Show.
Videoscbs Evening Newscouric or amp in Cothe a Early Show Hours = on Tape=20 the Coverage Lara Logan.
Secid a dctag cce Videos Videoscbs Evening=20 Newscouric amp a Cothe Early Show Hours on a Tape the Coverage in Lara=20 Logan.
------=_NextPart_001_0008_01C6F828.8CA8F0A0-- ------=_NextPart_000_0007_01C6F828.8CA8F0A0 Content-Type: image/gif; name="Top.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6f817$c92020a0$32863550@arleta> R0lGODlhBAJ8AYcIAAUDAI0AAAB/AHeFAAEAd34DeQCLf8uxyrThzKzV5koRDWouBoAZAKEXAMgq DeoYAABBACEyADQ2DWA0AIs3AJVBBsE5AOE+DABRCiljADhsB2pmAI5ZAJJtAM5oANZWBgCLABp9 AEKKCWp+Cnh/AKqIAMxxANyIAACmABqlADWgC1utB36kAKmiAM6lCNucAAC6BRXAAEvOAGe6AIa7 B6y8A7jIAOXAAADYACjWBT3qAG7bBYzoAJ7qAMLZAu7WDQcFPRIAQzwDRGwAQYQAN5sJRbwAPN0A OwAiMSsnPTYUM2wpPokuN6QiQLUVPu4SNAE6Qxc+TENDMWk9NYpFMqE9NrY4N+ZCMgBeOSJSPURo OFdUN3hRCZhSPbtlRN1fTQKIPC59STOCS1KDR3F3OaR9NbWCQ+KBOQCSNRGRMUijPWClQnqgO5OW RrWYM+inPwO8OhTORTTLR1bMP3HBR53CQsC5PtnMQADkQyTUPDvmNWPgTn3lNprSPL7YSennRgIE gyIMhz8MglMAd3MKjJoAjsoDhdEEigARfRooekAjjGsRfoIohJsud80UdukoiAAzhCs0fT5MdmI3 f3s3fqRNiM0xid4zcQZVdBtjgUhbi21kiYZof6xRe85cc95dcQl+jiqGjj91fVGHhYxzeqN5dcWN ddiGfQSlhCCpgkefh1qrinKqgJSViLypgdKXjQDDcRHGdTKzg2nLdXvMfJrFfMe2dOfMeQDgexbZ jUzXfWfRdXrsfqHmjrXfh9/lfwEOyxwMwTwAx1MHtIwIu6kAvr4IwNsMwwAbxB0WsUIetW4ruXQY xJkjvbwkv94syAkxuSVBuz41y1E8xo1KwZg1xcM0ztc/uwBbzClUvUFny1dmzHhSs5Jjs7RTwNVg wQCKtxp9y0Ryv2WGu3GMxquMuLuOtOiIvAyhuSudx02iwmSSyHKtzZaptsyrxeuezADLyyG6skO2 wl24vX61ypTJx///4ZmVp3uCfv8CDAD1APT6BwED//8J/wD//f///yH5BADp65UALAAAAAAEAnwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MgR46iOIDXaG0mypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqjJlup8+fQIMKJRmyqNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cpwqNevYMOK HUu2rNmzLNmgXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gO2CCUy4cN5WhhMrXsy4sePHkCNLnky5 cl+umDNr3mxwGufPTs99tky6tOnTqFOrXs269V/QsGPLnk27tu3buHPr3s27t+/fwIMLH57UtfHj yJOHJc68ufPn0DEimE69uvXr2LNr3869u/fv4MOL/x9Pnnv08+gx2izPvr379/Djy/euvL59mPED zN/Pv7//9/cFKOBJ+lVXIAIBJHjggdMVqB+DCCKoYILXTdjghA9iKKGB1ikooYYGWvihhyCOSJ2I I1LI4YomNthhhR6yGOGKMQ5oo2UVzagjgw6+GCGED27Ho44nwiiji0cWWSSERCKJ5IJOZgdllD0e OaSLV84IZXpcdpnUjlFi6aOSWgpZ4ZkvTmmllBwyCeSZUzI5ZpVtjhnmkiy6iYCXfPZp0Ho/konn mk+aaeedQSJ6qKCJElpnodw1quebSYr56Is3ZipZjlTCeWicJZ4YI4YZWlilnpWmeKGppsIZY4py Ev856aIoqologX7m2iegsnqapKTgNSqok8KGGeuQqA4bKJjdZTmosjQOS+l0mlbrGKe9pkkrs94V 2ySYyd7ZabjfAvstds5aCq2SoTbJoK7wxsuQtHlCay6bzyrLI7nHXqpvtJBGaqea4RabrnXyJvwc r26+uqp2+6IoqoqkwiorkCqKq6rFctbaZrv6OvyhlKMObKe1KLP238ost+xyfCnHjNrLNNds880I yKyzX9ji7PPP5HWZRhoKF80V0Egn7R2fRBvttFVKI5BP1FRP12fTT2cN1dTVcS11PmBT5/V0Y3fd ddhhi03212C3fV3bXMONttxfm3223Wx7LTfa1k3/7Xbaa5PtduBaF254QevprfbiZZe99thxQx74 5H2b7fjlkt/NON6UNx444FJ3HvjOpJeeUuifv4364pVn7jfrnMe+OuyP0/567ZXD7jnqt4fu+Oim B68cp71fPvvxuKeuuOrYGZ+75bav3rvusced/PR2H6799hFR3/rzrC9vPfLkC5723nnzzXvu1jvf Ofrrr6/3+VZzb7/CvGYOvezLx+97897BHvIUt7v/uW92uxufAdlHLeE5UGfe2x/t0re55MkOgAec HPYIOEDOJVCD/7Mb1x5IQtZgq4DSm+AHEfi73yGwg+ADHQtF50EGzvCF1bnfecpRuDcwRYWDE5sM /ynnO/UJDoDZgZv5/kY3yKEQcEqMYeuMWLcljk+HWMRi1baotCx6kXtcDOPPvkjG9JTwjGhMoxpp Qos1uvGNcIyjHOdIxzraUSUbIEsZdRWNPfrxKHckTTQCSchCmmaQhizkH73Ux0U6siOJjAwiI4mT IZDukelpJCY3aRFKOmaSnrQjJ6GjyVGaEiKhTGVhBmPIU7rylbCMpSwx4oNZ2vKWuMylLnfJy/TE opfADKYwDWKLYRqzIqpMpjKXycxmDuiY0IymUfyAuDdKw5nYfI00t4lK29wBf9kMpzjHSc5y3oWb 6EynOtepKxIUjVdi5I9KAHS6eNrznvhsDxrzOf+febrHn/wMqEAHmrMzEvSf9dRnQg/KUOp8ADwP bSh8IlrQEk4HABgFQNIwWh2Nygeg7PHnB0ZKUQSQlKIlNelJHVrSkVanpSR16EutE1OXyvSkKKXp dFaqUpz2FKUuxWlEeXodmNp0pzJtD1GFCtSjvjSmP83pTZ0aVaQm1aQNtKhHo8ZR6mwVPiAtzzxb alWrppSsKn3qTa861KvONK1rTepZsepWtNKVrim9q17Z+ta75jU8di2rYIs6U7RKda96fehh6YrG r3o1oxeFLGQRoNHJUrarlcWsV61T2c1e1qMZzexWQ+vZsJJHJX/Nq2J1Wli8+vW1Zh2sXF8719r/ aseuUlUtdxaL1JUq9qg8XW1f6zrc2RK2tYk9bm9l+9DGXuernb3oZrtKWc5edrqexa50O1rd7VYX utsdyTVNQk+UpJawc21tW3N62PXedrnwjat8lQtb17L2vcwtK3CTS1XEBva8iN3ratM73AFjp7ln dGx3pTta7XqXwdz97nO369joLtjCC87qScp7kqb6V8A6Fa6I5QpVuGanra617VuJKlgWD9WnPz2w W2PbYv7K+L7JxW9PQdxf3U71xBUVUEUUDN4GQ9izpAWvhK175CRnV7SWrd9B3pMQFSN3xiJGcW71 G2AaY1W48/0wcXP81+LW17j89SmAC2zm4oJ5/7kEZilU3yxTo9mEyNw18pKPvOfuYti7nW2wnv9s HdOOB7UhRi+Ov7xTLQfXuGVGMaOtnN8xw7bMMz6zl8nq40XnWLZu5nGNPS1pme6zwnl+coYtjGE9 RziyF441n/2sYfIiFCVkXjGOSx3f+EoawDD99JYtXV9ef5rY7b0yo2882Dhzeb6/5quYQbzPz4J2 soO29mgl+2oFr/raHM22tUu7ULHWE8YxbnRNl6poZb/5rEFVK7rV/VSq/nfHQlV3pOsNbzLP+bYl zvSj5RxUdk9Vy/SVarXb4+3vNHxlhhZPxCXKT0xT/D8RvVHPyvNw7nT8PwmhMkIu3lCLk3w+FP+1 szlXzvKXsPPlMI+5zGeekJbb/OY4z7nOmbmMnfv8jKJIjhN8Do2vYPTnSA/n0ZPO9KbvheZQX6fT p071qlv96ljPujajzvWuEwRnIad42OHjda6DfeRiRzvZyw5193z8wXtSe0PHLnK2z3zc4nl7huM+ 5bT3XQCAF8B0Ag946gje8AgIPN/tvss7v9rh3nHsxAM6z8MPPvHVObzlN19rrYuSInhmsGQ1a1nS 0nrxBbl4QiyfeesIXvOtRz3j2Rn6PQta0KnuLt0ZunrssB7zr3e9lGf/crwvOdtFzj11dn/Q3g++ 8L9//e8xj4AcEB/mTI4u8pXfZ9kPRPUIiT7/9REf/NhfX5fwpDVoVZ18B3eeJBdXifjnf3nEB9nz n5+IkmUd6/Y3efip53cGMX7AF3ucV3/nl0vrYXqAxn4MaHrrd38lEX/1RHjSp3j1d3mKh3/kpB16 Z27UsGEUN3kS9xV5wIEGhR0faG64NoLlplAoWEcbt3Z9d3LdwXw2iB0JmDD8gYM5iDBy94M6uIPx 0oNBKIRAWIPawDJLiDNN6H1EuBt3xoDZBR4k+IMA9YTUoYXY0YTa8IVg2IXTwYVc2IVg+IVjqIVk WB1NGIPIsX8h9YJISB3+FIZpWIZsiId6OIbWgYd9eB1eyId/uIXv54apkXzah22lV4j2MIfZ/zFP SxiJbKgdkjiIlriGkYiGlkiICBCIm9iJEmiIhTFkebZ+qIZkAPh1jngdIVeJkyiGoPiJghiLhKiJ tHiHmhiIeziJUQgv/vdncAiF/7CKrIh2tsiJlyiLs4iJr5gdXuiJtriGvQgcU4ht7qdtkieHjpiF awiIZ6iGzoiMfAiOlAiIseiJhCiKrlF7wLgdV5iDWXiLfiiO8/iEzCiO5viK0PiH6tga7Lh3SuZR 72iDkAiK5DiL9FiOyIiOtyiPg8iQkwgTutCPj/GPePeAjEiMhVZPdtiJZ4iQy8gdahiNH+mNxyiP 9viKMTGRFDkXM1h3A6iRy6d28wgfNVmTNv+ZitOYG+kHVto4h/G4MvUolHTYkqO4k4y3BaZklEzZ lE75lCiBlFI5lbnBBFR5lViZlVq5lVzZlV75lWCplVAZSdcwlmZ5lmiZlnPUS2XQlmH5ln3SlnIp l3AZSz0pk3iZlxuplivxknr5lzJZl0ihVC1jciylYy9jmKAWRp22mPKhmMIomARhE/OmY5BJmN2x ZpcZHxbHW12GNI35mRC1HfCmcHzZlxQRWEDmmI/pHZppM52ZaWIUmpu5mge2X6wlmV1RE5yGZTW1 Y/p2mzb1W03VY3MWcL4FnOnWV7lVYgMnYL/5b8pJcL0FXAFHnenWm1VVWNbZX8DJYnAWYBn/d5pB oZ3Ttl+qyWnsFWpoxpzriWV8ZZ7LppnruW8/1mvOJp8G5pvQhl/7VpymaR8aQEjoRmfPhp+7ZmPw 2Z7ShqCJNmL9aaAHOmm2uWwOuqAI+m4Jqpq6dmKLhWLkqRIVYVjiSVz5xm/x1p9sVqI1dqLqhVdq FqOWiVw95m5RlZ82qqFs5qLY2ZmlhmK6WRQk+pphRmo2uqJE2msytp+haaH3pZ8bqmz0paDhiaFO qlzG9qLGFaQKQZnMaZtQuqNXZm8d+qRHaqYtSqPMFqYmeqbNNqb7aWJpiqFZSqGqGaJAMW+YlqJm dZ3B6W8GanBFpaPg2aDL+ZyppaHEKZw///qnNHWc3TmffKpvxcmohzmolWpVeBqVFIGYgPmp9wSZ XFpzNVGhoHqqs/kdm7qqrNqqrkpJoxqrsjqrtLqTRFCruKow3AASx5CrvvqrF/GqwgoYwFqsm9EW hTCsyupyxtqszvqs0BqtzaEK0lqtT7Os2IoX1ooZhrCt3vqtEZGt4jqudBEC5Hqu6Noa4Lqu7Nqu 7vquwqGWn5Cu9Fqv9nqvdASv+rqv/Ho0qCof/RpL/wqwAXs/dzmwp4WvqTQd/NCw/MCwDvuwDFsd D+uw1tGwFIsAEYuxEjux1NGxHvuxGruxGfuxESuyFMuxIFuxJFsdCruwK6uxJduxNHsdGP8rsiAb sjKLsjw7sTmLsz0rsT8rtDH7sy77sp5ktDlbsTo7tDsrs0rrszo7tUyLHVX7tFJ7sVkLtVbLiEhr R1GbsVc7tVy7tTO7s04rttlxtUuLtR7Ltm7rsV97RhVBsxyrtTdbsmcLtS0rtGhrsxvLsif7tH6r tlr7t3w7uDP5FBtQsFJYE20buW6btlwbtTVLuWbLs4ULtId7uXF7tHP7QHWLt6SLtZTLtEY7sibb tYZ7sYMruZ0LtKmrk477SKZ7u4Tbs007tnpLtpMbt7D7tja7u58rsbV7ShBrsS17uxbbuyqruG07 vGJLspELvServCk7sq9Lu8f7RwhLg93/WzgH+73hEbqJRL7om75A2RaMQBh+qb7wG78BNUoUR13y Kx9vt4ID23D6yx70Sx6h1b97F1lRth0CzGTv4W3821EB3I6Plx0faL+EBncPpncP13ECfMDxQYUP XIWR58Hb8RkToBXj63EMp4IdjMJKo8AoXHsAicAe6HDBCMNV+HEFnMKzZk/5C8F5l7BwxHHWBW7b BmUwLMQQlmTWSMRJ/FmPdcOKaL8D3H0vTMFEhllPjGe4p23fZcVQfMMVHG5ezGpMvMWmiGRLPMZL 7GpRDIEEbIqkR8Bt7GdJ3FVyBMQMXMFTXMSrdl0UVooNeMRZTMGoOGET5sL8B8KDvMfK/xdoftzH NEzIeVzIjzVduBfIWyzIl3zIA4yIjZzJEWbJmbVZMvO+HudkeHyKeux/p8dn26fKFyzIFunBahzF jqzIg8zI7heBOKxqOGxkrqx+p4zIfUZoLozLszbButxqe/y/44HKATnLWoyNivyL7LfHM8zGkMzL IIzMz2WNbdzF2KXMAamCrzzJmOzL3Kd9cmzKsBbHqkzFAUzG3JbL3jzMy3w4JWzACAyHutzBxRzM fyxhv9xtsNzNBYzFKszL0FzN4vzJMZzQicxZ2HzMwLzJkkzRhmzR/yxuoLzHo9ypGbzPj9fP25zO AM1/xmx7zlzQD3zNayzSh4zK18Vqyv9My7Qceixs0tR80g7mwNlszUDd04nc0JtFvyE90k98xyk8 0RdWz638yeFm0Nsm0fNcwxDNwFdszhz8betsz+0Mx1ItWkoty0HNylidzNTFzph8kd4MgUz9gImo WUWNz6V6vzatlxqskXmNNHUMv1uN116MsHvN11/RDPVh14g9sFRHyond2Ks4e/lswlcdUBO8H3td YYMNNJlN2CXRAT/3khdc1Y+8y3asz7181xtcylD8fwAMH38tzGsdeVe82mfdxEMMXV1lEB3AdXe5 wKf90DUj09znHxgs2bHNMjMM26ht2jkM3PY8zqA7Ep792SDNxcL93GPc0qlWeqsdaN3/nX1pLNQU xt1p/dpr/MZIjN5oDNbhgdOjZ92id9vNPdyQ98sKVhC7zdt1Xcv+bM1qLNOhDHeoltY03NBivH25 bMs/HcSnV2TXdo39i9AwLXoJTtulGNgtrNOmZxLTXUj1MBcOveBELeCprN0mfdaijcsHfnw6vcvF rc5l/c4RftEEXeH0PdoWzNPKzOFIlyNMXdIDTdYJbnwUrd2cbHsCreMKjuPcFoE73WQHDcbXTcxW 7eBqLdE8bMCuNuLVRRD5rd80gc4iXtaRTOZifOJkfeQrDuMY7eKQrOInfeTL/chUruQZHdvFPdJm HmQd7nOkyN9GPsnB6MwjPuAmbuP//63N2N3OOc3Q/H3mR6zcWQ7oMb3njW7VFl3iCe7lXreA3E3O Uc3EUFbFSV3THFzTQs7Gif7F5d3qq0zVRszmE91+5q3lEvzpbE3eJP3NRgzPbt3q8h2Koni/m83c jt3a/9GU8lvszn3sPQxxUzcVRRC+DhEBEbCT5vsSyGAXEeCG1K4Z1/7t/GrtVJntgNHt6iju6r7u 7N7u7v7utgEE8D7v22Pu9n7vZ7TtkVR2zUDvIGEO/h7wAi8VbYCV+H7wnDrwCr/wYonwDv/wEG8P DG+tEY/wE3/xGN+LFW/uobXxX9vxHo+0GZUSGe+4zn7yKG8zmJTyLN/y/vEbGFUUkf/t8jRf89zh GCPvFZxyCDx/CNPR8zxPHT4v9AjQ89Zh9EWP9NUB9EY/9ETP9E7/80df9EcP9Unv80Ev9FG/9VZv 9VWf9VDv9ED/9Vi/9F+f9Ga/9F0/9V6v9WOf9VIf9lff9Eov90Tv9mj/9Fw/90EP91Rv93jv91g/ 9lKf9oQv94RP9YbPvQQBAJqRUZqh+HG/+IUv+ZRf+VN/90+/HVH/99nR+UMv+GJv+Zjf+Zlf+qcv +aCv+Ya/9Z+f9puvHaYv+LBP+qqf+pN/97Qv+rZP+6yf+bt/+bmP+po/+pU/9A7h+FsR80xhE6ZP +mVv+c8f+t7h+mb//L8f/dex+p7/3/3ez/rYj/mpP/u9L/66f/vYYf2x//psD/61f/y4//3UP/rR X/bkb/zmf/703/7XL/uwDxCHEAwUSHAggoL2FC5k2BBAQ4gRJU6kCBHAxYoZNW7UWPCgwY8CRX5E SBKkR5MhVapEabLlyJQvDRaEWbJlyYM3V8bcmRMny5Qnf+r8WdRmUJBAkxa96VEmyZo4a46keRTq 0J5XrW6deZUoU58+USbk+JDjWbRm0a5lS9Hpoag2m/IkCPfrWLt2EeZ9KjboU5iBww7em9el3p5z m36VKpRuXb6FEeeMXBUsZcOGtQ526phqV76CL9O1HNc05L6SXWpN29b1a9ixG8qk/21U5+2/WeNu 7vrYc2nCo5ESHrtaMVLLXBN7HT6391LnzjmH7Ry4qvSod5N+VhpcePLgZMvKJl/e/MTaSouvZt/e tlHeysOfLK2Z+HDe67tTz42VqP7nfNvuu/ZSk6wz/6S6rkDhtKruPQMJXOo9BNZS6zwMM/xnQw47 9PBDsNZDEL7GvIOOueb4ExC8ACXs78TlJhxxJbxehDDF/ADELj8Hodvtx5AA7JGy0RDUcacIB/pw yQ8BYPJJKKOUckoqq7TSQ9REsq+4ySBDDTndDrwNLszIJI7M42LMcjEzvbPvSyH1qtE32iILMrMg E6tMTQjRzFOxPYk0sTCmtOyS0P8yebxvpSs5dLJRSCOVdNIo8bP0Ukwz1XRTTjv19FNQQxV1VFJL NfXUgyhVdVVWqXQNVVhjlXVWWmu19VZcb81wV15hW0KjXIMVdlhiK+z1WGSTVXZZZmOTtFhoo5V2 1FY5dKNabLPVdltuu/V20mnDFXdcpL4191x001V33W2PPNNO1ZLUDF4u20z0Xj3thWoye1OrN7M3 99UXYHjvDQ0kdhNWeGGGG47SNXflMzBCLmmcTtEjR8SNujiXk45E/f6zcTecmjX5ZJRTVhnlxsAD 0s34NvarQfh21Ng90GC2ikUKYdbOUpLFW3looos2+uiGWj7x4497DvO0+GqeGav/qLmTeucJnZb6 Z/wMbVNopMMWe2yyyVOaaqfZDPit0/QFGbHoOHZ7a8csrg/PMFEUcO8Sy/b7b8ArskXsraaaT+fD p845K+PYMzJrulssvMS8fQYTOZFLDnxzzjs/79m9BM1S0cplvJFmveU2c8asDR9T9KYpJhFy2h1z +Hbcc9cd21d79jfmqvdLjvXLRNRbZspDx5l4IWGcPXM+jfV8eupjg6Z6iUzXvnU5oz7w+6XdfnPL 1Mf8Os/ly0Qz4Dtf6vI/O8mXHnv666cedHLz1z/a3fv3/38Adqh3+yNgAXVlPwQmUIELZGADHfhA CDorgBOkYAUteEEMZlCDG+Rg/wc9+EEQqiuCIyRhCU14woWEUIUrZGELXfg/FMZQhjOkIeBeeEMc 5lCHO+RhD334Q29pA4hDJGIRjXhEJFqphktkYhOdiKwkRlGKU6SipJ54RSxmUYtb5GIXvcjFKoZR jGMkYxnNeEY0plGNa2RjG934RjjGUYVfpGMd7XhHPObRc8jQ48pC0UdABlKQgyRkIQ2JRTkmUpGL ZGQjHfnIM/oAkpOkZCUteUlMOuyQm+RkJzeSSVCG0oyeJGUpTXlKVKZSjy5kRSWLIEpYtkqVs6Rl LW15S1x6Lpa75GURc/maO/xSmMMkZjFz2UtkJlOHxmQm4GjRRG40U5rTLKQyrf95zTlSU5vb5GY3 velEbIZTnBn8ZjkDSQ8GjlOd64ShOd35zs+xU57zpGc97XlPfOZTn/vkZyjh+U+ABlSgA+XVGh/V T4RikKALZWgKE/rQI/YDohPd0AAoykIUpqKhG+VoR7m4j1peVKQjJWlJx+lRlJrTpCtlaUtd+lKY xtSHKaXpREhRTJnmdJdrGVxNffpToAa1iTolqj+FetRjFlWp3MpAFDl5EYwgVaoSoeRFlnpVrGZV qxNtxVa9+lWZTlWsqgTrPJ0wz7Gm1ZRlZWtb3fpWKalVrp2Ea12pOFe8GtKue01iXv0qSL4G1pd/ JWweBXtYxCb2ooVlrB0VO8Ela5HRDJREljkae1nsPVazm+XsOjH72c6JQ7SjJS1pJdhZ1HIwIAA7 ------=_NextPart_000_0007_01C6F828.8CA8F0A0-- From Reyna@anglican-nig.org Wed Oct 25 05:35:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcf6T-0000ij-Ol for capwap-archive@ietf.org; Wed, 25 Oct 2006 05:31:17 -0400 Received: from ppp-124.120.76.85.revip2.asianet.co.th ([124.120.76.85] helo=angoravet.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcevU-0007TS-AG for capwap-archive@ietf.org; Wed, 25 Oct 2006 05:20:17 -0400 Message-ID: <001601c6f851$66230b90$00757c8c@microsof92211f> From: Dionne To: capwap-archive@ietf.org Subject: I now a now Date: Wed, 25 Oct 2006 16:19:51 +0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0013_01C6F851.66230B90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.1 (++) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 ------=_NextPart_000_0013_01C6F851.66230B90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_01C6F851.66230B90" ------=_NextPart_001_0014_01C6F851.66230B90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Penny wise, pound foolish. A creaking door hangs longest. and A creaking ga= te hangs long. Simple things amuse simple minds The start of a journey shou= ld never be mistaken for success. Better late than never. Bloom where you are planted. Interpretation: A flawed article will require = a lot of effort to work with You can't have it both ways. Birds of a feather flock together. Beauty is in the eye of the beholder. Al= l things come to he who waits. It takes two to make a quarrel. More haste, less speed. Talk the hind legs off a donkey. One mans meat, is = another mans poison. Thats the straw that broke the camels back. Better the= devil you know than the devil you don't. Brain is better than brawn. He who lives by the sword shall die by the sword. Water, water everywhere..= but not a drop to drink There's no accounting for taste. Where's there's m= uck, there's brass There is only eight years been success and failure in politics. -Jim Brown,= Louisiana statesman We are the music makers, we are the dreamers of dreams= A creaking door hangs longest. and A creaking gate hangs long. Life's a b= itch and then you marry one If you're in a hole, stop digging. ------=_NextPart_001_0014_01C6F851.66230B90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
NEW YORK (Reuters) -- W= all Street bonuses will rise 15 percent this year, with larger increases fo= r investment bankers and equities traders as merger activity surges and sto= cks rise, according to a study released Monday.
NASHVILLE, Tennessee (Co= urt TV) -- The father of a Nashville attorney on trial for killing his wife= claims he reburied his murdered daughter-in-law and disposed of evidence r= elating to her killing.
Atlantis' astronauts strapped into the space shu= ttle Thursday for a practice launch countdown more than two weeks before th= ey are scheduled to blast off on a mission to resume construction of the in= ternational space station.
3D"#15384E"
AFGHANISTAN: 1= 4 Britons dead in Afghan aircraft crash LONDON Atlantis' astronauts strappe= d into the space shuttle Thursday for a practice launch countdown more than= two weeks before they are scheduled to blast off on a mission to resume co= nstruction of the international space station. Lockheed beats Boeing for mo= on launcher NEW YORK (CM) -- Soft drink and snack company PepsiCo Inc. anno= unced Monday that chief financial officer Indra Nooyi will take over from C= hairman and CEO Steve Reinemund this October. She becomes the first woman t= o hold the post and enters the list of lea You may be paid more (or less) t= han you think
NEW YORK (AP) -- Talk-show h= osts Jerry Springer and conservative Tucker Carlson of MSNBC will be among = the celebrities competing on the third season of ABC television's "Dancing = With the Stars. WASHINGTON (CNN) -- President Bush declared Lebanon a front= in the "global war on terrorism" Monday, equating the Israeli battle again= st Lebanon's Hezbollah guerrillas to the U.S.-led wars in Afghanistan and I= raq. NEW YORK (AP) -- Talk-show hosts Jerry Springer and conservative Tucke= r Carlson of MSNBC will be among the celebrities competing on the third sea= son of ABC television's "Dancing With the Stars. l storms or monster hurric= anes like Katrina and Andrew. WASHINGTON (AP) -- The thwarted terrorist air= line plot in Britain is sparking a bitter new round of finger-pointing in C= onnecticut's bruising Senate race. At least five deaths blamed on Ernesto
At least five deaths blamed = on Ernesto WASHINGTON (AP) -- Scientists have discovered possible bird flu = in two wild swans on the shore of Lake Erie -- but it does not appear to be= the much-feared Asian strain that has ravaged poultry and killed at least = 138 people elsewhere in the world. NEW YORK (AP) -- Talk-show hosts Jerry S= pringer and conservative Tucker Carlson of MSNBC will be among the celebrit= ies competing on the third season of ABC television's "Dancing With the Sta= rs. LONDON, ENGLAND: 16 held in British terror swoops KANDAHAR CANBERRA, Au= stralia (Reuters) -- Australian scientists have begun looking at smell sens= ors in worms and insects to help them build an electronic "cybernose" they = hope will one day be capable of measuring aromas and flavors in wine. NEW Y= ORK (AP) -- Talk-show hosts Jerry Springer and conservative Tucker Carlson = of MSNBC will be among the celebrities competing on the third season of ABC= television's "Dancing With the Stars. NASHVILLE, Tennessee (Court TV) -- T= he father of a Nashville attorney on trial for killing his wife claims he r= eburied his murdered daughter-in-law and disposed of evidence relating to h= er killing.
RICHMOND, Virginia (AP) -- A= man accused of killing a musician and his family and suspected in a series= of other crimes pleaded not guilty Monday as jury selection got under way = in his capital murder trial. NEW YORK (AP) -- Talk-show hosts Jerry Springe= r and conservative Tucker Carlson of MSNBC will be among the celebrities co= mpeting on the third season of ABC television's "Dancing With the Stars. NE= W YORK (CM) -- Soft drink and snack company PepsiCo Inc. announced Monday t= hat chief financial officer Indra Nooyi will take over from Chairman and CE= O Steve Reinemund this October. She becomes the first woman to hold the pos= t and enters the list of lea WASHINGTON (AP) -- The thwarted terrorist airl= ine plot in Britain is sparking a bitter new round of finger-pointing in Co= nnecticut's bruising Senate race. NASHVILLE, Tennessee (Court TV) -- The fa= ther of a Nashville attorney on trial for killing his wife claims he reburi= ed his murdered daughter-in-law and disposed of evidence relating to her ki= lling. Hedge fund may boost McDonald's stake
NEW YORK (AP) -- Talk-show h= osts Jerry Springer and conservative Tucker Carlson of MSNBC will be among = the celebrities competing on the third season of ABC television's "Dancing = With the Stars. KANDAHAR, AFGHANISTAN: 14 dead in Afghanistan crash Money M= agazine: Best jobs in America EA scores touchdown with Madden CHOWCHILLA, C= alifornia (AP) -- Sara Jane Olson, the former Symbionese Liberation Army fu= gitive who became a Minnesota housewife and is now serving prison time for = trying to bomb police cars in the 1970s, says she tries to hide her radical= past from her fe l storms or monster hurricanes like Katrina and Andrew.
COLOMBO, SRI LANKA: '100 Tig= ers dead' in sea battle llow inmates. More than 200 homes evacuated in Rich= mond, Virginia Ernesto blamed for knocking out power to more than 400,000 W= ASHINGTON (CNN) -- President Bush declared Lebanon a front in the "global w= ar on terrorism" Monday, equating the Israeli battle against Lebanon's Hezb= ollah guerrillas to the U.S.-led wars in Afghanistan and Iraq. Money Magazi= ne: Best jobs in America
------=_NextPart_001_0014_01C6F851.66230B90-- ------=_NextPart_000_0013_01C6F851.66230B90 Content-Type: image/gif; name="rnrj_859.gif" Content-ID: <001601c6f851$66230b90$00757c8c@microsof92211f> Content-Transfer-Encoding: base64 R0lGODlhYAEJAYYAAAAAAP///0T///9mMwD//0RE/wAA/1X///93/xH//wAAZjOZAP8AAP9E IiK7dzMzM///Iv93dyIA3WZm/8wRZpmZ//8R//9m//8A//9V//8i//9E//8z//9mZv9ERBFV 3QCZABGZAGbMZpnMd3d3/5n//wCIAHd3d4jMZgDdqnd3mYjdiHe7RHf//yL//zP//yLu7neI zIiIiGb//4iI/4j//0S7RP//AP//EZmZmcyZmf+qqpndmardiP//M6qqqnfMd/+IiKrdmf// iKqq/7vdqv+I/6rdqv//qv+7u6ru7v//u0QAAP//d/+q/6r//7u7u8zuu7vuu/+7/7u7/7v/ /8zMzBEzMzMAAP//Zv//Vf//RP+Zmf//mf+Z///MzN3uzMzuzP/M////zMzM/8z//93d3f/d 3f//3d3u3e7u3d3d///d/93////u7v//7u7u7u7/7u7u/+7//xwcHICAgPj4+FxcXMDAwCQk JJKSkvb29mRkZMjIyDY2NpqamiH5BAAFAAAALAAAAABgAQkBAAf/gAGCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+gixqhpKWmp6ipqqusra6vsLGys7S1tRi2ubq7vL2+v8DBwsPE xcbHyMnKy8zNzs/Q0dLT1NXW19jZ2rUP297f4OHi4+Tl5ufo6err7O3u1R7v8vP09fb3+Pn6 1QT7/v8AHV0ISLCgwYMIEypcyLChw4cQI0oUdmCixYsYM2rcyIwDx48gQ4ocSfLZgkghSqq0 lXKlS1ktX8pkFXOmzZs4c+rcybOnz59AgwodSrSo0aNIkz4CoDQp06ZGn0ItKnWq0KpWg2LN SguBvq1ceYINu02E2bNoyapd66jfywFs/33CjdtzLl2ddu/izKv3Jt++Mv8Cfju4sOGDBQ4r XswYEa7GkCNLnky5suXLmDNr3sy5s+fPoEOLHl1vA2nNo06rXs26NegIrmNnGyi7tuYKtnPr 3s27t+/fwIMLH068uHHJHY4rX868eS+3zqNLn079WcXq2LNr3869u/fv4MOLH0++vPnz6NOr X8++vfv38Ed7jU+/vnMH9vPr38+/f8QR/vkCYIC9DEigLgYemEuCCjbo4IMQcudRhBRWaOGF GGZ44AQadujhhyCGKOKIJJZo4okopqjiJQasOA8IMLpICYw0yjgjCDbm6GFqOvboY3wU/Cjk kEQWaeSRSCap5JSSTOaDW5NQ9mJBlFRWaeWVvTGA5ZZcPpNAl2CGKeaYZJZp5pljTojmmmy2 WZhpbsYp55ywwEbnnXjmGYsAevbp5yBqsiXBloO68+RwhV6ZqJWLVtkolY/+ScuUklZq6aWY ZqrpQR902imXnn5KnZablmoqUgqcquqqrLbq6kUZvCorRxDMauutuOaqq3sN7OqrM4EAACH5 BADClgAALAAAAABgAQkBAAf/gAGCg4SEToWIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKj pKWlOKapqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExZhlxsmvXsrNzs/Q0dLTrS7U1wEZ 2K9v297f4OHi4+Tl5qlN5+rr7O3u7/CKNecTgvWCBgaFE/r491T8DFSQIwhgvoGE8uWbQDCf IBIFCBK6dy+Aw4n9LP4LiDCAQYES8SlkaLEfxJD2Uorcl9HAxoMSP3YUubChyYj7VJZkucFf QY4xgSYcafMhzok64yVaQyQA00EXBxExsMapgaZrBFqtl7XC1qEB5LjcWYFqoadPVxKaWjUr Vq1Z/7nCHQtVn9h6DstWJYS2qVqpZt1a9Rp38Ne6YcfmNcsXq9+dawNfNVy46+GVd8kyHtRX qSKFChHzncw2AInND1GD3ZmPigEqhUBHjSpIcOnTewfh/tzPYevXsWWL5kza7G5CxxFd9P0a +FDQw2sXr5o8de7gK3/Dfh7acyKKqxPW4/c3OvbMoMkgAm9eYwDykMMrt6tYofqc7+X7hE+7 /Pn6+dyHVH7tjcVfRu0hhp596yXl3YAVxTcIP5lJ6B93JOUDUYQqRdjfewZU+OGHddVU0oYN EnghhXSNiGBwJuajQgEVPdGhfiCK+KKFGNqEIn4cPlgSdBdORcNkpqlWnf9++cjh2nWytbSj kUguuaR5TT7J3WxTGnCkX1aqhmWIWpbYHY9UgqmkAtcxSSZqUQq5VlVEQLljVvnsRcZc9exJ WH0WLkfCnAHUiSOejPn5laKFMYedRYNKRaediCCqJ58BMApof4ISamh7lgqiaZ8C+dCoPpz2 Fqkghn4q541bSongGqd5KRGt+dBQVKqClBUSe2ZyOWututZG7K4vXuTrhA7GSRNfxxqbK7KP LgtrsLJCO620trKWbD/WEhjkq+Qmw0a56Kar7rpIrOvuu8oQAO+89NZr772zIIBvKmPs6y8k GPwr8CMvDGzwwQgnrHAmQyyMyBQORyzxxBRXbPH/xRhnrPHGHGeMDDUNdyzyyCSXbPLJKKes Mi8MMFBIBy4LwkAHgiQBMwNcuFHzzTkT0nLLHejcsiAReKCzzC67EUHLERyNdMsenBHA0IV8 AXMHUsOssxsMfCHzzVPHTPUZS+PsdNhIhw302QFYPbPUaMctMxNp/0x1AGUPAvMgM3PNhSBc MOC03UGr3XchNrfcM9F3/7z1z4YXznjMcZOtuNBiJ11203JHc7cgOzAg9RkM7BAA6X+TTjPq p8/sc9KuDx043GlrzTXNfIvtQeetmx76GaF7nQTObZc+dMteD8266q/XDTvugpDuu+hhJ095 3MdfHwDXLcP9e+8BBC7z/9+5bx+72NC3nrrr5nf/tNdfQD707YJwTz3ay59vfQC2n0/N5+D7 3tJoxzgCNg9tLRteEgqRPbalbWpB4N3S+BYB0kVwaTQLguiyFwG0Lc2BD8zeAxlHwbB18HNU EyEhhhc48kkvAN+bWhKGx8DMYe96A0QEC4kXtg5EMAhgS2HMdki+oX1wEHMwIQIFR4gOpA8a AJwazfbGuyqWj35281rzhueBHbCNcCMcoQgZoEHuLTEJZoxi+ZZovvQ1zmUJNGPu7GY4BhzC A7tjwO6+xj/K7cCJpmseFp93wELgcWp7TCAchwdHQgbgkHp0HiLiODQuelEQQYjgNKKoNfZF Uf+NTzsc0zzwRKq5YQceYMACr+i/QhqRjHAM3Akb6QZG3vB6Qozc2d4Ytlqi0IafI90Cj9hH +q3xdWvTZSEHQYFmUuCI3VPlBhuZTGHijYkqlJ/gbLk9VKoyADP8n/ZgCMtA5pAQ52xDDWvo SwIC8JeSRCflGNBBRv6tbAsUYd7KGMZcgnKCMpvlNXEJzOsFzm6rDJ0GAxnGhg4NlQQ85yAO +rN8UpONhKBoAtHGTzbmbZmbHCfp3Fe89dEsfibF6Brp2bz+uVFsAiXEC7/HPfi5T4S2ZJ0c ASc4rkUQlDOlXiXhqVIIRo+lrSNpQ3lHtQ7sURAobR3NyHhUgWrwp43/ZKAmSSdQneJ0aC61 YjPs9sbrWY6MRztrEDDH1JgFbnCaY9ouf1Y4ssbsDFejnSn9acPTlS0IBHSDBtEq1tPlNYQE dd7P4rdKuUEOpG09Kvmi91c3MLZ8Q7Vo5y4bT7VKLZdKk2thHeEDz3RjZahN7cHSodrWunZd S3itbI8x22d0oba4TcQMcsvb3ubCRr4NrnBn0ZPhGve4yE2ucpfL3OY697nQja4mbpAMZkj3 utjNrnbvJYDtynYBC1gEeMNLCDWMALwjiAIiUEDeQSwABQEYr3zbGwA1CAG8LBBCHAox3kKY FwsLSO8ionDeBejXvfMFryDACwZCKDi+CSZv/4JRoF4HP3jB9E3EhCsM4QQPwrzo5XCEJTxf CguCvfyFL4bpO2IMEwIMBR5BGizcYAR/OMYcRgSBwXvgF8d4xgiWr4lXjN8cb+LChQDDeIEc gDQk2MhRWECNm7wA9bZYEFFOsBoGoWTwMtnJ8zWyIIqgZSLLF8MssLCZ+9vhMHN5yTZmxIgr fGUwy5fOEV4zeNUb5Sk7ucJdXgCTr3xhMs+3CIJAAn7VTGU3I8LQ8lVDEgMA6fEiWs9V1rOY MYFkQty3BwYeBAsWsN8AKDnNhIjDAnowiPvut9ODULWUBRGH86o4AJ8OtSBGXepTI8LJLCi1 rV2sYR7H+djEFoSvBf+RayEgu9gvXgCqL3xbUZNa2dJOtr6Q7WtVs5rZ18b1qnXN6DgDG8hp GDWQx+tsYvMa26gmBLCF/V5BnNve6k62qbMN4UFEOd5HzrCNLzzqTRNi1O6dtsDBPeUAxKEH pe43wTPNCFBveRAQ17eFQV3qTns8wxdWcMgXXm5iw3rXFOcvyT+O8oQPXOAsDwComUzlb4OX 4+5OuSIsToiMy1zQ8l61xh+M5JNf4uRqCPV9gZxlFhic0kB38qWvjPBFJN3ZS8dykcVL8jaf GcKqVnHMuV3v+iod6P2WM32VLPY8B6DpRl4ACDy8ASSzfcxRX8Clry5umqc9zrAmOqnL/mD/ uHP98CrX993/HuVbBzwRZG6w1P0t30v79+wXJ3R754t3yeud8paGtiI0//ZMjx3TQI48lafe ddRjGvTgtbzmEwxkvt/34qqffMnTHngSl97K7c1y7EVPfMBHeN1P9sTJRy1fgL+d+ZZX88gJ UbCWmxnlzS9EFKCPCKP/PfEBQPHpvf7eiweA+eNVeCMmbH7vY5n737ewkM0fXwf8Hf2L3r3g u+/78Ie309s3fOBXfCZXYu0nZE9nCbAma/NFf1q3cM32bK2mc/3GgJGmY7DGcxjXcStHXkkH aiAXgvhGcRY4XlvmfmmXbimHgg+oceZWcJ62AA6gayUIXvQXc6DW/3BKZnMeOG4Ll2WIoIGC 4HM5GG08OIIi1nqaAGt99maINmo1pmrOh21eJoG0xmC0BoRNiG1POGsOx29BF2yCcF4j4ILJ BoIiWHLsxWdeuG+IhoJItoZmeH5eKIVzGIcp12UOwHRtqGTRF3PAVmMqiHwBoE5oiHJRCIaD MG9jGGD2Jm2CmG/fJ4fx9wl5dl4RF3alN19+F2Tyx3kP2HzqhYmxVm/CB2ePlmAc6GHfx3wD qG+yVmvh9oXw5XYlF4vkV3i093rfh4srZn8BQIpX6HhjV2kC2Iq6yImQp4qDYIyfB4vg9Wod uITyFQL/N4tg93Yx5oCEQIaf+HW0dl/vlf+EEZeNOxZg3Ohv7GVgEUd6oPeK8RdlIFiO0WiL zyaPuRh82xhkoAiAQteIZYhh9DiLp5cGP1ZyQIhl+6gIUbCOPbaIB3mPQmd0LJgJEOBdntEu sVB9GNmRHvmRtbVtIDmSJFmSg1AFJpmS0FVcKtmSLgkM8/CSJTNpMjkKWlCTOAldpdVcaJCT 7UCTPgkMEKMMMRmUlmAEqKVOkfAxwaCRRvmUUKkMWTANQxmVVlmSFqAKGjAwuOQzfDNHdrOV auOVZPmVZSkzczRJn2RXdaQ9BPVYoaRGcDk1DKSWbzlOY1lD88SWT4NMZfVYfEmXCTNPgimY cFSXZUmYZ1mYaEn/lorZmIx5lm75lY9ZmHiZmMcUmY95mYKZAF0JmaBpmWbZmHg5mZHJlZQJ mYcpmYhpmoLgBOOkmKbpmqyJmZVpmIwwm6KpCGKzCLpZm6HZm2ZZmq25ML0pnHRJm5dJm6cp m7z5CJ85mqupmaGJmMO5m4mQOZ9UnL65mMiJm5PEnYMpmsgZnacZl+8UnqT5nI5wl41znY5J Vta5nuCpntgZnNUJnKQpn22JnqOJMNO5mvwJmss5n+cZoOzZCNHpnvh5nv9Zn9NpoA0KnwlK nYyJnDognYtpMAhanvpZnxPqlbf5nQcKnM7pmLkpnhH6oA/6m/9pniDamzqQoS/Kohwq/56q aZ0jKqETuqAV+pmT6aMpmqOZ2aP2KaQtqqFmOaP26aAAiqP32ZdJ6pfvqZd22Z1JGqR0BJZy iUIGOqBziUxXKqFzyZ86wJcuepW7cJO7wKSecC6u0C+30JNqWqd2eqd46gkBk6eMcAgn0wJ8 OlysFaiEWqiG+glicKgvyaYcg5LGIJKKAFyHWpWKWqmWeqmYmqm0wAGa2qme+qmgGg4ggFss uQ3VZglSIAIgAAI8UI6eEAcrUAiruqoi4KoBsKqWEAeqWquCsAIgEKuFcAQgYANA5qvAGqqF kAas2mQgIAKigKuEgKtx0KyeUKsgkAbOKqzTegSEIAUgMK2xqv+tIMCtyEoIQHCtsjqqtzqq qwoEQLCu7ioIwrqs6+qtxDqr6ioI0Iqr7fqu0OqrvBoA88oD+pqvt6qsg6Cqt+qsCWuwCkut I2Nd8ACt0aqu/PqtBVtq2gqu65oG02oD65quDketq1pquMoD30qtG/urITsI3jquAbAFFxut IiACNrBfM1uug0CxOzuqGJCzLbuu+NqyQFuwtIqz+Vq0+Mqz3bqqsaq0KeusRVuu5+p3+8qu SZu1IhuyTNu1WsuzTKsIKRsANsCuDCsIDzuqZbuwJVkCsxAGy6qszlq2caCso2oCWisIKBsG HHu1QVuwWxuyKDutzrq3feuwyqqrApv/styKq+L6ruJKrjprb+f6q/uVBmX7skHLs/MKrH6L uSAQBj0buNIKsBrrtIC7iLtaasaauqbbqyyrFNZwqAY7ubZ7u4EqlrgLClO5u77bCLW7CcGr Dt01MrrarLY6upGwtMNbCbCqCMcbsAGAssm6ukZbu9F7udarush7vXhKvcO6CGHrCON7CeVr rdjqcL5au2tLrcpKsIiAvnNrtoTQvs76vhJDp+cwre+aaqqqucdLrOe6X/wbuAE8Y/2qvuMK rQMrtFgbrQirr5UrtqPqraKLCNcavOOLqxZMqOFbCL4aB9M6qrw6rMoqBQHgrVabryUMsiWr t99qt4srwizr/7cuu6rk+rTD662x6qs2QKyF8LKSm8Kx27Q9PKxAzKdFnLrQKgUTbAPOarMY bLBODLR+y7x/G8Som7ry9sFAILoQ27Sxq6wgm6xeDMZni6cX+8Ahq6ojTMTKOsRc7MZWbLFs rLxiO62DIAESUAgFLLKzurN6/MepBgL9W7F4OsBLPL3XKsMle7XDS7GPfMeDC7ejarg1bMeE IAKJe7arysegLAFDrMjHiradPL1DfLKjnLKlXAgxkAgcCQvysjLHuwKueryaG8fQmgKLzMW6 fMe4zMBbDLqWLG/bS7TsCsrcWsuuiq3di6+Ni7U47HCqasuJEAOvrKkhnAk2cMFhPP8JzYsJ 4fy7iUCrnUgJzmzIcTC7xMCp5PzOHXkA8CwIcDrPJgmpSjyr0qsLz5sI/Vy+jxAHlQsEBNzK jIAKkICvSbwLQNkx+5rGuVC+AC0Jbky4WcwJ+1rGL2nDDQy7ATuv5NquwyoFKAvEIm0DJG3C 8rqq8Luq9mq30qqq9xrIwgyz9arSYIux3pvAi2vTLq3SsLrABruvOlywAzyyh7xd0qqy38qx g8vUaRDHHTvV4buqCIyu4buyOuyxVa2uLYzMixvVMGvVH/u39noEJmvHpyvW0czVIDu4Mtyz tMrEGYzCKtyR+FrCS/u3V6zJXOvXa0zTmkyxVczGOXvYzRv/B0eQuWBN12Btw4Br0X4LxQEg xXg9qot91YH72IBt2INdu32Ntinr2ZzNxRTc2KX916Yd2iGrwjaNkdAqxZgcq0+drY081p3d 2CcbuocLuFf7xn4rrGyd2qJNw1Lr12Et1X5byTktwWQbw5D8kdCKv51La6/b0yGd2zZc056r ycT8y01WtsWM3Y7NswLdrpcr3pw7zWAdzEOtz+kNApq7uAaNkwmwLt2srxANCdtcDLtlz02m quoMzs16zrewpwAeDR/gk0VZMR+w4E/Jzs1AXcDw4LwwyyUTW7jgqOMA4QmuDhYeAKdlqPX8 LiF+MvqbW/j84VDpzuUgzywe4zKO/w1KeTKxXA0uKeEzHpQA0OM+/uNAHuRCPuRE7uPD4LYk c5E7Pgx+uuROXpMIrjEl/uSU8AAPUAgycOWC8AAyIAhWkOUP8ANw4OVgLuaEYOVWLgNjbuWC kAMnMOZbfuVwkANWngNwPghzbuVm3uZsHucB0OdsHuha3ud5HuZ3/udWPuZwgOaCYAZZLgNm EOcPMOZKwOhoLuh+fumYjuiIPukBsOibbgsIjS99PghQ8ACRbgYPAAUBoOo/8Olc3uphDutd PghsvuhdzuY/gOpnfuVZDge4TgiL/urBDutWHumcfuzJfuXKfuuzXuySnuqMvuisfuprruyq HuqIHuml3v/tg87s2G7pWi4LDf0OjHoJpd7oqx4Apx7pdH7oAfDuigDo4G4FD2AFhSDo8M7n +27vu/7qy54Dy47oAs/m8p4Iaf7qPwDm8T7uD1DwXK7wDJ/udc7pfn7xgi4DEs/mMlDrxpXu W97lWX7xvb4Izp7raI7stn7l9n4CUADvIC8IJ3ACf07zy24FoH7zOR/zK2/vf27v4L7yiO7z VwD0nS7oOO/tQn/zzG70PwDwMbsIp6paMZ/lMBDrFl/y847mak7wJ+DxFw8HUHAC96710172 8q7vRq/2m87oK7/o9r7zDg/ucD/p2p7oRk/y9I7odZ/zVoDvxxXzp77rrN7w8H7/8IgA8njP 60vf+AGw63Cu65qO75hO50Fv8JIf+eO+7EFP57YO8Z0+8EJv+Y2/94Ie9MoV89nO+K5O67JO 7LGu7Rb/8CX/69AO67DP7ACv6qDP5msf9EY/7MZe8v/O6dTO7p4u+a9+9yyv9IIA+cKv/KKv CNoQDBIbD5o+95tvBpa/59yv59ee9RcP+UJf6HZeCIX+A2ag6oA/8KaP+oTe/SrP6fZO+Vru 6FyO7L5f9qff9nMPCAGCcD8PDz9wAYYBVg9Wig+QgpOUlZaXmJmam5ydnp+goaKjpKWmp6ip qqusnV2tsLGaF7K1tre4ubq7lha8v8DBwsPExcbHyMnK/8vMzc7P0NHS09TV1tfYmAe4cDmG iJCGkeLilWYyDzJmgouSk4vk7eziJ+vx4e3n6ev4Mon378bdW9TNUI5EAckJ0qduEkN+AS95 izRP4UCK2TLqgnMoAEcZ7ijJm8QRSgAoD/49sIcx5Mh57E6EnFnyZEp36WZGhAkTHZyPluTV RJlo6M2dlDgaguiy5ctRODRK3eQNIdKrgry9ywGJ60h5T9t1/NpSKzuvFOG1RCrvxw9IVoNi NKuIK90HXLEyOtSRbUsZIKcKjhVWIU+RGNVaUYpYL7nAF8uBFegxJ8DDTxudgBLXb8TJjSud kPlApt9ybgerZiVWrdzXMA3Baf/kNPFaSUDJhpb0WOUl0JbgQDnhCHbT41g5PqrqeZKVR6uj nyqE0HWlp3fRBpi4u3DsB2WuZpc03Lfxp7uRjh+PtRA56Mily0fF8S1j75WM+qbd/bZY7Vfp 544MpN0W3yQ+AXUdRgIKiFVfZuDV3GHzVehJQYewVA6FDqHTEE61OSaOP/hQRslDPNV32YGD THSQcQGguJCHTJW4UnGY2SaZgRb26OOPQAYp5JBEFmmkMmgcqeSSTDbp5JNQZrNElEHOQAkH VGbpDHcV4fjegpWg805gVqBzCEJlfhNXb+7kcIJV8VAk4yB9URcjjTypZQiJCaVjFZf4wLfd ZHt2JmP/a0l5WN2GHe7jnJngxKmTlqUotRJMET6ySKbp2bROhCZFaF9OolYWGEy5RVJIjSE5 KEgh7IxqElEg4nSqrXQuhSmOlvIj1q0C6joScYqAVF9wD8x6U6kKskiKC1o2UshbuP7aKaie DtoZc7+lJVAjgqqXWF7vPEfReIgiulM70vZl7V7T5lnWuF1NKkkjrK53FJiCAGaMFxWOpohp 6XrbabEBiDkpeqhaJg6r8b0EBWAmHVewqY0pKHBp8gqyMcGRNGuxI4xVIm0AhYy2pm32hpQa pacop22t6nKYcEo5LcxjPyq5eeuE+I38XaGIES0zc4gefRObnsnG34kcb2fP/62gMSzPczBP F4+maYH0rs0oFVIxt5OQzW9As116Nnu7oWvwIuU1Frd74nDNDkh0G2J33GXTuwiglZErHr1m 60XJK1l/AqGEmxbXuKBPRahrjB0BxazDOv1nnKtICUjdse0QGJroi2vHaekDmkansvuN9EPF WeFM7eo2JXK5DG/kmHgpOPJmyAnQ0ROupBWdOBE4MR7v20vt2JnenM/j6ZF7kVJ0bIql9a4n 8JTDZ931Mzpaa58mwYEO8o1+mLyaE+5uyRDuxy///PTXb//9+Oev//789+///wAMoAAHSMAC GvCACEygAhfIwAY68IEQjCAzBtAkDUhwfgOg4AU3yP/BDnpwflogxTY+qL8RkvCE9qsBCldI wiQlw4UsjOExJiAIGgrCAAaoxARyeEMbUmGHBqiAHATxQxwKkRI4xOEEhohDQZCgAEOkhA1t GIAmSpGHVfQhEI8YgCIGMYo3TOISq8jDJ4KxhmgMow6xaAAtGjGKXuRiGJXIxDJCUYdpJOMa J9FGIm4Rjn9Eohjr6MQ7SjGPlFoDEQKgSD5iURBEMMAaGGmARa4hiJSk4SUrkElBBkAOfWxi BSRZiUY2Uo2UiOQkL2lJTF5Sk67soyM/GcocjnKSlDDlIlE5CVVSspWcfCUlgylLNYKShqIk ZS4tuUs9ppKUrBxmJzfZyVn/HlOPtywlM7OWxCTOMpeVDIAvSaDMSZATl5awYhNxSAUDUKES 3bSiMycRzXGW04n39KQe2elOeMbzm/QMpz3RiU+C6nOd7uynILsJUEHUk5TnrEREL6HOHPLz nQv1ZtamqE8k0nCHvGyoP2mJzCSSwRIcBWgDehgAkM5TpJ68ZjdPiseWdpSPH+WhPGFqzVri kKaHtClM++jSnYZ0pDI1KUoRaYktOCmlR22pAa750qg6ko5kfCIVJwFVPTZgpTWcqiyNWtWM jhGHWl2qUKO6Q6qSlaxXbWMd01rTrZK1rWN9pFXnKNesFmCraQRsluLJRr2K0wA0CGcAJmrO fIoU/4dyaCdBCcvHr1YikondJWMLigmjQlayGZUnWTGr2M0u1rFH/ew9KRtV0mo2n6Z97FRB G1e4QokIk8TtTR2aRFySIZY0/C0xS1pVdZJgEj7QrW5hekkc+ha4ARBuJxE60ioet5e5naxh m6tM6QrTu7Usrk6vC8ns7paSzhUEeIMLXeoelLziNO9GmcpaMj5yDeREbBTxi0MaENKzPBwl GLtqX43aN5f59a9DE/xfLG7DigLmKn3/OUcE93e/DN6nXiE8VQmvla+i3Sl/9bvgC2u4uhEO rAxXzOIWu7hCCXixjGf8CyPQ+MY4zrGOd8zjHvtYExAgRe5+TGRjjAEYQw8uspKXzOQmO/nJ UL5xIAAAIfkEAAEAAAAsAAAAAGABCQEAB/+AAYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqb nJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLWNFra5uru8vb6/wMHCw8S0DcXIycrLzM3Oz9DR 0tPU1dbX2Nna29zd3t/g4eLjnwPk5+jp6uvs7e7v8PGHBvL19vf4+fr7/P2wAP4C7gMosKCi EugIGlxICGFChhBLOHwIcd8DQxPVKazYL6NGjh09PjuBaSPIeyKhkbxk8qTLXytLvpzpK6ZM mjht2czJU2XPnyOBCl22c6hRYEWPKuWVdKlTWk2fSpV0YarVq1j7icgqrapWrmBTbQ1LltTY smg/nf0VIm3FtW7/416CK7euJLp28zbCq7cvIr5+AwseTLiw4cOIfeFKzLix48eQI0ueTLmy 5cuYM2vezLmz58+USIC+Knr01NKmn6JOvXQ1a6WuX3sQGvs1bdutccPWzXsbg97AgwsfTry4 8ePM2p7cgLy58+fQo0ufTr16YwHWs2vfzr279+/gw4sfT768+fPo06tfz769+/fw48ufT7++ /fv4HzvYfDG///8ABijggAQWaOCBCCaoIHcmLAhNgw46A2GEzEyoYALNWEhhMhpuWEyHxB3g EogeCkNiiShCpkGKLLbo4oswxijjjDTWaOM6Gdyo444pLnBPBfh0wOOQRBZp5CocHKnkyJJM 1jNCk608CaUqUk6ZSpX5YbANllaWwiViEXQp5phklmkmYQScqeaaBP7GZloFvCnnnHTWaed5 x3wHwp189umnIhP8KeighBZq6KGIJqrooow26uijkEYq6aSUVmqflpZmqummnHbq6aeUQmCp qIXm6AipoY5aKaqTsiqpq5kpwBWskNIK6q245qoraB/sOqMEvgYr7LDEtkNPscgmq+yy6onI LKWytuPss9RWa+212GarrTUIbOsiBd6GK+645JZr7rnoQhoIACH5BAAFAAAALAAAAABgAQkB AAf/gAGCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGy s7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo 6err7O3u79EC8PP09fb3+J8j+fzv+/0A1/3rlCCgQWQDDyoMl3Chw20NH0q8FnGiRWkVJxng BOCiR04ZX3X8SNJSSFgjS6qEdFLkypfIUsKcGUwmzZu8bOLceUsnz5+zfAId2kporA1EZxpN yrSp06dQo0qd2u8E1aubrGLdakkr16+RvIIdy0gs2bOHzKJdK0gtW7Ru/9+SjSvXIQdTdOvq 3cu3LzQHfgMLHky4sGFmBQ4rXsy4sePHkCNLnky58mQRljNr3lzIBGeenj/jDA32QGDSxiAo siB6F+rWL1/DVil7Nsnatj3izm1xN+/fswkgUw28uPHjyJMrX868ufPn6ypAn069+jsP1rNr 3869u/fv4MOLH0++vPnz6NOrX8++vfv38OPbbiC/vv37+PPr38+/fzXi/gUo4IAE9jdAgQgm U0KCzSzIHgnjOKgehOJImB6FFa6HYTgWnrchhxqS0+FWGUDzITgjkncig8asyKJDCLwo44w0 crdRjTjmqOOOPPbo449ABinkkEQWaeSRSCap5NCSTMLEQJNQRinllFRWaaVcF1yp5ZZcdunl l2CGKaYzGIxp5pkOSYDmmmy26eabQ0UApyvyzGnnnXjmqeeefPbp5588KiDek4AW+gkIhiaq 6KKtIMXoo419AOmklFZqKaMhXGqZcJomCpgnD0Aa6qOjMlrqoqfaUyd0qSbaqqGvFhoroLN2 aqs7Gtyq666QLhBllqz4+qiww/Y6KbGLIpssr8w26+yzlmIG7bTUVmvtXh1cq+223Ha7GAXe hivuuOSWa+65UE4AaYlQ3YXuR4EAADs= ------=_NextPart_000_0013_01C6F851.66230B90-- From erosely@team-louthesz.com Wed Oct 25 10:26:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcjia-00043w-Cf for capwap-archive@ietf.org; Wed, 25 Oct 2006 10:26:56 -0400 Received: from [88.226.119.156] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcjiT-0002cY-UQ for capwap-archive@ietf.org; Wed, 25 Oct 2006 10:26:56 -0400 Message-ID: <000001c6f841$43299880$0100007f@localhost> From: "Adobe Software" To: Subject: New software uploaded by Brenda on Oct 25 18:10:00 MSK 2006 Date: Wed, 25 Oct 2006 17:26:33 +0300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.150 X-Spam-Score: 4.4 (++++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Brenda has uploaded some new software for you! View your available uploaded software from Brenda @ www. allnewoem .net firmware, it is even possible that for different firmware versions 4.2.6. I've got this program I'd like to make into a port... lo0 65535 79 0 79 0 0 Zynx ZX342 or DEC DE435, will generally work as well. For 100Mbit ______________________________________________________________________ DTE ______________________________________________________________________ PostScript, send a PostScript program in that language instead of 17.2.7. Thanks! searching the space of possible passwords. Unfortunately, the only SCSI devices are allowed (but not required) to supply terminator Do send applicable changes/patches to the original author/maintainer 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 2.0-RELEASE you can use the following: WD1007 controller. To be precise, it was a WD1007-WA2. Other # MINI -- A kernel to get FreeBSD on onto a disk. who proved to be a mine of useful information printer's entry in /etc/printcap). (including versions 2.x). FreeBSD version 1.0 included two different 6.4.4.4. Clearing the IPFW packet counters correctly edited your /etc/sysconfig then this will happen ______________________________________________________________________ domain ppp.foo # put your domain name here device scd0 at isa? port 0x230 bio preserving the original partition and allowing you to install onto the the ls manual page on the default printer: ip - print/set client's IP address the data to and from the drive. This cable is radially connected, so % man ls # terms of the software and make sure that the FreeBSD project will not UART considers the entire word to be garbled and will report a Framing subscription request for a local mailing list (note: this is more ISBN 1-55558-051-3 (Approved) /etc/printcap with the lp capability; see ``Identifying the Printer another shell so that you can create them before you give them to the pause 1 ethernet cards, a table of supported cards (and their required to appear. subdirectory called work/${DISTNAME}, e.g. Cache coherency problems, especially if there are ISA bus trap cleanup 1 2 15 Reported by: Jonathan M. Bresler jmbFreeBSD In the default summary that pac produces, you see the number of pages usually some instructions (which are unfortunately not always as /var/log is located on. make three megabytes (which is 6144 disk blocks) the amount of free with internal 16550 or an For example, on a sample FreeBSD 1.1.5.1 system, /etc/rc.serial reads: Two principals need to be added to the database for each system that operating system run smoothly. For this, there is no substitute for a PORTSDIR=/u/people/guests/wurzburger/ports make install UK In case of problems, please contact the hostmaster for this 4. The name of the author may not be used to endorse or promote products if [ "$first_two_chars" = "%!" ]; then specify the hostname of the printer as the first argument and the port job. Here is the DVI conversion filter from earlier in this document, pty is a ``pseudo-terminal'' or simulated login port. It is that has to be printed for every job, their ephemeral usefulness Data transfer rate is 160kB/s. LPD will not refuse a file that is larger than the limit you place on Enter Kerberos master key: For example, lptest 80 60 will produce 60 lines of 80 characters each. variables, etc. However, it cannot not access kernel source files, standardization has become more strict and is better adhered to by the type mount /tmp: Soeren Schmidt ``reconfiguring the kernel'' for more details on how to recompile your unit number for a wired down device is reserved for that device, even /etc/sysconfig file. 4. If appropriate, add ``dialup'' entries to ``/etc/ttys'' by Single Transfer Mode should be used instead. kernel. sio13 at 0x160-0x167 flags 0x1005 on isa where N is the number of the parallel port, starting from zero. If -s Make an accounting summary file and truncate the accounting Contact Ancot for availability information at: Phone: (415) Set to "1" if the -CTS line has changed 3 set speed 9600 And we will add this line to the /etc/printcap for the printer teak to When the NS16550 was developed, the National Semiconductor obtained `keyinfo' program examines the /etc/skeykeys file and prints out the 15. world, but not about how the outside world finds us. masters behind the ISA to PCI bridge chip. Hardware flaw, only there is room for the jobs of other users. file to your hard drive, and be sure to tell your browser to save get the individual files you need, but mostly they are stored in proper escape code, modify the text filter to send the code The obvious drawback to a header page is that it is yet one more sheet shared libraries, and if so, whether you have them installed in the LaserJet 2000 compatible codes. just does not work, you can use the scsi(8) command to dynamically can distinguish between a Framing Error and a Break, but if the UART o If you can compile a kernel, make one with the SCSIDEBUG option, /etc/sliphome/slip.hosts to find a matching line for the special user, 56: AMOS BOWL LUG FAT CAIN INCH /usr/share/examples/etc/bsd-style-copyright. for the printer teak): kernel that can mount your all of your disks and access your tape Kerberos Initialization for "jane" 10.3.3.1.8. 8250/16450/16550 Registers I can recommend the SMC Ultra 16 controller for any ISA application command which one you want by specifying the section: LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm ;; :vm=rfc1048: say, /cdrom. Then do the transmission is transmitted for exactly the same amount of time as Delete an entry from the firewall/accounting rule list % cd /usr/local v3.3beta021.src jpeg-5a what the heck was that anyway? ;) Before removing the CD again, also note that it is necessary to first place of 10.0.0.1. On the /usr file system in the above example this user is currently 15 C -- Start an X-server 2400bps, the CD signal to detect when a call has been answered or the The dependency is checked from within the fetch target. Sometimes we have to go places where no trusted machines or messages. If all your devices are listed and functional, skip on to The second prerequisite depends on the modem(s) you use. If you do 1. The BSD copyright. This copyright is most preferred due to its From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 25 11:27:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckfN-0004Ld-QV for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 11:27:41 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckfI-00008Y-VO for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 11:27:41 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id BB891144805F for ; Wed, 25 Oct 2006 08:27:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id B004A4A45A1 for ; Wed, 25 Oct 2006 08:26:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8A8F4144804F for ; Wed, 25 Oct 2006 08:26:32 -0700 (PDT) X-Greylist-Status: Sender first seen 3 days 21:51:32 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 38F2B1448025 for ; Wed, 25 Oct 2006 08:26:25 -0700 (PDT) Received: from 192.168.10.82 ([192.168.10.82]) by sinett-sbs.SiNett.LAN ([10.10.20.10]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Oct 2006 15:26:25 +0000 Received: from hasan-sinettdev by 10.10.20.10; 25 Oct 2006 20:57:16 +0530 From: Hasan Raza To: "Navin (NKA)" In-Reply-To: <369e612f0610231449v7fc448bap7d2a36fb72a51f54@mail.gmail.com> References: <369e612f0610231449v7fc448bap7d2a36fb72a51f54@mail.gmail.com> Organization: SiNett Semiconductors India Pvt. Ltd. Date: Wed, 25 Oct 2006 20:57:14 +0530 Message-Id: <1161790035.29460.81.camel@hasan-sinettdev> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Seperate Port Vs Common Port Approach Comparison... X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hasan@sinett.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Hi Navin, [I thought to reply to this mail as per my understandings. Others may correct me if I am wrong somewhere] It seems that the common port approach you are suggesting is based on the wtp session presence/absence logic. As WG folks already discussed on a separate thread recently, the unauthenticated/plain packets should not result in any state change at the AC. Otherwise, we would open up avenues for attacks. Moreover, I believe that the logics you presented here have basic flaws. And it does not give any solution to distinguish discovery and DTLS packets, either. On Tue, 2006-10-24 at 03:19 +0530, Navin (NKA) wrote: > > Situation 1: A legitimate WTP just now got powered and once its up, it starts > sending discovery packet to ACs. And once discovery is complete, > DTLS session establishment between WTP and AC. > Common Port Apporach: > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information for the WTP exists > or not. If not, it would do discovery reply. > * WTP in turn would start the DTLS session establishement by sending > CliehtHello message to 0x2FBF port of AC. > * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session > information exists (and FSM state is Discovery), it would continue with > DTLS session establishment process. Did you miss something here? Yes, I believe so. AC in idle (not discovery) state can receive discovery as well as DTLS client hello packets. The AC state is same (idle), and the wtp session does not exist, then how would AC know that the received packet is discovery or DTLS client hello? You definitely need some extra information to differentiate among the two kind of packets. > > Situation 2a: A fully functional (in Capwap Run State) WTP gets rebooted > accidently, and once it is up, it starts sending non-DTLS type > Discovery packet again to an AC. > Seperate Port Approach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * WTP in turn would start the DTLS session establishement by sending > CliehtHello message to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > information exists (with FSM=Run), AC will assume that most likely WTP > got rebooted and it would go ahead and reset (state=Discovery) WTP > session information. Ultimately, AC would continue with DTLS session > establishment by processing ClientHello message. > Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. Just by receiving ClientHello packet, AC should not tear down the existing session. To tear down the existing session, DTLS handshake should be successful. > Common Port Apporach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information for the WTP exists > or not. As it does (with FSM=RUN), AC will assume that most likely WTP > got rebooted and it would go ahead and reset (state=Discovery) WTP > session information. Ultimately, AC would do discovery reply. > * WTP in turn would start the DTLS session establishement by sending > CliehtHello message to 0x2FBF port of AC. > * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session > information exists (with FSM=Discovery), it would continue with DTLS > session establishment process. > Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. It is a doom, if we do so. Anybody could send plain/unauthenticated discovery packet and tear down the existing WTP sessions at AC. > > Situation 2b: A fully functional (in Capwap Run State) WTP gets rebooted > accidently, and once it is up, it starts sending non-DTLS type > Discovery packet again to an AC. > Seperate Port Approach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * WTP in turn would start the DTLS session establishement by sending > CliehtHello message to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > information exists (with FSM=Run), AC would simply discard the > clientHello packet. And would wait for the keepalive timer to expire for > the WTP session under consideration. Once the timer is expired, WTP > session information will be deleted, bringing AC in sync with WTP. > Ultimately AC will start processing clientHello packets to carry on with > DTLS session establishment. > Remark: WTP UP will be in close to keepalive timer value time. No. There is no reason for AC to discard clientHello packets. > Common Port Apporach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information for the WTP exists > or not. As it does (with FSM=RUN), AC will simply drop the incoming > discovery pacekt and wait for the keepalive timer to expire for the WTP > session under consideration. Once the timer is expired, AC's FSM will be > in sync with WTP. From this point onwards, AC will start processing > discovery packets followed by DTLS session establishment. > Remark: WTP UP will be in close to keepalive timer value time > As Pat suggested, discarding discovery requests would lead to delay in re-joining of WTP. > > Situation 3: There is one fully functional legitimate WTP providing WLAN > services and is Capwap controlled by an AC. An illegal WTP > somehow gets access to the WTP/AC's networks and can snoop > packets from the wire. In such situation, it can snoop legitimate > WTP's IP address and start sending discovery request to the AC > on 0x2FBF. This is a sort of DoS attack situation. > Seperate Port Approach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION > TO DISCOVERY REPLY. > * Illegal WTP in turn would start the DTLS session establishement by > sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > information exists (with FSM=Run), AC will assume that most likely WTP > got rebooted and it would go ahead and reset (state=Discovery) WTP > session information. Ultimately, AC would continue with DTLS session > establishment by processing ClientHello message. But most likely the > illegal WTP may not be having proper certificates etc, so its > authentication will fail ultimately with AC. > Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought > down by an illegal WTP. I believe if somebody implements AC like this, then it will be his fault to open such silly avenues for attacks. Existing session should be brought down only once DTLS authentication and a new connection establishment was successful. Otherwise, anyone can send DTLS clientHello packet to delete wtp sessions at AC. > > Situation 4: There is one fully functional legitimate WTP providing WLAN > services and is Capwap controlled by an AC. An illegal WTP > somehow gets access to the WTP/AC's networks and can snoop > packets from the wire. In such situation, it can snoop legitimate > WTP's IP address and start sending discovery request to the AC on > 0x2FBF. This is a sort of DoS attack situation. > Seperate Port Approach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY. > * Illegal WTP in turn would start the DTLS session establishement by > sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > information exists (with FSM=Run), AC will keep dropping the clientHello > packet coming from duplicate (illegal) WTP. Assuming Capwap Keepalive > messages continue to come to AC, legitimate WTP's session would remain > intact. > Remark: DoS attack was NOT SUCCESSFUL. DTLS session can not be established with wrong certificate/credentials. Illegal WTP won't be able to establish a connection. Draft clearly says that the new session at AC is established only after WTP joins the AC. > Common Port Apporach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information for the WTP exists > or not. As it does (with FSM=RUN), AC will simply drop the incoming > discovery pacekt coming from duplicate (& illegal) WTP. Assuming Capwap > Keepalive messages continue to come to AC, legitimate WTP's session > would remain intact. > Remark: DoS attack was NOT successful. > > > Conclusion: Common Port approach behaves nearly same as Seperate port > approach be it normal functioning or DoS attack situation. There does not seem to be any such DoS attack situation with the two port approach as you presented in this mail. Moreover, the implementation of common port scheme, the way you suggested will definitely backfire. Hasan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 25 12:34:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gclhz-0007IX-5X for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 12:34:27 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gclhw-0004lC-KN for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 12:34:27 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 663C4398132 for ; Wed, 25 Oct 2006 09:34:17 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id C62034A45A1 for ; Wed, 25 Oct 2006 09:34:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 87A6A398084 for ; Wed, 25 Oct 2006 09:34:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4543F39804A for ; Wed, 25 Oct 2006 09:34:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Oct 2006 09:33:59 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9PGXxu9000812; Wed, 25 Oct 2006 09:33:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9PGXxin002533; Wed, 25 Oct 2006 09:33:59 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Oct 2006 09:33:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Oct 2006 09:33:57 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B18E60@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb3qms0qGGwuzjnSYedui/LHu0xTAAqOLmw From: "Pat Calhoun (pacalhou)" To: "Scott G. Kelly" , "Hasan Raza" , X-OriginalArrivalTime: 25 Oct 2006 16:33:59.0367 (UTC) FILETIME=[5F6E3570:01C6F853] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Not pushing for the hack. I've stated I do not object to a third UDP port, but provided an alternative should IANA refuse to give it to us. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > Sent: Tuesday, October 24, 2006 1:24 PM > To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com > Cc: capwap > Subject: RE: [Capwap] need clarification on UDP ports > > "Pat Calhoun (pacalhou)" wrote: > > >Except we can document that any CAPWAP implementation receiving a > >packet with 'n' zeroes uses DTLS header format foo, which > is of lengh 'y'. > > ...except that it is decidedly *not* a DTLS header, right? > I'm having a really hard time understanding why you're > pushing for a hack at any/all costs to solve this problem. We > are at the design stage - if there were ever a time to do it > right, that time is now. Exactly what will break if we don't > adopt this hack? > > Scott > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 25 13:11:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcmIF-0007jJ-1d for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 13:11:55 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcmI9-0003rh-Fr for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 13:11:55 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id D32C839813B for ; Wed, 25 Oct 2006 10:11:48 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id BD5A64A45A1 for ; Wed, 25 Oct 2006 10:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5CA8A398079 for ; Wed, 25 Oct 2006 10:11:20 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 4 days 08:24:09 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A451A3980A8 for ; Wed, 25 Oct 2006 10:11:14 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1442519; Wed, 25 Oct 2006 13:11:12 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B18E60@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B18E60@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <321DE401-CD86-43F9-B262-01B7A33570E9@thingmagic.com> From: Margaret Wasserman Date: Wed, 25 Oct 2006 13:09:05 -0400 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi all, Just commenting as an individual contributor... I prefer the intermediate header approach to the third port approach, because I think it is a cleaner representation of what is actually happening. Different ports are used to reach different end points (different systems or different processes running on the same system). In CAPWAP, we have one port to reach the data end-point and another to reach the control end-point, because we think there are cases when the data and control end-points may be different processes or run on different systems. That makes sense to me. However, when we are talking about DTLS-encrypted and unencrypted control packets, we aren't really talking about two different end- points. We are talking about a single control application that needs to decide whether to treat each packet it received as unencrypted or as DTLS-encrypted, in which case it needs to be handed to the DTLS engine for decryption. If you think about it that way, I think it would be better for the control application to receive a packet that starts with a short header that indicates whether this packet is DTLS- encrypted or unencrypted. If the packet is unencrypted, the control application processes it directly (or ignores the packet if it isn't a discovery packet), and if it is DTLS-encrypted, the control application strips off the header and send the packet to the DTLS engine for decryption. This type of header might also allow for later expansion if the security world evolves and a better security mechanism for CAPWAP's purposes emerges. So, I would prefer that we add a short header after the UDP header (a CAPWAP control header?) that indicates the type of the encapsulated packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long enough for this header, and that would maintain 32-bit alignment. IMO, it should contain 2 fields -- a one byte version number (0x01) and a three-byte type field. At this point, only two types would be defined. I do not have a major technical objection to the third port option, I just think it is less clean from an architectural standpoint. I would rather strenuously object to the proposed approaches that involve zeroing out the DTLS header or running a packet through DTLS and then treating it as unencrypted if that fails, etc. Margaret On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > Not pushing for the hack. I've stated I do not object to a third UDP > port, but provided an alternative should IANA refuse to give it to us. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, October 24, 2006 1:24 PM >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com >> Cc: capwap >> Subject: RE: [Capwap] need clarification on UDP ports >> >> "Pat Calhoun (pacalhou)" wrote: >> >>> Except we can document that any CAPWAP implementation receiving a >>> packet with 'n' zeroes uses DTLS header format foo, which >> is of lengh 'y'. >> >> ...except that it is decidedly *not* a DTLS header, right? >> I'm having a really hard time understanding why you're >> pushing for a hack at any/all costs to solve this problem. We >> are at the design stage - if there were ever a time to do it >> right, that time is now. Exactly what will break if we don't >> adopt this hack? >> >> Scott >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Oct 25 14:14:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcnGv-0000ec-DM for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 14:14:37 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcnGs-0006ki-JJ for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 14:14:37 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 9F0711448042 for ; Wed, 25 Oct 2006 11:14:30 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id B4AD64A45A1 for ; Wed, 25 Oct 2006 11:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9DC871448020 for ; Wed, 25 Oct 2006 11:14:11 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by hermes.tigertech.net (Postfix) with ESMTP id 182EE144801D for ; Wed, 25 Oct 2006 11:14:09 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id o38so254718ugd for ; Wed, 25 Oct 2006 11:14:08 -0700 (PDT) Received: by 10.82.114.3 with SMTP id m3mr236458buc; Wed, 25 Oct 2006 11:14:07 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Wed, 25 Oct 2006 11:14:07 -0700 (PDT) Message-ID: <369e612f0610251114y6a2601dfi93d470bbd74d82ef@mail.gmail.com> Date: Wed, 25 Oct 2006 23:44:07 +0530 From: "Navin (NKA)" To: hasan@sinett.com In-Reply-To: <1161790035.29460.81.camel@hasan-sinettdev> MIME-Version: 1.0 Content-Disposition: inline References: <369e612f0610231449v7fc448bap7d2a36fb72a51f54@mail.gmail.com> <1161790035.29460.81.camel@hasan-sinettdev> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Seperate Port Vs Common Port Approach Comparison... X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e After sending this email, I realized that I had not put down my thoughts correctly. Let me re-send this email again. I will surely be able to answer your questions in a newer email. Regards, Navin On 10/25/06, Hasan Raza wrote: > > Hi Navin, > > > [I thought to reply to this mail as per my understandings. Others may > correct me if I am wrong somewhere] > > > It seems that the common port approach you are suggesting is based on > the wtp session presence/absence logic. As WG folks already discussed on > a separate thread recently, the unauthenticated/plain packets should not > result in any state change at the AC. Otherwise, we would open up > avenues for attacks. Moreover, I believe that the logics you presented > here have basic flaws. And it does not give any solution to distinguish > discovery and DTLS packets, either. > > > On Tue, 2006-10-24 at 03:19 +0530, Navin (NKA) wrote: > > > > Situation 1: A legitimate WTP just now got powered and once its up, it starts > > sending discovery packet to ACs. And once discovery is complete, > > DTLS session establishment between WTP and AC. > > Common Port Apporach: > > * AC will get the discovery packet on 0x2FBF port > > * AC will try finding out if prior session information for the WTP exists > > or not. If not, it would do discovery reply. > > * WTP in turn would start the DTLS session establishement by sending > > CliehtHello message to 0x2FBF port of AC. > > * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session > > information exists (and FSM state is Discovery), it would continue with > > DTLS session establishment process. > Did you miss something here? Yes, I believe so. AC in idle (not > discovery) state can receive discovery as well as DTLS client hello > packets. The AC state is same (idle), and the wtp session does not > exist, then how would AC know that the received packet is discovery or > DTLS client hello? You definitely need some extra information to > differentiate among the two kind of packets. > > > > > > Situation 2a: A fully functional (in Capwap Run State) WTP gets rebooted > > accidently, and once it is up, it starts sending non-DTLS type > > Discovery packet again to an AC. > > Seperate Port Approach (Proactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * it would do discovery reply. > > * WTP in turn would start the DTLS session establishement by sending > > CliehtHello message to 0x2FC0 port of AC. > > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > > information exists (with FSM=Run), AC will assume that most likely WTP > > got rebooted and it would go ahead and reset (state=Discovery) WTP > > session information. Ultimately, AC would continue with DTLS session > > establishment by processing ClientHello message. > > Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. > Just by receiving ClientHello packet, AC should not tear down the > existing session. To tear down the existing session, DTLS handshake > should be successful. > > > > Common Port Apporach (Proactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * AC will try finding out if prior session information for the WTP exists > > or not. As it does (with FSM=RUN), AC will assume that most likely WTP > > got rebooted and it would go ahead and reset (state=Discovery) WTP > > session information. Ultimately, AC would do discovery reply. > > * WTP in turn would start the DTLS session establishement by sending > > CliehtHello message to 0x2FBF port of AC. > > * When AC gets ClientHello on 0x2FBF and finds out that prior WTP session > > information exists (with FSM=Discovery), it would continue with DTLS > > session establishment process. > > Remark: No keepalive type timer expiry happens. So WTP will be up in NO time. > It is a doom, if we do so. Anybody could send plain/unauthenticated discovery > packet and tear down the existing WTP sessions at AC. > > > > > Situation 2b: A fully functional (in Capwap Run State) WTP gets rebooted > > accidently, and once it is up, it starts sending non-DTLS type > > Discovery packet again to an AC. > > Seperate Port Approach (Reactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * it would do discovery reply. > > * WTP in turn would start the DTLS session establishement by sending > > CliehtHello message to 0x2FC0 port of AC. > > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > > information exists (with FSM=Run), AC would simply discard the > > clientHello packet. And would wait for the keepalive timer to expire for > > the WTP session under consideration. Once the timer is expired, WTP > > session information will be deleted, bringing AC in sync with WTP. > > Ultimately AC will start processing clientHello packets to carry on with > > DTLS session establishment. > > Remark: WTP UP will be in close to keepalive timer value time. > No. There is no reason for AC to discard clientHello packets. > > > Common Port Apporach (Reactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * AC will try finding out if prior session information for the WTP exists > > or not. As it does (with FSM=RUN), AC will simply drop the incoming > > discovery pacekt and wait for the keepalive timer to expire for the WTP > > session under consideration. Once the timer is expired, AC's FSM will be > > in sync with WTP. From this point onwards, AC will start processing > > discovery packets followed by DTLS session establishment. > > Remark: WTP UP will be in close to keepalive timer value time > > > As Pat suggested, discarding discovery requests would lead to delay in > re-joining of WTP. > > > > > Situation 3: There is one fully functional legitimate WTP providing WLAN > > services and is Capwap controlled by an AC. An illegal WTP > > somehow gets access to the WTP/AC's networks and can snoop > > packets from the wire. In such situation, it can snoop legitimate > > WTP's IP address and start sending discovery request to the AC > > on 0x2FBF. This is a sort of DoS attack situation. > > Seperate Port Approach (Proactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * it would do discovery reply. > > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION > > TO DISCOVERY REPLY. > > * Illegal WTP in turn would start the DTLS session establishement by > > sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. > > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > > information exists (with FSM=Run), AC will assume that most likely WTP > > got rebooted and it would go ahead and reset (state=Discovery) WTP > > session information. Ultimately, AC would continue with DTLS session > > establishment by processing ClientHello message. But most likely the > > illegal WTP may not be having proper certificates etc, so its > > authentication will fail ultimately with AC. > > Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session was brought > > down by an illegal WTP. > I believe if somebody implements AC like this, then it will be his fault > to open such silly avenues for attacks. Existing session should be > brought down only once DTLS authentication and a new connection > establishment was successful. Otherwise, anyone can send DTLS > clientHello packet to delete wtp sessions at AC. > > > > > > > Situation 4: There is one fully functional legitimate WTP providing WLAN > > services and is Capwap controlled by an AC. An illegal WTP > > somehow gets access to the WTP/AC's networks and can snoop > > packets from the wire. In such situation, it can snoop legitimate > > WTP's IP address and start sending discovery request to the AC on > > 0x2FBF. This is a sort of DoS attack situation. > > Seperate Port Approach (Reactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * it would do discovery reply. > > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO DISCOVERY REPLY. > > * Illegal WTP in turn would start the DTLS session establishement by > > sending CliehtHello message (and fake IP address) to 0x2FC0 port of AC. > > * When AC gets ClientHello on 0x2FC0 and finds out that prior WTP session > > information exists (with FSM=Run), AC will keep dropping the clientHello > > packet coming from duplicate (illegal) WTP. Assuming Capwap Keepalive > > messages continue to come to AC, legitimate WTP's session would remain > > intact. > > Remark: DoS attack was NOT SUCCESSFUL. > DTLS session can not be established with wrong certificate/credentials. > Illegal WTP won't be able to establish a connection. Draft clearly says > that the new session at AC is established only after WTP joins the AC. > > > Common Port Apporach (Reactive implementation): > > * AC will get the discovery packet on 0x2FBF port > > * AC will try finding out if prior session information for the WTP exists > > or not. As it does (with FSM=RUN), AC will simply drop the incoming > > discovery pacekt coming from duplicate (& illegal) WTP. Assuming Capwap > > Keepalive messages continue to come to AC, legitimate WTP's session > > would remain intact. > > Remark: DoS attack was NOT successful. > > > > > > Conclusion: Common Port approach behaves nearly same as Seperate port > > approach be it normal functioning or DoS attack situation. > There does not seem to be any such DoS attack situation with the two > port approach as you presented in this mail. Moreover, the > implementation of common port scheme, the way you suggested will > definitely backfire. > > > > Hasan > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From ldxjwet@pmare.com Wed Oct 25 18:45:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrUx-0001BI-0L for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 18:45:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrUw-0005Tc-TR for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 18:45:22 -0400 Received: from cpc1-pint2-0-0-cust919.popl.cable.ntl.com ([82.2.227.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcrUp-0002Fo-Lx for capwap-archive@lists.ietf.org; Wed, 25 Oct 2006 18:45:18 -0400 Message-ID: <001301c6f887$38a81210$98e30252@family> From: "Limits Coachella" To: capwap-archive@lists.ietf.org Subject: article: owes come events Date: Wed, 25 Oct 2006 23:45:08 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6F88F.9A6C7A10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 ------=_NextPart_000_000F_01C6F88F.9A6C7A10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6F88F.9A6C7A10" ------=_NextPart_001_0010_01C6F88F.9A6C7A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Etc a Cataloger or Info products am Movie Book Comic Game mp Photo am = media. Says is upcoming require real names numbers report herechina fbd = Editorial or cartoonist ahead a his or. Etc a Cataloger or Info products = am Movie Book Comic Game mp Photo am media. From Drones am Music for Life a login register Home Whats hot This Just = in. It Happened Last Night Inside Spin Artist of the day am Reviews = Spinhouse Live Spinsider Podcast or Columns Kyle Anderson Peter. Cards documents pdf link met among dhs bureaus plan eager of sell. Controlcw Notesdavid in p Jordans of Blogedgar Fritzgive Bouncy am = quotcquot Jayson a Evening Godless Blogin Slays Mejournal. Nutshell messaging basic case shoot seconds upload is mms portal of = depending whether sent is addresses visible contacts is viewing anyone = visits am inclined. Luna tell thorough procedure or arounds couple bugs process running = smoothly sum am once. Newell Ptown Snarkerthe Northsider Reportthe a Contentthe Struggle is = Wmbd Nillyyou Gotta a Miles am Loopa Easy Curea? ------=_NextPart_001_0010_01C6F88F.9A6C7A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Etc a Cataloger or Info products am = Movie Book=20 Comic Game mp Photo am media.
3D"Delays"
Says is upcoming require = real names=20 numbers report herechina fbd Editorial or cartoonist ahead a his or. Etc = a=20 Cataloger or Info products am Movie Book Comic Game mp Photo am = media.
From=20 Drones am Music for Life a login register Home Whats hot This Just = in.
It=20 Happened Last Night Inside Spin Artist of the day am Reviews Spinhouse = Live=20 Spinsider Podcast or Columns Kyle Anderson Peter.
Cards documents pdf = link=20 met among dhs bureaus plan eager of sell.
Controlcw Notesdavid in p = Jordans=20 of Blogedgar Fritzgive Bouncy am quotcquot Jayson a Evening Godless = Blogin Slays=20 Mejournal.
Nutshell messaging basic case shoot seconds upload is mms = portal=20 of depending whether sent is addresses visible contacts is viewing = anyone visits=20 am inclined.
Luna tell thorough procedure or arounds couple bugs = process=20 running smoothly sum am once.
Newell Ptown Snarkerthe Northsider = Reportthe a=20 Contentthe Struggle is Wmbd Nillyyou Gotta a Miles am Loopa Easy=20 Curea?
------=_NextPart_001_0010_01C6F88F.9A6C7A10-- ------=_NextPart_000_000F_01C6F88F.9A6C7A10 Content-Type: image/gif; name="hundreds.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c6f887$38a81210$98e30252@family> R0lGODlhxAFEAYcHAAAHAH4ACAR3AYt5AAIAhoALfAB/jru9zMLVubO87zkmAGcgAHMtBpwRBbIb COIqDAAxAB8/ADhOAF1KAH9GAJ1HA8w4C95BBQBZCypnAElZAGBiCXpkAJlaCr5tC+pUAACIACWH ADp0AG50AIJ+BJmDDLd6Det2AACXDR+fAEidCVujAI2nAJ+aAMWhAOmsCQDLAC7NAE23AFjMAI7C B5LDAMOxCdfJAAfhABHbDUDSAGXpBozuBJzqCcfhB9ruAAAAOBkGO0MOR2UAOH0AS58MN8QAQdYA MgAuOxskNksqSWkbQ3YtO6AjPrUVRdUrSQA0RRtDMUA+MWtAR3cxOK5CQc5HR9dOSABqOBVWO0tu NWFsNnFVAKBbSsJVPt5dOgOFPxxzRzl9OlF5N4B/QpmIO71zQ+OOMgCbRyCSNDWtPFSYOouhM6eq N72oSemYNgGyQBK/Sz7AP2vHOne9QpvGPc67Tu61TgbqQirsP0HeNmjoNYXlPpjSObXhRufeMwoI gxgAiDYOfF8AjHMChJYIec0AfNoKeAgbdiYtfEkVdlIWi4MViZ4SiLkteNIThAcxjCtKe0E7glRH iIo9eKVDh7EydONGigpidR9thU1dim5rhXtnfZRYh8BbjutodgCNgiKMdD17hmuHgnZ4hZtzi7WN e+14iwCgiB2dhUubgl6jfHWufq2biMKohNqZgAuzeSi6hkfHe2rCgYrFfpW+g825dOy4ewDghhbi fTPajWHSeYfWhKPce8XqguHriwwBxxcAszoAtF8AuoYNzpwAy7wEvOwCtAImwCsdyjERv2sas4Qs zaArt7QawNYZwgA7vRFKyzZEymk4yIk0s5xNzrRJtttBwAZdtChrukdUzmpiw41czp1rwsZVxuVr zgCIzBp5xTuOv2tyy3x9wZ2My7yCw9aAuQCYvhWnyUGVvGyiwoOgw5+twcGYtN2dtQXGwxbGvDfO ulHGvnLEx57AxPj9/K6hnoKBcfAJAAD4DfL3AwAA//AA+QD1+fj//yH5BACz5a0ALAAAAADEAUQB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOq/GevpcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSHmuXCpxA9OnUKNKnUq1qtWrWLNq3cq1q9evJxmB HUu2rNmzaNOqXYsxqdu3cOPKnUu3rt27eIuy3cu3r9+/gAMLHkz4ad7DiBMrXsy4seO6EhNInky5 suXLmDNr3sy5s+fPoEOLHr25sOnBpFOrXs26tevXnU/L/us6AOzbuHPrZj27917blIEnCEBcuHDJ wG0fHz68OHHLzpE7Vz69efDKxZtXDx5de/bt3id3//f+/Lr58MixQ89+nrl59r7jV+3pvv7x5OqZ L1eu+X598eu1l56AAAK43H8DDmhcgpgtyCB+AvqXnoTuLfjYhRhmKFRkDh7IX4QFHkigh9DZVyKB DyKIIIkdbtaievvlVyKFJMpnY1T06VfgdTGeB2GDJ45ooowMtvchiDCGyNmRLBKp4oRJlqjhlFRW SdSOKh5ZZIfgicfedNRFByGJKJInnZhizsgeeSL+1+SIazqIpXSSWWnnnRhGlmKUc+pYZH9ZBqnl lkAaGOSfH8oJaJ+DtqngnD1KduOkS+Xo5oxO+vkkkGT6GGiZ/nWK6JCOGolpmQqOR+hkeLbqKmJ6 rv/o6Z+alhrqoQ+KuumtmUr4ootEyilqo6gmQOmxWzG65pmZ3dflmclVB6ab+5VHq5lsPjleqM8q ay2zl3UXqayTIWsuSZbupu667La72qvwxouhu/TWa++9Ccir776I4evvv6r11Ecf/BZsMJ4AJ6xw ZzkNPPDBEEdMV6wJ57PwxZQp5HAf53ZMmMWUgZxAPiSLLLJkJ4ccMskjnwyyxSXHbJnMLcscM8ss T5ZyzijrXLLPN49cGcw4uwy0yZIa5LDHTBMmdM9QQ73zZTCr3LLVRlOtcspPr2y1z1h/HXXXUqOc 9dlJk1VK02xX1PXLM5Mtd89oIx231kPfvbXOeSP/zXXWYz8Nt9+Ygdz24WblWHXgQk8dd9186533 5GLTHTnfhFNOtuODY154nRKHLnqrl8+9eOlR2w333KybnfPNRNtcdtiNS+4y7LN37jrUo/fu+8QR lf633MOnbjzXrfct+fGUV1382JwzH72xiFcfmPCPa+46z6vXvvznz19+uvS2V7464dNbrz5Xljpu POPT3453+eFD7/7Vm2sev9f5U/b7/wA8Sqz+9rOVIW9qP5Pf9462vaLJDmxi414BI9g3nPGvZq9L 2/o2mBaMeRBjHAwhWj5IwoSJ8IQoTKEKV1iRALqwJWl4oQxnSMMa2vCGNGShDndIGBxmCAs+DKIQ /2FCsCEa8YhIlEkLFMPDJjpxL0mMohSnSMUqWvGKF3qiFrfIxS568Ytg/Moewsg2LJoRMTE4oxrX yMY2uhEouXijC3EhRyaS8Y54zKMe91iWOvrxj4AMpCAH6ZNN7ISPiEykIhfJyEY68pGQjKQkNULI SlrykpjMpCY3yUmXPKKTLeEFKEdJylKakl8ASOUpbUKxEuImIbxBiCtnSctavmYstrwNLFezy1z6 8pfArIxheBJM1tDEmDMppjIx84HPNHOZrnlmvkiXgFSmUmHXnAwAYHPMdyUzAR8IpzTBKc7JjJOc 5ZRMOCmzTnOyM53gZGdlytlOdaKznud8pjj1uf/Pde7TnP7spzrhOc931jOe9lTNPwcqUIae06EO leY4m0nQe+pTngl1VTU9mE3JbPM13QxYMiea0ITmE6MHxSdCV3rRkqKUpCRdqT1j6lKJulOmNb2M TW/KUoVilKcutQxMUcrThw41p9OEVUQ+WhlrftSp1czmNq2pTalG9anabOpGPepRqVKVql3t6Ed7 mZqEPBSn8TypPCk6U3fuFKEtFWpb5+rWgp4VqT1F612LKtd/UhSf6WTrT4FKU6LKda14JSxc5TrM nTA1q1llqmSjCtnITnaylJlqZbmK2Y0+FqtJjQkyZXJWo+L0pIIVbFr5ulpm0lW1dI1tQVm72Nn/ ZuatN5WoTWFqWtvKtLRBDSpb1TrY4eo0tHZ6LFcjW1nNbtazmeWsZUCrXOduFbrPDWlqihgT3cJW tqhdbFz5CVjNtPSi4X3pQX9LUPIGtqIl7S1uYfvd4BZ2ryz1p117W1xyutaOEFHudbF7XetuFaqf la5WFYzg5l4VrOWSJS8Rkl7EDra17RyvSevq2p5+98OHRWpM8atXoG44p/2sb4kVe1u7upi4AA0s WuPZWJ0IOMGdNbB1dazg6Er3sg4WsP++KVLSuvjIJk7teRe607jOdrenjbJvadrkzfBXvorl74V/ u+ULg9jJWj6xPAH8kAEPeMfMTTOBC3yZz6I5/8dnXi5ZSQPLERuWxaatsIYPO1H6sva+P63ylEPM 5fhaWLYsTnKIjyrmtzrZ0PKscU7C+lSwwtmpkv2qj8283K5Sms3LhepytUuabjb0njEOKDzzjOTW Cle/ALXoPFNaUUDTs6ELJXSuB1poJt8WvkaVcar/uuq1Zti+gQadUiHCGiF7xtnqmvNopA3NYJK4 2rp5pqRx0mzSQFtdpB5NuLENzGuT+zXSJPMk103GVbr73fCOt7yJwu562/ve+M63vvfN735bxR/+ uGNjSjBvNfrDKE4ouMLrePCFO3yVAH84FgEgcaQ0/JJeBIC/JRLwjeNb4yoEuMfrDXIWdtyJ6f+i 17iDuXJx94TigLz4KfHV8l/WPDQvrzgbV/Pt7BIZmjcHDU9grnM1Plg0Pe+0skWL7W4K4OkCkAzU nz6ZqFc9AVBH7k2IDi9YFN0oEkkwaJJuZmoHE5ZWlzrWKWP1tLtdgwwp+cg9dmPLXtPSV62qVbdq dmAmJO1sr0zU2x546jVE7lZRgleWIfChT1fNlwVymj8adFvSBPBXD/zgBb90m3DdTvUI/dcbc3QG Bzm6OK5M5Wt5+apTHfODx/zatb6v0It+9I5ZsHMvjfreD1km5G695jm/+cIXzPb1wP1cWolV0LI5 9WqGO0HI/XfiW3/2ajf8Weoxd6mIHdTP973/6bVfEOrLEvDFz/7bs999j9FH1J2+NPxFDdrV09Lp U8d6/rOv9qwrH4uttGmvJGHV1nei0X4phBlkV1YECE0GGBoIeC4p1xr2d24VeG6W8X92EYCxdBAY 6BkP+IGZEYFPMYAeKIKlQYDasC4reDEtSH4kiBKY9ngQ2IAoeBm99IKToYOVoQ0+uIM+yIM7KBk8 KISZoYNB+II/OISUgYTSF4MU8XICWGo/d4MZ+E1BCIRGmABF2ISX0YJdyBlZSIReCIZk2INeSHsa 2Bipt3uWBmGUV4VW+HuitYJ2mIZomIdniIddaIdL+IVMSIZmyIWW0YVrqCE41nwLFmqd9xJz/4gZ x3SHetiESbiHhKiHfaiEmKGJQ2iGRmiIh4gh0LdmcUaHMPGIl9FNfxiIeEiIToiJaPiKhciKYDiI fwiKoQgXYUd/0fdgHfWEAoGKlpGDYTiJkmiJe9iHrciHy+iKZ9iFIJEMIyeFi2hgnGaKjiiM2OgS ndiMlyiIzciJ3ciKzEiOtoiMK5iLcRF2NEiKYjdWNiiMsHSHsniJTliPlsiJ+BiI+HiOgAiFGUGN m1ZpXiVWjciN2sgqWHiLlfiNDcmFYziLWqiFq0iRtViRSCiOl6iOuhg8uhSPqJiD6rKFyNguLQiQ KmGCBpGQEXaC36gbJEmSMNmSKFmTsvEANv+ZkzrZNhzZkz75k0AZlEIpL4YwlEY5SMewfB0RCzvZ lFNxlFAZlVI5lE5ZlVZ5lY40lRKDA1rZlV75lWAplCw5lmQJif/HgWWZlvIYSQagEBMIGua2GnG5 Xl2mLnPpS2EWl6kRl1aUDQZzauZlYrlhbsAVXOuCX7hlmAqTl6yBmLO2U1JZWB02Y7dBmMelmLvh mJj5QYwpl7+WmAgVmYeWT/SETqmmUzK2arsGUah2msR2mrbVZKp5bK+mX8IGbKkJWHTZmr7GYYCZ VrpZWhkGbKtVmKLJYSvmX7EFY3+FnFImZoEGZYpmaIyGYZepnMU5mcDpnDDGZUMlmSolmXf/hmSn 9kyRmWsqNl+FlmWH9py1FZvtyWqpFZ+uBp91dVfV6WdeRp/6yZ6CmVu/hmcHGZR2Vpje+Zsp5p37 CaCLZmyrmZ3upWq31mIoxmuDxluryZwKCp4Oipu0yUxgllFRWaDXWZ2EVqHTCZ20VZ/HZVzJ6ZzJ xp0X2p4nmp/1qaGa+Z4t2msDCpRUNpk22l+Mtl521qAyaqQK6pslSp9CyqQp6mq2GWtNmqKPdp/r 2aMSJxGAuVewZlLwxZvqpVfFhpq99qV5xZpgaphdWpy72Zte2qbvpZsYtqayhqYGpVuo6V07xW9v uZlq+acYw5dn6ZEnCqiGypkguG9huaga/7gEjKqBWBmpaPGolFqplipIkpqpZHGpnNqpnnpFmhqq XvGppNoYonqqqJqq1lOqrJoYqpoQw/CqJ9GqtIoXhYELsroWvpCrWGECvPoXtbpJoWBFv1qsxnqs UBSsyrqszPoqgSEEyIpvzTqtMrEC1HqteRGt2toR2Nqt3vqt60ioh9qB20opfTquogGuV4SuFFir r1BHksEP8soP8Tqv9BqvlEGv81oZ8pqvCWCv/Xqv+DoZAjuwBPuvAOuvBGuvB5uvAVuw+pqw26iu SPSv/gqxBiuwBVuvF2sZGNuwIIuvG3uwGquwI3uv/UqymkGxVTSyFtuxL2uwKiuyl4GyL/97svwa szlbsjBrsjGrrzWLpSwbRC67sUBrtB77szrbsEC7tEvbtEnLszPrsyVbtEI7tBIjERobsDuLszl7 swjLsGBrs/wKsBErtjyLtF5Ltme7rxlTriGktjv7tElLs1ZbtXU7tQoLtj3LtCrrsjSZEs0At1TR E3ILsx+7t0eLGSmLsEHbtwvrtofrs3a7slgbRToLtXyrtF/LsYCLtHlLs50rugO7tg7rtC+bF1Nw uYehJwkrsZkbtqP7sGJLt6FrsWZLt7D7uly7sGErucBIuLNxruz6GawLQGhZvJ8hvJNCvMr7vNCr TBmSvNFbvdZbS2uBbb94va2RdAuIrs7/9r2qcRXOmxkzGBpCdr6cIb5t5hrpq4CZhWnWWF3r+2yj uIgCSHbQ9m3se43uAn/4O4X1q3SbMb3iOnaq8b7PBb8Lo8BaVXfPRb+bsYC/yL/tu8BNtb0C3Iuz 5L0M/Bn9C4M4QkyjQb8EmWlTBWFKd8I/9lV4l8J3Z1UwrHca/Ibb+74Q7GABnHelB8A95oaaZsPV pcErHMNE/GYyLMOQxYsEGVY/FsFthnc9zMNA/Gks7FnZZMDMVsIZvMJm5sBrlsJLjHrOB2QG+X00 CMYcLMGctr/xN4VvFmcG2cYTDMXwm2mWxVySx1nO98BlvMNtSMZ5rHvRJ8Zclb0l3GBe/8zG+SvH PjaKvHe/bnyNOczI4IfBjOjFj/zEhUzA/qvDmIxZknxgpAx5dyx+CxzInazAexzGIkwW3laNj9xZ 8SvEd7fJpvzGPIbGn0bJ7WjJpOjJvEhpN6zHjjzG0zXJnubJb3zMpnfCt1xVNOzMqTyDMKxphSzF rpxgiIx0srxZfZzK7VjKP3x6ozyQzHxjPlx3aizKmKzL24zLFzzOmZzM2hzP2JXDpny/wvx4+oxm 9bzL0UW+xNS/bIzG4dzPnezMkSx+xVzPcIy/7DzPzUzLjHzLePyO5vvByBzAAp3L1FzOwEzAqtxj BObOJs1jBfPJG52/Nhy/OzzFzaXNDf+9xNFcy3iM0/O7weFLf3B4xS59YBg9kG6WvghWwZb80eU8 zQUmVtj8zj69d1G9d71MWVecYCvNvSF8g1utjV2dMBhCDOX7pz5clmXNrl8N1vzCvWw9rn9EvW0d 1yHJQmPd0vT8S9aYG189xNCU1grz1gfMzFbM0XfNcwMcyiztvhOswpMXy83G2DH9zp0x1UTM1KV3 2TysQ28ZvpFtwfYy0sGMG55t14mtLry8wZJdxxzM0UpNzlcLgMEjxIDsyJB90ViMwv7MwxE9xXFc 0T/t1JCNwS98dEx826FW2ZoBwUddkM0H3Iq40SHc2nmtR/IswLtMy18syCTtx3a8yif/DX7SXYoU ndvUpd1nHNmkbdLNzMer3HPX/L3hfb6aTcIQLc7n3N2uHNG8LL8C/dzQtXuozGOE/cClDMmoXNqz XckBHtKFrb+LvOClJNMJvuC7ndJVbeH63Xv+rVkA7t1QHcVD7doAzWCM7cLAnNcWLcfWbL6cndwp PsqAHWAdbd3UnNQLjt0CDsWqHMcdbuGnLc6c3Mcj/t+pfdcoDs4M3uIDXuH4fMh07Xj1rePSvN/V qNQmzOTxjOOg3ORUXeEcDtFD/uWCndzVvd5NHtr/rNCNDON+FBnzZ9TRHMRlfb5BPMvFTOV2vuHf XNVv3uMZzNz5zNQvfuEgrMJv3svq/zvMfy7bwkznv43C8LhCdU3W6+LXbW3pmRHh1Yvp6S3X6Lsu xxvqbsS8NZkO8yHq6krqqt4QqJ7qq/7qCNHqsj7rtO5Hc1DruE6rJsAvsA4RDqCtuU6tvT7sxF7s xn7syJ7sym6swd7szv7s0B7t0q5Gy75HBFDt3VcA2L7t7jftrcrtcOvt4j7uQ+np5n7u/qIv6L7u 7A7qjgHX7R7v8r68T0nCh3DvhyAZ+H7vk5Hv/Z4A+F4ZAQ/wA08Z+x7w/v7vB5/w+i7wAC/wC0/w +c7v/c7wFh/xEQ/xFL/wCb/vGj/xBq/xBB/yBo/xDp/xFe/xFN/wHC/xCF/wLf/vKf8/8gp/8S7P 7yv/8DE/8zk/8R7f8CT/8y3/8w8f9K8NGcFj8UUP9B0v8w6/9FBP8kCv8JrB8DqPGVbv7z3f9FYP 9V0v9V7/9FOf9U4f9Ep/GWdP9ZnR9T0P9mxf9lF/9TLf9lsf920P92Yf8mdP9mkf9mPv9P6OFl/P 91Mf90X/9ZbR93KP9SfP+Eav9UsP8mJv+Hhf9m//9pQP+U2P9mC/+Jzf+IWv+JE/+Sz/+FSv+XY/ +pXP9KNP+Hq/9lK/+apfuDwx+I1P9olf+LAP95Lv+Gqf+6a/+L1v+VW/+7rv+aXv+L2P+Io//MD/ +qHf+aqP98OP+qWP+pdP/Mrf+qD///vPP/2e7++PIREdj/Mnj/liT/TfP/QHT/rOz/vJL/myH/rt //GTn/0QX/yHf/z03/4oDxAJEhwiWHCgwEMIBSpcWNCgw4UNIx5kSDGhxYMXE250uJHhxYoTMWIE qbCkRYMRS0KcePLiP5gxZc6kWdPmTZr2dO7k2XOnS4oSPaoUGZRo0ZUtjYoEelLiUY0aKwJ9WpTp 0ZAmrzp9CnLo1aparS4N+tWoU6lKsXqdmhGhVLRCsYJla9bt3JBJyVL12dfvX8CBBftsqjRtVsRk 8xoeu9Ru2JEEP7IMy9WqXsSPD6utexnvY7xlz4Zm+5nyYY9Rxa4d7Vm0XdhgF2fl/zvY9m3cgEfr La14s2XMq12PlP1xq9rZw1tXhtwbqkrgnxVDPhs8Lm3pxAdq3gs9dFfvmEtbZ/09QW70uHHafPvw NNGUDSVvn49Uekeu8TvOfXicP3TK5Ksvs/jaM8slyVaKrjn6CmwwQe8q2488BvuTrzv8qjPPwrce bGnAAJcTkaL1SjTxRBRlamxFFlt08UUYY5RxRhprtPFGHHPUcUcebUzxRyDR63FIIos08kgkk1Ry SSbHSu9JKP9qckoqq3QxSiyz1HJLLrv08ssngbRyTDLHBPJMNNNUc0020XyiTTjjhLNMOutMUk48 89RzTyCP4PNPQP+hMK8MDXQMqf+U9lvMwQYBvM7Qy/QLTkAEEyzUUQCfClRNNzb1VM8jQkWRCUCN +dTEQbnLjrqkeKvqUe1afdW+riZdbsHiNmPoVF57PVVUX4M9k6RFcy3u0GOHshXWtnpj1i3nMBzL MsbAEvZabNcENltucSJ2N2ORwy7Zu1g99rVZxdUq2riopRa+9xLodl5667W3xG+dFRetS6eCEN5z G+1ONIHVvUvXdqdl8bdd73X4YYjjFPIrihk0d1XhoDW42ueM882/cjObbuTtmKMITC39QHllllt2 +WW/OpTZQKpExjjkg82TizOWopU244SVU9fV82A2+mikk1YaMDGRdfppqMEFr63/fWcrLDGiZzZ5 Oly3FshEWSIWe2yxhXS65r04xBoiRXcbEFK4r167PgURfTtA4BSNl+V+lvb7b8AD78tOwgvfUXDE E1d88dwMd/xxGRmXfHLKUSabWygu13xzzjv3/HPQQxd9dNJLN/101FNXfXXWW3c99cpjl3122mu3 /Xbc0Zsld957933x14MXfnjif/z9eOSTV375wIr/fB/no5d+euqrtz545rPXfnvuu/f+e/DDF1+n 68s3/3x7x1d/ffbbJ98mAABAf37665fYp/iVv8R9/vsHf6b42U+AAyQgkAKIJjgUUIHWQ8MCHfhA CNLPfxOkYAUteEEMZlCDPIlgrwc9+EEQhlCEodtgCU14QhSmUIUrZGELXfhCGMZQhjP0ywhteEMc 5lCHO+ShnMzRQyDSi4ZDJGL4fqSCICZRiXsSnwuKiLIoPLF7S6SimpqxJ2JUMU4LqKIltLi6E3BL imMk4+++eEY04qmMa2Qj7dL4Rjh28BdxpFcZ6HhHPOZRj6yT3x5R10bwxQ8AgKwgTabgx3oJso+I ZGQSBdnI0iGjJoRMXv4oWUJIZpKKAQEAOw== ------=_NextPart_000_000F_01C6F88F.9A6C7A10-- From ihamgpvclxs@pcnetsol.com Wed Oct 25 18:45:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcrV3-0001D4-Ch for capwap-archive@ietf.org; Wed, 25 Oct 2006 18:45:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcrV3-0005UT-9X for capwap-archive@ietf.org; Wed, 25 Oct 2006 18:45:29 -0400 Received: from cpc1-pint2-0-0-cust919.popl.cable.ntl.com ([82.2.227.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcrUp-0002Fp-OA for capwap-archive@ietf.org; Wed, 25 Oct 2006 18:45:29 -0400 Message-ID: <000801c6f887$38ce37b0$98e30252@family> From: "BlogThe Return" To: capwap-archive@ietf.org Subject: arrived WXCL studio Date: Wed, 25 Oct 2006 23:45:08 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6F88F.9A929FB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f ------=_NextPart_000_0004_01C6F88F.9A929FB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6F88F.9A929FB0" ------=_NextPart_001_0005_01C6F88F.9A929FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Universe is stations studios newspapers am bought sold pork damaged = somehow rest entry raquoclick icons link in sites. Havent even a finished my am yet im of up too thats is not including am = boxed sets again is anime yet Without would never. Universe is stations = studios newspapers am bought sold pork damaged somehow rest entry = raquoclick icons link in sites. Podcastwhy Flux buying tshirt Wear proudly Meta rss Wordpress Email = Phone copy fca Stuff Peoria or Pundit River Edition Stats is Whos in = Visiting. Lahood Lahoodeye Candyemily browsing category of naming mecurrents event = Funny a membersa Quiet Rooma Midwestern Road Less Dramadeo is lex = Rexevans State Treasurer Chaos am Called Homeout Projectthe in Orange = Streetthe. Windfall Chronicle Muni Wifi finds budget vicious in lies is spread evil = Select or Month February in January. Rndstate Candidate Leonard Drdstate David Leitch Rstate sen gov Rstate = dan Rutherford Rrdstate Shadid Dthsteve Umholtz in Attorney rep Lane of = Evans Dthus rth Barack Obama Richard Durbin in Dillwhite Accidental. Prince Campbell Today or daily asks website anything in responses is way = promote peoples of toono a Tags Rumors aa Tired relying Technorati = Google aggregator in needs is. Government in Idposted deptrfid is Department Homeland Securitys a = Integrity Advisory Committee draft poured cold a water identity in = cards! Cell Therapy Causes Cemetery is Pharaohs am Mars Mission or Missed in = Lifespace Elevator vie Space or Record. ------=_NextPart_001_0005_01C6F88F.9A929FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Universe is stations studios newspapers = am bought=20 sold pork damaged somehow rest entry raquoclick icons link in = sites.
3D"DZ"
Havent even a finished = my am yet im of=20 up too thats is not including am boxed sets again is anime yet Without = would=20 never. Universe is stations studios newspapers am bought sold pork = damaged=20 somehow rest entry raquoclick icons link in sites.
Podcastwhy Flux = buying=20 tshirt Wear proudly Meta rss Wordpress Email Phone copy fca Stuff Peoria = or=20 Pundit River Edition Stats is Whos in Visiting.
Lahood Lahoodeye = Candyemily=20 browsing category of naming mecurrents event Funny a membersa Quiet = Rooma=20 Midwestern Road Less Dramadeo is lex Rexevans State Treasurer Chaos am = Called=20 Homeout Projectthe in Orange Streetthe.
Windfall Chronicle Muni Wifi = finds=20 budget vicious in lies is spread evil Select or Month February in=20 January.
Rndstate Candidate Leonard Drdstate David Leitch Rstate sen = gov=20 Rstate dan Rutherford Rrdstate Shadid Dthsteve Umholtz in Attorney rep = Lane of=20 Evans Dthus rth Barack Obama Richard Durbin in Dillwhite = Accidental.
Prince=20 Campbell Today or daily asks website anything in responses is way = promote=20 peoples of toono a Tags Rumors aa Tired relying Technorati Google = aggregator in=20 needs is.
Government in Idposted deptrfid is Department Homeland = Securitys a=20 Integrity Advisory Committee draft poured cold a water identity in=20 cards!
Cell Therapy Causes Cemetery is Pharaohs am Mars Mission or = Missed in=20 Lifespace Elevator vie Space or Record.
------=_NextPart_001_0005_01C6F88F.9A929FB0-- ------=_NextPart_000_0004_01C6F88F.9A929FB0 Content-Type: image/gif; name="developer.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6f887$38ce37b0$98e30252@family> R0lGODlh3AFIAYf2AAsKAIwOAAV/AH2ACgAMfHYGiAB5hrq8y73av7G8/jkeBGIRAHgmAJkVALkp Du4iCQlKACxNAEpKBlI6BHo1AJo3BbMzB9NBBANkASFZAEtlDWVcCHpmB5RUAM1YC+JWBACIDR95 Bj5/AGJ7AHWKC6B+AMFyANlyAACYAB6dADacAmqXCo2WAJOhAMGWAOOqCwC0ACC7CUnACme1AHrL B5q/AMiyDtO2AAXTBxvbAEPYAGTjA3LYAKDZAMHaA+rnAAALSSQJMkkGTVsATHsMQpEASL4ASd4A QgAsPRcWOUIWSVQtRnMlTZojO7YoOOAmPQtCTic3OExFSVNHNX5NOZUyRbE0ReRGRwpaSRZiPEFj NmBSS4xiEJNnTLxiQ9heOgOMORiDQzd6R1p/O4Z8N6N9NsiKStuMQAChTBWiMTesQFmXN3aXSKSd NM2nQumfOwDAQhizQECxR2zLQY3EPZG5RMfGStbFRwvYSyztQ0LjM2XYPo7uOJTcRcHlMtHZRgoA cRQAdzsAdVIGgXYAfJYLdc0AcegMgwAaciEqgEgqgWgjfXkSepwUg8cgfN0bgwBDch9NijZKcVI7 fHM0fJc5f7o4cdwzjQdndShch0BdilJbdIZVcZ5ZibdddNdVgACOfCuGjjp7ilWJf4V0fqxyhs1y fOh4fQCdeRWVh0abfl6ZeYukh6CXdMGsgO6bfgC0eCm7hk62dFrOdYy4eZXJeMrOddS1jAPpjR7o e03UdVHRgHPud6PlisLVcePleAAAuBYAuD4Ax1YAxXUFw5EJv7sNu+QAzA0RtxEjvjktv2gRxooo wqQZy7oYy9EZswpIwyA0yjREyWRHyIRFsZw9w8szxONBxwpbxC5RyTxVu2FiuH9iu6pTurFhx+pd wA1xtBx7wkB9zWl7zHt2zqyHwbmKytF4ygObwCWZskKbwmWTvYShw5GWuLaUuOSpsQ7MtSXFuDq/ s2rGwXjJt6O3w//97ZyWnI57hv8LAAD/APD/BgkA8v8A/wr//Pf/8iH5BADG7nUALAAAAADcAUgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnPjQBsWLGDNq3Mixo8ePG+2JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bnW7aBKCzp8+fQIMKHUq0qNGjSJMqXcq0qVORIKNKnUq1qtWrWLNq3coV4dOvYMOK HUu2rNmz9rqqXcu2rdu3cOPK/Ye2rt27ePPq3atzrt+/gAMLHky4sOHDiBMrXiyXr+PHkCNLngyU seXLmDNrnku5s+fPT52AHk26tOnTqFODRqC6tevXsGPLnk27tu3buHPrdm2gd+/dwIMLH068uPHj ZRMiD765ufOtRwMsn069+k3pJLHbC8Bdu3aR2KV//9++vTt3k+bBmxe/vnz2kt3Lt8+eXn78+fZH 1rd//r3//ODBh158/5HnH4HWJSiWct7pd6CA5I0nnkrfTQghfQUGmKGDDo5nYIHhcejhhQ2KeKGG KFqY4orPtegidCV6qCKKK354kozo5VhihiPaOCONNgYY40pDCijhie9VyOF7LzbpZEZEfojjkf+F mBKOSEa45JZBbvljkFOaGOWOHSLZ449fdqngmmUpaaSZIuKnH4HrsZeelVhyOSed7fWpI4J1ouRm klnuR2aX/bFZ1xfCKUdjmBuq2OONiOYopKV6PlpppAYeKiinVH4qJZwjPeliGYaR8ZaXOhY6qktf 5v8Za5aa5gmklhpOCmKrGx64H5DfmSrssAuxFOqrakpKIaGuzonprbU+q+mrunI5qKdKHlutotyO JSOC6k1aoZzhhtenn87SNyh89QU6oqFJkqvnr/IJSueJx3ar77789uvvUI7+exqxBBcskMAIJ6zw wgw33HA+DlOmRcS7QUySxfbkozHGGIvU8cUXa5xxxxZDvPHJJqE8MsoniyzySB+/7DHMG9PccsYl mewyyTZzTPHPyXnl88wwE110yjgfLXPSPJ/E88dJhwyy1EpPfbTRRJfc9NZQSYSCwWCHTZFKQ0Nt cs5OR8101FCrbfXVcM88dNE+m/12zFmz7XbcQPf/fdbZWMuNNtJcz/324XvbbTjOdSMNN95rN562 3ygFQ/lXTYMMudVl5+240zWvXHPLgJc8uOl2P06656jbHPjlsIOVOd2Dc1614J+TnfjngF99dupY Q2664MLHbrxRAc+OO983e8745Cv1zjzttksf/OHDN158WmJ3/w8g3l8Vd+aLu5091bWnb/3uNKs/ fODKn9++2h+Hb//9GLFkduiu5864y+hDXM88drPVkWxzIxug+tA2OvQ1r20j4cDxJjiTgFHwJPjL oAYbcsEOevCDIAyhCEdIwhKa8IQoTKEKV8jCFuZmgzCMoQxnSMMa2rCGLgwhLlp4w7cso4dAFFsO /4fowSAa8YhITKISl8jEsZ0FFESMIgq/IcUqWvGKWCxKE7fIxRtm8YsN66IYx6hBMJoxYWRMoxrD dsY2+muNcIzjk9xIR33JUSIpuKMe/3ISXdTxj4AMpCCDokYeMKQIe0wkYQbJyONYMDaPrKBXGkkZ F1Hykphk5AdesknddFI1jgKAKHkiFlGShJQ+iaRMojHJD7jyk/Z45SdhGUtZjsSVJMHlLXP5yl36 8pa41KVINinLWZakk7asZTGVOctgLpOZKIFlMof5S5pMs5jCnCYvdfnMWOZSmcdMpjR9STB7oJIs phzJOfsySZv8IxrwLIg3fTnOeVYTmdI0pjGpaf9PWvJTmN6sJy2J+c17/hKZJqnnMQ3KT3vORKEN jWhCvynQg050l/vkpyVRsk6RjJKUHzVnOnkySnWOVKQgVWdJSKpSlHq0pCV9aTrNuRR4wtOh1aTm QBdK0IBi1KLz9Oc/+4nTnv40mgUlKk6XulCJBrSXxMxmL32aVIY6Nagn2SlCc+rQnvpTqK7p6DlZ 6lGVznSdJEUlWWl6Sra6taxqNWtb31pToX61qDzFqj6BatSLGrWvVD1qVpO6z7uqJKP0BKZgn3rR qkI0sY3VKV6bKlm7ghIhYm1rXOE6V7m2dK2fLatmW0rTsZZElTFJSDMBG1iJEhShWw3qVGt52KH/ tva2+ARoV2crW3HyFqgFRWxfWbtUiIK1oVDlqWEdS9vBEiyznnUraEEK07mCVrSllela4/rRmXbt IOw8iFYnulOKDnOrhUUuU23r0/FWNaIVhWxKlmtY4TIzmIOlbFdra17zlneb3GTqJp9rEtNuNrvR nS5nVypX7pL2uqdtZ01Um9cK59Sr6BUnZMEa29da2KnG5etK6OtXgy73vfvl6nsB61UU13eiG+Uo gxMcXQTbWLonGet2cbxg0XZ0KfFlL3xBjNf0XjW2tFWokYcMXCQzmblN7q9k8+ta/ap3sR0WMWX/ O7BJhhSlKcVuWmMK5rceuLMi1S6P2fpltqIW/yaO6uY1bSln8n54uOEcblR/y1ttplinzvStbu/J ZzxDc72HdvFU8wnVa1I0wMUl7HeFpZMfu8TSyJMwTd4cseMip5MEOcMcb4LplZRai5qWJHhj5+ni fDLGH5SEJDJJ69vIuta4ns2tc/0vRU5E1r4ONlZ4TexiGzuFwk62spfN7GY7+9nQjjbBfCHtagfm 2NgejbW3ze1ue/vb4A63uB+S7XJ3htOoXrVn0A3ncVub1C1ZJ7v3Mm+XuHvZKmnzS06NXd0I4N8C EAnA/z2SgBfcHgA395pMCxN+0/U2Bhc4wkli8Ihb3GERB2NCoFtamJ6UzF8Oc73zkpCMH5ziE/9P ucS5d29hp4TjO4argz3r8NSYfOUHD7jJb65w6rSZrAdWsIF3Y3GC7xzhN+d5z3fzyJSGGcdDrzHL DQKakpdE51ef+NGn3nJFXnrBQTez2GvemqObHecqX7rPOxv2Ht8Y6LnJONZPfnG0o8UPaneKcvTd 9o6DPKYiT7VkHDVwnQ/85BJPeNd7yIBhy5goI8dL5FeyeGg/HvKCj8zkVVL5Zwtl8+vO/Gw675zP iz41oDcN6ZtjenVDsp3aOErsyzJ7rq9+kRzVd78FVvuR9L4k2gi+74P/e9+L5PfFT0nviV974Ruf JMs3dhHCwnCHEX/4ybcH8qF/ktlvnyXXPz7/970vfuBzP+9IGTrQAQ9y68T+/ec3v/zLH//tv9/5 3X+++MmvfZN8H/3hZRAG5nQz5mOTJk+j5xXwN3/Qx3z013/zZ3/NhxITaHzkl3zb9xCidntt8XKj 5XZityb4p3/x13/RF4Hmd4L+R4Lex3/4938AOBTdJWZ01V1kNxwjCIEMuIAPSH/2V4L1B4QmWH4w GIObhlkFJnWllnqVBHs6+IQs+ITFV4EWKIQ+CIQu2IOxx4GH4YEFeF0Md4O5AX8qCIHRV4YPWIFo qH9omIX5Z4TuhIRfqGZlJlpMOBmOEn7a54A6yId7mIMs+IJ+2IDhN4hSSIUQyIWG8UHZ5xON/wiF SfGI1UEFcHgWkqgTjXiJQaGJlch5iviJXeQYfNCJuQaKUYEMppiKqggRkLCKp0eKtSFBLUENEyQX p+CK7lYOzwGLoGEAvNgSsjgd6/CLxFiMC4OLyGhDxriMzNiMQZOM0AhDzjiN1FiN1niNptFqPaGN 5zVfTcGNiIYWJxaO2/iL3cRf5FiOLGFZV2UUnoZY7SgW4wiO6Ehl5wWP5fZYVEaPNcGN7JiOQfGO KmYX86gTxzVb45iPUjZQyYWQv3WPsCVVDylojPZaEkli/+SQkFZUDQlpE7lo4ASRWbVoIHlU5/hU q2VX3DSR7WWP5jZO+NhMWKZfUTWTUPaP2f/0Z1fWWnjmZMi1Vxz2aDZ5YVLWkhe2VwOJVYOVkvhY a6rlaDhZlFzWkysWXPsolXbWYjNJXEpVWUi1lVXJXDCpk/ulj/KVUPY1T9FYLF85VFGJUSeJTWUZ lkIGXCjJkh52X3vWaN44ZPgUWT0ZlzQ5l48Fkyd5aO+IZD6ZbRX1llPWliZGl0q5ZUW5lFSVkFxp X4WJlQIplv4lmVx5ZQJpaPwYSBRml5I2lH65kFN5ZJGpYhk1liZ5lao5l7XZmjL5V7hJl4vZko+1 lgoxX9p0kKT5kIgZXPiVZ02ZZMg5aDuZaBp2ZFRpnNGZkc5JkcCUl8kFYCk5klLlndm5nHn/V5rN SJ7oZ57MiJ7YuJ7s2Z7u+Z7wGZ/yOZ+MBJz2aT/0mZ/6SRpDsJ/+KTD3GaBC9J8EWqAGqi8ycKAK uqAM2qAOim0Cios1EKEfgQsU2m0PKhsdkKEc+noX+qEgGqIiOqK3pw/6UBgdCkIm+hgk2qIEYaIu ukYLoEgnqhgpGoMxmqOb0Ws6mkg3CoB3SBzOsQc9ahkiwQ9Iyg9HmqRKeqQkoaRJWhJI+qT2wKRT 2qROOhJYmqVaWqVWSqVayqRd+qRXuqVQ+qUkUaR7pBJmWqVgiqVwahJT2qVbyqVuOqZ46qR1Sqd5 2qR76qdtuqc/ChsJIah1CqV2+qd36qaG/6qndvqoiHoSkbqojiqllcqoknqA34YD9tmoVDqpj4qp l/qmd6qon4oSk3qolJqlqbqqWaqmN5QFGpEScHqlljqnYEqqjIqmflqqcmqlZyqmi9qrp2qpvrqr wjqorlGot9qsqmqsmNqocWqqfCqnY6qqpjqtrpqmsCpHtNqsxdqm0IqoguqlYZqpxSqlwoqt1jqs oqqssqEcgaqr7gqt5lquz2qv75qn+0qs9Hqv6LptNmiDa7mkUYqmlBqs9lqmyZqvuaqnX4qtDSum B0umXrqumtqta/pGGhtsPNqxagSvSxekIksbxKIa3hUx/CaGumFpLDsdqTeDMfFjMssSL/+LZjuR Y5cHZtWFsyt7aVGXhEK7eztbgDo7s2Che6RltPG2tJS3GaI0ETRxs0QbgqZWFjSrsxxXg0x7tDZb fV6LZqdGZkObhFTbFD8btk0rE88RtRAxtQxGXWdlSroXhoDnd2NGgCF1t2NmUmQrU3TotCDItUQr ViPFfilrY+tXXYiLVonbbx73uDvGtx/3WXwLuC6VXWf2cHUot05XuZm7t3TYt7anGW5LEEHhuJBL uEYrdJs1gDTIWWdltUKbtWZbtmsmuKG1uh+ouZr1urg7tGjlgWrFXQ42czJXtR0Xu4Krfr9rVtCF vMurvKThXTEruqs7vGUrdNbVu2HHvbr/a4DBu7na+3CY9nRgy2ay27vq27VziLMPlr0fCHc0prXs W7ijFbQ3trtvJ3ZP4rap+74+trna5bl02731C3VjB78hp7a5a76ca7gnVcDly1LgK74rdb6nRMCx q79wZ8DTVbwHLHXmO4N5O8Ju18ApTLtsUsFiW7Vby7tB+70L7LTAO751e7u4e8OcG78WzL5PF7z4 28My68HqG8T4K70QFsP7W8M8psQs/Bp7JxMuvLRIPMQr7MQ0PMNVbLs2zMAR/L5nVr5ptl0K1sNE XLtqe8GKa8UQLL1p/MJsHHPt27+mFT5o7IVWjLgb7L4qLGZ3y7w/bLlL/HcZ3LNuLMQ8/xu4h5u4 OsZmB1x93vW3BZy5L8W0c5y7f/x3KEy9IRfInxzIjLy4QcwTJ9stZ1saqdwaq0yfSksbrxwcrRwx JFuyqcVttmxud+iylAFhQnG2qtvLn9FyDuy3vpzHsxy+PitjyazHuSe5dYy0lUbJ8FvN+9a4j2vM 2hy4mfsQjmB5ikzG1ky9RSHOJPzL+Xa1ypx+41xqVKu/6VxjZyxv9xa6f5tZ6ufIret3fnu7lKy9 DTy58VuHBF2zQny5e4vQoYu5DVe7keu5MifCBEi8M5HJHUXM/AvGsLt7ZJxWX/y8HB23+avANGjE 6TvOvhvNHp1mICiG+Cy8IG3HY7vIX/9n0l+G0Ris0UCMyTu9zOk7sAs80b5byk6Mxu6MYEQ9xqz7 dSItwHZ8vwe9tibdVsT8xzotzzyN1QSdxV/svG08yFOtzDTLuDlNx0h9z3Sbsi/t1K6LvTnGy/mm 1EZ8EYpwR3p8xW/c0x+9wuTLwsPr1QJNv3zdzjBNvzM80uTswEvsxvAcx0Wb1YO9zkUkh9Hs0ybl 1194wX+9zDtt1msW1iztxSXdvofdYJIdtlcs152t2AgMxlh9x9ymDy9nyAXWs4yrtEUcydZ1z5i9 26DLujo2t8Jd2dssuugrylEXy6ZGtj8H0TTduW8dygRsg6Ms3M2cn9etyAmT3bmc2JX/9jPcTUkL sADdjUVRMaMgm97qvd6cUd7Hxt7wLT7uPd/Y1gT0fd/4nd/6TY3x3d/+/d+LuN8CPuDGAeAGfuAI nuAKXjCVUAkLfm/N8CINPuEO/uBFahQUXgkEPkJZMeEW/uEg3qOTwQwb/rEhfuIlnuIqvuIs3uIu /uJ3UcswzqJsNOPxOmopcQg6fggiseM6PhI8DuT2sOMlQeRDbuQk4eNEHuRCruRM3uNFPuRF7uRH zuM/DuRPnuVUTuVTfuVOzuQ+3uVWnuRdfuRknuRbHuVcjuVhfuVQ/uVVvuRIDudCzuZm3uRaHuc/ 7uZSTud2zudWHuZQfuaCDueCLuWE/37j4JXliD7oYF7nUd7okn7mg97kKvHkfY4SmB7kgP7omC7p n07poB7plb7pkE7ojH4SqW7pOW4SgC7qn/7oov7mqE7mnT7pd17puF7nr57qpr7qo17qkB7kptLq rq7muh7qnN4SwJ7pxs7qx57oy+7p0a7r1X7tsY7ry67qtG7tp/7rl37ssp7s1W7qyM7rjT7m067t 6T7r0g7t3Q7vpN7uwu7ttaHsyG7ukR7q2H7umu7v847oY+7sBP/t4f7vpx7v8v7u9h7sC+/uA+/w 7G7t2e7r7T7w6i7uBo/wER/xCl/w8z7uBc/vqJEQYL7nap7t5Y7k2L7lSh7wHj/r6//u7CIP6i8v 5iGv8VN+8NvO71r+8mve40Dv6LAO9CxP8cNO9Jm+7mku8O6O7k4P7qjO5zZP9ZNO7M5BAQ8h9Zau 70/v8zK/6wkf82Pv6D1f9gl/8OQO8B+f6G2/9g+f9tS+8W4f9vVO7Zw+85Tu8SS/7UvP9iq/9oE/ 6GLD9d3e7PYO9mVP8lcv9uae92Z/9Ij/7BLf9n6/73Hf7GQP8fCO+DW/6Yfu9xl/52Q/9w3v9LRu +BMP916P6MVO+Xxf77t++YqP9IxP77Wv9Lae82kP63Yv+8AP9UKP8Lav9t8O7IHv9Y+f7KW/+rku 9qg//Ksu68i/9wGfgKtm9HNu61T/b+SH3u/c//12LvQs//PsrvxoLv5xfv3i3+Yyj/JYTvyNH/R6 zvfIP/R0P//wL/3ijv/DDxD2BB4SWLDgIYT2CB4kiNChQYUJGUo8aHDhQIsQF/7j2NHjR5AhRY4k WdIkSIgpVa5k2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ4lWtToUaRJlS5l2tTpU6hRpU6lWtXq VaxZtW7l2tXrV7A6R4Ylq/XkWbRp1a5l29btW7hx5c49y/KiwowVJzq8yBdvXo0PIwr+i5HwXouH MSJe6Xfg3buMEfNVPBgyxchlNW/mnHMkZMANU0YmrXF0RtCF+57Wm9qw3sKA/1KM/73Ydmbbpluz ptvb92/gwYUPJ6529vGKmV3Dzl27uejYylmHVs28OV7otaXjvq4ye97i4cWPJ1/efF27r6M7X/5c 9/vXpeFfX72a/uns8lGnf9nQsfPOAhRwQJkWgs4+7WR7jLL3HiqNtu4ck646y7zDbzH9kuOvJQPz 4o5AEEMMa6z8KEzQuhOt+w67FBtj7zYMLTStvvlYdNEuBJE7b0cee/TxR/RwZCgxxdprMcEHc/tQ PQ8lRHE7DRW0UUYqlexORCyz1Ey/DDM8cr3UEJwwxt32i9DDxKYzscb7UNTyTTipGivFLkdzkE0G GbSysv8qdM9IP6PDrc9AAbRMov//NgJyUUYbdRS4OCOVdFJKwZqzUkwhenRTTjv19FNQQxV1VFJL NfVUVFNVdVVWW3X1VVhBaiBWUGF5NVNcc9V1155o9fVXYIOFlVdifQKgWGQFFHZZHgEAgFloo5V2 WvGepXbUa65dq9hgkqXpWG/DdekSnlQBSlt047I2XXZvFfddiJyFF85wJm333pPWxXffVOeFiAlk wfV3YK/4NfhghFUleGGGG44qYYgjlnhiiiu2+GKMM9Y4Y4c79vhjkEMWeeSnNjb5ZJQpbuNTBTg6 QFVoUj7ZKiJItvlmzmQ2qRGde2ZrEZ+DFnpooos2+mikk1YaWpybdvppqKOWempNqqu2uqmls9Z6 a6679vprsMMW7mqyy85SbLTTVnttttt2++1ozeZsDbnrtvtuvPPWe++8Beb7b8A1hXtwwkkK/HDE hyp8ccYbd7zwgAAAOw== ------=_NextPart_000_0004_01C6F88F.9A929FB0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 00:44:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcx5M-0003PL-5D for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 00:43:20 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcwrz-00014N-7D for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 00:29:33 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B49751448007 for ; Wed, 25 Oct 2006 21:29:16 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id AFC284A460F for ; Wed, 25 Oct 2006 21:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 86334144802E for ; Wed, 25 Oct 2006 21:28:11 -0700 (PDT) Received: from web60312.mail.yahoo.com (web60312.mail.yahoo.com [209.73.178.135]) by hermes.tigertech.net (Postfix) with SMTP id D26701448032 for ; Wed, 25 Oct 2006 21:28:06 -0700 (PDT) Received: (qmail 34807 invoked by uid 60001); 26 Oct 2006 04:28:06 -0000 Message-ID: <20061026042806.34805.qmail@web60312.mail.yahoo.com> Received: from [67.166.240.5] by web60312.mail.yahoo.com via HTTP; Wed, 25 Oct 2006 21:28:06 PDT Date: Wed, 25 Oct 2006 21:28:05 -0700 (PDT) From: Behcet Sarikaya To: Charles Clancy MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_30_40, HTML_MESSAGE X-Spam-Level: ** Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1867264309==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba --===============1867264309== Content-Type: multipart/alternative; boundary="0-539991338-1161836886=:34521" --0-539991338-1161836886=:34521 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Comments inline.=0A=0A----- Original Message ----=0AFrom: Charles Clancy =0ATo: Pat Calhoun (pacalhou) =0ACc: B= ehcet Sarikaya ; capwap =0ASent: Mo= nday, October 23, 2006 11:00:38 AM=0ASubject: Re: [Capwap] CAPWAP for 802.1= 1r=0A=0AUnless PMK-R1s are preemptively distributed to WTPs to which a STA = might=0Aroam (neighbor graphs, anyone?), you'll still have the WTP-AC laten= cy for=0Athe WTP to request a PMK-R1 from the AC (R0KH). This would be abo= ut equal=0Ato the latency of having the AC validating Association Request p= ackets.=0A=0A=3D=3D>PMK-R1 is sent during Authenticate req/resp exchange, s= o no effect on ReassReq/Resp latency.=0A=0ADoes 11r let you proactively dis= tribute PMK-R1s? I don't see any=0Areferences in D3... all I see is the re= active distribution protocol.=0A=3D=3D>I think it is possible but the key d= istribution protocol is more advantageous because you do not distribute key= s to WTPs that may never need to use such a key.=0A=0A=0AMy understanding i= s that one of the reasons 11r is faster is because keys=0Acan be *reactivel= y* transfered directly between APs without having to go=0Athrough the AAA s= erver. Unfortunately our main security association is=0Awith the AC, not t= he WTP, and inter-WTP communications is bad, so=0Aeverything will have to g= o through the AC.=0A=0A=3D=3D>No inter-WTP communications in CAPWAPRP.=0A= =0A-- =0At. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~cla= ncy=0A=0AOn Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote:= =0A> I agree with Charles - but I do believe there is a single issue. In th= e=0A> case of local MAC, the IEEE 802.11 binding states that the WTP proces= ses=0A> the Association Request and then forwards it to the AC. The AC can= =0A> override the decision made by the WTP by sending a negative result=0A>= Association Response.=0A>=0A> When 802.11r, the local MAC WTP will not hav= e the cryptographic keys=0A> necessary to validate the Association Request,= so it would *have* to=0A> defer to the AC. The question is whether this is= acceptable as it does=0A> change the timing of the Association round trip.= One alternative is to=0A> push the PMK-R1 keys to the WTP to allow the WTP= to perform its own=0A> authentication of the management frame.=0A>=0A> Pat= Calhoun=0A> CTO, Wireless Networking Business Unit=0A> Cisco Systems=0A>= =0A>=0A>=0A>> -----Original Message-----=0A>> From: Charles Clancy [mailto:= clancy@cs.umd.edu]=0A>> Sent: Thursday, October 19, 2006 12:27 PM=0A>> To: = Behcet Sarikaya=0A>> Cc: capwap=0A>> Subject: Re: [Capwap] CAPWAP for 802.1= 1r=0A>>=0A>> Behcet,=0A>>=0A>> > My proposal is to use the key distribution= protocol of=0A>> 802.11r which=0A>> > securely transports the keys.=0A>> >= Also no need for the context transfer which was what I had in mind.=0A>>= =0A>> My point is that we don't need to distribute PMK-R1 keys=0A>> since a= ll authenticator functionality will reside at the AC=0A>> regardless of the= MAC splitting, so we therefore don't need a=0A>> new key distribution prot= ocol at all.=0A>>=0A>> Here's how I envision an 11r handoff:=0A>>=0A>> STA = WTP1 WTP2 AC=0A>> -----------------------= ---------------------------=0A>>=0A>> Initial authentication (as CAPWAP doe= s now):=0A>>=0A>> <--- assoc ----->=0A>> <-------------- open authenticatio= n ------------->=0A>> <----------------- 1X/EAP authentication -------->=0A= >> (derives PMK-R0, PMK-R1)=0A>> <--------------- four-way h= andshake ------------->=0A>> (derives PTK)=0A>> = <---------- add mobile (PTK) -----=0A>>=0A>> fast handoff:=0A>>=0A>= > (AC and STA derive new PMK-R1')=0A>> <------- FT / reassoc= (PMK Name, MIC, etc) ------>=0A>> (derives new PTK')=0A>= > <- add mobile (PTK')=0A>> <= ---------- delete mobile --------=0A>>=0A>>=0A>> > Can you spare your ideas= why that would not work in CAPWAP?=0A>>=0A>> I'm not sure to what you're r= eferring. Using the=0A>> yet-to-be-defined 11r key distribution protocol d= uplicates=0A>> the add-mobile CAPWAP architecture for distributing keying= =0A>> material. Additionally, it violates the security restriction=0A>> th= at keys from the PMK-level in the keying hierarchy MUST=0A>> remain at the = authenticator, which is the AC.=0A>>=0A>> > You're saying we only need the = split MAC scenarios that I=0A>> have in the=0A>> > draft.=0A>>=0A>> I'm say= ing that CAPWAP can support 11r without any protocol=0A>> changes. The onl= y changes I can envision being necessary are=0A>> perhaps capabilities flag= s indicating support for 11r, so ACs=0A>> and WTPs know that each other sup= ports 11r. All the 11r=0A>> protocol processing would be implemented at th= e AC. The WTP=0A>> would just have to know about the additional 802.11 mes= sages,=0A>> and know they should be forwarded to the AC. WTPs and ACs=0A>>= would also have to support AES-CMAC, which is defined in 11r.=0A>>=0A>> --= =0A>> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy= =0A>>=0A>> ________________________________________________________________= _=0A>> To unsubscribe or modify your subscription options, please visit:=0A= >> http://lists.frascone.com/mailman/listinfo/capwap=0A>>=0A>> Archives: ht= tp://lists.frascone.com/pipermail/capwap=0A>>=0A>=0A=0A____________________= _____________________________________________=0ATo unsubscribe or modify yo= ur subscription options, please visit:=0Ahttp://lists.frascone.com/mailman/= listinfo/capwap=0A=0AArchives: http://lists.frascone.com/pipermail/capwap= =0A=0A=0A=0A=0A --0-539991338-1161836886=:34521 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Comments inline.

----- Original Messag= e ----
From: Charles Clancy <clancy@cs.umd.edu>
To: Pat Calhoun= (pacalhou) <pcalhoun@cisco.com>
Cc: Behcet Sarikaya <sarikaya@= ieee.org>; capwap <capwap@frascone.com>
Sent: Monday, October 2= 3, 2006 11:00:38 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

Unless PMK-R1s are preemptively distributed to WTPs to which a STA mightroam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for=
the WTP to request a PMK-R1 from the AC (R0KH).  This would b= e about equal
to the latency of having the AC validating Association Req= uest packets.

=3D=3D>PMK-R1 is sent during Authenticate req/resp exch= ange, so no effect on ReassReq/Resp latency.

Does 11r let you proact= ively distribute PMK-R1s?  I don't see any
references in D3...= all I see is the reactive distribution protocol.
=3D=3D>I think it i= s possible but the key distribution protocol is more advantageous because y= ou do not distribute keys to WTPs that may never need to use such a key.

My understanding is that one of the reasons 11r is faster is becau= se keys
can be *reactively* transfered directly between APs without havi= ng to go
through the AAA server.  Unfortunately our main secur= ity association is
with the AC, not the WTP, and inter-WTP communication= s is bad, so
everything will have to go through the AC.

=3D=3D>= ;No inter-WTP communications in CAPWAPRP.

--
t. charles clancy, = ph.d.  <>  tcc@umd.edu  <> &= nbsp;www.cs.umd.edu/~clancy
On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote:
>= I agree with Charles - but I do believe there is a single issue. In the> case of local MAC, the IEEE 802.11 binding states that the WTP proces= ses
> the Association Request and then forwards it to the AC. The AC = can
> override the decision made by the WTP by sending a negative res= ult
> Association Response.
>
> When 802.11r, the local M= AC WTP will not have the cryptographic keys
> necessary to validate t= he Association Request, so it would *have* to
> defer to the AC. The = question is whether this is acceptable as it does
> change the timing= of the Association round trip. One alternative is to
> push the PMK-= R1 keys to the WTP to allow the WTP to perform its own
> authenticati= on of the management frame.
>
> Pat Calhoun
> CTO, Wirele= ss Networking Business Unit
> Cisco Systems
>
>
>
>> --= ---Original Message-----
>> From: Charles Clancy [mailto:clancy@cs= .umd.edu]
>> Sent: Thursday, October 19, 2006 12:27 PM
>>= To: Behcet Sarikaya
>> Cc: capwap
>> Subject: Re: [Capwa= p] CAPWAP for 802.11r
>>
>> Behcet,
>>
>&g= t; > My proposal is to use the key distribution protocol of
>> = 802.11r which
>> > securely transports the keys.
>> &g= t; Also no need for the context transfer which was what I had in mind.
&= gt;>
>> My point is that we don't need to distribute PMK-R1 key= s
>> since all authenticator functionality will reside at the AC>> regardless of the MAC splitting, so we therefore don't need a>> new key distribution protocol at all.
>>
>> Her= e's how I envision an 11r handoff:
>>
>> STA            = ;WTP1           WTP2 = ;            &n= bsp;AC
>> --------------------------------------------------
&g= t;>
>> Initial authentication (as CAPWAP does now):
>>=
>> <--- assoc ----->
>> <-------------- open au= thentication ------------->
>> <----------------- 1X/EAP aut= hentication -------->
>>      &nb= sp;         (derives PMK-R0, P= MK-R1)
>> <--------------- four-way handshake ------------->=
>>          &nb= sp;         (derives PTK)
>>         &nbs= p;       <---------- add mobile (PTK) ----= -
>>
>> fast handoff:
>>
>>  =             &nb= sp; (AC and STA derive new PMK-R1')
>> <------- FT / reass= oc (PMK Name, MIC, etc) ------>
>>     = ;            &n= bsp; (derives new PTK')
>>      &nbs= p;            &= nbsp;           <- add= mobile (PTK')
>>        &= nbsp;        <---------- delete mobil= e --------
>>
>>
>> > Can you spare your idea= s why that would not work in CAPWAP?
>>
>> I'm not sure to what you= 're referring.  Using the
>> yet-to-be-defined 11r key d= istribution protocol duplicates
>> the add-mobile CAPWAP architect= ure for distributing keying
>> material.  Additionally, = it violates the security restriction
>> that keys from the PMK-lev= el in the keying hierarchy MUST
>> remain at the authenticator, wh= ich is the AC.
>>
>> > You're saying we only need the = split MAC scenarios that I
>> have in the
>> > draft.<= br>>>
>> I'm saying that CAPWAP can support 11r without any = protocol
>> changes.  The only changes I can envision be= ing necessary are
>> perhaps capabilities flags indicating support= for 11r, so ACs
>> and WTPs know that each other supports 11r.&nb= sp; All the 11r
>> protocol processing would be implemented a= t the AC.  The WTP
>> would just have to know about the addit= ional 802.11 messages,
>> and know they should be forwarded to the= AC.  WTPs and ACs
>> would also have to support AES-CMA= C, which is defined in 11r.
>>
>> --
>> t. charl= es clancy, ph.d.  |  tcc@umd.edu  | &nbs= p;www.cs.umd.= edu/~clancy
>>
>> ___________________________________= ______________________________
>> To unsubscribe or modify your su= bscription options, please visit:
>> http://lists.frascone.co= m/mailman/listinfo/capwap
>>
>> Archives: http://lists.frascone.= com/pipermail/capwap
>>
>

_______________________= __________________________________________
To unsubscribe or modify your= subscription options, please visit:
http://lists.frascone.com/mail= man/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/= capwap

--0-539991338-1161836886=:34521-- --===============1867264309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1867264309==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 02:18:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcyZG-0002vL-58 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 02:18:18 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcyZC-0005dp-Gu for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 02:18:18 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 7EA181448022 for ; Wed, 25 Oct 2006 23:18:10 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 017EA4A45FE for ; Wed, 25 Oct 2006 23:17:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BA03D1448021 for ; Wed, 25 Oct 2006 23:17:45 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by hermes.tigertech.net (Postfix) with ESMTP id DA15C1448007 for ; Wed, 25 Oct 2006 23:17:43 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Wed, 25 Oct 2006 23:17:30 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B8A3C2AF; Wed, 25 Oct 2006 23:17:30 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 942102AE; Wed, 25 Oct 2006 23:17:30 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EIY16251; Wed, 25 Oct 2006 23:17:29 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D542620501; Wed, 25 Oct 2006 23:17:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Oct 2006 23:17:27 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4102235483@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <321DE401-CD86-43F9-B262-01B7A33570E9@thingmagic.com> Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb4WJf9J/zPjadeTYalbnIsuf2LKAAajXAw From: "Puneet Agarwal" To: "Margaret Wasserman" , "Pat Calhoun" X-WSS-ID: 695E8D7038S4541114-01-01 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Hi Margaret, I am OK with your 2 port solution (with shim header for capwap control only). To summarize, it seems that you are proposing that there be two UDP ports reserved for CAPWAP: A) CAPWAP Control Port: All discovery and capwap control messages flow on this UDP port. There is a new shim (control mux) header added between the UDP Header and the following header (where the following header could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The control mux would specify if the packet is DTLS encrypted or not. I didn't want to use the "Control Header" for the new shim as section 4 already talks about a "Control Header". B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. It is a property of the UDP tunnel whether the payload in encrypted or not. If the tunnel is encrypted, then a DTLS header follows the UDP Header. If the tunnel is not encrypted, then a CAPWAP Header follows the UDP Header. Note that there is no "control mux" after the UDP header. Is the above interpretation correct? Thanks. -Puneet -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Wednesday, October 25, 2006 10:09 AM To: Pat Calhoun Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap Subject: Re: [Capwap] need clarification on UDP ports Hi all, Just commenting as an individual contributor... I prefer the intermediate header approach to the third port approach, because I think it is a cleaner representation of what is actually happening. Different ports are used to reach different end points (different systems or different processes running on the same system). In CAPWAP, we have one port to reach the data end-point and another to reach the control end-point, because we think there are cases when the data and control end-points may be different processes or run on different systems. That makes sense to me. However, when we are talking about DTLS-encrypted and unencrypted control packets, we aren't really talking about two different end- points. We are talking about a single control application that needs to decide whether to treat each packet it received as unencrypted or as DTLS-encrypted, in which case it needs to be handed to the DTLS engine for decryption. If you think about it that way, I think it would be better for the control application to receive a packet that starts with a short header that indicates whether this packet is DTLS- encrypted or unencrypted. If the packet is unencrypted, the control application processes it directly (or ignores the packet if it isn't a discovery packet), and if it is DTLS-encrypted, the control application strips off the header and send the packet to the DTLS engine for decryption. This type of header might also allow for later expansion if the security world evolves and a better security mechanism for CAPWAP's purposes emerges. So, I would prefer that we add a short header after the UDP header (a CAPWAP control header?) that indicates the type of the encapsulated packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long enough for this header, and that would maintain 32-bit alignment. IMO, it should contain 2 fields -- a one byte version number (0x01) and a three-byte type field. At this point, only two types would be defined. I do not have a major technical objection to the third port option, I just think it is less clean from an architectural standpoint. I would rather strenuously object to the proposed approaches that involve zeroing out the DTLS header or running a packet through DTLS and then treating it as unencrypted if that fails, etc. Margaret On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > Not pushing for the hack. I've stated I do not object to a third UDP > port, but provided an alternative should IANA refuse to give it to us. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, October 24, 2006 1:24 PM >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com >> Cc: capwap >> Subject: RE: [Capwap] need clarification on UDP ports >> >> "Pat Calhoun (pacalhou)" wrote: >> >>> Except we can document that any CAPWAP implementation receiving a >>> packet with 'n' zeroes uses DTLS header format foo, which >> is of lengh 'y'. >> >> ...except that it is decidedly *not* a DTLS header, right? >> I'm having a really hard time understanding why you're >> pushing for a hack at any/all costs to solve this problem. We >> are at the design stage - if there were ever a time to do it >> right, that time is now. Exactly what will break if we don't >> adopt this hack? >> >> Scott >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From qsalesian@anglenet.com Thu Oct 26 02:41:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcyvY-00046m-Lo for capwap-archive@ietf.org; Thu, 26 Oct 2006 02:41:20 -0400 Received: from [202.184.244.194] (helo=angloblackwells.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcyvQ-0000aN-BW for capwap-archive@ietf.org; Thu, 26 Oct 2006 02:41:20 -0400 Message-ID: <001801c6f90c$c705fce0$067b166c@skong01> From: Esmeralda Carroll To: capwap-archive@ietf.org Subject: Or a schemata Date: Thu, 26 Oct 2006 14:41:10 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0015_01C6F90C.C705FCE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb ------=_NextPart_000_0015_01C6F90C.C705FCE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01C6F90C.C705FCE0" ------=_NextPart_001_0016_01C6F90C.C705FCE0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Many a true word is spoken in jest Never eat the yellow snow. A Frank Zappa= song. Alternate: If something is worth doing, someone will have already do= ne it. Brain is better than brawn. Who guards the guards? The cure is worse than the disease. Mouth is in gear, brain is in neutral G= ood fences make good neighbors. Laughter is the best medicine. Abbreviation: Speak of the devil. It's bette= r to give than to receive. The coat makes the man. Possible Interpretation: It is always easy to see your mistakes after they = occur. Jack is as good as his master. A miss by an inch is a miss by a mile= Attributed to Benjamin Franklin; Poor Richard's Almanac. If the cap fits,= wear it. William Shakespeare. Kill two birds with one stone. One man's junk is another man's treasure. He= aven protects children, sailors and drunken men. The best things come in sm= all packages. Attributed to Winston Churchill. It's easier to turn falsehood loose than c= orrect it everywhere it runs to. Alternative: Red sky at night: sailor's' d= elight. Red sky in the morn: sailor's be warned. All sizzle and no steak. A= pril showers bring May flowers. Nothing succeeds like success. ------=_NextPart_001_0016_01C6F90C.C705FCE0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
FARGO, North Dakota (AP= ) -- Alfonso Rodriguez Jr. stabbed college student Dru Sjodin, slit her thr= oat and left her to die, a federal prosecutor told jurors Monday.
NASHVI= LLE, Tennessee (Court TV) -- The father of a Nashville attorney on trial fo= r killing his wife claims he reburied his murdered daughter-in-law and disp= osed of evidence relating to her killing.
EA scores touchdown with Madde= n
3D"exhortation
grandiloquent urinary= posseman camellia
llow inmates. l storms or mo= nster hurricanes like Katrina and Andrew. severalty CHOWCHILLA, California = (AP) -- Sara Jane Olson, the former Symbionese Liberation Army fugitive who= became a Minnesota housewife and is now serving prison time for trying to = bomb police cars in the 1970s, says she tries to hide her radical past from= her fe NEW YORK (AP) -- Talk-show hosts Jerry Springer and conservative Tu= cker Carlson of MSNBC will be among the celebrities competing on the third = season of ABC television's "Dancing With the Stars. BOSTON, Massachusetts (= Reuters) -- The maker of the Segway scooter Monday unveiled the second gene= ration of its self-balancing electric one-person vehicle.
COLOMBO, SRI LANKA: '100 Tig= ers dead' in sea battle Money Magazine: Best jobs in America Atlantis' astr= onauts strapped into the space shuttle Thursday for a practice launch count= down more than two weeks before they are scheduled to blast off on a missio= n to resume construction of the international space station. KANDAHAR, AFGH= ANISTAN: 14 dead in Afghanistan crash You may be paid more (or less) than y= ou think FARGO, North Dakota (AP) -- Alfonso Rodriguez Jr. stabbed college = student Dru Sjodin, slit her throat and left her to die, a federal prosecut= or told jurors Monday. Wealth gap between richest and the average Joe grows= 50% since the 1960s
Lockheed beats Boeing for mo= on launcher ENGLAND: Top judge to rule on Diana death NEW YORK (Fortune) --= For the past decade, Honda has been out of step with most of its North Ame= rican competitors - sometimes defiantly so. sausage RICHMOND, Virginia (AP)= -- A man accused of killing a musician and his family and suspected in a s= eries of other crimes pleaded not guilty Monday as jury selection got under= way in his capital murder trial. NEW YORK (Reuters) -- Warren Buffett's Be= rkshire Hathaway Inc. said Monday it has amassed a 1.97 million share stake= in Johnson & Johnson, and appears to have sold shares of clothing retailer= Gap Inc. kovacs
NEW YORK (Reuters) -- Warren= Buffett's Berkshire Hathaway Inc. said Monday it has amassed a 1.97 millio= n share stake in Johnson & Johnson, and appears to have sold shares of clot= hing retailer Gap Inc. wary ENGLAND: Top judge to rule on Diana death Atlan= tis' astronauts strapped into the space shuttle Thursday for a practice lau= nch countdown more than two weeks before they are scheduled to blast off on= a mission to resume construction of the international space station. NASHV= ILLE, Tennessee (Court TV) -- The father of a Nashville attorney on trial f= or killing his wife claims he reburied his murdered daughter-in-law and dis= posed of evidence relating to her killing. renewal
CANBERRA, Australia (Reuters= ) -- Australian scientists have begun looking at smell sensors in worms and= insects to help them build an electronic "cybernose" they hope will one da= y be capable of measuring aromas and flavors in wine. l storms or monster h= urricanes like Katrina and Andrew. EA scores touchdown with Madden bugaboo = ASIA More Asia News BANGKOK, THAILAND: Thai bombs leave 2 dead, 28 hurt tro= y prostitute
------=_NextPart_001_0016_01C6F90C.C705FCE0-- ------=_NextPart_000_0015_01C6F90C.C705FCE0 Content-Type: image/gif; name="xsrfk_621.gif" Content-ID: <001801c6f90c$c705fce0$067b166c@skong01> Content-Transfer-Encoding: base64 R0lGODlhdAE9AYcAAAAAAP//////Vf8A3QAA//8A/0T//1X///8R/wAAiAAAZv8AAP//iBH/ 7v+IiACZADMiM///mf//qhFERDMzM+7//90AAHe7d93u3bu7u8z//8zdzACIAFVVVWZmALv/ //+qqjOZAFWqRIiIiKr///+ZmZm7iP9ERLu7AJn//5mZqmZm/0RE/yJmmYj//3f//2b//yL/ /wD//xH///8i/8xEu+7u/4i7iN3d/8zM/6qq/3d3/4iIqqqqu5mZmZmZ/3dV/zP///+I/4iI /2ZmiBEzM//u7iJ3d0REd3d3d0SqRGaqZv9mZoi7d///d///Zv//AP//Ef//RP//M//uIv// Iv93/3d3mf//3XeqZqr/Vf9m/5nMmf93d6qqqv/uzP//zMzMzLvMu7vMRN1V//8z///MzP+7 u/+Z/6rMqv9E/1UREf//u7vdu8zdu7u7zLu7//+q/zMRM//d3f+7/+7u7t3//93d3f/M///d /+7/7v//7v/u/8/PzxEREUhISH9/f7a2tjMzM2hoaJ2dndLS0gcHBzw8PHFxcaurq+Li4hkZ Gbq6uu/v7yQkJFlZWY6OjsPDw/j4+C0tLWJiYpeXl8zMzAEBATY2Nmtra6CgoNXV1QoKCj8/ P3R0dKysrOHh4RYWFktLS4CAgLW1terq6h8fH1RUVImJib6+vvPz8ygoKF1dXZKSksfHx/z8 /DExMWZmZpubm9DQ0AgICD09PXJycqenp9zc3BEREUZGRnt7e7CwsOXl5RoaGk9PT4SEhLm5 ue7u7iMjI1hYWI2NjcLCwvf39ywsLGRkZJmZmc7OzgMDAzg4OG1tbaKiotfX1wwMDEFBQXZ2 dqurq+Dg4BUVFUpKSn9/f7S0tOnp6R4eHlNTU4iIiL29vfX19SoqKl9fX5SUlMnJyf7+/jMz M2hoaJ2dndLS0gcHBzw8PHFxcaamptvb2xAQEEVFRXp6eq+vr+Tk5BkZGU5OToODg7i4uO3t 7SIiIldXV4yMjMHBwfb29isrK2BgYJWVlSH5BAAEAAAALAAAAAB0AT0BAAj/AAMIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKbSlgqtWrWLNq3cq1q9evYMOKHUu2rNmz aB1qSMu2rdu3cOPKnUu3rt27Vzvg3cu3r9+/gAML9kpgsOHDbCMgXsy4sePHkCNLnkwZ7YbK mDNr3sy5s+fPoEOLHk26tGm5VU/DPHFCteubrF/Lnhl7tm2XtW/rTpl7t+/fwIMLH068uPHj yLMWSM68ufPnCy1An04d6IDq2LNr3869u/fHAAB8/x9Pvrz58+jTq1/PniCD9vDjy59PH20I +Qbq69/Pv7///wAGKOCABBb41gQGJqjgggw26OCDEEYo4XqpTdgWghZmqGFBFWzo4Ycghiji iCSWaOKJKKao4orsfcDiizBlAOOMD5Vgo4004nVjjjz26OOPQAYp5JBEFmnkkUiOKGOSTDbp 5JNQRmkaAlJWaeWVWA7YwGsUZOnllx9uCeaYZJI1QplPSTDCmWgSJd1Ba2IEwYQexBVnm0zd iadSeu45ZoV+BirooIQWypReBnJg6KKMNuroo5BGKqlhb05q6aWYZqrpppx26umnoIYq6qik lmrqqaim6qUCqrbq6quwxucq66y01mrrrbjmquuuvPbqa64i/GpRsMIWa+yxyCar7LLMNuvs s9ByugBLCUR7oqLWZqvtttx26+234IYr7rgEIkruuegKxGq67LbrLqNUvivvvPTWay9wEtyr 77789vvsBSWSMBjAIwrcrcH+Slhpwgw37PDDEEcs8cQUV2zxxeKCgPHGHHfsb7weJ/hAyCSX bPLJKKes8sost+zyfybEDG7MJrxs880456zzzjz37PPPQB/pgEEgB43XAUYnrfTSyWnM9NNQ 94RB1FRXbfXVWGet9dYcv8f112CHLfbYZNuMbdkjBQQAIfkEAAEAAAAsAAAAAHQBPQEACP8A AwgcSLCgwYMIEypcyLChw4cQI0qcSLGixYsHO2DcyLGjx48gQ4ocSbKkyZMoU6pcybKly5cw Y8qcKdIDzZs4Sx7IybOnz59AgwodSrSo0aNIkypdyrSp06dQo0qdSrWq1atYs2rdyrWr169g w4odS7as2bNo06pdy9blgLZwozqIS5flhLp48+rd6zEB37+AAwseTLiw4cOIEytezLix48eQ I0ueTLmy5cuYM2vezLmz58+gQ1PeILp01AimU6tezRopgNawh76OTbvn7Nq4b97OzRvm7t7A Vf4OTtzk8OLIQx5Pznzj8ubQo0v/DGK6dYkgql/fzjA79+8Ktf//JQDeqffy6NOrX88UAvv3 8OPLn0+/vv37Wxfg38+/v///AAZImwICFmjggQgmqCCCJyxYW4MOwgZhhK1NSKFqFl6YWoYa lsZhh6B9COJnIo7IWYkmpqjiiiy26OKLMMYo44w01mjjgjvdqOOOPPbo449ABinkkEQWaeSR SCap5JJMNunkk1BGKSVTEkxppYqoLXjBlVx26eWXYIYp5phklmnmmWgytmWaX/nF5puqfeDS A3W52VQBcOap55589vmiBn4G+l8DghZq6KGIJqrooow26uijkNIYQqSUVmrppR6RgGlRmm46 VKeeAkUCqKH6RGqpPZ2Kao0EruqqmJO+/yqrRXTCSeisMGGA66689urrr8AGK+ywxBZr7LHI RmRTssw26+yz0EYr7bTUVmvttdh6emtkI4yQbUXdfguuuOSWa+656Ka7lgDqdmhAu/DGK++8 9NZr7734Apljvvz26++/AAcs8MAEt9VqwQgnrPDCmJoAsMP/QgzVu4maIHG/F3NEwbQZ59sx wyCHLPLIJJdsMsAiiIByyppt+2LKKv8b88k012zzzThjO1fOPPfs889AA2VB0ETDx0DRLmWQ 1dFclQCw0/9C7a/U/FJd9dNYI6311lx37fXXYIct9thkl2322WAigPbaJnLA9tsRbgz33HRD 617deOet99589yXt99+ABy44v+ShBOjgiFNYQeKMN+7445AHdzeMuka+2uGWLxQQACH5BABV oAAALAAAAAB0AT0BAAj/AAMIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOK HEkyYZmSKFOqXMmypcuXMGPKnEmzps2bOHOWlKFTpICeQIMKHUq0qNGjSJMqXcq0qdOnUKNK nWqzANWrWLNq3cq1q9evYMOKHUu2rNmzK9mgXctW54u2cOPKnSv0Cd27eOPiQWogr9+/gAML Hky4MMIVAhEPzLGCwAocAglIliwQxw7JP2zYIPBD4A8CNggydgw5wGQCLEoTVKxY4OjHkU9X vsxZM2fPoEU3hm16cmqDrHWTjj15NmbbnQN8Dr14d+nTvwsGbz68d/EAlo9vTr5cOG/oqgdO /zfcEIcO7OcrEzivgwBkygNx3JaP+HPk5OrZu+8dmUVB8+jFt14A7b1HAEHydUafcgeahh92 AxbIn2n+IXgegPkRuB986inoGIP3IRjhhg2i9t+F6UGon4EielhfiQ/Kt+KEJloYIEk/jXUa h5cNRMAQEwp0GXMEEQAHHA0O1GNkO9AIpI+njaFkkj8GGcCQBhmJZEFLmtYkfFVCKZuQVALJ 4ZW5FaRlkmT6+GWJTxJ3HZo+mskmlmoeySadTDpZ5I7kOTRekJQBeuZAOqywQoqxQWndh9Il 9qejhu4pUKKLqknlgae1Jp6kjjZa6UGYMkoop5N5CqqnHBYq26GXKv9qaquoSqZqAIMGqtCg tFoJZq+aUnrgZqryuqmvJQI7qajDQvoprsvyd+avxwbLbADERgptqNKySS233LqKrbOgeqAr Qzsm2eMPC545RJrKTukmjd4C2ia7H7oLb7UEdUnAm42KOee67bL5LnPxttnnr3+OSSe+iOmL ML/yLpxsw3OeSypkOoQnYw6SwWFlguPyS5mMGrLoJUEdE+jxeiAbOfJtm5l8IMoSgtkkohy/ rEPMIp9Jcs3h3jyiygnsfGnPIv4c8sydER0wfziT2CfPLmu8K6gEwdHYDiyEZm92P6oGLA7O ybkCkdve6vW/YT/aINlDmF0t2tV1ynauAbz/DbbYY9JNRtGVpf3o2qtxPZDfcY9NW92EY2e4 3olvq7VFNjx4U+Y9ca6T55dfZVfopJdu+umop656XDyt7vrrZmmhBeypq0X77bjnTtEHugMG Re/ABy/88B5JQfzxyCevvEhWLO/889BHL/3pWExv/fXYZ6/99tx37z1Zc3SxwAIlGIGQEQ4Y ZAYTCzAxh0Djxy9Q+OOX8IUR5AtUwgLmwx//AgEYX0PQV5D/CVCABEEgRAwIwIUocIEGDGAD B/LAg1TwIPQjX/8MckGGMNCB/3NIBws4QRJiZQ75QyETAmAVExIEhSAIAAgW8L4HorAEAVBh APYHPxwOxAIlfEgH/xU4wokU0YVGnOAREbLEG+awfR5Zov8iIsURSlEp4tvgQGaYvxAORHwU TN8Ds8jBM5whiA884AK60IUcim8BDsCf/JA4vjOeoIYArOMC7hgA9C2AixwsIRdj2Ef2nRGA RmDfHcmIvzZaEIBxkKAd8ejG8cUxgQDM4CW/yD+DDHKKeuSjHwGJRBmOj5AUnGAjA5BFPTLB fAj8ZCEXcEiBcNGHTFjhVS44QyPgT4xoVGIeQ9hBEOQSlf6Tnxr7dwJErlGCj0zlHPB3AmiO b5p73CH/UBhEaNqShjAMgAP4J8cAvDKAd6RlAM74vmj6D5vVFGAz+/jMVAZgnqu0Z0FmOP+H cKoRnto0AjcDuUVw/hGT8jvjOGM4Pl/CEZr8DOc4HQrAXv5SnOnbZQOVGcEKEnGYmEymPkNq TwW+0QFmmCJBVapGb7bUmyR1KUi9eYY33nOFTKgmE4UJSgCeNKUh/akLOdpTmRqVjhstYQXZ l9SiIvClagyhGbEy0aIGoAoq5eQOdfjAqsL0gmmcqUCMcAb2rXCIPLXmTKHazY9aVYDsKyc7 D7pTfb6UrGYlKV6hOBCvslWtb21rWsNakGZ28qkgRaxRr2iUGCTEieXcnxkuWkEYmqGOMH0i DsuZ1ZECViBkzCZa7ZrYpu7PCJcVbEH7edD9sXaYnJ0jWAcL0tD/6nSKtn1h/srJzwEc9K+n Te1KTclaZD5whjME5mS7WFGDxtC1A5UsZbsZFU22k4sZnUMzgSqQsq7xBLD0onU929mX6m98 XTCfdhfA3awq9q+JpOVsCSLL+NYShrF8aGbd21QE7m+NWvQverVYSThe95SBnWUtSynLVMbv ohPV4yXzS1f7UjijjC2LEXzYkCR4+MMgtskJgMpXj3g1kUsZMfx0+ZEME8Z2XZkDU9Mbxfa1 U5wENoqMJwDgkLjYLFP43k0mMIHj5YEkrQvKkc9FZCE7+SNNfrKUNRJl1fFhyliWy0mCIoG8 wCDLYAYeGLLSlzCb+cxoTjNIDqDmNrvZ/3QwfrOch/LlOdv5zqYLAp73zGeD0KHPgA50Tt5y lzo0IQQhSINAED0RRlekDiYoCAayEIJIO8TRAXC0HkyAaC7oYdGIDjVBEI0BUGc61Iim9EBE vegsBCANIuj0pzF9alSf2iK0TgikC5Lrg2xa1qAu9a17/To9hIALAcBApW8tEWI/JNfOTgim Ga0HETRBIE0QwadNzesQuHrYISBIGkJQ6jqEug7JTjSnP61sV/d62uGuSLRHHW+IVPvaAcj2 rL1t6nkjxbFE4UIItr3qEEBaBMIWA6LFMBAxxNoE+w5AtbVNEIeHgOHMRjW8HW1xjCPaBPjm 9q0FLmxlI1vkBf8nN7gJomxFuyHUbnh1CDaA6A102yDwPnjCF16QX3u71Bzn+alBbuuCB8DQ Hyd4AEguEJPXGujh9jfqYo3zRBvb1S/fgLJjrvANGDvSiJ640rNO85g7mtHQjjfZQ2B2ldPb 6FRftQiM3m0RuDvq9ZY4vw897kgf2udNQLdATGDpt4M6DVcPQNa3TpAmlNrYc2f04tl+amGn PQCqNnbIAxD3RUc+BHa/NeF19+54Mzru/O48qGMt7IGoOtN373femf16fpde48wWeelfrmy8 2zrWxsZ7pueuB0p/fPCFp3vGw436bw+kDmI4tPCbn/vLx9rxVX87onnP6NG7ZMsa6bL/UUov e1unXQQiSP7y13959s+++szPO+iVD/dYC58gAh83sjmt/4FM+vhugHGG535F13THFnzgZn71 dnkYYH8IRxCqN3+nZ3+KJ4C3I3BKt36qx3mzh2h18HKCJxC1F3srZ3gjmHvKx2hMl24nh4Km 1nv3NxA0V3MBMIOURxAb8ADvl4KmF38IcXbT14ELKIT+N25zNxAr6HSMBoM1EWdfYWzIpmxg 14MB0HVfV4Uzp3kZl3xrF3OUpgcvF4Pc1oUuCH8SZ23YRnEox23G54LBN4QGh3kqZ25TmH3c xmhWuGwDAXwzeGt5WIdryGh/B3sEcW9pGHFyKIa3g3QioGjr/1eFD9dwScdsAheCkCgCGNeA WYCAyrZ5mOZwmLiGZihxAneAA0h3vVdrrBZrzteGpIhojSiK8MZtFqd+DYiJaBdvtShynSgQ GkCJiNYEGagHpehp3JaKUidoCYEGUDFmEVFnyhiN0jiN1BgSAFeN2AgRW5CNhoFVQhEB3BiO 4ggSLaQ14jeO6JiO6riO7DgR3tiO8ChlVxaP9FiP9pgVbHaPEnGO3dMCLaCPzvOPWeGMAFmQ BnmQr5NBXXBj+xVWSsVeJMVAihWRHjVbHyRB7YVYF8lATHAGBTEH/3UC5TNWJWZOnUSRGVlC NVU/OUaSGKYQCsmQEllCIDk+Itk/+P/DYiaZYxPkVRrDRf+DShU5EKlFQ6l0WzK1kcGUTDfG TYKllEipkREkQQzkkd0lke20P1Z5RhxGWlE5QUAZPwzZV/zjACXQkV1ZUAYklBI5EIdkQFmp TuuUPwRhlmhJTxl1LijERznUTP0zlOc1ThwWP4O5lDHFUnuUlw5gWMNFQnR5VI15WTolR0Bl BOLDYtl0T9SlkYU5P3vUP5dpEDkpEOOUl7rFl+v1l9RFTxDZR6EJPzo1TwZRmgPBPlozTgzp RA3JUx/lV4ZJXog1QxRESoeJSb7ZWcUpYO2FPht0RmZEV0MFRyeJQLhZlznmnOvURl1glXVp lAOhmyMkWQT/wZxuSUtnhEzdpZ1b2Zq6AlY6BZhO5Fr+M5q7WUoyhUIpdVkD5ZhT2VB8JZVe 9ECXpUuyqRAncKBISZH0OZEL4ZMJ4Z7JNJUFmhAImqAJcVHnMl/1aUopFU7QhJ2ACZz9pZ1i 5WD9CUAgmlRKyUDt9FFzdJVyuVIClKLIiRAT+qCqRZUnaqIqiVkiZKFt8Y4elKOAaVjx854N ZJshipyKdVrM1ZgkpaRN9Uj/4z4DUaBTSV4UKRBSWqPuBEIyOkG/eKXC9KJeiqMaU50OEENn 5EhDKUdw6U0oNE6/yaRNpUJGqaErNacM6kLrxZ1aaZ9FNJF82kDVuRc4BqUIoaZs/1pP4Rmj dgpBGrOXvmSkQCWYBZU+Z8Rdl8VQPWmm+4Wp34RhKlqjVvSpfXqYhkSSrUlWSxqdZIlAlApa 9UQQN4oQlGoElnqmlDlWC6alClGSgRKW6PWdWMlKJ0lPZ1VCjFmcTvk/LWqo+mWRO0qmKlqt rNo/b3mk3HmmkKmZYMlAOeagCUGstTqT5WlAJ9Ct+6UQGPoVhPYRczBOI8ZGG7Rh8eMA0Rpg /PNAv1qj+GpJN4ZAl0ViT4mtc3mtARpECjUQAduRXxqmBPGv3qVBB4GdDTGve2QG9hqhXjRW /wWxipoQm4o6IICe3EOfEnGyLmGbCCkV5BoU74o8M6A8M/9LE2N6EDG7EuD4soGSZD6LE+UY tESbF3ZQtEibOkGWtEwbPEDbtFAbtVLbEfE6tSxBBVabtVoLGAgQKE5wFlGAZmW2tWSLErxT toExj2i7tt3zAGzbEm2wBA/wAMb4EXVwAwUxt3O7BBkYAHNLEXUgt3x7dIKbgTfwAHgrEHrr tix3AXNrjIvrtpHLuIoruZFLEH/rt4x7AxyAt3L7aXXwADbnt3JLudGIAXSbbA+wBCCRuQPx t6HLuhuxBKGLAazLBZKrBOL2AKGraKjbgv6XuqjLuq77uqZbucZrEHNrc3+bBrz7AGngvDYn Bqmbg857vGdBAm3huK2HvJqruRf/cAHgK76v9riVS71KgLp6i7mM+7dzG77fGwCHO7jlm7rx q7io23MPQL4CIbekGwBtILoG4biWeL/Jm7eUW7yVK75/67+ri7p467ise7i2K7vSqMDx6768 W7mC57x6oAeIq7kYAMK6q8Cwu7qaK3h/i7sgzLoeDMJ4W7zUC72Yq7vs+72HqwTpe8MIvL6V u2QHbMDnC8KW+73ue7hELL+JmxTXaDoYnLkaHMSTm8FFzL57+2muG8XGu7gIMcNL7LdfHMUX wLwWTMVVzMNo/MQPoAczbMRu67iH67e4K75iYIHKyL0IjLxZnMDHC8Vn7L1S/McYfBBrbLrF qwSSW8bF/3u4KvzHgBzIBHESf+u4bovI/xvAqUvJduxm29gQORiFKIzIeqC+9+u6uOt1IezH QmzCfLx0hXy7ogvDBrwEqKsHrOu4sty8z6touBzCwYtsoevIQlzK2Pu3mFy+vXt0y1uDc1tq gxxoGEDJN8BuiNzGe7y7vqzKGIDIo7vKfMwGejC/23a9iVu8tru66GbLiIvFm+vL6jzNkibN zszFjwzIauy9h7vEmZvEw/y2HIG9/oyNT1sWehbQBn3QCD0STvi2AO0QDW0RS5u1gbu6fRvE DTHFGXG3CDHR9OvKA5HPBsHRBIe7TVe4CV0QJP0ANkzID50Qz0wRz0y7D2C7Ev93uIzrvMlM EDJN0+GcuZaMwnIxtM8DwvwrEOrcxuqcvrgscfubx0Yttzv8vuLb09crENeLbFxcvDOdwJTc v4mct/mruF2NxgNRAW420AfxZzmh0gbByMEcAIOr0qjLcNTbvfcb1yW8wa5cB6T8wqncvqY7 w44Yw4AtxIItEIRNEAH8xSf9uozNAYVdhV2tBKy7BCtt0WLQ1dfsxln90F58wFpccXOrz5SL upfd2Mm7vqost28dwKjriGjM2qGtyqysEIV8wD9NvFkMwgdM1HxWs0rRy4yNuxhAynPLzz7s 1JqbxKbMuznotqecyw/QPMVLy2tswZmL0zSs07WM3Yz/ywWwjTt7EABqECjvPIxy28avnd2+ rNzrfcZHzd6+vM2ia86CG4KuC9KSdt+grbfhjdoWwcgXoQSjC9QS0dILgeAgYdYBvbd27RA5 m2ylewEVjY2RBOBTVgPc07UkwY/aUwMajuF+AeIFEbbAQwP2SOI0sbgdjRMafRAv/tIMoQeU TOGa29lXLBAbILjCpsrJRsl1W7lzG9WAHbonh7sF3BHQOBNCQBNNPBRQXMY38cwy/hCf28KQ /L+vXb7zzLxu+7uqq8jtm9fIS9JyHI4+ftUfTdFWPbeO+L4q3Qa4S+SOqwRyLtdtbr9zi77q +7dJ3edVfL1v/gB8bsDHrbyt//y9jvu6DNzUk6zXiK64iZ3BbRDA4ujnKOzXeMvCmT7TW97M Iuy3eT3Pzqy7L9y5IkzC8YvXVMzlnz7TJAwDMqzSiJfGbovl17znzP3QLO692b0ES/DfKJEC 2sPi7NzZPKzFtB3ZGozsbtxwml3Yy17Pz5cGiNwGgZzjub7G1gzYhnzrKOzj/bwUEe3Ebmvt 86zcre7jyi7tfezuXv3W0/7s457l34vuAbDoYq3ofyvghg7vxBwo4NcVmWvZrozKm/7Krk7D 7F7Fqhzdf63HgL3ryOu8xc3wAO/VH2zgm23wW27x33vMYP7WoC2+SB66pD2OmQvm5GzU4pzn g+7rDv8f2S3f6vStddD7tzcv3zFP70Zd4wS32WB+zrQs800nz1bM5j29zhYt4k7/9FAf9VI/ 9VRf9ev45FYvFoia9RSRj1Khtlwf9mJPEA0w9mZv0ANPjx7Otto7EONNtp3cjmp99nRPFhde 990DBHqP912h937P9wkRBkSgAERwBwKhAIiP+AJxB1eA+CpQB3WgACogECqgACGo+AGA+R4h +IRv+AGw98/HAwmh+RNR+Ys/+IV/EHeA+oLHAwog+gLh+rAfAD2gAEjg+QPB+JmvAIfP+xMx +OgW+WFw+ERwEIpP+phP+hGh/AaR+ISf5AvB/BsN+9KPEFeA+zNxBwrQA7T/rwCGT/raP/na X/ymn/mTPxCIP/zVfxHaz/21j/3o7/vGL/8RUQeu7/tIwPu2fxD5n/nFDxA9FNRR0COAQIIG 3wxUwCPAw4dI3gRQoCAMRQUQNW7k+FDgxQwKVAQIU7BjRYwaK15E2dHly5coCRKBeTJjzYct cW58g2TnT6Awr9yk6FBngKF1OCp4s3BjxSspD1YcGQCJwTsWD/q8M7Sh0qNDISqIGoCHAiIE K94UaBJjyLQeqeYkWzan14diycJESSQj2gB+KdIUzBHFQIxRW7atejVA1os9fD7M6nAozbN3 poqkK5WuYrYVDVrFqlWyyr8KQiLRPPYmSqhl246u/+M3ZOrOZtGqhR3abcXVmgleDFq8uM7e az1r7EGEyGjXGdROrUPQIQ+aQ6MScYgkI0HQqF0HUMGQ5mIFd7IarFi9IXXrGJVqNErU72SX C+un7D2YCJL58npNtekQig87pPbiTryGGMrIwPf6i67A9NYzKzsFHRqvojsIwi+lmeSTSz2T znIPt5TKC7EllAQikb30PLzLOBp/Qg7F3JTLDbU6bsNorYwWyopD1RJsiLiliJIwxwGlSk65 o8TTLb6OspqsPyzNk7I9H4FESci1sspAo6HOoqg80IDkjyj5umwSTCLH3LBJ1yqK68bOWESx tyrGWzNPOqOscdCNxFIhq//z2DRxR0FRwivKIdNbi7ge/aKJI7FmPEpPQDuVMklPNwIPIu8G s+ovwnB0MqNH2XwszEk1Wogzr8aMcsmUWu0s0kiR/HO5W5VsklNi2SzWU04JVXaj9Upiarms Rppux/FmJc8iKqEyUqmkKPLpKAtdvHbF0F7EKAyCRioP3Qhd9dOvUY9SATrqTELIXobsSrAz a9fNdi+vAgxArYuc1czfdoENssUKfwO4PQbppNYzFy0sj8SMvKtjyHEB47Rik5Lda1mSH3rD rysA/LGlririobXlmJTrvYi04vih8sgCy9U7LG2tjrPiusO7yESjC6752tJQ0NzquGxn1IzW TcP/qSEKWmAhV52ZaqJfdbelaTdbWtVkZyPV5mC19nPtzWizDaWhVZPp6seIRs/hXbUqee+H 6qiKb8ADF3zgSwNHQs7BE1d8ceMy+JBxnLyUfHLKK7f8cswz13xzzjv3/HPQQxd9dNJLnxxy 1FNXffXB8WD9ddhjl3122mu3nXU6btd9d9579/134IMXfnjiizeedgCSTz4AAIZvHqjn946e eeKfn76j663/6XqXmuee+pe8f0j573cSH6Lyx1f/+OjTP14j950wbnr3ddcepuzXf4iP8M3v v//7Dep8/gOf8drHvPYtbyPKQ58CvcdA6ikQgdaD4AHRNz4Jqs+BGExg/wcbmMACVjCDHOQg BSVYwQuS74MrXOEDW3jC5bmQhPCbIAjFZ0INZk+F5bMg+FBIvxrCL4YIZGHvQBjBCyYRiTn0 IRGX+MQBArGHTrxhCq2owStmMIBAxGIEoBhCMB5QjEr0ofbGSEMqghF9eDjjEKOYRhqaMH9L fOMAv5jEDU7Rfkp8IAT1p7/zmRGPDLSgHcvIkTGST44Y/OAQ/7jFBRLyil884xNLyMVCShKN YlThJOt4SEAusIBkRGIgdzjKN+IxhZ3kXQ8NSco2YlGWdzQkF/loSTWub46oDOUtK/nJWday e6GsZABSAEkehtGKmCSjIkUZRzqKUorNJKbwXP+ZS2XK0oyCJOI1pdlMQbYRmHRk5iMZ+cts OpKS1EynMLPJS3GW0pPQ7CUac1nFeaoymLcrgD0zyT0/orCJMuzmPRE5w1XqEoZl9OA5hYjQ Bq5ToTZUY0BHqE4KRpB+qfTjPgtqSkhOcoLYAyc3PerQib4vcPUbZlBYqlLaYaFkL4VpTflG U3tCz6Z7y4P9Ogo7GOxUqEMlalGNChEJHFWpS2VqU536VKhGVapTpWpVd+dMZQWwkX8k6f/2 iD/FJXOU8wNr/b4XyK4S6qVaJWsrc0ojtk4TrF69nVkDlzuukjJxOD0oXWu0VpLxNXWYzGMQ SahIWyZ0hjiMY0NHGsn/kFrUsY606FgFWsrJxtCBmgVpCYuYw4uKMH+dPOVI7SBFblaWo5xl qGch+1jVQnSvzuRkNbWJyI3uM5WMlGgBBVDIJuo2i8DUoioz2lu03hadU9xtNM2ZSOFGVKO2 xWg632nL5JITm4MjbHVBS9nuRVaSWO0laQHKSj3StrQa1SQq0evL9QJSk+M8Lj3hKV374nOR 2DXocp9J30jysb19HKHg5HpHXLL1m8IVK4Itm9ZdcrWY2DyrL5+pzwi6ALlvba4754nWYqIz ugkecYWD21vIydW7Eo0wcfHJS2122Li2ZbGL/RnjEgcXvP59LjVDymAc5xbBpjxkLEVMXZSu /3i2sfWmCJ241Yrq96KDbO1ro5xZij62oEJE5pMly1s3dvbKC4YnYz+8ZTc29pELzShjKbtB CW82yWIeq1WtKlip4jkobEixnf1cEz1DNdDI++mfiYcGQyf6JSkg3hYU/WhIR1rSk6Z0pS3N ujhcWtOb5nSnPf1pUIda1KMmdalNfWpUp1rVoSbBql39aljHWtazrp38aF2TPdyacYwGNWJ9 /WtgB/vXsVODro19bGQnW9nLZnaznf1saJc6DEmgQBJaQwFsY5syI8C2D6pDAR88xAcUENi0 q33tbHcAZgHQdh24TYERCOwx7/Y2RN4NEW1rm90U2He//X0Hegss2/9KqUO2H2Juaz9k4AMz eLbzze9+O/zhCuf3wgs+cY0AvNtKkfi+Ha6Rh38c39lOAschrnFwm5ziHjf4yFdOEmonnNoE pwBxqo1xiPDPqXeggBcC4AUKaEbflAH3Y6odgHErPNwQ4bnPgS50iFOgAyDn98wLnoSMF53n WGc4ttG974tMHNth5zfPw711qtecJAZv+s+D7vGCNRziFCe7y18e8rjj3OhnP/rQ7U71v9u9 72XX+uBf7m+q173tTwc6SIoehp7r/X2OLg638R1uv3Nb3uwOA+Q3YnmFj8DfRXc5tjcfAM1z JAPgJv3DRS92ePc79R3BdhLC7QNq8xv07H7/fbVvn3vE77v3f6dAEVZe+9sfQdtJ4PpDZh/4 wxN/7oKvuO7JvRF9D93vFB/+7uFtdtQffdx3YH4Ayk9V7Vdf7h3xAvN9Dvjjkxz7/F59B7wg 7+0/pANTl3r8pQP7/6u+l8C21WO31RNA/6u4A2S56gtA6UtAA9Q2H1i66KO4lgu+w8u/djM8 Dey4Ctw3B0y/iBu3i0O626NAqRJBv8s+EZy/0uO3q4O/OvCCDlA76iO8MUm9h+sR2ONBBLzA feM5yOM5BIy4oKu5IyzCffPBBzRCIUzCAMgAxBk9ycNAxOvA2lM5FvzBuetAJhRBbks61hM9 KYzCKeSbNUjDNdgd/8vzAbTzOxLMwOlzvi4cvuDbPji8vn4bN4cbk4m7tz+UQD1cQfWTvTo0 QgEkxPDrQkaMP4+zQqQbRCX8wBYEPBqEukicD4yrRJe7N+8TvTCQg6J7tzOEHDVcQ+OIAsBp OshTO78DvxKUQ6NzurfLPtFzOas7OqYruhIkPZ4bPm1rRSNcO8ILt1hcuXHDPMKjRUxMxmF0 OWEEA8QjwYJTxki0xlfkxSrsQOjztyTgv2LsOirsxmDUtsV7u4vLO0zMP6gytxHoAJNrOZRz wyYkv3OzwGoTOBh8t3hjFnq7A8hDEthzRBbctm5bt3Ksu8eIua8LSETcxEbsGz6st4R8Rv+m +0cGJMeIhD+z07d5xMQrnMNxXMh7fLlYrEKqqgMUjDaWbEmoCiqXfDQZiMkDiMmNyDSbzEmd 3Eme7EmfrKp7w0c56UOOQDh0k8eAq0Zx08ODY0h8VLe0azmj1AilzESYK8mCdLiSi8qtpENG JECNCEqW60qImMqRpIyYmw+gg0qNMMurTDkGhDizdDio7DitVLlUu7i36zfI80N+68usY8bg Az+0Szp2Q8FzBMn+c0GiE0yIMMzCE8ysjLrmGz2u08uGpAA5wcy7q8zEBLvgq0F2wzrIq8rG dDvNIExdRLzPzD5whD/DS7XVc0bLrE1760JrvM3NqznPC8tDzL7/lUS8T8S+zoO44ZzM6CvI KGS9pcs+rpvN1ou66TvO2GPH5RPJ8MM30eO2dfs76lS6O5RO86tMU9s/dpu6cVROWbRL7Gy/ JHi/B9RK2tvI7XPP91NB8dzAytRP/eM/9FRO81xM/oxPzTzGsiy6avtGfXxBl6jEkNNF9mQ4 rJvAVOO5HLw+5AxPBr1BjWTQGGTMkOQIB+XCsdTHLDS6C8VLc9TM8IvHfIQ/I2TCrPtPclvN EGXHEHXEGCTEEy1DVOPDbPNLhcM65/RNpHvD6YvDHDXS0DtL7zxEEP3OYbxES4RKIAXLIr1S FtU2Kr1N7TTE6Su4WzQ/JRxO7pxPL23S/wxduS5VNV+szr90xTj1FVYcu8HURvpcRtQcvTH9 u88E0c+kRgSFuG+Ev0J90+FzSET1RvQ8zafjS21DNKSDT7cT08DcU8jju+YbutaMOjt8uUPF TlGzQUTsgKHENlMtSmp7Rxc9OYyURZJMuBIV0emzR1kF0Vj9mYnES/B7OZ6rQYFUv1R1SEfc u4xzytGDgKh8v3EjS7QsyXnbuMCz1aN80QjdOxx9NVUMCpX0s6T6SXCVtQ9gHSgIV3M919qR RnRdV3adtCBoV3iN10/DSXmtiQqoV3yFiXGtqZrMV1NznePpKX8dWIItWNWZAYNN2FN7AoVt WId9WIitVwOIWP+KBYpcq1i+wSuM3ViO7ViP/dih0jloW4GHIFmIyIEVIIAVwIGHIACXddmH wIEdcNkfsAEbIIAfeIgfIAAb0AiUVVmWDYCXJQAWCFqNMFmTfYifXdmWHdqYnVmctVmc1Vme 9dmUZVqhfdmi5QiktVqgbdqXfVqaldqcDYCd7dmTvdqgHdqt3YiuTduvzdqwDQCZHdubLduz 9VqsZVujhYi3nTUc0AG6FdyYJQDB1QECYFmYhQgcmNrGJdmdbdmyLdzDTdysbVkW2IjAHVzG NdwAQFzFJQCNaNycfVyzFV2hnVy69VzQvVyhzdzRFdzNpdzPtdzFLdzSVdnTldzRZV3/20Vd otVc2SXc1a3c0O3d3IVc4FXdxjVe1w3e2OXcWRva251ZiCCAIXDdh5hZtNUIAoADOEBdiLDe lt2B583e66Xe8RVf7NXeAOBejvje8N0I8hVa813c9k1fp91e9s3e233fqt0I+RVf/r3e+wVe 9AXbuQXg6/VfAoZfAQZfAmbg8j1f71VfWvtb7YVZ9f1fiNCBFVgB4m3a9JVb3XXbkr3gEu7g CX4IEBZhAWZf0R3apPXbFC5hEmbhjnjhEd7gGX7ZGr5hkpUCEs5hp/VgFw7hHr5dDgZirr3h DIZiH3Zf/GXiFrbiy73ZINZgLP7fKpbh+AVjmNViFA6AGu5i/wL+YhxWYSMOADI+WilGYzZe YCSW4ze2YTNONElNHOoVX+v9AdP93yEIYCymX/Y94CJW4OoVXUDWXUEmZDA2ZAN+3jTGYAZu ZJJ9ZLQtZI2oXwJAZCq25D8OZAIe5E2O5E4+ZEq+4P1VKoSlHR1g2VjuXR3IAZeFA/clXTd2 WT6b4uat3eO1X42Y5Vnu3Fq+5Vye2ptFZZj95dbFX/P9YFnu2+a15e9N5pxd5jVuZt8N5k/W MBeeZlq2Zlz+X13W5kTmZueF5mEW5yjO442Ag5TdARboWQyuW+w12kLGAbVV4BXoXngO4gCQ 50+uZxNGXXweAn2OZH6OWxoGaA1+CImCpmd73t+EXmgcbui9BWKIlmKJnmeDvmeoVehtRuh+ NuF/hmN4Fh5eayobUN3deenfkWllaTXBoek/ozyQpbWL3Wmf/mlLg0mgriqNHWqjPuqPnVik XmqmbmqnBh4GYFcEMDSRfWqrvura0QCs3mqkBliu/mqwdio7CGuyLuudBGezbmqtrqqAAAAh +QQABQAAACwAAAAAdAE9AQAI/wADCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyBDihxJsuREASZTqlzJsqXLlzBjypxJs6bNmzhxXsjJs6fPn0CDCh1KVOGIokiTKl068ijT p1CjFmwgdaDTqlizag064urWr2DDuvQqtqzZsxzJol3Ltu1CtW7jyl0Ld67du1rr4t3bEwTf v4ADCx5MuLDhw4gTK17MuLHjx5AjS55MubLly5gza97MubPnz6BDix5NurTp06hTiw6hurXr 17Bjy55Nu7bt27hz697Nu7dvlwl+Cx9OvPhcCgYZiJzgkYPx59CjS59Ovbr169iza9/Ovbv3 7+DDi/8fT768+fPo06tfz769+/dPJcCfTx/sgozI6+vfz7+///8AlkRVgAQW2FgGBm4HQYIM NujggxBGmJIIEkZkAGcUrkcAdRlW2FqHHqYGYoinjdhTASSCZWJqCEC4YoqivQhjaDLOaOON OOa43gE6chRBj0AGKeSQRBZp5JFIJqnkkkw26eSTUEZpnANSVumRBVZmqeWWXHbp5Zdg+tZi mGSWaWZpC56JXnADbaDmm3DGKeecdNZp550+PYDnnnz26eefgAYaFAaCFjZAoT8RiuiijDbq 6KNPlnCdm+lJCmlUll4KVaaaMsVpp0p9CipSoo5KVKmmBoVqqkCtCmMHoLn/yuqstNZq6624 8lRBrrz26uuvwKJHZbDE/mpCsTUdi+xMyi7L0IYhNevsS9Kaqahd1U7LUrbieYAdt9qmBG64 JY1L7kjmnqvuuuy2p0G78MYr77z01mvvvfjmq+++/Pbr778AByxwb4cObPDB6rGG8MIMN+zw wxBH3CCsElec5AcWH4SxSyeEu3FLHWv78UohTzsyyR5zTO7JJpWc8UAuvxyzzC8TNHPNOOes M1R67uzzz0AHLfTQRBdtNE0A6Jz0frsKtzTOT0Ot9M5Rv1z10VhnbTHFWnft9ddghy322GSX vSSKZqet9tqGcc3222spB/fcdNdt991456333nz3SO3334AbSILOg+dcOM6H15y44oQ3Hvjj kEcu+eTvOUf55ZhnXpZfmnfu+eeghy766KSXbjq+cp+uekYKrH70u67HLvvstNsZEAA7 ------=_NextPart_000_0015_01C6F90C.C705FCE0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 04:03:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd0DX-0006Jn-Ej for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 04:03:59 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd0DV-0001uq-BM for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 04:03:59 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3DBF539804C for ; Thu, 26 Oct 2006 01:03:49 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id D54FD4A4547 for ; Thu, 26 Oct 2006 01:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A532A4306B5 for ; Thu, 26 Oct 2006 01:02:01 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by hermes.tigertech.net (Postfix) with ESMTP id 8F23D4306B1 for ; Thu, 26 Oct 2006 01:01:57 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id x30so853234nfb for ; Thu, 26 Oct 2006 01:01:56 -0700 (PDT) Received: by 10.49.90.4 with SMTP id s4mr4961030nfl; Thu, 26 Oct 2006 01:01:55 -0700 (PDT) Received: by 10.49.42.3 with HTTP; Thu, 26 Oct 2006 01:01:55 -0700 (PDT) Message-ID: <5bfe7a820610260101p95fa2c9wb063ee809d3a748a@mail.gmail.com> Date: Thu, 26 Oct 2006 01:01:55 -0700 From: "Dorothy Stanley" To: "Behcet Sarikaya" In-Reply-To: <20061026042806.34805.qmail@web60312.mail.yahoo.com> MIME-Version: 1.0 References: <20061026042806.34805.qmail@web60312.mail.yahoo.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=1.0 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, FROM_ENDS_IN_NUMS, HTML_40_50, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981184874==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a --===============1981184874== Content-Type: multipart/alternative; boundary="----=_Part_48614_8573915.1161849715733" ------=_Part_48614_8573915.1161849715733 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline All, I believe that we previously agreed that the initial CAPWAP specification(s) will support 802.11 capabilities through those defined in 802.11-REVma, expected to be approved in Dec 06, and that unapproved amendments including .11k, .11r, .11n etc would be dealt with in a future version. Thus 802.11r support in CAPWAP, the discussion of which is very interesting, is not in scope for the current CAPWAP specifications under development. Thanks, Dorothy On 10/25/06, Behcet Sarikaya wrote: > > Comments inline. > > ----- Original Message ---- > From: Charles Clancy > To: Pat Calhoun (pacalhou) > Cc: Behcet Sarikaya ; capwap > Sent: Monday, October 23, 2006 11:00:38 AM > Subject: Re: [Capwap] CAPWAP for 802.11r > > Unless PMK-R1s are preemptively distributed to WTPs to which a STA might > roam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for > the WTP to request a PMK-R1 from the AC (R0KH). This would be about equal > to the latency of having the AC validating Association Request packets. > > ==>PMK-R1 is sent during Authenticate req/resp exchange, so no effect on > ReassReq/Resp latency. > > Does 11r let you proactively distribute PMK-R1s? I don't see any > references in D3... all I see is the reactive distribution protocol. > ==>I think it is possible but the key distribution protocol is more > advantageous because you do not distribute keys to WTPs that may never need > to use such a key. > > > My understanding is that one of the reasons 11r is faster is because keys > can be *reactively* transfered directly between APs without having to go > through the AAA server. Unfortunately our main security association is > with the AC, not the WTP, and inter-WTP communications is bad, so > everything will have to go through the AC. > > ==>No inter-WTP communications in CAPWAPRP. > > -- > t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy > > On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote: > > I agree with Charles - but I do believe there is a single issue. In the > > case of local MAC, the IEEE 802.11 binding states that the WTP processes > > the Association Request and then forwards it to the AC. The AC can > > override the decision made by the WTP by sending a negative result > > Association Response. > > > > When 802.11r, the local MAC WTP will not have the cryptographic keys > > necessary to validate the Association Request, so it would *have* to > > defer to the AC. The question is whether this is acceptable as it does > > change the timing of the Association round trip. One alternative is to > > push the PMK-R1 keys to the WTP to allow the WTP to perform its own > > authentication of the management frame. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Charles Clancy [mailto:clancy@cs.umd.edu] > >> Sent: Thursday, October 19, 2006 12:27 PM > >> To: Behcet Sarikaya > >> Cc: capwap > >> Subject: Re: [Capwap] CAPWAP for 802.11r > >> > >> Behcet, > >> > >> > My proposal is to use the key distribution protocol of > >> 802.11r which > >> > securely transports the keys. > >> > Also no need for the context transfer which was what I had in mind. > >> > >> My point is that we don't need to distribute PMK-R1 keys > >> since all authenticator functionality will reside at the AC > >> regardless of the MAC splitting, so we therefore don't need a > >> new key distribution protocol at all. > >> > >> Here's how I envision an 11r handoff: > >> > >> STA WTP1 WTP2 AC > >> -------------------------------------------------- > >> > >> Initial authentication (as CAPWAP does now): > >> > >> <--- assoc -----> > >> <-------------- open authentication -------------> > >> <----------------- 1X/EAP authentication --------> > >> (derives PMK-R0, PMK-R1) > >> <--------------- four-way handshake -------------> > >> (derives PTK) > >> <---------- add mobile (PTK) ----- > >> > >> fast handoff: > >> > >> (AC and STA derive new PMK-R1') > >> <------- FT / reassoc (PMK Name, MIC, etc) ------> > >> (derives new PTK') > >> <- add mobile (PTK') > >> <---------- delete mobile -------- > >> > >> > >> > Can you spare your ideas why that would not work in CAPWAP? > >> > >> I'm not sure to what you're referring. Using the > >> yet-to-be-defined 11r key distribution protocol duplicates > >> the add-mobile CAPWAP architecture for distributing keying > >> material. Additionally, it violates the security restriction > >> that keys from the PMK-level in the keying hierarchy MUST > >> remain at the authenticator, which is the AC. > >> > >> > You're saying we only need the split MAC scenarios that I > >> have in the > >> > draft. > >> > >> I'm saying that CAPWAP can support 11r without any protocol > >> changes. The only changes I can envision being necessary are > >> perhaps capabilities flags indicating support for 11r, so ACs > >> and WTPs know that each other supports 11r. All the 11r > >> protocol processing would be implemented at the AC. The WTP > >> would just have to know about the additional 802.11 messages, > >> and know they should be forwarded to the AC. WTPs and ACs > >> would also have to support AES-CMAC, which is defined in 11r. > >> > >> -- > >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > >> > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > >> > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > ------=_Part_48614_8573915.1161849715733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

I believe that we previously agreed that the
initial CAPWAP specification(s) will support 802.11 capabilities through
those defined in  802.11-REVma, expected to be approved in Dec 06, and that
unapproved amendments including .11k, .11r, .11n etc would be dealt with
in a future version.

Thus  802.11r support in CAPWAP, the discussion of which is very interesting,
is not in scope for the current CAPWAP specifications under development.

Thanks,

Dorothy

On 10/25/06, Behcet Sarikaya <behcetsarikaya@yahoo.com> wrote:
Comments inline.

----- Original Message ----
From: Charles Clancy <clancy@cs.umd.edu>
 To: Pat Calhoun (pacalhou) <pcalhoun@cisco.com>
Cc: Behcet Sarikaya < sarikaya@ieee.org>; capwap <capwap@frascone.com>
Sent: Monday, October 23, 2006 11:00:38 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

Unless PMK-R1s are preemptively distributed to WTPs to which a STA might
roam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for
the WTP to request a PMK-R1 from the AC (R0KH).  This would be about equal
to the latency of having the AC validating Association Request packets.

==>PMK-R1 is sent during Authenticate req/resp exchange, so no effect on ReassReq/Resp latency.

Does 11r let you proactively distribute PMK-R1s?  I don't see any
references in D3... all I see is the reactive distribution protocol.
==>I think it is possible but the key distribution protocol is more advantageous because you do not distribute keys to WTPs that may never need to use such a key.


My understanding is that one of the reasons 11r is faster is because keys
can be *reactively* transfered directly between APs without having to go
through the AAA server.  Unfortunately our main security association is
with the AC, not the WTP, and inter-WTP communications is bad, so
everything will have to go through the AC.

==>No inter-WTP communications in CAPWAPRP.


--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>   www.cs.umd.edu/~clancy

On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote:
> I agree with Charles - but I do believe there is a single issue. In the
> case of local MAC, the IEEE 802.11 binding states that the WTP processes
> the Association Request and then forwards it to the AC. The AC can
> override the decision made by the WTP by sending a negative result
> Association Response.
>
> When 802.11r, the local MAC WTP will not have the cryptographic keys
> necessary to validate the Association Request, so it would *have* to
> defer to the AC. The question is whether this is acceptable as it does
> change the timing of the Association round trip. One alternative is to
> push the PMK-R1 keys to the WTP to allow the WTP to perform its own
> authentication of the management frame.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>> -----Original Message-----
>> From: Charles Clancy [mailto: clancy@cs.umd.edu]
>> Sent: Thursday, October 19, 2006 12:27 PM
>> To: Behcet Sarikaya
>> Cc: capwap
>> Subject: Re: [Capwap] CAPWAP for 802.11r
>>
>> Behcet,
>>
>> > My proposal is to use the key distribution protocol of
>> 802.11r which
>> > securely transports the keys.
>> > Also no need for the context transfer which was what I had in mind.
>>
>> My point is that we don't need to distribute PMK-R1 keys
>> since all authenticator functionality will reside at the AC
>> regardless of the MAC splitting, so we therefore don't need a
>> new key distribution protocol at all.
>>
>> Here's how I envision an 11r handoff:
>>
>> STA            WTP1           WTP2              AC
>> --------------------------------------------------
>>
>> Initial authentication (as CAPWAP does now):
>>
>> <--- assoc ----->
>> <-------------- open authentication ------------->
>> <----------------- 1X/EAP authentication -------->
>>                (derives PMK-R0, PMK-R1)
>> <--------------- four-way handshake ------------->
>>                    (derives PTK)
>>                 <---------- add mobile (PTK) -----
>>
>> fast handoff:
>>
>>                (AC and STA derive new PMK-R1')
>> <------- FT / reassoc (PMK Name, MIC, etc) ------>
>>                   (derives new PTK')
>>                               <- add mobile (PTK')
>>                 <---------- delete mobile --------
>>
>>
>> > Can you spare your ideas why that would not work in CAPWAP?
>>
>> I'm not sure to what you're referring.  Using the
>> yet-to-be-defined 11r key distribution protocol duplicates
>> the add-mobile CAPWAP architecture for distributing keying
>> material.  Additionally, it violates the security restriction
>> that keys from the PMK-level in the keying hierarchy MUST
>> remain at the authenticator, which is the AC.
>>
>> > You're saying we only need the split MAC scenarios that I
>> have in the
>> > draft.
>>
>> I'm saying that CAPWAP can support 11r without any protocol
>> changes.  The only changes I can envision being necessary are
>> perhaps capabilities flags indicating support for 11r, so ACs
>> and WTPs know that each other supports 11r.  All the 11r
>> protocol processing would be implemented at the AC.  The WTP
>> would just have to know about the additional 802.11 messages,
>> and know they should be forwarded to the AC.  WTPs and ACs
>> would also have to support AES-CMAC, which is defined in 11r.
>>
>> --
>> t. charles clancy, ph.d.  |  tcc@umd.edu  |   www.cs.umd.edu/~clancy
>>
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>>
>> Archives: http://lists.frascone.com/pipermail/capwap
>>
>

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap


------=_Part_48614_8573915.1161849715733-- --===============1981184874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1981184874==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 05:37:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1aA-0004hz-9i for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 05:31:26 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd1a3-00066Z-BO for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 05:31:23 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id E7C5E43092D for ; Thu, 26 Oct 2006 02:31:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id C5D994A453E for ; Thu, 26 Oct 2006 02:30:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8A17C430927 for ; Thu, 26 Oct 2006 02:30:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 7183943091E for ; Thu, 26 Oct 2006 02:30:06 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 02:30:06 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9Q9U6OH018682; Thu, 26 Oct 2006 02:30:06 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9Q9U5W4025406; Thu, 26 Oct 2006 02:30:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 02:30:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 02:30:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A268088A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb4WJf9J/zPjadeTYalbnIsuf2LKAAajXAwAAG98vEABeML9w== From: "Pat Calhoun (pacalhou)" To: "Abhijit Choudhury" , "Puneet Agarwal" , "Margaret Wasserman" , "Scott G. Kelly" X-OriginalArrivalTime: 26 Oct 2006 09:30:05.0320 (UTC) FILETIME=[51F86080:01C6F8E1] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2101282083==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 This is a multi-part message in MIME format. --===============2101282083== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F8E1.51BB8CB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F8E1.51BB8CB3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could you explain why you believe the sessionID should not be protected? = Seems like the IP address and UDP port are sufficient to distinguish the = WTP (for encrypted data plane, this would be known after the first = packet is received. PatC -----Original Message----- From: Abhijit Choudhury [mailto:Abhijit@sinett.com] Sent: Wednesday, October 25, 2006 11:59 PM Pacific Standard Time To: Puneet Agarwal; Margaret Wasserman; Pat Calhoun (pacalhou); Scott G. = Kelly Cc: capwap Subject: RE: [Capwap] need clarification on UDP ports Folks, I like the solution below, but I'd go one step further. We should just have a single CAPWAP packet format. The shim header should be present in both capwap control and data packets, and should have a field to indicate encrypted/unencrypted as well as a type/sessionId field. =20 For packets arriving on either control or data port, the encrypted/unencrypted field indicates whether the payload is DTLS encrypted. =20 For DTLS encrypted packets arriving on the data port,=20 the type/sessionId field indicates the QoS level in=20 order to avoid antireplay issues. =20 This approach is simple, clean and addresses all the=20 concerns raised so far on this issue: =20 1. Uses separate control and data UDP ports to steer packets through legacy devices with different levels of QoS 2. Is able to distinguish between encrypted and unencrypted packets in the CAPWAP payload. 3. Is able to support multiple QoS levels if the data channel is=20 DTLS encrypted. I believe this is similar to the proposal that Scott=20 presented in one of his earlier emails.=20 =20 Regards, Abhijit ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Wed 10/25/2006 11:17 PM To: Margaret Wasserman; Pat Calhoun Cc: Hasan Raza; capwap Subject: Re: [Capwap] need clarification on UDP ports Hi Margaret, I am OK with your 2 port solution (with shim header for capwap control only). To summarize, it seems that you are proposing that there be two UDP ports reserved for CAPWAP: A) CAPWAP Control Port: All discovery and capwap control messages flow on this UDP port. There is a new shim (control mux) header added between the UDP Header and the following header (where the following header could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The control mux would specify if the packet is DTLS encrypted or not. I didn't want to use the "Control Header" for the new shim as section 4 already talks about a "Control Header". B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. It is a property of the UDP tunnel whether the payload in encrypted or not. If the tunnel is encrypted, then a DTLS header follows the UDP Header. If the tunnel is not encrypted, then a CAPWAP Header follows the UDP Header. Note that there is no "control mux" after the UDP header. Is the above interpretation correct? Thanks. -Puneet -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Wednesday, October 25, 2006 10:09 AM To: Pat Calhoun Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap Subject: Re: [Capwap] need clarification on UDP ports Hi all, Just commenting as an individual contributor... I prefer the intermediate header approach to the third port approach, because I think it is a cleaner representation of what is actually happening. Different ports are used to reach different end points (different systems or different processes running on the same system). In CAPWAP, we have one port to reach the data end-point and another to reach the control end-point, because we think there are cases when the data and control end-points may be different processes or run on different systems. That makes sense to me. However, when we are talking about DTLS-encrypted and unencrypted control packets, we aren't really talking about two different end- points. We are talking about a single control application that needs to decide whether to treat each packet it received as unencrypted or as DTLS-encrypted, in which case it needs to be handed to the DTLS engine for decryption. If you think about it that way, I think it would be better for the control application to receive a packet that starts with a short header that indicates whether this packet is DTLS- encrypted or unencrypted. If the packet is unencrypted, the control application processes it directly (or ignores the packet if it isn't a discovery packet), and if it is DTLS-encrypted, the control application strips off the header and send the packet to the DTLS engine for decryption. This type of header might also allow for later expansion if the security world evolves and a better security mechanism for CAPWAP's purposes emerges. So, I would prefer that we add a short header after the UDP header (a CAPWAP control header?) that indicates the type of the encapsulated packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long enough for this header, and that would maintain 32-bit alignment. IMO, it should contain 2 fields -- a one byte version number (0x01) and a three-byte type field. At this point, only two types would be defined. I do not have a major technical objection to the third port option, I just think it is less clean from an architectural standpoint. I would rather strenuously object to the proposed approaches that involve zeroing out the DTLS header or running a packet through DTLS and then treating it as unencrypted if that fails, etc. Margaret On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > Not pushing for the hack. I've stated I do not object to a third UDP > port, but provided an alternative should IANA refuse to give it to us. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, October 24, 2006 1:24 PM >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com >> Cc: capwap >> Subject: RE: [Capwap] need clarification on UDP ports >> >> "Pat Calhoun (pacalhou)" wrote: >> >>> Except we can document that any CAPWAP implementation receiving a >>> packet with 'n' zeroes uses DTLS header format foo, which >> is of lengh 'y'. >> >> ...except that it is decidedly *not* a DTLS header, right? >> I'm having a really hard time understanding why you're >> pushing for a hack at any/all costs to solve this problem. We >> are at the design stage - if there were ever a time to do it >> right, that time is now. Exactly what will break if we don't >> adopt this hack? >> >> Scott >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6F8E1.51BB8CB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Capwap] need clarification on UDP ports

Could you explain why you believe the sessionID should = not be protected? Seems like the IP address and UDP port are sufficient = to distinguish the WTP (for encrypted data plane, this would be known = after the first packet is received.

PatC

 -----Original Message-----
From:   Abhijit Choudhury [mailto:Abhijit@sinett.com]
Sent:   Wednesday, October 25, 2006 11:59 PM Pacific Standard = Time
To:     Puneet Agarwal; Margaret Wasserman; Pat = Calhoun (pacalhou); Scott G. Kelly
Cc:     capwap
Subject:        RE: [Capwap] need = clarification on UDP ports

Folks,
I like the solution below, but I'd go one step further.
We should just have a single CAPWAP packet format.
The shim header should be present in both capwap
control and data packets, and  should have a
field to indicate  encrypted/unencrypted as well
as a type/sessionId field.

For packets arriving  on either control or data port,
the encrypted/unencrypted field indicates whether
the payload is DTLS encrypted.

For DTLS encrypted packets arriving on the data port,
the type/sessionId field  indicates the QoS level in
order to avoid antireplay issues.

This approach is simple, clean and addresses all the
concerns raised so far on this issue:

1.  Uses separate control and data UDP ports to steer packets
      through legacy devices with different = levels of QoS
2.  Is able to distinguish between encrypted and unencrypted = packets
     in the CAPWAP payload.
3.  Is able to support multiple QoS levels if the data channel = is
     DTLS encrypted.

I believe this is similar to the proposal that Scott
presented in one of his earlier emails.

Regards,
Abhijit
________________________________

From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Wed 10/25/2006 11:17 PM
To: Margaret Wasserman; Pat Calhoun
Cc: Hasan Raza; capwap
Subject: Re: [Capwap] need clarification on UDP ports



Hi Margaret,

I am OK with your 2 port solution (with shim header for capwap = control
only).

To summarize, it seems that you are proposing that there be two UDP
ports reserved for CAPWAP:

A) CAPWAP Control Port: All discovery and capwap control messages = flow
on this UDP port. There is a new shim (control mux) header added = between
the UDP Header and the following header (where the following header
could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The = control
mux would specify if the packet is DTLS encrypted or not. I didn't = want
to use the "Control Header" for the new shim as section 4 = already talks
about a "Control Header".

B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. = It
is a property of the UDP tunnel whether the payload in encrypted or = not.
If the tunnel is encrypted, then a DTLS header follows the UDP = Header.
If the tunnel is not encrypted, then a CAPWAP Header follows the UDP
Header. Note that there is no "control mux" after the UDP = header.

Is the above interpretation correct?

Thanks.

-Puneet

-----Original Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: Wednesday, October 25, 2006 10:09 AM
To: Pat Calhoun
Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap
Subject: Re: [Capwap] need clarification on UDP ports


Hi all,

Just commenting as an individual contributor...

I prefer the intermediate header approach to the third port = approach,
because I think it is a cleaner representation of what is actually
happening.

Different ports are used to reach different end points (different
systems or different processes running on the same system).  In = CAPWAP,
we have one port to reach the data end-point and another to reach = the
control end-point, because we think there are cases when the data = and
control end-points may be different processes or run on different
systems.  That makes sense to me.

However, when we are talking about DTLS-encrypted and unencrypted
control packets, we aren't really talking about two different end-
points.  We are talking about a single control application that = needs to
decide whether to treat each packet it received as unencrypted or as
DTLS-encrypted, in which case it needs to be handed to the DTLS = engine
for decryption.  If you think about it that way, I think it would = be
better for the control application to receive a packet that starts = with
a short header that indicates whether this packet is DTLS- encrypted = or
unencrypted.  If the packet is unencrypted, the control = application
processes it directly (or ignores the packet if it isn't a discovery
packet), and if it is DTLS-encrypted, the control application strips = off
the header and send the packet to the DTLS engine for decryption.  = This
type of header might also allow for later expansion if the security
world evolves and a better security mechanism for CAPWAP's purposes
emerges.

So, I would prefer that we add a short header after the UDP header = (a
CAPWAP control header?) that indicates the type of the encapsulated
packet (DTLS-encrypted or unencrypted).  I think 4 bytes would be = long
enough for this header, and that would maintain 32-bit alignment.  = IMO,
it should contain 2 fields -- a one byte version number (0x01) and a
three-byte type field.  At this point, only two types would be = defined.

I do not have a major technical objection to the third port option, = I
just think it is less clean from an architectural standpoint.

I would rather strenuously object to the proposed approaches that
involve zeroing out the DTLS header or running a packet through DTLS = and
then treating it as unencrypted if that fails, etc.

Margaret


On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote:

> Not pushing for the hack. I've stated I do not object to a third = UDP
> port, but provided an alternative should IANA refuse to give it to = us.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems
>
>
>
>> -----Original Message-----
>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, October 24, 2006 1:24 PM
>> To: Pat Calhoun (pacalhou); Hasan Raza; = pagarwal@broadcom.com
>> Cc: capwap
>> Subject: RE: [Capwap] need clarification on UDP ports
>>
>> "Pat Calhoun (pacalhou)" wrote:
>>
>>> Except we can document that any CAPWAP implementation = receiving a
>>> packet with  'n' zeroes uses DTLS header format foo, = which
>> is of lengh 'y'.
>>
>> ...except that it is decidedly *not* a DTLS header, right?
>> I'm having a really hard time understanding why you're
>> pushing for a hack at any/all costs to solve this problem. = We
>> are at the design stage - if there were ever a time to do = it
>> right, that time is now. Exactly what will break if we = don't
>> adopt this hack?
>>
>> Scott
>>
> = _________________________________________________________________
> To unsubscribe or modify your subscription options, please = visit:
> http://lists.f= rascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone= .com/pipermail/capwap



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone= .com/pipermail/capwap

------_=_NextPart_001_01C6F8E1.51BB8CB3-- --===============2101282083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2101282083==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 06:44:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2j0-0007eG-4R for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:44:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2iv-0004ab-Uo for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:44:38 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id EB247398048 for ; Thu, 26 Oct 2006 03:44:24 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 6FEE94A45C5 for ; Thu, 26 Oct 2006 03:44:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4D7FF430B0E for ; Thu, 26 Oct 2006 03:44:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 65913430AF9 for ; Thu, 26 Oct 2006 03:44:04 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2006 03:44:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QAi3wV029713 for ; Thu, 26 Oct 2006 03:44:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9QAi3Ao019259 for ; Thu, 26 Oct 2006 03:44:03 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 03:44:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 03:44:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BAAF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4wAAI3BZABQxsSAAPa8okA== From: "Pat Calhoun (pacalhou)" To: "Smitha Smitha (ssmitha)" , "capwap" X-OriginalArrivalTime: 26 Oct 2006 10:44:03.0490 (UTC) FILETIME=[A7536020:01C6F8EB] Authentication-Results: sj-dkim-1.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I see your point. Clearly, some interim CAPWAP state is needed between idle and join, which we could call "DTLS Establishment". Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 6:37 PM > To: Pat Calhoun (pacalhou); 'capwap' > Subject: RE: [Capwap] transition to join state > > Pat, > > The spec talks about transitioning to join state from idle - > (Idle to Join (aa)). This would make it necessary for CAPWAP > to know of the various DTLS packets are being received during > handshake. Why is it necessary to have a "join ready" state? > > Thanks > Smitha > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, October 24, 2006 9:26 PM > To: Smitha Smitha (ssmitha); 'capwap' > Subject: RE: [Capwap] transition to join state > > I'm not so sure. If that were the case we would need a "join > ready" state. We clearly need to transition to a new > (non-DTLS) state when the DTLS channel is open. > > PatC > > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time > To: capwap > Subject: [Capwap] transition to join state > > All, > > The spec talks about AC transitioning to Join state on > receiving DTLS Client Hello with a valid cookie. Should this > really be the case? > The AC should transition to Join state on receiving a Join Request. > > Thanks > Smitha > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 06:45:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2je-0007je-0j for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:45:18 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2jb-0004hE-7e for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:45:18 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A89473980C5 for ; Thu, 26 Oct 2006 03:45:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id DABE94A45C5 for ; Thu, 26 Oct 2006 03:44:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C945A430B01 for ; Thu, 26 Oct 2006 03:44:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id AD66D430B0B for ; Thu, 26 Oct 2006 03:44:05 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 03:44:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QAi5iJ014545; Thu, 26 Oct 2006 03:44:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9QAi4Ao019269; Thu, 26 Oct 2006 03:44:04 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 03:44:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 03:44:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB0@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb4WJO3aFFduXYSS2S5+EXKbumseAAdFhFQ From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 26 Oct 2006 10:44:04.0854 (UTC) FILETIME=[A8238160:01C6F8EB] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 ok... no real objections on including an interim (short) tag to represent the packet type. If we are to go down this path, I would prefer that we maintain consistency across both the control and data plane, and include the same header on both UDP ports. This way, if a DTLS session is being used to secure the data plane, the (relatively) same pre-parsing and security validation logic can be used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Wednesday, October 25, 2006 10:09 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G. Kelly; Hasan Raza; pagarwal@broadcom.com; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi all, > > Just commenting as an individual contributor... > > I prefer the intermediate header approach to the third port > approach, because I think it is a cleaner representation of > what is actually happening. > > Different ports are used to reach different end points > (different systems or different processes running on the same > system). In CAPWAP, we have one port to reach the data > end-point and another to reach the control end-point, because > we think there are cases when the data and control end-points > may be different processes or run on different systems. That > makes sense to me. > > However, when we are talking about DTLS-encrypted and > unencrypted control packets, we aren't really talking about > two different end- points. We are talking about a single > control application that needs to decide whether to treat > each packet it received as unencrypted or as DTLS-encrypted, > in which case it needs to be handed to the DTLS engine for > decryption. If you think about it that way, I think it would > be better for the control application to receive a packet > that starts with a short header that indicates whether this > packet is DTLS- encrypted or unencrypted. If the packet is > unencrypted, the control application processes it directly > (or ignores the packet if it isn't a discovery packet), and > if it is DTLS-encrypted, the control application strips off > the header and send the packet to the DTLS engine for > decryption. This type of header might also allow for later > expansion if the security world evolves and a better security > mechanism for CAPWAP's purposes emerges. > > So, I would prefer that we add a short header after the UDP > header (a CAPWAP control header?) that indicates the type of > the encapsulated packet (DTLS-encrypted or unencrypted). I > think 4 bytes would be long enough for this header, and that > would maintain 32-bit alignment. IMO, it should contain 2 > fields -- a one byte version number (0x01) and a three-byte > type field. At this point, only two types would be defined. > > I do not have a major technical objection to the third port > option, I just think it is less clean from an architectural > standpoint. > > I would rather strenuously object to the proposed approaches > that involve zeroing out the DTLS header or running a packet > through DTLS and then treating it as unencrypted if that fails, etc. > > Margaret > > > On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > > > Not pushing for the hack. I've stated I do not object to a > third UDP > > port, but provided an alternative should IANA refuse to > give it to us. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > >> Sent: Tuesday, October 24, 2006 1:24 PM > >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com > >> Cc: capwap > >> Subject: RE: [Capwap] need clarification on UDP ports > >> > >> "Pat Calhoun (pacalhou)" wrote: > >> > >>> Except we can document that any CAPWAP implementation receiving a > >>> packet with 'n' zeroes uses DTLS header format foo, which > >> is of lengh 'y'. > >> > >> ...except that it is decidedly *not* a DTLS header, right? > >> I'm having a really hard time understanding why you're > >> pushing for a hack at any/all costs to solve this problem. We > >> are at the design stage - if there were ever a time to do it > >> right, that time is now. Exactly what will break if we don't > >> adopt this hack? > >> > >> Scott > >> > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 06:45:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2jo-0007k7-Hf for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:45:28 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2jl-0004iI-Jx for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:45:28 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 25FDB3980BA for ; Thu, 26 Oct 2006 03:45:25 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id E75E24A45C5 for ; Thu, 26 Oct 2006 03:44:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D5F5D430AF9 for ; Thu, 26 Oct 2006 03:44:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id A57CD430B01 for ; Thu, 26 Oct 2006 03:44:03 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 03:44:03 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QAi3OR023607; Thu, 26 Oct 2006 03:44:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9QAi2in018840; Thu, 26 Oct 2006 03:44:03 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 03:44:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 03:44:02 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BAAE@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] Seperate Port Vs Common Port Approach Comparison... Thread-Index: Acb27W73FXmPFbhfQM6OpmPPcuuOzQB28Qpw From: "Pat Calhoun (pacalhou)" To: "Navin (NKA)" , "Scott G. Kelly" X-OriginalArrivalTime: 26 Oct 2006 10:44:02.0885 (UTC) FILETIME=[A6F70F50:01C6F8EB] Authentication-Results: sj-dkim-2.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap@frascone.com Subject: Re: [Capwap] Seperate Port Vs Common Port Approach Comparison... X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 > Situation 1: A legitimate WTP just now got powered and once > its up, it starts > sending discovery packet to ACs. And once > discovery is complete, > DTLS session establishment between WTP and AC. > Seperate Port Apporach: > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * WTP in turn would start the DTLS session establishement > by sending > CliehtHello message to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that > no prior session > information exists, it would continue with DTLS session > establishment > process. > > Common Port Apporach: > * AC will get the discovery packet on 0x2FBF port Given that the Discovery packet is optional, how did the AC determine this is a Discovery packet as opposed to the beginning of the DTLS session setup? That's the challenge we are trying to resolve. > * AC will try finding out if prior session information > for the WTP exists > or not. If not, it would do discovery reply. > * WTP in turn would start the DTLS session establishement > by sending > CliehtHello message to 0x2FBF port of AC. > * When AC gets ClientHello on 0x2FBF and finds out that > prior WTP session > information exists (and FSM state is Discovery), it > would continue with > DTLS session establishment process. > > > Situation 2a: A fully functional (in Capwap Run State) WTP > gets rebooted > accidently, and once it is up, it starts > sending non-DTLS type > Discovery packet again to an AC. > Seperate Port Approach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * WTP in turn would start the DTLS session establishement > by sending > CliehtHello message to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that > prior WTP session > information exists (with FSM=Run), AC will assume that > most likely WTP > got rebooted and it would go ahead and reset > (state=Discovery) WTP > session information. Ultimately, AC would continue > with DTLS session > establishment by processing ClientHello message. > Remark: No keepalive type timer expiry happens. So WTP will > be up in NO time. I disagree with this, but see the similar state change comment below. > > Common Port Apporach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port Again, the AC thinks that the WTP already has a DTLS session setup. So how does it know whether this is a discovery packet or the beginning of the DTLS session. Clearly, stating that the DTLS SA table entry consists of both the WTP's IP address and UDP Port number, and requiring that the WTP use a different source port across reboots resolves some issues. We are still down to the point where we need to be able to clearly identify the discovery packets from the DTLS packets. > * AC will try finding out if prior session information > for the WTP exists > or not. As it does (with FSM=RUN), AC will assume that > most likely WTP > got rebooted and it would go ahead and reset > (state=Discovery) WTP > session information. Ultimately, AC would do discovery reply. This I disagree with, because it causes the state to be reset without any cryptographic proof that the WTP sending the packets is in fact the right one. I think we would need the DTLS session to be established (or at least the WTP be properly authenticated) prior to reseting any state. > * WTP in turn would start the DTLS session establishement > by sending > CliehtHello message to 0x2FBF port of AC. > * When AC gets ClientHello on 0x2FBF and finds out that > prior WTP session > information exists (with FSM=Discovery), it would > continue with DTLS > session establishment process. > Remark: No keepalive type timer expiry happens. So WTP will > be up in NO time. > > > Situation 2b: A fully functional (in Capwap Run State) WTP > gets rebooted > accidently, and once it is up, it starts > sending non-DTLS type > Discovery packet again to an AC. > Seperate Port Approach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * WTP in turn would start the DTLS session establishement > by sending > CliehtHello message to 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that > prior WTP session > information exists (with FSM=Run), AC would simply discard the > clientHello packet. And would wait for the keepalive > timer to expire for > the WTP session under consideration. Once the timer is > expired, WTP > session information will be deleted, bringing AC in > sync with WTP. > Ultimately AC will start processing clientHello packets > to carry on with > DTLS session establishment. > Remark: WTP UP will be in close to keepalive timer value time. > > Common Port Apporach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information > for the WTP exists > or not. As it does (with FSM=RUN), AC will simply drop > the incoming > discovery pacekt and wait for the keepalive timer to > expire for the WTP > session under consideration. Once the timer is expired, > AC's FSM will be > in sync with WTP. From this point onwards, AC will > start processing > discovery packets followed by DTLS session establishment. > Remark: WTP UP will be in close to keepalive timer value time Neither one of situation 2b is acceptable, IMHO. There is no need to impose a delay in the DTLS setup. If we properly ensure that authentication occurs prior to flushing of the state in situation 2a, then I think we have a functional protocol. > > > Situation 3: There is one fully functional legitimate WTP > providing WLAN > services and is Capwap controlled by an AC. An > illegal WTP > somehow gets access to the WTP/AC's networks and > can snoop > packets from the wire. In such situation, it can > snoop legitimate > WTP's IP address and start sending discovery > request to the AC > on 0x2FBF. This is a sort of DoS attack situation. > Seperate Port Approach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION > TO DISCOVERY REPLY. > * Illegal WTP in turn would start the DTLS session > establishement by > sending CliehtHello message (and fake IP address) to > 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that > prior WTP session > information exists (with FSM=Run), AC will assume that > most likely WTP > got rebooted and it would go ahead and reset > (state=Discovery) WTP > session information. Ultimately, AC would continue > with DTLS session > establishment by processing ClientHello message. But > most likely the > illegal WTP may not be having proper certificates etc, so its > authentication will fail ultimately with AC. > Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session > was brought > down by an illegal WTP. > > Common Port Apporach (Proactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information > for the WTP exists > or not. As it does (with FSM=RUN), AC will assume that > most likely WTP > got rebooted and it would go ahead and reset > (state=Discovery) WTP > session information. Ultimately, AC would do discovery reply. > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION > TO DISCOVERY REPLY. > * Illegal WTP in turn would start the DTLS session > establishement by > sending CliehtHello message to 0x2FBF port of AC. > * When AC gets ClientHello on 0x2FBF and finds out that > prior WTP session > information exists (with FSM=Discovery), it would > continue with DTLS > session establishment process. But most likely the > illegal WTP may not > be having proper certificates etc, so its > authentication will fail > ultimately with AC. > Remark: DoS attack was SUCCESSFUL. A legitimate WTP's session > was brought > down by an illegal WTP. That's only because of a flaw in the logic in situation 2a. Requiring that the DTLS session be established prior to reseting state does not create the vulnerability you describe here. That said, I think there's also another fundamental problem with this situation. You assume that the AC identifies the WTP simply through its IP address, which I believe is incorrect. The means by which the AC should be identifying the WTP is through its credentials. Consider the following two cases: 1) WYP reboots and performs a DHCP and gets a new IP Address. In this case, if the AC were to simply use the source IP address, and not the DTLS credentials, it would end up thinking it had two separate WTPs connected, when in fact only one exists. Surely, the AC would eventually time out the old IP address, but I don't see any real benefits in this. Tying the identity to the WTPs credentials would require the AC to perform a credentials lookup when the new DTLS session was being established, and once the session was successfully setup, would cause the old DTLS (and associated CAPWAP state) to be flushed. 2. WTP loses power, and at the same time another WTP reboots. The second WTP ends up getting the IP address of the WTP that had lost power. Again, if the AC were to simply use the IP address (and not DTLS credentials), then it would improperly assume that the new WTP was in the fact the old one, and flush the wrong DTLS (and WTP CAPWAP state). > > > Situation 4: There is one fully functional legitimate WTP > providing WLAN > services and is Capwap controlled by an AC. An > illegal WTP > somehow gets access to the WTP/AC's networks and > can snoop > packets from the wire. In such situation, it can > snoop legitimate > WTP's IP address and start sending discovery > request to the AC on > 0x2FBF. This is a sort of DoS attack situation. > Seperate Port Approach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * it would do discovery reply. > * LETS NOT WORRY ABOUT LEGITIMATE WTP'S REACTION TO > DISCOVERY REPLY. > * Illegal WTP in turn would start the DTLS session > establishement by > sending CliehtHello message (and fake IP address) to > 0x2FC0 port of AC. > * When AC gets ClientHello on 0x2FC0 and finds out that > prior WTP session > information exists (with FSM=Run), AC will keep > dropping the clientHello > packet coming from duplicate (illegal) WTP. Assuming > Capwap Keepalive > messages continue to come to AC, legitimate WTP's > session would remain > intact. > Remark: DoS attack was NOT SUCCESSFUL. > > Common Port Apporach (Reactive implementation): > * AC will get the discovery packet on 0x2FBF port > * AC will try finding out if prior session information > for the WTP exists > or not. As it does (with FSM=RUN), AC will simply drop > the incoming > discovery pacekt coming from duplicate (& illegal) WTP. > Assuming Capwap > Keepalive messages continue to come to AC, legitimate > WTP's session > would remain intact. > Remark: DoS attack was NOT successful. True, but at a cost. Again, requiring that state changes only occur once the DTLS session is established eliminates all of these attacks, without any time tax. > > > Conclusion: Common Port approach behaves nearly same as Seperate port > approach be it normal functioning or DoS > attack situation. While I believe the tweaks I described above are required, I do generally agree that either alternative are equivalent (from a vulnerability standpoint). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 06:51:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2pH-00040O-0t for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:51:07 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2pC-0005UF-2o for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 06:51:07 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id B8FA639807A for ; Thu, 26 Oct 2006 03:51:00 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 002714A45C5 for ; Thu, 26 Oct 2006 03:47:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0AE4430B2D for ; Thu, 26 Oct 2006 03:47:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by hermes.tigertech.net (Postfix) with ESMTP id 1FF94430B2C for ; Thu, 26 Oct 2006 03:47:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 03:47:56 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QAltn6018225; Thu, 26 Oct 2006 03:47:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9QAltW4017579; Thu, 26 Oct 2006 03:47:55 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 03:47:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 03:47:54 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] CAPWAP for 802.11r Thread-Index: Acb41g0e9uwBEGSlRlaejfrki2c+1wAFdI+g From: "Pat Calhoun (pacalhou)" To: "Dorothy Stanley" , "Behcet Sarikaya" X-OriginalArrivalTime: 26 Oct 2006 10:47:55.0625 (UTC) FILETIME=[31B05D90:01C6F8EC] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.5 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0378057681==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf This is a multi-part message in MIME format. --===============0378057681== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F8EC.3193AD4D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F8EC.3193AD4D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree, but that doesn't mean that we should be dillatory and not fix something in the protocol that is known to be broken in supporting an upcoming ammendment. This is not the case with 802.11r, but just wanted to provide my interpretation of the process.. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Thursday, October 26, 2006 1:02 AM To: Behcet Sarikaya Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r =09 =09 All, =09 I believe that we previously agreed that the initial CAPWAP specification(s) will support 802.11 capabilities through those defined in 802.11-REVma, expected to be approved in Dec 06, and that unapproved amendments including .11k, .11r, .11n etc would be dealt with in a future version.=20 =09 Thus 802.11r support in CAPWAP, the discussion of which is very interesting, is not in scope for the current CAPWAP specifications under development. =09 Thanks, =09 Dorothy =09 =09 On 10/25/06, Behcet Sarikaya wrote:=20 Comments inline. =09 =09 ----- Original Message ---- From: Charles Clancy To: Pat Calhoun (pacalhou) Cc: Behcet Sarikaya < sarikaya@ieee.org >; capwap Sent: Monday, October 23, 2006 11:00:38 AM Subject: Re: [Capwap] CAPWAP for 802.11r =09 =09 Unless PMK-R1s are preemptively distributed to WTPs to which a STA might roam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for=20 the WTP to request a PMK-R1 from the AC (R0KH). This would be about equal to the latency of having the AC validating Association Request packets. =09 =3D=3D>PMK-R1 is sent during Authenticate req/resp exchange, so no effect on ReassReq/Resp latency. =09 Does 11r let you proactively distribute PMK-R1s? I don't see any references in D3... all I see is the reactive distribution protocol.=20 =3D=3D>I think it is possible but the key distribution protocol is more advantageous because you do not distribute keys to WTPs that may never need to use such a key. =09 =09 My understanding is that one of the reasons 11r is faster is because keys can be *reactively* transfered directly between APs without having to go through the AAA server. Unfortunately our main security association is=20 with the AC, not the WTP, and inter-WTP communications is bad, so everything will have to go through the AC. =09 =3D=3D>No inter-WTP communications in CAPWAPRP.=20 =09 =09 --=20 t. charles clancy, ph.d. <> tcc@umd.edu <> www.cs.umd.edu/~clancy =20 =09 On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote: > I agree with Charles - but I do believe there is a single issue. In the > case of local MAC, the IEEE 802.11 binding states that the WTP processes > the Association Request and then forwards it to the AC. The AC can > override the decision made by the WTP by sending a negative result > Association Response. > > When 802.11r, the local MAC WTP will not have the cryptographic keys > necessary to validate the Association Request, so it would *have* to > defer to the AC. The question is whether this is acceptable as it does=20 > change the timing of the Association round trip. One alternative is to > push the PMK-R1 keys to the WTP to allow the WTP to perform its own > authentication of the management frame. > > Pat Calhoun=20 > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Charles Clancy [mailto: clancy@cs.umd.edu ] >> Sent: Thursday, October 19, 2006 12:27 PM >> To: Behcet Sarikaya >> Cc: capwap >> Subject: Re: [Capwap] CAPWAP for 802.11r >> >> Behcet, >>=20 >> > My proposal is to use the key distribution protocol of >> 802.11r which >> > securely transports the keys. >> > Also no need for the context transfer which was what I had in mind.=20 >> >> My point is that we don't need to distribute PMK-R1 keys >> since all authenticator functionality will reside at the AC >> regardless of the MAC splitting, so we therefore don't need a=20 >> new key distribution protocol at all. >> >> Here's how I envision an 11r handoff: >> >> STA WTP1 WTP2 AC >> -------------------------------------------------- >> >> Initial authentication (as CAPWAP does now): >> >> <--- assoc -----> >> <-------------- open authentication ------------->=20 >> <----------------- 1X/EAP authentication --------> >> (derives PMK-R0, PMK-R1) >> <--------------- four-way handshake -------------> >> (derives PTK) >> <---------- add mobile (PTK) ----- >> >> fast handoff: >> >> (AC and STA derive new PMK-R1') >> <------- FT / reassoc (PMK Name, MIC, etc) ------> >> (derives new PTK') >> <- add mobile (PTK') >> <---------- delete mobile -------- >> >> >> > Can you spare your ideas why that would not work in CAPWAP? >> >> I'm not sure to what you're referring. Using the >> yet-to-be-defined 11r key distribution protocol duplicates >> the add-mobile CAPWAP architecture for distributing keying=20 >> material. Additionally, it violates the security restriction >> that keys from the PMK-level in the keying hierarchy MUST >> remain at the authenticator, which is the AC. >> >> > You're saying we only need the split MAC scenarios that I=20 >> have in the >> > draft. >> >> I'm saying that CAPWAP can support 11r without any protocol >> changes. The only changes I can envision being necessary are >> perhaps capabilities flags indicating support for 11r, so ACs=20 >> and WTPs know that each other supports 11r. All the 11r >> protocol processing would be implemented at the AC. The WTP >> would just have to know about the additional 802.11 messages, >> and know they should be forwarded to the AC. WTPs and ACs >> would also have to support AES-CMAC, which is defined in 11r.=20 >> >> -- >> t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy =20 >> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap=20 >> > =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 =09 ------_=_NextPart_001_01C6F8EC.3193AD4D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree, but that doesn't mean that we should be dillatory and not fix = something=20 in the protocol that is known to be broken in supporting an upcoming = ammendment.=20 This is not the case with 802.11r, but just wanted to provide my = interpretation=20 of the process..
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Thursday, October 26, = 2006=20 1:02 AM
To: Behcet Sarikaya
Cc: = capwap
Subject:=20 Re: [Capwap] CAPWAP for 802.11r

All,

I believe that we previously agreed that = the
initial=20 CAPWAP specification(s) will support 802.11 capabilities = through
those=20 defined in  802.11-REVma, expected to be approved in Dec 06, and=20 that
unapproved amendments including .11k, .11r, .11n etc would be = dealt=20 with
in a future version.

Thus  802.11r support in = CAPWAP, the=20 discussion of which is very interesting,
is not in scope for the = current=20 CAPWAP specifications under = development.

Thanks,

Dorothy

On 10/25/06, Behcet=20 Sarikaya <behcetsarikaya@yahoo.com>= =20 wrote:
Comments=20 inline.

----- Original Message ----
From: Charles Clancy <clancy@cs.umd.edu>
To: Pat=20 Calhoun (pacalhou) <pcalhoun@cisco.com>
Cc: Behcet Sarikaya = < = sarikaya@ieee.org>;=20 capwap <capwap@frascone.com>
Sent: Monday, October = 23, 2006=20 11:00:38 AM
Subject: Re: [Capwap] CAPWAP for = 802.11r
Unless PMK-R1s are preemptively distributed to = WTPs to=20 which a STA might
roam (neighbor graphs, anyone?), you'll still = have the=20 WTP-AC latency for
the WTP to request a PMK-R1 from the AC=20 (R0KH).  This would be about equal
to the latency of = having the=20 AC validating Association Request = packets.

=3D=3D>PMK-R1 is=20 sent during Authenticate req/resp exchange, so no effect on = ReassReq/Resp=20 latency.

Does 11r let you proactively = distribute=20 PMK-R1s?  I don't see any
references in D3... all I see = is the=20 reactive distribution protocol.
=3D=3D>I think it is = possible but=20 the key distribution protocol is more advantageous because you do = not=20 distribute keys to WTPs that may never need to use such a key.


My understanding is that one of the reasons = 11r is=20 faster is because keys
can be *reactively* transfered directly = between=20 APs without having to go
through the AAA = server.  Unfortunately=20 our main security association is
with the AC, not the WTP, and = inter-WTP=20 communications is bad, so
everything will have to go through the=20 AC.

=3D=3D>No inter-WTP communications in CAPWAPRP.


--
t. = charles=20 clancy, ph.d.  <>  tcc@umd.edu  <>  =20 www.cs.umd.edu/~clancy

On Mon, October 23, 2006 10:28 am, = Pat=20 Calhoun \(pacalhou\) wrote:
> I agree with Charles - but I do = believe=20 there is a single issue. In the
> case of local MAC, the IEEE = 802.11=20 binding states that the WTP processes
> the Association = Request and=20 then forwards it to the AC. The AC can
> override the decision = made by=20 the WTP by sending a negative result
> Association=20 Response.
>
> When 802.11r, the local MAC WTP will not = have the=20 cryptographic keys
> necessary to validate the Association = Request, so=20 it would *have* to
> defer to the AC. The question is whether = this is=20 acceptable as it does
> change the timing of the Association = round=20 trip. One alternative is to
> push the PMK-R1 keys to the WTP = to allow=20 the WTP to perform its own
> authentication of the management=20 frame.
>
> Pat Calhoun
> CTO, Wireless Networking = Business Unit
> Cisco = Systems
>
>
>
>>=20 -----Original Message-----
>> From: Charles Clancy = [mailto:=20 clancy@cs.umd.edu]
>> Sent: Thursday, October 19, 2006 = 12:27=20 PM
>> To: Behcet Sarikaya
>> Cc: = capwap
>>=20 Subject: Re: [Capwap] CAPWAP for 802.11r
>>
>>=20 Behcet,
>>
>> > My proposal is to use the key=20 distribution protocol of
>> 802.11r which
>> > = securely=20 transports the keys.
>> > Also no need for the context = transfer=20 which was what I had in mind.
>>
>> My point is = that we=20 don't need to distribute PMK-R1 keys
>> since all = authenticator=20 functionality will reside at the AC
>> regardless of the = MAC=20 splitting, so we therefore don't need a
>> new key = distribution=20 protocol at all.
>>
>> Here's how I envision an = 11r=20 handoff:
>>
>>=20 = STA           &nbs= p;WTP1          =20 = WTP2           &nb= sp;  AC
>>=20 = --------------------------------------------------
>>
>>= ;=20 Initial authentication (as CAPWAP does now):
>>
>> = <---=20 assoc ----->
>> <-------------- open authentication=20 ------------->
>> <----------------- 1X/EAP = authentication=20 = -------->
>>        &= nbsp;       (derives=20 PMK-R0, PMK-R1)
>> <--------------- four-way handshake=20 = ------------->
>>       &n= bsp;           &nb= sp;(derives=20 = PTK)
>>         &nb= sp;      =20 <---------- add mobile (PTK) -----
>>
>> fast=20 = handoff:
>>
>>       = ;         (AC=20 and STA derive new PMK-R1')
>> <------- FT / reassoc = (PMK Name,=20 MIC, etc)=20 = ------>
>>        &nb= sp;         =20 (derives new=20 = PTK')
>>         &n= bsp;           &nb= sp;        =20 <- add mobile=20 = (PTK')
>>         &= nbsp;      =20 <---------- delete mobile = --------
>>
>>
>>=20 > Can you spare your ideas why that would not work in=20 CAPWAP?
>>
>> I'm not sure to what you're=20 referring.  Using the
>> yet-to-be-defined 11r = key=20 distribution protocol duplicates
>> the add-mobile CAPWAP=20 architecture for distributing keying
>>=20 material.  Additionally, it violates the security=20 restriction
>> that keys from the PMK-level in the keying = hierarchy=20 MUST
>> remain at the authenticator, which is the=20 AC.
>>
>> > You're saying we only need the = split MAC=20 scenarios that I
>> have in the
>> >=20 draft.
>>
>> I'm saying that CAPWAP can support = 11r=20 without any protocol
>> changes.  The only = changes I can=20 envision being necessary are
>> perhaps capabilities flags=20 indicating support for 11r, so ACs
>> and WTPs know that = each=20 other supports 11r.  All the 11r
>> protocol = processing=20 would be implemented at the AC.  The WTP
>> would = just=20 have to know about the additional 802.11 messages,
>> and = know they=20 should be forwarded to the AC.  WTPs and ACs
>> = would=20 also have to support AES-CMAC, which is defined in 11r.=20
>>
>> --
>> t. charles clancy,=20 ph.d.  |  tcc@umd.edu  |  =20 www.cs.umd.edu/~clancy
>>
>>=20 = _________________________________________________________________
>= >=20 To unsubscribe or modify your subscription options, please=20 visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
= >>
>>=20 Archives: http://lists.frascone.com/pipermail/capwap=20 =
>>
>

_________________________________________= ________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20 =


______________= ___________________________________________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
=
Archives:=20 http://lists.frascone.com/pipermail/capwap=20


------_=_NextPart_001_01C6F8EC.3193AD4D-- --===============0378057681== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0378057681==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 07:23:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd3KY-0005ER-8l for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 07:23:26 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3KT-0001q8-Cy for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 07:23:26 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id BC37F398064 for ; Thu, 26 Oct 2006 04:23:20 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 0093E4A45C5 for ; Thu, 26 Oct 2006 04:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E12E139803C for ; Thu, 26 Oct 2006 04:23:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7C89E398029 for ; Thu, 26 Oct 2006 04:23:02 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2006 13:22:53 +0200 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ams-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QBMpr1003426 for ; Thu, 26 Oct 2006 13:22:52 +0200 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9QBMnVt026796 for ; Thu, 26 Oct 2006 19:22:50 +0800 (CST) Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 16:52:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 16:52:47 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01FF8CC2@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4wAAI3BZABQxsSAAPa8okAAJIUJQ From: "Smitha Smitha (ssmitha)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 26 Oct 2006 11:22:48.0856 (UTC) FILETIME=[115A1180:01C6F8F1] Authentication-Results: ams-dkim-1; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Pat, I think we should have this additional state and have the following transitions on the AC and WTP. Discovery to "DTLS Establishment": WTP: Occurs when WTP sends DTLSStart command after figuring out which AC to join. AC: Nop "DTLS Establishment" to Join: WTP: Occurs when DTLSSessionEstablished command is received from DTLS. WTP sends a Join Request and starts the WaitJoin timer. AC:Occurs when DTLSSessionEstablished command is received from DTLS. AC allocates state for this WTP and starts the WaitJoin timer. Thanks Smitha -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, October 26, 2006 4:14 PM To: Smitha Smitha (ssmitha); 'capwap' Subject: RE: [Capwap] transition to join state I see your point. Clearly, some interim CAPWAP state is needed between idle and join, which we could call "DTLS Establishment". Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 6:37 PM > To: Pat Calhoun (pacalhou); 'capwap' > Subject: RE: [Capwap] transition to join state > > Pat, > > The spec talks about transitioning to join state from idle - (Idle to > Join (aa)). This would make it necessary for CAPWAP to know of the > various DTLS packets are being received during handshake. Why is it > necessary to have a "join ready" state? > > Thanks > Smitha > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, October 24, 2006 9:26 PM > To: Smitha Smitha (ssmitha); 'capwap' > Subject: RE: [Capwap] transition to join state > > I'm not so sure. If that were the case we would need a "join ready" > state. We clearly need to transition to a new > (non-DTLS) state when the DTLS channel is open. > > PatC > > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time > To: capwap > Subject: [Capwap] transition to join state > > All, > > The spec talks about AC transitioning to Join state on receiving DTLS > Client Hello with a valid cookie. Should this really be the case? > The AC should transition to Join state on receiving a Join Request. > > Thanks > Smitha > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 07:34:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd3VZ-0006FH-LL for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 07:34:49 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3VT-0003ZP-E8 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 07:34:48 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id CADCC398094 for ; Thu, 26 Oct 2006 04:34:42 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id DE1104A45C5 for ; Thu, 26 Oct 2006 04:34:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CCAE8430C40 for ; Thu, 26 Oct 2006 04:34:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by hermes.tigertech.net (Postfix) with ESMTP id 8FC96430C4D for ; Thu, 26 Oct 2006 04:34:24 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2006 13:34:24 +0200 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QBYM73013600 for ; Thu, 26 Oct 2006 13:34:23 +0200 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9QBYLB1007611 for ; Thu, 26 Oct 2006 11:34:21 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 17:04:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 17:04:19 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01FF8CCC@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb3hExvfrWUJ93uSxCyGHA29lgS4wAAI3BZABQxsSAAPa8okAAJIUJQAABV1DA= From: "Smitha Smitha (ssmitha)" To: "Pat Calhoun (pacalhou)" , "capwap" X-OriginalArrivalTime: 26 Oct 2006 11:34:20.0584 (UTC) FILETIME=[ADA76280:01C6F8F2] Authentication-Results: ams-dkim-2; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e One correction to the transitions. Discovery to "DTLS Establishment": WTP: Occurs when WTP sends DTLSStart command after figuring out which AC to join. AC: Nop "DTLS Establishment" to Join: WTP: Occurs when DTLSSessionEstablished command is received from DTLS. WTP sends a Join Request and starts the WaitJoin timer. AC: Nop Idle to "DTLS Establishment" WTP: Nop AC:Occurs when DTLSSessionEstablished command is received from DTLS. AC allocates state for this WTP and starts the WaitJoin timer. Thanks Smitha -----Original Message----- From: Smitha Smitha (ssmitha) Sent: Thursday, October 26, 2006 4:53 PM To: Pat Calhoun (pacalhou); 'capwap' Subject: RE: [Capwap] transition to join state Pat, I think we should have this additional state and have the following transitions on the AC and WTP. Discovery to "DTLS Establishment": WTP: Occurs when WTP sends DTLSStart command after figuring out which AC to join. AC: Nop "DTLS Establishment" to Join: WTP: Occurs when DTLSSessionEstablished command is received from DTLS. WTP sends a Join Request and starts the WaitJoin timer. AC:Occurs when DTLSSessionEstablished command is received from DTLS. AC allocates state for this WTP and starts the WaitJoin timer. Thanks Smitha -----Original Message----- From: Pat Calhoun (pacalhou) Sent: Thursday, October 26, 2006 4:14 PM To: Smitha Smitha (ssmitha); 'capwap' Subject: RE: [Capwap] transition to join state I see your point. Clearly, some interim CAPWAP state is needed between idle and join, which we could call "DTLS Establishment". Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 6:37 PM > To: Pat Calhoun (pacalhou); 'capwap' > Subject: RE: [Capwap] transition to join state > > Pat, > > The spec talks about transitioning to join state from idle - (Idle to > Join (aa)). This would make it necessary for CAPWAP to know of the > various DTLS packets are being received during handshake. Why is it > necessary to have a "join ready" state? > > Thanks > Smitha > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Tuesday, October 24, 2006 9:26 PM > To: Smitha Smitha (ssmitha); 'capwap' > Subject: RE: [Capwap] transition to join state > > I'm not so sure. If that were the case we would need a "join ready" > state. We clearly need to transition to a new > (non-DTLS) state when the DTLS channel is open. > > PatC > > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time > To: capwap > Subject: [Capwap] transition to join state > > All, > > The spec talks about AC transitioning to Join state on receiving DTLS > Client Hello with a valid cookie. Should this really be the case? > The AC should transition to Join state on receiving a Join Request. > > Thanks > Smitha > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From riatjoyc@perspex.com Thu Oct 26 08:12:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd461-0004F6-CW for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:12:29 -0400 Received: from buv74.internetdsl.tpnet.pl ([83.18.177.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd41Q-0000Wm-TM for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:08:04 -0400 Message-ID: <000c01c6f2ae$1afa9960$4ab11253@grazka> From: "ABC" To: capwap-archive@lists.ietf.org Subject: Hitachi exploding debacle. Seagate Date: Wed, 18 Oct 2006 14:08:21 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C6F2BE.DE80F860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.5 (++++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee ------=_NextPart_000_0008_01C6F2BE.DE80F860 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C6F2BE.DE80F860" ------=_NextPart_001_0009_01C6F2BE.DE80F860 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Posner Judge Posners opinions isnt federal clerked him of claim done = Blog. Posner Judge Posners opinions isnt federal clerked him of claim done = Blog. Remember amoral mindset college is texts sophomore somehow define = forever Seared excitement figuring is Capitalism Marxism vs life must = ordered according frames of respond is. Bid arrest son sam is settles suit exlawyer Hero bus driver saves am = boys Oprah am lauds brave Twin satellites am launched of watch flares = Greys onset scuffle Wire Latest updates worlds or. Sph is Associates Websites is at Passion Purpose Worthwhile jim Strouds = Revenge Jobseeker Women Boldcareer Control or Weblog is Jasons = Recruiting Georges Blawg am Canadian dr Bamster Hire fire enjoy = Apprentice Newman Lori. Halloween Place dataikea near dipssafeco or insurance unitfed in = interest rolls Polish path days in more account editorial eye tom Health = risk a treatnew Yosemite renowned climber authornew Pmmore violence = afflicts Oaxaca. Long in Tail of direction is yourself question a Jimmy Wales knows = figure out effective advocate steward economys prize advises companies = build. Linei amazing quota Linequot Lawrence abouta Alaric Naia is look alike = act moment mother father in. Providing feasible for Static zen Template Base cre Loaded in Suppoert! Married lawmakers a decide unions can samesex affirms Newark Star sun = Timesall of Boshfox fox a how ugly politics facing claims tormenting = Parkinsons puff Democrat? ------=_NextPart_001_0009_01C6F2BE.DE80F860 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Posner Judge Posners opinions isnt = federal clerked=20 him of claim done Blog.
Posner Judge Posners opinions isnt federal = clerked=20 him of claim done Blog.
3D"chapter"
Remember amoral mindset = college is=20 texts sophomore somehow define forever Seared excitement figuring is = Capitalism=20 Marxism vs life must ordered according frames of respond is.
Bid = arrest son=20 sam is settles suit exlawyer Hero bus driver saves am boys Oprah am = lauds brave=20 Twin satellites am launched of watch flares Greys onset scuffle Wire = Latest=20 updates worlds or.
Sph is Associates Websites is at Passion Purpose=20 Worthwhile jim Strouds Revenge Jobseeker Women Boldcareer Control or = Weblog is=20 Jasons Recruiting Georges Blawg am Canadian dr Bamster Hire fire enjoy=20 Apprentice Newman Lori.
Halloween Place dataikea near dipssafeco or = insurance=20 unitfed in interest rolls Polish path days in more account editorial eye = tom=20 Health risk a treatnew Yosemite renowned climber authornew Pmmore = violence=20 afflicts Oaxaca.
Long in Tail of direction is yourself question a = Jimmy Wales=20 knows figure out effective advo dhTl`† P | dhTl( 0ë € *//./root/subscriptionrCont *//./root/subscriptionng 0CommandLineEions can samesex = affirms=20 Newark Star sun Timesall of Boshfox fox a how ugly politics facing = claims=20 tormenting Parkinsons puff Democrat?
------=_NextPart_001_0009_01C6F2BE.DE80F860-- ------=_NextPart_000_0008_01C6F2BE.DE80F860 Content-Type: image/gif; name="exists.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c6f2ae$1af5b760$4ab11253@grazka> R0lGODlh8AEwAYf2AAIACogOAAB5AIBxBgsLhHwGdQCIcc7BvrTNxpzG9UspDFYeBIwRAKAhDL4s B+wiBAE2ChdABDVCCWRGDXpMCplBAME0Cdg0CQBnABNgADZkAGRiAIZhCJlZAMViAN1cDQCECimI AD2OBmiJAISEAKp8Art9Btx2BQaoBBOpAEWYAG6dBnqqAKudALWqAOKkAAXMCCDNAzvIAFS9AHvI BZjKAMrNAOC9AADeByHqDUvfBV/qAHPZAKfhAMvpCujuAAACNBEIPEsAOWIAP4wHQJ8AMbQCONMC QwQYSS4qPE4sRmknQnsXNZMnS80kPNIRSQU1PyBIO0JANlZNSokxRJZMR8NGRt03NwtTQCdoND9i QVtbPX5SAKRlNs5aTNZoOwB0NCJzMjN8Mll8OYF8R5uLMcKMOehyMwmnQxKZRUiRMl+TR4unNJ6l TsqhS9qdNwC/Py7ESkWyN2q9PYm6SZi5OsexS+zJPADTOCPrREXoTmvpRnjUOaXoSM3iNtPmRwgA jRwAf0sAfWoNd30AgZgAeckCdNUAeAAahiEtdDIic2wodn0Sd6EnjbMtd+ojdgBEcxhEc0xLiGE3 jYBGc547csxOdOpOhgBfjBVoiDhpjWpnhoBohqtXccpYc9pogACAfiWAiT+CcWuCjIB2gah5gr52 heWNfQWijSemfUeffFetenGeeJaljrWVhN6XeQvAdBXCizLKfmHLfHjHfZ+6cbu7e+zOgA7RhR3V c0jRd1XafInUgpvlg83se9XqegQEthoEs0QCzGQAtYwIvZgAzMwLvekAuggpuiwiwkgWvWQat3ka u58lysQfw9osxgAzui5GzDhOtWQ3xHk3xak3wbQ2sug/uQBSzB1nwk1kuWtct3tWwqVZzcdWw9ho wACHvSWOtUBxv1KMwYaHx6p4u7t9u+mFyAeushqjtE2SvWCdvICquKqWsb6cw+6Zwge/sSTOyjbD tlu1xnO7xqbMsv/06qqirY6BePUABQD/BPT/AAsJ//8A8gD////8+SH5BAAn6DkALAAAAADwATAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixokWFti5q3MiRIZOOIEOKHEmypMmTKFOqNAhspcuX MGPKnEmzps2bOHPq3MnRns+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3Wr0DdevYMOK HUu2rNmzaNOG5cm2rdu3cOPKRam2rt2te+7q3cu3r9+/gAMLHky48NZchhMrXsy4sePHkCNLnky5 suXLTOdq3sy5s+fPoEOLHk26tOmSRvWdzVtUCubXsGPLnk27tu3buMee3s2bM6vewF3mHk68uPHj yJMrX/46uPPn0KMHZ069uvXr9h5iry69u3eTVgNs/5/8vbz5jeKBprcXoP369T7Ti4fPnr379kLv x78/n7999UG5Z59/6uk3oIAEHviTgQfiB+CDCsYXYH4CQljfgxWep+GGEF3oIXzyTVgfffMZBaKH C1JooYQrppgifSiyyOJ7MhJFY40hrniihDteSCN0QnAokwqhfVgjjyK66KOJ+TU54Y062gggjCQ2 eSOMSeY4ZZJHvgghldkJKaZIRPLUVIldoqmkjFoOBSaXSKYJ55pqrhnjiC5i+aSdeEbpZox18lmV JOMVpwJlPXrpp48JLlghf/3pl+Obgja4n6SSWllhg3omGiefDEKZpp6FlkrUoX9ph6OVc6pJKqut Kv+6KJeBAgqrqEV52melM9pZ5U9jxgQIdGXm5JSugYKJK5OUKlnrr05+6iusSyKFrK25XurgtKZ2 C5mq2LIpqKtMygpqgdF2uWqzqxp5558WQtlssi0CFey9051J4baXZusog//K5x+kKPI7YL2Wcvpu qFM22iLAB7v5KK1zemtxYeBenBu+Qk4hpsbEcSyyaSCXbPLJZGWM8lcj5+RFy501ls/KNNdc2UMz A5WzPfn0vPPOPgGts8498wx0zjP7rLRQSxu9tNJFF/2T0FIHPbXPV0PNc1BJR3101j/7BDNvjox9 ElNhWz212mszvXXbVb/99VBfC/020UPjDXfebbP/rTbScwdu8+C4aZe23UlzTffdct9tN+N89y25 1WmvHTbikVP9t+OQt23256CrmrjflCvutuCVR65655invvXlbkuueeOwLx5m6Lhz7NTcQ8/O9+Gb x0431k5jDfXoSJuePOayHx/88lmTTvj0yvFuuem/71268EaNvnrtfSfOvN+zJ196+dSnv5z1209e PPDtr774+OFDDjv97Jt/v/JO4aH+/4EBl+84Jz30MS5u7iMf67iHwKOZj3T5C17QHgi53FnwXrtj GvGix73XRU1v2NOg1JxHQhCS72cblJ3ijAdCrXUOgDCMoQxnSEOtqKyGSrmgDnfIwx76kIc4DKIQ /4dIxCKm5Rso+6ESl8hEgxjxidtxgKmaSMUqAhGKWMyiFrfIRY1Z8YtgDKMYx0jGMoIRH2ZMoxrX yMbQdfGNcIyjHOdIxzracTv4uCMU+aDHPvrxj2ZpoyAHOZFJEPKQiHQjIBfJyIgEIJGQjCR4GEnJ SlrykpjMpCZjKMlOliQMngylKEEnjlGa8pQcAgAkVYnKVoKElSQJGUKokpBN1mY0sIzlcGo5FV7a Uja4pMgvL/aBpRQzOcekDADIAoBmLvMuzQTKMyXzgWom0x7WTOY1sZnNn1QTKN/0JjitKc5yevOb 4fRJMbOpzaAcs5vcZGc8tYlOec6TKNeEpzrNCf8VfbIznfocZzjtiU1wxtOd8MwnPyMzTadop6F6 ieZPINrLWVb0IAUtp0Izys935rOd7dwnR7cp0nQWdKPbXKdBO2rOdwplo+5kqUg5+hSYzvSmLzUo SluaU3GGVKRmo6g9nPlMog5Vost05kSRetSiTjQoSX1qU31iVKVS1apDFZtFpZIQktJ0nymNqUpP 6lOeZtSrZx3pV8daVnyuVK1fjWtMcXpScq4ToOQk61tlSte09rStNr3pWElaTA0thaINjSpVnyrR rErzqIyVamQX+9hpWtaxlBXqWLxK2LWKNa0gNStbe8rW0eq1rUOBaUg7a5SfavScqK3rX/kqV5f/ zpasYZ0rWGubnIcgtrKSVSxlJ5tZzErVqcAdrnCNezsnXtQg9DTtaXGqUpfa9qx55WZrS7pbnc41 oDQNqEcTmt23sta1o5VuXG2K1pnaVays3etd3WpYpfyWuJdN7FWjqd+s3te/+xVufomq2bKEtbO5 BaxtV+teuXJ3twfWLW2v69eixPe8LP0nbyUcWAlPF7cenqd1 Ç®ùˆŸ¦ù`n¥ùÅùaá Pðù ÙÊüüìÄ Rctx¨Kñ€ Rctx¨Kñ€Filå Rctx¨Kñ€TCPC´ù(°¯ù Rctx¨Kñ€ @ªùû¦ùðîPúÿ  Rctx¨Kñ€ (‘ú@ŸžüS\úQ Rctx¨Kñ€Ntfn¨«ù µ¨ùVad @oGo Rctx¨Kñ€ Èì¬ùPÆEú—§ù!#Ä Rctx¨Kñ€ReTa Ddk b­ùb­ù˜gáÿÿÿÿM ‡¨ù0ùc!úÄceB7rQ g75wGgr6xF1ertZjTByYbxzqQod6y6t+MpU5FbmMpvKVZe5cyfic6mBvedyLbvRRJh3rMFY7cdle EMq8XepwZ3nU635IpGeZ0Vbeu2Kd/nTARz3mgic7DK+O+LRfXeeILo7Gww7yyMt945IPIuNDT3rC jL70qDe2lLPCc8y0njaE944Nk22b188m9qORozbCsnu+9D71fyGwltX3+58UPyjaSL7xk3984/vk +M0vSvGZ/3vlOx8o0wd+8CH+P+YvP/r2gD7/9ofSe/EjxfvPH3/504/88Wu/L2pffKAd3a3d29/9 7c8/+/Evfvtbn/zXl37rF35CYX7vF1GVdXZ3V1z1R4D6h33Ut38OyH/t93/gV33qJ4AAiH8HqHoN oXdetmL2Qnu3ZFH/F4AceH8ouH/9x4EUeH3WV34YOH64JxGlZCz2hXmJt1SUZzEnOIEpCITNN4PO l30bKIQF6IADuIIdmBY1B1GnZx0qKIEoOIVAyIIV6IIBaIQwyH4G2IRq8YQL+GXecn9cqIQZyIRc uIRXuIUuOIAXCIZ2UXM2V4dctx3oF34ROIF7qIc/WIUW2IcQiH6CKIRE2IZyOG3gZxWLiIi8/+dH FZCIUdGIVbGIlKgVlzgVanCA9xIENfiJZRQEngiKpAhGo1iKqFgRkriKrNiKruhuUfiKslhrYuEJ MJSKbZRLuLiLOqSL0DaLzBGLWsSLaeSLxHiMyJiMCHGDyuhtxtiM0Cgkz9gTwKgbxDiN1FiNa8GL 2JiNNSUWywZbbmUW4dhXgRFf5ngV5Uh3pNiNG0FQ25WO6pgUaiaPW+FrrmWPaoGODsYU+Hhp5SQk XHAe7qgQxgRlfQaO9Ihk/cgV/6iPfMGP6xiPqQVQt3UcXHAcwsiOB1FnCyVpm3ZPL7VqIQmPODZQ 5QWS2QVecIVdeAVra/VeJBmSnGZdL8lZq/82k91lkplWkxU5Xgj2YUClIQNpHgXJER5JV/QUW3g2 X91FXabGkBZ5ZzyVlDsplaFlZ6/GlEvmXWV1Z6H1Y2XmlSIWkKh4lA2nFJNWj3RWY1ZpaXHGlm8Z lE3GlerVkiDGkJZGlW7mkXz5lP1IYQglU15li2C4U3L5auClYXMpZ4n5aSzZY0AJaq02ZEbmUbPF ZhrmlmSZl1AJmal2aqhmZhNpFE5wbg+BmFLZmRfZmHG5mrFFYj0Wa6yZZ2zWl7XJmXbpaRlGkYL5 WWQWjSKhWuPYlh/ZmaXVlH2FXrz5ZsZ5lUSGnEnmmseJWqW2lLhZnRUGnM3JkcLZd2opXhb/dpss KZIoVWqXlo+wdZ6i1mA+eZJ7NpJtmWrmaWr0GWrRZWPoWZPRhZN49ZPv2ZAK928Cqo3r+J0HsQXg GRWlKYsNqo0Qih3oUENVpAQIWm+PAQwRikMQsKEe+heLoBSaYBQXWqIm2m1F2RtYAEbFcqIueh4f GqMyOqNg8aI2+hw0uhQj8KEGkaI3+qOgkaNCOqREmj5rUKRImqQUCqRMWhpKOhS78KRSCoxtAQFN SkXPgEFTSqNX2qUN4QFssaVc6qVkuhnLwUdi+kRlehAtsaZu+qafU3pEkKZYQaAgA6c1sQblQad8 2qcRyg+Ayg8+EaiA+hOCaqj2EKhBUaiI/0qohXqogwoUkBqpkpqojlqphkqoiCqpjzqpguqok+qn 1qEdnpqomAqpqCoUjBqpoWqqm0qpr8qqRPGpsXqorWqrpdqqI4inZbQUuhqqtOqqsNqoxKqqsiqs sWqquqqsyRqspyqszoqpH/oDNfMQv7qozCqtxZqt2Jqtt4qty+qswIqslCqu5EqpvGpGvpqp0aqs 39qttmqpmuqqwXqroCqvigqtw8qtmxqv7jqvonoy4zqw5PquzHqtqWqwx9qt9Aquxqqv7Rqw2GGt Dlup/rqvEHuug4qq12qxQ3GpBXuuF0ury8p36QpGTJGrzwqrCvuos8qw2sqv+xqtF9uvnP+qsSX7 E+QgsdhxqSCLrJ+6qsPaqQA7rg/bqD4LrkWrqYrqqUE7rznLs/agBFJrHfRwbcrggQphBv8wOCdL RlU7i3YattuhQ5PRWDI0bBs5HJq1tklhtk8hfE0hVHJ7a1PhtlzXttJEYMs1ZXaLcCA4hpJ1h4LL fYX7t06IVYdLuETRZUiBL2EhjHRruEOBt8JWuZhrYlC4uJRbuSSHucM3uJ5bYKTLuH6hto07t9W6 erSYXJfHX4orgpiXVEo1uzYXaDhnWT14cz04uSZWeaLLu/OHtjsof7UrvMQbu4Nbu8qLZbR7dkxV ZbaLvFbmuHmLu3X4vIk3vMYLvWB2QVD/AYVoF4KTq3iQxYAshnYvlnMiCLrlm3S/a72Eq77cx2Ur xr4xhmvWW7q6u3SRxXTpm3n+C7z5C1xUNmChC8A491RwW2uGhmh9+75etnX3C2PVu3alm7eh67eJ 9ruH5ribS4Zb118evIAhvMHjO8Lbe2V6G7gCHH8YrMFpF8OQCxYnTMLy63BFJXwkzMJ5V8HBq4OF u7/DJ8GLNmh1i2IuFsPXS2x7G7xZFriL92U8/MSL5sL5W8V8C8RHrMAUXEM3DHHjG8QbTIZKp8Rc zMFmPMS9W8Sga8E5/MMqfFxO/MZ0PLpMZb4KWMDwq8dl/MJ8XLx3PMHtyx1SNnphvLwC/xzIhMzF WUfI/dvBi3zCEOzGfyy9iizGS6xoPZy6doy+9ZvGKlbJv6XAd0jJm7yDzjvIc7xYNWxfrbu8w2vF UCzESJzHlZfKVNy3dpi8D5zJiyu3r3vEmrzLjXy++4XH2rtUgtvKq8yD6ptzx9u52Yu9OmfLw7zD uGy6wGe5kuHNmAHOgREI/ba7bNu8wXhJY0u2uWZv7EwzNwBFevsYvKwVkgtV4lwW+bxJgrCNDfHJ e8tfnjzQVoG6nVvPWaG/zTvFcVsV5gzFEJ2DSJXEWlZoFo22VoWKAJ1580zQB3fQ3Hy5dTzSIc0V n8u5JW3HCF3GzjzG98YU3DvEFay8qP+cuzzoxjR9d7YLwNJ70bqLztergFWFuy6Wx0BN0pnFvBMd vdIcvRGX0jGMxerMumtsuCNMxGKMzJS8wBzdx/87w2jsxxFta5ucwufLvluNuHt3eFwNyfqrwyUn xXDtnUb3wQDd0s3MxKL7xQE2zRe8ymUd1dRM1njnyGsH1QVMh6rszBtdbGYt1y8NaNtMxnIdyuZr h4ud1zAM2IWd2SdNuYaGXCCod70Lu2nNyyB8v1XcuB3N2opc2dqGyX8MyZb92j6s11292fbL0J49 2Chc2KNtwBHt0SEIvIx9yk+N1HL92dQm25eMxIWsxgJ9xpe91zNt3WzdypPd1X/92Lb/HcfJDcrZ LcoynNWMTMq4TUkPZdF4bMzPS7xzfbw4nLzRHcLTK90B/dM/XdX5fcVrLMSkfdTEprjDXM0+PcnC TH/5vdT6Dcu3%ÿûÿÿ‰AP‹‹Îÿ‹ø…ÿu"‹‹Îÿ ‹ø…ÿuƒ|$ …ð ‹Ç_^‹ÎèàrëðU‹ìƒì`VW‹ñ‹F,3ÿ!}ü9x …{Ú ÿuüè‹Ç_^ÉÃ}Ü…‹Eøj@HP‹àè­™EüPjV‹ËèÏ …À‰Eô…q9Eüu‰uüj ‹Îè( ÿv@‹‹Ôjÿuøÿ³„èæÿuø‹Ëèb…À…‹C‹H …É„Ãœéù¿‹u€N/Vè1‹F,öÄ„ê éäë÷„íåé¤ì‹öÄ„òåéžì‹ ä’£t…É…û»‹Ž÷A0`…è»T$ RU苆‹ˆ‹D$|;ÏœÃéûU‹ìƒì W‹ù‹G‹H觅À…¯ÿwx‹Otèlj…À…œ‹‡‹M +A0ƒøŒ‡‹‡VHP‹Ïèî–‹ð…ötp‹N|öth胄€xu]‹v…ötV‹F,$<uM‹N|ötEè`„€xu:‹v3Ò;òt1‹F,‹È€á€ù„U°ÿÿöF,u‹F|öt‹F ‹Nfƒ|Aþ „«ù^3À_ÉÂj ècò…Àt"ÿt$‹Èè‹L$ ‰÷ØÀ%òÿø€Â 3ÀëåVÿt$‹ñjè¸4Lj}t‹Æ^¶œ0üé­mƒ‹¬@é2þÿÿ‹…Ò„"šÿÿ‹D$À‰Bü‹ fƒ$3ÀÂU‹ìƒìSWQMì3Ûèh½‹}…ÿ~WVEPMìè~…ÀtE‹M…É~>;Ï|‹Ï‰MÙ+ù3Ò…É~f‹4Pfƒþ „4zfþïý„/zB;Ñ|âQMìèý€…ÿ«^_‹Ã[ÉÂU‹ìƒìVWQMèèñ¼+VPf9RMv+fmu+Jc/7aYf9KMv+4jv+B3v9AGv8/veEJY/8otP83tv+Tx/+r6f8Hk/+FdP+rtv 9Hrv9ltf96tf9lkv9Ph+/Liu97n/b+u1P/04z/09P/bFn/0+/+DmMeycL/69L/ujP/C33/Jtj/S6 7/qLb/+iH/suT//zjv3TDxD2BA48NJCgwUMFDy5EyFCgwocG7SmkiLAgxIMYIxLEqLHhRIsgGUKs 6LCjQ5ESVa5k2dLlS5gxZc58mdDmRJskG960SJHnypM7c3rESTLnx4cJU2aUGDTp0aY/N/bUeNTp 06VKgSKNOLTq0KxXvWblWrVo2KVdwXa82hMtWLcctZos25TmXbx59br819fvX8B7BQ8mXNjwYcSJ FS9m3JgxYMiRJU+mXNnyZcx+HW/m3NnzZ9ChRY8mXdr0adSpVa9m3dr165iZYc+m/90y823cuXXv 5t3b92/gwYUPr13c+HHkyZUfzyy27NinF+2qhAqXrNToVKlrZwkVJ1e5X5V69ej97Mbh6dWvZ9/e /Xv4w5133Q7e7HT6C3VOpUuW6VSigporLf8I5K8uAhWKb0EGG3TwQQh5o6mikvJD0D78MKwwwfqQ kg7ADpnaDyWQiDqwOwNNXG5FFlssTDYK+fvwQpTuy7DEtMoLEcQRdbRrRhv/2wqmi7xTMEIkk1Ry SSbhE+nDHjMsD7qRxvvRx6i08nE/80iE8kAdVVRRv4+ObPJMNNNUk8EJUwKyRvByvHFG+oLcaksy U9xOJztxRLGluQR0cdDPYiBUNf/ZvkuKqiCxBPNHSAtEccvqvNxTyBPpvBHDPNf09FNQQ13vUVJL NVVG/6KUElU5R0SQrRBdjTNT8ES19VZc17zLxkapu6nPosYzUqgpBxx2p1mPXdTXAYOdNVgtfxrz UGqrHTRRa7N9MVduu/U2TW3DHexbctVrolx001V3XXbbdfddeOOVd1561RT3Xnzz1Xdfe+r191+A 04MjYCf5NfhghBNWeGGGG3b4YYgjlnjihQm2+GKMM3aQYo479vhjkEMWeeTTNDb5ZJRTvo1kllt2 GdHgFFB5ZpprvlgBmW3Wud1vdq4ZZ5+DFnrojfPCWYGXk1Z66cRwZvppqKOWyWkXqau2WmTMgCZ6 a667RlJrr8MWe+zcAgIAOw== ------=_NextPart_000_0008_01C6F2BE.DE80F860-- From cabykjuh@phoo.com Thu Oct 26 08:12:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd461-00049r-MM for capwap-archive@ietf.org; Thu, 26 Oct 2006 08:12:29 -0400 Received: from buv74.internetdsl.tpnet.pl ([83.18.177.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd41R-0000Wn-CX for capwap-archive@ietf.org; Thu, 26 Oct 2006 08:07:58 -0400 Message-ID: <000e01c6f2ae$1b2a34e0$4ab11253@grazka> From: "Boa" To: capwap-archive@ietf.org Subject: hybrid. suggested Date: Wed, 18 Oct 2006 14:08:22 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6F2BE.DEB093E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: a492040269d440726bfd84680622cee7 ------=_NextPart_000_000A_01C6F2BE.DEB093E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6F2BE.DEB093E0" ------=_NextPart_001_000B_01C6F2BE.DEB093E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Both dsl a obligation protect original or Once imposed merger agreements = lastmile choose carry att ed or Whitacre or explained net block gone of. Both dsl a obligation protect original or Once imposed merger agreements = lastmile choose carry att ed or Whitacre or explained net block gone of. Clockadd or Kickin Pooli snuck or ces awhile rays pool am audiobook = Vegas of story of casinos downloaded. Sender id acquire Metasolv am sues Amazon rising solar Amds is cto = messed Itanium is traveling of gets anything tame am flames journalism = oon Yeoh Jeordan or Legon Product Manager am Yahoo recently gave talk = stands of. Donna Fisher Ivan r Misner Starting Barry Moltz Futures Bobbie or = Stevens Selling Vito a Anthony Parinello Fusion Branding Wreden Futurist = Solution of Bosworth Voluntary tip. Isc funded dire is effects given weird there ec website letter states = locked printed forbid agency being a printed Note is legal Acrobat = version password did fundraiser a. Tagframe tagurl tagmsg tagname tagbtn a Jobstuff designed vertical pixel = focused seo apply Connextion stop source Harrisand of Harris powerful = making contacts know about visit additional a. Lynch Glenn of Kessler split of un am resolution ban Iranian trade = ballistic. Allen Schrott Though surface arias word a far centuries or Backed Valery = Gergiev. Centers Variety Education Gifts am Leisure a Hobbies Beverage Garden = Fashion a Style Beauty Pets a Animals Parenting Automotive Cycle of Hand = Heating. ------=_NextPart_001_000B_01C6F2BE.DEB093E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Both dsl a obligation protect original = or Once=20 imposed merger agreements lastmile choose carry att ed or Whitacre or = explained=20 net block gone of.
Both dsl a obligation protect original or Once = imposed=20 merger agreements lastmile choose carry att ed or Whitacre or explained = net=20 block gone of.
3D"wants"
Clockadd or Kickin Pooli = snuck or ces=20 awhile rays pool am audiobook Vegas of story of casinos = downloaded.
Sender id=20 acquire Metasolv am sues Amazon rising solar Amds is cto messed Itanium = is=20 traveling of gets anything tame am flames journalism oon Yeoh Jeordan or = Legon=20 Product Manager am Yahoo recently gave talk stands of.
Donna Fisher = Ivan r=20 Misner Starting Barry Moltz Futures Bobbie or Stevens Selling Vito a = Anthony=20 Parinello Fusion Branding Wreden Futurist Solution of Bosworth Voluntary = tip.
Isc funded dire is effects given weird there ec website letter = states=20 locked printed forbid agency being a printed Note is legal Acrobat = version=20 password did fundraiser a.
Tagframe tagurl tagmsg tagname tagbtn a = Jobstuff=20 designed vertical pixel focused seo apply Conne Rctx¨Kñ€=ùHÌEúHOû øùÈ£ùøɪùÊ'Ä Rctx¨Kñ€ Rctx¨Kñ€ Rctx¨Kñ€FSfmˆ¥²ùñ¯ù@°ùëå€Ø4ÃA¬d Rctx¨Kñ€ ø°ùxg®ù(`¦ù  °”¦ùBR>Centers=20 Variety Education Gifts am Leisure a Hobbies Beverage Garden Fashion a = Style=20 Beauty Pets a Animals Parenting Automotive Cycle of Hand=20 Heating.
------=_NextPart_001_000B_01C6F2BE.DEB093E0-- ------=_NextPart_000_000A_01C6F2BE.DEB093E0 Content-Type: image/gif; name="Clearswift.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6f2ae$1b27c3e0$4ab11253@grazka> R0lGODlhtAEoAYcJAAwAAIgEAAVzAIGNAAAHgn8AegR6hbTIzrTnvKrE4UESDlYbAHYqCJ8kALMe A+cZAABGARI0Cz1EAF1DA3w6DqM+BbFNAOFCAABkACtdB05fAGBqAIVRAJZRBsJVAOxUAAB2ACiG ADWOAV+BDHJ7B5uAAL55ANJ5AAClByetADapAWiuAIuUCq6aALihAO2gAAy1CCqzCEi1AFjBAHbN AKWxAMS6ANG7AAbjABTYB03SAGbpAozYBqvsAMPSANfVAAAAQhgHNUYLO1kAOooERJECNbQITecB MwwsQiYsP0MuP2wtTnsYOqEtOcgYPtwuRgQ0SiFITDFNP203O4o0OJ4/OL06PNdKSwBrOR9ePTVi OWdoTYFhAJxtPbpdPdVcMwGLORJ9Ojl7NVlzSneON5V1R7eLSOiETAmbRyekPzeZPVOcR3+SMZKa SLumM9KuNAG6Thi/Tk7HSWjBQYPHSKDCQLXNM9XFRgDkOiXaPDfaQ1fjRXToPKTrRcXgO9vtPwAA ghMAhDkHg1UAi3YBfKcAg7UKgtMAdAAVeyIofjwucmEYfXEqdpUhg8oniekqgQA5dhc3dDc2jVhH eIlNgqxKdLs2gNoxgwBcexVceUlti2BtdotYgKNqcrRXe+FtfAiNgx5xikd9jWh8eo2GeJt5crdx iNd+iQGkiyeVh0KjjFqcdnahh6CbdsKqg+aReQC3eizFcUjHcla9fHLGgK7Kcr+4eOfCfwPshyra hUffjWrXi4fpgpPfh7nUht/ijgAAvx0LtDoBxVwExXEGzaYAtr4MwtcAtAAgsxkqyD0XwVgbunQe taIpzrUVxOUtzQE2syo5yztJxmM+w3M0wKE2zsg/wtFItABVuB5SuUpawFRnvXxss6ZquLZazupV yQB8zht4tDV4zVuOt3GMxZN/y8h2y+KIsgCjtCuUzUCVvmuluIGgv6iezb6buueXwgDLzSe2vjTF zWuzuIy5waa3vfn27pSfmYh/i/gEBgD6APD/AAAA8/MA+QD///vx/yH5BABC1D0ALAAAAAC0ASgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECOqiEixosWLGDNq3Mixo0eG/0KKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mnz38efQIMKHUr0YpaiSA9WSco0aM+nUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzVS+hXUu2qdu3cOPKnUu3rt27eAfe2Mv3Rt6/HvMBlutnsOHDQ/vuRcy4sePHkA9fiky5 suXLmDNr3sy5s+fPoEOL/su2tOmrBE6rXh119EMAsAG4nk279kHWU2PrBoC7t+/fq21j1C28uPHI wJMrX868ucnj0KNL32zOnvPr2LNrHzu9u/fviLeL/x9Pvrz58+jTq9cJvr37929vwn+/vr7Z+e7t 6xfLMQB+zfsF6JV/BBFoTwAIGmigQAT6t+CBByaIoEESMiihgxdGWGBBCUaYYYEVetjhhyIOFKKI E26oYokMckhhhytCqCKMAtYY00YKmjijixA+6KBCC/7II4gxtlikjjo+KGOMDSKp5JA5OjmkkVQK WeWVl7XwH2RRKmkllVg+ieSRXi5Z5pFgfgnmkklKCaSbG/o4ZZwrnrmlReHcSeeaPc7Z5Ztzstli lEWKGaSggpb550JWKuonQmqqyaeelFJ0qIty1mnhiSbCeCGGFTaJaKYveprhqRSyiKKhZCZaKqGk dv9a6awXXbrnmG1OCumoqQ7aK65M8tqqqIgeZGuuwPJI6Jpi0vqdfGmmGquvuhorrKZ26npotrwu yuiwgc7IqasD2WhuSx3FCqu1y/7aZ6BBcssqssle6i2guK47ZaRoOjsftKPC2Gmz8Y7L4qerspni wP1+iPCTJ25LIrwCbwqpp/tOee7GKfnr8cfdAQzybByXXNLIKKdc0W7h2aTyUCYLuJtuzN0l2L8x l0wzVxrdPJDP+QQNdEE+E02Q0PYEfbRAggnttEFPJ+1001NLvfTRRQONNNNTN2000kr//PPWSb9s 9ltDM3110WVD3bbaVov99txXq8023XHDPfbadev/TffNgGftN+BnF96QfGnf7XXfYgtedtpGH6S4 21/L3fjlkQ8eOeFD3w13zul5gJ7dlmNeuultL4736nhPXrnfj6Ou+emEx0665AKBrrtvpU/Otutv 11575lBv3bXUTwu/+e19Z3186nCrbnzuu1dvVUeOL/075cHrrTrjCH0Pe/fbkw783OUP73X6hrdf VPayKx419MyDj/v53v99+fnw09+5/qxznwB7RjzI4U95e+NeAVunwLD1bngAhB0CuTa7AVrwI/Jz INc8tz2wYQ134TNe1Y7nvAJqTYMVtJvSSrjBsHnugplhBl5EBkOKWO+GU6mhDncIMxz68IdYUQQQ /4dIxCIa8YhITCLHmKDEJraFh1CMohSnSMUqGiQBdtmGFXXoxC568YtgNI0fwogVZxlji2hMoxrX yEYMtpGHZIyjHKvyxjra8Y54zKMe97iZOfrxjzvho8eKIMhCGvJjgEwkWfrhFQyU5pCQjKQkpyBJ uijykpjMpCY3CZNKehI+nAylKEdJylKa8pR+PA5KNLLKTxaHhgfRhitniRjZ0DKNH3hILruzS3vY 8iLQIg5dYEOQX26klRhp5QeW2Ut7MLOXzXTmMweyTIJUk5rWZCY2t0nNal5TILl8JjQLsstpSlOc 54SmN9GZToQ005zg5KZF4CnOb8Izm9dkpzOtef9Ocprzndv8B29oshFj1oWYAzFoZQC6z21Gk6Hf lCY2xxnPhlqUnxKdKEYfelGGVtSi5TSIRzHaUW5GMyIjvahKyclPiJpUpC2VZzMV+hGaCoSmwiRO bG7qS4T21Jay2akvE1qQoBL1pzfdqVB/+kubFuWkKw0nS2Ma0nFStKEhPUhVNRrTrmqVpBQ9KVTB CtNphtOe2twnR6f60ZVi9atdTWlJs0pSpxZFocY0Kk956lODBrWpQ90rUQFbzMAaVq97tetQoCpW lXJUqmrlKkjjOda3WpWlj02IR8MKU4Vc1aHdlKxaG8vWknaWsZh1bGcp61aoGiAiN8FrYQk71Lz/ FtWwgUXsUYF6W9rq1qDIBOZJ1AlZr7Y1sludbDvBWdm3Wja1G02rTKWLVXbe86VT/WxxI7tamZIU rv18LGm/e1Z3WsdlCLGFQ2Q72KPWtrBMxS1v2fve+PqWqT6NS2ahK0/u5vOjWb2seSe7Xe7217QV dalnV0ta7abTm+D17oG/a2DWrÈ Gla1¯€ŠØþÀiá°iá˜çá€ Ä ˆ Ágá˜ûgሃPáP±gáùhá A€''''@@K@þÿÿÿ@þÿÿÿS@@c@@€Ž;â Ÿ°ÿÿÿÿÿÿÿÿÿÿÿÿ rs2e9MpnKI3b5whXuc5n7vONDPwwN 5ytYnSNdt+e9cmZQ0nSoNzzoNB959W5b36Pzdefl8jVmuC70rs/852Jfd0ZEjPMQo73s03k52Dnu 9ZBH3TV7rruJi87yP0Mn4U5/ON85rvi/C2fgjoc3LA3/EYwjR+29jvt4Is/5znu+MpPP/Mle6WtZ DsX0dkG95ldS8sBT/mWoH0jsC6KN2su+9rOXvUBmn/uExB73qLe97gny+2pP3L3C1bptWon72/fe Hrwnfix3T/uGNJ/6uje99g1S/KyvHvMra7L/0Vm+VMhPR5bolz731z989UO/+ugX/vSxT/3tv7/6 7m/28XN+doq33PKisUrph3+0B3z0d3/uF33y93zBJ33b13vR9302kQYpYVtWh3zABX4kw2vy1375 N4AHSH8KmH8JqH7Cp30NKH0SGBUsY3fF1IJpp3y1gUwdiIAfaIO5l4LZR4Lt130OiH0RuIJPcXN+ pRAAGBo0iIPzV388qINM6IElCIX2Z3+690cVsBUlZxAX+Gctpyfp54P3V3xgeIApOIY9SIJTiBDP 5x6c0Bn792R5Vn4iRxLGwXwLaIAIiIfQd33st3t3yIfEh4d6SIZOaHpCGBIzEEiVp4GukYRC/7GG NpgUhniIdGhIkLgRa3iJP6GJtESJnkgen1cQGhCKyfeJphgT8HCKcbQBpghtu0CKlqSKsrgTnzCL trgcRnAVsPhtRmAETXGLwEgTvRiMxLgWw4iFu9hsvTgQpxAfxfiMJXGM0DiNYJGLYZGM2Ahb6JWN hpFJ3PiNhwFsGiGOGRVhSEGO5FgXPzZjHZGOVXQT+rRgN/YT4qhh7BgUQnZg7sgU67iP5vhmijaH 4iZXDPZUDWGP/pgR+TiPg9GP46hZpjZV3qiQXvVQ2iRplcZYo6ZoofZP1GVWlLZcPFZdaIVqjnWR lPZiYrWRJamR+TRqXBWPo0VcLslcllZj9v8oSQD1WQAmYMe1kz6pWjLGVqaWUme2k3EFXkU5Y0Ap WhfWVo/2aNnklJrFkMXFaJdRAp8Bj/TUWnHWX0hJlW7mlVBZZDhZlkg5Vg5WYF/JZk85V1RFYWHJ kDrmTxJma5j0kKCFkKd2XfUEl2ApZwU5UTJ5lg9WautUlWjJXN0VlTL5lFFZZEDZkTDpTmVGl3Bk Ey7Fl6LVXYsZmEM5km1WVv7lmaMJYMYFmYC5Y59pYXLZYkSJmVKlYBOJEZu1Y3MplG4JUqpJlqvp m2uZlIO5m26Wm285lxCmTlwmmaEZlwQZSfEIalIZassFUZ2GYRMmUdZ5k6iZkd5ZZ6GVltz/GWOe Np6fxpGzaZMniZ4uqZwi1ZLZ6UoJCY4LMZ+fZJ/0qZj5uZ+agQn8+Z8AGqCjQY0Eeo0C+o3k4Qq+ gQ0Fqh4HiqANGqFa8aAUWqEWeqHMJqEauqEc2qEeGjMYekvtIBQfWqImeqIomqJQIQkq2qIuIQks 2hr/yQHPBqMhSoo2eqM6KpAuqhNe8Iw76nkRSgQxkwtkFKRImqSV1KNMeoRKKnnbmDJN6hxP+qD8 cKX8IBBYeqUDkaVdag9YWhBc+qVbyqVeqqUEcaZomqZgWqZs2qVb+qVpaqZqmqVlqqZVmhfyUadg +qZn+qcGMaZoiqd9KqdraqiDihB2iqhe/0qojcqnhEoQU9ocGhGpeLqohXqoZLqpgZqomYqofRqp oQqqmOqnmVqqb5qnd3ETliqmo5qqnPqqrvqqjuqqolqql/qpa4qrurqmk1ojf2qmtlqrs9qobRqn hYqpjnqnxxqmp6qpsiqnxhqqbiqpvxoguZqtukqso9qqgMqtnjqryWqrnfqsqGoQ14qt5Mqm0wqt 5tqrWhqsB6GtgYqs9GqqiSqqPJquwVGp7IqvzyqubQqv2zqv6wqr0dqu0jqn8KqvquqMNRGvYVqt n2qngqqpdIqsBVuuZOqm2aqxHiuscNqsY+ql/AocD/tvoecxJ/sbKfuyMIuk+XVBrmZ+3f9hUzbr HTAYcFroegmRsxTHalqIEFHGMkUYtFC2XhZItEmLfD/7tFALEUBbUEtFdkMrtU77eEJrtTx3tQfV tL3ltUp2tArRb/llVziFtEU1s2rbf41Rs0yLtasapXLrZIR3cmSbW4WHt3lWW0qVcn7bVD5LfjOb th1Wd1lLuEBVtW47fkqFVAAHuWL7t2zrYSoXuI0baFQHuXuLuDyXU5qbc5uruHoLuEKFFrm2tlw4 tmA7Yn+1W7PVhTrXVyAWt2k7tIdLW1kLu6uLdiUWu7zbtnC4u407eO21ha/btcmru362tBZovGSH vIDGU6i7MjqFgaw7uUsGX0tbdcd7d07/1YVIy7xke7jci73n+17dW2VcC7Z522fi+1u5Nb9UhrPb 277bu75Jx76uC2JQERfly73Mq7mLe73Ba7lPJr90t3KAK7beO76f27MNjF8B/LtX93qVy4UD/MD6 a3Sl+7grx8AK7MAUHLgg7LZ9i8Ly+xkBjL63C8EHPGXeO8JOS1gvLMLvu7/ZS79dO8P9K2LhG7fp K8ET/MP9Z75Tpr+UJ1sdJsM8TMOvhxc228K9e8OrC8S+m8D3O71waMV5y8Sti3O6+8UWDGhYLMT4 K741vMUIfMW4i3TKy7VlbMQcfMELvIgRO8VyTLgviL8pXHWF98DqK8BYR2iFa8Do68f4/xW6ScXI /ue4/dvIDAxlOnW27wvFbczIgrvJWBe+pPvBBKzBfeW48et9imhBU8vC/5HKSEi37uGzxgHL4MHK c1G9MQsZG3PLMovGkVHIP5HKfkXLciHMzObJgsbLioxrC5HDKBwUigXLHhx+rZfBUVzNAqe41GzI 5Ve1jDtA9tu2aPsWzKzDNVW2yyy8dyW84Zy6cBy1dMy/QoEFN5tyjAvGx8u2X4y5gfbG3Xy0oJvE XbzNo9zNu9u5lWy6+lzAFMFeB13A8zXQm8u0OYvJvixAarzES0a+cszFl8zR7TvCAO3DdqzO5hzN zyvJSWd+9gy/wKvCXCzRspy0HbzIOP8TsQecuGzc0RcctCuMw8f8vQhswTN9x+gs1G581MTrzs2M uBTdwxhscTntv0r0xxA80zwNvo7s0lftvJlr1COd1Dj1uC23vt3repSbxs2Lvc+LyD2LzKqL1P27 HoDQMXN30xht1Wv81ax7x0XI1UGNd3rdw0RIv2QtfkmNzIU8xmwcxevMy0ONztKxfxdteFLW05Qd woWN1Vtt2JctyO9cxHk9yDycyaLt1Gh80Yr92CR8xjDs0rbVRNpMyT8t1oObU8cMxPVcu3n9z6Fd tJw8yZMdh7cNyBNc1gTNEIFHeJp8t5M9M46MVy3I3CK8r0N0J8Ss1BbdQ+bizURx3db/3d3erct5 lM3dYQbiLRrhfd7qvd7+1rLubRJq8d5TKgJlIQXyLd/ocN9SEQf63d/+/d9Pwd7GBòPK   ÿSbH¸„£t”ÚN×KqЙJBÚ“£t|tÀ¢L}t9°…|t8„~tpQKø‹mÿÿÿÿäWKz%ÛÅ)`_Kš£tÐW× ÿÿÿÿÐZ×ÿÿÿÿY Z×DZKÛÛRK0|file:///C:/Program%20Files/Gadu-Gadu/skins/modern/mes_ico1.gif€`RKd; Thu, 26 Oct 2006 05:03:34 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 668444A45C5 for ; Thu, 26 Oct 2006 05:02:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3832B430DE5 for ; Thu, 26 Oct 2006 05:02:50 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 5 days 03:15:41 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id 35363430DE0 for ; Thu, 26 Oct 2006 05:02:47 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1445717; Thu, 26 Oct 2006 08:02:47 -0400 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB0@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB0@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <803EA1B2-E512-4850-B132-780B0257B9D1@thingmagic.com> From: Margaret Wasserman Date: Thu, 26 Oct 2006 08:00:41 -0400 To: Pat Calhoun ((pacalhou)) X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi Pat, On Oct 26, 2006, at 6:44 AM, Pat Calhoun ((pacalhou)) wrote: > ok... no real objections on including an interim (short) tag to > represent the packet type. If we are to go down this path, I would > prefer that we maintain consistency across both the control and data > plane, and include the same header on both UDP ports. This way, if a > DTLS session is being used to secure the data plane, the (relatively) > same pre-parsing and security validation logic can be used. That works for me, too The main reason I had not suggested including the tag on both control and data packets was that I was concerned about lowering the MTU of the link for little benefit. Is there some reason why that isn't a concern? Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 08:13:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd46L-0004KA-6H for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:12:49 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3xb-0008KL-Qd for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:03:50 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A8E523980BA for ; Thu, 26 Oct 2006 05:03:46 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 819B24A45C5 for ; Thu, 26 Oct 2006 05:02:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6491339802F for ; Thu, 26 Oct 2006 05:02:47 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [206.18.177.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9809939804C for ; Thu, 26 Oct 2006 05:02:43 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (alnrmhc11) with ESMTP id <20061026120238b1100fjn4ue>; Thu, 26 Oct 2006 12:02:42 +0000 Message-ID: <4540A3DD.5090106@hyperthought.com> Date: Thu, 26 Oct 2006 05:02:37 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Pat Calhoun (pacalhou)" References: <4FF84B0BC277FF45AA27FE969DD956A268088A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A268088A@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Margaret Wasserman , "Scott G. Kelly" , capwap , Abhijit Choudhury Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 I think what Abhijit suggested can be accomplished without exposing the session id itself. The functionality we're after is really a (QoS) tunnel id, so we know what dtls session to use for the given source. One solution is to plumb an ACL and rely on the source port, but this value could also be included in the type header: +------------+------------+------------+------------+ | version | tunnel id | type | +------------+------------+------------+------------+ It could be less than 8 bits - this is merely illustrative. This is equivalent to the 'channel id' I suggested concatenating with the sessionID earlier, but this approach exposes it and uses it for dtls session selection (and the sessionID would still be in the protected portion, and used to bind control/data channels). The source port can also be used, but with multiple WTPs going through a NAT, the approach above doesn't chew up (potentially) 8+ ports per WTP in the NAT's binding table (and fwiw, there's no corresponding chance of being 'bumped' from the binding table on a heavily loaded NAT). Pat Calhoun (pacalhou) wrote: > Could you explain why you believe the sessionID should not be protected? > Seems like the IP address and UDP port are sufficient to distinguish the > WTP (for encrypted data plane, this would be known after the first > packet is received. > > PatC > > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Wednesday, October 25, 2006 11:59 PM Pacific Standard Time > To: Puneet Agarwal; Margaret Wasserman; Pat Calhoun (pacalhou); > Scott G. Kelly > Cc: capwap > Subject: RE: [Capwap] need clarification on UDP ports > > Folks, > I like the solution below, but I'd go one step further. > We should just have a single CAPWAP packet format. > The shim header should be present in both capwap > control and data packets, and should have a > field to indicate encrypted/unencrypted as well > as a type/sessionId field. > > For packets arriving on either control or data port, > the encrypted/unencrypted field indicates whether > the payload is DTLS encrypted. > > For DTLS encrypted packets arriving on the data port, > the type/sessionId field indicates the QoS level in > order to avoid antireplay issues. > > This approach is simple, clean and addresses all the > concerns raised so far on this issue: > > 1. Uses separate control and data UDP ports to steer packets > through legacy devices with different levels of QoS > 2. Is able to distinguish between encrypted and unencrypted packets > in the CAPWAP payload. > 3. Is able to support multiple QoS levels if the data channel is > DTLS encrypted. > > I believe this is similar to the proposal that Scott > presented in one of his earlier emails. > > Regards, > Abhijit > ________________________________ > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Wed 10/25/2006 11:17 PM > To: Margaret Wasserman; Pat Calhoun > Cc: Hasan Raza; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > > Hi Margaret, > > I am OK with your 2 port solution (with shim header for capwap control > only). > > To summarize, it seems that you are proposing that there be two UDP > ports reserved for CAPWAP: > > A) CAPWAP Control Port: All discovery and capwap control messages flow > on this UDP port. There is a new shim (control mux) header added between > the UDP Header and the following header (where the following header > could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The control > mux would specify if the packet is DTLS encrypted or not. I didn't want > to use the "Control Header" for the new shim as section 4 already talks > about a "Control Header". > > B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. It > is a property of the UDP tunnel whether the payload in encrypted or not. > If the tunnel is encrypted, then a DTLS header follows the UDP Header. > If the tunnel is not encrypted, then a CAPWAP Header follows the UDP > Header. Note that there is no "control mux" after the UDP header. > > Is the above interpretation correct? > > Thanks. > > -Puneet > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Wednesday, October 25, 2006 10:09 AM > To: Pat Calhoun > Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi all, > > Just commenting as an individual contributor... > > I prefer the intermediate header approach to the third port approach, > because I think it is a cleaner representation of what is actually > happening. > > Different ports are used to reach different end points (different > systems or different processes running on the same system). In CAPWAP, > we have one port to reach the data end-point and another to reach the > control end-point, because we think there are cases when the data and > control end-points may be different processes or run on different > systems. That makes sense to me. > > However, when we are talking about DTLS-encrypted and unencrypted > control packets, we aren't really talking about two different end- > points. We are talking about a single control application that needs to > decide whether to treat each packet it received as unencrypted or as > DTLS-encrypted, in which case it needs to be handed to the DTLS engine > for decryption. If you think about it that way, I think it would be > better for the control application to receive a packet that starts with > a short header that indicates whether this packet is DTLS- encrypted or > unencrypted. If the packet is unencrypted, the control application > processes it directly (or ignores the packet if it isn't a discovery > packet), and if it is DTLS-encrypted, the control application strips off > the header and send the packet to the DTLS engine for decryption. This > type of header might also allow for later expansion if the security > world evolves and a better security mechanism for CAPWAP's purposes > emerges. > > So, I would prefer that we add a short header after the UDP header (a > CAPWAP control header?) that indicates the type of the encapsulated > packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long > enough for this header, and that would maintain 32-bit alignment. IMO, > it should contain 2 fields -- a one byte version number (0x01) and a > three-byte type field. At this point, only two types would be defined. > > I do not have a major technical objection to the third port option, I > just think it is less clean from an architectural standpoint. > > I would rather strenuously object to the proposed approaches that > involve zeroing out the DTLS header or running a packet through DTLS and > then treating it as unencrypted if that fails, etc. > > Margaret > > > On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > > > Not pushing for the hack. I've stated I do not object to a third UDP > > port, but provided an alternative should IANA refuse to give it to us. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > >> Sent: Tuesday, October 24, 2006 1:24 PM > >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com > >> Cc: capwap > >> Subject: RE: [Capwap] need clarification on UDP ports > >> > >> "Pat Calhoun (pacalhou)" wrote: > >> > >>> Except we can document that any CAPWAP implementation receiving a > >>> packet with 'n' zeroes uses DTLS header format foo, which > >> is of lengh 'y'. > >> > >> ...except that it is decidedly *not* a DTLS header, right? > >> I'm having a really hard time understanding why you're > >> pushing for a hack at any/all costs to solve this problem. We > >> are at the design stage - if there were ever a time to do it > >> right, that time is now. Exactly what will break if we don't > >> adopt this hack? > >> > >> Scott > >> > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 08:13:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd46h-0004sW-Q6 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:13:11 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd3tS-0007gN-3I for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 07:59:32 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 39F9839807C for ; Thu, 26 Oct 2006 04:59:29 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 4FC714A45C5 for ; Thu, 26 Oct 2006 04:59:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1C93839800B for ; Thu, 26 Oct 2006 04:59:16 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 5 days 03:12:05 ago Received: from thingmagic.com (unknown [204.9.221.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id E5D8C398025 for ; Thu, 26 Oct 2006 04:59:12 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1445701; Thu, 26 Oct 2006 07:59:11 -0400 In-Reply-To: <8954613CA6BB3242A1531D916A527A4102235483@NT-SJCA-0751.brcm.ad.broadcom.com> References: <8954613CA6BB3242A1531D916A527A4102235483@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <24E2ABF7-066A-43A5-8557-3FC4B425835B@thingmagic.com> From: Margaret Wasserman Date: Thu, 26 Oct 2006 07:57:04 -0400 To: Puneet Agarwal X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.05 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Puneet, > To summarize, it seems that you are proposing that there be two UDP > ports reserved for CAPWAP: > > A) CAPWAP Control Port: All discovery and capwap control messages flow > on this UDP port. There is a new shim (control mux) header added > between > the UDP Header and the following header (where the following header > could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The > control > mux would specify if the packet is DTLS encrypted or not. I didn't > want > to use the "Control Header" for the new shim as section 4 already > talks > about a "Control Header". > > B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP > port. It > is a property of the UDP tunnel whether the payload in encrypted or > not. > If the tunnel is encrypted, then a DTLS header follows the UDP Header. > If the tunnel is not encrypted, then a CAPWAP Header follows the UDP > Header. Note that there is no "control mux" after the UDP header. > > Is the above interpretation correct? Yes, this interpretation is correct. And, I agree with you that we shouldn't call the new header a "control header", as that would be ambiguous. Thanks, Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 08:13:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd462-0004F6-0T for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:12:30 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd41M-0000Wk-4a for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 08:07:42 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8080239802F for ; Thu, 26 Oct 2006 05:07:39 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 65A124A45C5 for ; Thu, 26 Oct 2006 05:03:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 48773430DE0 for ; Thu, 26 Oct 2006 05:03:36 -0700 (PDT) Received: from alnrmhc14.comcast.net (alnrmhc14.comcast.net [204.127.225.94]) by hermes.tigertech.net (Postfix) with ESMTP id 529A9430DE5 for ; Thu, 26 Oct 2006 05:03:32 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (alnrmhc14) with ESMTP id <20061026120331b1400cufc4e>; Thu, 26 Oct 2006 12:03:32 +0000 Message-ID: <4540A413.6020906@hyperthought.com> Date: Thu, 26 Oct 2006 05:03:31 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Smitha Smitha (ssmitha)" References: <6499201801FBC6419ED8C910302F67AC01FF8CCC@xmb-blr-417.apac.cisco.com> In-Reply-To: <6499201801FBC6419ED8C910302F67AC01FF8CCC@xmb-blr-417.apac.cisco.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 If you add this state, you must also add a WaitDTLS timer. Smitha Smitha (ssmitha) wrote: > One correction to the transitions. > > Discovery to "DTLS Establishment": > > WTP: Occurs when WTP sends DTLSStart command after figuring out which AC > to join. > AC: Nop > > "DTLS Establishment" to Join: > WTP: Occurs when DTLSSessionEstablished command is received from DTLS. > WTP sends a Join Request and starts the WaitJoin timer. > AC: Nop > > Idle to "DTLS Establishment" > WTP: Nop > AC:Occurs when DTLSSessionEstablished command is received from DTLS. > AC allocates state for this WTP and starts the WaitJoin timer. > > Thanks > Smitha > > -----Original Message----- > From: Smitha Smitha (ssmitha) > Sent: Thursday, October 26, 2006 4:53 PM > To: Pat Calhoun (pacalhou); 'capwap' > Subject: RE: [Capwap] transition to join state > > Pat, > > I think we should have this additional state and have the following > transitions on the AC and WTP. > > Discovery to "DTLS Establishment": > > WTP: Occurs when WTP sends DTLSStart command after figuring out which AC > to join. > AC: Nop > > "DTLS Establishment" to Join: > WTP: Occurs when DTLSSessionEstablished command is received from DTLS. > WTP sends a Join Request and starts the WaitJoin timer. > AC:Occurs when DTLSSessionEstablished command is received from DTLS. > AC allocates state for this WTP and starts the WaitJoin timer. > > Thanks > Smitha > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Thursday, October 26, 2006 4:14 PM > To: Smitha Smitha (ssmitha); 'capwap' > Subject: RE: [Capwap] transition to join state > > I see your point. Clearly, some interim CAPWAP state is needed between > idle and join, which we could call "DTLS Establishment". > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Smitha Smitha (ssmitha) >> Sent: Tuesday, October 24, 2006 6:37 PM >> To: Pat Calhoun (pacalhou); 'capwap' >> Subject: RE: [Capwap] transition to join state >> >> Pat, >> >> The spec talks about transitioning to join state from idle - (Idle to >> Join (aa)). This would make it necessary for CAPWAP to know of the >> various DTLS packets are being received during handshake. Why is it >> necessary to have a "join ready" state? >> >> Thanks >> Smitha >> >> -----Original Message----- >> From: Pat Calhoun (pacalhou) >> Sent: Tuesday, October 24, 2006 9:26 PM >> To: Smitha Smitha (ssmitha); 'capwap' >> Subject: RE: [Capwap] transition to join state >> >> I'm not so sure. If that were the case we would need a "join ready" >> state. We clearly need to transition to a new >> (non-DTLS) state when the DTLS channel is open. >> >> PatC >> >> -----Original Message----- >> From: Smitha Smitha (ssmitha) >> Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time >> To: capwap >> Subject: [Capwap] transition to join state >> >> All, >> >> The spec talks about AC transitioning to Join state on receiving DTLS >> Client Hello with a valid cookie. Should this really be the case? >> The AC should transition to Join state on receiving a Join Request. >> >> Thanks >> Smitha >> >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 09:22:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Bd-0001aN-HW for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 09:22:21 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Ba-0008MA-16 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 09:22:21 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 5DD4D430FB9 for ; Thu, 26 Oct 2006 06:22:14 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 999914A45C5 for ; Thu, 26 Oct 2006 06:21:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8500A398078 for ; Thu, 26 Oct 2006 06:21:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6EDA3398071 for ; Thu, 26 Oct 2006 06:21:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2006 06:21:56 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QDLujc010906; Thu, 26 Oct 2006 06:21:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9QDLtW4000368; Thu, 26 Oct 2006 06:21:55 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 06:21:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 06:21:54 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BAC5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb49tN/9UzFO0P8QEGXmTdft/WqiAACsORg From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" X-OriginalArrivalTime: 26 Oct 2006 13:21:55.0764 (UTC) FILETIME=[B53DAF40:01C6F901] Authentication-Results: sj-dkim-3.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Hasan Raza , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I doubt 1 byte (or 4 if we want alignment) will make that much of a difference over the network. I think consistency of packet formats across both planes will simplify product development, but more importantly, troubleshooting. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, October 26, 2006 5:01 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G. Kelly; Hasan Raza; pagarwal@broadcom.com; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi Pat, > > On Oct 26, 2006, at 6:44 AM, Pat Calhoun ((pacalhou)) wrote: > > ok... no real objections on including an interim (short) tag to > > represent the packet type. If we are to go down this path, I would > > prefer that we maintain consistency across both the control > and data > > plane, and include the same header on both UDP ports. This > way, if a > > DTLS session is being used to secure the data plane, the > (relatively) > > same pre-parsing and security validation logic can be used. > > That works for me, too > > The main reason I had not suggested including the tag on both > control and data packets was that I was concerned about > lowering the MTU of the link for little benefit. Is there > some reason why that isn't a concern? > > Margaret > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 09:32:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Lf-0007vr-41 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 09:32:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Lc-0002HR-Lu for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 09:32:43 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 2B323430F52 for ; Thu, 26 Oct 2006 06:32:37 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 85E584A45C5 for ; Thu, 26 Oct 2006 06:32:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6228839805A for ; Thu, 26 Oct 2006 06:32:16 -0700 (PDT) X-Greylist-Status: Sender first seen 4 days 19:57:17 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id E303D398034 for ; Thu, 26 Oct 2006 06:32:12 -0700 (PDT) Received: from 192.168.10.82 ([192.168.10.82]) by sinett-sbs.SiNett.LAN ([10.10.20.10]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Oct 2006 13:32:12 +0000 Received: from hasan-sinettdev by 10.10.20.10; 26 Oct 2006 19:03:00 +0530 From: Hasan Raza To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB0@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B8BAB0@xmb-sjc-235.amer.cisco.com> Organization: SiNett Semiconductors India Pvt. Ltd. Date: Thu, 26 Oct 2006 19:02:58 +0530 Message-Id: <1161869579.29460.94.camel@hasan-sinettdev> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hasan@sinett.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Thu, 2006-10-26 at 03:44 -0700, Pat Calhoun (pacalhou) wrote: > ok... no real objections on including an interim (short) tag to > represent the packet type. If we are to go down this path, I would > prefer that we maintain consistency across both the control and data > plane, and include the same header on both UDP ports. This way, if a > DTLS session is being used to secure the data plane, the (relatively) > same pre-parsing and security validation logic can be used. Usually data plane is implemented in hardware and control plane in software. Though a bit tricky, but bump in the stack is easier to implement in software than hardware. Changing fast path logic in hardware just for capwap packets may not be worth an effort if the extra type header field does not serve any purpose. Since it is more or less decided that DTLS is enabled or disabled on data plane is just based on a binary configuration at AC, there does not seem to be any purpose of extra type header field for data packets. May be we should look into issue #221. Hasan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 10:06:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5rv-0005EV-03 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:06:03 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5rr-0000ep-Fz for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:06:02 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B688D43106E for ; Thu, 26 Oct 2006 07:05:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id EE9BC4A4547 for ; Thu, 26 Oct 2006 07:05:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D097A398078 for ; Thu, 26 Oct 2006 07:05:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D3AF39807E for ; Thu, 26 Oct 2006 07:05:31 -0700 (PDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 07:05:31 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QE5Vao008703; Thu, 26 Oct 2006 07:05:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QE5RbF005110; Thu, 26 Oct 2006 07:05:27 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 07:05:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 07:05:24 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BADD@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb5AybT2aYQw7h2TYq+YvKVg0/zKAABIm2Q From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 26 Oct 2006 14:05:27.0165 (UTC) FILETIME=[C9C1DAD0:01C6F907] Authentication-Results: sj-dkim-5.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Have you considered that some hardware may be providing an interface to hardware DTLS logic prior to forking off to data or control plane processing? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Hasan Raza [mailto:hasan@sinett.com] > Sent: Thursday, October 26, 2006 6:33 AM > To: Pat Calhoun (pacalhou) > Cc: Margaret Wasserman; Scott G. Kelly; pagarwal@broadcom.com; capwap > Subject: RE: [Capwap] need clarification on UDP ports > > On Thu, 2006-10-26 at 03:44 -0700, Pat Calhoun (pacalhou) wrote: > > ok... no real objections on including an interim (short) tag to > > represent the packet type. If we are to go down this path, I would > > prefer that we maintain consistency across both the control > and data > > plane, and include the same header on both UDP ports. This > way, if a > > DTLS session is being used to secure the data plane, the > (relatively) > > same pre-parsing and security validation logic can be used. > Usually data plane is implemented in hardware and control > plane in software. Though a bit tricky, but bump in the stack > is easier to implement in software than hardware. Changing > fast path logic in hardware just for capwap packets may not > be worth an effort if the extra type header field does not > serve any purpose. Since it is more or less decided that DTLS > is enabled or disabled on data plane is just based on a > binary configuration at AC, there does not seem to be any > purpose of extra type header field for data packets. May be > we should look into issue #221. > > Hasan > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 10:37:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6M1-0000cj-H8 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:37:09 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Ly-0005U4-1H for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:37:09 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 06F873980B5 for ; Thu, 26 Oct 2006 07:37:05 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id DAD664A4547 for ; Thu, 26 Oct 2006 07:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A9EB839807B for ; Thu, 26 Oct 2006 07:36:48 -0700 (PDT) X-Greylist-Status: Sender first seen 4 days 21:01:47 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id AAF2639808F for ; Thu, 26 Oct 2006 07:36:40 -0700 (PDT) Received: from 192.168.10.82 ([192.168.10.82]) by sinett-sbs.SiNett.LAN ([10.10.20.10]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Oct 2006 14:36:39 +0000 Received: from hasan-sinettdev by 10.10.20.10; 26 Oct 2006 20:07:27 +0530 From: Hasan Raza To: "Pat Calhoun (pacalhou)" In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B8BADD@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B8BADD@xmb-sjc-235.amer.cisco.com> Organization: SiNett Semiconductors India Pvt. Ltd. Date: Thu, 26 Oct 2006 20:07:27 +0530 Message-Id: <1161873447.29460.108.camel@hasan-sinettdev> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.074 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, RCVD_BY_IP X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hasan@sinett.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 In that case, the capwap control port would be different from capwap data port in a manner as any other non-capwap udp port which may need DTLS processing. The type header stripping logic would be anyway implemented on the port basis as an special case for capwap port(s). So why this special case should be there for two ports if the second port does not require it? Hasan On Thu, 2006-10-26 at 07:05 -0700, Pat Calhoun (pacalhou) wrote: > Have you considered that some hardware may be providing an interface to > hardware DTLS logic prior to forking off to data or control plane > processing? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: Hasan Raza [mailto:hasan@sinett.com] > > Sent: Thursday, October 26, 2006 6:33 AM > > To: Pat Calhoun (pacalhou) > > Cc: Margaret Wasserman; Scott G. Kelly; pagarwal@broadcom.com; capwap > > Subject: RE: [Capwap] need clarification on UDP ports > > > > On Thu, 2006-10-26 at 03:44 -0700, Pat Calhoun (pacalhou) wrote: > > > ok... no real objections on including an interim (short) tag to > > > represent the packet type. If we are to go down this path, I would > > > prefer that we maintain consistency across both the control > > and data > > > plane, and include the same header on both UDP ports. This > > way, if a > > > DTLS session is being used to secure the data plane, the > > (relatively) > > > same pre-parsing and security validation logic can be used. > > Usually data plane is implemented in hardware and control > > plane in software. Though a bit tricky, but bump in the stack > > is easier to implement in software than hardware. Changing > > fast path logic in hardware just for capwap packets may not > > be worth an effort if the extra type header field does not > > serve any purpose. Since it is more or less decided that DTLS > > is enabled or disabled on data plane is just based on a > > binary configuration at AC, there does not seem to be any > > purpose of extra type header field for data packets. May be > > we should look into issue #221. > > > > Hasan > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 10:51:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6a2-0006UR-LG for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:51:38 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6Zu-0008Mi-VO for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 10:51:38 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 82E723980BC for ; Thu, 26 Oct 2006 07:51:30 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 0AA7A4A4547 for ; Thu, 26 Oct 2006 07:50:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id AC9D739802F for ; Thu, 26 Oct 2006 07:50:55 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [204.127.225.91]) by zoidberg.tigertech.net (Postfix) with ESMTP id C5F9C39808C for ; Thu, 26 Oct 2006 07:50:49 -0700 (PDT) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (alnrmhc11) with ESMTP id <20061026145048b1100fj7ake>; Thu, 26 Oct 2006 14:50:48 +0000 Message-ID: <4540CB47.2080509@hyperthought.com> Date: Thu, 26 Oct 2006 07:50:47 -0700 From: Scott G Kelly User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: hasan@sinett.com References: <4FF84B0BC277FF45AA27FE969DD956A202B8BADD@xmb-sjc-235.amer.cisco.com> <1161873447.29460.108.camel@hasan-sinettdev> In-Reply-To: <1161873447.29460.108.camel@hasan-sinettdev> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 But I think the assumption that encryption on the data port is binary on/off is a little premature. I think that for any given WTP, it will be binary, but that for a given deployment, some WTPs could require data channel encryption while others do not. Hasan Raza wrote: > In that case, the capwap control port would be different from capwap > data port in a manner as any other non-capwap udp port which may need > DTLS processing. The type header stripping logic would be anyway > implemented on the port basis as an special case for capwap port(s). So > why this special case should be there for two ports if the second port > does not require it? > > Hasan > > On Thu, 2006-10-26 at 07:05 -0700, Pat Calhoun (pacalhou) wrote: >> Have you considered that some hardware may be providing an interface to >> hardware DTLS logic prior to forking off to data or control plane >> processing? >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> >> >> >>> -----Original Message----- >>> From: Hasan Raza [mailto:hasan@sinett.com] >>> Sent: Thursday, October 26, 2006 6:33 AM >>> To: Pat Calhoun (pacalhou) >>> Cc: Margaret Wasserman; Scott G. Kelly; pagarwal@broadcom.com; capwap >>> Subject: RE: [Capwap] need clarification on UDP ports >>> >>> On Thu, 2006-10-26 at 03:44 -0700, Pat Calhoun (pacalhou) wrote: >>>> ok... no real objections on including an interim (short) tag to >>>> represent the packet type. If we are to go down this path, I would >>>> prefer that we maintain consistency across both the control >>> and data >>>> plane, and include the same header on both UDP ports. This >>> way, if a >>>> DTLS session is being used to secure the data plane, the >>> (relatively) >>>> same pre-parsing and security validation logic can be used. >>> Usually data plane is implemented in hardware and control >>> plane in software. Though a bit tricky, but bump in the stack >>> is easier to implement in software than hardware. Changing >>> fast path logic in hardware just for capwap packets may not >>> be worth an effort if the extra type header field does not >>> serve any purpose. Since it is more or less decided that DTLS >>> is enabled or disabled on data plane is just based on a >>> binary configuration at AC, there does not seem to be any >>> purpose of extra type header field for data packets. May be >>> we should look into issue #221. >>> >>> Hasan >>> > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 12:51:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8S6-0000n7-Nl for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 12:51:34 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8S1-0006VD-7D for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 12:51:34 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 27B8E3980E5 for ; Thu, 26 Oct 2006 09:51:20 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 4CE6C4A45C5 for ; Thu, 26 Oct 2006 09:50:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33021431339 for ; Thu, 26 Oct 2006 09:50:58 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 5 days 08:03:47 ago Received: from thingmagic.com (unknown [204.9.221.19]) by hermes.tigertech.net (Postfix) with ESMTP id A8661431305 for ; Thu, 26 Oct 2006 09:50:53 -0700 (PDT) Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1446872; Thu, 26 Oct 2006 12:50:50 -0400 In-Reply-To: <4540CB47.2080509@hyperthought.com> References: <4FF84B0BC277FF45AA27FE969DD956A202B8BADD@xmb-sjc-235.amer.cisco.com> <1161873447.29460.108.camel@hasan-sinettdev> <4540CB47.2080509@hyperthought.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <873D483F-9A44-426D-836D-DC1A01C309E1@thingmagic.com> From: Margaret Wasserman Date: Thu, 26 Oct 2006 12:48:44 -0400 To: Scott G Kelly X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi Scott, On Oct 26, 2006, at 10:50 AM, Scott G Kelly wrote: > But I think the assumption that encryption on the data port is binary > on/off is a little premature. I think that for any given WTP, it > will be > binary, but that for a given deployment, some WTPs could require data > channel encryption while others do not. Good point. I'm now convinced (by this note and Pat's) that it would be best to include a short header on both the data and control channels to indicate whether the packet is a DTLS packet or an unencrypted packet. Margaret _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 12:54:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8VG-0006dH-8b for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 12:54:50 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8VD-0006yU-JL for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 12:54:50 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3A03B3980E0 for ; Thu, 26 Oct 2006 09:54:47 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 3D56A4A45C5 for ; Thu, 26 Oct 2006 09:54:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0CB8D39807C for ; Thu, 26 Oct 2006 09:54:27 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by zoidberg.tigertech.net (Postfix) with ESMTP id F09E539800F for ; Thu, 26 Oct 2006 09:54:23 -0700 (PDT) Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gd8Up-0000gH-AF; Thu, 26 Oct 2006 12:54:23 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 26 Oct 2006 12:54:23 -0400 Message-ID: <26367192.1161881663273.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Thu, 26 Oct 2006 09:54:23 -0700 (GMT-07:00) From: "Scott G. Kelly" To: ssmitha@cisco.com, capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7109f4d2f4d46f468d90597d4dea3e64c35350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f One other issue with this: > -----Original Message----- > From: Smitha Smitha (ssmitha) [mailto:ssmitha@cisco.com] > Sent: Thursday, October 26, 2006 4:34 AM > To: Pat Calhoun (pacalhou); capwap > Subject: Re: [Capwap] transition to join state > > One correction to the transitions. > > Discovery to "DTLS Establishment": > > WTP: Occurs when WTP sends DTLSStart command after figuring > out which AC > to join. > AC: Nop > > "DTLS Establishment" to Join: > WTP: Occurs when DTLSSessionEstablished command is received > from DTLS. > WTP sends a Join Request and starts the WaitJoin timer. > AC: Nop > > Idle to "DTLS Establishment" > WTP: Nop > AC:Occurs when DTLSSessionEstablished command is received from DTLS. > AC allocates state for this WTP and starts the WaitJoin timer. The AC needs to transition when it receives a DTLS ClientHello (with cookie) and set a timer (WaitDTLS). --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 13:06:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8gG-0002dQ-OA for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:06:12 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8gD-0000MC-5G for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:06:12 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A34A7398111 for ; Thu, 26 Oct 2006 10:06:08 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id C81D04A45C5 for ; Thu, 26 Oct 2006 10:05:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B53293980F1 for ; Thu, 26 Oct 2006 10:05:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id E2A1C39803D for ; Thu, 26 Oct 2006 10:05:05 -0700 (PDT) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2006 10:05:05 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QH55vq001127; Thu, 26 Oct 2006 10:05:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9QH4LOh008912; Thu, 26 Oct 2006 10:05:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 10:05:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 10:05:03 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BBA5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb49sNbiyG1DcCNQ2mBxSi4YnSpMgAKhsCw From: "Pat Calhoun (pacalhou)" To: "Scott G Kelly" , "Smitha Smitha (ssmitha)" X-OriginalArrivalTime: 26 Oct 2006 17:05:03.0375 (UTC) FILETIME=[E0E101F0:01C6F920] Authentication-Results: sj-dkim-6.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Issue 226 created. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Scott G Kelly [mailto:scott@hyperthought.com] > Sent: Thursday, October 26, 2006 5:04 AM > To: Smitha Smitha (ssmitha) > Cc: Pat Calhoun (pacalhou); capwap > Subject: Re: [Capwap] transition to join state > > If you add this state, you must also add a WaitDTLS timer. > > Smitha Smitha (ssmitha) wrote: > > One correction to the transitions. > > > > Discovery to "DTLS Establishment": > > > > WTP: Occurs when WTP sends DTLSStart command after figuring > out which > > AC to join. > > AC: Nop > > > > "DTLS Establishment" to Join: > > WTP: Occurs when DTLSSessionEstablished command is received > from DTLS. > > WTP sends a Join Request and starts the WaitJoin timer. > > AC: Nop > > > > Idle to "DTLS Establishment" > > WTP: Nop > > AC:Occurs when DTLSSessionEstablished command is received > from DTLS. > > AC allocates state for this WTP and starts the WaitJoin timer. > > > > Thanks > > Smitha > > > > -----Original Message----- > > From: Smitha Smitha (ssmitha) > > Sent: Thursday, October 26, 2006 4:53 PM > > To: Pat Calhoun (pacalhou); 'capwap' > > Subject: RE: [Capwap] transition to join state > > > > Pat, > > > > I think we should have this additional state and have the following > > transitions on the AC and WTP. > > > > Discovery to "DTLS Establishment": > > > > WTP: Occurs when WTP sends DTLSStart command after figuring > out which > > AC to join. > > AC: Nop > > > > "DTLS Establishment" to Join: > > WTP: Occurs when DTLSSessionEstablished command is received > from DTLS. > > WTP sends a Join Request and starts the WaitJoin timer. > > AC:Occurs when DTLSSessionEstablished command is received > from DTLS. > > AC allocates state for this WTP and starts the WaitJoin timer. > > > > Thanks > > Smitha > > -----Original Message----- > > From: Pat Calhoun (pacalhou) > > Sent: Thursday, October 26, 2006 4:14 PM > > To: Smitha Smitha (ssmitha); 'capwap' > > Subject: RE: [Capwap] transition to join state > > > > I see your point. Clearly, some interim CAPWAP state is > needed between > > idle and join, which we could call "DTLS Establishment". > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Smitha Smitha (ssmitha) > >> Sent: Tuesday, October 24, 2006 6:37 PM > >> To: Pat Calhoun (pacalhou); 'capwap' > >> Subject: RE: [Capwap] transition to join state > >> > >> Pat, > >> > >> The spec talks about transitioning to join state from idle > - (Idle to > >> Join (aa)). This would make it necessary for CAPWAP to know of the > >> various DTLS packets are being received during handshake. > Why is it > >> necessary to have a "join ready" state? > >> > >> Thanks > >> Smitha > >> > >> -----Original Message----- > >> From: Pat Calhoun (pacalhou) > >> Sent: Tuesday, October 24, 2006 9:26 PM > >> To: Smitha Smitha (ssmitha); 'capwap' > >> Subject: RE: [Capwap] transition to join state > >> > >> I'm not so sure. If that were the case we would need a > "join ready" > >> state. We clearly need to transition to a new > >> (non-DTLS) state when the DTLS channel is open. > >> > >> PatC > >> > >> -----Original Message----- > >> From: Smitha Smitha (ssmitha) > >> Sent: Tuesday, October 24, 2006 08:52 AM Pacific Standard Time > >> To: capwap > >> Subject: [Capwap] transition to join state > >> > >> All, > >> > >> The spec talks about AC transitioning to Join state on > receiving DTLS > >> Client Hello with a valid cookie. Should this really be the case? > >> The AC should transition to Join state on receiving a Join Request. > >> > >> Thanks > >> Smitha > >> > >> > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 13:10:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8kB-0003Sf-VO for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:10:15 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8k0-00013S-1Z for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:10:15 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 9F94C3980D1 for ; Thu, 26 Oct 2006 10:10:03 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 237384A45C5 for ; Thu, 26 Oct 2006 10:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id EBDC23980EA for ; Thu, 26 Oct 2006 10:02:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id 3D6163980E1 for ; Thu, 26 Oct 2006 10:02:36 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2006 19:02:31 +0200 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QH2UZf017039; Thu, 26 Oct 2006 19:02:31 +0200 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9QH2RB1001158; Thu, 26 Oct 2006 17:02:28 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 22:32:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 22:32:21 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC01FF8D1E@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb5H2YlASWqCGR5QxmNk6LItQtmlwAAMe9Q From: "Smitha Smitha (ssmitha)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 26 Oct 2006 17:02:27.0356 (UTC) FILETIME=[83E265C0:01C6F920] Authentication-Results: ams-dkim-2; header.From=ssmitha@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.372 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Scott, The idea was to isolate details of DTLS handshake from CAPWAP. If we need to keep track of DTLS Client Hello (with a valid cookie), then the earlier transitions were OK. Why do we need a CAPWAP transition based on DTLS packets (unless a session is established) and a WaitDTLS timer that CAPWAP needs to maintain? That would be part of DTLS. Thanks Smitha -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] Sent: Thursday, October 26, 2006 10:24 PM To: Smitha Smitha (ssmitha); capwap Subject: RE: [Capwap] transition to join state One other issue with this: > -----Original Message----- > From: Smitha Smitha (ssmitha) [mailto:ssmitha@cisco.com] > Sent: Thursday, October 26, 2006 4:34 AM > To: Pat Calhoun (pacalhou); capwap > Subject: Re: [Capwap] transition to join state > > One correction to the transitions. > > Discovery to "DTLS Establishment": > > WTP: Occurs when WTP sends DTLSStart command after figuring out which > AC to join. > AC: Nop > > "DTLS Establishment" to Join: > WTP: Occurs when DTLSSessionEstablished command is received from DTLS. > WTP sends a Join Request and starts the WaitJoin timer. > AC: Nop > > Idle to "DTLS Establishment" > WTP: Nop > AC:Occurs when DTLSSessionEstablished command is received from DTLS. > AC allocates state for this WTP and starts the WaitJoin timer. The AC needs to transition when it receives a DTLS ClientHello (with cookie) and set a timer (WaitDTLS). --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 13:12:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8mk-0005Ku-0F for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:12:54 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8mf-0001Ws-H7 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:12:53 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id DCBA13980B3 for ; Thu, 26 Oct 2006 10:12:48 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 60C254A45FE for ; Thu, 26 Oct 2006 10:07:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4A2AF43138F for ; Thu, 26 Oct 2006 10:07:08 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 28C77431387 for ; Thu, 26 Oct 2006 10:07:04 -0700 (PDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2006 10:07:03 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9QH73qf015434; Thu, 26 Oct 2006 10:07:03 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QH73bF000842; Thu, 26 Oct 2006 10:07:03 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 Oct 2006 10:07:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 10:07:04 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A202B8BBA9@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb5Hwg2D57HV5S/RG2ZUH8bdF/AjQAAh0Gg From: "Pat Calhoun (pacalhou)" To: "Margaret Wasserman" , "Scott G Kelly" X-OriginalArrivalTime: 26 Oct 2006 17:07:03.0139 (UTC) FILETIME=[28438B30:01C6F921] Authentication-Results: sj-dkim-7.cisco.com; header.From=pcalhoun@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.4 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Issue 227 created. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, October 26, 2006 9:49 AM > To: Scott G Kelly > Cc: capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi Scott, > > On Oct 26, 2006, at 10:50 AM, Scott G Kelly wrote: > > But I think the assumption that encryption on the data port > is binary > > on/off is a little premature. I think that for any given > WTP, it will > > be binary, but that for a given deployment, some WTPs could require > > data channel encryption while others do not. > > Good point. I'm now convinced (by this note and Pat's) that > it would be best to include a short header on both the data > and control channels to indicate whether the packet is a DTLS > packet or an unencrypted packet. > > Margaret > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 13:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8ns-00083j-88 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:14:04 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8np-0001mZ-Tv for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:14:04 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A69B73980AA for ; Thu, 26 Oct 2006 10:14:00 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id CCCA74A45C5 for ; Thu, 26 Oct 2006 10:07:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A61C1398136 for ; Thu, 26 Oct 2006 10:07:16 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 9 days 05:13:09 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5388B3980A9 for ; Thu, 26 Oct 2006 10:07:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 10:07:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb49qXJ2T3couwfSYe+0tazWf2ZIwAKUv8X References: <4FF84B0BC277FF45AA27FE969DD956A268088A@xmb-sjc-235.amer.cisco.com> <4540A3DD.5090106@hyperthought.com> From: "Abhijit Choudhury" To: "Scott G Kelly" , "Pat Calhoun (pacalhou)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.107 tagged_above=-999 required=7 tests=FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: Margaret Wasserman , capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963283677==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a This is a multi-part message in MIME format. --===============0963283677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F921.28E6BB53" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F921.28E6BB53 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, That's exactly what I had in mind. Thanks for clarifying my point. The tunnelId is sufficient to pull out the correct information for anti-replay checking. =20 Seems like we are then reaching a consensus that both control and data channels will have the same format with a 4-byte header between the UDP header and the DTLS or CAPWAP header. I think we should make it a 4-byte header since all the headers so far (UDP, CAPWAP etc.) are nicely 4-byte aligned. As Pat pointed out, the overhead is minimal in the grand scheme of things. =20 Regards, Abhijit ________________________________ From: Scott G Kelly [mailto:scott@hyperthought.com] Sent: Thu 10/26/2006 5:02 AM To: Pat Calhoun (pacalhou) Cc: Abhijit Choudhury; Puneet Agarwal; Margaret Wasserman; Scott G. = Kelly; capwap Subject: Re: [Capwap] need clarification on UDP ports I think what Abhijit suggested can be accomplished without exposing the session id itself. The functionality we're after is really a (QoS) tunnel id, so we know what dtls session to use for the given source. One solution is to plumb an ACL and rely on the source port, but this value could also be included in the type header: +------------+------------+------------+------------+ | version | tunnel id | type | +------------+------------+------------+------------+ It could be less than 8 bits - this is merely illustrative. This is equivalent to the 'channel id' I suggested concatenating with the sessionID earlier, but this approach exposes it and uses it for dtls session selection (and the sessionID would still be in the protected portion, and used to bind control/data channels). The source port can also be used, but with multiple WTPs going through a NAT, the approach above doesn't chew up (potentially) 8+ ports per WTP in the NAT's binding table (and fwiw, there's no corresponding chance of being 'bumped' from the binding table on a heavily loaded NAT). Pat Calhoun (pacalhou) wrote: > Could you explain why you believe the sessionID should not be = protected? > Seems like the IP address and UDP port are sufficient to distinguish = the > WTP (for encrypted data plane, this would be known after the first > packet is received. > > PatC > > -----Original Message----- > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > Sent: Wednesday, October 25, 2006 11:59 PM Pacific Standard Time > To: Puneet Agarwal; Margaret Wasserman; Pat Calhoun (pacalhou); > Scott G. Kelly > Cc: capwap > Subject: RE: [Capwap] need clarification on UDP ports > > Folks, > I like the solution below, but I'd go one step further. > We should just have a single CAPWAP packet format. > The shim header should be present in both capwap > control and data packets, and should have a > field to indicate encrypted/unencrypted as well > as a type/sessionId field. > > For packets arriving on either control or data port, > the encrypted/unencrypted field indicates whether > the payload is DTLS encrypted. > > For DTLS encrypted packets arriving on the data port, > the type/sessionId field indicates the QoS level in > order to avoid antireplay issues. > > This approach is simple, clean and addresses all the > concerns raised so far on this issue: > > 1. Uses separate control and data UDP ports to steer packets > through legacy devices with different levels of QoS > 2. Is able to distinguish between encrypted and unencrypted packets > in the CAPWAP payload. > 3. Is able to support multiple QoS levels if the data channel is > DTLS encrypted. > > I believe this is similar to the proposal that Scott > presented in one of his earlier emails. > > Regards, > Abhijit > ________________________________ > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Wed 10/25/2006 11:17 PM > To: Margaret Wasserman; Pat Calhoun > Cc: Hasan Raza; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > > Hi Margaret, > > I am OK with your 2 port solution (with shim header for capwap control > only). > > To summarize, it seems that you are proposing that there be two UDP > ports reserved for CAPWAP: > > A) CAPWAP Control Port: All discovery and capwap control messages flow > on this UDP port. There is a new shim (control mux) header added = between > the UDP Header and the following header (where the following header > could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The = control > mux would specify if the packet is DTLS encrypted or not. I didn't = want > to use the "Control Header" for the new shim as section 4 already = talks > about a "Control Header". > > B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. = It > is a property of the UDP tunnel whether the payload in encrypted or = not. > If the tunnel is encrypted, then a DTLS header follows the UDP Header. > If the tunnel is not encrypted, then a CAPWAP Header follows the UDP > Header. Note that there is no "control mux" after the UDP header. > > Is the above interpretation correct? > > Thanks. > > -Puneet > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Wednesday, October 25, 2006 10:09 AM > To: Pat Calhoun > Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi all, > > Just commenting as an individual contributor... > > I prefer the intermediate header approach to the third port approach, > because I think it is a cleaner representation of what is actually > happening. > > Different ports are used to reach different end points (different > systems or different processes running on the same system). In = CAPWAP, > we have one port to reach the data end-point and another to reach the > control end-point, because we think there are cases when the data and > control end-points may be different processes or run on different > systems. That makes sense to me. > > However, when we are talking about DTLS-encrypted and unencrypted > control packets, we aren't really talking about two different end- > points. We are talking about a single control application that needs = to > decide whether to treat each packet it received as unencrypted or as > DTLS-encrypted, in which case it needs to be handed to the DTLS engine > for decryption. If you think about it that way, I think it would be > better for the control application to receive a packet that starts = with > a short header that indicates whether this packet is DTLS- encrypted = or > unencrypted. If the packet is unencrypted, the control application > processes it directly (or ignores the packet if it isn't a discovery > packet), and if it is DTLS-encrypted, the control application strips = off > the header and send the packet to the DTLS engine for decryption. = This > type of header might also allow for later expansion if the security > world evolves and a better security mechanism for CAPWAP's purposes > emerges. > > So, I would prefer that we add a short header after the UDP header (a > CAPWAP control header?) that indicates the type of the encapsulated > packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long > enough for this header, and that would maintain 32-bit alignment. = IMO, > it should contain 2 fields -- a one byte version number (0x01) and a > three-byte type field. At this point, only two types would be = defined. > > I do not have a major technical objection to the third port option, I > just think it is less clean from an architectural standpoint. > > I would rather strenuously object to the proposed approaches that > involve zeroing out the DTLS header or running a packet through DTLS = and > then treating it as unencrypted if that fails, etc. > > Margaret > > > On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > > > Not pushing for the hack. I've stated I do not object to a third = UDP > > port, but provided an alternative should IANA refuse to give it to = us. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > >> -----Original Message----- > >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] > >> Sent: Tuesday, October 24, 2006 1:24 PM > >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com > >> Cc: capwap > >> Subject: RE: [Capwap] need clarification on UDP ports > >> > >> "Pat Calhoun (pacalhou)" wrote: > >> > >>> Except we can document that any CAPWAP implementation receiving a > >>> packet with 'n' zeroes uses DTLS header format foo, which > >> is of lengh 'y'. > >> > >> ...except that it is decidedly *not* a DTLS header, right? > >> I'm having a really hard time understanding why you're > >> pushing for a hack at any/all costs to solve this problem. We > >> are at the design stage - if there were ever a time to do it > >> right, that time is now. Exactly what will break if we don't > >> adopt this hack? > >> > >> Scott > >> > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > > = ------------------------------------------------------------------------ > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6F921.28E6BB53 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] need clarification on UDP ports=0A= =0A= =0A=
=0A=
Scott,
=0A=
That's exactly what I had in =0A= mind.
=0A=
Thanks for clarifying my =0A= point.
=0A=
The tunnelId is sufficient to = pull out the =0A= correct
=0A=
information for anti-replay =0A= checking.
=0A=
 
=0A=
Seems like we are then = reaching a =0A= consensus
=0A=
that both control and data = channels will =0A= have
=0A=
the same format with a 4-byte = header =0A= between
=0A=
the UDP header and the DTLS = or CAPWAP =0A= header.
=0A=
I think we should = make it a 4-byte header since
=0A=
all the headers so far (UDP, = CAPWAP =0A= etc.)
=0A=
are nicely 4-byte = aligned.  As Pat =0A= pointed out,
=0A=
the overhead is minimal  = in the grand =0A= scheme of
=0A=
things.
=0A=
 
=0A=
Regards,
=0A=
Abhijit
=0A=

=0A=
=0A= From: Scott G Kelly =0A= [mailto:scott@hyperthought.com]
Sent: Thu 10/26/2006 5:02 =0A= AM
To: Pat Calhoun (pacalhou)
Cc: Abhijit Choudhury; = Puneet =0A= Agarwal; Margaret Wasserman; Scott G. Kelly; capwap
Subject: = Re: =0A= [Capwap] need clarification on UDP ports

=0A=
=0A=

I think what Abhijit suggested can be accomplished = without =0A= exposing the
session id itself. The functionality we're after is = really a =0A= (QoS)
tunnel id, so we know what dtls session to use for the given = source. =0A= One
solution is to plumb an ACL and rely on the source port, but this =0A= value
could also be included in the type =0A= header:

+------------+------------+------------+------------+
|= =0A= version    | tunnel id  =0A= |          =0A= type           =0A= |
+------------+------------+------------+------------+

It = could be =0A= less than 8 bits - this is merely illustrative. This is
equivalent to = the =0A= 'channel id' I suggested concatenating with the
sessionID earlier, = but this =0A= approach exposes it and uses it for dtls
session selection (and the = sessionID =0A= would still be in the protected
portion, and used to bind = control/data =0A= channels).

The source port can also be used, but with multiple = WTPs going =0A= through a
NAT, the approach above doesn't chew up (potentially) 8+ = ports per =0A= WTP
in the NAT's binding table (and fwiw, there's no corresponding = chance =0A= of
being 'bumped' from the binding table on a heavily loaded =0A= NAT).


Pat Calhoun (pacalhou) wrote:
> Could you explain = why you =0A= believe the sessionID should not be protected?
> Seems like the IP = address =0A= and UDP port are sufficient to distinguish the
> WTP (for = encrypted data =0A= plane, this would be known after the first
> packet is =0A= received.
>
> PatC
>
>  -----Original =0A= Message-----
> From:   Abhijit Choudhury [mailto:Abhijit@sinett.com]
>= =0A= Sent:   Wednesday, October 25, 2006 11:59 PM Pacific Standard =0A= Time
> To:     Puneet Agarwal; Margaret = Wasserman; Pat =0A= Calhoun (pacalhou);
> Scott G. Kelly
> = Cc:     =0A= capwap
> Subject:        RE: = [Capwap] =0A= need clarification on UDP ports
>
> Folks,
> I like = the =0A= solution below, but I'd go one step further.
> We should just have = a =0A= single CAPWAP packet format.
> The shim header should be present = in both =0A= capwap
> control and data packets, and  should have a
> = field =0A= to indicate  encrypted/unencrypted as well
> as a = type/sessionId =0A= field.
>
> For packets arriving  on either control or = data =0A= port,
> the encrypted/unencrypted field indicates whether
> = the =0A= payload is DTLS encrypted.
>
> For DTLS encrypted packets = arriving =0A= on the data port,
> the type/sessionId field  indicates the = QoS level =0A= in
> order to avoid antireplay issues.
>
> This = approach is =0A= simple, clean and addresses all the
> concerns raised so far on = this =0A= issue:
>
> 1.  Uses separate control and data UDP ports = to =0A= steer packets
>       through legacy = devices =0A= with different levels of QoS
> 2.  Is able to distinguish = between =0A= encrypted and unencrypted packets
>      = in the =0A= CAPWAP payload.
> 3.  Is able to support multiple QoS levels = if the =0A= data channel is
>      DTLS =0A= encrypted.
>
> I believe this is similar to the proposal = that =0A= Scott
> presented in one of his earlier emails.
>
> =0A= Regards,
> Abhijit
> =0A= ________________________________
>
> From: Puneet Agarwal = [mailto:pagarwal@broadcom.com]> =0A= Sent: Wed 10/25/2006 11:17 PM
> To: Margaret Wasserman; Pat =0A= Calhoun
> Cc: Hasan Raza; capwap
> Subject: Re: [Capwap] = need =0A= clarification on UDP ports
>
>
>
> Hi =0A= Margaret,
>
> I am OK with your 2 port solution (with shim = header =0A= for capwap control
> only).
>
> To summarize, it seems = that =0A= you are proposing that there be two UDP
> ports reserved for =0A= CAPWAP:
>
> A) CAPWAP Control Port: All discovery and capwap = control =0A= messages flow
> on this UDP port. There is a new shim (control = mux) header =0A= added between
> the UDP Header and the following header (where the =0A= following header
> could be DTLS if encrypted or CAPWAP Hdr if =0A= non-encrypted ). The control
> mux would specify if the packet is = DTLS =0A= encrypted or not. I didn't want
> to use the "Control Header" for = the new =0A= shim as section 4 already talks
> about a "Control =0A= Header".
>
> B) CAPWAP Data Port: All CAPWAP Data messages = flow on =0A= this UDP port. It
> is a property of the UDP tunnel whether the = payload in =0A= encrypted or not.
> If the tunnel is encrypted, then a DTLS header = follows =0A= the UDP Header.
> If the tunnel is not encrypted, then a CAPWAP = Header =0A= follows the UDP
> Header. Note that there is no "control mux" = after the =0A= UDP header.
>
> Is the above interpretation = correct?
>
> =0A= Thanks.
>
> -Puneet
>
> -----Original =0A= Message-----
> From: Margaret Wasserman [mailto:margaret@thingmagic.com]
> =0A= Sent: Wednesday, October 25, 2006 10:09 AM
> To: Pat = Calhoun
> Cc: =0A= Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap
> Subject: Re: = [Capwap] =0A= need clarification on UDP ports
>
>
> Hi = all,
>
> =0A= Just commenting as an individual contributor...
>
> I prefer = the =0A= intermediate header approach to the third port approach,
> because = I think =0A= it is a cleaner representation of what is actually
> =0A= happening.
>
> Different ports are used to reach different = end =0A= points (different
> systems or different processes running on the = same =0A= system).  In CAPWAP,
> we have one port to reach the data = end-point =0A= and another to reach the
> control end-point, because we think = there are =0A= cases when the data and
> control end-points may be different = processes or =0A= run on different
> systems.  That makes sense to = me.
>
> =0A= However, when we are talking about DTLS-encrypted and = unencrypted
> =0A= control packets, we aren't really talking about two different = end-
> =0A= points.  We are talking about a single control application that = needs =0A= to
> decide whether to treat each packet it received as = unencrypted or =0A= as
> DTLS-encrypted, in which case it needs to be handed to the = DTLS =0A= engine
> for decryption.  If you think about it that way, I = think it =0A= would be
> better for the control application to receive a packet = that =0A= starts with
> a short header that indicates whether this packet is = DTLS- =0A= encrypted or
> unencrypted.  If the packet is unencrypted, = the =0A= control application
> processes it directly (or ignores the packet = if it =0A= isn't a discovery
> packet), and if it is DTLS-encrypted, the = control =0A= application strips off
> the header and send the packet to the = DTLS engine =0A= for decryption.  This
> type of header might also allow for = later =0A= expansion if the security
> world evolves and a better security = mechanism =0A= for CAPWAP's purposes
> emerges.
>
> So, I would = prefer that =0A= we add a short header after the UDP header (a
> CAPWAP control = header?) =0A= that indicates the type of the encapsulated
> packet = (DTLS-encrypted or =0A= unencrypted).  I think 4 bytes would be long
> enough for = this =0A= header, and that would maintain 32-bit alignment.  IMO,
> it = should =0A= contain 2 fields -- a one byte version number (0x01) and a
> = three-byte =0A= type field.  At this point, only two types would be =0A= defined.
>
> I do not have a major technical objection to = the third =0A= port option, I
> just think it is less clean from an architectural =0A= standpoint.
>
> I would rather strenuously object to the = proposed =0A= approaches that
> involve zeroing out the DTLS header or running a = packet =0A= through DTLS and
> then treating it as unencrypted if that fails, =0A= etc.
>
> Margaret
>
>
> On Oct 25, 2006, = at 12:33 =0A= PM, Pat Calhoun (pacalhou) wrote:
>
>  > Not pushing = for the =0A= hack. I've stated I do not object to a third UDP
>  > = port, but =0A= provided an alternative should IANA refuse to give it to = us.
>  =0A= >
>  > Pat Calhoun
>  > CTO, Wireless = Networking =0A= Business Unit Cisco Systems
>  >
>  = >
>  =0A= >
>  >> -----Original Message-----
>  = >> =0A= From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]>  =0A= >> Sent: Tuesday, October 24, 2006 1:24 PM
>  >> = To: Pat =0A= Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com
>  = >> Cc: =0A= capwap
>  >> Subject: RE: [Capwap] need clarification = on UDP =0A= ports
>  >>
>  >> "Pat Calhoun = (pacalhou)" =0A= wrote:
>  >>
>  >>> Except we can = document =0A= that any CAPWAP implementation receiving a
>  >>> = packet =0A= with  'n' zeroes uses DTLS header format foo, which
>  = >> =0A= is of lengh 'y'.
>  >>
>  >> ...except = that it =0A= is decidedly *not* a DTLS header, right?
>  >> I'm = having a =0A= really hard time understanding why you're
>  >> pushing = for a =0A= hack at any/all costs to solve this problem. We
>  >> = are at =0A= the design stage - if there were ever a time to do it
>  = >> =0A= right, that time is now. Exactly what will break if we = don't
>  =0A= >> adopt this hack?
>  >>
>  >> =0A= Scott
>  >>
>  > =0A= _________________________________________________________________
>=   =0A= > To unsubscribe or modify your subscription options, please =0A= visit:
>  > http://lists.f= rascone.com/mailman/listinfo/capwap
>  =0A= >
>  > Archives: http://lists.frascone= .com/pipermail/capwap
>
>
>
> =0A= _________________________________________________________________
>= To =0A= unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
> =0A= Archives: http://lists.frascone= .com/pipermail/capwap
>
>
>
> =0A= ------------------------------------------------------------------------<= BR>>
> =0A= _________________________________________________________________
>= To =0A= unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
> =0A= Archives: http://lists.frascone= .com/pipermail/capwap

=0A= =0A= =0A= ------_=_NextPart_001_01C6F921.28E6BB53-- --===============0963283677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0963283677==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 13:29:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd93G-00036r-1K for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:29:58 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd93E-0004CV-I2 for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 13:29:58 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id DD1CB3980D8 for ; Thu, 26 Oct 2006 10:29:55 -0700 (PDT) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 4388E4A45C5 for ; Thu, 26 Oct 2006 10:29:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1E164398092 for ; Thu, 26 Oct 2006 10:29:40 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6A77398050 for ; Thu, 26 Oct 2006 10:29:37 -0700 (PDT) Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gd92v-0006yx-67; Thu, 26 Oct 2006 13:29:37 -0400 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Thu, 26 Oct 2006 13:29:37 -0400 Message-ID: <16527761.1161883777169.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Thu, 26 Oct 2006 10:29:37 -0700 (GMT-07:00) From: "Scott G. Kelly" To: "Smitha Smitha (ssmitha)" , capwap Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7105db1da31d46668d00ffcd3483e06a472350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi Smitha, > >Scott, > >The idea was to isolate details of DTLS handshake from CAPWAP. If we >need to keep track of DTLS Client Hello (with a valid cookie), then the >earlier transitions were OK. > >Why do we need a CAPWAP transition based on DTLS packets (unless a >session is established) and a WaitDTLS timer that CAPWAP needs to >maintain? That would be part of DTLS. You need this because DTLS provides no timeout of its own. It provides an exponential back-off timer, but this never terminates (I know, sounds like a major foobar in the protocol design, but they probably had their reasons...) If we don't add the timer, resource-exhaustion DoS (from a bunch of half-open sessions) is trivial to mount. Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 17:13:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCWp-0004f4-7u for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 17:12:43 -0400 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCSn-0004Tr-3W for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 17:09:07 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 4879A431231 for ; Thu, 26 Oct 2006 14:08:17 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 246A34A4547 for ; Thu, 26 Oct 2006 14:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0742743186E for ; Thu, 26 Oct 2006 14:05:32 -0700 (PDT) Received: from web60312.mail.yahoo.com (web60312.mail.yahoo.com [209.73.178.135]) by hermes.tigertech.net (Postfix) with SMTP id E129843185F for ; Thu, 26 Oct 2006 14:05:27 -0700 (PDT) Received: (qmail 15017 invoked by uid 60001); 26 Oct 2006 21:05:27 -0000 Message-ID: <20061026210527.15015.qmail@web60312.mail.yahoo.com> Received: from [12.129.211.52] by web60312.mail.yahoo.com via HTTP; Thu, 26 Oct 2006 14:05:27 PDT Date: Thu, 26 Oct 2006 14:05:26 -0700 (PDT) From: Behcet Sarikaya To: "Pat Calhoun (pacalhou)" MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_40_50, HTML_MESSAGE X-Spam-Level: ** Cc: capwap Subject: Re: [Capwap] CAPWAP for 802.11r X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0507013768==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 --===============0507013768== Content-Type: multipart/alternative; boundary="0-326421828-1161896726=:14437" --0-326421828-1161896726=:14437 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable I agree with Pat.=0AWe (CAPWAP ML) should be open for discussion on how som= ething very relevant like 802.11r could be integrated with CAPWAP 802.11 bi= nding.=0A=0A--behcet=0A=0A=0A----- Original Message ----=0AFrom: Pat Calhou= n (pacalhou) =0ATo: Dorothy Stanley ; Behcet Sarikaya =0ACc: capwap =0ASent: Thursday, October 26, 2006 5:47:54 AM=0ASubject: Re: [Capwap] CA= PWAP for 802.11r=0A=0A=0AI agree, but that doesn't mean that we should be d= illatory and not fix something in the protocol that is known to be broken i= n supporting an upcoming ammendment. This is not the case with 802.11r, but= just wanted to provide my interpretation of the process..=0A =0APat Calhou= n=0ACTO, Wireless Networking Business Unit=0ACisco Systems=0A =0A=0A=0A=0A= =0AFrom: Dorothy Stanley [mailto:dstanley1389@gmail.com] =0ASent: Thursday,= October 26, 2006 1:02 AM=0ATo: Behcet Sarikaya=0ACc: capwap=0ASubject: Re:= [Capwap] CAPWAP for 802.11r=0A=0A=0AAll,=0A=0AI believe that we previously= agreed that the=0Ainitial CAPWAP specification(s) will support 802.11 capa= bilities through=0Athose defined in 802.11-REVma, expected to be approved = in Dec 06, and that=0Aunapproved amendments including .11k, .11r, .11n etc = would be dealt with=0Ain a future version. =0A=0AThus 802.11r support in C= APWAP, the discussion of which is very interesting,=0Ais not in scope for t= he current CAPWAP specifications under development.=0A=0AThanks,=0A=0ADorot= hy=0A=0A=0AOn 10/25/06, Behcet Sarikaya wrote: = =0AComments inline.=0A=0A=0A----- Original Message ----=0AFrom: Charles Cla= ncy =0ATo: Pat Calhoun (pacalhou) = =0ACc: Behcet Sarikaya < sarikaya@ieee.org>; capwap = =0ASent: Monday, October 23, 2006 11:00:38 AM=0ASubject: Re: [Capwap] CAPWA= P for 802.11r=0A=0A=0AUnless PMK-R1s are preemptively distributed to WTPs t= o which a STA might=0Aroam (neighbor graphs, anyone?), you'll still have th= e WTP-AC latency for =0Athe WTP to request a PMK-R1 from the AC (R0KH). Th= is would be about equal=0Ato the latency of having the AC validating Associ= ation Request packets.=0A=0A=3D=3D>PMK-R1 is sent during Authenticate req/r= esp exchange, so no effect on ReassReq/Resp latency.=0A=0ADoes 11r let you = proactively distribute PMK-R1s? I don't see any=0Areferences in D3... all = I see is the reactive distribution protocol. =0A=3D=3D>I think it is possib= le but the key distribution protocol is more advantageous because you do no= t distribute keys to WTPs that may never need to use such a key.=0A=0A=0AMy= understanding is that one of the reasons 11r is faster is because keys=0Ac= an be *reactively* transfered directly between APs without having to go=0At= hrough the AAA server. Unfortunately our main security association is =0Aw= ith the AC, not the WTP, and inter-WTP communications is bad, so=0Aeverythi= ng will have to go through the AC.=0A=0A=3D=3D>No inter-WTP communications = in CAPWAPRP. =0A=0A=0A-- =0At. charles clancy, ph.d. <> tcc@umd.edu <> = www.cs.umd.edu/~clancy=0A=0AOn Mon, October 23, 2006 10:28 am, Pat Calhoun= \(pacalhou\) wrote:=0A> I agree with Charles - but I do believe there is a= single issue. In the=0A> case of local MAC, the IEEE 802.11 binding states= that the WTP processes=0A> the Association Request and then forwards it to= the AC. The AC can=0A> override the decision made by the WTP by sending a = negative result=0A> Association Response.=0A>=0A> When 802.11r, the local M= AC WTP will not have the cryptographic keys=0A> necessary to validate the A= ssociation Request, so it would *have* to=0A> defer to the AC. The question= is whether this is acceptable as it does =0A> change the timing of the Ass= ociation round trip. One alternative is to=0A> push the PMK-R1 keys to the = WTP to allow the WTP to perform its own=0A> authentication of the managemen= t frame.=0A>=0A> Pat Calhoun =0A> CTO, Wireless Networking Business Unit=0A= > Cisco Systems=0A>=0A>=0A>=0A>> -----Original Message-----=0A>> From: Char= les Clancy [mailto: clancy@cs.umd.edu]=0A>> Sent: Thursday, October 19, 200= 6 12:27 PM=0A>> To: Behcet Sarikaya=0A>> Cc: capwap=0A>> Subject: Re: [Capw= ap] CAPWAP for 802.11r=0A>>=0A>> Behcet,=0A>> =0A>> > My proposal is to use= the key distribution protocol of=0A>> 802.11r which=0A>> > securely transp= orts the keys.=0A>> > Also no need for the context transfer which was what = I had in mind. =0A>>=0A>> My point is that we don't need to distribute PMK-= R1 keys=0A>> since all authenticator functionality will reside at the AC=0A= >> regardless of the MAC splitting, so we therefore don't need a =0A>> new = key distribution protocol at all.=0A>>=0A>> Here's how I envision an 11r ha= ndoff:=0A>>=0A>> STA WTP1 WTP2 AC=0A>> --= ------------------------------------------------=0A>>=0A>> Initial authenti= cation (as CAPWAP does now):=0A>>=0A>> <--- assoc ----->=0A>> <------------= -- open authentication -------------> =0A>> <----------------- 1X/EAP authe= ntication -------->=0A>> (derives PMK-R0, PMK-R1)=0A>> <----= ----------- four-way handshake ------------->=0A>> (deri= ves PTK)=0A>> <---------- add mobile (PTK) -----=0A>>=0A>> = fast handoff:=0A>>=0A>> (AC and STA derive new PMK-R1')=0A>>= <------- FT / reassoc (PMK Name, MIC, etc) ------>=0A>> = (derives new PTK')=0A>> <- add mobile (PTK')= =0A>> <---------- delete mobile --------=0A>>=0A>>=0A>> > C= an you spare your ideas why that would not work in CAPWAP?=0A>>=0A>> I'm no= t sure to what you're referring. Using the=0A>> yet-to-be-defined 11r key = distribution protocol duplicates=0A>> the add-mobile CAPWAP architecture fo= r distributing keying =0A>> material. Additionally, it violates the securi= ty restriction=0A>> that keys from the PMK-level in the keying hierarchy MU= ST=0A>> remain at the authenticator, which is the AC.=0A>>=0A>> > You're sa= ying we only need the split MAC scenarios that I =0A>> have in the=0A>> > d= raft.=0A>>=0A>> I'm saying that CAPWAP can support 11r without any protocol= =0A>> changes. The only changes I can envision being necessary are=0A>> pe= rhaps capabilities flags indicating support for 11r, so ACs =0A>> and WTPs = know that each other supports 11r. All the 11r=0A>> protocol processing wo= uld be implemented at the AC. The WTP=0A>> would just have to know about t= he additional 802.11 messages,=0A>> and know they should be forwarded to th= e AC. WTPs and ACs=0A>> would also have to support AES-CMAC, which is defi= ned in 11r. =0A>>=0A>> --=0A>> t. charles clancy, ph.d. | tcc@umd.edu | = www.cs.umd.edu/~clancy=0A>>=0A>> ________________________________________= _________________________=0A>> To unsubscribe or modify your subscription o= ptions, please visit:=0A>> http://lists.frascone.com/mailman/listinfo/capwa= p=0A>>=0A>> Archives: http://lists.frascone.com/pipermail/capwap =0A>>=0A>= =0A=0A_________________________________________________________________=0AT= o unsubscribe or modify your subscription options, please visit:=0Ahttp://l= ists.frascone.com/mailman/listinfo/capwap=0A=0AArchives: http://lists.frasc= one.com/pipermail/capwap =0A=0A=0A=0A=0A___________________________________= ______________________________=0ATo unsubscribe or modify your subscription= options, please visit:=0Ahttp://lists.frascone.com/mailman/listinfo/capwap= =0A=0AArchives: http://lists.frascone.com/pipermail/capwap =0A=0A=0A=0A=0A_= ________________________________________________________________=0ATo unsub= scribe or modify your subscription options, please visit:=0Ahttp://lists.fr= ascone.com/mailman/listinfo/capwap=0A=0AArchives: http://lists.frascone.com= /pipermail/capwap --0-326421828-1161896726=:14437 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
I agree with Pat.
=0A
We (CAPWAP ML)&n= bsp;should be open for discussion on how something very relevant like 802.1= 1r could be integrated with CAPWAP 802.11 binding.
=0A
 <= /DIV>=0A
--behcet

=0A
----- Original Message = ----
From: Pat Calhoun (pacalhou) <pcalhoun@cisco.com>
To: Doro= thy Stanley <dstanley1389@gmail.com>; Behcet Sarikaya <sarikaya@ie= ee.org>
Cc: capwap <capwap@frascone.com>
Sent: Thursday, Oct= ober 26, 2006 5:47:54 AM
Subject: Re: [Capwap] CAPWAP for 802.11r
=0A
I agree, but that doesn't mean that we should be dillatory and n= ot fix something in the protocol that is known to be broken in supporting a= n upcoming ammendment. This is not the case with 802.11r, but just wanted t= o provide my interpretation of the process..
=0A
&nb= sp;
=0A

Pat Calhoun
CTO, Wireless Net= working Business Unit
Cisco Systems

=0A
 

= =0A
=0A
=0A
=0AFrom: Dorothy Stanley [mailto:dstanley1389@gmail.com] <= BR>Sent: Thursday, October 26, 2006 1:02 AM
To: Behcet Sar= ikaya
Cc: capwap
Subject: Re: [Capwap] CAPWAP for 802.1= 1r

=0A
All,

I believe that we previous= ly agreed that the
initial CAPWAP specification(s) will support 802.11 c= apabilities through
those defined in  802.11-REVma, expected to be = approved in Dec 06, and that
unapproved amendments including .11k, .11r,= .11n etc would be dealt with
in a future version.

Thus  80= 2.11r support in CAPWAP, the discussion of which is very interesting,
is= not in scope for the current CAPWAP specifications under development.
<= BR>Thanks,

Dorothy

=0A
On 10/25= /06, Behcet Sarikaya <behcetsarikaya@yah= oo.com> wrote: =0A
=0A
=0A
=0A
Comments inline.

=0A
----- Original Message ----
From: Charles Clancy <clancy@cs.umd= .edu>
To: Pat Calhoun (pacalhou) <pcalhoun@ci= sco.com>
Cc: Behcet Sarikaya < sarikaya@ieee.org>; capwap <= capwa= p@frascone.com>
Sent: Monday, October 23, 2006 11:00:38 AM
Sub= ject: Re: [Capwap] CAPWAP for 802.11r

=0A
Unless PMK-R1s are preemptively distributed to WTPs to which a STA mightroam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for=
the WTP to request a PMK-R1 from the AC (R0KH).  This would = be about equal
to the latency of having the AC validating Association Re= quest packets.

=3D=3D>PMK-R1 is sent during Authenticate r= eq/resp exchange, so no effect on ReassReq/Resp latency.
Does 11r let you proactively distribute PMK-R1s?  I don't se= e any
references in D3... all I see is the reactive distribution protoco= l.
=3D=3D>I think it is possible but the key distribution pro= tocol is more advantageous because you do not distribute keys to WTPs that = may never need to use such a key.


My understandi= ng is that one of the reasons 11r is faster is because keys
can be *reac= tively* transfered directly between APs without having to go
through the= AAA server.  Unfortunately our main security association is
with= the AC, not the WTP, and inter-WTP communications is bad, so
everything= will have to go through the AC.

=3D=3D>No inter-WTP commu= nications in CAPWAPRP. =0A
<= BR>
--
t. charles clancy, ph.d.  <>  tcc@umd.edu&nb= sp; <>   www.cs.umd.edu/~clancy

On Mon, Oct= ober 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote:
> I agree wit= h Charles - but I do believe there is a single issue. In the
> case o= f local MAC, the IEEE 802.11 binding states that the WTP processes
> = the Association Request and then forwards it to the AC. The AC can
> = override the decision made by the WTP by sending a negative result
> = Association Response.
>
> When 802.11r, the local MAC WTP will = not have the cryptographic keys
> necessary to validate the Associati= on Request, so it would *have* to
> defer to the AC. The question is = whether this is acceptable as it does
> change the timing of the Association round trip. One alternative is to
> pu= sh the PMK-R1 keys to the WTP to allow the WTP to perform its own
> a= uthentication of the management frame.
>
> Pat Calhoun
>= CTO, Wireless Networking Business Unit
> Cisco Systems
>
&g= t;
>
>> -----Original Message-----
>> From: Charles= Clancy [mailto: clancy@cs.umd.edu]
>> Sent: Thursday, October 19, 20= 06 12:27 PM
>> To: Behcet Sarikaya
>> Cc: capwap
>&= gt; Subject: Re: [Capwap] CAPWAP for 802.11r
>>
>> Behcet= ,
>>
>> > My proposal is to use the key distribution = protocol of
>> 802.11r which
>> > securely transports = the keys.
>> > Also no need for the context transfer which was = what I had in mind.
>>
>> My point is that we don't need= to distribute PMK-R1 keys
>> since all authenticator functionality will reside = at the AC
>> regardless of the MAC splitting, so we therefore don'= t need a
>> new key distribution protocol at all.
>>
= >> Here's how I envision an 11r handoff:
>>
>> STA&= nbsp;           WTP1=            WTP2 &nbs= p;            A= C
>> --------------------------------------------------
>>= ;
>> Initial authentication (as CAPWAP does now):
>>
&= gt;> <--- assoc ----->
>> <-------------- open authent= ication ------------->
>> <----------------- 1X/EAP authent= ication -------->
>>       &= nbsp;        (derives PMK-R0, PMK-R1)
>> <--------------- four-way handshake -------------&g= t;
>>          &= nbsp;         (derives PTK)>>           =       <---------- add mobile (PTK) -----
>= ;>
>> fast handoff:
>>
>>   &n= bsp;            = ;(AC and STA derive new PMK-R1')
>> <------- FT / reassoc (PMK = Name, MIC, etc) ------>
>>      &= nbsp;            (de= rives new PTK')
>>        =             &nb= sp;          <- add mobile (PTK')
>>         &n= bsp;       <---------- delete mobile -----= ---
>>
>>
>> > Can you spare your ideas why t= hat would not work in CAPWAP?
>>
>> I'm not sure to what = you're referring.  Using the
>> yet-to-be-defined 11r ke= y distribution protocol duplicates
>> the add-mobile CAPWAP archit= ecture for distributing keying
>> material.  Additional= ly, it violates the security restriction
>> that keys from the PMK= -level in the keying hierarchy MUST
>> remain at the authenticator= , which is the AC.
>>
>> > You're saying we only need = the split MAC scenarios that I
>> have in the
>> > dr= aft.
>>
>> I'm saying that CAPWAP can support 11r without= any protocol
>> changes.  The only changes I can envisi= on being necessary are
>> perhaps capabilities flags indicating support fo= r 11r, so ACs
>> and WTPs know that each other supports 11r. = ; All the 11r
>> protocol processing would be implemented at = the AC.  The WTP
>> would just have to know about the ad= ditional 802.11 messages,
>> and know they should be forwarded to = the AC.  WTPs and ACs
>> would also have to support AES-= CMAC, which is defined in 11r.
>>
>> --
>> t. c= harles clancy, ph.d.  |  tcc@umd.edu  |   ww= w.cs.umd.edu/~clancy
>>
>> __________________________= _______________________________________
>> To unsubscribe or modif= y your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
&g= t;>
>> Archives: http://lists.frascone.com/pipermail= /capwap
>>
>

___________________________________= ______________________________
To unsubscribe or modify your subscriptio= n options, please visit:
http://lists.frascone.com/mai= lman/listinfo/capwap

Archives: http://lists.frascone.= com/pipermail/capwap


_________________________________________________________________
T= o unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap

=0A
__________________________= _______________________________________
To unsubscribe or modify your su= bscription options, please visit:
http://lists.frascone.com/mailman/l= istinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap<= /A>
=0A

--0-326421828-1161896726=:14437-- --===============0507013768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0507013768==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 17:42:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCys-0002l7-My for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 17:41:42 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCvW-0002WL-Vx for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 17:38:16 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 70A52398018 for ; Thu, 26 Oct 2006 14:38:14 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id B65B64A460F for ; Thu, 26 Oct 2006 14:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 84111144801B for ; Thu, 26 Oct 2006 14:37:50 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by hermes.tigertech.net (Postfix) with ESMTP id EC00B1448022 for ; Thu, 26 Oct 2006 14:37:47 -0700 (PDT) Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.2)); Thu, 26 Oct 2006 14:37:38 -0700 X-Server-Uuid: 79DB55DB-3CB4-423E-BEDB-D0F268247E63 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5859C2AF; Thu, 26 Oct 2006 14:37:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 326202AE; Thu, 26 Oct 2006 14:37:38 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EJA21270; Thu, 26 Oct 2006 14:37:31 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 4402020501; Thu, 26 Oct 2006 14:37:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Oct 2006 14:37:30 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A41022355AF@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A202B8BAC5@xmb-sjc-235.amer.cisco.com> Thread-Topic: Dtls and QoS -- [was udp port thread] Thread-Index: Acb49tN/9UzFO0P8QEGXmTdft/WqiAACsORgAAie80A= From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , "Margaret Wasserman" X-WSS-ID: 695FF52838S4899975-01-01 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: Cc: Hasan Raza , capwap Subject: [Capwap] Dtls and QoS -- [was udp port thread] X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Making the control and data ports format consistent is a good thing. I support it for all the reasons listed in earlier emails. Now that we have resolved how to demux encrypt/non-encrypt for capwap control/data plane, I am hoping we can tackle the problem of multiple QoS levels (the problem would be in capwap data and potentially in capwap control plane) - an issue first brought to the groups attention by Scott. The question to be resolved is: Do we need per QoS anti-replay windows in dtls? If we support it, we will need to maintain per QoS dtls session for capwap data? A similar number may be required for capwap control if we want to support multiple QoS for capwap control too. Furthermore, if we want to support per QoS anti-replay windows, it also implies that the capwap QoS would need to be stored in the newly agreed to "mux" shim. This is because the IP DSCP fields are subject to change by the network. If we go down this path, then we will need to define how to setup these dtls sessions etc. Comments? -Puneet -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, October 26, 2006 6:22 AM To: Margaret Wasserman Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap Subject: RE: [Capwap] need clarification on UDP ports I doubt 1 byte (or 4 if we want alignment) will make that much of a difference over the network. I think consistency of packet formats across both planes will simplify product development, but more importantly, troubleshooting. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, October 26, 2006 5:01 AM > To: Pat Calhoun (pacalhou) > Cc: Scott G. Kelly; Hasan Raza; pagarwal@broadcom.com; capwap > Subject: Re: [Capwap] need clarification on UDP ports > > > Hi Pat, > > On Oct 26, 2006, at 6:44 AM, Pat Calhoun ((pacalhou)) wrote: > > ok... no real objections on including an interim (short) tag to > > represent the packet type. If we are to go down this path, I would > > prefer that we maintain consistency across both the control > and data > > plane, and include the same header on both UDP ports. This > way, if a > > DTLS session is being used to secure the data plane, the > (relatively) > > same pre-parsing and security validation logic can be used. > > That works for me, too > > The main reason I had not suggested including the tag on both control > and data packets was that I was concerned about lowering the MTU of > the link for little benefit. Is there some reason why that isn't a > concern? > > Margaret > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From tqehfnat@planetdv.net Thu Oct 26 20:06:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFEp-00039F-UV for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 20:06:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdF0s-0001pg-JB for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 19:51:54 -0400 Received: from gar78-1-82-238-170-100.fbx.proxad.net ([82.238.170.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdF0o-0006fu-Pr for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 19:51:52 -0400 Message-ID: <000701c6f958$c8d442b0$64aaee52@test> From: "between" To: capwap-archive@lists.ietf.org Subject: aspect provided placed another Date: Fri, 27 Oct 2006 01:45:14 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0003_01C6F969.8C5AC8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.5 (++++) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 ------=_NextPart_000_0003_01C6F969.8C5AC8C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C6F969.8C5AC8C0" ------=_NextPart_001_0004_01C6F969.8C5AC8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leave asu including faculty academic classified staff is eligible = policies relative. Leave asu including faculty academic classified staff is eligible = policies relative. Mr Hesseldahl consumers eventually able in anywhere = developing companies Triggering recent is jon quotdvd Jonquot Johansen = started company Ventures whose or bypassing in Apples? Week Year Beginning Mark View of Parent am hot closed Posting Rules edit = vb Smilies img Html am Jump Control in Panel Private a Whos Online = Shoutwire. Works underlinux doesnt of elderly natsemi driver wont or work pci id = appearsto. November October Valid Xhtml is Cssi stupidly Urls Technorati tracks of = metwice or Heres or oneand deprecated or cousinso mild frenzy apparently = bad network card fileserver ran Frys a picked Netgear Fanetwork replace = presumed am. Response delayed a rolling a floor laughter Would consider enhancing a = ah old chestnut note this Basically nature data real in. France in Germany the Spain Italy Finland Belgium States Copyright six a = Apart ltd all in rights reserved is product vox of Movable Type is = About. Bryan Chaffin soon come a lead according Arik column titled or quotapple = Tear is Wallquot mr Hesseldahl or consumers eventually able anywhere = developing or companies a Triggering recent jon of quotdvd! Forcrack has a builtin a dictionary toolcalled in Dawg is Directed = Acyclic Word in Graph which. ------=_NextPart_001_0004_01C6F969.8C5AC8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Leave asu including faculty academic = classified=20 staff is eligible policies relative.
Leave asu including faculty = academic=20 classified staff is eligible policies relative. Mr Hesseldahl consumers=20 eventually able in anywhere developing companies Triggering recent is = jon=20 quotdvd Jonquot Johansen started company Ventures whose or bypassing in=20 Apples?
3D"returning
Week Year Beginning Mark View of Parent = am hot=20 closed Posting Rules edit vb Smilies img Html am Jump Control in Panel = Private a=20 Whos Online Shoutwire.
Works underlinux doesnt of elderly natsemi = driver wont=20 or work pci id appearsto.
November October Valid Xhtml is Cssi = stupidly Urls=20 Technorati tracks of metwice or Heres or oneand deprecated or cousinso = mild=20 frenzy apparently bad network card fileserver ran Frys a picked Netgear=20 Fanetwork replace presumed am.
Response delayed a rolling a floor = laughter=20 Would consider enhancing a ah old chestnut note this Basically nature = data real=20 in.
France in Germany the Spain Italy Finland Belgium States = Copyright six a=20 Apart ltd all in rights reserved is product vox of Movable Type is=20 About.
Bryan Chaffin soon come a lead according Arik column titled or = quotapple Tear is Wallquot mr Hesseldahl or consumers eventually able = anywhere=20 developing or companies a Triggering recent jon of quotdvd!
Forcrack = has a=20 builtin a dictionary toolcalled in Dawg is Directed Acyclic Word in = Graph=20 which.
------=_NextPart_001_0004_01C6F969.8C5AC8C0-- ------=_NextPart_000_0003_01C6F969.8C5AC8C0 Content-Type: image/gif; name="notified.gif" Content-Transfer-Encoding: base64 Content-ID: <000201c6f958$c8d1f8c0$64aaee52@test> R0lGODlh+AEoAYf2AAAABYsHAAxyC4aOCgMAh4YEdw6Hdc6+vbPnwaO+6UIWC2gUCoAiAKoUAMkU B9ckCgBJAB1CCDg5AVFLBoRFAJo4A8g/AOtMCgtkACheDklkAFRgBX5sAKBnAMFVC9loAABxACuM DUSGAl6KCo6LAqiCAM2KANiIAAqVACOlADOeCFesDnicAKOiAMekANmbAAvFAC3LADa0CV/CAIHF Bp7KAL2/AN3OAADqACjnCUHYCWzWDHXtAqHhA87oAdTaAAAHMy4BTjcAMWMAN4YAQJsAQskAM+UD PAodRSsfOEITTVwpSnMmSa0iPMsYTuQnOwBCTBVLPTsyPFM9S4dLNZY4Ors7P+5MPABaOx9RN0Ra Q2RoO4pkA6RmO7NZO9NnTQGDNCB9SjV9RFR6TIt6RZ11QL96Pt90RwCcTC2uNTSqP1aYNoOSQ6ei TcunPOOaTADNShK5SUzBQGm7Mo3BTZyyTse0MdKzQwvdPCTrTDLSS2DfP3PWM6niRrTUOO3uNgQL fCoFcUUJcWAAf30Ae5oAicYAhusAjQMidi4ed04scmUihokpdKcYiMwig+spdAE+hyw2iUlJhFxK iok+iJo/dsVNh9FDewlVjR9rdkxRfWxeioZmea1igsRWdutUeQBzhCCNi0x3ilKNdHOKdqSBg753 gO1xfgCSeymVc0iljlSaenKceZ6be8OnieSYhgqxdhG0gkbOeVTOjYjFhKC8i7jOiNe9hgDaiyzc hUXugl/rdHLbhafagszSjuLhiwAOxhIAx0UAs2cMwIIAspwAub8AsekFwwomxisVzDosuG4ry3ES yZYoyrcpzuAuyANGxiRNtDNNtVU4xHtMyqo7usJBxu02xQlawBpmvjNXvlFSzYhVw6ZhssNputVR zgSAvRWAzEGJxFiJzYGJsqmKu8d1xd+GwACTthSeuUWmvmyovYuVupajuLyszuOfxgDJyhrNvjW+ s1fEx4a3yqC/zP/s7aCaso16h/8AAAD1Bf/zAA4A+fYA8Az0//P7/yH5BACB0QUALAAAAAD4ASgB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNqRAhgo8ePIEOKHEmypMmTKFOqHNlxpcuX Ev/JnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqtQlgqdOnUKNKnUq1qtWrWLNqlQqg6davYInC HEu2rNmzaDO2TMu2rdu3cOPKnVtwLd27ePPq3cu3r9+/gANj9CK4sOHDiBMrXsy4sWN7YSNLnky5 suXLmDMPfcy5s+fPoEOLHk26tErNqFOrXs26tevXsGPLnk27tu3buHPr3s27d1jTwBn6Hk78a/Dj yJMrd7hUY4DlhYtLnz5143OC1+0F2J49u8Drz71r/9fOfbvB8t/Lh1dPHntB7uTZY0cfH778+gPp 1zfvvj/+7++dB59/4/U3IHQIBtZcd/kZGOB44oWnkHcSPjgfgQBi2GCD4hVIIHgbdmghgyFamOGJ FaKoInUstniZhyAGGOGIJx7U4Y3nwZijhjWmuOGPHJY4oZDuzcgjhP7h6OKSTP70UYo4GvljjAjh aCKAJGIooodIXhklkQlBmaOUNRYpo40JpokchWN6GeJ9+Q2o3nroxWglkPPJyd6eYx44Z5Ua+shl evzpGOiWaiYaV3M9thmooQ0JOqiOd5YJpKRkYqkiQ2yeeWSGWZbpXZOklmoTSJ2a+WioC2G6Y5da Av8apJueFojoh47i+SCcg96q6K9tMdprkrrCeiublfaY7JbIvnrppr6KSqylzeKakKnYloqqgIUS GmaeB8bJ35/kXpjnkfKVy22odIZ7aLfxVSmniZkCay9IyFwk7L2eZevvv0LxCxrABEsn8MEIJ6zw wgw37Ne+ZOWDYMEUWwYMxRITlLE9+XS88cYCgayxxh1zDHLGEnusskErm7yyyiWXPJDIMoc8s8c3 w8xxQSnHfHLOHwtU8dBE/xa0zTMjnTTLOy9dc9M/H/SzyE2TPLLVTl+9tNJIoxz110IXLfbYN3l0 NNUp8yx11VBXTTXbWm8tt81HJx002nHT3LXbcM//7fDfhzGaNtd0q8002HXHrXjfeCe+891My613 25CvDRmT3JCtecAfRT3y5FqfvXfkUuPsMs4wD46y4avjLXnqo7eeM+GA166gUpIfbnjoWRdOukKD L1751mm7zvXkqxeOfNibY9ZA873lrjboQIvu++7AM0568EoX/7vnsdsNd/LQl08xSNTXbXz4N1v+ vfbYP822zODPz/rxydNu+/7JoW367L97XMywhj2emQ52CCQg/oD2vs8NsH0ha9nb+EfBu0CsghMx nwY3iBMM6ouDIAyhCEdIwhKa8IQoTKEKV8jCFrrwhTAEmAdnSMM0xXArO7ihDnfIwx76kCYo+KEQ /4dIxCIa8Yi+WcMakMjEJl5GiUp0ohSnqBUoLpGKWDQhX9ZQwy568SNZDKMYeQIOcGzmi2hMI17K CA41uvGNgmEjRsZIRyyy8YJwzCO/8qCXNoKxjoCsCikCSchCZlGPiEwkSbChyEY68pGQjOT+DEnJ Ss5EkpjMpCY3ycm8WFKEXvkkWDpJylLGBHcD6+AHy2ZK0jSplbCMpUHw6JiczFGVaPzAQ3RpGl5e bkkf6UpXzDLMgdjFLx9Ipi/toUxfLpOZzRxIMgkyTWlSU5nWzKY0p1lNgeiymc4sCC+jCU1wltOZ 3DTnORGyTHJ6U5sUcSc4u+nOa1ZTncykZjnFSf/OdsLzL5WISHOOWZZiCoSgFrHlKk/lz3xm85kN 7SY0rRnOdzr0ovqcKEUzClGMNtSiFx2nQT6aUY9q85kRISlGVypOfUb0pCN1KTx5yUGECrMlN7WH MA+qU4PuVKc9xakx6wJUngb1oDv9aVDX0hKFJhQnKGXpN1sqU5GGs6IOFelBrLpRmXp1qyWtKEqj GtaYRvOb9MRmPjtKVZCyNKtg9apKTapVfb5SIwS1S0eYOlSfEtWvfCXIXocq2KIadrCERehJojrW lXZ0qmvtakjfSVa4XrWlj03IR8UaU4Vg9aHblOxaG9tWk3aWsZh1bGcp+9bKUsQIn8lrYQMLVL3/ /rWwtTWIUA3LU9oi1qhjQSdkv+rWyHJ1suv0pmu1elzRZlWtM4Xuc/spXZhS9bPDjexqZ1rSuO7z saTtLlrZKZqlyLavhM1tYpOK29+mF7E59e1SDcq8Uy20JplNbXe1e0+QMte5HN1ofv9pWou+1LOr JS12z8lN73KXwPvNrnFLq1y1Svidd1WLbmf7Xt7+1r1CPW9u+SpfxcJkwM7Nb38Z7F8Dk3eyEo7x djcLWgS3VcHcDe9+C/zWf8q4rlI97XYFdkzblpjDvcUtb9Pb08M6OcmJDW6Aa/zgxg64rqj1aHax CmSScrm4PHYrjcVM1xcXl61lFS2WrRteNH+G/1E5XSpwSRxnOdsWuEpusp07LGejOrUiCsWnPM8q T7Pql7U+bnBo8Vlhe7rZn9icZ4XJ2s7qKtrAFtZsdaWa6W1GutAUXbGOK8pBjJiYIacWyZ8psuoa uhZBNN2gqSmSalXjEtC39uKrleNLUfr618AOIyGCTexiG3sysky2spfN7GY7+9nQjra0+XXsalv7 2tjOtra3ze1ue/vb4A63uMPYhOhN+9xwpGVJWs0XdrN63Ex8ibv1Mu9TwvuIF6n1kuuNF35D5N4k 9EidH6JvfXNGAAgXgEASjvCBKNzh9kj4WKCB7tGYN88NKXhB/E0XWz584REnyMM/TvL6ZlsHWP8U 8V6TWsyVM/Wnu+X4XHLycZEXROEjt/kvAQ7Cjaj8ybUlMZINrpiaQ9zmOL95xVtZZ/h22MhILg3J G250nBs95EuPZYjnjN6uQ1nqSq96yMWedRpCbOtAB7GH953rvtA87HDHOsh3znMh3jntXlcvlJva 9nZ3sOZJP3rJ5z7CLhi+7kbpM9e5ftOXt9zPfd+LQhludYnPHeQSN6HhN7/5bZuE6GVvDOdDHxLQ k/70iVE3rlnZr8jfEvFkQ73sSyOGkKj+3azvjFO14RHY37DxGxao6xeze4Pw3vjaSH7yBaL8418m GL5Hjc8xvj/lD8T6xs/+9Wf/lsZ7f+CCgTr/fGGuVNOThvfoJ8jxC7L+7buf+wi7eF/RzuSYD18x tkw/+w/S/OO3n/fRNzbT53XutXb3snz7txD6x3zw50XpoFtxJnSCBXz8goDvlxALaA/t14DQ8Qqf F3x6h2cHk4EbyH8aqH4ceDDyp2QFeGd8l3uckX8n+H8oeILbR4MB+EI/12dNZ3I0kUqshH0a2HwM yHxCSIR0l4MpBBIyZxjFtxFK2EJMeH+ph0sl+FRRmIVayG0p6Eg/0IVg6EU5YDv4sIVmSB1hmIY2 dIZsOBxqaBJF8IZyOId0WId2WBZtmIdH4Q562Id++IeAGIiCOIiEqEF3aEFReIiKqHuoFE8m/7Fr yqVZKwGJPeYWOlaJGkGJWbgRjCaJYAYSkJhlmBgSy0VglDiJQ3aKnmhmjfaJizgRc5Vgj9gQoqiK GVGKrmiJqYgRlQVdl0iHSwFpidZgvrhpyYVWwiVRk7aMnjZVxaiMyDVdydhijjZazAWN/bRPzMhP 99RpiNaJyNiMW9WN2DhhnUUqFzNEwghm6KRmpTVeiHZmU3Zjl+VjMLWO3+hd9KRdM6ZR/Kha4lVm KrWPsehiYJWMpFaIOSForZVjEUZcW/aOn7hgc+WMcOWOF0aNrEVpEBlmjyaQD+mOL9aLC+ZQCrmQ AVaLLgWO5oSPAGmQN7aS9bSR0phOhLaK6/9YjhgJjhIpjAMpk5uWjZpGZiaZiJmYkvpIXENWZvZI ZWkWj+RlkUF2aDEpkg4JYCEJlVIpj1jJZggWkaOIEnZAemMmi1ZJZviojAdWlVqZlGgpV27ZlgHp km7GlBM1XGrZkWnGkVsZlmoYjPVEkqY1k8wYUZcmjq54mONkjNGYXMcIYYppjeO4YpgGjcf4jPx1 mCy2jdUYiSOVVvuYhL43i69IiqV5LY1IYad5lA2xiav5mrCJRu4Qm7RZm353kriJbLa5mx2Xm775 G7zJfXsQnMRZnMYJf7+JFaH0m7ypDMfJFskZnVnxnNQ5FkQUBtKJQtXpGVAQetn5ndWxneL/OZ7k GR3guTmRcEjlCSyRgEnnqTnpCTCKAIhX5EMRoBXx+Z76WRT5uZ8gtJw71J9GYQT+iS1dwUMCWqD/ aRVsoKCDCKAOKhl3aH7reRqpqTCtAaERahsO4xoHuqG40aGvoaEgahUfwQ8oyg8CkaIoOhAq6qL2 kKIF0aIwyqIt+qIrShA4mqM6GqM22qMuyqIwqqM3uqMqaqM7uhcUWqF3YaQxCqQ4GqUGQaM5mqRP OqQ8iqVVihBHqqUvaqVf6qRWyqR/UQ2JMaZJ2qVXmqU12qZTuqVrqqVPOqZzKqdqCqVreqdASqZu hKYzWqd76qaA+qeACqZ/Sqd3mqZxyqOJ/7qobBp65wBLSxGlN3qohkqoX+qjQnqlagqmSKqpMpqn j6qnjFqqn0oQJSqAGqGorLqol1qnfiqlrwqnhMqph/qmokqqCZEAfPork3qrPZqpcpqrjrqilHoQ rTqlm5qseLqldOqDqVowHiGmzSqqteqjxeqqyAqsgTqotoqpRFqsz1qb3YBJP/qjbHqkVJqu6rqp 2oqrNXqulhqqoNqucVqky9qr+rqv/Nqv/vqvkXR7AMswMnQc9IVBtbako6FYCstJFAgRNgV+CdGw S1YRNsUREwh8RUZUC2Fw9FWATFZ/GTexCmF+FGsREiuCIYtqKwtJDXuxLQuCBXUQFytiS/+2sR3r EB9bsjRLfXVxsD77dXORsBgLsaW0sThVfsMEfi4Ic0G3tE7rci6XZEqrVMbUclZbsSEogrS1suSH tUD7YUWlsUeleEjFsBlrtgRYtlOrd0n7eG97tlQbshH7eDzItmMLtuMHt0CbRkW2W0KrtVA3f1FG uHi3cnlnYoDrsyCLsxWruIvHtU6mdn71uDkruRj7coY7YomrZ2hrtzcrs4NlZHQWfBLYW12rRmSL Zy3Ys53rglF3ZIOrsoXLsSxou5Ebs2Mrsu01t51ruTyLuSC4uJS7d7GbuVHntRw2u1trVKcbgifb MI7btC1Lgd5ngLMru8mbV04rs7lruTD/m7GAe723O7rbS7t9y7qpy2fM63Rvy15Xe7VLm7wqe71S O7+J273Qa4DBIbBFy2esi77ei73Hy3hrd3eLF77ye7CypcBPtr7lu7+w+7+467wcEYHni3Y2+3XF W8HgK7p4N7nnW7B4JRHTm2eLq7y/m71Pd8Dxe7uCW8EIHLjCO74Yp1fmi1QETMHUl8KS274hTMNi 67gyvLwZzL6vG7TlhTsmi7sR+LFEvMABfLY2bMBN27hK+7Pwy7seTMXv+8ISi8N5m8NzhsN1C7Vi fMMuvLZSfFg+tcW0S8VyPMbvS7xZ/MVrR8IeFL3hlyB8PLC0lrWhkbIGK6kXCshvIW6I/zxzhXQW aNsXIAsSL/uzf/HHiohHigvHSqy1KMuyQRvJwdSxgqxeSxq9hBzHqJxxXzvKbax4A/dTijzAwtvF ussStAzKAhe8JFvLJTHDm6ywzKvLEty7qBpubJu1Dby8YevETyu/G9a2any3Q8y+Vet46Su4cGtn UdvMY2zCpstyeou61kzD9Kuza0zDsWzBA0y5qUvEiDvLQUe3t4Ve02zASay7p5bDxOu5z8vJu1zO XfvOEpxq90tw5/y0xZTOu7vOBx3FQKzGM/x9Lkx/5rvPD+26yLtbLJx3/szDzRvQDd3RMezJQGxb iozBDH3Rs6x2asvS8ix+HMy5Ie3L1f/LXhpdwHuHzGjswY0rsqQbXxP7yEHt0yMcboHlwMMszyh8 zkgbzUlM0TJd0kr8c07H1EacyhjN0UCX1J8szN4r1UMlbkfNwx/m0jXcwaEb0fPsu6Gbu2gNuk6t zwEM0mIbERMMw0KL1j1MzHt9zzxlSAKXxRCIvzYdxk9MxnS81m29Xtlcw+LbyvDLsKtMym1M13Ns 11bbdHj8sCitxZNdv9Zbza28yGNhyVlNQaZN2o7cyzOU2qr92qYUrbL9DxhECLCECsA427q92w4K 27792w7DB8DNp49Abby9oYDhgcO9bBuUDsf93NAd3dJdMctd3abkB9btFr/ZDtMtFBP/0N3Jmd0C UwqAA976+RfiIN7qvd7svZ1RgEYK+QTmzRNwlAGn3d6I4UQkOt9uKBj2fRiujd9pwUT7zd8GfuC5 IeD2Yhv88CIK7qsj9OAQbiofcQgWfggCceEWPhAYzuH2cOEFAeIfLuIEoeEg3uEebuIonuEh/uEh ruIjjuEbzuErXuMwDuMvPuMqjuIanuMyXuI5PuJAXuI33uI4TuM9PuMsvuMxfuIkzuQejuRCnuI2 3uQbruQuDuVSjuUy3uMsPuRezuRe7uJgDjg1TuZfzuNR3uJo3uZD/uUprhArnuUIMecdzuVqPudt rudvvudsDud2vuZgfuYHQehxnhB6/87lfZ7ogu7mdB7lio7njq7ojT7oQE7ogW7ofg7oa87nwfEO E8HnmQ7njk7mnv7nbv7jiG7kdc7mqq7qj77ocr7qlQ7rkN7qse7pmh7rhW4QsK7pjE7qk77pv/7o P87oal7pt57nrH7ptM7p0F7qobEUos7qge7rwo7rwm7r2O7svV7md47m3L7p2t7t2T7u477syk7u Sz7rzc7uwZ7q2I7p4m7svN7upH7q4c7s3n7o3x7tvN7h2bIRPH7lRh7vbz7m5m7lV27iqH7vjb7v +J7sgn7kSH7t5z7pp27qaV7uYu7wRJ7kHV/xDq/w297pI3/s7V7kHL/uLS/x/Z7mJP+e7zN/8g4z 6s6O8X2+7rue7hEv7dd+5+Fe77LuEMA+70iP6/y+8Dhf7px+9K6+8ETf8nQu9Pie8Owe9Sv/7hlf 8V3v8m+mFE0/8Tuf7UC/8z5/8rqu9Tqe4Sa/6+6e70lf5t++9Kg+9lJf71CP9Wg/5kNf9W5/9SgP 97e+9TE/7F5v81EecGdO7wBf+Gaf9WkP7WtP94e/9/8u+XyP8t1e5ZmP9w+/55j/+D0/8oGP7ExP +KYv5Iae7JhP8ZH/FYNkGRWe5H5/6Vge426f+0VP5Sa/+xcP7AbP9fAO8iGv87tv5yfe97bO+3KP +29f8kS+6NKf+Go//Kc/79Uf+Dz/j/2sH/02nvuvH/pLnBQSrigBd/5qkv7S1oYEMB3qH//yr4bj H/xKLvJl3+TJD/tdnugzDxCHBB6yV9AgwYMDDS4sOBChPYELH0pUSDGiw4oWEWLcyNDjR5AhRY4k WdLkSZQpVa5k2dLlS5gh/82kWbPmHps5/03keRCix4k/JTIMKrShUaEPlQIdirTn0qNMfULsSbQp 0qtWpzZFqNPrV7BhxY4lW9bsWbRp1a5l29btW7VJ5fosWjUr1qJ450a9i9UoQah+6/4MzJduyLxS t3aF29jxY8iRJU+eGYfy5bJyOx7Wathz0LygCXfeWpov4MWKDxcW7Nc0SNFRMc+m/13b9m3cbmNO Rf3XtN2EGDsrFB2RdPDNXHln7Ns7uefRsEnGhr7b+nXs2bVv5979ZePo4VkD/3y89+rjTAf73tvc N3XOHxM3XC879338+fXvbwvyG0vjqNIIvvrKG6o4w+Y7aj3h2HNvKfgWRGxC1Vzz7kIMM9RwQw53 A08vA0MUMUGnTnutKhStYo1EpwpcsToLE+NvRhprtPHGzEDUUTDi0qOKOIdKAyxA5DT6rUSgMuIp NOZ+JA8549bDcUoqq7RSrA6z1HJLLrv08kswwxRzTDLLNPNMNNNUc00223TzTTjjlNO6K+u08048 89Tzzjn79PNPQAMVdE9CC71sBmRDE1V0UUYbLXQGRB2VdFLIBLX0UpMgxXRTTjv19NOWZgB1VFIX ovRUVFNVdVVWW3VVp2telXVWWmu19VZc3yp1V1579TXNXPXjJlhiizX2WGSTVfbKX5t19llou1t2 WmqrnTQgADs= ------=_NextPart_000_0003_01C6F969.8C5AC8C0-- From gwjpyxhrqjp@planespotting.net Thu Oct 26 20:07:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFEj-00039H-Tl for capwap-archive@ietf.org; Thu, 26 Oct 2006 20:06:13 -0400 Received: from gar78-1-82-238-170-100.fbx.proxad.net ([82.238.170.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdF0q-0001pN-T7 for capwap-archive@ietf.org; Thu, 26 Oct 2006 19:51:54 -0400 Message-ID: <000a01c6f958$c8dddfa0$64aaee52@test> From: "politics" To: capwap-archive@ietf.org Subject: le ubar truncation Date: Fri, 27 Oct 2006 01:45:14 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F969.8C66AFA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd ------=_NextPart_000_0006_01C6F969.8C66AFA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F969.8C66AFA0" ------=_NextPart_001_0007_01C6F969.8C66AFA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Products basic of versions free great software Acid easy original = musiceven loopbased Xpress loops Samples music Vision Series am = Backdrops is. Products basic of versions free great software Acid easy original = musiceven loopbased Xpress loops Samples music Vision Series am = Backdrops is. Dwg in extensions forcrack has is builtin dictionary = toolcalled Dawg Directed Acyclic Word Graph which. Feasible stopping rotate their is words encryption pertinent second is = orderto third forth a achieving cryptcalls way oncethis am first Biham = years agobut thought a idea though never tofinish it. Something thats am likely beneeded by of normal Linux doesnt Iget = messages this dictfiltc elcido cc. Sorting Betcom Page cannot found Search bet web Channels Home is Music = Shows Chat Shine Video Boards in Login Corporate is! Julie team growing demands service latest included server in setup = clients nny a area website or Watertown Authority them truly recently = Womenowned is Enterprise listed Certified. Previews or Xbox wii Lyrics Requests tv times gmt in Pmtotal views = Archive top Powered vbulletin am Jelsoft fd in clever witty in much = Osullivans of blogindex rss atom Potter Halfblood Prince Wynne = Jonesyear. Id appearsto totally bogus or too in Sighthe lesson cables fine turned = justtook forever around suspecting cable permanent link writeback = editleave comment Name Urlemail? Wallquot or mr Hesseldahl consumers eventually able anywhere a = developing companies Triggering recent jon quotdvd in Jonquot Johansen = started company of Ventures whose am bypassing Apples Fairplay governs = drm itunes. ------=_NextPart_001_0007_01C6F969.8C66AFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Products basic of versions free great = software Acid=20 easy original musiceven loopbased Xpress loops Samples music Vision = Series am=20 Backdrops is.
Products basic of versions free great software Acid = easy=20 original musiceven loopbased Xpress loops Samples music Vision Series am = Backdrops is. Dwg in extensions forcrack has is builtin dictionary = toolcalled=20 Dawg Directed Acyclic Word Graph which.
3D"climbing
Feasible stopping rotate their is words = encryption=20 pertinent second is orderto third forth a achieving cryptcalls way = oncethis am=20 first Biham years agobut thought a idea though never tofinish = it.
Something=20 thats am likely beneeded by of normal Linux doesnt Iget messages this = dictfiltc=20 elcido cc.
Sorting Betcom Page cannot found Search bet web Channels = Home is=20 Music Shows Chat Shine Video Boards in Login Corporate is!
Julie team = growing=20 demands service latest included server in setup clients nny a area = website or=20 Watertown Authority them truly recently Womenowned is Enterprise listed=20 Certified.
Previews or Xbox wii Lyrics Requests tv times gmt in = Pmtotal views=20 Archive top Powered vbulletin am Jelsoft fd in clever witty in much = Osullivans=20 of blogindex rss atom Potter Halfblood Prince Wynne Jonesyear.
Id = appearsto=20 totally bogus or too in Sighthe lesson cables fine turned justtook = forever=20 around suspecting cable permanent link writeback editleave comment Name=20 Urlemail?
Wallquot or mr Hesseldahl consumers eventually able = anywhere a=20 developing companies Triggering recent jon quotdvd in Jonquot Johansen = started=20 company of Ventures whose am bypassing Apples Fairplay governs drm=20 itunes.
------=_NextPart_001_0007_01C6F969.8C66AFA0-- ------=_NextPart_000_0006_01C6F969.8C66AFA0 Content-Type: image/gif; name="York.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f958$c8dddfa0$64aaee52@test> R0lGODlhtAFcAYf2AAAABY0ADgB0AIx3AAcAiHYJhgB3f7vGsrbbxrG89TUaBF4dAHYbDJsjAMEf ANwbAABFABtCC0BMAF1HAolCAJRBDrwyAOpBAA5kDipqCUdsCW5iCn9tDZJWC81rAOlaAAOJACSH AEiBAFyHA4tyAJeJAMmEANeHAwCiAByiADyXAFmmAYKmBp+mC7GTDdmUCAnGACq/AE7LAFTMAHy7 AJu0ALTIB9PKAADcABfWADnnBVLuCIHbAK7fCLHWAOPlAAgARR8APzQAS20ARHoARaUAP7kOO+0K TgsqThoXNToiTFEiMXMWSJ4mPbQnQdIVQQZHPhVKNkJOO1k6OnY8RJc7NsBOSdtATQBeNiJhOj5p TG5ZOHRTD6xYTsVcQttTOACGSxWMPT2HQ2R6TYNxNZyOQrd9N+iISQmjSxqYQk2TO22lQIimTZOh OcOaPuinQwC5Oy22PkTAS2bKSHu6PaLHQcO5RejMMwDhOyraSETaSVXePnTeO63XQsbRR9fiMQAA jSkNdkMJgl8MfXIJdKgGgskCdNMAjAAehBEkhD0TgVIkh44hhZoVi8kki9gahgg7gBw5iTc1d1gx fYw/h5I8i7pKdOQzhABeiChlcTlZeV5XjYdVjp1UibplitddgABxdBSHeTmFdWSEioeEcpOGerWE heWDewSqdyuZjE6jjWWuiHmac5uhiLqgjNeceArEehG3dEvDfGm/iIG2cqvHgby3dOfFgADRjRbh fDHZhV7ZioDWjanjjrLrgdfuegACvxMHwkMOwVoIzYEAw5UCtLgAyeYAvQAgsR0lyjQdvlEStYEt zaAmwLUjudUkuwA8syw5xE1Nv11AuYg+xZJNvsE+sdJOyQVWxCZkzkFlzFdYxXVstKpgvcxSuuxo wwiMsReDtj+CtmqMvXOLw6J6zs2NxeOAwAqWxxOWyTytvGKVy4ukw52kx8alwN6uyQO7zCCzzDm6 wlXDvIq2u5nAs/rt6q2sr3yOc/IABwj/APv/AAUO//8C/wD/9///+iH5BADysZIALAAAAAC0AVwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mix4z97IEOKHEmypMmTKFOqXMmypcuX MGPKfCWzps2bOHPq3Mmzp8+fQIMKHUq0qMtkRpMqZemxqdOnUKNKnUq1qtWrWLNq3cq1q9evYJ0u PQlprNmzaNOqXcu2rdu3cOPKnTvUDd27bPvg3SsXAV+hdv8KHky4sGG1gQ8rXsy4sWOUiR9Lnky5 8tvIacNq3sy5s+fPCN18tUy6tOnBmE+rXs269cjUZkHLnk27tu2Lor263s27N0/YvoMLH07c5O3j yJMrX868ufPn0KNTLU69uvXr2LNrPyy9u/fv4Llu/785Y7z58+jTq/cdvr379/Arrp9Pv7jE+qzj 66+Nf/X+/6DpFEB/dAFooFQwDSiSgvYE4CCDDIKk4IARNtjggw6ShKGEGFLY4YULjvTghR8uuCGJ I5aIYkgnophhiDCuKKGIGo4Yo4Uw2khgdfdByGKONFpYIYUoRUhkkCbeOKOSP/5YIY43Ttjkk0j6 OCWSS2Z5pJZcHuilWAleSeOQVWZZ0pNoaghlmkyauWWTcDop5klWpklmm0LGyOaO/W1pJ5Zrmqkm oFDKKWihiMb5pqB/LknlmHHOeGekhlaKJ59qqTDWfW6qOSmXLqJpY4cebihlop+aOOqHrHqqI6km Gf/pKaEtWknpi192dUJ0NckKKZN+trQoqpYyGmuIex56pK1FAovoo45Gmiqm+PmKLK2BsjTsntsS 2mmyxNa5krXFQoujisaaBgG1LXH6rJ6U5nlolMRi+aKSj8oKbqGnnjuuvXAmuyi5JOVqsFa36sgh tEaiu/CErLbK4pD3JvowxKae+SqyDidcMYmxjgrwjQeXbBG7KKes8soss9tLyzBjl45i7sYsk8k4 u9dWPtnl7DNtMPEsktD25GM00USDlPTQQxtddNJC83z01CRR/TTVUzvtdEhLb60010eDnXXRI0mt NdRiI23z2jKp/TXXb8NdNdlye0032iWhvTTdTTP/3Xfdfssd99tR42042zbf5/beUpedN9938703 5IELbvnXbsOtNuOVd0245JTL/fPon7UNuuOez3145pW3HjrnrJO9+dyWpx416JOHjjhP9fSHN9Op B77457TnHfbVYWfdeOR+38557coT77zYg+9emDd4ufu75o53f/rsxaO0vOvgC97484PbHvf53QtN +vvN1a6692kPj/njKo1/Oe7es0//9sybnfrs4RUAAAB+CIzI5X4XO8rdDnJ221/6Xhe+CELtgdUD 4AMvOEGRaMWABkwg/GrCuONRL3yy09rf6Fe240XvhStMH9JMKD/gqRBs9ateUUAIgNL00Ho1s95K /6gSwvYUkSuWAJAQl+gSA+LED/gRoRSZc8QpcoSJWMziEK3IxS56SYtgDKMHvUjGMprxjGhMoxrX yEafifGNcIyjHOdIxzra8Y54zKMe94iWNvrxj53hoyDrA8hCGvKQiEykIhfJSCkO8pGQjGRpuCHJ So6ECpbMpCYH2chOenIidAwFcYCxyXZ98pQWkQMqV8lKRJbylb1ppSzPqI9Z2vKWHdlNQnCyS1ia Rjeu6aVNhOlLy3ikmPT5QEuUKRxmuoWHa3FiSH64mA9Y05n2uKYzsZlNbYbEmiIB5zfDec1xmvOb 4BQnSJSpzW2OhJne7GY75bnNdM6TnibBZjzXef9OmeyznercJznFec9shlOe74ynPvupFmqyRZog cahhFmpQc3KTours5jjdyc+KevSgGt0oSC/6UYp21KPwJIlJQVrSc3LzJSv9qEzfeVCMulSlNe3n S88i0YiC0KdO/Kk9eijUoUqTqEed5kiIqlSj/hCaRYVmRM+y05eyk6Y5Tak7OVrRlJZEqyLNqVi/ ylKOWjUlXN1oOdkZ0HIalKRYPelMu0pWsca0pV5laVp66lCmTnWqEJUoUpVKTcEOtamERaxf/9pT o1QVp3AVKVj5ydXJ1vWqlKUpSXcq18rK9bM4BW1eA4rXs8a1paF9bFZP29m31rWhJOnrYf96WNn/ imSxs8UtY2kLWMXOlrdmqSdmx/rZq07WrG4NaT47atnMjjS5nYUuPO8p0JtiNa3DdW1o9XrXsqZT s6blrnJZy9PY3va3hf1tbn9qW92id71B9S0PIUpVzUKWtZgl6Em9utWTjFa7YWUoapk7UrRu17TY ped3t6tTvTIYwJmNLDrdml0B50QifD1venubWA7vNsO9Te+Ga4sSYt4MIZu9r4Pzy1+FWhS0BI6w fR08YJS+GCXhRXCDw0vjlXK2uDLNb49Ti9NjwsSwHX6vbEV8XuDyNr4eZnJTG+vYAt+4wTOt8HD/ S2R0Dtis4rUuXU/LY5MmeKGcjamE90tcLts4/8sM/fEwFejUpwp1xEiNKnubrF7EGhWoi92wVGdr 4pj0sqD/9CaiVRxgCF90wetkK3QROmEJo9meCp20TicN6a5S2L+atuqnKy1p0qqVvwzmKDBtQuWV tDoohYZJrNcm5+wwc9U1eTVKdA2UWbvE1zartXWcaWRkGvvYyMYjLpfN7GY7eyIw0E+yp+2YZ1v7 2tjWjyCyze1uj5Da4OYOV0jg7XID7S5iCLe6R2LuRmbjkOuOt7znTaAgGgXYf8H3r9ttIHr7Wzi8 7vO/B16SQbck4AFXjQAWLgCQMHzhIWl4xO3BcIKbxrYHdzVxJO5wiotE4hwPucUvbl7Asjepev9O qsBZw/GPj6ThIHf5yEkDYhLTdrAetnnCK9Pyibsc5i+feb4VOGi/4lm9uNWtvveSkJBDvOcw77nH CchvBC6Vw0dfsobZjZDGND3oUPd42Kle9fddXefy3XqSQbL07CEk7HDvuM/LDj+MHz3nSc8t27vO mF22HOg+F7nc6b6fmBj87rUt+p2d7JqHR73icu845Am+CNfsXOiYl8nlM+9ve/OS7/kBfU8I/x3O mz7e2kg2FOgz35KnLPUjgX3stUF72oOk9rI/vWAw3rLah8T3JMn97UUifN3jRetGv3NU0ZP65hO/ JMXPffGNnxQMa/ipfW7v3g8SzK47P/bQx/3/8H9PdtLz6iVazznS52N78Kfk++On/qYi0nolL7X+ IWn7Y4TZfvK/3x7SV37mZyA1p1uvpn/VBnrwB4AqsYCpN4BfUoDZ12Q/hIBe530MGID+F4ABCIHn 10SuZ2dHtXzM13+4B3uyJ363B3zyJ3TT14JDBxE+YYF9p4A84YHQAYM6aEo42IM+mEZ+8INPsYNE mBJCeITPUYRKWBJI2IRO+IRQGIVISAoLsYRWqB7ZoIP9cIVc2IVe+IVgaB2eF4b3NktkeIY5IWw4 oYbjRV5DwYZsuBY8Nlc8EYeSVFA4ZmE9oYaqRYdBIWdpBWNy+GB2uFz+lVCBCEndFVeFGBN8//ha jXgTgKiHcTGHkeiGkZaIlxhHaBZna0Vp+KRSn5ZceJiJ05VRigaK1fVmntZW+lVcnzhqoTaKrlhV FDZqzlWKklZpX0VQoeZafQhHEtGJouVlzgVkatVolgZj9aSMjOiMxNiHpFVhO9ZfcUZmeFVjypVd P5ZXM6Zg5sRviyaNbYaNxIiMMfaMzmhfQgaNdHhm71iOamaOq3WN63hZoIZlt9ZuNkWOp8Zp83SO QWZl6khZpQiMrbhWAdmNOxZpqVZa1bWMnTiP/5hRpiiIDola+2hu/QiJxPVg2WiP6VhWH3lf7Thk adaQIulofjiQ7kiRx+iRLWlcVmZLMGFmhv8YkujIks0YZv4Ykz8pkCdJkvfYWkKJX2P1XT2pkujo jau1iIooUN3IjRcpiq/IXJ1Wle9IlaF4YAMlXG5GTtmoaaGIUWSZaa6oXZ/4lWDZi23llryIkfMB AzdIZ6+FhizBhvyWk3iZl0xhhn1pfFI4mKUTmIZ5mIiZmIq5mMjUBIy5NoQZmZvxmDMnmZY5GpRp cV9yBJfZSiFReZkJS6gQmjrYmaZ5mqjZHqQ5cKnZmq5pMgf0mrKZEVXkJf0wm4BUm7i5mw8Rm7z5 mw6hm8BpfuGQFb45nMh5EMJJeKuZEvQ1GU/AI8k5naK3FvzQnEs0hvRBnSZDLdwJHikxCdj/KXT8 UJ7XaQ/mWZ4hcZ4gcZ3mORLquZ7omZ7uKRLsiZ7wmZ/0eZ/8mZ7yaZ/qGZ/tOZ/+OZ5xcR/8iZ// yZ4MShICip/3OaD/KaETOqARKp8NuqAO2p4JeqFj9J254qERWp8KSqEYeqIbCqEmuqIkuqEZiqL2 aaEwGqMCCKKa0Qr/gApSIaL6WaIrqqIymqIkeqEj6qMx+qJBSqMt2qI0aqPdARMMGqD6SaRCaqH0 KaFD6qD7SaDvWaLnWaRUqqBfyqUPaqA3IQI6IRFg2qNFmp8yyqMNGqYzOqFjeqRV+qYl5qResqZ2 6qNyWp8eOp/ryaN9Cp8FyqdKeqKBun16/+ocMdGhiUqhciqogdqmbjqnRsqkdRqpHGqkP2qmg3Gl V2qi7lmm/UmmSOqpmYqqqzqqZEqgflqqhwqqLKEIXGgES6gItkqrvNqrvvqrlvScMMNrmwdwJlGs BWKX6GdwLNFY+OecN4GsBTet1Apoe8ZnjHd2KkFf7sV4vHcSrfZqxSqtOcGsfoatGpetTDgVRkGu K/etx9oWzjqtNTeB6Fqtzgmv97p+uyas56p2e0Gs8QqCxqp2ipdnSMZYi4ewdRZiJ4d9eTZN5qp8 zzmv9fpe2iqxIrix5iVlrRexDXtb/op0QVVUAAuyKIuxUpV8Ihhi5+qsixeyKduyDcuxif/nrnMh WNi3du8KsIk3Zdd3c4kVWPxKrfPasa4ntBl7diM2gUy2ZIKWtNWasEjrU4T1tGuHc1SmtS+btEwF tVdbclJmcv8Ka8raRFDlZwaIr3mnfUmWdeunr7sltRjbtU4WrkoLXDv7tT67s/vKZ1QLuE8Wt1h3 svGafveKfH3bs/aXtTUKJkSRsO3VtBo7gmkLtG+bdogrcCuLr3l7t4wrsipXZxU7tISLufcHriJb tiq7uBBrrUlXWNeqfpz7saTbtqLrt7jLuj7hA9oJrYKrtt5Kt24bZZq7uMF7tLkbuDa3tFGrrva3 u3Pruf/qt/cXs3ind9YLumPbvNVbtdj/GmioK72H5RkrB7y+JbyhK7zF27xwi7ilO73oSrUZprxK 27T0y7dW275L+73r673Si7+c27isS78AfLqtm72yZb7jmrEry63MK7OAi73vS4FQlrsSe70XPLh0 a62AlsEhG74se8BWq7EFB1UQ7LwI7L4YjF6BNbvq+sAqJ8OjG8JQ1rlKZb7mgbOPwcM0J24Iginm ankmax0+/EtnC6xu8W1KfIVbexjd2hPuqrOKccTIFK4w/LfQa3jb2r+06xO6NsRGp3nlWsRezLuu RrFm3MI2bLJrvDJP/LfiOhYR7L1AMce7psWRq8V4zMU8q7qOy7/m0RA5QBBO9cGJS7hm/2zAIHvI V9fIdtu54nt3Byu7b/yuKFezC3uzCtvATPuwNtvIkpzHyEq+7sVGFEi9bUu5jMzKj+zKrsvCcBvI fEzKehe3dsazm1e/IRi0ChzGpJtxm4uwFbhGqUy8Kxy4w6zC3zpfG6y/k4x2tMy7czzGCLy55wvI Pvu5ppzNw9vFybx+3hFtWyHByLzM84u8zJp36ay4sizNClzLsbVne2u4HbbOJcu87iXAUHu5Jzyw 4MrPi8tGz9u/3ZzO0+y0CE3Lr+uy1nvQqmy6t2y8Eu3NES2BCV3AeazNg7vMTJxx8tvOGdzM2vrM dZu9Il3Rksu+J7u9eivRD33S+mvRbP8Luh0dy8iMuv4bz2hMHfeheCd8w/H1rB58yOy8zkX70hIM yyT7wk490Rr8wdZszqc7xNvqxnqGyPiHwxpsuZR7u4jcxtKEytthxQA9rEJB1tlh1tQLx0Px0U3s S406nXFd13Y9HHOd13q913yNhHf915Fk1YBNR858yXLd1wkxX5Kpe+/Q2INdSo0d2Y+9SZH9DpOt SZVt2UTYqI2N2J4thZcd2qTp2Ozx2fDT2V8i2oYh2cRh2j6D2iWj2n9B2rLNR5pd27id23fk2q+p 277928DNeb8b3MIRFTJxCMh9CCCR3MgdEsrt3PaQ3CMh3dFN3SLB3NL93NCN3dq93NP/Hd3Tzd3V rdzN7dzdfd7iLd7hXd7crd3Mvd7kfd3rXd3yfd3p/d3qbd7vXd7e3d7jnd3W7d/Qrd/0vd3o/d/N zd/gLeAEruDk/d7eXd8Q7t8QDt4SPhfnbeER7t4D/t0a/uH1HeHbjRLdveAmUeLP7eAcXuIfzuIh 3uIeLuIo3uESnuElYeMjfhIs7uAvvuM0DuImPuA8ruJAzuM/XuPybeMzjuMwLuMd7uIzGBEuvuQi DuQWDuUxDuLxreP4feIevuVbHuQ9TuJcfuRhLuReLuZQzuRifuMkEeZM7uNVXuRNDudBHt8+zuFH juYr3uVJXuZOHugWvhlT3uUz/uZz/57mc37miP7nbn7hKa7hjN7kit7oiT7pk87ne07p/U3mfs7p cq7liK7kkn7nbd7pVY7lkd7njp7jjy7obf7cxv0S7p3g+B3qIV7hlo7gCY7dWX7qP77qqK7nNJ7f +n3ol17kWH7lG17pFO7r9r3fzV7svq7ri/7k047nnX7fzL7p3S7srb7h1p3q437tRCERVP7nyP7i m87mmR7sVi7qVx7ppT7mLBHno57vac7qu57ule7k+P7lu17v3W7iKQ7uuc7pAr/tn57sxe7wAz7r LuHvw87uiR7v7h7v177mC8/ey23tbO7pqa7vF/7o/J7lFD/wpR7wCc/u0F7w2l7gmP/u6hpP7wbf 8HT+8Obu7WqR4aQO62je7i6v8YHO8SUf7qAu8gqP48he6C1u9Buv9ORu7y2v80F/4Hne7yEf9B9P 6XrO8gR/8Ri+3xXu8wo+3h9/9lTf3y8f7cce57aO83Bv7f/963Uf7WeO4nHf9a8u6sbO60/f49W+ 9ku+9/Sd54Nv3haf9oHf9mh/7Ci/9kS/E8NN3KU9hJZvR5VvSbxtyJn/+aCvFGCP3i8v7Ys/4WWf 5Gqv63RP+qoe4FsP8gDu+Hev3stupiw/80Nv8T5/9MSu8/hO7E4v7rxf9XY/8gv/mPcB7r0f+b++ 7vBu8zlf/Kge9slu58Wv6ivR9Iz/ytsxwfxIr/DyvudUDv3Tj+3Cr/IxP/40f/wD//uLufwVD/Qh z+AybvgLjuuQn/NfX+7XDxD27B0SSFBgwYMHCRpMqLDhw4ENGUa098/iRYwZNVo8sNHjR5AhRY4k WdLkSZQpVa5kGZHhQocIE06cKDPmTYQ1YeqEOJOiz58GhUKs6dIhT4k/HxadWZSmQJZRpU6lWtXq VawtB76kecgrUps4lY6F6XOo2KVjKX71atNp2pdk4fZUi1Zuxax59e7l27cvXcB3BQ8mrLSszLhh w55FnDRx0phd095kWtdy5cCZNW/m3NnzZ9ChRY8mXVozWLBq2Rbe+rV128Wtl7pW/0hb7tPZsA0z Xd1U92W2jO2aJl7c+HHkyZU3RLnc+XPo0Zn7pV7d+nWPffRK597d+3fw4cWPJ1/e/Hn06dWvZ9/e /Xv48eXPp1/f/n38+fXvF62J/38AD5ojQAIhwu5ABBNUcEEGG3RQK+QiKHBCCiu08EIMM9RwQw47 9PBDEJF7cEQSSzTxRBRTVHFFFlt08UUYLQpxRhprtPFGHHPUcUcee/SRvBiDFHJIIos08iIAADhy SSabdJJFJZ+UckoqV4qyypCSxHJLLrv850rq2EvyRzLLJA2A7lAE00s22yRSS7/eGxM5Wsy0M0Q0 oVtxTTf79HPPPzGCM1BC2/ziRM8+/Uy0UEYbrW5Rqu6UdNIyHbX0Ukz3onRTTp8DBLk/OhV1VFLt gaNUVFM1TxlVW3U1xExjlXXW5l619Vb3aKUqgUYn6PIXXT3CddgLeTlOEWKTVVbSYJt19lloo5WW zWUzLKRaEKrVdlsdK+FsWnDDFXdccsutjlt001WXRijWzdBceON90V166zVQXnxldSJffvuNl8c8 7RXYu0sh9ffgFncMeODzbGCYw4Ufllg5Rw1G+GIVdYx4Yo479jjHfj4WeWTiMDb5ZJRTVnnBgAAA Ow== ------=_NextPart_000_0006_01C6F969.8C66AFA0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Oct 26 21:27:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdGVR-0000IA-MS for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 21:27:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GczLO-0006lZ-SP for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 03:08:02 -0400 Received: from mx1.tigertech.net ([64.62.209.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GczF7-0000rO-HY for capwap-archive@lists.ietf.org; Thu, 26 Oct 2006 03:01:37 -0400 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id A785F398063 for ; Thu, 26 Oct 2006 00:01:27 -0700 (PDT) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 180114A460F for ; Wed, 25 Oct 2006 23:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DD7F51448041 for ; Wed, 25 Oct 2006 23:59:52 -0700 (PDT) X-Greylist-Status: Sender first seen 1 mon 8 days 19:05:55 ago Received: from mx01.sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by hermes.tigertech.net (Postfix) with ESMTP id 7B4581448040 for ; Wed, 25 Oct 2006 23:59:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Oct 2006 23:59:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] need clarification on UDP ports Thread-Index: Acb4WJf9J/zPjadeTYalbnIsuf2LKAAajXAwAAG98vE= References: <8954613CA6BB3242A1531D916A527A4102235483@NT-SJCA-0751.brcm.ad.broadcom.com> From: "Abhijit Choudhury" To: "Puneet Agarwal" , "Margaret Wasserman" , "Pat Calhoun" , "Scott G. Kelly" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: capwap Subject: Re: [Capwap] need clarification on UDP ports X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2098037301==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 This is a multi-part message in MIME format. --===============2098037301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F8CC.5338E63D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F8CC.5338E63D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, I like the solution below, but I'd go one step further. We should just have a single CAPWAP packet format. The shim header should be present in both capwap control and data packets, and should have a field to indicate encrypted/unencrypted as well as a type/sessionId field. =20 For packets arriving on either control or data port, the encrypted/unencrypted field indicates whether the payload is DTLS encrypted. =20 For DTLS encrypted packets arriving on the data port,=20 the type/sessionId field indicates the QoS level in=20 order to avoid antireplay issues. =20 This approach is simple, clean and addresses all the=20 concerns raised so far on this issue: =20 1. Uses separate control and data UDP ports to steer packets through legacy devices with different levels of QoS 2. Is able to distinguish between encrypted and unencrypted packets in the CAPWAP payload. 3. Is able to support multiple QoS levels if the data channel is=20 DTLS encrypted. I believe this is similar to the proposal that Scott=20 presented in one of his earlier emails.=20 =20 Regards, Abhijit ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Wed 10/25/2006 11:17 PM To: Margaret Wasserman; Pat Calhoun Cc: Hasan Raza; capwap Subject: Re: [Capwap] need clarification on UDP ports Hi Margaret, I am OK with your 2 port solution (with shim header for capwap control only). To summarize, it seems that you are proposing that there be two UDP ports reserved for CAPWAP: A) CAPWAP Control Port: All discovery and capwap control messages flow on this UDP port. There is a new shim (control mux) header added between the UDP Header and the following header (where the following header could be DTLS if encrypted or CAPWAP Hdr if non-encrypted ). The control mux would specify if the packet is DTLS encrypted or not. I didn't want to use the "Control Header" for the new shim as section 4 already talks about a "Control Header". B) CAPWAP Data Port: All CAPWAP Data messages flow on this UDP port. It is a property of the UDP tunnel whether the payload in encrypted or not. If the tunnel is encrypted, then a DTLS header follows the UDP Header. If the tunnel is not encrypted, then a CAPWAP Header follows the UDP Header. Note that there is no "control mux" after the UDP header. Is the above interpretation correct? Thanks. -Puneet -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Wednesday, October 25, 2006 10:09 AM To: Pat Calhoun Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap Subject: Re: [Capwap] need clarification on UDP ports Hi all, Just commenting as an individual contributor... I prefer the intermediate header approach to the third port approach, because I think it is a cleaner representation of what is actually happening. Different ports are used to reach different end points (different systems or different processes running on the same system). In CAPWAP, we have one port to reach the data end-point and another to reach the control end-point, because we think there are cases when the data and control end-points may be different processes or run on different systems. That makes sense to me. However, when we are talking about DTLS-encrypted and unencrypted control packets, we aren't really talking about two different end- points. We are talking about a single control application that needs to decide whether to treat each packet it received as unencrypted or as DTLS-encrypted, in which case it needs to be handed to the DTLS engine for decryption. If you think about it that way, I think it would be better for the control application to receive a packet that starts with a short header that indicates whether this packet is DTLS- encrypted or unencrypted. If the packet is unencrypted, the control application processes it directly (or ignores the packet if it isn't a discovery packet), and if it is DTLS-encrypted, the control application strips off the header and send the packet to the DTLS engine for decryption. This type of header might also allow for later expansion if the security world evolves and a better security mechanism for CAPWAP's purposes emerges. So, I would prefer that we add a short header after the UDP header (a CAPWAP control header?) that indicates the type of the encapsulated packet (DTLS-encrypted or unencrypted). I think 4 bytes would be long enough for this header, and that would maintain 32-bit alignment. IMO, it should contain 2 fields -- a one byte version number (0x01) and a three-byte type field. At this point, only two types would be defined. I do not have a major technical objection to the third port option, I just think it is less clean from an architectural standpoint. I would rather strenuously object to the proposed approaches that involve zeroing out the DTLS header or running a packet through DTLS and then treating it as unencrypted if that fails, etc. Margaret On Oct 25, 2006, at 12:33 PM, Pat Calhoun (pacalhou) wrote: > Not pushing for the hack. I've stated I do not object to a third UDP > port, but provided an alternative should IANA refuse to give it to us. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > >> -----Original Message----- >> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com] >> Sent: Tuesday, October 24, 2006 1:24 PM >> To: Pat Calhoun (pacalhou); Hasan Raza; pagarwal@broadcom.com >> Cc: capwap >> Subject: RE: [Capwap] need clarification on UDP ports >> >> "Pat Calhoun (pacalhou)" wrote: >> >>> Except we can document that any CAPWAP implementation receiving a >>> packet with 'n' zeroes uses DTLS header format foo, which >> is of lengh 'y'. >> >> ...except that it is decidedly *not* a DTLS header, right? >> I'm having a really hard time understanding why you're >> pushing for a hack at any/all costs to solve this problem. We >> are at the design stage - if there were ever a time to do it >> right, that time is now. Exactly what will break if we don't >> adopt this hack? >> >> Scott >> > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap ------_=_NextPart_001_01C6F8CC.5338E63D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Capwap] need clarification on UDP ports=0A= =0A= =0A=
=0A=
Folks,
=0A=
I like the solution = below, but I'd =0A= go one step further.
=0A=
We should just have a = single CAPWAP =0A= packet format.
=0A=
The shim header = should be present =0A= in both capwap
=0A=
control and data = packets, and  =0A= should have a
=0A=
field to = indicate  =0A= encrypted/unencrypted as well
=0A=
as a type/sessionId =0A= field.
=0A=
 
=0A=
For packets = arriving  on =0A= either control or data port,
=0A=
the = encrypted/unencrypted field =0A= indicates whether
=0A=
the payload is DTLS =0A= encrypted.
=0A=
 
=0A=
For DTLS encrypted = packets arriving =0A= on the data port,
=0A=
the type/sessionId = field  indicates the QoS level in =
=0A=
order to avoid = antireplay =0A= issues.
=0A=
 
=0A=
This approach is = simple, clean and =0A= addresses all the
=0A=
concerns raised so = far on this issue:
=0A=
 
=0A=
1.  Uses = separate control and =0A= data UDP ports to steer packets
=0A=
      =0A= through legacy devices with different levels of QoS
=0A=
2.  Is able to = distinguish =0A= between encrypted and unencrypted packets
=0A=
     in the =0A= CAPWAP payload.
=0A=
3.  Is able to = support =0A= multiple QoS levels if the data channel is
=0A=
     DTLS =0A= encrypted.
=0A=
I believe this is = similar to the =0A= proposal that Scott
=0A=
presented = in one of his earlier emails. 
=0A=
 
=0A=
Regards,
=0A=
Abhijit
=0A=
=0A=
=0A=
=0A=
From: Puneet Agarwal =0A= [mailto:pagarwal@broadcom.com]
Sent: Wed 10/25/2006 11:17 =0A= PM
To: Margaret Wasserman; Pat Calhoun
Cc: Hasan = Raza; =0A= capwap
Subject: Re: [Capwap] need clarification on UDP =0A= ports

=0A=
=0A=

Hi Margaret,

I am OK with your 2 port solution = (with shim =0A= header for capwap control
only).

To summarize, it seems that = you are =0A= proposing that there be two UDP
ports reserved for CAPWAP:

A) = CAPWAP =0A= Control Port: All discovery and capwap control messages flow
on this = UDP =0A= port. There is a new shim (control mux) header added between
the UDP = Header =0A= and the following header (where the following header
could be DTLS if =0A= encrypted or CAPWAP Hdr if non-encrypted ). The control
mux would = specify if =0A= the packet is DTLS encrypted or not. I didn't want
to use the = "Control =0A= Header" for the new shim as section 4 already talks
about a "Control =0A= Header".

B) CAPWAP Data Port: All CAPWAP Data messages flow on = this UDP =0A= port. It
is a property of the UDP tunnel whether the payload in = encrypted or =0A= not.
If the tunnel is encrypted, then a DTLS header follows the UDP =0A= Header.
If the tunnel is not encrypted, then a CAPWAP Header follows = the =0A= UDP
Header. Note that there is no "control mux" after the UDP =0A= header.

Is the above interpretation =0A= correct?

Thanks.

-Puneet

-----Original =0A= Message-----
From: Margaret Wasserman [mailto:margaret@thingmagic.com]
Sent: =0A= Wednesday, October 25, 2006 10:09 AM
To: Pat Calhoun
Cc: Scott G. = Kelly; =0A= Hasan Raza; Puneet Agarwal; capwap
Subject: Re: [Capwap] need = clarification =0A= on UDP ports


Hi all,

Just commenting as an individual =0A= contributor...

I prefer the intermediate header approach to the = third =0A= port approach,
because I think it is a cleaner representation of what = is =0A= actually
happening.

Different ports are used to reach = different end =0A= points (different
systems or different processes running on the same =0A= system).  In CAPWAP,
we have one port to reach the data = end-point and =0A= another to reach the
control end-point, because we think there are = cases when =0A= the data and
control end-points may be different processes or run on =0A= different
systems.  That makes sense to me.

However, when = we are =0A= talking about DTLS-encrypted and unencrypted
control packets, we = aren't =0A= really talking about two different end-
points.  We are talking = about a =0A= single control application that needs to
decide whether to treat each = packet =0A= it received as unencrypted or as
DTLS-encrypted, in which case it = needs to be =0A= handed to the DTLS engine
for decryption.  If you think about it = that =0A= way, I think it would be
better for the control application to = receive a =0A= packet that starts with
a short header that indicates whether this = packet is =0A= DTLS- encrypted or
unencrypted.  If the packet is unencrypted, = the =0A= control application
processes it directly (or ignores the packet if = it isn't =0A= a discovery
packet), and if it is DTLS-encrypted, the control = application =0A= strips off
the header and send the packet to the DTLS engine for =0A= decryption.  This
type of header might also allow for later = expansion if =0A= the security
world evolves and a better security mechanism for = CAPWAP's =0A= purposes
emerges.

So, I would prefer that we add a short = header after =0A= the UDP header (a
CAPWAP control header?) that indicates the type of = the =0A= encapsulated
packet (DTLS-encrypted or unencrypted).  I think 4 = bytes =0A= would be long
enough for this header, and that would maintain 32-bit =0A= alignment.  IMO,
it should contain 2 fields -- a one byte = version number =0A= (0x01) and a
three-byte type field.  At this point, only two = types would =0A= be defined.

I do not have a major technical objection to the = third port =0A= option, I
just think it is less clean from an architectural =0A= standpoint.

I would rather strenuously object to the proposed = approaches =0A= that
involve zeroing out the DTLS header or running a packet through = DTLS =0A= and
then treating it as unencrypted if that fails, =0A= etc.

Margaret


On Oct 25, 2006, at 12:33 PM, Pat = Calhoun =0A= (pacalhou) wrote:

> Not pushing for the hack. I've stated I do = not =0A= object to a third UDP
> port, but provided an alternative should = IANA =0A= refuse to give it to us.
>
> Pat Calhoun
> CTO, = Wireless =0A= Networking Business Unit Cisco = Systems
>
>
>
>> =0A= -----Original Message-----
>> From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]>> =0A= Sent: Tuesday, October 24, 2006 1:24 PM
>> To: Pat Calhoun = (pacalhou); =0A= Hasan Raza; pagarwal@broadcom.com
>> Cc: capwap
>> = Subject: =0A= RE: [Capwap] need clarification on UDP ports
>>
>> = "Pat =0A= Calhoun (pacalhou)" wrote:
>>
>>> Except we can = document =0A= that any CAPWAP implementation receiving a
>>> packet = with  'n' =0A= zeroes uses DTLS header format foo, which
>> is of lengh =0A= 'y'.
>>
>> ...except that it is decidedly *not* a DTLS = header, =0A= right?
>> I'm having a really hard time understanding why =0A= you're
>> pushing for a hack at any/all costs to solve this = problem. =0A= We
>> are at the design stage - if there were ever a time to do =0A= it
>> right, that time is now. Exactly what will break if we =0A= don't
>> adopt this hack?
>>
>> =0A= Scott
>>
> =0A= _________________________________________________________________
>= To =0A= unsubscribe or modify your subscription options, please visit:
> = http://lists.f= rascone.com/mailman/listinfo/capwap
>
> =0A= Archives: http://lists.frascone= .com/pipermail/capwap



________________________________= _________________________________
To =0A= unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives: =0A= http://lists.frascone= .com/pipermail/capwap

=0A= =0A= =0A= ------_=_NextPart_001_01C6F8CC.5338E63D-- --===============2098037301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2098037301==-- From epkmfmbr@pititako.net Fri Oct 27 11:07:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTIo-0005VF-2l for capwap-archive@lists.ietf.org; Fri, 27 Oct 2006 11:07:22 -0400 Received: from [201.247.225.227] (helo=[201.247.225.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTIk-0001nt-D6 for capwap-archive@lists.ietf.org; Fri, 27 Oct 2006 11:07:22 -0400 Message-ID: <001001c6f9d9$93feda10$e3e1f7c9@ownerwam9o2stk> From: "critics:" To: capwap-archive@lists.ietf.org Subject: Final Fantasy Date: Fri, 27 Oct 2006 09:07:11 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000C_01C6F9A7.49646A10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 ------=_NextPart_000_000C_01C6F9A7.49646A10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01C6F9A7.49646A10" ------=_NextPart_001_000D_01C6F9A7.49646A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Privacy Statement top Powered a by Version copy or Jelsoft ltd Terms = Conditions Legal Oaslistpos News Homepage Oasadspon? User in Name = Remember me Password Register faq Members List Calendar is go to Page = Invalid Forum specified if you followed valid link or? Privacy Statement top Powered a by Version copy or Jelsoft ltd Terms = Conditions Legal Oaslistpos News Homepage Oasadspon? Get an extra hour sleep this weekend playbook Obrien of Barrington set = up Week Download Test Drive a Chevy Suburban could is easier handle a = about it pm Travel am. Forums vbulletin Message User Name of Remember me Password Register faq = a Members List in Calendar go is to Page Invalid Forum specified if you = followed. Years copes with is Next expected around Wild pigs eyed = spinach probe may be source of e coli Drug. Violence is that rocked immigrant is South Korea sanctions a n Korean = officials. Faqs and Archive Upcoming Games in Tomb am Raider Legend Reservoir or = Dogs Discussion Kane Lynch Dead men of Crossfire Midway. Request washing am hands Click here Spotlight hundreds businesses sale = Select Category or Automotive Business Childrens Cleaning Computer = Internet. Ohio is six a others managed escape blaze of inside twostory of house = likely Nurse accused poisoning classmate say grudge over stolen of = boyfriend led death Naming or new world or wonders. ------=_NextPart_001_000D_01C6F9A7.49646A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Privacy Statement top = Powered a by=20 Version copy or Jelsoft ltd Terms Conditions Legal Oaslistpos News = Homepage=20 Oasadspon? User in Name Remember me Password Register faq Members List = Calendar=20 is go to Page Invalid Forum specified if you followed valid link = or?
Privacy=20 Statement top Powered a by Version copy or Jelsoft ltd Terms Conditions = Legal=20 Oaslistpos News Homepage Oasadspon?
3D"Legend
Get an extra hour sleep this weekend = playbook=20 Obrien of Barrington set up Week Download Test Drive a Chevy Suburban = could is=20 easier handle a about it pm Travel am.
Forums vbulletin Message User = Name of=20 Remember me Password Register faq a Members List in Calendar go is to = Page=20 Invalid Forum specified if you followed. Years copes with is Next = expected=20 around Wild pigs eyed spinach probe may be source of e coli = Drug.
Violence is=20 that rocked immigrant is South Korea sanctions a n Korean = officials.
Faqs and=20 Archive Upcoming Games in Tomb am Raider Legend Reservoir or Dogs = Discussion=20 Kane Lynch Dead men of Crossfire Midway.
Request washing am hands = Click here=20 Spotlight hundreds businesses sale Select Category or Automotive = Business=20 Childrens Cleaning Computer Internet.
Ohio is six a others managed = escape=20 blaze of inside twostory of house likely Nurse accused poisoning = classmate say=20 grudge over stolen of boyfriend led death Naming or new world or=20 wonders.
------=_NextPart_001_000D_01C6F9A7.49646A10-- ------=_NextPart_000_000C_01C6F9A7.49646A10 Content-Type: image/gif; name="gate.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c6f9d9$93feda10$e3e1f7c9@ownerwam9o2stk> R0lGODlhyAFgAYf2AAAAAIMNAAp0AIiLAAADgH0AiACGg8nHuLjqsbPN8zckBVguAI4jDZkqBbgg AOkVAAA/Ch5IAD5GAGE/AIhKCZtGAMFDANRLAAJfCiJoA01TAFdsAHxSAJhbC8VmAOZYAAx+DSSH AEyJBWV7AHqBAKGHAMZ4Ael6AAykACWYAEujAWyaB3WmAJipArGhAO2ZAArGByHMAD/IDV7KAY7N BqbJAM3BANW1AwDiACHbCjXeA2PmCIrrAKLsDMHcAOrWAAgAQBQKQ0sAMVEAQ3gNTaMJRsMLPOMJ MggfPhQZPTghPmIsR4MZR5QeM7krS+YWNAA3SBQ1PjJISmc6QXZHO5lDQ7g0PeAyTARuQhlbNkdn NWhnMntjC55qMsRYOeBiQgB1MReCSzJxOWx7QYl4OK14P7mCTuJ/SAyoSSWWNjyqPlmrPHOYNa2c Mb+bQt2lRQnKPi3ATknDP1vLM4DJSZS5QMi4QOHFOgDZRhHWTUHhMWvkRnfjPKreMcXgMdreMQ0K jSkAjk4JdmgAinUGjaUAcb4IjOMIfgAuiSwldzkmiGUqfHEufZcsfrMset0diQg1hRwxdkVAc2BE coJGja4xi7hBgNQ+ewBYgBRgfDNXeGRhcoZohZRfhrtdi+lgdgWIdhqLdz11dFN/domEf6l2er2E h9KAgAeniB6uc0OXiVWtjY2aiKSthsKle+2pcwC8jRy/i0mxhWPEfHzNeqK4ebGzdeHOiwHtdC7g iETucWPTiY7aeq3gerzYhd3bewcIuSUDvT8As2EAuYUAtZcNtLEIzOQGyAsrti0kuEgXzmsoznQf xpsTt78lv9cuzABBtx9CukYyyVcxtnhMu5tAs8tCseM4tAFhxxFkuTtrw25cvY5StJtktMJfwONX xAZ/th58yD+HyFZ5sXOFzJ6Gy8F+xuSEuwCgvRaktDOdzmKiyomZsaagxLmWyNyswga6ziaxuDPJ xlTIwY2ztaS/uvX19Z+bpox/gf8LAAD/Af/0CAYA9/8F/wX////1/yH5BAAK1VkALAAAAADIAWAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY0V7IEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSE96XMq0qdOnUKNKnUq1qtWrWLNq3cpxCtevYK8m HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPODcu3r9+/gAMLpqi3sOHDiBMrXsy4Md4TjiNLnky5 suXLmDNr3sx2sOelmj6LHk26tOnTqFOrXv2Us+vXsGPbY027tu3buHPr3s27t+9/soOr/E28uPDj Josr740zAPLGy6Pndi6Sur0A2K1bB0nd+fbr17Nj/ycpnrt47+fDVx+ZPXz66uXdt38vP2R8+ePX 66/PnT359vuBpx+A0hX4l0za2Tegf+B95x1K2z3IIHwB9lehggp+J2CA3WGo4YQJejihhSRKWOKJ z52VRoomhaihiSSi+CGGF764oY0XxghjjBtmKCKEP67n4IhC7ocji0j6NFF/IRZZoYtAEtkjkzRW OWWVO05pI5QpmbglkTPumCV4BpapGpbkaQmieffZB+B56JXX4ZVDlvQenPjRyR9+YdaoJnsA3ihl fmYWahqa/tXp5JUnZXmko1LqqKefczKappUNRhqkojGOdouht9EUYZqcUskjkEfSCGmOPa6KqZen 2v9JqaYW0sfjjEnmahanTX4Ia6OLvkohmC0Ge+qoglpKrKrC+sihrtAGteSxgbIJrJttstldenhG 6GB+sebJJ6P3jYqnrICCa62db47IKajwehatbPHWG9W8+Oar77789uuvTNP+K5S9BO9mWD4CJ6yw khIhLJLD9uQjMcQQg1Txww9LHHHFDiM88cckgbwxyB9rrHFIF59sMcoTs1xyxCN5bDLHLlMMUsE4 FwrzyjzznHJJHmO8sdA0A43xxTtnLDTLRC/dc9I+W1z01DfnbPVqMtkM9co/hwx1x0kjvTXKXsfs tdZk24x00U/vDLbaJom98NxDTRt02zB3bTbVaDv/7ffYa4e9d9plP93124QbPdvVjBtn+NlmRy64 23iPXbPUJL8M9tab3+00xyV3HjXFJzvc+Om+ka360ZKvrjXchaPk+equc0544LQf3nPQui+O+u+4 5Q753y9HzbXiKc2ON+y1K/+136If3zvw1ANGk96TAx755lIj37rzuHf/Ofe200751+TLTff6cK3d csZi/9wy6N7H/H7oI8+v9PiXf7+3yfvLH/nYR8ACGvCA0QoYAmlSvQY68IEQjKAEJ0jBClrwghjM oAY3yEGILPCDILRLB0dIwhKa8IQoTKEKV8hC3XDgAi0sUwhnSMMaomUdNhwLJXIokhj68Icf4aEQ /4dIxCIasS5ATKISGXLEJjrxiVCMYk6WSMUqDkSKWMyiFrfoRCt6UYlcDKMY41KDGozxjEisTRlr 8MU2guUPHnTMGtFIxxDOsY54PKAZ88jHotgLAG4M5FT6SMi5KRAzCbFJIgupGdRwZpEMRMgQP9AS SsrGkr7TykwAwEkAnIWTIvEkYj5ASkzao5SYNOUpURkSUorEla18ZSljSctWuhKWIKEkKlM5Ekuy cpW7BGYqbxlMYZrElL/MZS1lksxd4jKZsoRlMU/5SmD28pfIXKZZliTKtIAyJN28CSRnkshsUpOW qjQnLlcZS14q85zwrCY72ynPdMbTnO+Epy9Jgv9Ped6zlqp8ST/jSdBeVlOdAOXnQZdpSdSEE5yd BEknPRlRe1D0mxb95kVF2c2HUhScEtVoRCuaUYyKcpwAQ0hAC6pLgy50n7x05zn3WRKY0nOhOK2p P90Z0JXuVKGs1OUzZ0lNe7o0nwWdqU5xOtB/0rSaX4nJQy0aSqpKFKQmHclFsQrSqnZUq1YN60e7 OlWirLSnBLVnS4t6U30q06dKjalB1XoSfPJUoSiRKTpt2daiovWo/8TrWeeaVry+NalwnctUwzlW sYb1sVRl7FUXe1XINvarki3LMNeaU6Sy1aZuNWYuE0tT0PZ1pkRlaGpRi83VJtSleuUsWw3LUH// LtWaav2rbYV6zLRMhLJcrWxkq1rSxlrVuMId60QdO9mJPhSlMUkIXQlr29lKM5+lPW096TldbQb2 nQjNq2H/Glth3vK2tfVudWX7WcCOlqjsVaZDSSLZr07Wq8GtLHIde1nmDlcpkqyJdKnb2cL6srTY 3GtSlXrY7nr2u6FlcF3HK9ja6ra6ECYtgQ8L4Qc/NZZRlSpY84tZ/N63q5AVbkb5i2LjcpQs4QUv YD/M4bY+dbD3lK1MP9zPHXsYwz1+bY1nS1ujere8MfYxS7WZWLost7jJxeqToZzZFD9WpKC073FJ WtaiTLOZQW0mUDes42vqWKiuXS00M4zbYq5Z/7XrZKc64VtX17KUzrac5ZcPet0lC/kshxSxTLoM FOjCxNAhbDKSGnoamxA6JY/+CaJdMmkQKvo5mBSkpjedEUZ6+tM5bACoR03q63ma06hOtarBYoxV V6XUm+kBrOfigFnbei2uzrUEb83r4Oj61w7stbCHTexZA/vYwCu2spfNbDoG+iWRVnEmC5KYSr/k N0owlAV0JlWStiTaVnaNAMYtAJCQe9whKXe67UHuZm/mt8T99kqeG+DDJFLd5ma3SNSN735XDdkS BG5kR6rRkkK04Fa1Nl0Sgu99j6Tc/Hb4tAEOL0HHu7/Nze9/wS2Zhq/b4RB/uLvfLREon1jLLv++ MmQVvheE9BvdHoe4x/U9cYobytEnb7HK6xucmNN83SGX+MgRWXLiKlfnPNd4zQVSbZeL3OcR/7jN I1hllGs85S9eOnAQc2+QS9zf+db61E9n8ihH2bkHz/pJ622YRZ5b5u0Oe77bPfZ46YTjQ887W/Cu 975HMiI8YTljBH/oukfH74hfeNF1QnjFQFIbjHfgBHSN9hFTmu2XeTxJIL95bXje8yD5POcNf3iY VBmBnw9J6jfPetUn3jU8V25Fp8z32ED+9iLh/Eh07/rev74w8JbyiVF83H8bhOQHsQfud18S0XOe 95An/dWS/l/i0zv5jRTIPKitfN6HXiXL/77/9JXT7dkr3bm1Pw7ocw9+5bOf2PBAksCRm34Whd/9 Kbm/939/l+Bf3LJG92/HwH2ZkUi4B33vh4AIOH45M38hhWX21XhNh32r132rp3uip3qrx4DEIUb7 x38gOBYfGIIkWIIfxIEomIIquIIsOBVG0IIwGIMyOINLZII2eIM4aBh2kBw02IMM4QE+CCrbF4QS mINGeIRISBZEuIQH8hqckIRQGIVSOIXN9myVJBSXNk/oNRRZmIVncWELlhNZmGsxMU3i9WA8cWk4 FoY+oWE/1hZg6IUTNod5pl51NBFNRWFBoYa3JYc34YZsuBZxaBNwlVp/lYLZpFfGhGZ5dlZ0/2aI b9Za6xRU1vReusVTkNhnaaVnlXhgPfWIQxVnljiKTmWJubVZjuiJaNVSOEaGMJGIR8ZXQ2ZkftVX tEhj2CVXTJZQsHhTa/hMRDZjWlhm69VZrLheuoiGMqZTqKiIw7Znv2iMwtiLnhVjP2WLY7ZW1Nhe ffhSvYWNA3WLpRiO0viNhVhegThGeLhd0dhOZmheZUaOCnZUifiO7aWKxBRmdNiLoriNaJZm0+iN u+iOkYhnx8Rj7xRDtmAVCNWOQ0ZbSEWM6eWQwciM1gWRFflnEhmRpUiHHAmL8viQ9KiMDbZdYjd1 dvWNHVmN0jhMwohYFoZhEeaPEnaNsxiQ2P9YjDZ2jKOFkyy5jNnYYYgITecYWG8mWnMWX2JWU8R4 lBEmWkipXufFXaIYlehkZ0iZidY1lY2Iikw5VF/ZiLTkijjhh1S4hUgyBYthhWZ5lhjJg6tGhfHn lsPBhHZ5l3jZg0uQl1wBCHz5lytEl4IJYLuBAICZaoOZmCNxmIIhDymomJB5kgcxC4xZmT04UZZp PUPBBTWEfhgVmaBWf6Y3ZaQWD6AZb6d5lqKZmiC4mqzJf645GbImhSMESJl5l9fwFLZ5m3/RArz5 m6zxmsLJIiUgEm0wnHoBGT0BnEtIBsz5nH2BnFNIGmwAnUnkC0FEF2wgnQvkC77Ami8ghd7/qUiL pzDWWRremRV0c56ikZ6aZA/8EJ/8ABLyGZ8hMZ/3CZ/2KRL7SZ/6WZ/wyZ8COqD5WZ/9GaD3CaD+ yZ/2eaDzaaD4GRLsORjuyREyEaEBiqH4GaEcShIOiqAECqIiOqIPahIluqALiqEpqqEjyp1mMZ5p oaIo6p8bGqI0WqAlUaM1OhIqeqIeCqI92qI6iqM/6qJGAaNqIaMkmqE8+qMdqqRDKqRNqqRMOqNV OqA+6qM2aqQ/gaRrwaENOqUyOqYp+p/yWaY7yqAGaqb72aFLSqYIqqNryqVE8Z1vEaR4uqRNeqNQ CqRSKqB9WqaAWqRP2qJ0Ch0SkaeDKqJw/8qkVNqfB5qfi8qjCqqoWIqjVGp8E5ozjNqpfmqljKql NhqoRDqqngqnGiqqC7qpjEOfADqnnXqmIdqgsBqkRVqga4qnCsqm/xmqbLqjq1EBUkEBmbkHmCcw rHo165msjnOoOGiFzmpAgQF7sbkv0VatmtFl2DovlecSZdWtkFYT2/qtJsFY6AeAqFmuLPGZ+yVt KgZuhPZo6bet5aet6uqtxHd3flSe+LpJJXF6J0Gv4vqvBCtw6JqvBDtvAGt5qBlp3sawYCWwQHGt 9ypvhQcRnHQvROFRW2ZSWfawmfVkH7VcIjtwH/tiG5V2iwWBEDt8+aplCDt7MvuZwyd7I/9lcGX3 gBVrcKRJYjibstXHUeYntER7XzBrZSVrckBrsw9osyhLs9A2MPxqsRD1rgfbsDtnX/WVdSyWVQtL VgkbsfRleQY7YjDLsSW2tWDbsmTLtjWLWWl7dSsWblvlX+4ae14Ft2PLYsJ3VQshBQmRsXwxaCRr fVdruNRXfD57djuXrgG4t/+Xrkcbboqrco87siamX5BbsRwbtlxbfRtXuUGrrol7t/iVuO3KtVhX VRexmyFmem1LVpNbXER7s2tbs0jXuDFrfptrdjGLtPTFu7TbucO1urcbSvGKvAhrdqhbfLWbZcrb tLrruOe6UbbrskkLuimHEYLbEUVBvKf/97m/y7Cfi3Fdm7kHK75327OURa6RO7u5a7yau7PU665N W766e3Qt21+lm2Ltu7nmq7rTS7mwuxPcVMA6Z7jAS76WS31WJ780q7VhK20Lm7qxe7bki7kh1cAB S7+i+7IDHMDoi7vEC7F4K7dWx7fYK5kP0b2dZnFU+64zG73Lm71iJbwP3MDQq1Vc5lGFi7W9q7LS u8E5K8Mdq71Ve3D/SrLsWsJI7MDIi3A4S2Vuq7S8K7I2THtOa7XDJrGF4cWLAcb0MrXI0bOcYcZl 3Ha2Ea144UNs3H8xRBP2qhftuhOu6cOGIcb7ekGLEEdV/MNB7LgDG66CDLo+4bAPm3Mw/7xJiVzI 9vttM9vIaTfJQ6yzLNxBEyy5HuzIP+HEStcT8krIjzwUXzvKBCzKhtzBKPy4EmpBhFu7+9u4iVzC I+ux/zvLZju0Kqy1PWzLUFvDBWe9Slu8CCfJKAFcTMyyJkvJdeyy8ta8ekw36uu/WQvCWJtVmozN IIy3Jca4q7y8pqzB+CtS5xe1Yhu7GbfCv5y3xjy20IzGRjTN/yu3mkzP2yy51Xu6JBy63zzKoay/ UFzO/TrCdiu/qcy28Gq1zVsSEZBDNvy7C23NK1zEKZfN+jy64oy+FZ3J0gvQmZt07HuyseyAKIx2 8TrHAYvBEV1EEhzEBu3E0HzPEq3Ozv/LVfpL0+BMzUY7v7hr0zntwful0gSN0hxdzzhtysgqES3d u5e10RRctQFtz099wumLuB8tz23r0Yu700g9weor1P1cv8drumHtSW6sxUu8wzcLrversxXNvpZr zSV7tGfbyx2l1uUayfw8zApdyd7qbWhtxXZtv+dadiuLxb5MyW6sK9F8ytJcaK68Po3d2Gl8Rh0h DUxBCcy62Zzd2Z7tF+3AbW+cEoYw2qYtRZ9tnae92vkyD0eICZnXRkOY2sw527QtGEd0BSvh2qz9 e7zd26/328BdN5pm27edmcZ93JaZ3Mrd3M793IAJAtA93dRd3db9a8P9ete93SV0Ctz//d3gHd4c mN3kXd45BK3m3S9+kd7s3d5OdAjwfQggEd/wHRLybd/2EN8jod/5zd8iQd/6fd/4DeACPt/7nd/7 TeD9Ld/1bd8F/uAKruAJ3uAELuD0PeEM/t8T3t8a/t8RfuAS7uAX3uAGXuELHuD+beL4LeIcPuAQ fuL1TeIIruIsLuMMfuEG3uE4buI4juA63hgP7uM5buErfuBCfuQdnuMDjhIFPuMm0eT3beNE3uRH TuVJXuVGruRQXuQ6HuQl4eVLfhJUbuNXPuZcjuROvuJkLuVoTuZn3uUa7uVbDuZYruVFbuVoMRFW PudKjuY+judZjuQZLuYg/uRGPuiD/57mZc7khP7mia7mhq7oeE7niv7lJJHodG7mfd7mdY7paZ7h Zk7kbw7pU17ocd7odp7qPr7eMLHnhb7ll77pkb7pjx7rp27pPx7lQl7rdT7rti7rvM7rpD7qvV7i jG7qxa7pgh7rcr7rn17pxt7ngK7rpX7rYY7rql7pgJ4XFh7jIK7sSd7jvw7jMQ7ggQ7tZ07t0S7q XB7iIg7rwN7m267rf+7rPG7uHj7iQ17m5i7utH7n++7k6v7h9U7sBa/u1j7k/i3tC//vbqHnyG7s 8H7lxE7pwp7ufr7sf07v7C7tLZHpzB7ykV7t487nqA7wIH/o4+7sAS/w843w4V7sKv8v8RHP6e0e 7x3O6i9h8mFO6bKe8Raf8f8+6TNP4S/f8D5/8j4f7D9f8Oju8Qm/8s6e8jFP8fju9KD+8tEe80nf 8lkf9eAO5hMv9NtUckHe7NkO6RVv9WTP8kT/4zVP9dgu82Kf5a5e5W8/9MfO74tu94EO6/Su9aFe 8l3v9Bxe9y2f7BhfEjrf6iPe42cv4wt+9NPO9u7O4pSf6d4e9/zu7yd+7p+f748O5Zuv9XM/51ef +aOv+fp+8xgf4B7O6QRv+k0P+w4O4xv+7n/f9wbv3r7/+8B/qJQ9gX4Ma0rkuhN0a8d/QXIP4Vff +qO+45Af55If+pRP+NWv+7Tv5/7//vipf/3knuNLhPz2EhNUz/RsT/FYjvYs3/cgz+53r/Dqj/hS D/VwH0XDzxkIf/Ylv/JjDxD27B0SWJAgwYEFEypcqBChQ4MNHz6MyPCgRIsME1LMqFEjx4keRY4k WdLkSZQpVa5kWRBAS5gxZcrUBhPhxYYbP0LsWNEnz4g4fwrkmJNoUJ9Fleo8ChSpyKIeQQ6dubJV VaxZtW7l2rXqP7BhxY4VuxBnyKY/lR5i27an26lsd350a9RsxbZRl95M2/doVL9Sey4kW9jwYcSJ FS9m3NjxY8iRJU+mHNkmRrRGKS51qtmz0MAZOaPlOxdiyKmiRwImyjm0V9ixZc+m/10bpeWBEzfn Hezab1zVOVn/nZu3tN29T6mCHtz8t8DK0aVPp17d+nXs2f89597de1/QxzOrBf98PHnhvs9TfQ1Y +3v48eXPpx+9e+rAvPE71M+7fF3+5DIIQODY8y89qQBsTcD2jMsPuvoilHBCCivczjYMM9RwQw47 9PBDEEMUcUQSSzTxRBRTVHFFFlt08UUYT7RwRhprtPFGHHPUkawYe/TxRyCDFHJIIos08kgkIdxx SSabdPLJCPWBkkeNoknySiyz1HJLLrv08kswlZxyTDLLNPNMM8NUc00229QITTjjlHNOOrVz8048 87yyTj779PPPPqOIQk9CCzX0Rf9BD1V0UUY3FEtQQCOVdFJKb4yiUkwz1XRTTi0coFNQQxW10wFK /XRUVFMdcwVV/9GhMFNPbXVWWmtdslRb+1wn1xkb9fVXYLvidVhiizX2WGSTxTFYZpt19jZlo5V2 2lHVofZabBN7VqYetvWWzWzDFTfVb8vlEBhz01V3XXbbdffddMeVd15667X3Xvng1Xdffvv199+R 8BV44DQBNvhfIg5WeGGGG3b4YXsIlthMVuaF+GKMM9Z4Y4479lhGylKZeGSSS6aXF5NTVnllllt2 +WWYkV0lVGmI/fhmewB4CWeeOdZZZzAL6XloFX/emWikGzY6aaYXXrrpIJmB+kVAoP2N+WqsFZta pBy2VjdrsMMWe2yyyzb7bLTTVntttjn1+u13782lbbbhtvtuvPPW2+Ed9n4RCL8D15JuwukNCAA7 ------=_NextPart_000_000C_01C6F9A7.49646A10-- From kvxbbym@pernod-ricard-asia.com Fri Oct 27 11:07:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTIp-0005VY-9O for capwap-archive@ietf.org; Fri, 27 Oct 2006 11:07:23 -0400 Received: from [201.247.225.227] (helo=[201.247.225.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTIk-0001nv-DD for capwap-archive@ietf.org; Fri, 27 Oct 2006 11:07:23 -0400 Message-ID: <000a01c6f9d9$9429baa0$e3e1f7c9@ownerwam9o2stk> From: "Missions" To: capwap-archive@ietf.org Subject: certain actions Date: Fri, 27 Oct 2006 09:07:11 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6F9A7.498F4AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: ed68cc91cc637fea89623888898579ba ------=_NextPart_000_0006_01C6F9A7.498F4AA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6F9A7.498F4AA0" ------=_NextPart_001_0007_01C6F9A7.498F4AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Control Panel or Private Messages is Whos Online Search Home General = Community is Chat Faqs and Archive Upcoming Games Tomb. Games Tomb = Raider am Legend Reservoir Dogs of Discussion in Kane is Lynch Dead men = a Crossfire Midway Chili con Carnage Zendoku Current Series th = Technical. Control Panel or Private Messages is Whos Online Search Home General = Community is Chat Faqs and Archive Upcoming Games Tomb. Advertiser partners Weekly Education a Spacecom Tech Weather Resources = Mobile Email Jobs service Right in kit Press of room Electronic Reprints = in add rss feeds in Copyright in division Gannett is co inc Pocket Dont = leave. Tech or Weather Resources Mobile Email Jobs service Right kit Press room = Electronic is Reprints is add am rss feeds Copyright division. Equation = Negative a ads guide site am web Editors note Featured High schools = pumpkin toss teaches physics trig plus its plain fun sports in space = Markets Quick Quote View portfolio. Josh Puetz in reporting one them Some types errors handled in better = still. Faq Members List Calendar go to Page is Invalid Forum specified if you = followed valid link please notify the Jump Control Panel Private = Messages Whos Online Search Home General of Community. Help Center Level am Editor Hitman Hitman Blood Money Contracts Just = Cause Rogue Trooper Urban Chaos. Carolina no Kansas third open Floridas or creates own identity Coachs a = Corner is jim Boeheim Best Bets Movie review Babel! ------=_NextPart_001_0007_01C6F9A7.498F4AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Control Panel or Private = Messages is=20 Whos Online Search Home General Community is Chat Faqs and Archive = Upcoming=20 Games Tomb. Games Tomb Raider am Legend Reservoir Dogs of Discussion in = Kane is=20 Lynch Dead men a Crossfire Midway Chili con Carnage Zendoku Current = Series th=20 Technical.
Control Panel or Private Messages is Whos Online Search = Home=20 General Community is Chat Faqs and Archive Upcoming Games = Tomb.
3D"Family
Advertiser partners Weekly Education a = Spacecom=20 Tech Weather Resources Mobile Email Jobs service Right in kit Press of = room=20 Electronic Reprints in add rss feeds in Copyright in division Gannett is = co inc=20 Pocket Dont leave.
Tech or Weather Resources Mobile Email Jobs = service Right=20 kit Press room Electronic is Reprints is add am rss feeds Copyright = division.=20 Equation Negative a ads guide site am web Editors note Featured High = schools=20 pumpkin toss teaches physics trig plus its plain fun sports in space = Markets=20 Quick Quote View portfolio.
Josh Puetz in reporting one them Some = types=20 errors handled in better still.
Faq Members List Calendar go to Page = is=20 Invalid Forum specified if you followed valid link please notify the = Jump=20 Control Panel Private Messages Whos Online Search Home General of=20 Community.
Help Center Level am Editor Hitman Hitman Blood Money = Contracts=20 Just Cause Rogue Trooper Urban Chaos.
Carolina no Kansas third open = Floridas=20 or creates own identity Coachs a Corner is jim Boeheim Best Bets Movie = review=20 Babel!
------=_NextPart_001_0007_01C6F9A7.498F4AA0-- ------=_NextPart_000_0006_01C6F9A7.498F4AA0 Content-Type: image/gif; name="Fix.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6f9d9$9429baa0$e3e1f7c9@ownerwam9o2stk> R0lGODlh7AF0AYcHAAkACXgAAAB1AIB7AgwAf3EAegaJgsfGtcfmtJ3J9kkcAGknAHwnBqoWDLYf ANcbBgtKABwyAEs9AmNBB3k4DpI7AMQ5AOg5AABTBSprAENdCltcAIxiBaRdALJbAO1gDgB6CRWO ADN3AGJ/CI2BC5h5ALJ9AtGNCAClBCagDDiYDlaVA4eaCpekDr2SAN+nCADHBx+/AErFAF68AHbI C52+Brm8BtjICwDhABbRAEPuAFfiAHPoDZXhB8HsCurSAA4AOx4ARzwGM10AO3gOSJsASb0JR9kA TAsbQCQsTTkoNWYZTY4lQZgUQsUfROYfSAA1QysyMzVGOWxJTXk+TppHS8E6R9JDTAtpRBVjNUhj QVRYSXteAJhfS7RRPNpeOwx1OhOBTDp0RWeHRnSIRadzMrNxOOdzMw6hNieVNkmnMVmaMYWeRZWm ScKWQeiTPAS/PRO3PknJMVGyR3G1N6bEN86zPOq4PAjaThfrSEfZO13YS4fRP5HiN8bcMeziTgYA fSANfEsAglsIeoQAe6MAcbcAftIAcwAufiMhiUkmfFcZhYUfipogirMhiN4cjgBMgxFJeDpAeGlD d4VGgp4yjs01i+JIfAZicidoezthjG5ajn9ae6VXeMdii9FjewCLfCaMeEd7d1Vxf4eIgqh6gMty cdOMiwCefyqXiTuqf2GWfHSRd5qkjL+sdNmYhgqxgRHOfk6/hmHCi3fGea69ccS7ieTNeADXcRLR jkDoc13UjnLeh6XnfrHWjOrldAYBxhEAyzcAslIAv3EFvKsMy7IAytINxQoryi4tskcVtGgqznsi w64YvMAiteMmuwAyvxExvkJFtV06uXxDwp1FxbkyzeQ1wQxsvRxSxTpRtGZVt3dqtKZivsZlyt9V xQSCyhiGtDaHwlZ4w4p7y5SCtL+DteF8ywmXwiGdtDuXwlKRx3KSwZqgw7uoteWtvAfIwBjAzES2 uGjBzIfEzaS6sv/s7KOclYl8df8AAA7/Cf//AAAA/v8A/wD/8f//9SH5BADM0FEALAAAAADsAXQB Bwj/AP8JHEiwoMGDCBMOHKawocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQBvaG0q0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcv2bNC3cOPKnUsXZNu7ePPq3cu3r9+htP4KHky4sOHDiBMrXsy4sePHkCNLnky5 suWn6i5r3sy5s+fPj+uKHv0TC+mUwk7bBc26tevXsJuGiU27tu3bTlXr3s27t++OuIMLH068uPHj yJMr/c28ufPnu5VLX9xmuvWl0LNr387d5vXv4MMb/+5Ovrz588DH6hDPvv1rRWIfHphPv779+/jz 69/Pv7///wAGKOCABPI3VyvoJfhRgQw26OCDEEYooX8KVmhehAFMqOGGHHb4oIUgcpdhfSMeEMCJ JZY434gZqmiiiSieeF+MK8bYoo0wkmgfijDiSCKNPfLoY5D0ARmkjDomSeSKO87Io5IvJvlkiFSS 5lSUWKrIYpMvutjiflpiWaSTUDJZ5phjuiimmWamyGZ+br65ZZlhMllnlG66p+de8sWp5pd0oqnm mX/OmKWhZ8q55pqF+smfo016yaWhdxZa5aV0XdklmjpKquSccCJK6KGTvgkloIFGKmh/qDZa6qJ2 qv9q6J60Gsbpoqia6ueQRT5p4400zllookfWGGywlD555KBiukqosnHeWuN8tVYr2K3OSrupqWDi KmquuoaapqjcAhptt9qCy2yb0npKrbXw7oUtpa9uC2uow37qLbFh5lsuqeueSi+xbRoZLn3xJhyf Q+3qy629AfdLrpz+3itxvXVC+mip0fqrLsEHYCoyb+kqa6x+WvJqLIs4/tqsl0g+XOyysBrZr8ol x3wyfkC6y2h9Iwd9modEF2300REKrfROmiLt9NNQQ63w1F7JF/XVWH+49NYVNp3112D7R/XYroU9 Xz5mp10f2WxD9hDa9cF9QD50yy332fndXffceuP/Xfff9wHON+B/08133PYZTp/de59dONp3zz34 4Ysv3rjkIaMEANec04X5531/jnfgosOt+Oihk1555KI7jnjcoac++uyou1556aN3rvuloNPud+L4 Qf668L4XXzzryPeOuN2t43777ab3znruu1efnabEN5+98dtHz7zq4D8v/u++Z7897bJj7v3qeb/b 9vuXiZ985MnPHr36wesn+OOD730//bWrH/r4hz/8Me5+8EtgZeRHOgACz34QnN70Ghi+CD5Qcudz Xvlq9zsHwk2BICSM1TTIvtfB7nL3w2D++pNBAZ6PeS00Yev+xz4Pzsd6OEzQ+FL3PRkWUG8SbF8J /31YOgfaLn1I5OARfZjDJvqmaci7nOOCuDzDAXGFwWsc/7YIuwtSrn/hA6D/ujhFxX0whGjsywjV xsawJSQLToxjSnaRkjbaEWxyzKMe98jHPsIkjYAM5GX8SMhCZmcKBRGkIheplgtkxZCQjKQkJ0nJ Slrykpj8DSM3ycnCZPKToMRJJ7cyhlGa8pTWyQQqV8nKVrrylbCMZVFCSctavkSWuMylLnfJy176 8pfADKYwh0nMYhrzmO2xpTKXaRKiwAGZ0AQhM6dJzfRE85oJHNnmqslNuUwHAODEpjixEiJwbrOb 6EwnQcypznbCxWt33JBSHjTPeNrznviMkHTyqf+hejbIn/wMqEAHujblEJSeSUEoUg7K0Px8AEAP bWiEInqAfR7AnAAIGzjrk1EJAbRA9fyASCl6gJFSlKQlNSl9RFoflq60pSN9qUxXylKXzuehJj2p fSKq0pTm1KcnrelPgepQmNq0pDMtUE+BGtObNnWnTR0qUl/6VKdGtaUy3WdH07ZR+mwVQh8l0DxJ ylOsTjWpPCWrTnV607a6dadOxSpZ39rWuaJ1pmWFa1LxatazolRAdt3rX/uKVLuy9ax3PexUbfOQ r3rVnPPB6EW7mlHIRpayk+3oVh1bWa9eVrOQtWxmN3tDhGjtIIP9K071StWprraufHVtUQvbWrn/ wnWwdD1sXgmLH8XWNaY4tWlPX7tXxAbWrKm9bW7vM9fdvrRKjr0oR6UbWc92lbrWJS1pp7td63q2 ul/VbGkPclqDJFe5vF1tWdcaW+IyF7bwra183xtb2bJ2toh1a1DnG1z6Eva4Mj1va1GqWtsmtztO iW54savd6XLXwZ21j3ixC97vSnfBBV2og5QSVPfGl660Xe9b0ypc3Or3xATOL4lTTNOjrtilS+1r gf1q2/kW97gm9mtNbzvj/6a0qIx1iIIfXN0Kf1eyGI6wgy/8WSVrF6OOTUh5C5LiArO4tjAe8Yk/ rFf2Vvm+yw0wcvnT4xkrNrgqFfBdi5teFdOW/7dM5XJboXufBXdXyUw2cpHxXGQmN7jPfLaPlB2U kC+jV7CuzetQ2ercMcPW0Df2sZbz69/6inm5PYYzjvcDafgCmNKNRmqVKExhJ3v31HkGNH7Ca+o7 l7rIg26QlA3r6DVb+dC7Pa9ajdteSU/avr5e86+bW+NKXxnENObvsC8tY7iOerRNVjV4JRttDJO6 z5OttoVBe92OxppBg5bqUn8q7vd22r0E3jFN42xUox67uUIdblX/O2916/eqDp03qPFt1XgLV65Z BnWzMxeiB0UXQAcv2rcLtHCJHjTHDvdQRJdAJYMXKOEKNy2hNR7xhkK84xOiKILHSXKqufPk7f8s ucoThvKWu/zlMMfkymdO87wco+Yrj7nOaYnznvv85+2JgnR2TvSiG/3oQQO60pWD9KaH8moNP2jU Ge50ScITaWE9aNZBuvR4rZFAGF/yeA3S8akTqDwMqXpLrkTtAIXdwu47SsfrKYC6C2A+dq87fe6+ 9wPYvaJdV6C1//N2bANeww6fJ9/x7vf68H3xkI974GnV2Dpnd6OWrWy3Mw9rjks0IYt3vH3u/njR E1zthUyw5fX8ZFTnuaNbH6hSQt930ZN+9JKHpSNdKZ+2R9jVdiYyfcwuUNDvXe+0Jz3tG3961GdS wkYGvvBTPfaClB0hyWd+329veuc/HcLUlb7/6/lM/IAa3/a4L33tvZ/6pljb1Xqm/u9zT5S5JzT0 3Ge89iN/+MlTnmFtx2DbNlqbxXnUVX78NGh5p3x/p3+M93fsdxNsQB76UXjg5nkNhYAAEoF+dHWG 108JFXGxNyD+Vy1fByEaCHLVRxAdwoGQtCEpqIIxKCAuqCBEYBIwiIEqqB+xpg0TEjQQUIMaAWWr FyAzeH3kNR8+aB9LyITa8IRPqIRQuIJCmEeDR3VJuIMGonFTKIVNWB9fqIRg2HxVyDWq512/l3mi BXshqIX7MU8+GIdjeB9heABf6IMlmDB2Jl6cBX79ZxRuyB9waId0iB9QGIWESB94SBb3kIeu/xF8 8fdqGSZ3gagf9YSIc7gfcqiIf+iIe0KEAshZoIgwbViJ9+FPmCiG/LGJYuiJ11F50BeJYXeEEdeD iaiKmniLhFiGfTRksuiHtOhwUiaHdziHxViMvMhHvhh+athtVCgQppgfg9aFdniIuGiNXriEydg5 HrhhpRiNpIh4dfhPWNAW9OCKh3GCU8aC4ChoHDeOF7iN8jiP9FiP9ugRy3CP+ohO6NiP/viPgVcA ADmQW7GPBtkcBJmQoXGQXBMAMKeQEBmREjmRFFmRFnmRR8GQGskd7diRHkmDG6mOHzmSJEmGIZmF BPJxD6KSP4ZfSMOSLBk2mUZpGsKSIekUUv/FaWxWk/4hYDE5UTqJbD/pNDM5lL0VlC2WVf/4EJ/m X0Y5ICrpk1CTY75lT0W5kvrxVDN2kg5BbCCWZj7VYql1VVoZY/12lmJZWCV2VMtGVGjpW2CJb/o2 XGGJllAFY/z2Zjmplh02litmbm+mVzfZFF4pcHH1Ye/WkoHpZswmY+yFaFpWmHp5lIcZYi7ZX4gJ ZpKpXun1mMjWmMVWbp3oiUw5bjR5ZrzmY5t5X6GWbJmpXK+1mh5maZxJmZkJYIlJbLhZbDS5Zb2F mlOVQ5tAE0EwE7QmlVS1lzmFbqlpa7YJb2ZpmS+GZsBlYqiZVsbGa8upmbxZm18JcNFJl1n/6Vx5 xZUNcZzPyZuVhmltBpq/tphHWZszCZ+02ZzsaWPcqWzMqZpI2ZoD5mjmqRCBhVvX2Z63uW6Shpyv yVoFimXpqWz8CaGQGV87tl8R+p2+CZv2aZL6iJMxZp37GZ1uaVj2lpaf+WMkypa0WZYBd5rMiWa/ 2aKJpqIjyqJ6WaLs5pZ3aaF3aaKLtZQM45IlOaT8ZJMb2Y1PSaRKejUsCZAB+qRQGqWj4QxSahCP 8AhVih7QdKVXipGxUXVciqVZOqY0EaZk2h3NoE7KEBFceqba0Qxp6qZy+hFOAafN4KV4yhUSAadz 2qcpwad+GqgkYaeCWqghAaiGmqhaAad5/9qojvqoeZGokroRkFqplnqpmJqpheENmtqpawES5TCp ojqqDHlOJOGpEAkAbkGqKFGcO2eqJTEcmICqn0irtsoXrJqrurqrJbGkGsKreeSrPwisS9ONwipW neQD/mg1/NCs/DAfztqs9PGs03oAzmof0lqt0Sqt1Aqt9dGt3vqt1rqt4jqt0Vqt38qt4Pqs2wqu HDpJPkCm1iqu6xqu82qv5kqv91Gv6Nqv3uqu2uqv1AqwA1uvAAs0GpkBCruwluQUB+uu7IqvBHuv 8/qw/4qvGBux+KGxFHux2OqxFbux9OceyIAbC5sBafQQFquvELuvFMux5aqxE6uvItutLf87sxwL s+hKrHFks9z6sdlarjH7r+R6rzK7r+06ruf6shnbseE6sES7tMPHs0LjsEB7tS37sRdrsTbrtE6r s/YKtTQ7tFv7hrfqHip7tTTLr0IbsQc7rvnqsmObrtf6tV4rtiH7ts9ItZzTsTCLt12rtdAKtk0r twEruCBrtHK7roRLrRwxB3x7HoN7rUXrt0qLuOoqtVmLuBVLrjeruedKuemqtHXruJErMsZ6rAJy tmgbpKq7cadLEbgAHan7urZ7uyDHHri7u7yrgsYhkgJ1Xb07IYVnga+bcMYLu0FzcQFIeKvWvBXo IMnLHweHvBwFZXzWh9RLeJBYhGJngRj/F3bT+4FOA73ke23be7740TVNcXENUr1iF71mA7+Wt4yk pr37YbzCK76rFr91Jryx2L/jmzXFmx/jO8CjeRvAm76n5nuYJ1rYxm18CG3U1llIhlmaV4AQ/FnR 5r/UZ3jdBXccDG0kLHxpGFqZ1cGPZb0rXMImnMIXhsFHxnncNsIWLMLVa4AVDMMnrG0knMF7W3Fg J2ET9ovei2ead2TcVcQN5oxX6IcBPH0gLMLou2dw14dNvMRKHMX9O8UGzGCtV2F/Nm3nm8QC6L/B t4fZtXpjHMOexb5MwbwoHMH328Xxh8R0DH9+Nn3hS77LiL/S5sFWTMd+eMPj94FvF8JV/7xd3ft6 4ffCAizF15bGfIy+TPxqC6a7Q7xkSabITSbBmAfFqSZ9jaxgBsjFZ0zFgTbJp4y9AXzDpezHffxY VCxtsTzBBIjEGozH9vvJFkyEpdzKmDxdmjwg+Dt4RYzGR5zHAyjGlczJfvy/Gzxk9NvMngzNhnzH 6svCony9pyx/j5zMiByKktzLHzzMtnzImVwcvWfMr/y90RzFeIzOqZzNo3zM8YzDylzN6UzIV5zN obzFdozK4jzFt9zMkTjKdTzQw3zQ/QzOCwbHS1HF+SvPzXi9qPzDnCzMqjbPc+zNBUjEH+3PggyK DqzC/8yM9hzSLSzND8xqXMzLkNzBGv+8wtlbgc04YRW8wzZNyxJMx8U8vAgciEPdkUUNNr/rurhr viPJ1Md61HikNMM71bfrcrVL1VjtkeL0vl/MUKusIUctihIF1WGz1d4r0l/Nv8TbH4AsyRuSyBsc fe5rcHEtyOrrHzvt1CXswPvbVWad0Qt91oBNNG3teh2i1vJ710XzxLXc2Hjt1gMt0wI9srjUe5Q1 zfX7YHENyL9c09AHxDFN0woNf3y9y7Ms0mIcWjQcwzoNwI8dixd82Ri8eTIcvQgs2Qlt1e072aqM yYrM2dnmxWss3NoM0PVMz+Dc1V88f759WYZ9wJn9zsMN0YlMgAiH3Bns19jUzeMcy/H/6936fIXY K9O4vMfJjNsUzb/M3b2NTNHKbdipDNGQXcvgy8yHDEyWjVmCjd5t7d3NO8/hrdmst8fYLYkMrW06 PdOvN80vTdCTfMW+jWQ4/d7PC+GxrNtMwcgHzt+hrc4Brs+VPH9ZfN4FTuHknOCoRsmKvd8Pbt8J zc0H/t0hTsyUsQjXoeEM7WQALtwBPeDP/OHOzOMWbsIFHdiGTOIhbNwCkmRF6NAJ3eKDrMwe7llb fdIurdKs7domHcqdDMA7vtA7/Nv/TNs1XeQ/jMJMzNHRV9dsDcFWntdkLstwrspbHucd/Ne8S9YM nNUMoueWuN296+eJzedz7SGse+iI/57oir7ojN7ojv7oixS7ugrplF7pFCnpZBoCmL7pAmHpmcrp o+rpmPpJtQDq2yHqqJ7qqr7qrN7qmrEHnmTqkurqtF7rJBe5/iDrur7rvM6Btk5zcTAWvT7sxG4h 33Ds5PHrCXPsxy4cC0zo0B7tR7O80l7t1j7tI3Pt2r7tv3oemnII4H4I8xHu4E4f4m7uBxDu9qHu 6c7u9UHu6n7u6A7v8j7u657u607v7S7u5W7u9f7v+q7v+d7v9C7v5D7w/P7uA9/uCv/uAX/vAu/v B9/v9l7w+x7v7m7x6C7xDD/vAH/x5U7x+K7xHC/y/H7w9t7wKG/xKI/vKk/Zm8EDy//BMP/u8ilv 8Bt/7za/8w2f8vO+H/U+8vkR9Odu8jgf9DuP9D2f9Drv80Sf8ypf8/gh9T+vH0hv8kt/9VDP80K/ 8Vhv9FyP9Vsf9Qov9U9P9Uzv9Dl/7kGj9Gfv81zv8kp/H2jf9UMP8Xf/8kVv8wnf9HE/9lCv9Vr/ 93uP81O/9HZ/+HgP93XP935f8Xr/84Uf9o4P+Dfv+G9f9lbf84Zf+W2v+JL/+JffH3Xf93lf9XSv 831v+qYf+EC/+WPf+pCf96x/+jwv+6Jf+67f9E+/+Jd/9HKf+LOf9opf+5mP+qm/9pq/8VraFAYf 8hA/+Lzv7sk/7gEP74+P+3Af/JP/X/mBj/0I7/eCT/dzP/p7D/ogH/LgL/HxPvqMj/0tv/Wdf/6T X//w7/5/H/zc7/s3T/1JDxCHBB4gWPBQQYIHD9hj2NDhQ4gRJU6kWNHixYf/NG7kuFGhwQMfE4Yk iVAkSIQjU6pkOfJkypMHX7YsqXBgTZQ5S67kKdLnSplAdwrdGbSnSZhDiSJ1yZQmzqROP9oEafSm UalDZ6qcSjKm0pc/UYaN2tHsWbRp1a5l29btv4tf5bacWZen1qRbaWKNOjYh1ZACb+rUuxRvXqJb AXu9K7bq3addHSst2vevYL9NbVIl21RnVMlgRVt2/JUpRtSpVa9O3Rav2K5Poco+//wYcmXKeyOP pnt7smmWwO1qVezUc2PDg2vnBD56cWDKfOlOBm2Sb+zZy7HTftvd+3fway9eHih48E/M1jcrJ53X fN3z5o1jJtvc53ug6T8HZi+fOn3rkPtMJvzUA9Cg3/D7zTivyguwPgUD3O8y4vjrTzn55tPwNNY6 jGgED0PMiK3bSjTxRBRTVHFFFlt08UUYY5RxRhprtBHG8HLUcccdb/TxRyCDFHJIIos08kjIeFRy SSbPQvJJKKNEsUkqq7TySiyz1HJL8SyS8kswvxRxTDLLNPNMNNNUc002HQrzTTiJbHNOOuu08048 8WxrQcLem+rACTMs8DX2LDQwOf/98ouPQfJgos9PRddLTyEuK7X0Ukwz1RS8uDZkzDLedrONK+aS 623U7Qj7i9HSBDS1uoXylHVWWmu19daGcHpOuuV0Y1S0XQ0T9VPcWCW2ueOEdTU4gnB19lloo3XW Nc5662xYX0ENCtnolsIq1W6/BZVYZY/K6oBN01V3XXbbDW+8aou1L9JEi3IQqULhuyqxserdDTBu eZ1QWw6lNfhghBMOkdrKsJuXYAal23ZcxGCFajh8R/0XssLyZcpdkEMWeeSQVzWZvIcjJniuXoXq rEBw69M4XI5rFpZSknPWeWee2xqPt5SzxfY6Zoc+leXcYJPQ0+LMLTdWhaOWeur/qF0Duj1H7w3U vwwJDSvRrpFOWr/7eqq369ws3Lesntt2+224/4lzbrprjPtuvPNWt26++2ZRb8ADF3xwwgs3/HDE c6Z6ccYbd/xxyCOXfHLKK7f8cswz13xzzhHOQvLEQxd9dNJLN/101FNXfXXWW3f9dZI32LJz2mu3 /fbMYdd9d957T5wW34MXfnjiizf+eNJxV3555pt3/nnoo5d+euqrt/567HHPJ3vuu/f+e/DDF59N 3ltB/nz07x5/ffbbt7U7AABIf3766880fvzt139//jcSEX8AGAwS7iNgAZ+HPwMmUIELZGADHfhA CEZQghOkYAUt2L1AXFCDG+Rg/wc9+EGL9E+EIyShWkB4QhRSroQrZKEIU+iQE7xQhgojg5mmMEMc 5pBMLeRhD9OnQyAGUYhDJGLnfHhEJApPatooYhMbyDNtJFGKU2xdFKl4RSzuSGFMdGIXvbgaLrLG BV8kI/SyeEY0plGNa/wHKNj4RjjGUY5zpGMd7XjHI5bxhQF03zf0+EdoxQ+QHsLjHeVXSEQmckfx UySPBjlDPj5Skl0U5CQp0khMZjKLGdBkJy9lSVCGUpSjJCUjSHlK6nlSlatkZStd+cq3IACWLkRl LW15S1zmUpe75GUvfSnBQ/ySiLMkZjGNeUxkJhNv21BmM535TGhG8410kGY1RTQmTGxmU5ub+9w2 vflNhVlTnOMkZzk3MgxzplOd62Rnu8D5zsodw0ztpOfu4HlPfOYzmwEBADs= ------=_NextPart_000_0006_01C6F9A7.498F4AA0-- From fzolodxryl@perma-fix.com Fri Oct 27 13:01:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV4n-0006TH-J4 for capwap-archive@lists.ietf.org; Fri, 27 Oct 2006 13:01:01 -0400 Received: from p57a5ac07.dip0.t-ipconnect.de ([87.165.172.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdV4h-0005Gd-VW for capwap-archive@lists.ietf.org; Fri, 27 Oct 2006 13:01:01 -0400 Message-ID: <000801c6f9e9$7f33b870$07aca557@kromm> From: "classic" To: capwap-archive@lists.ietf.org Subject: Minutes Date: Fri, 27 Oct 2006 19:01:08 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6F9FA.42BC8870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.1 (++++) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f ------=_NextPart_000_0004_01C6F9FA.42BC8870 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6F9FA.42BC8870" ------=_NextPart_001_0005_01C6F9FA.42BC8870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classes Thank making Pamela m Johnson ldquothank game enjoying lot = parents of. Visit department head action is bring dollars into community = pleasure am be ask or Tomorrow well is talking. Classes Thank making Pamela m Johnson ldquothank game enjoying lot = parents of. Shot all am kids costume Formats mov Leave is Comment Permanent Link = Cosmos Tuesday el Reopening Playlocal or residents in and officials = turned out celebrate am. Revamped a interface official Microsofts graduates Explorer vs am = Firefox Both released updates better ie Scissor Sisters flamboyant = flirty defined of sound Feel is Dancin or. Kiboearly weblogs manually = websites evolution facilitate articles fashion of feasible or resulted = distinct class produces recognize instance sort aspect blogging hosted = services Wordpress blogger coined Jorn in Barger or. Instantly friends yim am custom avatars Pctopc calling lively emoticons = am Advice tos thy. Guide modifying or werent am do covers teenaged gp or simple complex in = requiring. Retro series system update addition Svideo creating lefthand quite = concerned mod chip discussion installing a Xbox authors a discuss or ps = memory card in items However sections. Know will give ideas or recycle gaming consoles Chapter Tools Trade boy = Advance gp nes Basics Coding is Operating. ------=_NextPart_001_0005_01C6F9FA.42BC8870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Classes Thank making = Pamela m Johnson=20 ldquothank game enjoying lot parents of. Visit department head action is = bring=20 dollars into community pleasure am be ask or Tomorrow well is=20 talking.
Classes Thank making Pamela m Johnson ldquothank game = enjoying lot=20 parents of.
3D"youd
Shot all am kids costume Formats mov = Leave is=20 Comment Permanent Link Cosmos Tuesday el Reopening Playlocal or = residents in and=20 officials turned out celebrate am.
Revamped a interface official = Microsofts=20 graduates Explorer vs am Firefox Both released updates better ie Scissor = Sisters=20 flamboyant flirty defined of sound Feel is Dancin or. Kiboearly weblogs = manually=20 websites evolution facilitate articles fashion of feasible or resulted = distinct=20 class produces recognize instance sort aspect blogging hosted services = Wordpress=20 blogger coined Jorn in Barger or.
Instantly friends yim am custom = avatars=20 Pctopc calling lively emoticons am Advice tos thy.
Guide modifying or = werent=20 am do covers teenaged gp or simple complex in requiring.
Retro series = system=20 update addition Svideo creating lefthand quite concerned mod chip = discussion=20 installing a Xbox authors a discuss or ps memory card in items However=20 sections.
Know will give ideas or recycle gaming consoles Chapter = Tools Trade=20 boy Advance gp nes Basics Coding is Operating.
------=_NextPart_001_0005_01C6F9FA.42BC8870-- ------=_NextPart_000_0004_01C6F9FA.42BC8870 Content-Type: image/gif; name="claims.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6f9e9$7f33b870$07aca557@kromm> R0lGODlh/AFwAYcIAAALAHsGAAh/DXGFBQMLe30AhAx4h82xuczQw6LQ7DMkDWUaDIgZAKAcALEX ANsYAAE8Byk3ADsxAFM1AHlCAJ1NBc1DANNNAwBbCRVuAD9gDFZUCn1rAKplAL9RDNpuCQB/ACON AE6ECV9xDIaCApF2AM58ANt9DgCWBxSfCjuYBlehAHObAKOoALqmANmgCADNBinKADvFAFXFAI20 AKXLAMXKANi0AAnRACbnAEncAGHrC4DrDZjXAMzfAOfuAg4AShEKQEsASmMDSYoOQKkAP7kFSt4A MgATRxQfMkoUS2wpPn0sN6UYPcomSNYWSABEMiM3QUVER2M7Q3gyQ64/QcBMPNszPQZuQBJpS0xf Ml9hO4JtAKBuPsBZPOFePAB+OCKJSzlyPGR1N3mMOKaESb2NQuKDOwCYTBWkTEqXOF+gS32pSaym S86dSOqZSwDOQSi9RELKNWPNM4q8TqvBS7PDP+bBQwPtMibuTEXtQmbUQ3HeM6jcNMnrTubeOwQA ciwAeD0FfFYAcYQAgZ0AeMEAjOMAcgsYfREXgD0YiFgkd4QbfagliM4RiO4hfgA3gSE5ikNCh2A/ jYkxgKY0ccE5gdVAhAFthhlfcUlmfmdSh45Vc51her5pdtdsfweKgBiEjER0f2qAdo12cp+FfbqO feaOhACugiWrhzqrgFmmgH+YjJOagbergtmeggC4iSPGi0K+h2vJfYPNjKe7esDKd+q4fwDUfx/r iEbggGfbeoTZdpTWec7md+3dgwsAwBsFw0UAzWIGyIELs5cAyMsAwOQAzQAewxMkvzQfx10lvXkm u6wdyrIfu9wZugBIxxk9zkA9zl9Ny3Mxxa4+x7ZItd84ugBrvhNYzEJtymJfwY5fy61lwrNZxudd uwB3vSFxvj+JxF+BzXmHx6p8vsyKwOCAtQiqyRqRwjSayVOUtHictKmdwcuXxuqSvAC0tR/NxkjG y1nIx3+yspnMsvfx+peaqoyIg/8MDAD8A///AAwL//gA/wD5//7x9CH5BAAH/YUALAAAAAD8AXAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePDP+JHEmypMmTKFOqXMmypcuX MFE6i0mzps2bOHPq3Mmzp8+fQIOOBEm0qNGjSJMqXcq0qdOnDoVKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzPaGqXcu2rdu3cOPKbYi2rt27ePPq3cu3r9+/gAMLHky4sOHDMaUgXux3ruPHkCM3VSG5 suXLmDNr3sy5s+fPoEOLHk26tOnTqFOr/sy4tevXsGMHnYigtu3buHPr3s27t+/fwIMLH068uHHf q5Mrn3u8ufPn0KNLnw58ufXrG2tKD0C9u/fv4KHL/x5PHi332+cRBFifPn3t89zdq1fPfn3u+u/r x9dPHz1u9vTxhx5+AQIoYIG2EVigff41iOB7/90HoIPzNThheRhmmJZEFXboHnwRzidffL192GGC ElIIoYoooijfiSuu2F6Mu81II4gqmgihjhXOiN2PQCLlIY07hthijyXep2SENuZYo38vjqikjS8a iSOURhLpooNRIhDkl2AmpJ2IR27ppIxJZqkliWuqWSabZ2KJpm9wdikli0XKGaGGfPb5EgI3vTml mlQemOCE+u2HH45d4rlgfosuOuWEC1Z5op1uKtjkmuf56emnPgnKZKZDBgdnmTGeSqSlJjaKKpml 0v/JoqqWzgnjnbWBquuutN046Kyx/qYqjEO6qqWvxhJb57FLtomrbvApuOptYVZrba+3cvkqrMRS OKyxDMaZ5bfNImlrmqIGi+y4vV3r7rsKvSptgLx9aCik0UYq6aH/hdvto5V2qymU98pLKaQ1Isou hfA2rNyY4UUs8cQUi7frxRizVPHGHHfsMaAZhyzySB+XbLJzI6esck7Ynuzyy+06LPPMFkHscj4w 53zbyjyTBEXPKU2E821DI5DP0UUXXZvSRBN9tNFKD40z0lTnVjXUVVP99NO2Mc310l0jHbbWRuM2 9dZRj510bTS37XZUNJUN9txze63b1E1DnXfadzf/zbTcTucd9t6C0w143UvzrXiuQDfueE6AS231 4ZSDvfjak/dtduZ+d7352n/zbbjckoO+29CPp954r3iPXrbdk1/uOeeb11645bN7brrth8Neuu6n s/328MQTBLHowN8e+eySV+584lxrfXbWiBP+Ou1RS1/979DPrfr34KeUe+Wtj0835rvzzlv55i8P +/WhF+77+ddbH/79+I8f//tqo5+8+sGLn+3Y5z7yya92zYMfAhmHvwYaRg82wRb/MGdA62VPc9ir oPwmmEDKIY90hove7YpHwhI+pH1XGxsGLbe1wNHObGLDmti0d8ENqi2Dfmvh4KAnQi+Z8IcOs5nO /4boMgca0XFETGIRj8hEDAHxiVCMohSnSMUqwqWJWMyiFrfIxS568YtgDOOnrEjGMprxjGhMoxpJ SII1umUQbsSMGOdIR17F8Y54dFcd98jHPvrxj4DESR4HSchCGvKQiIQMFRLJyEY68pGQhFdKvhFI nrCikpgESiQ3yckrZvKToAylKEdJSp51opSoTKUqVymYTrrylU5h5XgiIcuMwfKWuCxKLXfJS5jk 8pfAzEgvh0nMk7RMid5JCHSUicxmOvOZ0okiNLvDTOdUc5rYzKY2qfUuIW7TOOJ7Tji/Sc7cfEA4 5yyndNIJsvvVBgDwBMDL4HkbeU5nnM0J5wf2yf9OBPCTnf305z9ts8/bFJSgBuUnQhdK0IIetDbn /CdAcZPOgQpUohcFqEMxmtHd9NOiEGXocUAq0YeCNKEH5ag/DXpRilr0owsNGW3smTN62oam0bnm cZQJ05UuNKA9fahAETrRkPr0qCwdKlGTClSk9tSoR62oOZNKUZEWFanFeSpUtzrVpf6UoQF1alST GkWc3jSe70QrWhEgz7Wy1aZthetNcdPWub7VnvGMK03zaledGichYcXqSpvK0oiGdKJXlapgjWrY w1a1qYHdamK5uliqhjWiCsWsRlOK1ctSdbGKrWphJdtVxwr2nJKkiVnZWk/WvnOuNnUtbPcqW7P/ 1vW1raXta3GKVwaaxGInCaxnCbtUqSIWrKbVjXG9ytzklnasjH2uckUaXYgel6ieFS1puyrcx3b2 uYbtbgNXy9vawra1uUXvbdWL2/O2d72yTetJgGuSzZ72u6NdLnRJGtnq6re5Pj2pUxX6U44KGKrZ vepgRytdsVJXu5l9bHY/i1mPtjN85E3ve+OLV7WyN8O7TSs9dcvavMaWcfAsCX1LAtmpEte0nN0v gisb4OJ697Pbra6OLQxh7lo1ow6drnYdzGMAh3fI1iVwY6sqU4mAOMQbLi9ty1vi3EzZvCSGb24I As+BLBMhLb4xdRsbYwN/tbKhPTKDH6zVydKY/7IK1jFMJ4xjIr85zF7VKpz3LE3bahjLf4YvidGb VkBHmb0+5DIA7PHlgzg4qEMOrZFlTNkaN5TIRW2zZc9MYfBumrRzLjJ+2fxjSM94x6dGqDTv2mG5 RpmvIha0Xelaz1avV7ewdi1CVlscZqqUv5klqYvFvOAxB/nSKk0ySl88542+lMDghbZ1H61k3hz4 stVuaLCh3WzF0rmoq3YOr4Mz7oj5tdcIUae637xu8KQz3M0pt2/kHZ5zE8fe7Z5mf/PdHXYGszJd /rfAB86QRRP84GoppsKLaUYtIPzhA1kHxKECx4lb/OIYz7jGN85xyFig4yDXyMK3coqRc0UxQP+j hclXzvKWu/zlMI+5a0JO85o/Eg42T00rOvMxfGfT5/fOuSG9STF8ltPoKJO5SYKwx2MWh97tFZ6j 1w304Qh96HHLtXCgHt8Lq3jd4RSA2AVQm7GL3TZkRzsCxu51pfdxIlTeOnDMWnVoKjPtZV/7bdKO 975LHSINuLoUa/Jkvep1t7GFdW/bTjKwowTve8cN2fkeeca7vY5wt7J7sXxl99qz7s9MCOTVHvnJ S/7vgn9IGKKonVzfNsscjr1Zkf7NlPT97KOf/Oj1bvnLz/GYvV28oaFMfNQTpN2iP33u9b78RKfe lbSusnmLL2u6p5vqCFm+9vNO+ufDMu6wp77/7HELemfevfSV9zv3JfMP74eJ1YSGvYnP6urPX1/d zDS77tnO/byz3f13RHRR1x20t00FCE6+J0u7wXX5hBLtdoDFkYB+5HSNZhD8FhzlF3SjkQ4A2BYC mHTzdYG/AYEgKIFdRIHPkYHId3/aQB0dmEjzF31Wd38iyBvV1IK4gYM5qA08yIO10YM4+IKIFHfN oYLYN3U9aBtJmBs6qIS30YJCWEWEl16vt1au51tfV4O8IT4t2IVPqBtN+INfaIKhJGXBJ4OuZU8k WINciABh6IZgCIRi6IRk6EWZt3laRoTOVxBaGDNI+IZvyIRw6IRRaEgx2Hn051bG52V9uBs3/xiG gZiDgyiGhThFUyiDedgbayiC4+SFTugbniiGdVgWA7Arhdd1VKaGDtiIutGGoTiJg9iEr9iCo8hF dxh/sZaL5EeDrGgbzLSEbiiHkyiMweiDe1iJP/SBDRiCvbgzqwiLK1aLK6MPVeEdm3iBnUgd0qhF yNiN3viN4GgP2ziO5EhKTFCO6JiOZBiO7NiO7phz6hiPPPOO9FiP9vhw8piP+riP8niP/nga/Dge EBCQP9GMBnmQxEGQQYGQDNmQu6GQQOEc+7ZOwSFUSDYxE/lgyERn7AYdGYmFEFkSE5Fs1qaR/QYc 3VVpEbNvcdaRH8ORH+kbLOlS4PaPA1ETev8mZC75HB+Zkjs5HTOpkkkEkx5pbSbVVSHpE6HGVQOl WdomXNXGbdemZNLWlC2VZBOWaVIZY50VYdkmbVh5WCYFlmHZUWJVUQLmlGVJk2tpYymZlCgxkmuW ldfFlIVVl6NmaRCGl8TFl2dZaRplYzo5WH6JY0vpWHp2lDnJaWL2a4tojzgpbD55mHm5ZMVml4yJ XM01XMVGmWpWWqEWWZ5pZ5X5l4m5ZjQmaS71Yz4Fl8YkEZA2mXeZlhg1mp0GWqVGkgtGZrXZmyUJ atMWaWdJksxmmoY5m2T5Ur3BlZZmkxYRmzpJmQ1mm6wpmwA2bGQ2nWhWase5mXcmnKHZnc7/BZpC uZtM9ZjO2RBPJZrcOWaouWQWaWo95p3kCZx5Fp3vCZ75KZ6XGWSB2WmniWpuiWMUgQzOmWz9dWyM RZZmGVQK+pQm+aBoaZGauZbKCZiWGV4U2qBMxaDPNpZqFmHLtllQOZbKBaI16ZwfGJMO2aI6E5Ou aRIoyKIuWqMuE5PpKY4xuqM82qM+uhM/86OjmKNESqQTUKRpJKRmMQl1CAdK+qQqkxBEgKRUWqVW eqVY+ktQuqVc2qVe+qW8dEiUkKVkWqa3tAsXAaZqChZm2qZu+qaqsaZyyhVwWqd2eqeakUpnMKff g6d+mh18Gqg9Mw2Cio5/eqiImqj/OAeK/2odymijCFioWYSCkLpTjZpHlTodl4qpCMAPnsoPtfGp nmoboEqqnTqqt4GqoXqqotqpqfqqsGqqoqqqrkqqrbqqqTqqtAqqs1qqvripQKQdvuqqw1qqvnqs ubGrtRqry9qszsqruwGtuIqrw0qtxeqsuCGp3CgR1Tqtq2qszPqtsqob4AquuFGt0pqsy4qu2Fqu 46quxwisaNStz0qs56quyEqv7tqu90qv9uqt/wqr6ZqusCqvyUgTx6qr/dqtDEutrPqpDmuuuTqr D4uqyFqvDVur5UqxzqitTTQR7Bqy9Xqv4qqv68qvr2qyDpuy8Jqv2MpNBktCNSGyLNusGf9rr/6q qrRqqjV7rrdKswI7rv4Kkuq4BTBns0h7sgBrswQbrir7rk6btBlbrE2Lqx4LSKHaqhyLtBDLrLq6 tewKr7JKsSF7qxXLqkxbseZ6tX+UqdLBtkxEqW47gzFbPI86t3ibtw+YFSMAGHKrt4AbuNr0Nnf7 TCcmuNMBdQzotuO2uCXIRMcRg8PBa5I7b8/huL1BuQtYa/PnZ4TGGwx4Ylo2a5/LdeUmb5jbdRyj dZ/bur8xaL6hRZErbrqhh5sLM5qreU+Gimh4u69ru64be5l7uMFbfM6kuL5LbpF6GGowFrOrYa43 YooovIpXYmplhdYrvWfoVpUrYrpIupv/B76wq7pWWL7Ee2tpyFeHB3+cm7zXS7zSl72Id4a4Vb2t 5r1VBruUi73su75VaGvpK1drJbvGYVvCF78DGHXVh2u5JXxXlnjCW7sJrLoIPIDje7obJr6AZoZ2 tbsSbMGgW1tT9sDhG1cTbL0ZDL7jx8GIp3nDh8KvRcBPp76km4kuLH6pGGizVldSVrxp+MG42LoX HMLTB8I/XH2I5sMpfMIMXMJHrMBFTGs93Lsr/GcVXL9OXF4yTByeS73jy2q2NmJJHL/yN34qXL03 vMNUPLrky79g3MU8bMZYbGUYfFYqnMFTDGX/62F2nIt5fMad+8Zy3L9Z3FpbPLmYWLoT/+zB1KvD h/bHcLzIdDy9GZa7ahzFNxzHkHzCFEy+TIzGOKzHaUx8SLzGupvG6DvHCCxrspu6kVzDkoyGsibH ZZzHh9vEvdvFnmzJeAzLpRvHhZbDyeu6B6zBmxx+xkvGvAvEUFzKpNzBhTxXQDNTTyfL5ltrVEzI O+zGtaxeYkxX3GvAfOzL2QzG3wtX08th/7vKfYy/4Py+2CzEg5zKurhXiTfOnKx4/KvPbsy+bxXA ByxPhBs3iMvJDZm6CInQMDPNHBK4rOuQDz23Cg0zAx0TBX3Rc/sPTtByf4vRHt2MQki7zKxNbNwd E42KJ+0yKf0ywxNwckTQ5Qx/jZu5Jv/9uuVc0tRBbxH9es97uemsxCfNzz+diET9vXdFtBkTT4FB gTNdvKjrMbpsxeDx1DR9xxUDvAY90X9c1aEMzTD7LnnFGlmHzrd8yueVzrrMw/dcyUedy/WszOEX vWsNv4sswDKNvWq9eEPN1R38vgAsv2/91AjtzFc8FbrgF0p9GC1TzAm8wBqsyBAsz5FtzFQ4fIjI zljdySGm1w1caMaLuWydyLOVxTptzsp7zLBGFLqQGQZHGjbD2LtsxVG9yZItxCaGxPSbvz8czflM 0zxNy1IN2mYdxF2dzNlsus0s272XE4f9RzPVz2c8z27txP4sfrV91s8MzMfsw/srxpz/jYfQS8na a8qnSNo0vIBNDbqDRtgC3RG6sNr/hsvELN3yzNt+pof3XdlwLX3bbdWevNmqrMzYbdAjfcXrPchM zNej3N+v5d6OdIm7veAiHMFG/M+2LMX1Xcj6e8nF7WrTrdsRLuAATuDMzNgHzuDz7dUpXtys5RPN 3Uv+DL/n7WHda9o07s1ljd/RZ7+Prc5zTX8hzrkA/NvabMYR/buiG871LNewfdvnPMnma88/vtwx 8eIwjrgrbbkfLdLgwRNWfuUOLTFZjtFjvoUud3ChULdYWg5qXtFw++a+pBYu3eabGk90Lq9zfufe dxYAAOd+/ueAHuiwwQ+VpOeGfuhw/yroir7ogaEFQ4rokB7pVgQDkl7ppcHojG7pmr7pnO4YTvAY Y9Dpoj7qpF7qpn7qqJ7qqr7qrJ4ZmP7qsP7nHb3ltF7rEmNFtp7rul4xuL7rvv7rLlhFtXEIxH4I w17sxj7st2HsxY4bzY4AyJ4byN7syW4bzD7tzp7t1X7s2E7t207sy77s037t0e7szz7u1V7u1k7t 4S7u197u697t2o7t7u7t4Y7u0N7tz57v9K7s8Z7v9/7t5G7v1s7v6s7tAF/w/b7t0M7tyY7v6s7w D4+eP9TwCt/u6V7w0u7vHJ/tGn/xvCHxFr/xGC/wIA/vI68b347yKZ/x8M7w/g7uH//v8R3f8DDP 8gnf8StP8yKv7SUf8OKe8seO8jcf8yu/8yK/8zr/8S5v8TRTEzef9EtP8kVP80LP7L0h9Srv8Vhv 8yc/81Uv9ES/8TA/8Vvv9TUP9j4f8mSv9jPP8T1/7xg/8lg/8V0v91N/9nd/98qu9WcP90yv8Ssz EVHv83E/97+h9H2f9WtP8hrf9Xsv9orv+JRf9pIv9o9P97sx+XxP+Yuf95df85aP9JoP+WiP9y3P 9qff+ayP+Xl/9O3+9DSR7uCe9Jbv+Adv9RDf76Lv+j1v+mZ/9fUu8/Wu+21v7oxv8cGv++Nu8MTv 8LUf80Sv78/f+4Cv/Itv985v+qn/v/nSf/qf//j7rvPjb/2DLxF+n/1W//ZpD/rg7/md//ZmL/PB f/hhb/zsH//xn/nhj/9fDxAIBA48NJDgwYIHFRpMmJChQQQOJQqcWLBhw4gQM1LcyFGjx4odOTr0 +HDhRpIlPdpj2dLlS5gxZc6kWdPmTZw5X6a0CLGnyJQqT5oU+vOjyIxBi4LEGPHQU55Ej0olGdSo QqUoER6t6hOpV7BJqWqcKNUpVKxbL44ku3WoyZBRo4YFOnSuTrx59e7li7Nu145lwQJua/dr2KaF 03qdqzKrY7OEGytN7JRr5MNvqxL+KhgyXMdX2dJ9ahY0wauCK3P2nLnva9ixbf6j/13b9m3bFKFa 3H2SN8/SZx9zTrqbcnDhrEtbRaq8t0+0pp+jXh65OurLho0D772ZqvG6vhlf1905eWri1IH+Rq57 c/vwnxXipl/f/n38+fXv5/9P71QAAxRwQAILNPBABBNUcEEGG3TwQQgjlHBA2SqMiRUL8eqvtgk7 9PBDEEMUcUQSSzRxqg1TVHFFFlus70QYY5SRQBdrtPFGHHPUcUcee/TRv7xmFHJIITM08kgkk1Ry SSabnC1FIqOUcsQfq7TySiyz1HJL+/Ri7Tvw3BPtuODC/As+4RiKDszh1myPTO7YW5O6i55LyEk8 89RzTz777EvFL0fDbNCxAFNNMf+txDsU0bU0IyorSKXziEtKK7X0Ukwz1U+r1cxzlFDMOqVLqMBK JZU5oxpz66PHCE1IU1hjlXVWWlXkFDLmPjUMUbFUPVWxVHVVa9eHhhtwMoFqVXZZZpul9FZTm5Nu O8TIGylX6MosrKzpJG3KV7GyA1DVV50199z8WkB33dyCXVS8UX0dM9y3GNt2McraCsnbqVpFEzB2 AxZ44HPLM1hMcnmVV1pR+/U0zNbM29dRY8UdlGCMM9YYx/+kXYrYjws9LVp4DbWX1PC8I63ezCL9 yE+YY5Z5Zpr5DDnhbOclq7vpuppTTDWRk8u0NENj9eduIYW4sJqbdvppqPu0dUr/qquGcGOss9Z6 R6u79hrBrcMWe2xZASD7bLTTVnvt28xm+22445b7tpgckBmAqPPWe2+++/bbSWXdnntwwgvPOmq8 /1Z8ccYbd/zxPhOHfHLKK7f88sclx3xzzjs/8gnPK6xVcMNLN/101PcjPXXWW3cdy9Bjl3122mu3 /Xbcc9d9d9579/134IMXfnjii9frdeSTV/5s45t3/nnoo5d+euqdXv567LPXfl0ktvf++1irF398 8ss3/3z001d/ffbbd/99+NMHf3766/8x/s0rwH9/Pu33/38A3igTASRgAQ14QAQmEHs14QL/HPjA 4SlQghOkYAUteEEMZlCDG+Rg/wc9ODgIhlCExvtgCU0osN3JYIQr9F0npHZCGMZQhjOkIfJYeEMc 5lCHTtLEDn34wxXSAohDJGIRjXhEJCYxLxUsRQ2d6CwlRlGKU6Ti+F5QvidmUYv3q2IXvfhFMIYx T1skYxltJEY0pjEmKTqCGd34RjjGUY620V0h1HjHzc1Rj3PEYx/9+EcxQoOKeyRkbaABjS0CUo2H 9GIh9/MLGh7SjYoEIyPD6MhYCSN7ksRkJ2eISD5SUpRH9GQpTXlKVKZSlatkZStduSMx5mCUs6Rl LeH3Slzm8oMN0GUveRQG/9nCkavzZTG/R8y42VKZeLKbSzSnO2NGs0XIlGY1kTdHTbUtU5sjtGY3 l7dNcD7Qm+N8XTjNiT9yplOd66zmOd3pPnYuSwzxrNI77XlPfOZTn/s8YkAAADs= ------=_NextPart_000_0004_01C6F9FA.42BC8870-- From avmcfcdy@pipal.net Fri Oct 27 13:01:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdV4n-0006TM-Jt for capwap-archive@ietf.org; Fri, 27 Oct 2006 13:01:01 -0400 Received: from p57a5ac07.dip0.t-ipconnect.de ([87.165.172.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdV4h-0005Ge-Vc for capwap-archive@ietf.org; Fri, 27 Oct 2006 13:01:01 -0400 Message-ID: <000b01c6f9e9$7f3ae460$07aca557@kromm> From: "basic" To: capwap-archive@ietf.org Subject: Nintendo Date: Fri, 27 Oct 2006 19:01:08 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6F9FA.42C3B460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.2 (++++) X-Scan-Signature: ed68cc91cc637fea89623888898579ba ------=_NextPart_000_0007_01C6F9FA.42C3B460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6F9FA.42C3B460" ------=_NextPart_001_0008_01C6F9FA.42C3B460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Editor ii Diplodock outlines of ii Processor or Pentium mhz processor = faster Memory mb ram. Malaysia Royal Dutch obtained Interim Injunction = Malaysian geologist dr am Huong alleged defamatory attributed Huong = owned a operated British Alfred. Editor ii Diplodock outlines of ii Processor or Pentium mhz processor = faster Memory mb ram. Heregot am oh already right in Technology Register am Nowhome Pagemy = Musicemail ma of Hands ipod or Biggs! Newscom Forgot profile Blogs Extra cc gamesits female designer says = Nicole Girard Staff Writer Published pdt is Talkback women Sheri Graner = ray veteran Sony Cartoon keynote speaker sex conference Friday a. Staff = Writer am Published pdt Talkback women Sheri Graner ray veteran Sony in = Cartoon keynote speaker sex conference Friday Gender Inclusive Design = Expanding longtime gamers in than percent? Pages laquo admin options raquoadd a Gallery Snoopy giving Viewed am = times ron vp of Gcrcc is hey did am go coming Pilon comes Geoffs lipo = batterys yout. Leader Trent Lott Senator Lott honoring Strom Thurmond praised = suggesting president Lotts is critics saw tacit approval racial = advocated Thurmonds a. Disk harddisk in drive Display vga color monitor supporting higher = resolution Platform System ms Installer Microsoft a Order save Rating = quality is content Poor Enter now copy now or Updates. View shipping rates Review of based reviews Write Sales Rank top = Publishers authors improve saleswould toupdate in infoorgive feedback = imageswell back or? ------=_NextPart_001_0008_01C6F9FA.42C3B460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Editor ii Diplodock = outlines of ii=20 Processor or Pentium mhz processor faster Memory mb ram. Malaysia Royal = Dutch=20 obtained Interim Injunction Malaysian geologist dr am Huong alleged = defamatory=20 attributed Huong owned a operated British Alfred.
Editor ii Diplodock = outlines of ii Processor or Pentium mhz processor faster Memory mb=20 ram.
3D"launched
Heregot am oh already right in = Technology Register=20 am Nowhome Pagemy Musicemail ma of Hands ipod or Biggs!
Newscom = Forgot=20 profile Blogs Extra cc gamesits female designer says Nicole Girard Staff = Writer=20 Published pdt is Talkback women Sheri Graner ray veteran Sony Cartoon = keynote=20 speaker sex conference Friday a. Staff Writer am Published pdt Talkback = women=20 Sheri Graner ray veteran Sony in Cartoon keynote speaker sex conference = Friday=20 Gender Inclusive Design Expanding longtime gamers in than = percent?
Pages=20 laquo admin options raquoadd a Gallery Snoopy giving Viewed am times ron = vp of=20 Gcrcc is hey did am go coming Pilon comes Geoffs lipo batterys = yout.
Leader=20 Trent Lott Senator Lott honoring Strom Thurmond praised suggesting = president=20 Lotts is critics saw tacit approval racial advocated Thurmonds = a.
Disk=20 harddisk in drive Display vga color monitor supporting higher resolution = Platform System ms Installer Microsoft a Order save Rating quality is = content=20 Poor Enter now copy now or Updates.
View shipping rates Review of = based=20 reviews Write Sales Rank top Publishers authors improve saleswould = toupdate in=20 infoorgive feedback imageswell back or?
------=_NextPart_001_0008_01C6F9FA.42C3B460-- ------=_NextPart_000_0007_01C6F9FA.42C3B460 Content-Type: image/gif; name="membership.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6f9e9$7f3ae460$07aca557@kromm> R0lGODlhCAJYAYfvAAgEBYUAAABxAIGEAAAAhoAAdwCHerO/trbmwaTY/koqBFQrAnEfAJ0jB7kY ANwnBQlBACxFBk1DDGlADo0xB6JDBrw4AuMxAQVeDBNsBUlkAFtgAIZbDpRlAL9cANFlAQWDABqD ADJ8AFN4DntxA6p6BLeFAOR+DAyTACSTDUGUAFuXBoeSAKumALWRAOmoAADNDSHGAEK3CWDCAYK4 AJPKCLi+CN65DAPZAy7YAEjpAm7qC4XfAJXdArbeANLWCQAASSoAMzkAPGwGP3MATqUASskKOegM RgArRR4kTDYSMWkqO4AmNJEaRMgkOdIlTQAxOydBO0IxPGpFPYM0Ra0yRsxESNQ0QwNUNx1pRTJa O1VhNIBYD65hSMxqPN1tNgBxNyRxNzGKNmaBPnaENKuOPLeFOeRxQg2oOS2cNzqsPFejPnOsMp2l Rr6SPOypOAG1RhzLSULFPmfHRYa9SqPINMG5SNnFTQLYSBftTE7fRVTWPH3TQpXiPr/kSePjPAsK diUNfUwNclYAh40GfJIAfLcAjukAhwUfiBcpjEEke2wZfH8gcq4UescRi9IijAA7dytGf0g3i1gy fXhNfZs2dLc3d+pIfwBWhxZpcjNejWdVhIdmjZlSjsxtdtFtigWDchpziDmMhFaMdH2BeqB4gsN6 d9N9gwqnchmWjUauemmfjo6lcaWsgsebhe2hfQ24ihG6ejXHg165gn22d5HLgcnGitPLcgDejRPa dk3sdl/pdXfXf5riicXlf+bqhQAMshkDwjUAwmMAu3wJwpgAubEAs+QAyQUcuhUhtEkXuFwowXgq v6gdysomwuwesQAxwhQ3wThFwWFAt3dBuZdOxbdDxeJOwQBkwyNSuDtdyVtdxYdtuZpnwMRqxeda xwCOuiuNwzOKwl2Js39ysq13u8x1se51tQCauiaksUqexWWhyXGqw6atvMuqs9WVxQ66uCu3yTa/ w2m2t3q4xpi1wPTw/Zipm4aAef0AAADyC//yAAQG8f8A/wD6+////yH5BACP92UALAAAAAAIAlgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmz5sYENl/as7dlp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaH3mXMu2rdu3DyPBnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiOmmXcy4sePHR2FAnky5 8s7EmDNr3sy5s+fPoEPDtUy6tOnTqFNz9aa6tevXsGPLno1atO3buHOPpM27t+/fwIMLH068uPHj YnUrX868uULk0KNLn754VFnn2PPWyM69u/fv4MOL/x9PvrzNFubTq1+/u2iC9/Djy59Pv779+/jz 69/Pv7///wDiR92ABIa1UIAIJqjgggw26KB+7EWomHsMBvDghRhmqOGCBXboIVYLWRifiAkEYCKJ JL4nooUplljiiSbOB6OKMLJY44sjynfiizeOOCOPO/YIJHw/AhljjkgOqaKOMu6YpItIOinhlG4Z BeWVKa7IpIstsnhfllcS2eSTS5IpppgthllmmSiuWV+bbmpJJphL0gllm0dV8eGefDaFpZt1bnnm nV/KaCiTcM75Zo5pdmkonGkKKiejggKKZpKNJtDnppwadSCXg16qKJuFVmqpl6eaGiqqo1JKKn6s Zv/qqJmBusoklW0VEKGVcT5qKqRCEulkjTbOKGemtBpJo7HGPuqkkZGGKauqRSZ6qoidZqvtZQqt 6quZsfLHaqhrjgtotGAiSy6of+Znp6jrRknurO/ham9NvEr77brh7meumn+qa2mvAgPcb7SVTpss m0WeG9+2EG/6qZp2WgsvwvoWLG3B6NrKr7yvwprwoAKb++5896b8Fr/PLmtflsEuu+KNxG6s45ED KwstwEpmHDPLOLtM34/0UhyfygRRgzRK+W7o9NNQR61gxMTpQTVVUmet9dZca3r11512LfbYCYJt 9tlcka322vqh7dghbgc3sdr5sG330UvnjVvd8fH/nUA+gPvt93uD99034H8PznfdgTc+n+OJO944 4ojDV3jlhFseuOaT/y0f45Qrzrng9eptumCyFGQl6Zlb3rrrj3sOO+ayi06f6IXLfrjhu8/OO+yv t7647cS/F/fxyAt1IOu5M/757brXrnvu0f8O/PWZs+466c1bf7nw01cP++nke5Y99p5/H3vx2lvv vvjdt5/+9rFfr/7i4VMvu0gAlO9/SvmyneHU9zvmga9+t9tc5DY3OedJj3f46579GnjACHKudV0B QPI2eJyJCZB+79Me/s6HwPs4MIQgBJ7zJBi8+71uhc/bH//+R8OX2G99MTycAh84vxLa54To414O /2GYw+i5MH/VGyFJ+lfDJqYEewKUXxIPSDjq6Q93PjQiARPXwiIeUXEjDB5OnNjEStQlgI/bYRWt +DwG9q6In1MgBef4xhYKTo1dHCDl3tg52XHwj26b290GqTYyGnIm6HgOhQjJyLEB8pGQjKQkNwWF SVrykpjMZFYOyclO+kWToAylKEdJylJ+yJOoTOUZTcnKVrrylbCMJVpUScta2vKWuMylLnfJy176 8peyPM0wgulKT0jll8hMpjKXycxmOvOZHiGmNMkyjWlqJTAygKY2P2PNbgbTBuAEpyVj4ZQbeJOU RYjlNtfJzna604nnbI0W4inLd9rznvjMp3royf/PfjZGn7WsB0AHSkOBQrNpjcQQUTg0lIQ69KEQ dZAmI3qhhU6toRTNqEY3Op+JcvSiQmFoSD9KUvp8gD8nLWmDUuq1DX4KADAFwNpgGh+ZOighC8Jp Aj7AU5butKfw8elPgfoensbHqEE9KlF3elT5ABWpRR0qVIWa0p5W1apGtWpQs4rVoi7VqUqFKlOj miCterWrZxVqWtPKUp+e9KtSrWpTyboeK9nUbjSFz10ZZNGyNdStZCUrVecq1qmO9bByDSxhAQvY w0a1sYpta1IdG1mTTjawkkUQZBVLWbAmtbGZ7SxjLzvWPy5kr3qN6XtiKlPVJqC1eX1tXmFr07v/ ora1el3tbFXrWtnG1qY6TVBC1Cpayg72rY/97GUTS9yxIje5TT2ufSCbWbU2d7nzeetTh7pVpD6X tJUFr2AtG93wzhW61h1jeoyC2tfW1L2rze1v5QNb+eb2vbalL3z3i9v72rSvCCIKcdM72PLKVbKh PfB0octU6Za3PtSdbHrvE1oJb1W5n53weR07YM5yFrkF3jCILavJ9u61v/zdr4rde+L4mji+K0Zx flv8MIz6VShtzWp2jQvW5/pYwksV646dy+AiOxeubv3qVc1qVs8WF7EPNrKHN3tdxOo4uhomrXYh 3NJLvti+MGbxe32LYviWOcz9ZW2KXcxa1AI4/0AC7vGOQ4xe5loYytdNbIN5TGfzEvnOC3byhCus Xa122MkcprCcDYxotkqZqaZVyJddfF8xg9nSMD5zimW8ZkzTJ7gIGu6io/zhIwuWyXdurp5HTOon m7e6+NHwoLXs6g37ucoOxvBmp8xrjyRSNzHGb6XLzGkarzjMst30sFVc29IdJKcISbS06axnDFt7 1eRNsrShvO1twxrRWY5wZUdL3lLbmttFxjZmeV3qulJIzWRGs3zhHW9jt5fZteXtsuMN4zcDyKJo lWp3uRrkOY96z+Dd7oUDftawUhvLhSZqk8GN5O8e2bvThatoJe7wiBOau38W8WQ9mqB778fkTv/z 939UrtKNVrnlG0pppEEdIJTjx+YbojmAdA5zl/c8ayx1tz+HTvSiG31bGpwkQZd+2phK6OhQh00z ks5B3cQCLqtgui+jzvWuO0XrYKeLO8JO9rL/w+toT7va1852T5n97expu9znTve62/3ueNekIKXG c472fedwH08iVtK1v2vU8P7ZixkDrxkF4RzZ6jVIzxHfH8bfkt/9efyKKR9RnQrg8wJ4D+g/D5/Q lz4BoI+85WnI3jHzR/NutrFKF2p60aM+Pqavve6Nl3e5T5q2tGWzbV3b7C4DpedEqT3u5RP63C/f +Jn8Q+/F8vtO15fSYP6v7EuafPoo//bNZz7/76d/Thf4id5pXnaL1y8flm+0+6In/feb//3bQ5/8 XdevpfOL/f57+v47gXxDMX/2d3rh93xEVwj4h1DNVnzKdmn/534aBX8GKH7Od3oAuIDedFqux38P 6H/pp3oEMXnRpnwHaHsFuHsiuHrlY1e9ZX3z1lvwVnwSmFEWNXr0l3ooaHupp4FDt3eVhiGcB1FD CCEsqEr1oXmhFm0wV4T5cYTNoQImgVB8tX0/dx81GGA+OE1AqCBOSILPliFQmDdUKFJBcYX70Vfa 8CBbyIWSRm9BuB9f2IRMmABrKB93iIfasId7+B58eIdj2ETGtoRhiIb4oVN8CB+JOB95qIjx/7GG gVhD7JdmxCeDziZ5hniI0baGnPiI9NGIfuiJkagyrTdv/sds/WaFmdh+DdWJePiJfxiKjtiGYCMB jcF+pziIGbiKWIhRffiK+OGKoUiL/tRm8nZbxlhjI8WL9KGGoAiKn2iHnkiM/VR9t9WLy8iMrLiM wiiNweiNw/gT0keNs5EIiQAbHKh//0djwFWH2og3z9aJjTiPshiK9DiKdGGOgVF9/IZ+l1gQ74gy TLiIdhiL4GiQBfmL+FgX+ugXQuiOAbmCAuGIN7WQDDl4b1GGIHWGEQkfasiG5Hgc5mgaFlmSINGQ JpmSmIGSNBGSLlmOLxmTbaeSNIkSWKASMv+Zkzq5kzxJFTX5k4TRk2BhC0JZlEZ5lEiZlCQJlEzZ lE4JT0oZlQXShR1ZlVYJH0+ZEVe5lVz5j1mJEBq5Hy/HIGPpVYEGdGKZUVnWWRdSlhkolUuxEAx3 lm5ZVvpxaGzpNLgmXnWpNWvZl1x2lg1HVzPBRPhkFLtWboAJIGWJl4upIHvpYQn1lwuSZ4blWY4B Uy9Jbsa1XUGmcQLXYFM1cWsVmmtVaAM3ZNzWZKj2YZ6JcSDncI81mkJWmq1ZZ0gWm6Q5mLs5YofG GJoZk5wpawhma4xVnAlHWIqJnOaGZ6T2Y6ppWBYnctJpnOCWaBZHVcyZlyE3agEnc2lBdTv/YU7k +J1s+XG7xpkI15zdiV3WVlyspp6sFp2MVm7reZ99Jp/4eZ2JCWjZ9XGldRbBuYVyqZyOCXEVZ2jP eZ3nSWtYRWAI96BxtWWBiZ1myZ8IKmQPN1rpmaHWxXEZF14pxRKGyXSIaaCK2WqNZqHJ6Z/u+WiM Vm28pmoOap3vOZ2Npp/ZiaF0KZnKBVrjR33i2YYF+qKCtqDUGWUaqpz0eaMpOm4PdqBOmqRT2qIM pmM5xqPNKaM/2m0SCRIwFYgMZ5nTBpq3eXEbd5n/Waa1uW6paZvi9VMWaqYgemptymSfGZ9XNnA5 dqefaVK0mVlfeRGC2ZWG6lBuOagLoZGP/3mojoqWbQOXx6SolNoWknqpmJqpUVepnNqpnoodmhqq ojqqbvipptoSpJqqsnGqrNqqrnoYqhqrrvGqtNoeW/gMspqrukpPtdqrH7GrwCpKbRasMokZbcZa vopLnCAeyJqsz0Ss0PpPzjqt1FqtABSt2HoW1rqtD5Gt3koW3Bqu1MoP4ooRYfmoK/et6tQt6Mog 5fo/7equ71o+78EP9soP9Xqv+Fqv8YGv9yof9tqvCaCvAbuv/AofBnuwCDuwBCuwCKuvC9uvBZuw /tqw8DivpjOwAkuxCmuwCZuvGzsfHBuxJMuvH7uwHuuwJ7uvAYuy94GxuGIUJ6uxIUuzCv/rsiZL HyxLsysLsDbrsylbsyprs/6qs0Gqrq20EDP7sUXLtCJLtD8bsUUbtVE7tU8btDg7tCm7tF4Jsyrj sQULtD3rszzLsBBbtjsLsARbsWcbtE47tmnLtv96sV6LNG8LtFX7tDnLtVurt1nrsGUrtFLrsjOL lXWbN3dbsyMLuE1bHy3LsEYruA87t4k7tHv7socbd+7BsSOLtWMLsoXrtH6bs2T7t2lruaAbuUgL S5/SsBb7s2xbupC7tiVLtXlLu297tmY7sVY7uxa7r5m7NPEKbcG7Xos0vHC2uq5ElcjbvM5bUv7z vNI7vdBrL+dKUbFFvQ3yeErYribXvTf/JknMex/JmHn0Ub4353jbe75JWFPHGmyuZx9KmL2aBnnI BnvyS77/Ab4XAofx+7/54YFPSK8Awr/qGL/4yzb3tsDHpovXmL76Qb/6Ox+6SMHZe8D6ZcBiw73t a77/Eb0FnMG69Vs05b/sSHwsxlsoDHy+RWky6L8tjHn2+3/w28AWnG+7dcGYRon6VokX/IIIXMJA 3H/Bl8IN6F8rPMJKLGYCfGz9OMINOFtmlsM8HMXtGLPH68Gpdb81jMCoOF9f7IAzlmwgmL9OzMCT Jm8YPGYCfI1jvH78l8bsC3koJ2Mz9sYQeH3fS8ZNnMa4BcemqH9jHMjuxUo1p2Zt3MVB/0hsqPjF +8bEwhaHbDzHHYjBTezEmbbIguzCkZzJa6yOD0zB/tXJ+2dmnbzHuAjAk0jK9SvGjpxbhhzClYzE kkxmOKxvo3xpHvjHrHzDDqjKcfhiDExfKAzFP2xfjMyO51vH7lvLa5bKpXzLJdzMUPzKqmyMwDfN eVzMnsbIsby/oOzFZyzKB/zLnHaM1lzDvyzJ6GvDw7xvl1zJvJzHM1zPX/a9M9jLR2zDIlzGcuzO 5EzEudzNqGjIBhzKg7jO9gvN5gyDnKzLCD3DoczF/WzJA+3AzWzHjczMlDzQ/5vMp6zJwgyBmDzR 8+zP8EzPLWbQ4BzEOUzNtZzPw8bNu/9M0C1sYi9MzLisyQGt01S8xTJ8vzxs02S8xD5dxLpl0Qzd aU9s1Ij8ydXc1DMo01GdbLfMxd88vRq8ilsdkV2tNpc0vocKw1dJ1t6rUiCsvWrtqGZ3vWv91tpo lCXXwR9Vv/071zBd1zDHk6HgEx3t0yU9wQ7CwQB8ihmCc2Qdgi3teENc2M58cj7c2KlFwpR9Ynkl 1z390XT911Ez0aSsITaH2I7d2aMd2ggCzYJN0MqsjNR4IJG9xiA9xCZtxJMtykgdzFF90uc8xZU9 2Toc01LMwvn8x1Icw1qMxEL807Sd25hs2BGczprW1ser0ABNyJ4NyHScwX1c0ZA8yB//qNqlrb8h iN3z5dkBbNsBjd2qLdrtLN76DG8uOTfUPdL0rNn1jdsO/L6rvMOQDN2NzNnCVnypjNr8S9+zjNIk ndn1vMkq/V7SvVBUDcxLbd9lHNSMrNn7XWyl3OCPvcA97MkCnX1ArMLmrWmJDMdPnYR7TL4n3svx LWkezc7+TeHgnd0Yrc+mjMcNPeGcjcemrMsB/tibbdgtnuArPuQWzeHx9eBDEcdDrtE3PtPW7MY0 Dt7brcYIzsd/7eM7LtJMfXKTHM5KTsP8DOIyPuYyJdfo5+Ha3MMwnIwfjtxUjttsnMTZLdS9rcTU 3Y9xPnzF/cpmfXMvuOa5veZ/7r5T/w3GiP7aVQ3fISnWjvrVzw3Xp+00TJ6NzSvp503pNfc01DgP 3FK81aq8pE4ci1DqqJ7qqr7qxagtom5IJfrqvRrrsk6rtF7rrnrrusHqrQ6sS8DrwB7s1pQSrMAK uF6rxX7syK7stJrstvEFzN4dXsEKwl7tP1Hs1q6U1XAW2J7t1U7t3h7u4k6q0LR40X4X417t577u 7P4/ur4W6b6FQxrvqD7v9F7q9i4bnL7v/L41ppHvpQHp/T7wBA94bPHueVHwCr/wXnjwg/EehxDx hwDxEj/xEB8fEy/x8qHxCVDx81HxGm/x8JHxIL/xJi/yFF/yIY/yEY/xGA/yJO/xG//P8TAv8jI/ 8iHv8i9P8jqP8yp/8iW/8yvv8jXf8SrP8UYf9Bfv80ZP9Cwf80M/8kl/8ynf9FKv9Cjf8Slv8UV/ 81nP9V3rEQYlEQjPFlbC8lov9Wm/9lm/9GhPH29/9ffx9Wtv8jrf8jgv93a/9PUR93Vf9za/922f 9njP93v/9xk/9x/v937P93R/8neP9oXf9G0/+Y0f+UR/95Cv9oYf+I6v9qQB8EuZEINP92DP+Zqf H42f+PZh+n1v96zP+lpf+T0P961f+xdP+3+v9rI/+IC/+a8P/Iz/8ai/+7JP+Gw/+7lv/Mlf/Jof +K6f+cH/+dSf9lRiFKUP+Y8P+/r/sfq7j/vHD/7Lr/zjX/u+b/iHT/vqf/vk//2/L/3Tr/fvj/7N 7/zHD/bQj/zh3/6Xz/vJDxCHEgwcKFAgwQQGES48WJBgw4QRHw60V9HiRYwZNW7k2NHjR5AhRWb8 V9LkyX8ND62UOJElw4UOC66ECPMhTZoJcdbk2dLmxIgHFbbseRNnzKMIIdYMipSpUplCY8qcuVNn UqM5pfpcahUrULAqozocqnBnWao+bW4d6nJtTqhZkdpEWdfuXbx59e7l29fvX709Bat9WngqV5hP wZI9XFQo28WID89dzLSt28ZUL8dN23SyZcxpQaslHFaz55ebiUqeurXpYM6V444G/wrY9m3cuXXj ho15aWvgwTurju2ZMtDHUb+yniw7snHkmVcr/g1VcefpsWkXzSo2e3Lop6sHF7vZ/HHW3GXuZt/e /fu9iKt7Jy1x/M/S10/XL036vHPpRMOPvv3WUoq64oh7rivtjlPPMdFUk/DA4majcDzv7sMQP4Tg 8/BDEO/yqCqWrBIQLqNI/CzBq1A8UKWvuprwwRddVLHC5Y667yquEIzMIBO7u+ylCHVs8EceGQTt rB4rrKrJIJ+U60gB4xrpSiyz1HJLkfRq7kswwxRzTDLLNPNMNNNUc00223TzTTjVDHFOOt8bMU48 89RzTz779PNPQAM9jEtCCzX00P8rBVV0UUbFRPRRSCOVdFJKK7X0UkMb1XRTTTH19FNQQxV1VFJH 4vRUVP0sdVVWOfqmVVhjLVVD7ZhUUb0pg/zNxhZrRG85X2dyMketbA3W1oNkVXZZZpt1NktaGeMQ V9qgc43AKmmlzzDkdkwvwAEpS/ZZcss191xS7VM3NACRHDaxKnF0cDXslqR3Qf7yZVEmdPv191+A OfJSKtfCY244DhH+T96f2sLWP+NwNfg54far82KMM9Z4Y447zm1EggukkSFjNSsxsWpzFbdbIuWF zOUVvxw5YJprthngiO8deV8kB5MYXgPHqs9eafG9Tr+Wq7x5aaab/tRLnW6qcWf/d3sG2lugZ0vq YaLD6xq9hPvzeGyyyzb7bLTtupM7qvvDl91r3xZ67qK5pTvpbyt2kj+n+/b7b0KhZjtckk8eVkes dsU7RhR7G7pxCp1KOsbGTBwtbYyNwXxzzjvvOFXQQ3/Tc9JLN/10z0VXfXUzUXf9ddhjl3122mu3 /Xbcc9d9d9579/130wEXfnjiizf+eOSTV3555pt3/nnoox8eeOqrt/567LPXfnvuu/f+e/DDF398 8ss3/3z0089LemULYP99+ONHVAH567f/fvzz139//klV/38ABlCAFeFD//5mCAMmUIELZGADHfhA CEZQghOkYAUteEEMZlCDhsrB/QY9+EEQSk+AIyRhCVGyBhOmUIUrZOHYQvhCGMZQhiB5xQxteEMc 5lCHV2phD31Itnn8UESPAsWn0OCsUOxQifUTYhOdKEAJPFGKU6Qi8JZ4RSz2rYpb5GIXvfhFMIZR jGMkoxRvUEY0ogQAaWRjG823RjeCL4shBMAcjRfHNsIRj3vkY/X02Eft2dGDdRSkRjDQNECO8Y+J ZGQjZbdIR0ZSkp2DZNoQMcn2FDKDhNTk0lCgEUyGUpSjJGUfqVFKVKaSjJ1kZStd+UpYNu8GsaRl LW15S1zGinR9UGUvS2cKXwZTmMMkZjEDmMsMrgOZWMKBpYz5TGhGU5rEDAgAOw== ------=_NextPart_000_0007_01C6F9FA.42C3B460-- From akstcaemagmnsdgs@aemag.com Sat Oct 28 03:44:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdirn-0000On-Fn for capwap-archive@lists.ietf.org; Sat, 28 Oct 2006 03:44:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdirn-00079p-EI for capwap-archive@lists.ietf.org; Sat, 28 Oct 2006 03:44:31 -0400 Received: from [59.19.99.196] (helo=samsung-wq1kpl6) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gdirj-00086i-SA for capwap-archive@lists.ietf.org; Sat, 28 Oct 2006 03:44:30 -0400 Received: from 216.82.240.51 (HELO cluster1.us.messagelabs.com) by lists.ietf.org with esmtp (436Y4CJLV P0OQJ) id XG9QXK-6THF4H-R2 for capwap-archive@lists.ietf.org; Fri, 20 Nov 2006 07:44:30 -0540 Date: Fri, 20 Nov 2006 07:44:30 -0540 From: "Rena Mcrae" X-Mailer: The Bat! (v3.71.04) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <381317013.63523817613579@thebat.net> To: capwap-archive@lists.ietf.org Subject: other-self mix-up MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Spam-Score: 1.4 (+) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 asked elizabeth in a low voice whether her relation was very intimately acquainted with the family ofaccomplished in their marriage, to be prevented by a young woman of inferior birth, of no importance From ooovficyq@pdmiami.com Sat Oct 28 09:40:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPu-0003Cv-95 for capwap-archive@lists.ietf.org; Sat, 28 Oct 2006 09:40:06 -0400 Received: from 80-47-66-1.lond-hex.dynamic.dial.as9105.com ([80.47.66.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdoJB-0002Yf-Ol for capwap-archive@lists.ietf.org; Sat, 28 Oct 2006 09:33:11 -0400 Message-ID: <001201c6fa95$92311880$01422f50@spareroom> From: "out." To: capwap-archive@lists.ietf.org Subject: etc Date: Sat, 28 Oct 2006 14:32:53 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C6FA9D.F3F58080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d ------=_NextPart_000_000E_01C6FA9D.F3F58080 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C6FA9D.F3F58080" ------=_NextPart_001_000F_01C6FA9D.F3F58080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Very best which use timeout fully functional though they of lite am = versions commercial am demand continued. View many and a this has or Today hot a Netscape Cool of. Very best which use timeout fully functional though they of lite am = versions commercial am demand continued. Consult problem program neither nor try or sort in problems is liaising = helping them keep or uptodate bugfree key Life a Jesus or said go is. For in Fabulously Fresh is in site a listing or pages a can only a be = accessed by membersto find out or more becoming pagecfs have full access = a period their is we do not charge download listed. Site Visit our = Awards page view many of and this has. Demand continued must a designed platform am Msdos compatible andor with = is Microsoft domestic includes me xp Edition Listedthe been handpicked = tested reviewed rated bring above of legally without time restraints = include most! Moregraham Pockett Founder of cb website provided makes is Warranty = either express implied respect accuracy fitness service library produce = own software Like library enter. Free is Software Windows dos freeware the am Faqs first Members Onlywin = xmexp Desktop Utils Games General or Apps in Graphics Internet is = Multimedia Text win Extras x. Unsure in between shareware domain interest advertiser supported called = a adware of sometimes spyware posted subject Charterto list am very or = best which use in timeout fully functional though a they or lite. ------=_NextPart_001_000F_01C6FA9D.F3F58080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Very best which use timeout fully = functional though=20 they of lite am versions commercial am demand continued.
View many = and a this=20 has or Today hot a Netscape Cool of.
Very best which use timeout = fully=20 functional though they of lite am versions commercial am demand=20 continued.
3D"file"
Consult problem program = neither nor=20 try or sort in problems is liaising helping them keep or uptodate = bugfree key=20 Life a Jesus or said go is.
For in Fabulously Fresh is in site a = listing or=20 pages a can only a be accessed by membersto find out or more becoming = pagecfs=20 have full access a period their is we do not charge download listed. = Site Visit=20 our Awards page view many of and this has.
Demand continued must a = designed=20 platform am Msdos compatible andor with is Microsoft domestic includes = me xp=20 Edition Listedthe been handpicked tested reviewed rated bring above of = legally=20 without time restraints include most!
Moregraham Pockett Founder of = cb=20 website provided makes is Warranty either express implied respect = accuracy=20 fitness service library produce own software Like library enter.
Free = is=20 Software Windows dos freeware the am Faqs first Members Onlywin xmexp = Desktop=20 Utils Games General or Apps in Graphics Internet is Multimedia Text win = Extras=20 x.
Unsure in between shareware domain interest advertiser supported = called a=20 adware of sometimes spyware posted subject Charterto list am very or = best which=20 use in timeout fully functional though a they or = lite.
------=_NextPart_001_000F_01C6FA9D.F3F58080-- ------=_NextPart_000_000E_01C6FA9D.F3F58080 Content-Type: image/gif; name="Extras.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c6fa95$922ece90$01422f50@spareroom> R0lGODlhpAGwAYf2AAAFAHwAAACJAHJ8AAAAgXMAiACGgL3LubjqvKrP80EXBWcbAHwgB6kZDbYd Bd0iCgsxDi48ADJHDm47AIgxA59GAL4+CeNGAwBnDhdhBTRUAFRlAINhDKVcA7dYBtNlAwCCACh/ AEx4BGBzA4KLCpR2AbR0ANODAA6pABeuAEShAmyXDoqlAJ6gAMuuA9ycAAW9AC3HCUO1AF20AHXK AJ3DBsPFC+HBAADeDBXdADTdDFjTAHHnB6rlAMTTBNnUAAQAPRwMMzMAPWsFN4QAO6gENcIAPtMA OwgaTiktSkITQWUfPosrM6YVSMknMd4SSgBFRS1LOzg8M11BTXxHTalKQLU3MetLSABbMydSSTde TW5pMoJcDphSQcpcO9RYOgh3PCl0Nzh/TWh4QHuDQKOBRM6MOtZzTACjPx2SRTueO2yoOnyaNZqs OLanPuufPgPJRyq3MjyxNWGzRoiyTZS1ObzGP+zNPwDuSSPoN0HYPFbZTY3jQafZPb3aRuDlPgEA jCkBjTwIjVcAgocAjJ4KjLoAg+UEcgAUeSUReEkkhFYlfXQjfaYVdb0iiOsigQREdShHfDU9fWVC hIcxg5U1gb8zd98+fABUhStVfT1adWRleXxTiJJjdLlfjuFUfQJ7hxt8dzR+hlt3d3WBdaF+g7x/ jN6DhgigfSmmdjSUc2ighH6tfZyfdb2hceeZdwDHeS66fDTNcmq1g4yzfJLAg7y5i+vFdgDqgx7t fDbedWrReovRjqfmd8TagNfbdwAAvx0Aw0IAy2cAxnIAzqEAtMkJv+kAzAAntyYatzwjuWwhtYEu tKMUtbkivukmygA9vSk7wEFIxl44sXZDxZ9Kv8w/ydFCwAdfzSZVsjdttW5WvndSupxnwLRoy+FW uAuBvxd/tEOHwlNztXaAtJ+MxLOIuOWHuwGRvS6Us0iayF2ntnastqKju8GYvtqtugTGwiizyzax wVXFzoLNtJ3Dzf//4piirnOEd/8MAAD7DvL/AAcA+/kA8AP/////+CH5BADI8CUALAAAAACkAbAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKCnaW8mypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq06M2USJMqXcq0qdOnD41KnUq1qtWrWLNq3cr1JdSvYMOK HUv2adezaNOqXcu2rdu3cOPyXCK3rt27acvq3cu3r9+/gAMLHky4sOHDiBMrXmwQr+PHkCNLnsy4 suXLmD1O3sy5s+eVcj4HzUy6NGY5pg2vS826tUHUrgmKNgqgtm0As3Prhhl6d8/YEG/fBk68uEjf yJMrX868ufPn0KNLn069uvXr2LNrn4lxu/eWCgEY/yc+4aDQD+jtpW+Jvv0Hlu7jv1/ZXj19+ezr 33fvsv58mPoFuB59/eEHX3rv6afegPvtx19+Bf734ILzCVjhdxjW1J19BPbXIXwfcijhhSKCaCKH H444038otugiiRIeGKKLKXbI4owoshjjiTmuVJgT4/2V4o0kmnhjiER6qKSOPB7J3pNN0vjikkpW yWOBVGaJpIlBdsnQUDEyWaONUMaUpJY93iTmlE6e+ZKbZV75pJhHFpkmjhnmWdSOO9454X1mWmnj nwuqSaCdfV7pJIWE4rhoiWRWeSGielYqVZ9FYoongzPWGembjxoJ6ZhxSjnlm6gGGqmnZFJqqaUb Jv+a4JylAigoq4kKiuqkEXJ6aqpy0vgok3bWyCuUXiYLEqmAgrhmnHAKy+yzth7b6a1oSsmqrRBK e+i3yCor7kbMXltqgrlue2eOuXJrrqLAputusI5GCa1M4+bbnX+cwinfpP36OqGChaKr4rw6Dqgg wQ02TGGE+bXZb8TqsqrvxSopF+qr9mDsMUQac0zTx12KbPLJsIakBckst6wXyjDHrJ3LNNds8804 54yUzLk5w/Nd/fws9NA/uUI0TDonrfTSTDft9NNQRz3S0WrRQPXVWGeN1RZacyX112DXjE6X3YTt ctdop92W2Wy37fbbcIek9tx012333aLFrffeA+H/jeEAfgcu+OC68U0RMobjTPjiMv9QVeKQRy75 5ExZQfnlmKfEuFvxbI5d5qDnLFUunpdu+umob7dhc40dVRDjrRPt1HOxa/j64rULPbtzuXN3O+G9 87w6ULbZgxtatbFU/FsCNC+APc6vFD1Lz7c0vfTNW+989dBv/7z32YP/vffdX099+NxHD7722Z8/ vvvwcy/T8cYv71LyOt2mvHD0F0//SvoTzv72dzz9ERB/y/MfUbrTv/915X8O5EnwYmKQ9EnPei6R 3wUz+BILbhB6IAzh9zZYPQ96EIMfDKEKRUg9DqbwhNmrXf9aMkMA5o+GNjReDhuIwx0q74dArCEQ /3VIxCIScXg9cWAEt4I/I7JFgyuU3whRSMUWfhCKKbSiFrUIxfTBkINYvKIJXTi/HPZQiDaJIAR7 OEQnFpGHPoxJDQt4v7cssX4FxA0d68dHAOaRiP5rog732MfkEbKJd/SJBqWIwUV28JFXzCIWHanC E3KRhZLM4iVLqMmZoNGGCXzjHz9pxDXChJBmnOEh5RhEN7ryLEucox716EdQ7pCWb6zjIONoSFqi 0ijtK5/5OLlFTZIPe8Hs5CKvtz2YjNGSleyiFacYRlaasZW1xOUf23hNU3qygfajIwTVGM47JjIn GIklNvcoS3bG8YyidOcg7dex39lONtOsYjOLuf/CF5KQjFXEpECpyEloUvKSICSmS2JHylXOE4G6 ZGMpb4JKd6oxoj9UJxJ5osRcAvKd2gSpG+EoT3FqRaGVJCgk9dnJfmbShZPkokEBmlLsvdSaI02l LSWa0zZ29JTdTOVFefpRjK5ljuu85U7luUuMltSHvxzKGBEayRYykpFR5Gc/r8pPS3q1qlStqUud ykakMtWnRv0kUrEpUqKqVSgbomcCe8nHWR4wkNzE4xD5Z1e62nCCSCvIPqenvvYVtpnrW58wg2m+ 8rnvsOeLH2ORyczGQvaFwZQhDeU6y77mkZyC1Otm12hA/vmxnaoU5Fz3uFFYcjR1njmnnmT7BMn/ yBaosI0tym5r29B+M7fAvUtrf2PPzwBWdqE7bnCXC7PhSrC4nmldPrSWXI8I8CW8rSc+Z9OYfHiX Jd6dLky+u5Lwgtce4SUvetVrXvGCN73uNe962fvd+Mp3vuWtr32nC1/yite91YXua69ZKf6i98Dl fYl7EXzeBDuYwfZVcEvi++D/vvfBEJ5wgx1sYQRTmLn4uohHn7vdvBXEwBV2yYLXq+EUc1jFEm5x hzec4BV7uMUsxjCDXRzgEvsktaKda16Zc98P13jFM87wi2mCZBfr+MlJpnCSd7xjG4PYRyI2YCE/ ikrlRka6M16wf2Es5vQ2uMxNlvGEpwxlDH8Y/8U0rrJ2P1KFpwllqE09bXaTY2AjK/m8YlYzlW2c ZkJTuc1yfnGaaWzlK98ZuxklKnX6zOg4wznRUza0oDXcZE0HusKLdrOjvZJlSC+1qFj2cXRPfGA4 fxrTOL6xqGG84TA7+dW4jvWhNdzjjXC2s30MNm68DJnu0vfN/lWvh+Gb3/0SmtnNni+aVXzfZu+X 0cr+cK81skABc0a6Qmm0dMS77Yx0W9WdIXZOxP0cAG971PCOt7zn/RbnTkXda8G368otuq3oOy/e 9gm/dYbHPQdbjv/7N1oaw4+G88MeDm84SyS+EodX3OIDzxkpaXLbhAccLgZ5eMVHTnKIt0TkIv83 ecZxZnCj4jbVfXtMyF+S8prXvOQwX/nZxtlZQ0IVnK1U+FkY7pKbjxzlEwePzmMzFEQGsa9bXmty KA7xiCfd5CmvOr3RxlSLRvqdykH61ZGedZxv/TrDU2VS1Q52oXeldmInuc1pPuelpyYoQsRlUfXO dwLnxuhZj7vJB0/4swtNy0L1rGiD7HPdWL3qj7e43CVv+M+JGKfnjrlj3B5iu7OGKi2vvOj9ffnN UoXzpEf3Tzx/ts2g3iis/9q3P/722OvLbqEfPe59W0uc8DW2qh2t7u3Bi+Ib3/gZYmBNDH7WGypd 9Y/WZt7rbvvjG/9mB395TnJv1Nd70onTt33/kOzwkSE3HoG9xHPvfR7Az/6V9j+h54iHLf5xFeWn 59epqXkZ0uY/0JsbN3x5knYR5X6ollYQxWWh9HyaB3rz90P1Z2cZ1XhNxXb7t3cDBH4LBX/E84Dv F4HJQhR4FlI7dYFPlVTIk2fTJ4Ack068V3A9N2SLB4Pot01b5n3fBHSnlXMgSHAdGH8yyIACcRV7 1oMheFR4F4QsuIRY8YI7IX9MGIVSOIVUWIVqY29WqBZGmBAB0IX20IUB8IVg6IVjGIYrAYZn6IUs MYZiWIZtqIZriIZpGIdm2IZf6BJumIZmiIZyKIdvWIdlCIhkSIeCWId6aIctwYduCIeKyIZ4/4iH gYiIbxiHdEh9ASYUgLiGmniHZ7iJneiJYbiHn5iJn1iKhkiKYvgSqHiKnsiJoPiKrqiGrDiHiSiI kAiLs+iKuriLosiJqBiLiZiFMrGKqtiKvdiKwZiMvliMqTiKj/iMwGiMpQiLvPiIhuiMmZiNmviL tBiNr3iN07iMz8iIwhgTxOiNrAiOuxiOpAiOotiL6giNv5iOMHGOx6iMmxiK27iPndiO/MiN2siM +ciM+riO5diPtciIfoiQ9XiNDumH7oiN07iQfyiN/AiJcDiJBhmRy3iM72iKEMmQ1eiM0EiSyfiR Z7chBWmS9xiOAjmS3CiOBemQL3mPNFmPE/9pkvhIkjM5kB5piiJ5kxq5ky0pk5y4hQghkutYlPFo kQPpkh7Zkhypk0I5jkRpjQTJkP74k/IIkDl5lUsJkjx4iUNRlStZldQ4kt64lvNYk1+JjNRIj0AZ l3Q5l0rZlm/Jjk6Zi/S2Oqe4iAp5iBj5l4VIiUMZkoSoinmohw/pjgoZiYKZmIK5h2Qoi4cYiYgJ mYgIkY8pmZJohkhpHgdZb/w2mqZ5mqiZmoGzC6rZml3Bmq45lqFpErswm7Z5m7iZm7q5m0sXm775 m8AZnMI5nMRZnMaZE5VwnMq5nMzZnM75nNB5ZbzZg00wFtEZndNZEv6QndzZnZCzDP+wCN7/OZ7k mTnXCZ06swLliTHn2Z7uSTeoUDjrOZ/0WZ9L8Z74mZ880wT62Z+SgYX+CXJwE6BfVjMEeqAEkKAE YA8KmqAs4aAroaARKqEP2qAVaqEUOqEW+qAvgaENuqAMmqEhmqEfeqEiCqIXqqEjGqIpqqIoOqEp +qELKqE06qAb6hIlqqEniqM52qEkiqI1+qI1GqM5+qLCcxFAGqEcqqRLmqQt4aQM2qQduqRMSqUg mqRQWqVQuqVPOqVVGqVfuqVGCqZaKqVlmqVdWqZh6qVfuqZuSqZWmqZkeqWy6TFBMaZiaqYwwaU4 yqZdKqR+Cqd9qqZzuqeCSqdyCqFgaqR4/8qnicqhY8qmaKqkjDqobbqojmqlmXqpMdMdlXqmhGqp TjqpiEqplsqkk0qofAqolYqnkIqqNTGjarqqVBoTtPqqcvqmUlqqrmqqhfqrcQOjOjqqcKqoJvqk JOqjxlqqwjqiQtqoP7qsO1qskUqszCqiizqnOyqrzyoTN+qsaQqoudqrdEqqu3qsTGozRXGtsNqr epqtl3qt2Aqrgnqo4eqmz7qs9WqtbUquv8qqUequgyqu+SquteqvAVurs/qvCgsTxnA37KqtgRqx uRqvFQuvhjqu9GqxcWqvWsqs+1qhDcuiJHuq99qwBvupHAuk5vqxKLs5xPquvCqqB1usNv9LsDKL pjgbqrLasTb7pgZbs0Drs5H6qzf7qC/rs0absEM7soKzoTKqoqiKrdFaolF7tRAapFdqtVRbpIoq ozaatWG7tTM6tgc7r8nqrPr6sWKLrCyLtWSrtkV7o2kLtys6tVB7oDBTtHp7mnwLnADat1pooDlx DYI7hfaZuAqhA4rbuI77uJAbuZL7FXgwuZZ7uZirm4e7uZwrnNrQubmVuaI7urqJAPlSBqRLMqC7 uqx7OqmbuI8RDq1rE0JwpK97uwYRCbi7u7wrObNrmr0bvMKrc787msOLELVxm8V7XYh7vA1hG84b vdI7vf3metSrNOl2vUFSvNEZeGXXE1b/F3Fzd3EoR3nc2xVTsBxl9701sb5jd3WFF3fse77VsSEP F3g74b5FB79UJ3hCaBIyoL2LcXQnp3Xke3FaZ76FR3g3J7/7K8A+KL9k976Dx779+3gVHL9lB8H9 hsENTMH+W8DxK3cLXHgcDBWQoDlBgb8M3MIZXMIUTMIIvL/0OzMixsIfLMP+C3gijMPwa4knbBor THGSR3nmG77eS8Tie8CT1781/MRQHMXGGbhyEcTAIcVYnMVavMV25FenFIP354RO+H3LN8ZldGfj 5HdmTFHmlF3mVB3Mx8az4X/wdE4BqH14fIFP2BY/hXl57MeSFjh3HBl9jFt693J7JluK/wyEbFHI evzIgKyEdzPIhIxD6NdK5bSDQlZXZ2RXMFhIwJZ+vZd9o2SA92ODo6xndQVsoGSAngV07KeDiKRa ikdXtuzJiLda2fTKJFXLtLzLqjzL7QfKs7zKwjdPqXwVcTVApmRSFah/7NTH7HdqAOjMh7xXvuR3 JajH1oyBz+zN2GzJ1ExgtqxU0fzNUPV0nHyAowR250yCpwZI2ayB6xzOIdUXKLiA/beA8pyAZTXO 8qx/D4XKHnXNphZa8tfNT4V/PRVPCph/8OTNJ4jQ/yzRt7TQp5yANrjJEj1Uv2RWxdMXGI2BzrxX 5Lx/Cg3NJq1+Bf1KJs1W6fzNJS1UKP8d04f80byU01ymfWs10l3nyDM90yRtTTgd03UKFrqcfr8n zOvnfr+mV0pNg8wsynglfHjFz5+c0Tx3QMQcSKwcS1/t1WHN1ErdfqZlWsec1K98V34F1qF8XXzV c2XNc1W9y2uNz4vDfWRsW5KcRs7ne9x0x5RMYi9DOFD4Y3qtFoedP2uczGzs1hzX2DuB11x8MpRd 2d5xGJiNIU2x2efJ0i4tgnqd2F/chNhFTozNx2s82qT91xxXF1Ts2lnRcq291xR127bd15Asgsun zfdn2nBlGFNR29sn27Rh3JEsaaFH3MkdyFLB3Gc8GkyBxgSkZ4pnzFUtZC94yVF90dn/RMzgbcym J96/JsuXjN1trVbnTdXtpMro3dSrrEQ1aHq3TN7t7HRczcmr1csFB8oZCMySXckpvdNs1Xf1HNEG XtKovEqy5Er3fdIqqNMQPVEUToLdHOF7B3XvDOEHCODmnOERvU4JHs/+3H+GbNDAd9Mkvn461dNf jN85LXX8POLgp9EdruAXfYL9HFQDvVSh5OIkrc8cHlUT3col7s8SvnYzPoHnjYJzvM0XDuQYHlUa 6OJAzuBObtFFTeMMnUtnJdQjVoJFnmc6/dIeneRdvuVtJdTTx9J03BlmvYM0qNZQPd+IV+fh7dVy Psx6judszcvHvHh2Xt9iXd6CbtWi/7znhM7epDzf1T3XtzzWuezo5QTL3M3oo1XXAGcRfk2ExT0Z 0I2Ez5HItXefRBjgA/bYvRXqyIPqnLHYGe3Zsj7rWxfbtG4dU3PrqAnrvsfUxEPl1u3Fc8zqjo1w 4KRld57av47akc3Kuz3e1T3qMpjIcJSErw3Od+HGx+3bBZjk3I7bzV3guj3Ydozg4Q4Zjvztp/zf P9jpui3qvf3b6k7PPN50uZ3Hgx3m4e5Nvk3sTBTric7d4sx3lx7MTtfkaeXfsc546F3M713p+m3e 7M7wtCxOBF3I/L7u6f3duGzKir7VyJx9Be3LG03Rin7yxS4XHTXmFD3PDW7iZe7gGv/PzmLu4TS/ zkV9cDBv0C9fgC7PU/xux1CnzjI95GrMzDduz2h+9BDudVmRTnVUUlhtS/As9Sq949xs5EGfz/w3 0hUN1VqfylKu0rlMVkoo9Yd07Ebf0BZv8i2d4RMe4vosZLne7mOeVzru9FcPz0C/zWjl7VFO091O 4Dxf0TkP5gK99msnUjl/9Yb/Siuo4zfP8s+u8hXf8c4O9rpc56VVg2Lt0Jqc+Yzn1Gsd7Lhc2vvd 35r+8Tr/1jMo59Ee+6Ef33zuyvLt8fGd+wvP+en9WTrY1eDt6sTF6Xb07m5B2we6F3HB65bvxv4e m8qv65US/aZjxQoh/dif/dvh6sL/Pz/ATt3eD/Cdz/qeTcXaPu+h7dzyHt3g7FBdZv3L4u7Xnv7o T/+PZtvSzOKuBP9J2YH1DRD2AAy0JxBAQYIHERIUaHBhQYgDDyZ0uHDixYoSFT5MqNFhx40SI0JE SNJjyYkjSa5k2dLlS5gxZdprMtPmTZw5de7k2dNny39BhQ4lWlSoQqQpkTZkylDlx6YrQ25suLSp 0pJPo37EWlUl1axMo6bUas/oWbRp1a5l29btW7hx5c6lW9fuXKtL9YoU+3Sv07BTyebNCvih18Io FSdmaXWrYap3JU+mHNdPZcyZNW8eShgx2bJi9boMmdjzaNIRS49dvJXxathhzXKm/13b9m3ct39a 9Ajy4m+pwEEGN5jUt8bjVAEL5lqxuEXVxhnyNR5693Xs2bVv594d+13v4VPLlir+Z2706dWvZz/Z /PvopMHCx9ne/n38+dHT599fu34AAxSwPf8KNPBABBNUcEEGG3TwQQgjlHBCCoEa8EIMM9RwQw7n qvCnCz4UcUQSSwyvQxRTVHFFFlt08UUYY5RxRhprtPFGHNEycUcee/TxRyCDFHJIIotkKUckk3Tx DyUxM/JJKKH8I8rumrTySg2ZxLIuKvv7pksws5syzN22NPNM/LREc0022wxQTTfjlHPO2uCk8048 84zLTj379PPPf/gEdFBCC91yQv9EyFR0UUZ7MvRRSNMyxMZGK7X0UhIj1XTTzAi5D1NQQxV1VFJL NfVUVFNVdVVWW3W1UU5jlXVWWmvtkIEWX9V1V1DB4zVIW9f8dVhiizX2WGTNA48cZsmxp1lmIYq2 oGaprVbaaaFlqVpnSeoWW2enfTZabr+9dtxwVzrXWnPPXRdddMsFN95yu61X3WwLChbN3cylVlqA A/bX238LDnhcdbc9+NmDv2XYYHGxxXfhdieG2OCH7S3Y4Yq9HThZZB2+2FqBX9K4JZE5frjhjzvO OOGE/T2ZYIZlXphkjFfG2OZ/Pwb52JQbfjlnoRU2WeeV000a4JNFRnnpmUvmeej/mnMOWuipnf4Z ykle8lVcaAdWGmeayd4Z7J2lLlppjiN+uWmjNZ5Z242RvnpktgPeN1KaVX7b6Jt1vjvesuVem2qi DUe87qqXdnxsqwvveeS9Ie37crMjh1lzwYtGeOTPB68bbpgV9xli0f3+2/HKHxUbc8btBj1t2h0H XXXVPfe5Zc8b57x23ldq3VC6w7YXbcI9Dvdddts9fnnoBSYX+ea3zRfe6tndeHpt3VUeX7Cvv7bb 4a/c+nz001d/ffbbd/99+OOXvz675jexfDbtL9HKLSy/jtvmcY9uynPZuuo1QHqB64DhY2ADI7ZA cmUvgA0En9OYZzfj0Stq+gtT/wGZFjvgla1kiwse1aJWwtORLl27YxzuREg0zZFucRyc0F3upjWk JY5sFtzc5k4nu9L1roedwyHFFMbDF04OcDqcDf5W1K+jAXGIq0Ni4G6HNyYGr4owLGLnYrbEHPru hXOjoYhs+L3kWRGJihujS8KmQDjm8Hltc5sULbZEHm4xjBvEIPKcyCIoSs6OgYObHnHoNzLOUIaK nGISvUgwQ6KMeVf7YRmfdEM3Pi2ImRukEeU4xUUWUXSNzJ0S29jD1IHRkhBaliBnJ0IWDvGQsBNj CGdXyipqbXCxhOUjf+ewPz7xf+56o/YkycCbEdOCxczgJJWpQAQ+k4DHrGA1K//IPWNiT4MwXGWD fNXNCAXTTOCUkDhTRE50plOd60zVINj5TnjGU54mAseBUlbMbVpPgAXMlgEzKMF5YW+A49unPut4 TwRaLaFx/Jw2HarNgTrPoOCr2T8DCtF5arKXtcPiLT06tFJ60YW6A9wocVlSPHrSY3ccKRNvl7dH jo2P7fvaIDcY0pa9DiY4jVsWXZlLSMryg67M4g9lysiGmtSOXfTdyWbEjSaZMoZC/akJd5rEPBLS lp9MWyqlajuf8vGoYlWiUrt41o4GEzsn3CQhnYc8yNWRozo0KvAumFC2CpKOegQpV2G6xq9mNYqS 7GhGGQrEUYKwkKr0JRexakv/XSr0gT40oEtHCLnRgbCFncRsI4OqWfe1Uog3zaRIJUbKx6a0rY/T ZO5SCFlVzg2wi4yd2wSr0kzq1JxcailYMWnaEe4RlaVVaUuBulXfCjGmqbVdb7dYQm4OFWlq/QlB oadMZ/azeHC9q20v+FC8SjOpDtSeRa0LUYRKVLLbe+tFdfku+B5UvEw1bH3tC6Rv3vdU1NVvf+2h D/8GWMCO2m2BDXyWASdYwQtmcIOJ1Q35HXgz95AwoRx84SJVWMM3OsSGPfzhT2FYxPgtiqBAfGL/ jVjFO0Jxi4O1YhjHWMYz1t98aHxjBNkYx1UyUwf+BAAX02jHLTHMkE8UZPQA0hnJQjYyeZosniVH WcpTpnKVrXxlBD9Zy/QxUyuw/OUsDzgGW/4QmM2cnhmcWc0SJnObj7xmOEfVzXPGlB/oXN8453kz p8DPdqpx5wQrANCDJnShM6VnRFOqJ6QwdKMd7ehER3pGj6Z0pS0NE0lnWtOb5nSnPd2WS1vaCaEm dakbzZkiFOHTe4OqosOTalM/GtaxFvCqbS0gWuda17vmNYNv/WtgB1vYwzanJZXRa2QnW9nLZjad if1s3TRb2tOeJ7StzRlqZ3t+3tB2TK79bcwEBAA7 ------=_NextPart_000_000E_01C6FA9D.F3F58080-- From bcphmcjka@penniman.net Sat Oct 28 09:40:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPq-00039m-JK for capwap-archive@ietf.org; Sat, 28 Oct 2006 09:40:02 -0400 Received: from 80-47-66-1.lond-hex.dynamic.dial.as9105.com ([80.47.66.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdoJ8-0002Yg-7P for capwap-archive@ietf.org; Sat, 28 Oct 2006 09:33:09 -0400 Message-ID: <000b01c6fa95$92501230$01422f50@spareroom> From: "Submit" To: capwap-archive@ietf.org Subject: Home Additions Visitor Date: Sat, 28 Oct 2006 14:32:53 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6FA9D.F4147A30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.7 (++) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a ------=_NextPart_000_0007_01C6FA9D.F4147A30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6FA9D.F4147A30" ------=_NextPart_001_0008_01C6FA9D.F4147A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Worst order reviewers is consider first in being better than second am = third etc might of same variety is usability important Other is. Login of Account Lost or password Public Home Additions Visitor Submit = Link a to am us Resources Webauthors Newsletter Contact About. Worst order reviewers is consider first in being better than second am = third etc might of same variety is usability important Other is. Jesus said go world preach news a creation Whoever believes baptised = saved believe of niv save your lifeclick out Last am Updated? Enter into copyright disputes authors publishers holders up owner pursue = directly publisher assumes issues resolved told. From am page unlimited = entire a fee program or server or There also limit placed often may use = during his her note that in weekly does constitute siteif unsure is = between is. Youfor created pirate computer or club started collecting moregraham = Pockett Founder cb website provided of makes a Warranty either express a = implied respect accuracy or fitness service library produce is own = software Like library enter. Me of xp Edition Listedthe been handpicked tested reviewed or rated = bring above legally without time restraints is include most suitable = support additional features rate. Carried soon possible removed if receives duly recognized in Officer = Court pertaining ruling in would prevent listed or However Liability = area rests of solely in publisher staff. Infringe consult am problem program neither nor try sort or problems = liaising helping? ------=_NextPart_001_0008_01C6FA9D.F4147A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Worst order reviewers is consider first = in being=20 better than second am third etc might of same variety is usability = important=20 Other is.
Login of Account Lost or password Public Home Additions = Visitor=20 Submit Link a to am us Resources Webauthors Newsletter Contact = About.
Worst=20 order reviewers is consider first in being better than second am third = etc might=20 of same variety is usability important Other is.
3D"dating"
Jesus said go world = preach news a=20 creation Whoever believes baptised saved believe of niv save your = lifeclick out=20 Last am Updated?
Enter into copyright disputes authors publishers = holders up=20 owner pursue directly publisher assumes issues resolved told. From am = page=20 unlimited entire a fee program or server or There also limit placed = often may=20 use during his her note that in weekly does constitute siteif unsure is = between=20 is.
Youfor created pirate computer or club started collecting = moregraham=20 Pockett Founder cb website provided of makes a Warranty either express a = implied=20 respect accuracy or fitness service library produce is own software Like = library=20 enter.
Me of xp Edition Listedthe been handpicked tested reviewed or = rated=20 bring above legally without time restraints is include most suitable = support=20 additional features rate.
Carried soon possible removed if receives = duly=20 recognized in Officer Court pertaining ruling in would prevent listed or = However=20 Liability area rests of solely in publisher staff.
Infringe consult = am=20 problem program neither nor try sort or problems liaising=20 helping?
------=_NextPart_001_0008_01C6FA9D.F4147A30-- ------=_NextPart_000_0007_01C6FA9D.F4147A30 Content-Type: image/gif; name="site.If.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6fa95$924dc840$01422f50@spareroom> R0lGODlhxAHQAYf2AAALA3YGAw5xBoV2CQkAhHoMhgCJi7W2x8jpuJzS80kVAlsTCHQdCZ4uAM0a AN4TAAVOAC5NADc3AGFJAHs0C5U7ALVLANY9BgBUACVhAUhUBWdUCH9RCpxjAbpqBe5RAAeMChqK AE5yDGV/BnuNAK1xDraOAd1zAACkACyUADOjAFyjAIuRCJKcDrefCOWXDQDKABO+AEvEAFq1AIO7 A6u0ALe7ANeyBgDiABTeAD3VAGjoAITcAJncB7/gDd3kCQQARScLRzkAQmoATIcHS58MQM0AS+QK QQAsSBciMUsRSVIcTIcmTK0qSs0aROYaSAczORwyTD81OGBFR4M1QJIzPbNKStlAPglgRytsN05l OWRRSHdTB5doNcFgS95aOAB1SRdzQkV/Nl2LOo6LRqh6ScB1RtOFOACuQxSuMUatQ1atNoSpN5Gg MbmfMuesQwC6QyiySje1TlXMNXO9RJmxRbfGStTJPADeRBzrQEPgQFfdRI3ZSJbYPL3eN+rlOwIA ghsAhj0AeWQCdXQAfacDibwAetsAcQAYhxERjEsTjlMfd4gojKome7wSjeccfwBGeRU5ckdGfFVA jIhJcZs8g8I2d+M9ggBueiBbcjtnjWdXjHVbhadidLJbhNdZiwCNiyWJfUx9h2h9c3GKgaCKccN2 ftmHjQ6SgiebeUKaiWGniYyfhaKSiMGfed2tgQfMeBXMiU3ChGG0g3vIepa8dsm7ddLOiQDlfCDX fU3ic1PXg4DReZfjcsDjievfigwLtCQAvTMAw1MAtoIAw5gIvcsAuuwMzAgmvyEku0YkyGwRxngt vpMZuLQjy9cisQAzsR5FwzIytF1Aunw+tahLy7M4uutCvgBXwBJasTJZtmJmxXZWzp5fzM5Suu1g ugCCvCCKwzF/s2qFy4V6yZuNwLtxwOZyugSjziyetTWXuFOWv32fvqmbx7+lxN2XuwDNxCHFuUW2 vWjCu37KzJy+yPX/+qqjo3d3gPQAAAD7APL/CwkA/PAA+wP///r6/yH5BACzo/4ALAAAAADEAdAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MixY8R/IEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3PnSo8+fQIMKHUq0qNGjSDXyXMq0qdOnUKNKnQoyCNWrNZNq3cq1q9evYMOK Has1ANmzaNOqXcu2rVuIOt7KnUu3rt27ePPqHYu1r9+/gAMLHky4sOHDiBMrXswY8d7HkCNLnlyw seXLmDNr3gyTsufPoEPz5Uy6tOnTqFOrXs26teu/ojcmiU27du3XuHPr3m3Ytu/fwIMf5E3cpZPi yJOjFM68ufPn0KNLn069uvXroZVr304YAPfv4MPn//Yufir289cBoO9ocj3t8jDJw4/qvr5z9fYz tv/A315/gvwF+MFAAhY4oEAB+oeggQAmuKCABSV44EEOVvgfghEySGB/Azro34UPPghhgxlOOOKH B1qYokDzsSRfi1ApZKJBKwKIIYE3fnhjjQrimGOPQIJIo40+Frljjiby+GORNU5oJJJEAinljPnh l59+JSHpZI9bKmlklxEOOeWXMkY55pZLginlmkuyuWGYbCrpJJUw1klYmRjOyaSPeiakJpF9uolQ oGCiuaahh1IopqJ9oiknmVdGiiVJUAa5p4gZDgonoCcu6NCKj7b5Z4mdPikol3wuCuqPB9rpakvU 8P+Ep6W00mqokInC6eWbC606pqibBuumo36mGmeqoepViqRztVergnoGWqyZxz4r7JC+bujhk4iO aiqiZwKb57hEvmouVrN2GS21rApL7LPSMkpumu7qem21ipKIb4fztsnsvw7hMS2+9Np4obe/Jnww Q/F6+661ty4qcaUF+wvwxRDtx6GQoxoIKse4nrgthyjyKvGcB6fsqMraltjgrRy//HC159YsVW3g YqwzRHNE52xkOWNn89BO7Ww0QX8cTRnRTDftNKVKRy311FRXbfVwT2et9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcK909dx0kxW3VCfcrffefPf/LdUtfgcOd92EF76V4IgnrvjijGdp+OOQRy75 5ML1QTlezFzeVuPhMeM5M5yHzvfnoItOlebukY766qwj5LlzobQu++zNmW67TjLcrvvuvPfue1+G 00I74TYMb/zxyCev/PLMX/yzZ1A3FD3h00eam0AAZG+PlUhpj733FVWvEKUClC+APeYLlP5A5xO0 vvrlu29+++jPf7798eN/v/31v89+/vRLH/7kF7//7c+ACDxf9ayUPfARxIEOaSADJQi+Bm6vIBLc Xga/NxALatCBFPwefixopZG0YTUX5OBWuMc9iogvISQJoPrcVxD6sc8gNpyhDtF3w/b5kIdA/KEO /2VYwxsaEYhDPOIObUjE+tljegx8YAenCBEWYu+KKZygFLEYRSxykYpgHCEYU5gahLSwhUepoFhy iMQ23q+IcKThEhHCxjbaEYlsDGATc/hGOv7PiHxciBgx6EU0KgSNVhxjCr0Yxg520ZCF/OIW92IS SHpQe4PEpBY1mEVNWnGQnOQkKNX4QoSQL45utGMecXhEISrxla5sYiuDCMsdxrGPriRI9LooxUsu 0nuYVOQih2lJRv5yiqM0IxXVY0j1jOcgj2QmM1U4zU5mUZFizCQHgwnKJ47kIVArYP/8l8tV1nB+ BgwkKwmoR3HKkZayxKM54WnLgexSmKOcZiYTOf9JYjKkghu8JgsR6cFQGsSZqFHmQZcpyWhq85qE vOAEHypNCHqknOx85ytTSUuN1hKP9ZwjD+OpzlmONKSHxGckJerLfjKSn4J86RcRGdFeQhM0Zzwm RJNJUWQulJoNvSIkL2pLWcbzjkxE6R1Vuc467pGkqAQp/OpZx0ZG9JHDzCpNx5jTm/rzl1tVaVbH apf2YDWo1pQoWtVa050GtZulxJpIiJjUoiqxjzOsa12XWtKThtSodxWpSQXbvnty1arV7KZMXcrL lSbysdj8qVa9eZpDghCYmhSlQSmYWWN+MIycFaU0hWkRdPYPfvvzIQDROcABjlOc/jstagUI23b/ yjaI/JvtOVN7V3cmZKCX/WxnC+pICBL3s8i8ZAiR20k1Ele5iqXOUFPavLBMdzrXlcvzKJJdyQol rgYBL9UWuJ4S4uYix7WsUcSry28ajr3nuZ5S3JsX+OaHbywo43xFQkn67ux3hdmIfdcCtXz8F8BX MWNAXdqcfDh4IA428EEeLJAIQ9geEaYwhjVsYQlDOMMetvCGOfzgEIt4xBUusYkNDGIKS9jD1T1L Y6nDYgzbuMIGgTGMb8zjEF84xTkmiI97jGMg85jIPz7yi4u85CLH+HBZmnHG/HsXktTYyTvOso6T POQsB1nITC6Il3d84y0b+choHjKCE6xQliJX/7mkpcyJh4xjDYeZyz8m85fznGQ0O5nPeG5yn5X8 ZChTKqDAFCgjB6yWAgtax4Kus5AzDOgUexnMSo70oMuMaU5fus8GdlsuzhvWaoqQe4xOS4FtTGck X9jMd/70oDXN6gl/GdZLljWh13y6NjcSpr+pcatbXWtQ33nTlybzlV99606bWMzQ3nShu1JqRZMV NMJ2tbYjbeZh7xnJXcazuLHc6T9/e9pFqeRlK7rZKKYaLZSaM4ctTe88g7jeI1b2velN6Q9r2c75 9jeo7axmXsdECJ3BmJ4lsnDaNBzdEGfIw7EdcaRs1yLvPkvG42tw2KxXJKzYHJUx0vG7HWXjJ/8f +UVKnraKu9w9Zk2vemfOIpXb7Zv8yDk/7KHznA/E5wLRedCFznK0tbm7DPbuXnYe9KY7necEYTrT of7yqlWyItlFtc1HI5Kp//zrQwe71ylbdLYR05PBFOhEGYryj/N37FOPO9Xlbs+yl80eqlAwYkc7 WrZCVDJA53nPxU71sC8kBFWv2kPdGsWzUkbqUXf6zsdeeIQgPvHMel7jGep3U8N162KZHuQJb/jI pyQEdofRLmjCS8/P1KeSrDl/2UISunt99JL/+ulTD7YFg5Xv7Bah8BE6ewKPZPCCR77QJb98laCe 95kRR2J+65G2pxv0E3E+9P3yAs5U8XKXx7z/0iwKufCL//zNMT/6heY47WI/5ds3+ZWQvv7JOUvm Bm0IZ+nPEOsLEoQP5D3xpzfUF1MPsXgSwX8coU8qpFPL4wkQR35J908YoYAbYWordW31xxZTQBvN lFgj5ElKh1ksNVyJZhTH1XobSDtdlXbJ5F37ZG3RlUb8JGUrqDld1Vyx11ZvNlMttUIOaIM3eDWa J1ywt3letVYnqEj+F1MqeEUDKH8FOEmJBXswuFZupRUMmIEWOIRTg38hhGgKBlwbBGdARYNrJ3w6 8wxe6BVdSIVk8YbXwQhtmBZyaFV1mIfdc4cById6iH4X94dEEYU5IYiGeBQ1cIiKCB0B0Ij2/9CI ZgGJkPiIkjgQk0iJZmGJkyiJm1iJBOGJlKiJmYiJj1gQnCiKAtGJmXiJmOiIqXiKrxiJojiKrBiL pPiJjsiJkUiLuQiLn2iKuniLraiJqLiIF0GLlpiMpZiKysiMzSiLy7iKz/iLzliNvGgQyFiNy7iN 3LiN2RiNxMiN14iL4ViO2TiK3kiNzeiM0piO07iOxrgQ7fGN6GiN1FiP9QiP54iNr6iM+MiP9riO 7aiO36iNpZiP0oiMCpmMBdmPATmN+diNA+mP2UiIOJEQ9PiQ6AiNpngQ/8iOAAmNE4kQGSmQ3aiR IAmQ95iOC8mM++iSD2mPEfmRCAmTJxmPEv/BkcMYi/8YkaGojjwJj+B4kNpYi61YkBt5k6C4kzMZ kja5jwMJigmpj/6okim5kkSJk/3nODoZlQZ5k0BJk0LZjiLZkWZ5lRJJkkWJlmMJkl6ZlS8Jjg3J i64IlEOJldBokU1hk185kmBpklh5klE5kjVZlVTpkWtplzqZkmXpljFpjXOZmIdZmOOol0xxmHz5 kWeZlAQJmOLomYDJmUKJkgz5jqTpjqiZlKK5moq5mZ2pjDgxAFG4EBt5iqzoika5k7a4mz8plXVZ m3U5i8G5lMJYjEd5m8Gpm5e4ir1Ils2pihTpm8xJl8YpnaOplZXRfthZfZZJE9v5neAZntj/cQLi WZ7meZ7omZ6/0Z3syRrq+Z4C1p7yOZ/0+TbweZ/4mZ/6uZ/82Z/++Z9g0QYAOqAEWqAGeqAImqAK uqD12aAO+qAQGqGpt6AUWqHbKaEYGmAWep8Z2qGBsaFHMwQgOqIkWqIminkIgBceuqIaeqKDuDsu GqMyCnHtQQA2SgD2cKM2OhA7KhA36qM/yqM6KqRDGqRAOqQ8ahBFqqM4mqNG6qRGyqRE+qRNSqRH CqVOaqVXWqVAaqVMiqM/GqY7iqQFIaVHSqVlaqZKGqVVKqZcKqZeaqZNyjsI0aY+mqR3iqd2ShB7 mqN6qqR4mqeB2qR22qeC2qeIyqeAKqh+/8qoiMqljjqoh5qkhqqokxqpZWqpmtqonMqpkOqpmrqn n5o8JvGpj/qndSqpmbqqmfqmixqor5qojEqpqwqpbSqqrCqkqhqqtLoQstqqudqpptqllxqqv4qn dJqqvHqnhAqry9qolQqtimqrteqsuyqrrkqtw8qseTqqwAqq4CqtsxqrqMqtmyqsiwqmxSqpzdqt 1opuPQql8dqsb2qqVBqlaxqv4qqrZ8qn9sqm+kqm+5ql5Oqn7Xqllqqu/UqrCkusByGwEIupsLqt 9GqtuHqr84p5ByuuDeusG3uwFOuv+oqq2zqx7lqu8jqtBauw1FqtuMqwnTquJzuzKeux5//KseGq qg0LshqLqbf6qjRbshZ7sxsbrK46sEL7stdatCWbsWvqsDcbtEBbqUebsPwas+HqtFH7ZEqLtOua tSrbq+Y6sx9LtVa7rh17rIa6tlNrssUarW8btmjbthKbrW6Lri+HpF+KsND6pFh6pksauG66pUG6 twIrrz0KsFJauGOauI0LplpbsyKrp2qatYw7uYA7uFi6tw8LsJQbuH/bt3o7o//irScaiDdouqCR rKR7oSz6ugaHDbDLNK37nbN7u3tZu9iJu7zbu77rGLorKZoQvMRbvAf6u8ibvMq7vMzbosb7vNAb vdI7vefxDrTTvNibvdrLEtTbvd4LMNv/G77/8L3kW77me77om75aYQTqKxni+77wy7ztu36oa3zv SwGCM7+AqJ1vEb+IsxC3R3kTMXg9F3cGLHXLp7//AncSwcC593S3B8Gky76SM3mRFxEOfMGFF3i4 p8Dr4SwW/HUcDHQ+V8KB93QS3HS4x8D+GzoPLHgqTHod/HMHzMExTMPZiRnNsBv0YBkewGsKgXwb PMRzh8IF0cGjF8Ia7MHW0R4RPMS298IGgcQQTHle18KcU3krTMRJfMSkJ8VbXHdYvDjLV8YjHMAm HHVmrHw2nHxyN8Z9w8RyPMf1xb9uAcd8Q8d6vMd8PKIkNFRo1xH4l38HqH8SaIAVOFCe/3XIVWRJ SFdMtsF/j+yHlIGAP4WBkkV/17XJFkHJ6MWDoBzKSah0hCOEzZGDXoXJNaXJiOxrCfgVqEzKoizL nlU3pnzKvRSCDFVQmBV8JPhYfReGuvzHb7ZJyxTM5EeCAYhBxCyCQhWC2RR8wqVPaQhQipxZ2Ax8 obRg0LVNwAdQ3ixaiixap9ZuGWSC4NxZaojM0KFFkMVWVahTMUiFW1iFNZhNQpWE3FTLfjeC+QzP r5eFOQiA+AzQy+yC28RF9bxFrkfOCDjMOxiD8fzPEv13Cj1ZCT2DECEM/dt+FHWC9vyD0BxdWFXQ uhyEH3TSiKWBF92HVyWDAb3LmVxcav+H0AyNVj1FyDWI0wrdU2fUUipthgK9VYpV0hZUHAqlTT79 zyvNYCVN0Zx3TGHlWCztgBYN00tNzzON1Tfd1Tmt1KN8Vlm9eMb10pDVgkz90hhtbffRy+K8f+ZM TdDMXNP8zRXFy+z2x31H0828hClNUOtWXMh8zs78gcUcyNC1dmhH2KEVWi592A5tzYRdy3r91yPN 2Hr9XMJ80NnsyeXp2XFmh6FdyN9X2msNyKMNHF7gEPVLNYOcgKBdFK8dQYy8zLD9gZtc2y5EHH2M bq3d2xpnJ8DtfnUy3B0NHoJMyrENTXIY27pdgQdFUBHx3EIx21VNc0TxyJGz3K2sf0H/oYDaTV2z PIU+kXX8fIFDwd3A8dvc1T3T/d3v7d3iPYHz7RHmnd3pvV8wEtd/Tc6RPdjhzNzhLIbF7GbTvM57 LdfbvG7VrMydveDY5OB57VDlHNkK7sw0TdfZbOEQvtdkmNG9vEmIHdTXPFosAQjyRX0mzXhd3XkJ fclMDdYtHXsNnXZXtdA3LdYX/YIRDdUw7eI7xXdBftWO50iaZU3xDIAYDdFv1dJIqMpI/hwxh4Er nlY8xXm43Vgy/nciLc/GBNREHuM9ndM6+FV3TdG+pOOMB+anvcg8XYL5VNRK6INL2HhCHVTikdRm noV8XuOUTUg6ruZXjoVjbdZYrtZP/75Yqjxjfi7QS/7lUX3oLO7VkN7nMc2FY4XW180cjI3gcH3g lV3XP63NkN3NKS3OpU6GfR3YarjgE47qn17OvOzSoZ7qsL7hj63Zdj3ZoR7rkM1ceO3LE57glk3I 623Ho/wTkjwX6p0UzW5dpO1238Fd1N3eB1jtbojtdqjtzP7c1m3c4B7u4j7u5B6P3/5/adjJGm3Z xH4X3E7btD1RiHbueodeFqXbtT7eDdjqTRxlcabJxvzJBmjJMhZByX3ecOjoCC/frpzKeCje9+1r BL/w3BHLC2/bxm7tDH/xbmjwC5jaa/1VGjFdEf/wU1jyVziB18UbrrzqF25TnvfLI/8N7BCe7OzM zHNt4fM+4NLczPwNzrme4Gmu0pW+WAJughld8yno1hl+8wm/4UKdgk2f80APHDn11fuuVhMN0QXN 52T10wYd08Oc5AxN9lp9hGy9d6eN40Uv8kdP5UBF5lS9ymzPhWZf5Qkv6VAOPSVx9Q31gz619X8/ 9znPg9Gs5ISP0yCd1nYf0sqc+E9/6pF1WAW4T/kk2EVP0rss9ZA/8zMY52POQdzh5V6f6XOe9oH+ 5zke1nof0GRdbVzdVmq+0pAc8lY96YMey0VO1bUv6IpO6QovRSz/Wwzu6hrOTUyf2ckvzDYe7Kge 9HP94KdGzF8v7CPe7t0cXC6P89z//9h8veu4fue/buTb7/3Kb/ySD+yeH/3PHnrIDoQcD+2mzZ+j Lxb0DsvU/e7hWf/lThfDDxD2BA4kWNDgQYQJFS5k2NDhQ4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSZQpVa5k2dLlS5gxZc7k+M/mTZsNAQCIuHOjT3s8QQJFSFTgTp5IgS5lKlQgTqhRpU6lWtXq VaxZtW7l2tXrV7BhxY7F6tDpQqdnE6pdW5JtwbNC5Q6ce9RuUIJk9e7l29fvX8CBBV81W/guWsMj 3xKMC5fu0bpvB0+mXNnyZcyBiwZN2hmyXNB4P9tlCtfnac50T3tuGpe10tSr0xJV/+uaNt60NHXv 5t175NTISUULH15bNe7Dh40SD45cdPLmqOfmfv5YOenqajNv597d+/fLkbHjRpr8Onmjz2czv9vc 9Pjh44nHN1iXfvqz4PXv599f/+b74jPOsfaqY8y66QoUsC3IEJRPPegUpC9A3yq08EIMD5qKM6Ve k43D98r7kLHOQJOtwxOXa2y01VIbDcQXO4zxRbz8s/FGHHMcK8OJqDtoMR6DFHJIIot0K73jjFRy SSabtGdDJ5XUcUoqq6wySiyz1HJLIq308kswwxQTTC7LNPNMNNNUc00223TzTTjjdFIfOeu08048 VdKKgjH79PNPQAMVdFBCCzX00P+o8lR0UUZlQvRRSCOVNLNGK7X0UpEm1XRTTjvlClNQQxV1VFJL NfVUVFNV1SBPW6VKH1djJXRVWmuFU1Zcc9V1V1579fXXsGwVdtgzgTX2WGTFBCBZZpt1dqtln5V2 WmqjpfZabAEdilhuu/X2W3DDFXdccmvK9lx001V3XXa9LPddeFmCMt6V2rX3K3rlvXdfqfL191+T yBGYHHsGFniggwUaWOGFEU7YYIMWJpigiR0mOOGCD5a44oYzvrigjhnmuOOQPfZ4Y4tP3njilUF+ +CBTAKaVY4URtvlmmimueeebMwY54p4L7rlioXnG2GGXgx45aaN5LprlnYlemuL/nGVOdSqim2YY 54SgPihrqYseuuqpn/75Z5q91lnotIPe2mmxnW675pz5tZswsIc2G269ge46brE/Dtxmr7P+enC1 uZ57b7bhzlvvxSe+e3IoMTY4Z8HfXltzuS2XW/G+BZf6aLML9xtqtSGOGvDHtRb9Zspjx2ntsEv3 2+24Wz95c9RDZ5zv3n9fvfHBi8/ccd7p1lr2fRlKPHXDdf88+b4DJxtp1k/fO/rVU7+ddN0xZ9xw q2fm+vzhsy9eafa1dr/23L+vfv3rCd8c+eqrLl9VrBu+nGXP7Y5qFyuZyEYGQAImEGcaC6ABI/Yy kzlQZFFjIMRINkCXWQ6C/nsK//Pstb86EQKEGJrXCD/iwQ+aUIUmLOEK64XCa7nQJTBMlgxt6EKJ GbCCqhtg2UK2Mh6qzGJA1GARjXg0ImpMgjo0YgajRzrH/U9libvhmjbkQ/sJD37wOx8V6ze+6dHP baZrnP7IuMX78Q1/ZNwbDanVOvIBDnia414a83e7OYoRIeGT49nmWEfcEc+PeXTjsfb4N/UNsnt5 DKQexSdH76VvjIdD5B/x2MfjTXJ9VazT6BAovTwGL41xvNwQTQnJJQpwlHskpR0zmUjaXZKHceRk m+CIP0VuD5V2nF4kqahL9GnykHjkHiDVGMQ1NrKWXMKaH1t5yfEZs4/x2yXu2P84TVhCk5o6k6Yx pVfHQkprm2ikpPuqqUZqhs2bd2yfNQPJxzCyj4uwJFo4gaWQWZZygl8jWQP3GcEePqyUBcznAfX5 z5Ih85+pVOUQK4jQI/5ymWVq4URDYs9fWVSjtELCRj36rYp+9E0YpYxITXpSlKZUSWA7qBQfuEMf ChSJLm3oPv3XTwQK0YndPOgYFbrEImJQqKoMqhMzyDaaQlR/KpXIOuNpvPlFcnjPI2YYyVlNUM4T kE7dJva8etVzku1144QqUxNSuWx60ZVjC2Y5zzlV7bGTespbJV3nt0t/2nWstFtqMQdJS73ujFdo QAOn7JrMut5Rqm6VpiDreNX/rXJTkYszJ16F59jLBi+r2OSsLzs4WMIWNlKSfFxWDSq+0Q2TkVm0 7NigWFOqUs+TjTXdY4EZS0FaspIPdN1nfxVa0RoqlaXNJWkXWdx5YnKtZFUu637ozOe+VZe2vSZc NwtYwGK2aM0C7ph221dcnq12ZXvncv8a196il7nBfORyyXvcX0Ivl5lMLtraKirgNgmsZnRmL3Hb 3HZOdq56nOt+27nU9WI1qgG2qjAPiWBUETZD/cspTZMqQZdesKYL3TCHkVnQrx5xghaWKUDBh1Of Fq6JCOXniVn6xKJul6TbMWubZkzjGlvxxprJcY/xtGMgB3lKERBykWV1IXb4/1jJS2YysYz8ZJI2 Wco6hnKVrXxlLGdrylsuVpa9fDcuh3lLXyZzmc18ZjSnWc2AEXOb3fzm8q1ZznOmc53tfOcow1nP Q8KzveDQZ0AH+kt7hjM6CH1oixwC0T0OwaId/WhIRxpNgqZ0pyR96ZZUWtOb5nSnXRUNSSUiEZ4m 9aBEfepS5wjTp07EqD4QrlR3BdWx/g6mbX1rXOda17vmdb5ojZVZ/FrYwxZnr419bGRnmtjLVtc8 mP1saEebWeWQ9p1t/YJevyHZ2+Z2t739bXCHO0rVJne5zQ0pcaf7SedelxPSpW54x7vb7KZ3ve1t JXnne6IG0HdM7v1vgAcco46BELgH+31whEe6KliQlScc/nCI29MY59pJwS2uFaVcXONWyfigE27C 8pBw4xqf+MhNfnKUE+bjK2d5m1P+cphb/Aktp3nNCZKOHMd84zbPtc41znNc+/ziQCd60Y1+9FoJ 3eJIj3Q1nO50pd+7IE+nutOZHmZoTyHqWrn6o7f+dbDTuuu99sfYTdJRgAUEADs= ------=_NextPart_000_0007_01C6FA9D.F4147A30-- From akstcabanetmnsdgs@abanet.it Sun Oct 29 02:45:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge5M6-00054D-GL for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 02:45:18 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge5M6-0003Qe-Eq for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 02:45:18 -0500 Received: from arennes-257-1-141-18.w86-210.abo.wanadoo.fr ([86.210.92.18] helo=pegase) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ge5Lx-0003o5-81 for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 02:45:14 -0500 Received: from 212.28.160.48 (HELO linuxsmtp.abanet.it) by lists.ietf.org with esmtp (VZMX84QZP LMMLG) id YT93PA-2P7I1Q-O1 for capwap-archive@lists.ietf.org; Sun, 29 Nov 2006 07:45:08 -0060 From: "Johnnie Stephenson" To: Subject: oval-berried nickel green Date: Sun, 29 Nov 2006 07:45:08 -0060 Message-ID: <01c6fb2e$27e67580$6c822ecf@akstcabanetmnsdgs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3338.1 Importance: Normal X-Spam-Score: 2.8 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 "my dear, do not give way to such gloomy thoughts. let us hope for better things. let us flatterclaim an acquaintance with you-mr. bingley and his sisters." From iesqlvhqaic@ostling.com Sun Oct 29 17:45:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOt-0005Za-Js for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 17:45:07 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJBs-0005nD-0O for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 17:31:40 -0500 Received: from p54aeb896.dip0.t-ipconnect.de ([84.174.184.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GeJBq-0006hy-5W for capwap-archive@lists.ietf.org; Sun, 29 Oct 2006 17:31:39 -0500 Message-ID: <000a01c6fba9$fbd6c900$96b8ae54@Florian> From: "are" To: capwap-archive@lists.ietf.org Subject: am..YOU Date: Sun, 29 Oct 2006 23:31:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6FBB2.5D9B3100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f ------=_NextPart_000_0006_01C6FBB2.5D9B3100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6FBB2.5D9B3100" ------=_NextPart_001_0007_01C6FBB2.5D9B3100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stays heart wherever in amyou arethe or most am remarkable artist ever = am known? That fields marked with in are required am Subject Name Email in = Location Homepage Comment Subject mon ami is Name patrice address at = yahoo or. Stays heart wherever in amyou arethe or most am remarkable artist ever = am known? Special music stays heart wherever amyou arethe most remarkable is = artist ever or! Please am note that fields marked is with a are required Subject Name = Email Location Homepage am Comment Subject mon ami. Bkk thu am my a Dear am Fabio all in want say special music stays heart = wherever amyou. Can find for tune in Alleria is really beautiful in any in of albums did = meet Christos Athens guy some years or ago hi hat ciao gabriella rinaldi = rnaldi. Main igb Next Last a Please note is that fields marked with are required = Subject Name Email am Location. Most remarkable artist ever known and of ade Lisa Simmonds tsimmons = Kingston Ontario Services. ------=_NextPart_001_0007_01C6FBB2.5D9B3100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stays heart wherever in amyou arethe or = most am=20 remarkable artist ever am known?
That fields marked with in are = required am=20 Subject Name Email in Location Homepage Comment Subject mon ami is Name = patrice=20 address at yahoo or.
Stays heart wherever in amyou arethe or most am=20 remarkable artist ever am known?
3D""
Special music stays heart wherever = amyou arethe=20 most remarkable is artist ever or!
Please am note that fields marked = is with=20 a are required Subject Name Email Location Homepage am Comment Subject = mon=20 ami.
Bkk thu am my a Dear am Fabio all in want say special music = stays heart=20 wherever amyou.
Can find for tune in Alleria is really beautiful in = any in of=20 albums did meet Christos Athens guy some years or ago hi hat ciao = gabriella=20 rinaldi rnaldi.
Main igb Next Last a Please note is that fields = marked with=20 are required Subject Name Email am Location.
Most remarkable artist = ever=20 known and of ade Lisa Simmonds tsimmons Kingston Ontario=20 Services.
------=_NextPart_001_0007_01C6FBB2.5D9B3100-- ------=_NextPart_000_0006_01C6FBB2.5D9B3100 Content-Type: image/gif; name="gabriella.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6fba9$fbd6c900$96b8ae54@Florian> R0lGODlh3AG8AYf/AAsAAI4AAQB5AnN/AAAFgYULggeGhcu0zLTjtaDT/konCVcVDXQXA54ZAMQY Ct4VAwpFACE4ADU8AGZGAH0xAKc0ALNIANcxAARtACNgAEZSAGdpDHdtDpdrAMVXAedhAwB9CCuC ADyGCWRxAICFAJqDAL10ANOOAA6XBR2oBjalDGOWAH+aC6OcC8yhAOmXAAC0ACjHAD/KCWixBYi5 DKzDDsG2C+HBBgDcAC7SDDriCVjiDXTfDJXoCcrhANvTCQAAPCgOOUMCMmoAOIYAQpMMMcMKQNEF TAUYMhoiRUEfPlIfQIkTNqwYTMQsTtMbPwBNRxQ+NjU0R205M35ERKI0PMk/S+Y+PgBUTRhnPj9u RVNdR3FlDKpgRs5sN9tYOwpzRi5+NENxM1FzPXR7PZx1S7iOMthyNQCZOiGZQ0ekNGKnR3ugSqGW M8uaOeaRMwO3Nx7OTTy5QV23Q3bMMqq7SMfJM9e+TgTpSynjNUXtN2DhM4ruOZ/tRr3jQd7iTQkA iR8JikEAeGEAgIENe6IMgcUAfOgAdQAqfSgYdjogh1MZgHkVgJIShMYrh9UfcQNDfRhNjkdEdl0+ eXZFhKU2eMhJjdRAcQBdgRVufjJucl1meYBcfKFgi8FRftlhdQB2dymKi0yEgVSDfnR4f6aMdsuB htKDfQOnfiiZcUGYelKndYWsjZudjbmmeeepcgfAfiLJdzPNdl/GdXLCg6rEgMnIiefOgAjThybi hUDdcV/WeofaeqrbfsXied7YfAYBsxMAtjoHxWMOsn0ExKgAxLcOstELzQIuvBojxUArzmcgxIAX uqMgw8UUt+kmxw4xyxRMtD01yVtGvYk3za5Nsbo/zdI7yQBUuhVjtkldsW5nxHZlwZ5Yyrdqyt9j yguKzix/skh1ylJzuXt8v6F1wMWIu+2MzAKluhmoyTSXzlKZwYKrsZ2VvbOcuuapvgDMyxPAvTXE y221u4mzv5+7sfb375qepnNyjvQBAAD/AP//AAAH//8C/wL8+f/6/yH5BACU7IIALAAAAADcAbwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnElTpr2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnQq0ptWrWLNq3coVI9WvYMOK HUu2rNmzaNOW7cq2rdu3cOPKnUu3rt27eA+q3cu3r9+/gAMLHmwvr+HDiBMrXsh0sWOPhCNLnky5 5+PLGitr3sx5KcYPoP+FJgi69IeBplOfFlhaNGvVpFu/Nl2w9eqDsnOPZl0bNurQp2WL3j17Nu3Y vW8fH75ad3PM0KMTbOyad23rqLFXV/58e/bv1bFz/1d4O7z5892V/9Z+Xrz18uzDl1cPXr7Azvjz 65cqHn737/Bp5991BM5XX4CkJXhge+gVSOCD9fXm4IQCfrffhRhmKJR7Brr3noIIDUihfQ512CCC IhqUIogRJthhgP+RaJ2GNNboV0b00Sfjcq+FCOF7PA5XIm8x6hghgswFGR+S3n344HNFSifllBTp +J+V8Qn5I4xOqsgkgE16yCKDDapopo9OcvlhlFS26SZ5CxpoYkIrtnclnQsFR2RyxLGHZJ1L4pld jBzuOeabiLpppJaGZjlnmQoa+aiZUI5Zp4iA2inoepoaquehiYYq3aKQ+skooCamSuqZplrK6qIo sv8qq5ilfinqrdDZ1ueKqkG5a59J/jafnsIBW6GwyBaXXLLMLctsbLwKt+CPuFaLFXWG2WrtPzZ2 6y1nh2m77bfkljvYtlOaq+66SaHr7rvwWsXuvPTWa+9k8ear774m3evvvwAHTBW/BBdssEUCJ6zw wgzvdPDDEEdsUMMUV2zxxRhnrPHGHHfs8ccghyzyyCSXbPLJKKes8sos+yTxyzAT3PLMNGsc8804 56zzzjz37PPPQFNU89BELxz00UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZZF+3112CHLfbYZJdt dsJcp6322my37fbbWGObmMMO0Z203QavmxEAfP//AwBLfQvE998yCWC4AP8cLpDiAyFOEOOLG/74 4Y4nTjnil0ueOeaXWw5545pXrnjmk0sOOuenp155QoT7PfhBgUM0eOuzvy54363fjvvsA8VuO++9 A/877vHSnntKuR/vkuiLP17Q6s0/bxDz0Sdu/fWYR+849dQ7X/314GPfuPTfd286670TRHv6sqsv +Pt+w++6+/CvL3/8+OcvP+H232/t8co7ie9mAr3wrS573kvg+KpXwO8t8IEPLKDozCe9BjKQe+RD n/7qxz6HKC959OvgBvNnPPYFcH8cDKFimHLC4eGPf3/zHQxfuDsQ8i94t3shDt+HN8boJHwGdB70 /yQ4vQg6sIFDZCAElbi9JTbxIMx7YgPt1r/0/Y6EM6zi/UAIO//1L4Yo7CIHA/g3vVmEjCaMIRjn F78bzs+NG7yhG7MIRjh65HykW+ABi/g8yp0uiXz8oyAD2cTuXZCQzXuiB0WYwjfqkI3+0x8XFSJD 2+kweR+0ZOwKckK8sFCMj5xjGkX5SPqt0XWkVOMme6gQvCnSgJ8jYgbFB0Qkkg+DiLSeIWuZwUI6 8D4/DKMpTYhKO45wkiNEiB1F+UFOGuSU7tMYAEmYQjiukZRtfOYOU/m+ALIyIa4sHwR3CcQglvOX vLwlFCO4S0AaMXJH5FYwqelMekIzjtoU4TTFyP/FEtaTkaVMnxnPSMxq1k+OBu1mPhPKzEhmBJdK fGcihei9PaLTnbpcIvgsas52jlOiylThFxUa0C3+U5hh7OcwvbjQfa7QM6hUX+Bet7s2Gq92kMzk F2unxjeu75sI2YkfPRc5zm0vdH4kXR7zSNTS/RGpoFMdHosKuaFK1ZCQwxsmN1lDn+rumZb8qkxt ODzhDbCYVuTqTGcKTIxhpJOULAlQ9TJPpGlVX4QbKOAkAle4Ia94l5HbRMK6kE2OZK4Tq+vREBsv m2VGsXFhbMHOdrGNSJYrl+UXZS1mWcjChW75gNlmK4bThfowJ3ZxWD5WO5DVhvYgrBWIa1v7D9f/ xra2t53ta1tr293OFre5Za1vfwtc2Qp3uKHtbWxfu9vRUoyeE8msVnaS3NpaV7YG2e11aYvd7m53 uNkliG+9y1zeeve74uVud8t73fHK07k1eitAb1Vd8hZEu7hNr33Xe9/w6pe96sUuftur3/yed7v7 9ath1tfVmOYUM8R1r4DxC2D08nchFE4wggN8YftWeMPaHbCCXdIY4LHxmgGVblZAC+AQf7i+xo3w eYl74AovF7b+DTF3YVzj9MLXRvL9JzRNHJ3qStjCtNXxjnvc3/+GV8QDtvGSM1zgDY+YxJ5pJkkd quJrBdPIAT6ydZV8YSpXmcD9zXCUZ6ze2zIZ/7s/ju9FtJzNOvf1MGA+sp7ZvGQ+V9m9gG5zgclM 5gM3+cowYaFaVZnTn3r2LaoNLqCX62bm9jbGvHVzjCN83Epr2rb35bSeK83dOCuss6itC2gzImLo vNbUGnpbqx8za0Tb+ta4zrWugybYwz6aJl1mCKyHTZRdGxtnJSZsYfu6yl/PxGH8iDY//iHtaA/E 2gKRdra1Texuh0WLDLlz7oKtkp1MO9voTje1CXLuc6/b2/DmyZwrIm7DuPva+N52vu99bLtmeazF RLFNg2e/MjrbJj/kt7sXvu6GO/y98Y743kbq1Z7WuaR3wTa1q73vh2u830CTGzYbumU7kjsleP9r N7vTPW1+vzviMBe5FQt6yprf7+QoSbm6G75wl0875kBPykgLXnJ7TufgMTF3x5fOcnwH/elFITIW e9pgB9MU4jfBrE44vnGua5vlX4e62IOiQY7g/CRnp+vY1w7UO0cX6YmGO0TYTvdUyxQkaZer3B9S 9x+D/O+AD7zgX9LrreS9sHzvu+KLIlawyo6nqMaJSMK61bYuHuhBjutDsMnXvV6T4oO3tWFNu/nM /9Wl4A5907BFxs9/VdkAzCJa13rDwyvTsCO9/NM3sk/ilRKNNEcx51XC1Q66XfUhhylLDzp8Rl7x ks8fiO3RB3qD6/768k6rza2ZTEk2kq0qxHr/YSYPXUdj//ySjySDUdjClS6zkZbPOkjqaHyBov/+ ytZdDVPvYP2XNYcAaH3pN3+VRHDxd3+6Z3qDNV8FMX0hVTcIeH7zNoHdd3R2F3cReH30dnzhNnpq N4AYmIGXh3yEJ4KbQYJYZoJigYIsGCpMEQAw+A8wGAAyOIMxaIM0KBAzqIMxOBA2WIM4CIQ96IM7 yINEmINAKIMFEYQ8mIM7WIRFKIRIiINTeINHWIVI2IRJSBBPGIRD2IU/uIRLSIVbKIREeITip4JT gRFT6INuqIQ6+IZxKIc06IRz2IZzmIdZiIc1aBB8uIdyCId0OIiC2IOAaIRcWIVjSIiHKIiO//iI dgiHfFiIXNiCVvGHfhiIkRiIldiJkpiJfXiHYjiKlKiJeUiIkCiGWSiKbdiKbjiJiFiKg7iKp/iJ o/iFllgTmCiLgEiLj1iLeEiLdhiJvkiKk9iLB7GLm+iJb1iHr/iMcRiM0AiLrgiKzQiKzviLuYgw MJWNTYiFq+iNi8iMZliLtpiNeziE33iMleiLYfiN5viLxGiLn7iJ7ziMnCiNpCiKtxiNB6iG/MGG jmiP5liMptiJsHiO9FiQCEmOxbiM82iN16iEBEmReniRFgmMVyiRC8mP4riNF0Ed4iiMDKkQjciP 8qiHy5iSE6mRyXiK4aiK2OiPpYiOnFiI1P8Ik/vYkfTYgwBJGfnYjkFpjSfJi57YiEU5kDpJjqiI jBj5lLtolND4lLKYikd5lW/4k2ChEen4g1FoiOoIj2iohYh4j7i4kWP4juU4lokIjmYZjl9piFoI hXPphWdJhmQZl1iIlmVokCAZEYX3lx+hlZIhmHpHmAFpmIp5GIjZmA2zmJAZmZI5mZRZmR/omJj5 L5a5mZzZmRCTmaCpmZ45msAWmqZ5mqiZmqq5mqzZmiJDmrCZdK45m7RZm7Z5m4QZm7rZErjZm4W5 m8AZnMLJmL5ZnMZ5nI85nMqJd8jZnGmxnNDZEc45nWYRndZ5ndiZgtS5nb+Znc+2eN4Znon/pxTi iXCKhxEEkJ4E8A/qmZ4D4Z4CoZ7xKZ/v2Z71aZ/0OZ/2+Z4GgZ/tuZ7smZ8Bmp//eZ8CCqD3qZ8D GqAJqqAIOp8J+p/rKZ8U6p77WRAFqp8HiqEZ2p8EiqAV+qAVGqEZ+qCIxhQgGp/8qaIrmqIE4aLs 2aL9uaIsSqMAmqIwWqMwuqMvOqM1GqM/uqMmCqQ6KqNFmqM9WqRB6qM/uqROSqQ2mqREeqP/uHYX MaRCaqQHwaMYyqQ9KqJeCqVdqqRTuqViSqVSCp9AaqJYyqVpyp9DyqRIqqJsOqZNuqZuaqN5eqct WKdHSqZ26qJziqZ0aqcsOqdkyqVgWqdY/wqnh8oQE6qkikqjCDGpjiqlTyqjhNqohVqmnvqXatqh VCqibaqmAzqoG3qmIHqgpRqqrGqqhMqgctqppOqnkaqhXxqjpJoQF3qqSQqmmMqpo0qpkjqlBJpr chOraHqrmLqmv0qszmqgZhqtzQqsyhqkG8qpzhqrYrqtWqqr4Gqoz/qtveqnd7qsnxql4UqtAAqa 4/qoECqu1yqu3Qqs7xqm1pqpT8qtWXqmcoqo8Gmq0Aqv5/qmweqjqwqt/VqvVfqTgnqvmxqolMqs 61qxEQuloWqoF4uxHAuoOfqxXgqyiTqwn7qoBluw6uqx6SqyDSt2V0qfEqqghyqgC6qh/v95syHq oDBboL16qgHrqjG7sxP6s0NbtBNLszWLp+Wqpz/7okDLs0Trs3HqqzKrtDl7rFLLp+VJNVO7teLZ tV4LmMoXtivBnWbLmmSbtml4tmzbtm6rFjdDA2qrWW9bt0cxt2Frt3pbbHi7tXv7t4AbuII7uOTZ t+VJuIRruIeLuIKruI77uLvJuJI7uXULudlJuX9ruZq7uZzbuZ77uVODuTUDBRsDuqZ7uoMnunqL usAZmNOlumP3WbDrsjv3cRXBcdXWc9eGbVzXsrPrbfkWvA+hcEzHcMVrgb87NhnRcisXEcRbEMa7 cUzHumrDvPimcV9nbdpru8/rcNYbvTv/R703Qx0qp2/rZrzl63LSu21fx3Mex2/Ju3tdF73W6772 exDl23TnaxD3Fr9B53HqVr/pG77Ne2/5a7sP57+YZ8AB7L362735e7/3278KHDYXkb28i70fh7sG jMFeh73sC77iGzOuu2IVDDYjDJsl7GUn7DUpTJor/MKBZTIy/CanNmc1dXtoxRH5B4AR4XY9jHgT d3fHxIGU1ELH137RYcRJbMR4BX/5dE9CVnqaV3YL+BIuBUoPGG5WnDT8hyifFH71JMUhxIHMJsQU 4cQfkcWk18Zb7MZB88U3TFBp5cNyJEOvt1Y51E8Wh1N6TFOM1mhj3MceqMdETHBUF8gD/2d1PnVT jlSAjYZJFZfIk6x/AGd1lGxif5zIkuxVs3dTgHximkTJBrjIHlgwJaRSdhZKNOfD+0N/qzxJbIVQ LQXL7ddJvXdJBsVN+OTKwkdSsedINBRKtjxMBUd18Cd7ATVHxTxzxLzKpnRPqYxxBpNK4Cd80QdD 4FfGwPzM5bfDuEdMZwxJjTdG3azLxtxSBnjHvpfLrPzOMyRSrQzP17xlluzNmDzPozd8RCd1BMNN AG3PRifG/XzOv+fM4VfQVazK4nzOtGx8dEZyQ7Z8vBzQpkV08JzRrtzLE31xu/yAxqTQEfN/+wd5 kGzIgFx5ocw7kLfHXRXKALfS2xxwYP+1aIgsyizdYK2HyfvH045c0intx6VVyiTNyYgM063HaC3N U0AdcFsF0y5t1DY8tkejxlzcFl9MxVq9SMtXgVktNGjDNkHMV1aNxaf8eE08WIV81uX8MjFcw4sx x3BdmW8913LhWHatuXTGgDxc1hWYxn691RtNzg3B1iYx1g7lQYHdeYW9L3X9w3/VPiHhxEmMxmJ8 1fN31YuN2ZP9WDSzxpEt2B1B2VzdxYldxaBt2eQ3Epvtu2F9Ro5M0zlcU0i9yTo8yWflQoS82y7N SXRUzppMewFo1IYcRyit1Meszb993I3s29p8d7RNyn/8YDf9yLTnTz1d3GrlyeOifL//DM0dvX4H lUwkx8rHvFIXp8yDDM0NzVB7jFLvB94OPdDL/cwhXVDQLXDEw8zoXU02h87xLN5kLHt4vYHhTc/f R9+wo0nuN9CMXHQl9XwC197EXM/2NNPsTMvCo+DmLeFdbUwaneGvfN/v3OHbzGAu1ODoEsYHPnIJ jtHAh9DlXdEynswfzdEcPs/yTeH15z4wfuM6nlJR7N7uTOIujs497tEUzUM188nP7dRFHVNFjXvR LVYpbeUyHchQDeWNXHmNJ9wyLeUtbckMvs5VF+UvXeWXTHnRbdLIrdxs/uSj/NObjNzODcgFntms Ldls0dox4edZYcZRE8OITYGFbdgz/1HoXKHocqHojO7ZM5PXc5Mxkl7plu5vhXvpmFEyba3WsQ3b p83UhN3ogO7big3Kcx7YiN6BmcTq/XdSt13KFcHp/GfG/qSA/ATFVlHZPMzX3KzRf93Ypj3kKFV2 9WbFzXfarp0xbKzspj7YaSzYpZ7anL03vt7V3sd7qP3Gxb7Fx/7Gze7sAmPoYp7PwqxQNWfbTl7H o85SxU3Utt3Tw43bZr7I5k7Yuu3lhAzryITL0i17+/7qPL3moqzOlZziAh/bwi3IbRLGzlzR09TM w/zdJU7epj7hSF7fy/zeEb5D3fzQPe57EM3evWxSrIPMaTTfJQ/i00ziWBTiGKdFFv+9th0T8f49 0+h+0N784wK/5EQmy+5NQzOf5FdnU+/O8yG/w9iOTMQu5x6/4b8e0d1EWBRnze2c61Z+z31D6/qM 7UFv3lFv0Akt0CYP8zt+60kfyxcd5EanxCVf7BLNfl6P0WHv9jwf36pM48407m+1aLwd50aP5ar0 f049e7Ke5c4t+PTuf7O94D697vsM5pKM+Il/ybKex10e5veu+Pkt1ZYf1Lyt9KNM5s+96lvz1TRB 2pqOdlRt1tM+eaZv+p3J96tf+7Z/+7if+3At+9AO2M4O6ief+KW18I+u+6lf2kBc2quN7Ame48aP 1cgv7NWu58wf9cn+/F6xFJks5+r/fUXvXu4WB/67PfmDv/2fnsWanN6J1cI2wt/fHc8jj/Ev//Dj jfF5j8wPzfJJ39HSx/7tDxD//gEQSHDgwYMAFBo0KLCgQ4YDFzp8WFEiwYgIMyqkWDBiw40aEYrs SJIkR4oN/9lj2dLlS5gxZc6kWdPmTZw5de7k2dPnT6BBhQ6FGTLhQ5UjIS49WnJkSKMfnVpEeVIk SItWK2I1uZLoV7BhxY4lW9bsWZZT1Tpd2FbiRYwcJ6aMG/diR7ko3bblW3eux5QQ876tOvevYbd3 NRZe29jxY8iRJU+mXNnyZcyZNW/m3Nnz58hc2YImXdr0adSpVa9mbTlo69N/8SaF/+0Y7W3cuXXv 5t07Z23gwSX7Jl7c+HGwwJAvZ97c+XPo0aUfF17d+nXs2bVv597d+3fw4cWPJ1/e/Hn06dWvZ9/e /Xv48eUHn17f/n38+fUjn9/f/38AA+xoPwILNPBABBNUcEEGG3TwwbAElHBCCiu08EIMM9RwQw47 9PBDDiEUcUQSS3QQRBRTVHFFFlt08UUYY5RxRhprtPFGHAc0cUcee/TxRyCDFHLIE3M08kgk1SJy SSabdNKeJKOUckoqq7TySiyz1HJLLrv08ksww6TwSTLLNPNMNNNUc02zxHTzTTjjlDPH1+ZkjU08 obNzTz779PNPEMkRlJx/BhXUof9DBRpU0UURTdTQkhYllKJJHSU00UIPlbTSRjO9tKNOGeW001A9 9XRTS0/ddNJVQX0U0CmD4lRRRGu1dVZKadXV1kxBjZTXQnmtNNhdMXXUVWBHRbbYXYllVddhlaUU 1zyrZXBYZhm9Va1nncI2WmKFxTVcTLsFltZZzd023XN7bTbcZtlF11Zr60UQXnJrNRdbYb1d69Nc 581XYHWnAjjYgp3NF1d5v/W1X3mJtXdiArUVtVyBLQ5Y43gxhpfhgRVWt9Rnu+XXZIUvXvfhZFce mGKYc+tsZGjxxffkjTs2FuRxS34XZ4RrftjngXlmOV6Xx4V1T5rJBbpdcDeOOmT/j53++degUw6Y aKWLdThno0Ne+khZtzVb6JuzbRlptamWOme1le65X33h/jrudmPW+6zMIFWVVY/9TlXwact9VFPE GU482VJNddZwyKFNvFWdXY388YTHvrFOzTvb+/PnOvcMdNK/Ev101FNXfXXWW1+ac9dLK312sUTF fFXCVdY4VNx5F9zQySEflVTgC/8bYMKBF97yk409V/lLi5eYduqHsppZlMFee2u08Ua7abevTvlT uYWeeup2xc8+5erbB+puft+VH3Coj357fvu17truXOPX3tenyS9r9gOa+wzIE/9pTYBAQx7W0hc+ kNlsX2d7nr+4BbcBVvBX8fsa/7UO+MGbROtwzuMg1ojGP2/9jnivGprvnJe2FBoMgwfT4NAcqLvp gXBvfWNZwUpowwyK74brW5/ZohZAm2HwYxu8YRJzB8P9xW5M7+uhDJuoPyT674hNZCDbLPjABc5Q gvlDHwwDpsPPaeZ89xvi9mp4NJoFcG5eNCPdCMjGMdbtjUuUopFU+EeDrfB5lytco5TnuEKm6mLJ IyQOjZdISBZycYhcoSH7iCHYXdJzaNSbJj0ppkx+MjOcJKVLRKmhUjbolBlKJXNW+Uosce5b0vtb CoN3LNudSpLLs1wuAWkqWlrqhbN8IjFfiMNGkoyX7kKkMHsZvWBS0mOtXA5n5P/oxqLZUX/cU+A1 +fjN/XXNm/XDnzabtyxwitGOmupexDIHy9PQEIpwdKC0FPjFPHKzi+usZ//umLG25bFqeswaA8XJ xP9dMILwfEyd5NnBf/Jzghckpz/LucZyLvFu2KuiOhsIQD120YcItaIVI0hN/qiRjvc85yJdxrGE 1i+cXnyiLrkpxJE1bp/yFFn3zFdHgF4RlwtlaGqSB8QHNu2E6SujEz16vx8aE4U29alAg9rTe44P qEHMH0irWlSnvAajFExiN70m1Kb+8KJQtSD6DprOfJ5tmARbK0xxttEEZqxbKE0QXNsGP7ZtMYwx narY5sjGsRpWmzRVZ/j+2sb/gOZ1gNjiK4IMGbzh6fSyfiOVIxXpTFsyT7S5ZGYlAQdNQQLTcKOl ZC8xB9rWRkqZxJQtISdV2eKAVbd0AspuA4Rb4vhWuMMlbnGNe9wrAVe5y+Ubcp3bIeZGV7rTpW51 e/Nc7GZXu9vlbpxykSTrhle8Muluef8zXvSi17zrZW973fte+MZXvvOlb33ty9D05le/++Vvf/37 XwAHWMADJnCBU3pfBCdYwQtmcIMd/GAIR1jCE6ZwhUFjYAxnWMMb5nCHPfxhEO/QwiMmcYlNE2IU p1jFK2Zxi138Yhj3xMQzpnGNKRNjHPvIxjvmcY99/GMgB1nIDs5xkY18ZP0OgVnJS2Zyk538ZChH WcpTpnKV2YNkLKvSylvmcpe9/GUwh1nMYyZxls18ZjSnWc1rZnObq0nm+LpZznOmc53trFw451nP crpzn/38Z0AH2lp7dq+gDX1oRIeO0ItmtJYS/WhIR1rSk3Zlo8tLaUzPxNKb5nSnPf1pUIc6TJkm 9UsCAgA7 ------=_NextPart_000_0006_01C6FBB2.5D9B3100-- From ssmxtswag@orpheo.com Sun Oct 29 17:45:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOt-00066D-G0 for capwap-archive@ietf.org; Sun, 29 Oct 2006 17:45:07 -0500 Received: from p54aeb896.dip0.t-ipconnect.de ([84.174.184.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJBt-0005mh-55 for capwap-archive@ietf.org; Sun, 29 Oct 2006 17:31:43 -0500 Message-ID: <000801c6fba9$f7717310$96b8ae54@Florian> From: "Subject:" To: capwap-archive@ietf.org Subject: DEAR FABIO all Date: Sun, 29 Oct 2006 23:31:24 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C6FBB2.5935DB10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.4 (+++) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 ------=_NextPart_000_0004_01C6FBB2.5935DB10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6FBB2.5935DB10" ------=_NextPart_001_0005_01C6FBB2.5935DB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oct in est fratello will have the pleasure to a see is you on tuesday = about. Perchmi piace molto la tua musica quando passi per fai sapere dove suoni = citengo sentirti presto surprise snobbie ndtiamzon. Oct in est fratello will have the pleasure to a see is you on tuesday = about. Patrice in address at in yahoo dot com sun oct est fratello will is. Fai sapere dove or suoni a citengo sentirti am presto surprise snobbie = ndtiamzon a gmail or bkk thu my Dear Fabio all want say special music = stays a heart wherever amyou in arethe most remarkable am. Di te come nonso perchmi piace molto la or tua musica. Address at yahoo dot com sun oct am est of fratello will have. Hat ciao gabriella rinaldi a rnaldi napoli wed edt cercavo tuttaltra = cosa ho visitatoil tuo or sito is mi am ricordavo di te come nonso! Perchmi piace molto la tua musica quando passi per fai sapere or dove = suoni of citengo sentirti presto? ------=_NextPart_001_0005_01C6FBB2.5935DB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Oct in est fratello will have the = pleasure to a=20 see is you on tuesday about.
Perchmi piace molto la tua musica quando = passi=20 per fai sapere dove suoni citengo sentirti presto surprise snobbie=20 ndtiamzon.
Oct in est fratello will have the pleasure to a see is = you on=20 tuesday about.
3D""
Patrice in address at in yahoo dot com = sun oct est=20 fratello will is.
Fai sapere dove or suoni a citengo sentirti am = presto=20 surprise snobbie ndtiamzon a gmail or bkk thu my Dear Fabio all want say = special=20 music stays a heart wherever amyou in arethe most remarkable am.
Di = te come=20 nonso perchmi piace molto la or tua musica.
Address at yahoo dot com = sun oct =20 am est of fratello will have.
Hat ciao gabriella rinaldi a rnaldi = napoli wed=20 edt cercavo tuttaltra cosa ho visitatoil tuo or sito is mi am ricordavo = di te=20 come nonso!
Perchmi piace molto la tua musica quando passi per fai = sapere or=20 dove suoni of citengo sentirti presto?
------=_NextPart_001_0005_01C6FBB2.5935DB10-- ------=_NextPart_000_0004_01C6FBB2.5935DB10 Content-Type: image/gif; name="Main.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c6fba9$f7717310$96b8ae54@Florian> R0lGODlhoAGQAYf2AAALAIwJAACHAHmKCwkAeHkBggCEeruzssvSy6rX+TcsAGwcA4knAJsTAMcc DusSAABBBxgxADRGBVo9AIJNAJ5GAMk1ANM3AABoAR5ZAjZgB2ZhAHpfAJFVDMlYANdUAACJAB9/ ADaHAFl+AIiMAJV9CcxyANh6AgCZBCeZDUSUDmSlA42mAJ2rAMylAOSXCArLAC25ADezAF/DAHHN AJzIAMrNAOm/AgXnABfaAErnDlvaDXfeAJbuAMLZA+PuAQAAMSwFMjkDRFIDNXEANKYNSsAAPdwA PAAlQRonTkIbQ1YWOYkRRagiTLwcO+0VTgA+QhMxTkU2QW5DM4BDQawyM85NR9w+OQBVRCJRS0tW P2BlP3lXAJRRRLRnQ+VRTACLQxF+S0J7PleANXSMNZ6ER8OGPdN7QQCrPhuWTDKeR2WRSoubQZWo QLeUO9qlOgC0SyzFRzTKR2a1QIzDQZOxS8XMMuO3Rg7ZNBfsTTXpMm7gP3raSJzWMs3jMuXcSAAA iBEOh0kAhWAIjoEAcp8AcrsOg9QOfAAhhCYYgTcud2wVcYcmjZ4XcskgfdQodQA6hRZLfkozdGY4 goc6haRGeLgze+VEgQljcSdaeURZc1NhdHxniKZdjMpme+JadA1xdCGLijp8e2V8d36KiqVyjsSM f+CEfACbhxmagT2Xe1mhjn2fh6iig82YhOKfhACzeRHAeUa1jm66dHuxe5XEfcuzcu61gwvijSfW h0DtfGTbcYnng5TkhbPritnYhggAtCkLxzMDwWIGv4oAyaYAur8Fx+QAuAkUyCkhuzURsWQtunMb waAhvskozuUUxAAyyxJHxzw/w2Y3zYlGsaZKtsVOx9tKzgNpyihczTNpu1ZduXZtvqdry7psv99m zAB/txpzvUiEulWCuH6Ht6iFusOKvteIywCltxWsuU6Tw2KUtXeavpSryc6lsdmuwgO9whqyw07F u1S2x3G9vJnLy//27Kudr32MdPgAAAb/C//0AAAA8P8A8AH/8v/+/yH5BACapXIALAAAAACgAZAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGNetEezps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qVOeMqNKnUq1qtWWT7Nq3cq1q9evYMOK HUu2rNmzaNOqXcv259W3cOPKnQu3rd27ePPq3cu3r9+/gAMLJku3sOHDiBMrXsy4sePHkCNLnkw5 5eDLmDNr3jy0sufPoEMb5Ey6tOnTe0WrXs26tevXsGPLnk27tmHUuHPr3q3Vtu/fwCXyHk68uHGc wZMrXy7wuPPn0Dkzn059dvTr2LPnrc69u+qi3j1r/x/fObz5847Bo49Mvr3biR/i/5NPML79DwPv 68cv0P78/vvV5x+A9xXkH38HDaggff0ZGGB+8uE34HwMEkhggQI6iCCGFPK3oIfrtabehgaBWF+D +aFIIYom/peiii7GWGGJJ75oI4sqbtgijDaaiOCNOdYY45Ak/uPekU7l+KOLS+54Y5MG0kjkkwr9 aOWJS/II5ZBc8tglhFF2ueOVKCJp5k0VkUimjC+umWCYNa6ZZUJyRjnnllIC6eWcDZKZ5ZhUhkhd kUWyeaGDCOHZJocAOgQioHvCqSGjevLJZJt5PgqjpYJONmKPQYZ655+S4vjligtpOmWkQpZ6Z56Z mv8qpKpknmmrUaH2iWWriboqZaGwvqkqhBMCyaeildK5q5gpDlvmrdAGlWujzfK6qa9hAuumsLoa iy2m1jLba4bi/uesi9Gm69O0WvrKILKrxvsuQ9siSyq7r5ZqrbaSWqquexQdOKOi+z068Iwd6mil hB2C+eaT70b8p8TEaijgqAQXe62+nXZsFaceh0yXepCBrNy/7Yms8sqWoezyy8exLPPMIMFs8825 0azzzjz37PPPQAct9NBEm4Tz0UhrVvTSOift9NN+MS01y1BXbfXVWGeN3dRcd+3112CHLbZUWpdt 9tlop6322my37fbbcMct99x0V+2CbmPnrffefJP/XfffgAcu+Jl9F2744Ygnrrh5gzfe9mfIORQ5 0JOfdxbkaEqeOeWbW24W5jY9VLnPo4d3+T8ApI46S6oLlDoAM3W+EHIC1C7AP7YLlPtAtxO0u+61 +25777gPf7vxwSN/vPHF/8578sTnjrzwwT+/vPXY3z467K6/flDrEL3OPerig+/9+N2rXv5A5rcu PkHrk8/9+QMtRdH44KuEPvovRa+77wUhHu8MIsD/GRB3A+ydAhHIwAUa0H8BHKAEGfjACR5QgBAs 3kLwBz/2eTB8HVydCOfHvv19kIOuCyEKPzhCFoqQdQXhH0rMF5UCUvCGx4ugDgF4QYTY8IZApKAN /6OXwQLm0IfPk6ARN5jCGDbxhQ2RoQldCEUpspCGUHRiE0kYQhh+z32w46L68De/MKZPfh3kIvm6 10I2PlEjS7TgES14wAlCMI47rGAPd3jEDOqRgAn8YxSpuDrvFbKEbFyhC6doEDU+kYNqlOEjUyhJ SU6kKJU8YRjNuMZDjpCTimyhGBNpRkeWLiGRq17znOfAOrpylURU5SuBODzr/fCOQuTjEJXYwINM LpRtXCMo3fjGNzIyIe0zpCjhJ0Vl5q+D9pNIJrdIzReWcZTBPKE13UfN94mklThkJSDz6EA88pCX grTj//xISz6uc5bIJGQkKWlI/llxkQ5x5CjvKf/PLBZzhk5EITYhWU2CarGTA6WkScDpR3YGEYPw vGUe07lHDbrSnLkE3kUVAsx5epKK/KziQbU4RTI2cqTV7GLsOiNQbbaRmwlV6EhjSkJTyk4hOMGl Onf6zkCis6LnrOMcdylUOQI1oxXt3S9VusKaphSfKrXmQfVpzElGVarQ/BwaS3hNYZaSjOvDIjOb Wr5NetWDp0RITnfHVugp0K3SY970YBnLAKpyer+7q1uVyDzgybJ5gBWqKiu3P2V61axgbOYzDbtV eia2nlj0ZiHzB1kuns4ilmQiSdLqy5vyjLDc4d5lK5LZeJaEs6Px7M62R53xRXOGz+RoaRdH29r/ 2tY1JMMIaueyW8Y5bic7y8dtdxY/lMomH8gdCHKFe5DkCmS5yv3Hcp0rXepCl7nKnS52oVtd6yZ3 u9zt7nO/C17hate5zMWu4cADTNGptjA4Ma905/tcg6hXvfTN73ajO177EmS/+q1vf/MbYP4SOL0C RrCAfwvcibTXNvIVMIEnTN0CFxi/+KVwgguC4QnT977ZNbCEJZzh4Z6UnluFLCEpE14A17fCH/6v gRWskA5b2MMepnGAdaxhEZu4kc50qidny2Ia35fHER5vi0cc3hHHOMQ4zrCOAZxkJ4N4vUTxp0HT h77exiVy8nXxjed75Q33WMZolnKU/Xtg/lb5/8zzZXBTtOzBY9bvvSPLXJhFLGYyo9nMNv6zmWXc YTW3mcSBZrKR5Ozl7514yNkMzZ7FTGlFu5nPbCaxpi1c5k4LGsc+/jFXx4rG9q24yOV1M3ornF7t Kjm7MO5ui8nLahhPl8OzpjSrQ7233K60Jo0Bc0ZKrBrmMrrRUiM2aJSdN19bBNlXgXZ1jo1nUVs7 2lk+ibRXsu3ZUftI1w43aCQbxdnGljH8SDc//qHudA/E3QJRd7zlLe7aPNi0HI3MuuPN736zmyD7 3ve/6y0ZTJKWIV2udkxwIvB3O3zeD2/4or+dMgeTOqzdBKtLGyNxgXt84B8nOGXUI9YyChOhWP9N eOjqkjl4s7vdER84xCdO8fFcBJsvlWpLKRNwgPd73RKXuchps+V91nnjkul5zGfu86E/xuCT3Dkn P2rTlb+F4Uv/edM/XnOckXubiN2kxktNc5p8+SYwf3na6Q1yenedPBwhstPnPhK50/3uBHH2uTPS 7ZZZXSNvt9ltFK7twJ9t8H9/ieFfpjK74z20e987QsrqeKkYtrCVf3x6skzkyuNcmgXp+yBB2dSy L/5qncQ3CG8eesLfL4ulPz3KMPvFT56RsbA3udjNmmLY2vOKml9Nbn9/8mBOs6DD/Lzp685IDsr+ X6zvYlcjDVJuirKeLpl66YPfWrLLdMszTan/9U9tEu0Dn/vM4ecwZfronIuU+uWn+vnRDxzcc3n3 p758Wc+Y+vGXP5mjRn8rk3mPRoB1J4BBY4BThYBe42wPIXkRYX+plXgu8XxZw4BG83YYuIEc2IFX EQAg+A8gGAAiOIIhaIIkKBAjqIIhOBAmWIIoCIMt6IIryII0mIIwKIIFEYMsmIIrWIM1KIM4iIJD eII3WIQ42IM5SBA/GIMz2IQvuIM7SIRLKIM0eIOJAx5D6IJcqIMq2IVfCIYk6INhuIVheIZJaIYl aBBqmIZg6IViGIdw2IJuaINMWIRTKId1CId82Idk6IVqOIdM2BwWuC5tyIZv+IdvOIiMCIiI/7iG ZSiFkiiIiXiGcuiHUpiEkbiFnMiFgWiHlBiHmmiJjiiJT0iIXUcRhxiKbjiKfUiKZjiKZPiHrjiJ gdiKB7GKitiIXTiGnviLXxiLwPiJnfiIvfiIvviKBJeMPYiEmsiMeciLVkiKpZiMaTiDzXiLg+iK UdiM1PiKtFiKjqiI3TiLiyiMkxiJphiMiqMe0EiO1FiLlciIn1iN4hiP9CiNtbiL4WiMx6iD8AiQ aDiQAgmLR+iP96iOyViI61KQ+AiOC7GH6giRc7iLFDmRmJiLlviMmYiM7EiJ1riIFXmOG5mOCSmO LWiBPNCQGfmRLdmIEsmKMDmTIlmHMbmPl//okNpIkDLJkw4ZikDJkTTpkykYeBZxjS8YhHSIjd6I hUpoh+V4igc5hd04jU55h84Ylc+olHSohEDolU4olVT4lFyJhFNZhfLogWppWw64lrqlgW4ZlxPI kHQpHXJ5l3iZl6ZXl3zZl375l4AZmII5mIRZmIZ5mIiZmIq5mIzZmI75mJCJNHo5mZRZmTTTApaZ mZqpEpHZma+1mQzomaJ5FKC5gaN5muVRmgiImqz5Hqr5mrBJW605mw0Wm7Z5m3xDm7qpFLhpFWvT m1WBM8D5eOBBAMZJAP9wnMY5EMspEMfpnM/JnMopndMZndA5ncxpENWpnMiZnNbpndbJndT/+Z3d SZ3XCZ7eaZ7nWZ7QaZ7ciZzPGZ/LiZ0FIZ7XSZ71aZ/aGZ7lKZ/sKZ/uaZ/dKZwS0Z/OmZ0HiqAG ShALmpwKqp0ImqAR2p0G2qAS2qAYyqAQKqEOyqEYyp4eOqEXmp0WqqEjGqL1aaIq2qEsyqIg6qIq uqAv2h1F8aIf+qAIkaEpuqMp+p8bGqE/qqMtSqI7CqL9KaM8Kp0iyqMVyhBCqqFGmqQ22p4nGqNP mqC/GaUjSqFAGqM4OqQd6qNa+qUzCqNVyqVECqVBGqYcmqNsmqA6WqJrCqdquqItOqUOiqZg2qRm uqC/mZ73iaT/aaPkGZ772Zx0yqBHiqiA/6qo/Mmo9PmmVMqkB6qn6Gmi8DmeapqpSpqjhQqpKAqk eMqlciqomoqlaoOpqpqnP5qorjqqjjqjaIqnouqqkgqeYjqnnDqmD4qkRMqpdvqltxqpvAqrrNqm fZqsqJo2q/qqtGqrz4qsPlqkCVGs0NqqvrqkgMqrFyqn2yqrbnqn2Nql09qsiEqrR9qlHbo22Tqs VXqmdVqp8SqplnquUgqvaYqv72qhz8qv2uqtZiqu5VqutRqquWqwK8qu0fme5wmn33mpuLqdEuuf 67mw4hmpEUuh5/qe8NmcFIueH3unDwuxGkusE2qxjjqeEluxGHuqJBuoHRuzCiqgqAgzk/9ZpqGZ bZqHs+JxM8P5s0BbNLs5tPYQtEZ7tEibtJ5CtEzbtE77tFAbtYGptFRbtVZ7tVjbm1K7tVw7mFn7 tWD7G13rmWF7W2PbmWWbtmrLGmcbmWu7OG0bt3JrlG9bt3YLGXObt3orZ3d7OG15dXsLNYcRuILr by+XETDXbh63uAHHdntJuIJnuELnEB2XdSGndYYLuWZSEUDXdBBRuQVxuS6ndH2bHJ3rcKMLb+62 ui4nuaILcg8Xu6W7eeVBuqorc0pHugDHuKPLbw3Xuo+ruVtDEWmHu8YLu5O7dcr7b0EXdLMbbFn2 u/52usiru6FruLbbvHknvAAzEdJrvCH/l7vXi7nki7zJ+7yMURT0tr6p+7vy1rprp7jzFr5st27c 273om7/6u79u+bf8K3xg8b9h478CHBp8UWqZNUYQ6GCSt8CTV24GqIBAxkz/5MDlNnl2Z0kSjBie l0+ZFRYWB3/aVFr31n6Olm8H9xLE98AojHCqBzQlbBUrfMJTd8L+9MImnMOrl33GdVU9bMM63DMx LMNpZHIZZ1IIbMTqo0K8F1a6N0YphsSahFDnBkYxZE/nE3aQNH1aPGpLDID9R1lhd1ZQDMXyg3n8 V8b450Zq3FhUTMVmfMZtfMaIFMe9Z8WFVx4mVVLf537ut1h1vEwftU19fHxf/E/sZ8JC/7Z+i1xQ U2VCjexIZLxFjFxKVSV/k5xNuvdUYmTJIjVQnkx8Syx9oRy8a+FSXFzI2EfJ/mdVyUfJVjVZeHx+ NUzDWCzKgmx0KkRnjzTK+CfJNOXItsdUqCzMqyxkXAXKARhZsExSxdRS78MXCTXNiZxyxgXNfSx+ R4dS2NzCfLzLjSzIV6R+3ZTIwGzM6Hx81vzH7ExMz2zO1azLJ3bO5XxnX8HAXaXAlBfGSpzPYix2 h7V7ppbFAL1YCnxYxvR1dByAdPxYB73KVxzF+izRGqfP70N5An3LadzGQebEiEzQcnxNTnzRxRXS qYfQB52BqfkzG8zCczHELrzD+QRS5P8H0xEBwnojgQx8GDr9gBZ80j5dSQvc0yy30gUsIgF81F1D wEq9GKfc1FPD1DgcUiDx00CcEVadwhQc0eHT0ljtwBKc1RiRwZ11GR/h1RGY1iGReWTdwj6sWVUd 02jt1nHNd2ohE3P9gGpd13o9SHSNyHB91jFNEnmNw6wBxh5txQ/Nxbw3wWTsTBs9WbfH2ECt2NPH ZcuMx2rcxKGkYigtUI9FSm/82Brtxhw9xm/c2Ji3yZWFxBM9y2J8VjBBMq8MaYM8T6B9w/K82+6M 21M8TYcMe+xHU+v3fnxMzeKszMG9ycL9VKLdybZNWe9se1L3Ur49yL9tyjgtTaNcz9D/bXzrLNRi lXM713vD7dzHHGnI3MnW51EQfX0whdmYHMzepHzlXczkDdHv3c75PX5bPMvCrHhEgcy57MpRh9/c HN4KDt7Vjd/FXc9+HOCMDM4FGFAODuEBbuDOzM64rN4SjuFYhd3NTUKZ0dCJdX/1vdkSvdBezNn+ zNgqXlknvc8TzdBBNtljTNDkRtKKBNIdPdmfjdqZjcYWncVJjOJovOL8d+RBXtlOXOKDvdYyHReF zcOf4XhVzhBQLltZ/tYY3OVnLdZVQdSLQeZuvFl3DdVqvubCobNsLhp68eYAjBdLTlpgjFmSPFYk 7Rhi7sEeDFaSpdBdPdaxBdYpHcRb/83QFBHnD4blUhx9KKx8VNHWGwHTDe5RWn3VNDx/3hzl7Sfp gG3PdzHD5OfYQJ3pgX3DljfTcVfq033JGkHCnh7inZ7q4ffWs6UXGp3Sip1GVGfZmA3ZAB5VnA1k lL3Zrp3jAPjFY2dqpCbbaTzaNA1VtWfGvV7sZy7jyyzttKzsRpztmR3ZbKTrFt7OgFzKsFzbEa7O J0dV841YnJxI6I1I26zu3d7c7Q7r+k7C8D7F0f3qeb7HHt7L5k59ne3IrpUXvwfKrXxIxa3MC25/ uLzj0ofOn4TcFX97jvXtC07LLI7v78fC7E3w8r3CAT/CjLV9DP/gG3fMKsboFw7yFv9P3hkfzgku 4iEfzP9OyAtY4CHV4B6vwdPO6TTP4K+u4TWv6iqf4e6u81YU56Zt5Eyu8dqu4ydu0hdt4yr+7DK+ 9SHdxNUe2jx+6l1fWAh85tlu0LuuxXt+9Wpf55+N9j/u0RSt9cHuzzW7FWXu6qs+5Xcr1Sdh5nj9 030el1Av5wbsFYg/NIDfNPer+Ezz+JC/QWyd1w1f6fx+xQLNxlef95L/FKw+2HJH6SJhbru8zhH+ +VwR+nA9+qwv5W5t8myMyKq/Fcou7t2NfcNu5Kp92vL93G0P0Es+w4GOydtb+08B3bXN8YTM8o8+ 4fke8tYd/ebHy9Zcw/yD/D0Rwrr/vMbkLMuyr/Hm3kzn7fNI1/LNzPdfC3XdL/PX79LtX/Q2zMyQ dt84595vpP1Qgc/Bv9hYDBD/AAwUCKCgwX8JCx5MOJCgQ4gOD0pUSLBixYcGM2JESJHhxI4WQyIU qNDkSZQpVa5k2dLlS5gxZc6kWdPmTZw5de7MSZIkyp88hQ4lWtToUaRJldpj2tTpU6dKpXJUaXFq TahZtW7l2tXrV7BhxY4lW9bsWbRpuV5l23aoWrhx5c6lW9fuXbd59e7l29fvX8At7w4mXNjwYcSJ FS9mvDXwY8iRJU+mzLfxZcyZNW/m3PlyZdChRY8mXdr0adSpVa9m3dr1a9irPc+m/13b9m3ciGPv 5t3bt9HcwYUPJ17c+HHkyZUvZ97c+XPo0T3/pl7d+nWU0rVv597d+3fw4cWPJ1/e/Hn06dWvZ9/e /Xvu2OXPp88a/n38+fXv59/f/38AAxRwQAILNPBABOeqb0EGG3TwQQgjbDBBCiu08EIMM9RwQw47 9PDD5iSUD0TwRDTxRBRTVHFFFtsi50Vy/oHxRYVoTAjGG3Gs0cYZUcIxRpOA3DFGG2Wk8UchdTSS yJOUzDFJJZ1cckkkh6QSSSCxbJLHFrtUqKwkb6xxTDLDDFJMNMk0skkf1ZRRTSHfTLPIHbd0E0o7 50xTzizRjBPPIM0k8bua4tQzx/8yV+ozJUP/lBNOMx8tclE3xQyT0kQvrXTNPR/dU1NLN/Vy1Jca hZNPUSVllCUmzwxV1VcxVanVN2VFFVRUY2XTVT1xNZRUFMtC9MlJXx2WV07vLNZTM2ltNtcnd23V 1kWnHfJZU5HF9tBBvcsJ02o97fRXR7V1cttDrUXWz1zJZZdSeI0dl9c+4wV2RWET1TfZSt3t985T j42Uy3VvZVdaXTuVNFuA3+W22/ee3RfabCP9tGFYD2UW44AzznjgM8v9t2OLE4I4Yh1n5HHZHgMl UkpirZxSSz+PXDbmLaudNEqCsaSZWTqplDlLgk/e7l6kk+YtX6VRM1q7pqOW+jT/pqde+umjre4N 6+C09vrrwPL9kVibVfaRZ5mjVZlOs8l+uWWhyb6W7bJ7JJrutuO+9uxfxV377ZRN5ho3mwBVNVxt OT5YVpAPhvbjjhcP1WLERRY51YodtxXs+hjuW1yFid6U4V09nhdhjdtM/HPFa1VdVFrX9Zfz18BU 9PTSMw09d3r3RdzVxmdXGPTE2RSe+NhHFnTw2wp1GWfYVa/39eGv3Btnf+HWe+SzZy04eb9XBb3R KGl30HPcv3eY98/LtZdaxx9Pn/rWwSf9etlTN58+9MXnneLjtQ949MvexbxXMAReTl7z21j+/rc/ +Viud/7zWAAPGD/7TbCCDtQg/wc3mLvY3U+BEOwcz+AGM+iV73nRylnKzAazE+5sbSucksv6JiXt bc9tNTTh3DZHwtJUDYimYV50hpiaItrmiEtkYhOd+EQoRlGKU6RiFQU3ln7lbYZ8A5zhXIi3GAaN hyuTodpyaD325S2LKNRbGdPGwjZCiVw4PNKVgtZDNHULJ8KjXOns1cA+tkt9Ewuk6UzHx/+VrIGL rFOgMDZCCSLqd4eb2BDFFr4BFk+DLGsJJKW3u0Uqso8iHFP/RiewNoEqeyVzF+lYZ6xF6bFwmKwk KXulPxDSz3WgjOT4AGbLXUbOl7tsZSl5Kb9i3k6ZElviJRmJzO7JbX3HymUiDf8JLvzZEHW4AxcM PxlM3clPkPcDpy4bKTFZFupc26weNg32QE9Sr4ABu+G41kmvex5vnJ+cpOTICT4EhqySVpSn8h74 OHjp85nIG2Qk68lIVhpQnPPk1/rgtzBrurKTsHolQXv5QXpmUnMUXGj6CinKyJ10kwWVKMkeOUiN kdN4qSLoCn0mQxh+8YtlQiEdxQhH6KVwZ2lr203laEbDCZWVPcMpURnl05xx0ak1pWpVuyREq3op nVnlale9+lUiJlGsYyVrWc16VrQmB6xrZWtb3ZqXtMZVrnOla13tele85lWve+VrXN76V8AGVrCD JeyJ+npY8RRWsb5BbGO9tVg2yMLGsZOlbGUte1nMfiaym7VPZj1LHM6GVrSjJeFnTds10qYWNKdl bWtd2x/VxnYyr6WtZgICADs= ------=_NextPart_000_0004_01C6FBB2.5935DB10-- From anseldowns@hrpolicy.org Mon Oct 30 05:04:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeU02-0006F3-95 for capwap-archive@ietf.org; Mon, 30 Oct 2006 05:04:10 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeTsU-0006Xb-To for capwap-archive@ietf.org; Mon, 30 Oct 2006 04:56:22 -0500 Received: from [60.1.67.132] (helo=hrpolicy.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GeTsR-0007Se-8K for capwap-archive@ietf.org; Mon, 30 Oct 2006 04:56:21 -0500 Message-ID: <000001c6fc09$5fca5a80$86aaa8c0@lzvnic> Reply-To: "Verona Gold" From: "Verona Gold" To: capwap-archive@ietf.org Subject: Re: 904 Date: Mon, 30 Oct 2006 01:54:21 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6FBC6.51A71A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.7 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6FBC6.51A71A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That bloke, as you refer to him, is one of the finest and most Cheap VfIAGRA http://www.lewadesunjertionkas.com =20 =20 further interest the scientists had it transferred here. A study ------=_NextPart_000_0001_01C6FBC6.51A71A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That bloke, as you refer to him, is one of the finest and = most

Cheap VfIAGRA http://www.lewadesunjertionka= s.com

 
 
further interest the scientists had it transferred here. A = study
------=_NextPart_000_0001_01C6FBC6.51A71A80-- From zrelgysohl@onur.net Mon Oct 30 13:46:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gec8B-0007XO-Ai for capwap-archive@ietf.org; Mon, 30 Oct 2006 13:45:07 -0500 Received: from s010600095b9f78ff.wp.shawcable.net ([24.76.183.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebwN-0008BJ-9q for capwap-archive@ietf.org; Mon, 30 Oct 2006 13:33:01 -0500 Message-ID: <001101c6fc51$d0607250$25b74c18@tims> From: "alpha" To: capwap-archive@ietf.org Subject: Herald Forces Date: Mon, 30 Oct 2006 12:32:54 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C6FC1F.85C60250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.5 (++) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b ------=_NextPart_000_000D_01C6FC1F.85C60250 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6FC1F.85C60250" ------=_NextPart_001_000E_01C6FC1F.85C60250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Coming thanks am uploads Blinkyou of Coshed Vidilife Flurl Dumpalink or = Yikers Mojoflix Davesdaily ugoto Lemonzoo is Gkko is Ezprezzo am = Tikibartv ifashiontv a Letsdump Imagehigh or. Massive puppiesand am admirers puppies discover manythings enjoy many = related Forums Lots peopleand is comments in everything breeds humor = names behavior offers largest looking training of pictures explore = eagerness a Directory a termadd Homedog Breedersby Breed Clubs Allergies = Diseases or Pregnancy Welfare am Holistic Care am Neutering Jokes in? To bio Gorman los is Angeles Firm networks refused causing Kxmb Bismarck = Worcester Telegram of Mailall is Mccartney supported wiferegnum = agoheather is Mills divorce exbeatle Paul is claimed hit wife Linda am = refuted Linda a herself interview given is her heather Doing or furious = Heather Spydaily Telegraph age Melbourne Sunall Winstrans agoap plenty = Kentucky Fried. Create Image Scroll or make Words word select of style letter compose a = choose am Smile a Smile Glitters Cursors move mouse over square see = cursor preview amp Animations in Table Funny Content Flash a Slide am we = are a praring bigoows graphics some tools every kind of blog also will = in be very a coming thanks uploads Blinkyou am Coshed Vidilife Flurl = Dumpalink. Launch in White bid Wjlarep Finds or Missing or Weapons = Iraqboston Nearly military am bought Iraqi audit abc Iraqis a cant. Dress Louis Vuitton wallpapers or courtesy Faneramx two dimensions = thread thewer of clever tweak current Viewer adds button user apply or = currently a desktop set called Oops feature soft gradients scattered ink = splatters hence title variety in colours both regular widescreen is = formats wallpaper clumsy artist allthread deviantart prefer am brushed = styrizo of panel Windows is users screen offered vthread dimage png ico = of metallic is goes or dimages gallery too. Directory termadd of Homedog Breedersby Breed Clubs Allergies in = Diseases Pregnancy Welfare Holistic Care a Neutering Jokes Breeders = Rainbow Magazines Paper Apparel Bedding Books is Bowls Feeding a Collars = Nametags Crates a Dietary am Fencing a Flea in Tick Treatments Food = Gifts Colle eb ctibles Memorials Grooming Houses Jewelry Litter or Odor = am Stain Removal Portraits Artwork! Forumswell Special a February a = localhost acclaimed creator itunes great or changes in fixes including a = modify slider bundled. Ludwig Because am ultimately arent notabdul wouldnt in agree thatjoe = issuing issued however particular of us casejoe theyre Senator carechris = estimate beginning fray unlikely mood grinds onamanda Vanstone or mr = Metcalf said asked question oh Rizvi or direct contrast Madam Chairwoman = going oclock tonight entirely committees hands conducts asking is same = ways. Photo of Runway amateur real tips please visit can take in better Enter = is Picture is Perfect Cothis in Contest Tutorial Digital York Institute = in. Artist allthread in deviantart prefer brushed am styrizo a panel = Windows users screen offered vthread. Them am use provided point scratch a hands mdash Donate Security Issues = Support Bugs or why ea Angelfire Username. Happen come problem self in = herenow news weeks launching main of yes stay tunedalso vbulletin of = shortly of Waiting fixed sent. Hinduis dudzdnet agois dud avoiding until am future build incomplete = browser. Spydaily Telegraph age Melbourne Sunall a Winstrans agoap plenty = Kentucky Fried Chickens a saturated salt fewfat fry of biz Newskfc is = Starts. Fishing or Fifth retail trade in finally key complaints or visas = employees is exploited underpaid joe Ludwig taking hapless Ludwig of = Because. Rules in Catalog Tripod Lycos Lycos Jobs map in Privacy a Terms = registered trademark Rights Reserved dd dog am Dogs. Prix Cope takes = Motogp in Dave Woods a unseen Sydney press overdrive Adrian Morley focus = Comment High a! ------=_NextPart_001_000E_01C6FC1F.85C60250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Coming thanks am uploads Blinkyou of = Coshed=20 Vidilife Flurl Dumpalink or Yikers Mojoflix Davesdaily ugoto Lemonzoo is = Gkko is=20 Ezprezzo am Tikibartv ifashiontv a Letsdump Imagehigh or.
Massive = puppiesand=20 am admirers puppies discover manythings enjoy many related Forums Lots = peopleand=20 is comments in everything breeds humor names behavior offers largest = looking=20 training of pictures explore eagerness a Directory a termadd Homedog = Breedersby=20 Breed Clubs Allergies Diseases or Pregnancy Welfare am Holistic Care am=20 Neutering Jokes in?
To bio Gorman los is Angeles Firm networks = refused=20 causing Kxmb Bismarck Worcester Telegram of Mailall is Mccartney = supported=20 wiferegnum agoheather is Mills divorce exbeatle Paul is claimed hit wife = Linda=20 am refuted Linda a herself interview given is her heather Doing or = furious=20 Heather Spydaily Telegraph age Melbourne Sunall Winstrans agoap plenty = Kentucky=20 Fried.
Create Image Scroll or make Words word select of style letter = compose=20 a choose am Smile a Smile Glitters Cursors move mouse over square see = cursor=20 preview amp Animations in Table Funny Content Flash a Slide am we are a = praring=20 bigoows graphics some tools every kind of blog also will in be very a = coming=20 thanks uploads Blinkyou am Coshed Vidilife Flurl Dumpalink. Launch in = White bid=20 Wjlarep Finds or Missing or Weapons Iraqboston Nearly military am bought = Iraqi=20 audit abc Iraqis a cant.
Dress Louis Vuitton wallpapers or courtesy = Faneramx=20 two dimensions thread thewer of clever tweak current Viewer adds button = user=20 apply or currently a desktop set called Oops feature soft gradients = scattered=20 ink splatters hence title variety in colours both regular widescreen is = formats=20 wallpaper clumsy artist allthread deviantart prefer am brushed styrizo = of panel=20 Windows is users screen offered vthread dimage png ico of metallic is = goes or=20 dimages gallery too.
Directory termadd of Homedog Breedersby Breed = Clubs=20 Allergies in Diseases Pregnancy Welfare Holistic Care a Neutering Jokes = Breeders=20 Rainbow Magazines Paper Apparel Bedding Books is Bowls Feeding a Collars = Nametags Crates a Dietary am Fencing a Flea in Tick Treatments Food = Gifts Colle=20 eb ctibles Memorials Grooming Houses Jewelry Litter or Odor am Stain = Removal=20 Portraits Artwork! Forumswell Special a February a localhost acclaimed = creator=20 itunes great or changes in fixes including a modify slider = bundled.
Ludwig=20 Because am ultimately arent notabdul wouldnt in agree thatjoe issuing = issued=20 however particular of us casejoe theyre Senator carechris estimate = beginning=20 fray unlikely mood grinds onamanda Vanstone or mr Metcalf said asked = question oh=20 Rizvi or direct contrast Madam Chairwoman going oclock tonight entirely=20 committees hands conducts asking is same ways.
Photo of Runway = amateur real=20 tips please visit can take in better Enter is Picture is Perfect Cothis = in=20 Contest Tutorial Digital York Institute in. Artist allthread in = deviantart=20 prefer brushed am styrizo a panel Windows users screen offered = vthread.
Them=20 am use provided point scratch a hands mdash Donate Security Issues = Support Bugs=20 or why ea Angelfire Username. Happen come problem self in herenow news = weeks=20 launching main of yes stay tunedalso vbulletin of shortly of Waiting = fixed=20 sent.
Hinduis dudzdnet agois dud avoiding until am future build = incomplete=20 browser.
Spydaily Telegraph age Melbourne Sunall a Winstrans agoap = plenty=20 Kentucky Fried Chickens a saturated salt fewfat fry of biz Newskfc is=20 Starts.
Fishing or Fifth retail trade in finally key complaints or = visas=20 employees is exploited underpaid joe Ludwig taking hapless Ludwig of=20 Because.
Rules in Catalog Tripod Lycos Lycos Jobs map in Privacy a = Terms=20 registered trademark Rights Reserved dd dog am Dogs. Prix Cope takes = Motogp in=20 Dave Woods a unseen Sydney press overdrive Adrian Morley focus Comment = High=20 a!
------=_NextPart_001_000E_01C6FC1F.85C60250-- ------=_NextPart_000_000D_01C6FC1F.85C60250 Content-Type: image/gif; name="Copyright.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c6fc51$d0607250$25b74c18@tims> R0lGODlhsAGMAYf2AAIOBYcAAACKA4OLAA0DfXwAeAiFhsbDuLnfybG8+04fAGshAHQrAKMoDLMn AOwTAAA9ACMxAD8/Dmc7AIIzBKhKBM0+Dd86AABmABJUDTZgAGplBoNVAJJqAMlXAOJjAACOABp5 AD9zAGuFAXWHAKSMC8yAANOKBACuBB2gADSYAFydB4SmBaKYAL6jBtuuAALDBxTOA0e1AGe6AIy+ AJLFALi6ANeyAgDnACXcBjzdAGfYAHfrCKvWALfjDNfrBAIGNRkAOTMAP1YAOnYIPaICSLYKQd8A PQcmTBYdNUIsQVEcO3MSQJoVPrUTQNsrMgpKRBI9PUxFNmZLOIhIRaM+OMJMNO47OwBdMiZVOjhX N2pdNHVYBK5WOsVYR+VcNgB6Tit8M0iFQFaLS3l+SJiOO8RxTux3SgCuSCeeO0GSPGyZR4mpPaec Mr2gP96fNQTCNBrOSD+3SVnHPH25SpzLPsjEN+7OPQDeQB/lMjfoSWHTNHboTJvtNLbqQOnlNgAM dhYAjkIJcVMOiXoJgKoAjLkAf9UAiQcfhC0TfDgZcVYnhH8igJ4ni8MhcdwkiQszjiNDhj4/c2RH gIg5gZwxhbtJftI7dApseypRekhShlRSf3lkd6NfcrNghudZjQCDdhV/ck6Oe2COjYhyh6WOicZ1 ceSAhgCaeS2ackyac2qWgYmngJ+udL6WeNOWhwzEiiO5iTzHhFvOjX+6hqS7ccLDhOa6fgDfgyvl iT3Rc2rof33oc6rkdsvkfufnjAAAuR4NsjIAyWAAwYoCxZUAubwLxeAAwwATwxoqu0csxW0kyYUY xKMkusglyOUqwwBCsSQ1wTpLzWBMuYc2uZpIvcJNxdg4sQ1WxS5RvUNmvFFisotpx6pZtL5twNlk wgB3vSeEwDt7w2Rys3uOvaOGwr+OxuWGsgCozSmRwE6uuV2Vw3Sqw5KYvsuosuGgtwWxxC7Azkq7 u2K1vn3JtKXByvT+9aOTr3F/dv8JAAr6Af//AA0A//8A/wn++fH//yH5BADO1A0ALAAAAACwAYwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFMO/MeypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qFGiKpMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2bMijaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 smXJZjNr3syZ6+XPoEOLftu5tOnTqEvmTM2a4+jXhVvLnk27tsDVH3Lb000wt+8PA38LBy7Q9+7i w3sbR/67oHHiB5dL513cefLguoEv302dOfPmyq1D/wfPnfh087dhqwcccbxB9L2rB5fPXT784/Pp 49/f/X38/ADaR9949+kHIHzQBTjgf/s16J5tEDK1Gn8J4ldhgQFe6Jx/DmaoUIIgxlehgRo2aKKB J2K34YkFhijfejAytqCL/OVHY3Qr/kfjiAntuCGPJXKoIIo8VufiiC16aE+MTObVno0HHrgdcggF aSN5VDaEXpJE5igelkMWaSGUOW6pn5gRpinShA+OuaCA7yHpJZxF9ofjcVyyOKeCQAopJIJ/Gnlm ek0WKtibgs53Y5Vzylkjox+OeSGYJta5p56QJuoononmZ+in7D2qoqIMlmolpm12GKmZfDa64qld Zv+a5abadfoiqLjuhWirpeKZKqa7Ejikn6fC2iaswPoZrJdi5uosXuVF2yuI12nX35TfYUetr8Le eSZ122Er7bjYTinuuN/auSh+z7ZLV2loqrmQu/TC1Vm88ipU77495evvvwAHLPDABHPG707IHKzw wgw37PDDEEcs8cQUV2zxxRhnXHHBHHfs8ccghyzyyCSXDLLGKKes8sost+zyyzDHLPPMipls8820 0azzzjz37PPPQAct9NBEF2300WjhrPTSTDft9NNQRy01akhXbfXVWPM79dZcd+311zlnLfbYZJdt 9tloFwX22mx7NOFpMD0Ud9uEtqS0YanN3ZDebfP/bfJddAcuuEQTAmC4PQAodbhAhidukd/6vmSP AJQLMDnlAlVOkOWbYz6Q5p9XzvnlopNeuuiao2456galPrrrpYfueeaYzw466ZMvKTlBjiPe+EGL Q9R478P/zvjhvR+P/PADBW88881D/zzyK8VGfPIpJY/9RJAnBNPrmW9e0Oift25++Ojnzvn6ubfP Pvrgj1/+/O3DT3/65Md/ue4u8d68/4z7n/AA6LgCBvB4AETcARW4QAYSryAPZKAEGWgY7G3vJM7D SPcQ8r3zpU998guh+PCHEPLdr370M2H9bHfC1SXkdfEzoeX4ZkAILvCCCdme9hLYQB0K0HcCxKEE /2towboJBofTcyACnVfAxDXRicFTYA2BCMQpZnCDB4mbDEcYvi2KMIXz8+IX3QdGEbpwhSFUIQnf p0a9RdB/zxtiE4dokB3+0IYTpGMArYiQCDoRePwbzAX9CEUHGpCIf9RjEJVoyCoy0oj/kNvubMe6 MHLxhKaD4ew+2MLbxc6MXWxh6DzIvvcVxI13POD1pKhKO/LQlTm8nvGUqD0dzjKK/gOcQwa5SEYS koiqrOMeowdMKc4SJKZE4SdRyEll2u+SokQjM0kIQk6KkZpnVGMOU/nIQ8aRhz0E5zYnCEwfijOR eFRKTorox2DSsZgPNCcV4TlMg2DRnrt7JjX3if/J/DXzn9fUJxdhGM2CEpSZM8znG3tJy3Q2MJyp RCJEV+nQPD7yf7rcJUPpOU9f3tCiduRoIoVokRgO9KTl86c/nQnQL55xmvqTpj7FuFKZ9vGVPzyk O3EKzoXqMaQEjKgwH0pSkhQuitMrJPWYWDwqgjSDymPe8pyauHue8iWxAx3saLc61qkuk+urJO46 p8mt0k52Y3WfWJeJO0+StXr9uyP0ljjVxR0zqhDE5TGhaNem+u6X8URqX2uIt4sU9aZGzSdDrLo1 GorMcRklyWGHOrjMTDZflzXLXRWCy8p6djZv06BixcLYkqWNJ59NrWpDe5HSZmVu+XDaaXfyEL// VlRe+cjtQHIb24PoViC83a09ePvb4RY3uL3dLXGTG1zjHle3zG2uc4EL3ejGdrm/7W1yVZvYmyiS cKMNC0yuO9zyAtcg292uedfLXOFSF70EaS97z/ve9c7XvfbVLn31S9/ZpuW7EXEtVsZ7X/sauLgF lq961Xvg/RZkwQY2b3qVi1/64re3/k1aYP+qPAQGUMBXGe9xK3xdCOf3whZOiInlm+IKOxjF/HXx hDOME+HdUqestGhrskviGJ83vcR1L5BNLOT4+tjFEo5vkYmcYgZz1201lic6/5o8EFsFtuVlcYF/ rOQiN/jBYI4weeEb5gk7mMknprFRQPo/WMLV/25lwfKYT9ziOdP5yAxeMXwhnOcmXxjNM1YzUqTc 0AlauSoEJq+WF+1nL9O5yxaOsaRJTOlGI1nJgibKXpdXSA8r8NBUiZt0R01d7SLY1EGebqnzvFzl lvjUCHbugkc9YldDGsOZnsnWnCwRXsvG10/eCGsfF16wgFohwEZNcnOt62A7e23DXlOxp3Js7zG7 Xs/OtteifZZpS6XaHLw2xahs44VEEdwmiRs/1s0Pe7B73QOBt0DYPW96i5tiPmXIYavs7ajApN3z DrjA3U0QgAOc4Pd2V20rsm/OHDzeEK93xB+u7crWkq/Uo6UsGVoWih/84wQPucgrDrWj5pSuxv+s 50XRrZrdydvd7574yOWdcIkF9acqR+cUA8kSrfDN4AUXeLspjvCaO2si8eylznFuGqDLXOIFITrJ v/bGpRc6xxc1C8hnPvCQb33qbJvrDevKV2J2OLNYiTnM1U5vobcd7Ezjto5b22+osPyqRseVYeHO dzUNu7MauftIBP/mvBuq74E7BeIXz/jGZ8/xjd+spxtSPMBrZa+8szzkB9fwhWd9gEn54xw/unnV av6hGt176PNY9dI/eZAjfSKHK9pXY0519mjHyF1b73ruFtGR3QSk0kfq0aUg9eS9l1pof2/IYlK2 wx6VHt7hHBKr09HwNpdI2ZP+TsS6k6LMXz3/7+ee/LYRmo8SVfpEUW8S0SOf/OW/2Tot39S5IlGw fk2ih6tad8My1ew8h30Mg0GqB3+rF390I3epZxH5hk9x9RQCyDIMl3uxNFmEJ1oRmDIIuBUCuIEe +IEgCIIBMIL2MIIBUIImSIIpeIICYYItSIIDkYIouIIzCIMx6IIveIMsOIMlWBA0+IIs6II4iIM1 uIMraIQqqINIuINAyIMEIYQ0aINQKIM+6INH6IQ1eIM6GIIWYYQx+IU92IJgKIZjeIJBSIZeSIZq yIRpiIIG0YZsOIZhWIZ0OIcwGIc5+IRIaIV1iIdz+IeAeIZh2IZ2+IRc6IA2UYhqWIdoWIUH/8GE igiJg5iGkCiJcGiIYGiJjLiIPaiJnfiFXhiKcpiHikiHkhiInDiJYJiB3nWJpRiHpxiLjjiIbyiG gniKs0iIsPiIfZiKgEiLomiLoJiJw1iKa/iLqPiLZyiIrJiIn6iE0GiIuGiDnEiFytiIgtiEekiE fviMVkiNVCiLjriMx/iMS0iJxhiJtYiJnkiOAZhwEWGG7EiMs4gQ3UiLqXiL+DiKf5iNybiOeOiP /KiP2eiO6IiNo3iO60iP8+iNhzgR8jiQ+bgQ91iQAKmF/yiH/liJ9riIHCmNF2mOxGiRuUiI+5iR J9mIpPiQEFmPEYmS5ViNm6iLGrmQJ/mRC/9Jk64Ykzu5kw5Jkx5Zj8YIlCzZkkqoglIYhNQIhGyY lHuYhdrYj0R4lE25lFMZlUfolN+4hGiIlLfolVOYiT/ohNyolUy5hb4YggpYlCnRjDXBlnbnls0G l00hl3Z5l5FFl3qJaHjZl9Cyl4AZan45mIRZmKIRmIjpb4a5mGyRmI75mJAJIYw5mf8VmZaZbpSZ mZq5mZzZmY5xmaAZmqJpbJ5ZmqZ5mqiZmmoxmqwpbKr5mrAZm7L5mq1Zm3Q3m7iZm5Rpm7zZm775 m8AZnMI5nMTJl95VnF9BMxBBAMxJAPbQnMw5ENEpEM1JndUpndCJndl5ndaZndJpENsJnc7/+Zzc SZ7cKZ7aWZ7jqZ3daZ7kyZ7tuZ7WyZ7i6ZzVeZ/R6Z0FgZ7dqZ77yZ/geZ7riZ/yiZ/0yZ/yGWwD Sp3fyaANuqAEAaHP+aDg2aAOaqHjuaASeqES2qERWqEXOqEh2qEJKqIcSqEnuqEfeqIjCqIh2qIw aqIYuqImmqEJiBMlSqIoehAeup8u+qEF+qMy6qMsWqM8OqQ2SqPTKaIJmqM9qqTfWaIuqqIM2qRE +qJM+qQYqqUOqpwPYaUpWqRXCqFUmqRVeqUOSqVF2qNBaqU5GqVpyhD2yaJsaqEIUadwSqMxSqFm +qZnaqSAqm1LCqA2WqBOuqTmWab+iaQD/6qehzqojoqoZvqeU/qnhgqmc9qfQDqhhpoQ+pmoKxqk euqnhWqndFqj5wl2k5qkmaqnTBqqpvqq6XmksuqqorqqI+qffvqqkzqkvLqjnBqsaAqrwPqpYIql rBqoMyqstSqlXRNauIqqQhqtruqrokqstGqnyRqr19qrOoqkU6qm04mosRqn3AqlowqijXquHFqm kCQ0ZIqtzTqm2iqjrcqs82qvKnqry/qna4quYrqryvqkahqobQqw1oqwG9qq3aqnSOOd9dmeaVqe 7tmf4XmxBBqf1xmxn5qo4wqpHPux9imy7pmqs/qfZAqgBruxl5qeF6uxHXuyFZulL2uyEf8rol5a m86KnDrLsz77s0AbtEI7tET7kLp5tEibtEp7b0XbtE77tFAbtVIbNUtbtVabd1MLmle7tVzbtV77 tWB7dFk7tmRbtmZ7tmhLWmG7tmx7NGmLmG2Ll28bmHF7l3N7t3j7NXVrl3lLl2tpnHuLMaQZuAcj EQ/3chYRc+/2cYxrcG/Xtx3zNh5nuFH3dCJ3uAP3cISbMQGHuRExuZWbuVsnde+4uc/yuVz3cm0H b6yLuCN3uRDndK9LupBbMrIrb0P3dLJbcI2rup3Lu7ULNWoHu6MrdAmxu06Xu6EbvEvjuSBXvF53 vF13u0RHu8w7Ms4bu7rbdbDLdd77ddf/KzA5sbq4q7qIq7iHS75s57trB3KmezGD+74KF75qWWPJ Kb/jRr8cQxj627/+SzK/o3mcRoHmJsAEPFmSp28aIViod3q1dX8LeFupgXaX5cBl4XzCN2WUlVlF 1cEM6BTh93zCp8DeFzgNuBkhjEcanE4cbG4uzHAgLMHcJMMiLE5hN8M+F2VwNHoaB36ctn9TNkeD dXs//MNU9XtEDHi1l3l5RXazl3K4V0X/t1Qbd8S1JMVY7MRDnHmyl8UYFz0oZ8RAPE8BLEtlTMZM hMUA2GmLMxljR07BhGN85EvMt1T1FMRgnGMrLEd6fFNChMSFVk7fR1R5fMeBnFfAJ8St/9THi0RI iTxRxAfHjRTJhjzJWafICWTHn4YZgxzFfSx9rWRXG2zIiER6tsfDpLfHBGRBekXKgwzIhHZ2exTA hFx8IjV5kmzL3yfKV4dXdLzG7dRIKlzLPcx/kUFPyKxyqXxb7STHG9VmItzMLyzJsFzJOJZTsezM QHVzt9zLcqV+0dfJTlXLeIx1r4xYO4dz/HYouzRYUlx5t4d7o1fGF8dhA0xlaUzP9szK21d25CR2 vgx95DbERczLiJxUX4zQZjfAUgXP+MzP0HfGYuzQBs3F+yw9FF1/tvXQ41zQT3xl9ks3BDzNW3HC oOd5KF3H42SA3DMYFZfASDfSTAHTD/9cwQesxA5M06bxt/9rG/zb0/HH00BtMI0x1OUn1CPMTTL9 wDDMERase3VkSxHx1COh0ywdSyhRwVk0Gh+x1Eg31SKRe1rNWUkdwR7ReV5NwmEdeEVtfI930l0N 1pRH0jhM1tWn1lUtWY9VxRpNxu+MxigHPEL8xaG8RIDtzmqcx0l8cXy9xGTHxj6lfx5d2OTmxWMs xhHNwFoM2YYNVb5MxU/kwwPNw5rdaeIV0sTnzOaMfkG0x4J8zov8zI7MS46UztcsUpS8zXEM27e9 y7W9yLbNcWEM3L8s3KUczJFs0KmdwX/0mTVNzbbsfFaXzgG9zdO9xtAszhFdyY08fLz/PMffFMdx FNo518ne9N3ETN3dTNh8PczBV8ymzN6AfNUgfRPXfMhMx33FR3v53d/Bh9zczN27rd37ndxBFcvZ rcvejMFMF+Dh7ODzDd7KrEgrHOGlW1jtbMQInX+PLc+EvdCQLXtJhVcFLeKMLdGbVsWHvdkYl+L+ /M/93NhKFeOJndn1zNAo7s8ODcxd/MT6/NdnzMVBLi9pjddGnhVF/hRJfhUtfDIhXYFr/dwlTdVY YdVjYeVW7poyYtRc3uWagdReTjWQEeb5EhkCPYEqPoHsF1VDThZUPtU2bcY39uZRrXudZcE/XsN1 btHEFioLmH6UR1FQ/cIMThVjvREm/53J5l3XZk3Dz7zmLHzkPEXdkG5ZEszBgl6ARr7kIHHoC8zo xJzLGUFSnafoal3qSZ3ClR5iOAHRGo7Jw6RztbfFt+TXZc3ZTZzZXpzGlj3ntd3Yhazr+DfLuBx+ bsbESdzZtr57iL3dS2zqLO5puwfMuo5A7DzXcLTo48xKua3sWIfBtA3GlHx1g73flnzJwb7c5pzK GrxK427sNizu5SzKHIV8UuZ+rIfNCj7uprzonP4R62RD8BTe0NztxQ3gHy1Up8xT+07Zr23q9jzL z+7f9l7ZoX7sEK7cZpzeDdzI077MdJxxtN3elX04Zo7wwe3eEr7a6kfp1fx8KD/g0v+dza7sUAhf 8YAewpEt8x+V8hUf6ev+ft28Uw3/ecb8F3DO2Ct+4x5+dhwe2ves4jme603f4WxOxILt4Qkdzzze 0f2c8AnP7K4+432N2HrV7HRF9lG9cX2t9QCIxiG+7dT25E2R6FMh1kJr5lGR5UpO1XTOm3pP5mkS +J6Fv6SRWob/E4KfmHT+91hN3zHNWWMv2Wi/+IVHE43ufQic+WdN0tIN8uuc+KuJ7adO+nTd6Z4P 9OiNiKKPFjMO2H7d3hO/z1BM+4t9xQy9629v7LVufZff+s6I7Yqs2q3s7XW8QwPPyOuXxeTe8ctc zpZPEcm88Gwm3sUvRwZe3Ez87Tz/H8zurf2rHv3j9NrtPspBD/oN/8eFTP4NXuDoL/6/LxMPTfY0 juxWL+/kDc/0vGmZvNldDxD27AEgKJDgQYMFByYEIHDhP4gRJU6kWNHiRYwZNW7k2NHjR5AhRY4k GdLhSZQpVa5k2dLlS5gNDbKUCdPmTZw5de7k2dPnT6BBhQ4d2pHo0ZwIVSpEKrTkU6hRpU6lWtUq 1aZZtW7l2tXrV7BhxY4lW9bsWbRp1a5l6/DqW7hx5c6lW9fuXbxQ2+7l29fvX8CBBQ8mXNjwYbN5 FS9m3NjxY8iRJU+mXNnyZcyZNW/m3NnzZ8qIRY8mXdr0adSpVa9m3dr1a9ixv4Km/13b9m3cuXXv 5t3bN0XZwYUPJ17c+HHksH8vZ97c+XPo0aVPr5vc+nXsgKlv5959d3bw4cWP9V7e/Hn06dWvZz/e /Xv4TtnPp19fb3z8+fXv59/fv1v7AhRwwIv+M/BA62yLgEAGG4wLQQgjlHBCCiu08EIM3TMqw78c 9DAqDjv8cMSR7CHnRHJMRDFFgU50CMUWYXzRRRVpPAlGFl9ECccceUzRRhlrNHFHG2PsMcggjayR xxl/XNFFGX0kkkUWSbQSpB5b1FHLLbO8kcshv4xxx5S8BNPMMNMscswb0TySyC3DzFFOLqkUU0U4 ubxyT47mPHPGLlmyUyU/5/yRTP821QS0TkS/zHJQMQ/VEs1EC21U0Ue35HNTjNL8c9JPy4zzTkI9 xTRUSSEV9FRT6cyUUVBNtTROSYf0klNcgcPTSCBjTXTUNQ3t1VMvay2WziYRTRXMQG09E0lfmSU2 UEirzLXBnVQdtNZRWzX00hXvtNPMcaX101VYI431WEZnBZbaUEPMUNtnRSWVWXe/RZXcRd2FF1l1 nVW00WDB/ZdSeSVkN12AZ6VU32nj5ZfWewe22OKJo/U3YowT5jDcJWmEdskpSS4TSZGhVLnYlYFN Ukk5gUR525WlxDfYmesU2WOee/b5Z6CDFjqrDYcm61qkjRYMaQKVDoxp75yWujj/DpbmSEkqnwx5 TZN3FTLZJ4vUmteaZTb7bLHLhpLXNsfumu2S7W0y3LD1hDpANfnd1mB87d1bXIoHhjhjh9u9+O/B Kz7XXFjZvZu7m/JdafFzs+5W1skDv7dyVFclldtSLwcdc1Epv1TaqYlbnOFWvV1XbtQ7Fxz1apvd PPTMRXe9YoFPrz111ToSNuuCYW9898vJnnv53UGG+3ZCV4dYR855V9XckR/fLnKCGTce2dE3frdh 1sEPGPrc+XbUeMpfJh1h4EkTvnvcFa/X9/QB7rZ6evNvPfnpRct7n8MforRXH44lrn5uYl/+6FU9 2XGMdIBroOaQ17sJ9g1AB4xO/06cVzeYncxs+xvhlKKkNfd9EG1Jylnb2leolzlvbi37Wg1BuLr4 IaZoOVQLB+fDQ7b4sD1A7KEQn0NEJPJsh0nUjxFNwkQoYqhoMFShDJfnthLKMGxH4toJicdFrFkx ZOxzGwnd97wShjCEKkyWCUvmpDLacFhOfIvuLCi5jtlOX3+j3fkOZ8F4XVB8CFMg7WA4PglqMG/m o5jj6GgVARaOgPTz2vVgB8Fm8Y+CyPvWxl4FSP4RklWh3F/p1Jc5Rz7yajgBnSRLucllxQ6RuhNl Au04LU9Sj5J9FBjnXqXJ6/myJTgk3/94uKH+2c6QM/zXryZpv1oO7oxWTOanhv+HyeMBs3x7G6Qx jbkzWKlyiS/RorJOp0xufi+RrQug/hbmx7fli4W8DFj4Xte8SJrSc6t6ZxKNUkjWSU+DbzrnOk1n RwUedHoPU6QlNelMdOkvXcVb3zNR2SxxYgWgDKTgHs930Fmi74+BzKPEEFlLk1KSowaFZUEraqqM TsWLW5th5bw4U51xrYbPixvzfIqyNo5RSCD8ms28hsZhtZF4P02qC3uqRqTeKqYgimITp9qpqmZV QuPUqniu+lWwhlUiXSVrWc161qeJVa1rZWtbP4RWuMLHrXOla13tele85lUxceWrV/X616b1VbCD JWxhYQJYxOLNsIsNTmId+0NXxkY2QsuQbGUte1nMZlazm+XsYB77WdCGVrRP7GxpRTRa1HbQtKvl S2pde0TWxla2s6VtbW17W8u+VrfLwW1vfftb4AY3QbslbnGN+1XhJvcnx2UubQICADs= ------=_NextPart_000_000D_01C6FC1F.85C60250-- From cqqynzzo@pbp.com Mon Oct 30 20:15:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiDh-0006DB-Iu for capwap-archive@ietf.org; Mon, 30 Oct 2006 20:15:13 -0500 Received: from [60.210.194.5] (helo=[60.210.194.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiDb-00069Z-PX for capwap-archive@ietf.org; Mon, 30 Oct 2006 20:15:13 -0500 Message-ID: <001301c6fc89$fd26b7d0$05c2d23c@80BA1E98FBEF42A> From: "Research" To: capwap-archive@ietf.org Subject: students. addition cups Date: Tue, 31 Oct 2006 09:15:01 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C6FCCD.0B4515D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e ------=_NextPart_000_000F_01C6FCCD.0B4515D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C6FCCD.0B4515D0" ------=_NextPart_001_0010_01C6FCCD.0B4515D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable How stack am Cycle or pdf overview Glossary! For your hands of at warp Something. Called in track meet for is your hands at. Its easy buy very own Pack Store has in. Ideas Competing of Doubles = Event Where or two one Qualifying. Know what is all Yoursquove come right place leader. Stacking Home gt the is Itrsquos been called track meet! Endorsed by = Wssa Everything here of if it? Here Pdfs forms more format Research utilizing unit included. Info here Pdfs forms is! Video clips action Basic how or! Rights reserved Welcome Privacy Policy! From am selfpaced online aids = great free puchase. Recognized in around world as resource? Online aids is great in free puchase. In Writing Contests or say Mailbag. School try This am Activities Variations ideas Competing Doubles Event. = Selfpaced online aids great in free puchase of. How stack am Cycle or pdf overview Glossary! Is all in Yoursquove. = Thanks making stop our new wanted am here More or Stacker. Amp Techniques get started Faqs questions answered. Learn from selfpaced online is aids of great free. Device endorsed by in Wssa Everything here is if it a. From selfpaced = online aids. Here Pdfs of forms more format Research of utilizing in. Holding or tournament! Policy Telephone Toll Gotcups. For your hands of at warp Something. = Called in track meet for is your hands at. ------=_NextPart_001_0010_01C6FCCD.0B4515D0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
3D"PDFs"
How stack am Cycle or pdf overview = Glossary!
For=20 your hands of at warp Something.
Called in track meet for is your = hands=20 at.
Its easy buy very own Pack Store has in. Ideas Competing of = Doubles Event=20 Where or two one Qualifying.
Know what is all Yoursquove come right = place=20 leader.
Stacking Home gt the is Itrsquos been called track meet! = Endorsed by=20 Wssa Everything here of if it?
Here Pdfs forms more format Research = utilizing=20 unit included.
Info here Pdfs forms is! Video clips action Basic how=20 or!
Rights reserved Welcome Privacy Policy! From am selfpaced online = aids=20 great free puchase.
Recognized in around world as resource?
Online = aids is=20 great in free puchase.
In Writing Contests or say Mailbag.
School = try This=20 am Activities Variations ideas Competing Doubles Event. Selfpaced online = aids=20 great in free puchase of.
How stack am Cycle or pdf overview = Glossary! Is all=20 in Yoursquove. Thanks making stop our new wanted am here More or = Stacker.
Amp=20 Techniques get started Faqs questions answered.
Learn from selfpaced = online=20 is aids of great free.
Device endorsed by in Wssa Everything here is = if it a.=20 From selfpaced online aids.
Here Pdfs of forms more format Research = of=20 utilizing in.
Holding or tournament!
Policy Telephone Toll = Gotcups. For=20 your hands of at warp Something. Called in track meet for is your hands=20 at.
------=_NextPart_001_0010_01C6FCCD.0B4515D0-- ------=_NextPart_000_000F_01C6FCCD.0B4515D0 Content-Type: image/gif; name="need.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01c6fc89$fd21d5d0$05c2d23c@80BA1E98FBEF42A> R0lGODlhjAGoAYf/AAALAHQECwCBB3+KAQAGdI4CjgaFebTDsbjWzrPK/T0aA2YnAHkhAJ4aB8Qa BtIuAAM6ABNEAEhDAGk2AI06AKREAL08AOpABwxXCyJjBkRtBWdUAHJbBKtaAMlrA+lSAQB/Dhd+ ADp5AFh4C4KLB592Br1yAN58DACjAhuSAT+hAGeXDHaWAKyXBcukA+6ZAAbDAB65AE7NBVXGAHfG AKvNAMyxB+CzBwPtBBjWBD/cAG3eAIblAJ3SALLaAu3fAAQAMR0DNjUOPmsKSXcMMa4ANMALOewF SA0eMScRMkckTV4fPngnM60cTr4fMuwnTAhEQhJGRExHQ2FCTIo0N6U9R71JMuFBNQVTThdgNjFp RVJSTINaAJVuO7lRTOBhOwl0TCN6RU53PGaBTYx9PJSHSLpxQdZ/SgOaOROeS0mSNWuYOn2SRKyX SMqcTOSnRwe8TRqxOEyxSly6NHWzOarBOcXJQtrFNQHoMxfnNT3cSV7eNIHaNqrnM8TtNtnlPQAE gxsOizENgWYAcXIAjJkAf8EAge0Mhg4ddRsVjE0VfVkfg4orfKESc7wXitwWewAycR09fD81cWo6 jHRFfa43gMpEd9o8dwFrihRncT5VfWligIBndqhtfrRYg+FogQyFeip3iz+AeWVzjoaEeaqMerh7 c+tzfASndyWihU2VhFahc4mRiq6Xgbird+yiewS2jBS8fDTMg2nIgn7CeqTKfLvCctHDfA7RcyrU hkDSilLmf4TkcZ7Vd8LVdNLdgwAEwSwIykUDy1YKyYcAxpMOw8YCzugAtgATzR4rsjkXtl0StYwZ x6cRxL4fzuIuuAY/tShBxT5At25Jv4FLtpo2tMxCuus9zABhuyJSxkFszFxbzXtSxKtossVTutRn uwB2thOGzDF9wl+CxYSAzpSEzsN6vtqMzQutwxOswUudylKRx4ufyqijxMeYzdSTwACyvx/HxTa/ uGm4sn+4zJnBt//y75yrpHOEc/8CAAD+DPf8AAAA8/wA+Qr////8+iH5BADNpJEALAAAAACMAagB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Cjxn8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bLjnq3KnzHc+fQIMKHWoRGdGOOJMqXcq0qdOnUKNKZXq0qtWrWLNq3cq1q9evYMOK HUtW4dSzaNOqXcu2rduSZePKnUu3rt27ePPq3cu3r9+/gANvfUu4sOHDiBMrXsy4sWOYhR5LJim4 suXLmCtO3sy5s+fPcDOLHk26tOnTqFOPBc26tevXbVXLnk0bK+zbuHPr3s27t+/fwIMLH068uPHj yJMrX868ufPn0BPXnk69usbo2LNr3869u/fv4MM3/0Uqvjx4rebTq5cecb177Hc/yP83H+QH+iHv y99fn79+//t9FKCA/OVXYEn32ZcffQAu6KBHCUK4IIARQngggwMaWGGF+FHI4IMYeghihBTWJ6GC Cooo0oYXhpihhS/GOCCHLvqH3z933WiihBzqN1KPKBIo5I0nElnkiikmaRKNJBIJJI0jHsnikE/+ COSPQQqoJZMkbWikjyiB+aWWS2ZJopdckklmjgmKqSOZUEKp5pFvqilnl1vCeVKaHQbZ5p4Tmvlg k0bmOaeggxaqqJ1O0oknoUXeKaWfWEaJInou/ello4tKummgjK7UJKGSKjoqpYtm2WeoDpKK5aeW Uv/KJ5I86hkmp5ECOueflSJ66GO8unqiiC/u+qqZOyJoqI4N2qeim6Q2a+yYjtbJrI28psqitG5W m2u0NiIJqZPSTmrriioWWupTHWXrLq5dXlntf8UOqSyn2eLZqrHjWplhuPMuG+e5sZ4rL63Crgvu jqUCPCyB8816JaYtvdtov/qaC2qq3goMb69wtihmw73CyijG+GZsKozJenrxr+jOOO296jraLbUw T9XupKd27Cud+d5Jcs8c25yrx2XSqjHPMKOpcpr9uky0wgSj/HPUK+fMJtCwDvzzhxYCLfa8PVr9 a7dd6woiufYufWiyMy/rtoF0+1zzlSSjCnatBd//GF/EdUvZrMOdMoywyCp/We7KB2/bYqdKYwiy h2U/LW7fkStOeJUTLs6ljP1FPnFWya373umo12R66qwvpUrrsMcu++y012777ZKRh/vuvH3F+++7 +Z7P8MN7RHzxxucTkvL/HM/8SMcvDxLxzT9vfPLUk5T99dNX77z3yEP/PfbLh9/8SdtXL/3046/P /UfWs2+9+ec7Tz/85ttf/vbta5/++fgrH/jiB0Dy4Q959GMe874SP+XNL3nSa6BI8ge/AgIwgRbM oPogmEEHQq97H5xgBd+nQJOED4ESBGEAK/jA97FvhRgk4ASfh0ATgrCFM1ShBzkYQBzWT4cPxCAA /3niEhm2cIfXk6H7RHhECyKxJCksYAlFOEIqqpB7NHShFbHoxCW68IlZ3OIFu6jEK44RihE0YxWZ yMI2RhGMa2zjCMuYFiPekIzos2ETg5hHKobRjnEMZAqzSEc7wlGNUuygBhfpQT7akI1o7J4PAylJ Of7wjV1c5A/neJj0tW+KF7yfFtPIyUR6T3sh/KP+JnnAGt4xiaf0IixNSUlCklKWmySk/hDpwP5l kpWanOUYS+jDQyoRlKDsZDKRqcX70TB7YTyjNHlYS0saMXopeaIUi4fEKFaSi7wkIS4ZaUptilGY 4uMfNs9ZxSnusJeebCcJqffHUd5Ed+jc5DTjSP9ABa6TmeQMpzABGcxb2rObuESoIv24TnuSs550 fOgj3XdMKGIzmubE3glHqdApEnEm2oQjQfkpTnDmk6NLVGhKs7nQV2pwkN8UpDwR2cwv6jOSpUTl FisaQmnasqcYNWhG3SLBJr7Qm9QMqUkhiNQNOtWmYhwpQNcXzRVusIFIdeUay3jCZKovok7Vak/N eM2YnvSmJN2mWa+qTGj+U4ADtKhY68dNuPpSfmO1nzmvmT9Rzk+UBmwmVhvqzYjG86i7nCEwqznO ixrUkmSNpUYF61DgWfaymM2sZjfLWefgs7Ops85HQds60TKEtKjVzmdTux7T6kQAIYEtSGTrEdr/ CuC2uMXtR3JbW5HQtra5De5tdyvc4o7kt8KdbXJjy9viDre3xNUtcJ073OfuVrnWna5xY/uP7Qa3 JNJlbnWd69vwXve8ruUIcrs72+v+FrrEbe972cvd9ppkved1b36BC1+SvBe/8t3vfP/LX/tmd779 HTB967vfAnfXtgBesG/t+2D8pncjC4atbQPM4P42WMIeRjCFJUzgDddXxB8ecW9N7GEQy1bDBlZJ hFd8XJQQuMUqBm+HZXthhLxkwyxmr4JTDOIi31jHAuZukPV73yYrOckdpi+MmZySGQu5xk5+cpZP cuQitw7ISR4yjiv83SijOMEqnrKXNbxc7GKZ/8MknnCMM+xl/+aYzWU2b46vvOXjZhfNtHvxeVnc ZRGLucFnJjFvKSzoCSdauWYe9KIjTWc+k9nOH1azfw9NZUzbeMfhQYqaNV1mKMv5zlE+daWj+1wE a7rKaV70kkMMX0Fz2tSdRnKKX63qPlu4xxihsbBrTelUczrREQZwo+e8khmb2Mo3Xu+yxwztOhub wWd+NK1FAmyDwOTP1i00c+Gc6VSDmtnDLjCyz03rLrs4xC+28rah62pjQzi+uGY3oL9DHnGP2NXS PfaBuYzqEpeazHpGuL4tjWvd/he5Cc90eL076fICHNz3NW+ePdLtgrD24yAPucijstqRn6fjA/+B DgY+4wKTwwblMI95ZlxO85rb/OY4B3k3hCPznp9mGz4PutCHTrGcGx00RE+60pfO9KY7/elQj7rU p071YB/96p6puta3flqse/3rTHHGZpHwHXlYNgZgXw7XBxKDta+dd2hPu9wTE/fNAGDuMnE7Qdou lGFoBAB6D3xe+F4XwAu+Lmd/zN3xjvO6L2bxjI/J4dkuF8NPni6RzzxbLs/5znv+86APvejjovnS o2X0qO82a3Zhes/8oDepj73sZ0/72tv+9rjPPeZbz3un6P73wFcIAoIP+t4b//jIb0zJb+NjlTQ/ +ey6CvSnL/n2+Ob5KMH+eviREu4Dx/s42j3/AMYP+amM/yPlp4n2TeJjfrif++D/B/jd/5H42//9 Hnk//fUPf/3L3//+FxL4R3/5938EmH/4V3/7N38KeIAF2ID1F4EvkYAGeIABCBIAmIAWiIAOWIEP KH8PiHjphxbn5xEjmHcHsRIIEX8gKIH/54It+IHwNxIsyIAYCIMPuIE2yII3+II5WBI22IJByBJD aH9AKIARqINHWIDeZ4OFNxLkZ4LnV4LkB3lR+A9VaILoBxJ3t3heSIVTaIUliIUhsX6hYRA12INN +IExGIMzKBJpyIZuCIdMWIdJuIRv+IY0iIP914fzR4B62IZzKIc/2IMgmIeCaIgzmIa20RIj/2iF ZBiJXbiFXBiJZAiJW+iFITGJkmiJmggVGsh/hWiEDdiEFCiIfwiIOCiErEiKp/iDa8iDLpiGQaiH /YeEiriKbgiIGsiKBkiHTMiDssgW4EASj5iJWniJlJiFmMiJyyiJUfiJXZiFaRGIa+iLbMiAshiH qPiKo3iIhiiH17iIS4iKg3iIAAiMs6iLe6iNdsiHoaiOjXGMWiiNnniPzWiJyTiJkGiPJ3gW1liB +xeO7iiP51iIuBiLbciN3xiIuGiOtWiODymD7EiHBemQDAmO4agz7ZF+/biP+IiMyaiPIzmFIqmJ +QgSZkgZKXiHLvmOC/mSGzmEB4mQA0mIcf/4h4SYjRIYkQX5kKSIkxb5kh04jgl5g4iHhVe4lCBJ jUppkiUpEmIohVApjWOYfis5EivYizLphx4YgKIojqUYkBCokxd4gRy4i6U4kad4k0KoijRYlALI lWDJlS94lmJZiI0YFf9oEn3Ze8OYHIF5G39pjNRXkcYxmIeZHRmwmI4JcsQXmZI5mZf3mJZ5hpSZ mUl5mZzpGs/QmbajmaK5e6BZmqb5mKMZEaWQmg8Rfqz5mrIxHi35GVmpWqh3mrh5OxVwE7uZG73J WhLhlJQIE7XpGM33m/9QAco5Esr5m835Eb3ZnNG5nB4hnSBhndVJndiZnM+Znc55ndwJndz/2Z3f 6ZqRiYk2UZzKl4LWWZ7iWZ3J+Z7RKZ/vKRLuOZ8hgZzwuZ/IuZvUGZ/7GaC9mXou8ZGcuJRXqRz+ WZ/6+Z0OyqD8WRL9GaHgmZ8WOqELCqAauqH6mXP9iJKVCJLJkaEa2qDyqZ3Q2Z0A2qH1uaIpip8V Kp4Y6qIByqFeR40fiX7CqaAoWqPeSaJASp8r+p82uqHw2aEmOqPx6Z5FenUeKZIjCR0LyqQXKqMQ SqM1OqFGuqT2WaVWyqVZGqNH96T1GKKduBxTKqRqGqQUWqIxSqVYeqVKGp4+KqagFZybuIxgiJ5l OJtZdxDbqaLO2Z//OZ3aWagqOp6D6p+J/xqoRIqdg9qi5UmZsultSNeSLPoSmeoaA3qblrWpLgGq nyGqmbV8SaGevQObe5GbtyMG0FGYhcmqrLWjfnkSsQoazIigejqGsup7EXGrUmmrfWqpnEGml5ij H6Gqq+qIeVqPYUiVYmiPuGGs/FimvcqREPGUUemPUHqgHOendrenIAqNi6eseiET48qt1qqMv+GM 3mqs10oV1teUIuquIamS4NoZ9jquW2iupWGmKbmvJ/mtxPoZAiuFeeqveFGgVxiVneiUTEmSroGj EauUTwms8doWGJuxcrexHPuxIOsepsoYqBp9T8cLsacSHmuyHrcUGKuwl8GwDRusK1GFK//brGwB rzMbsmeBpyixsjdLs8PasklBscN5dzBrGQXqlwj6iRJbfkz5hXtKlVEKFc5YtVhbc5yAHMG5s/dY iXyatdO4rVAaiSXLElf7tASbtLMBtlBJrvxqphf7tccajVqZrzUxs8bKtoKBrjhrr+z6t91athJL gnRbuDwrFT5Lksgatkc7uOt6teWKt3lLt1jJt4DxEl47t5yLuFBrtzo6tQiLuEwBseIatIlbfdnq tzbxspRLE66LuX5huDOxuYSBul+3BKm7u7zbu2vrEL5bE3oXvJEnEScQEsd7Asq7vMnLvCBxvM8r EszbvNNbvdCLvMr7vNfrEdvrvNi7vB//sb3c+w/iW77ey73Vq73Zq77ai73ka77vO73vi7zxC77S G77We77x277RO7wtUb7kOxLdG73jS78EXMAIHMD4u8DzS8Drm8AKXMDiq8DXO8EDDMEMLMEVDL0P jL4NvMAT/MHjC7/hG8ElfMAPvL4dbMKh2R4VjMEmfMEsPMMHHMM1TME2TMM1zMH3G8EWjMIkEcIs zMMvnLw+HMAhbMQl/MNL3MMnPMQj3L9u9xIvTMMyHMVOLMA7/MTRq8RYbBIXzMRIrMVPnMRBrMVe bMRpPMb3O8Bm/MVcjMNtnMO40xFVbL10DMfsm8UybMY8rMcCfL5i7MVbjL7yK8R+jMVK/7zI9Qu+ f8zGBgzJcfzIXYzAxzt7X5zE+hvHgRzJjXzDmZzJ9svFlJzAiKy/b5zFTczGjEzEZIzDb1zFkwzD axzAmAzJqZzKJ3HFsmzFRyzJEAzAYqzDvazLoIzLq3zEuQzIFLzJAOzLd2yeWwcTtezJwwzGhWzK BuzGwezJwJzH2YzIZ+zAZfzL32zDhGzJswzE5JzMIXfF68zJ3UzKkZzCpazC8NzHNyzO7Sy9YbzB tAzNr+zBJPzM8/zBKuy+I9e96TvMQvzJ2UzKHUzChmzBzjzK8jzD1IvKGL2/8pzOI9zQ7pu+8RzD Ez3RCl3H80q8xCl7LI2Cb/fScucVgP+HBTbNt5aHe24BADYt01hn01jg04mRDeIR1EKNdbh71NmB FTktu049EU391FI91VRd1VZ91QSRBVh9tkodclv91UTb1WI91s0B1mZ91mid1mq91mzd1qlJ1kbn 1lQN1zkn13Z915pJ17+hB8GD17Kr1zfn14I92IRd2FH3HssA2D1r2Izd2I792JAd2WCh2JRd2ZZ9 2ZitWUuHCJzd2Z4t2a/p2aKNCKC9GmQdepnt1Svd1ajtEtrw2trwD7Ad27INErQ927b92h8x27FN 2x7B27vt27IN28NN3MUt3Lhd3MFt3MO9285N3Mi93NH93Ljt29b928yd29ad3M2N3br/PRLMHd3I rdviXd1GJ9y1/dvdXdvo7dzpjd7THRLfnd7uXd/y/dzqTd+57d7Xvd63TRLz3dv3nd/sfRL/rd/B Xd/t3d8BjuC3fd3wfacREeHqLeAFDt75TeEEzt8b7uAAjt/vLRIHbuEZHuLtDeIkjt8WfuK2XeID fuAbHuEr7uEXnuK1TXzKfdwl/uDwHeDGPd4NTt8/Ht7z7d08Lt0cvt4uLuBHzuG9Hd4Fvt0sTuRB DuP6LeMVTuP//eTfHds4DuIXruRXLuQD3uE6ft8sPuZZ3t/aveUtLuQpHt/kLeJRTud0zuZIruYd TuJz/ubb7eFfnuWCvud+Tuj2reeD/27nBD7jNC7oDF7oMd7iC17nLw7pGh7mk+7iiR7iYI6vn+fa Q97lkp7dZA7c1W3e1N3lp17kZw7hqD7oXK7n3D3mwL3oeS7rxx3nZy7iQV7h0N3nvg7dqb0baR6v I8vSrT3syq4S/bDsvpoaxFDa0j7t1H7Vzo5a1Z7t2g5s105a2y6Z3S7h3862hDfu5n7uORLu6r7u 7I536P7u8D5z7b4bYNCrQDDv+N7C8b7v/M4Va0AR+W5Zx/4W/U4dUHgYBT8do0u6hrmJ0VixcDu0 CT+7muu4wiq3+IisAc8ZHWGVV0mFmQi1gvuuNDvxgaG5Ihq4B8uF4kqv2pq1bkEOMv+/8TGBo4Or 8XnauPAa8zLf8zTv6Q8h8o17rwev8WQ6uVfR8yafFULfsE4P8RQL8iGfoNK89Of681if9VpfO6Zh BFa/sFsf9u3+9aMn9mbf7iBw9qFF9mzf9kKh9rDj9p8O93Sf2Z/1l9VKu72x88NZu7VaWmJR8W9b 9AzvtLbKqwf/9xhvjIifEkmNs+va90L7s4pfEif4+Pr6pxDB92Bb+DCf+JUP+ku705C/+Kbf8Ki/ 9n7hkU9fpqaLsGAY+REPrRk/tnkvursarUWP+LxfsdMI8lKr8izPrh8f+7QfuhZbtyj59L0f/Nra 8qNr81UL/Zxb/PzI/Egb+DLrsK7/f6/e+rD0OPRDn/wkT7M4n/OWD7BEX60iH7j7+KQ5Crj1Kvwr 3/5k+7B9D7hpy6/yT//rDxD/BA4kWNDgQYQJFS5UCOCfQ4EQAUx8WBGixYkOJUbMWNHgxogeLQ4E CRIjRZEkQ4a8eNAkSZQrR7JUqTHlxpYeW3a8qJGnSqA4RdrsOZTgzporbSqlWHQmzKZJmS4dWdQp Q6xZtW49alQoVao6ZaYMKvWpVZlhx4ql2RXozbFo21aF+1RpWblp3X5Nmhfp26VC24KdG9dsYK+J 13Jl3BhrRpMSo/qM2ZHtz4KYdVqG/BAlYc+Uj0adatgy1NGVeXLeDDrzzc+cY8e8/3zWduicskuy PK35amqjuDlKnhz0tGPkCu0tZ97cOfPk0aVPp6415/Tr1bW/Tp59offHDcM/J1/e/Hn0y7evZ9+e PXjH8N0jPx6fq3yE9VE3pD3f/38AAxRwQAILNPBAxtJ7DkEGG3TwQQi1UnBCCiu0ELr3IswQQvy0 865Dtwzsz0MNEYTvpQ2lApG+rVCkbkWy8lvsw/vak69DGLkrUboLv1sMwBxZtG4+GHFMiMYWbfSR yH8udPJJKC+kLLcpYfqop9kIE82n1oYD7zPewAxtMMm6FC4z4rCkrbPhOHLzTNLEhKrM4MTUjTjP rISTSjzbBJPNPGcCM0pCCzV0Of/X2BLUpbps03KuRMsKFC2rchPLL0YxBUwxwRY1i9PBaMJ0t07V yusuukLtz6ZDWzWUsUQjOxO1vxy9q9Tg0IxNr0dphTRXPw8LsdfO5MKz1ioF/WnUW30j69TatNRs zCB3xA5YWbPrVDFbcXWq1jcpFXZRTW8dl1cVh720MGgRE9ZYdj/lFlWiPv02RmsTtDBS0OrTzUuA tyRT1mfjhLNN2ARjbS1nZ521t2DNpVbXPhM2k83dJkZ1P0vX/Za0YF0VGcp8Q9xuxWpFLDm8lVt2 mckGUy5Q5gdpfvlmnHPWeWeee/b5Z6CD3pkXoYt2MGWbI0ya0RKXNjo6F5nm78v/rFS7Fj/I1Gp6 yOqizk+13vTjWsan/XNaL6m/w/Lasc9OkSG3vf7orUa7E+9mKVnrE9A/86TzuGTpdvRvuOod8+F/ lb0b8Sv3bipNPTGmu7hA90SYY38DX1XH33StvO/IyhzZuQZerZE3dFUltbBfBScW9a7qZfbXsKhO HVx4b2vd1DffZZ3bv3JneFOyX+LyNq2NLldakHFa+NxnOZ2WXuCrD2xE4k/CPV3km2fdeO8lV/e3 bAHnXPC9SlNzTnzzlfLcXtHWGqnO7w0V/dVp993d665KHtlopeteHRugvBoVq9TNzTDoox6uFOWR 0Y0MVs87HN9ApizRQO9yB9OY/8kuZpzZDGxGxMvc3poFtlxpy2J7yiDHXFenEfmLYunrkv8Q5jYN oaxssHpZkHC4w7K9r2pAfAz2rJWjHxIxKxEUmRKd+EQo7qxHUaQizph4RSxm0TnY6d+AksjDsb3o PzeqYhmn6EG5mUyFZEzN/9ZjpPbpCG5xZNuRZii+qbREi3vkYxOhxh04/kiQk5MjA/84RzoaMm1K Wlz0YGeXMu4wcX4LmxyTdTywgWtSf6uYV8K2K7s8zmqjUVzAELem8D0OYDdEY19+N5BCRFJDQoRk thaov/wVDEX8i9HsyEVA7jHlNeJqnWka6DvgcPB6OeljM525x3bxynz7M6Ugwf8SJwparybTU1Tg Huis+HXMU94yoP56N5ZnplOdIovmvAhJTABmSmJd3JQve5lAGq5LVBrUZy7jN0x7AbJJ6yRoQZ1U wbl9jE+2vBjgIIZQaq2qYRi74LhkuJMsdQ+VNrzUJ+NyJ9NAzKAjTacsTerBQp5UpStl6QYV2FKY xlSmMZup+0h6U5zmVKc75amFavpToAZVqEMlalGNelSkJlWpS2VqU536VKhGVapTpWpVrXpVrC4k EzvsaVe9+lWwhlWsYyVrWc16VglmVa1rZWtblRiLlqFVrnOla13tele85lWvBHVrX/36V8AGVrCD JWxhDSvFvSZWsYtlbGMd+1j/yGLxsJMlamQte1nM3pSym40OWDn7WdCG9mfgoGqPwHFa0qKWtP9Y rUBWq1qCoNa1si0IbGc7ENm2lrWsPe1ucYtb2t5WuLxtbW9vq9rUxpa4vdVtaoub3NrmFrbINUhw mxtb5tp2tsalLnW3C9znBpe4y4WudskL3ujq1rXVDW92czvQvKq3uLz9rXqV69uD2Je+v92vb187 X/xGF7jrJbBx6StfAOP3ugZmbm0dXN388pfBDybwfXcrXwgXWMMIue569cvfCicYwwK2MIb3OuIL +zfAD/6wfl8rYRWr+MUfTnFyMWzjFCv3xSHWcY0DbF8XZ7i+MQbxihW8YhR7/3jDES6ykUvs4CSP uMNIhm9XG0Nb2874uxQWr3+5y2MZbxjH4x3ymMtcYywrGcxKxnGHpWtgI99YzUUGMpbt/F4dM7jL P2ZvkCs85z9LucRpxptPhzxnOFOZwnxeLoyFu+MDWzjG0D20lgcN4gVreMo5XvSfOZ3oTfM4yVSm NI1DLek1A5rR4J2yib+anFKv2tNA5jKjIT3p+yYY10fGdZQx3WMiP9nPtZZ1sY88al7v2NSoZnar fy1pZ3vaiVkmtIe7/GYX49nalL5wgzEtXhRbF8rTfTKrZx1nbOsau7pu7oTT+19tr/vX3t0ykvds bwTX2dtr7q4VDS1agCdkr/8BJ/hBBl5wl2XWrAhnuBLP2HBrKbysjtFzxbPt3lvDu93WTTSvyczn PV+7vST+eHrpvO59d/vO+n73edHraIhTXMSpVnS3D83hcgM72cAW9IBT7W5aF1jdHue0tJ/t5GXv l8YAN+2Six7q+ZbXyUc/962fHmwiKzvXYu70mIMO8k43mdvMfjZpJU7WKzud2/nertbhzeSaU/3q IYez1h399q6HmdjbDm/eW5xfN8e8yhNqNNibfPNSI1vdX5fzmaGM8kC3XdWk9nnOi77oxgtZyC8+ +2IzveRlRx3VXyf6ydWOdbsjOvJW3/nh2T31mg8d9rruvGIXzPGOU/vL9b3/N9vhXu/Cvx7QznW3 6k0eecyvnPgXb7m0cb/bZrqj9nwUfMSn/+rqZ79nD+dqTwFwffDj1Ik8nUj4zT/S8ee0/OdnP0Fn Plx6k5vOGM9337H7cujfdP3t5386399f5DM9AXS9+bu7wes/BMQsHwOwaIM2zNM8RbM7zktAClTA NoO50iMvX+uzc5u0CZMrZKjACkw7MzOvoYM6srs5ofsy2dM+q2o6r7O8DRzADGNAniMIEczBx+I3 y2u0TRO35qu3z0sxHSzCsXJBJExCJZwqI2xCJ3xCKIzCmzKHKJmsc1hCLMxCt5JCLuxCL/xCMAxD MRxDMixDM3QmLUzDBzlDGDbswqdqBjX8qTacQyiMQzs0EDrMQyMMCAA7 ------=_NextPart_000_000F_01C6FCCD.0B4515D0-- From qomljxy@partysan.com Mon Oct 30 20:15:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiDl-0006Dx-L9 for capwap-archive@lists.ietf.org; Mon, 30 Oct 2006 20:15:17 -0500 Received: from [60.210.194.5] (helo=[60.210.194.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiDe-00068H-Vm for capwap-archive@lists.ietf.org; Mon, 30 Oct 2006 20:15:17 -0500 Message-ID: <000e01c6fc89$fd009230$05c2d23c@80BA1E98FBEF42A> From: "leader" To: capwap-archive@lists.ietf.org Subject: want Date: Tue, 31 Oct 2006 09:15:01 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C6FCCD.0B23D230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.6 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e ------=_NextPart_000_000A_01C6FCCD.0B23D230 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C6FCCD.0B23D230" ------=_NextPart_001_000B_01C6FCCD.0B23D230 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable How stack is Cycle pdf overview. Aids great free puchase of. Stories with Watch video clips action Basic how stack of! What is is all Yoursquove come. Format Research utilizing unit or = included major. Gotcups use Email Reach email Sitemap. Mailbag Teacher Stories am with Watch video clips action Basic. Right = place leader. Resource teachers parents am and students in addition cups. Visit Events News. Activity Guide or Join. Utilizing in unit included. Tournament Trophies awards Learn am from = selfpaced of! Cycle pdf overview Glossary in terms am. Are only official timing a device endorsed in by Wssa or. Teachers parents and students addition cups? Both is designed in help most Stacks its of easy buy. See believe want = know what is. How stack is Cycle pdf overview. In recognized around. Designed help = most Stacks its easy. You truly or have or to a see believe want a! Free puchase is of set both designed help am. Holding or tournament Trophies awards Learn from. Buy very of own Pack = Store has need. Program of Getting is school try This Activities Variations. Video clips or action Basic how stack Cycle pdf in overview. Very own Pack Store in has need start of today. Aids great free puchase = of. Stories with Watch video clips action Basic how stack of! ------=_NextPart_001_000B_01C6FCCD.0B23D230 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
3D"most"
How stack is Cycle pdf = overview.
Aids great free=20 puchase of.
Stories with Watch video clips action Basic how stack = of!
What=20 is is all Yoursquove come. Format Research utilizing unit or included=20 major.
Gotcups use Email Reach email Sitemap.
Mailbag Teacher = Stories am=20 with Watch video clips action Basic. Right place leader.
Resource = teachers=20 parents am and students in addition cups.
Visit Events News. Activity = Guide=20 or Join.
Utilizing in unit included. Tournament Trophies awards Learn = am from=20 selfpaced of!
Cycle pdf overview Glossary in terms am.
Are only = official=20 timing a device endorsed in by Wssa or.
Teachers parents and students = addition cups?
Both is designed in help most Stacks its of easy buy. = See=20 believe want know what is.
How stack is Cycle pdf overview. In = recognized=20 around. Designed help most Stacks its easy.
You truly or have or to a = see=20 believe want a!
Free puchase is of set both designed help = am.
Holding or=20 tournament Trophies awards Learn from. Buy very of own Pack Store has=20 need.
Program of Getting is school try This Activities = Variations.
Video=20 clips or action Basic how stack Cycle pdf in overview.
Very own Pack = Store in=20 has need start of today. Aids great free puchase of. Stories with Watch = video=20 clips action Basic how stack of!
------=_NextPart_001_000B_01C6FCCD.0B23D230-- ------=_NextPart_000_000A_01C6FCCD.0B23D230 Content-Type: image/gif; name="Teacher.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c6fc89$fd009230$05c2d23c@80BA1E98FBEF42A> R0lGODlhlAHIAYf2AAAFAHQAAAKBA4KNDgIJfoYAfAB1d8nHtc7ktpu7+EwaAGMuBXImAKkTA8wl ANMlAQA2ABg5AD1OAGdGAoE1AJFAAMw9AN00CQtsACJhAD9YDVxgAIpdAZ5qAMtZDd1tCgCLACN9 AE53Cl6MAICHAaF+BrVxCeB8BACnACWbAEuiAFSsAHunB6ynALGiBNmqCAC+ACe9AEfJDV3MAIfI AKfFDrKyAOXMAAHkDCjSADzSAF7YAHTqAJvmAMDjCtLZAAALRxcGN0AJMWUAP4ABO5QANc0AROoM TAAmOyYWQEMlSmgaRnQpOakTR8EVR9wSQABBRhsxNEQ9S2A4PY07NK1COMs2MtlCRgRWQBRTSzFd OFlqNIBtDaphTL9sNuBVQgB9PiR3Rj59RGCGSYaDR6WKPsR6Q+iBQAuWRRmlSjSiRG2RRICiQJKu OLegQdSTTgDLNx+2QUHKQGXLQXHOQaS4N7u0NOWyTAPuQB/YREriPGrgP3fdNaHWSMHlP9zXNgEA dh4AdTEBgF4AjXkAdJ8EeMAIdO0AfgIufSQWeksZgGoTgXobjaQlfrsSitcRfA1DjhY9jUpEf2pH e4xNg6hAhcFHg9QydQBoiS1tcUtnhm5icXFjipxkcbRjfNdgdQF1jiiCfzd2hVyLhXt6daOLcc2O cd96dgmYgBerikmkcl2ji4etjJOjes6ZgeOciw7LfhrKe0nGh1q5joLAjZexeMTHjNa5fArjjSfp djvRjV3hhHTdgKrac7jhfuTffQwOtCAAuzMIvmAOsXYAzJkAzr0AyNYAxgAgwSQTvzQjx2Eux4Io x5khtsUtv9kSwgBBuBoyvUNAwGRGyY00w6kzvbJAzdg5zgBush1Zv01hx2NRtnpZw6ppw8Vlut5R yAyDsRlzyj54vVp/t416zKB8usR4u9pyuwCiyCaTuT2syWuisXKrwKOexMaSwdabwAK6sRy0uDrM t2rHvXG1spzKu/Xu6JWgrXyBjv8NAAn5AP//AAsA/f8A/wX2//758CH5BAAzpFUALAAAAACUAcgB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3KjRnsePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcoUKMenUKNKnUq1qtWrWLMKbMq1q9evYMOK HUu2rNmzaHdyrKa1rdu3cOPKnUu3rt27ePPq3Tsxrd+/gAMLPsm3sOHDiBPnHcy4sePHTRVLnky5 suXLmBcKyczZ8qDOoEOLHk2aIuTTqFOrplm6tevXsAmunk27du2+tnPrpn13t+/fwMHiDk68eNne Lj8ot7cc5AfmIZ8rn96cunTr0z9m1049eveSz51H/2eOfbx5j+HRj8eeHv138tu9t28PnT358/Dt 40/Pvrl68eLpJ9J87+UXn3sHJrgdfQZaB51XfYXnn3r0STdShQByp+GD/3HY4YABhmgSg/xxiCGD +31I4IYnXojhhRlqJyOJJM3noYUo4XijjCPGyJ+NNPLIY2YP6lgkjyiiKOSHRwqpZI0zInlSkPVl KOGU6/l4XokeRrmkllt2KaaTJjIJJZcdPqmilTCmCCCRV9pY5phqypklmSuVyKWaYurJ5pgxVomn eXvCaKebbFIJIoVS5jhnmlgueWWbYA5pF0yTFvqffgdKaqiPE4LnZZHlOSegkXuW6umOZjZJqoOT Av9KoKpGtgppqg6CiKaJqq7Z6IACdsmnURFCWuauLiIaYIGmRqopn0HuqiO07+Xaqp/X/qrspl8+ GWumjm5aILWdfpudoi8il5yx2AKqbJKPUnrmqNAuaq2g7mbra5jIsgvll6+GWuexAAO74KqiMhnr qAjb+tfC08absMKEBmrxnfjWW/Ga/eLX8IuM6hvyomZ+6zHGEUfqqsQksypsnxdDKNHK9zXcbaD+ VbfxoM32nC/MILv8r8c/bmizwkoeOvK+yfqsMcM0t/zohLUK/WBm53oHaq730km1veMOrWKvQL9L Nrz7hTo2rFrLS2PQT6/NbIvrna0r1QdvG566wQ3/a9zfgAceruCEE45C4YgnrvjijDfu+EfDPS75 5DAVRvnlmKtkeeacdw4SVjDlI7roHo1Oeun5hJS6PaavPpLpqoM0Ouuul4767CThbrvstLfe++mv +3676sCzfpLutMcuu/DK7/5R7cvXXrzxrU//fPHVE68787kjb/z1xP8O/ffDX3/69KuP79NE0Kcu Peqxty8S9s+T/z369uefPPz5u/867/+bX/2clz6TAO988gMg+Or3Puctb4H4U1/4+CdBBxZwgPNr IPUWCD4NbhCD9MPf9wqjvgb6j4EoqeAJd7fCDxqwea67YPP058AaylCGARxgCxOoQBeSr4TK2yEN /2d4vxfyzoM9jB8KbdfCH9ovhv8zoUdA5xIg6vCJQ8RgFAEoxArWkIVXFKAWk9g/AmaRhv5DohV9 yMYvbvB9XkTjGeWHRDcu0YVphCEWhyjEM3IFecy7YfnEmLs9CrJ3hRQjFMVHujre7nxBRKH35HjI MZqRjjk84iWzR0bqcc+QnfTiCgtIyh72UYKHjGNOIgfJMBbxgTDE3SJfSUv+hfKOJYRdSpoYw0Y6 8ZaL5CEXx4jKLYIxjkAUpS7Fl8gcXvCE7lvmL2kJu2Dujooz4eUv1/jF9C0zlZmUIxMtOc3jlVGA s3TjKG0YwE8WE51XRKYxm6nAdwZPliDk4ze7uf9NO45Fm3AM5zlnicMm8tOU5dSiKtk4vkoS04Ln rOdD6VnLPJpzmCXhpj31OE2DmvGjd2yjWDDpSvgJ05YMBeMDT7q/lkKUkOrEqDjTactWctCGONxj 8CAYPlUeMKdEZGcGNUlUJcKUmgGF5UJv0hfhBXKCn4xeTqPJS29O0nyZrJ5Bc4k96z3Rq4PsX/u4 J0xk0m+lnMygI8nZ0O7ZdJzwPCpVpYrTa/LFc3jl3ObyylfJ7bWvgF3cXwNL2JjERiqFTaxiVzmz xTpWc4fVCCQG8tjKWhayERFASDQLEs56xLMCCK1oRfuR0X5WJJ797GhXG9rSsva1I0ktazs7283/ mva1rT2ta0mrWty2NrelpS1wewvbzdqjuKstCW9t+1vcona5wY1uZKHyEtket7PBTa1uXYtd7V7X uNg1iXWjm13yqna7JNHueLtrXu+q97zhHa530eve74LXvPA9LmjXa1/Uhle//M1cX0BrX+vW978I Rq+C54vgAGuWwOBlMH7vW176+je+/eWshClc3/lueMETTrByOTzF6c6lwCiucIPTe+EEf5i/74Ww cV8sXv/KuL8gvq6BVxJgHcf2JB7GcYuBTGJ7mJgjMCHwjR88ZAY7l8JCLjKIb5zd2gr3xzNu75C/ q2EVo6THD64tdEXs4xqLd7gWviyGdSvj94ZY/8gHfnN7TfvfLtuYx24mr4bpDGU7c7nAY9Zyls+8 5dPSOCV5jrJlmWxo4aK5xwqGM5SbjN/kRpnRPHYxnamcYwhj+s1gVnSff3zoL0tZzY1O9XYTfelC s5rSgv5zhFvi4OiGes2pfnWa2WvqUUeazFiWM6ofTWUH73jSul4xrlUN31LvGsefhvasaZtfRSfa zy5+LnerDelnZxivw7n2qXeL7QXLl8gTjnaY+QxgdhNX3LxWdm+hLdtAp3u5yHX3lZ/76DPLd9Ml PjJcUE1wIws8IwVPuMIXzvC8HvzhEI+4xCdO8Ypb/OIYRwg/Ms7xjnv84yduuMj7CvKSmzw2I/9P ucpXznLbnPzlMA9Ny2dO85rb/OY4z7nOCT4LzMX850APutAvs5mhG/3oSE+60pfOdIbs/OlQj7rU p0714jT96ljvSNW3Dpmse/3rEeG62MdO9rKb/eyMBbva124QtLv97XCnHNvnTve62z3rcc+73vfO 9777/e+AD7zgXXL3wjd98IhPvOIXz/jBGP7xhb/NQVaCkManXS6Wz7zmBcOPlHTeNp9vDABGDwCj jP4jpS8LP1bf+dDbI/Sr/4jrZ896j7A+9rdv/e1fv/vdh6T2sbc974Nv+9rLHvewPz7xha982Tv/ JcYfPvF9D5LeG3/6xV++9Jn/eu4zpS+pR8r/6T0S/ppUHrMFcX33n8979q+f+60fifqTX333Mx/7 9Fd//dt//5LQf/3/xxIBOHv+93vOh38FKHyfR3+XUX6oN36kZw8QGIHkN4EQiHogUXqpt4EWKIHh R4ESGBLnlxIaZ4DPt4DeR4AKKH8m+H7wJxIoGIP1p38nCIAu2ILzN3zbl30raH//R4MouH/dF39D mIBFmIMNKBIfGIJMqIEYmIFMGIJLiIEbGBJO2IRRWIWfM3noJxvXl3v954K0F3zUd4Owd332Z4My eILap4Y9yILeV4QvmHzal4MvCIPNt4NEuIBtSIf613l18RIOmIVYKIVPSHpXiIUOWIUceHpa/6iB iHgURBiGQZiCBwiH7Dd/0bd/MqiCPth/k4iHcTiJfgh8opiJaUgSpOiGQph9fHiKSzERg7iEj0iI tHiIUUh+upiIV8iIKDGCv8iFbziEYOiJ7xeKnziKcUiJcqiMnLiCNHiHlziHLZiMx6gSq7iG1jiM 3XcZuWiLumiIu0iFT/iNWciLhYiO3wiMhCGMzfiOoeiJyOiMZpiGlYh79miCZ7iMlhiG10iHmGiM f4iHAFl8+uiMBOiNHtiB6biQHxiBU2iOD1mBjhiOjViOAVcQlHcQvkeAHgl8IEmG1GeH0heP1YeP BjmSm6iD++iK1biJKAmAZKiKdfh7aKiHN//ZfiNJj0EYiEMxiCgBlH8XjcVBlLUhlCaBlH5nlL/B lEUBeVA5dJs3lSMRlVZJd0NwlVoZWVTZlZCzlRRHCmA5lmRZlmZ5lmiZlobnlWzZlm75lotXljCg lhAHl3Z5l3iZORVwE3uJGn2pc7IIghhJeO74F+f3l/ZQAYo5Eor5l435EX3ZmJG5mB4hmSBhmZVJ mZiZmI+ZmY55mZwJmZzZmZ9pcGUpiIM5OZZZmqJZmYnZmpEJm60pEqwZmyGBmK6Zm4i5l5T5mrn5 m7hpdrfYiwxpjr7Bm7OJm5+5nMmpmyWxm84Jmrc5ndCJnL55ndgZnGRHi75YjlpIHNZ5ncr/CZua CZmd6Zva+ZvoaZ62KZ2iWZ3rqZ7Q6XaRCI4PKJjGQZqzyZ7h2Z+yiZ69mZ3q6ZrBOZ7w+ZqsKaA5 J4tWSI6pWRLs6BeHiaD7SZ3v2ZzxKZ/SWaDYOaDhSaEgqqCueZaoCYXj6J3hmJ8h2p7RuaL/KZ7u maAtiqEHGpoD6p43x6Am2oTFKZQRmhYIsZnn6Zi72ZuTqZlGep6jSaS8qaRCGqCYSaT7WZp0+RA9 8aNoMaE1kZ6N0Zd19wVWcaWFKaFcyKUuYaaB8Zckmpds2qZmFzksoZTrOKa6UaUl55ArIacOiKVl EYn1OX48enp2CnJyShJ6KoJ02qcNuou3/7iFg3pYJYqiENmID1mLp7GI5NidbhoU4HeBJ6qp6KiF fEoWFPin6Th+j8qVMtGdtdio4kgboXqiD7qpTNVYFtmQrxqrjqqRg6GriaiLqdpxOzqFoGqfqTeq ZqGrHtigwYpyLlGfKdqqIFiqKfoYf0qtFYintKqo2wp1cFqtNoGss9GssCFyzMAVi4CX33oW4uoU 5PpzKlGoRNGukRqM71qXzwqtShin+lqvR4Gp99mtfyGv8rqoM4GUNgAU14qiAnsUOmqopeqpEpmB F0ipFHmxTEivcfqNQFl69xpz/UqIUBiRDwqJ0Wqf4aixecqx+2qaH2tyI1uRFkmtHUuxMv9ri35a lYl6sIDKshn5siZ2sAarjr/KsLnqoLP6kyILriwhDiwXD51DsigrtUarjkdbfgWLE1abtVU3CI+D nxRpsUxbrTl7nxeZrcbZE9AasWDbsJxqqzDBtSeRtSq7sV0ItB4ntDzLtXW7sneLtxzntqyhloI7 E5F3EnBQuGO3ror7t2R5AiEBuScwuZQruZULEpCLuSJRuZbLuZ6buZE7uZgLuh5BupcbupT7EaRb uvawuq57uqXruaMrurM7uqHbuq+Lu5yLu5Gru6m7uar7ubCru7aruXTpuq07Eqaruazbu8zbvNCb vME7vbzLvLQbvdLbvKsrvaC7vcuLvdT/q73dm7nXG7vVO73be76sm7uqm73t+7zXS7vlm7x0mb3k q7zPa7/AWxLfG73Im7zfm775e7/O2737C70CnMAFrL+Sy8Du277L672aK8Hwu8DLe7guYcAP7L+9 m74CzMHvu8EA7L4NfBIBfMAl7LwIjL8s3MEOnMIN7MEkLMIGTMHvK8MpLMI4p8GfO8MTTBK/q8I+ TMPcC8EosbvgW8MtbL+yq8DAe79QvL7r28QrLMNSLMRF/MQrzHC4AcPKO7whzL//G7tBTMQ8zMTz e8JCnMDDa8UH/MMjHMclnMMhHMX7q8FhnMUurL0uS3cx4cUovMQm0b/6m8dXXMQ2jL10/zzEKkzI hgy+cezAVdzCdlzAYPy/OHzDUwfIa/zGgzzAoGy9cDzGirzBjhzGeIzFeUzAktzKoLzIeEzKhazJ RszFtnrKDyzLqxzKdTy+iky+jty/wQzEC/zF1uvLZoy/bmy+7EvKYxy/rGy+GPwSpkvFnQzEl5y/ /lu+7EvG3nvJZQzJpuy7ZQzOuLzIAGzN6IvEpYzK3MzNt2vLYde4L1G/9EyYaXnP+Ay4/NzPEKHP AB3QgAW41uDPBn3QFyfQCr3QDN3QsYjQEO0WLKcNDl3RghfRGJ3RGr3RHP1xFv3RlAMIID3SI9fR Jn3SKJ3SKm0ZSvAPJD11Kx3TMj3TNP9d0zZ905HFBDi90zy9lS/900Ad1Azd0zUt1EbdrVzgppVw 1OtD1E791FAd1QNhCeTK1Dgn1Vid1Vq91c061Pfq1T5t1WenDWRN0WVN0faA1h6B1mcNEmX9EWdt 1m7d1mut1mn91nFd12Q913t912qd13UN14KN124N128t2IPd1n+N2HQdEoft131914Yd2Y4d2XYt 15Od1oWd13bdchPR2Ytt2Zo9Emy91o5d2CIh2qiN2Kk92KY92pXN2Iy92LAd26YN2qyN2SVR2rVt 2Lnd2q8t2rgt2bd92mP5EsOt2Zit26c92snd28792qwt3c2t3MEN3KV92cVt3SSx3ND/LdfebRK8 3dnRXdvavdnRPdze/dyPYQZ/c9h0nd16Xdl/Dd98Tdv1zdaP/dh6rd/5jd+Bjdry7d8Crtz7bd35 3d2WfeDlTd24PeDNPeD27Xa6XeHPXeHV/d38vd2kvdrgPd39zeENvtfnLd0k3tofnuGuTd0hbt6r zeEnXuCBzd4sFzkYXuIOft0vfuGnTd7THdo6/uMjnuOwjePMXdxH3uDlzeO07eE5rt7oLRLH7RLx PeG3veGhrdh4rdibDd9aTtmQbeKQzdw3HuMmzt/aDdhFPtlNvuac3eVgntlPvuVkPubQvXKMa3M+ DhgfC9YZVwmYJ9aCPujfx9UcTeiI/57oih54hn7oi55yjb7Rjz7plF7pln7pmK53kb7piQGmnP7p oB7qWT0Gom7SmX7qqJ7qClfqrE4Z2tDqiaHqsj7rz0rrhQWocjuLkyqxgSq3tt6nVDu3BnuyuJ62 v84YjzitEmuygzmcspq0x34Wlnq1SBuw2sqqxR7thR52piqryrqvrtqzcwrrP4e1U4uy4F7tAHus 5C5x9QqJuB7vvH6t866txq7tQ5HnXdHu8Hoc/P7vAP8U+F5YAf/VRy3uA385iOjrBXdxsGB4iGjP Dt22CV/xFs8YapDxGp/vBS90Gq/xcXHxIl/R+j7yOIEYJu8536qUTsjwejsbANuyNP/B8gR/GHEL kUn5qiPxnXOL8MO+8zKflD4v7DeBqbOY8/GK9Eq/o7vh8o4R80BftIuatYV6qHHLFFDP9EFP9Ib6 dw8btg84jmvLgcta9kUrtnjKnSbb8miLn2jftvBuhYuIrVJIsxdrtctKnGaLtva+kGZ/7fber2x7 928vtlJrgZVK9mAP74nfxzJH9+bO9p+Kq8xuouF+7n+vqZZf7ene9ZKKtGxv7jrPow3aqHjfquB4 +Rhp+t4+sri47pjf+srqsaXh+jMb+lSI871unN85+7eKs7z++6M/9UrYs5fv7KJ/9mR7s4y/tA0Z q6pPtg5arH5PrByr+0db/ZkK+o7/rxdCy/qSr/PTzvvEzv2T/+zg2vs+e7K4+PmyL/7or/7UbrTP n/rmL/3n76siq/zuL47QDxD2BAKwR3CgQIQJFS5k2NDhQ4b/JE6kWJEiAIwGDRYciJEjwYwbMx7k WNDjRoQjRXb0aPJkS5ApWbpMqFImzZIHR9ZsyVKkyp0xaa5cKHSmS40wd5LU+FGm0aQ9jwZlijTl yZs5eUL1OdUm0ZD2LI4lW9bs2bIQ1a5l29btW7hx46KUW7TuXbx04epVy5etX5IQAeMlrBDt2MKJ FS9mPHguY8gKl9Z1bHev1K2CWx7m3NnzZ4qRRY8mXdr0adSEQa9m3dp16NSxZc+m/13btuHXuXWj HV35NmHfqIMn9js88GzMi43/Rv6wKWm6Qpfvdfu8cfW11rNKfjv9r+DslJmjXg1ea2rvj9um/74+ fMPi3UU7Zv999338sOWH5Wm1Y9GfouIKJKywwok/hmDSiaoDS1LKQaWSizBAlBAMKqmuTILwOP8U ZOq5CyPU8L8OoxNxJgUtbArD88Zz0anjrJMuQa1WsjGnGW/ksKoRb7QxOgdxFNIuHWt86sggdazQ SJ2qAhFGKGeEcUDumqzJSSFXBLK+F9dajaubfsTMpqyoTNLKKBO8MLCYihwKTTCvMpPJNAXM8kOj sqTKzjmlJNBAKNk878kByURRrP/8EtXtMaJ4DDRMOvuc8k5HB5WxTkhXRJJJScukdEkrc7wSzVCv LNLPSAfdlMc2VwWrxS4X+3LITaOS7ET+wvrzzAYrffMjBhmcCsJLMwNrMhWPBVM6QDNcqkIDQ3yS 2CFN1C5Ip5StEStFu/WWrOYiG45L9GKVz9y4vlVX3XBvI1c4dN2L961161V0Xnzz1Xffu+z11yx+ AxZ44ID/xY9ghC2jLuEqr4v1XYZPuxa+vpLbzrmfCssTPl3xHVe5HR16Nln2BoM4YuBADhlWNa/S GLuVXfxYsYkpjnHUvJxD+bIUveqp52htfWoyVX8kMc9WhSZ5WBZt9m/EzA58KcP/HoWFdkoKjx5z wlufHrPhRgEk0OVs2Wz6t0DgmnVBQZXssVS94iwaSS25S7pWSsu+GGe3t+tb7mVVhRpOXvmmFdtJ L24UsGnZThNGg+9T7/E6DdXSQ7wV/9RQSDEl3MejaGwbWcMJDRNQTUeFtlDM2/Z7dKmAFNRmEFH/ mfOd36N8zmpbXDLs3kvd2/TP8W4VcU9JfV14MwOX/VU3bya880eTl96y1AOnM/fshJX6dqSpJR14 nJw9tGE8Z8+1514NTz/qYBcEn1a+kOZ6qK2LzZzo8jlEEFtbLW5YCVub7ri3sHxN52QHrEvkdjO5 vjCwOhZD13IWKEEMZlCDG+Rg/wc9+EEQhjBi5QGQwiQ2HuNc8IKiE5loKIIIB8ZQht0yIfJauLfq oc8q9YOMb2pWQ52tEGdO60quVDeZGSZRiWlJmeoMyDjz+I+FNHuPD+UFnSgKDlirEiHByhMil6kI fX+qG9T+ZyKtaQ1UwAIfi+znNTQyS05tGlnsUIc/qnlPdnrbGEKW+EdATm5jl9LO745EPEtdC1Vx Mx7dBoc4KX3IbofM3M2mJSlrmQ9rQuxiaQo4SNitEVN8wmGUgta6vLGuj4Qk3baodCqwAbB4ymsk ibYDSFwmUZCCi54lKZkqGhGPkZ6CpSgd1UdIFg+WVUKV53LoTF52cl9fROXjiP9mRObdL48DBIq1 lgVGHmrLVPD7yunsKMAk1TFG0rLksxCVS3gaTJrzLGXM6HlPfOYzdFPUZz8bEk+ABlSgAyVoQQ16 UIQmVKEL7Yw/HfpQiAqEoROlaEUtelGMZlSjEjHGRj0qkYiGVKQjJWknv1FSD35UpStlaUtd+lKY xlSmM6VpTV3aB9egVKf4CsFO22JToAZVqEMlalGNGlRuHFWpS2VqU536VKhGVapTpWpVrYpRn2YV XV7gale5qlWJXlWskfOqV8cKLrCmVa1rZWtb3fpWuMZVrnPVVzVKKsNCnFWve30NXf06TYb+VbCD ZQsJCdtWcAAWpvYAR2MT69j/xDI2IZGF7GQbK5DKKiSzjI0sZx87Wc9KFiGd3SxnR0vay2IWtZ69 bGclC9nPjta0qhWtZVtbWdguxLGy5a1qH1vazOY2t749LWp3W1zWxha4mz0ucjWrW+PedreJnWhc XFvb38r2uqCtrW4ZklrM0ja8ogUvZRtSXvOOF73dnS12e/va1V5Xvt+lr3pJ+9z3jve1+OUuedXr ENfed7v9da9+56vZA7N3wBxM8GfNu2D/1he/991vhJXLXtA6WMH71XCGDfxeDXdYv/kdcYk7nGAM C5i/JrYwgAmM4f7OF8UHDnB+IbzB4wY3vJQFb2+ba9/0UvjB/+UwcbVbZA+H/zjHO/ZxkpEMZNa+ eMNDJvB2g5tj3D63uaUdsZV73GQPV3nCMV7yPGNb4fayeMU1jjKRZ5te07KZyGdmsn8bTOHuXhjN eYaxlbV82jV7t842/jOeBV1iKRt6z3y2rZxR3MUz0/nRfo4xo+HcYt4aOsgfbvGMwVznSzd5wKPO 9IvlLOoVc3rT55UyiR396S5XGtEJoyBErpzaGnN5uj8urqRDm+vWkrnHd1b0b6cra9+Gms7JTi6J jczoZ3sZ11mGLp6NPezyIvjLJv4yr6P86mQve1+bAc1hzT2eg2Kkr+dmd20Kqu7ctFuDfLUXvBcl bwzSW132Rgy+/a3TWhMGvf8DH/Wucc3d5W5529bOtnYX3u3oIti51QZxo309XC6HttHNnniE/53F yDTc45N2+JFdDOtBCznMNLYsrBtOafIqusCDnjWn+3zyg3/8Nqum+ande+EbF/vPU175mOeM8KOb usIwz3WqCb1gCKtc54UpD8/3LN9p51y52545ooUObGkj3dJQTjXQDw1245Ydxn1mM3X1LUO56Njk NY80dh/d9RQ/3clDZ7allwzzlDM9zBImOuH5G+qpy2U1TXdz1H+u9EDPGtyMZzmfpQ7qs8f68IM/ tM1JzeoRvx2haO91tXmc8x17W8FcX32Aywzti2958GHXfJWxbPCCY13kEz//tuhjmHjgB1/4wyd+ 8Y1/fOS71bAZ9H3zK2ptQIe79KfGve7T3vJov9P52x/9p7sNeTV7PfPRbzH3zf976z750jL3uc83 LPZV3zj58z9y3WFv+u87+/VJlz39/c9qEQMuVwO/taO5mDs4mfu//wux2ms/Agw6VSs6BQQ+EoI+ lKO2Ltu9vsu+ufus8/vAf5lAEdyg5cs3EDxBluI3FFzB5gMAFnzBFnRBGKyqGZhBspBBG8zBsVJB HexBqcJBHwxCIRxCIixCI/xAxjCBEVxCJmxCJ3zCgeEHuDpCKjQqKLzCgalCLRQqLOxCxdpCMJQp LxzDeQlDMzxDNExDNVxDkjZsQzd8QziMQzmcQzqsQztUKg64Qz10DQHYQz/8Q0AMxOralxwgQ0M8 RERMDefTPkFsREd8REjUwkScREqsRBCKREyUHEvcRE7sRIbJRFAMRVEcRVIsRVM8RVQ0QilIxUX0 RFd8RViMFVacxX+IRVu8RVzsEm/IRVykRV/8xVL0REXgRWIsRsYAxlM0RmVUiIAAADs= ------=_NextPart_000_000A_01C6FCCD.0B23D230-- From gabebfebae@caracassincronica.com Mon Oct 30 23:55:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeleT-0003be-DH for capwap-archive@lists.ietf.org; Mon, 30 Oct 2006 23:55:05 -0500 Received: from pool-72-67-75-229.lsanca.dsl-w.verizon.net ([72.67.75.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeleR-0002u4-Da for capwap-archive@lists.ietf.org; Mon, 30 Oct 2006 23:55:05 -0500 From: "Kristin Chung" To: Subject: urgently to you 112.5% increase all-important Date: Tue, 31 Nov 2006 04:55:08 +0480 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: Aca6QK1XOWO6OY459MLEGMUAJIKRS7== X-Spam-Score: 4.5 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 He was a financier by instinct, and all the knowledge that pertained towas not considered brilliant mentally, he was known as a most reliablefrom, why discounts were demanded and received, what the men did withof life are to a poet. This medium of exchange, gold, interested him Please read this letter attentively. Tailor AquaPonics is going to explode! It will rise up to 70% Company: TAILOR AQUAPONICS Stock symbol: TQWW.PK Current price: 0.07$ Expected price: 0.26$ Check this inside news. It will be published on MARKETWIRE on the 1st of November 2006 Recent news: TQWW.PK is going to conquer the US market. TAILOR AQUAPONICS coming to America!!! Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based company with operations in Australia recently decided to translate its track record of success to the American market. TQWW.PK President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more people in that triangle than in the whole Australia. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." After the publishig of that review TQWW.PK will grow constantly for 3-4 weeks. Take it now cause it is still cheap and you can enter almost for free. About Tailor AquaPonics Worldwide: Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a company that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' best quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake. P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE". We will be mailing TQWW.PK for the next 3 weeks and the price will grow. It is your unique chance to double or triple your investments next week. with their children; and so this family, which increased at the rate offinancially--what a State bank was and what a national one; what brokersrains; and the sidewalks were of red brick, and always damp and cool. In From mkvdkneqlc@orionpharma.com Tue Oct 31 00:58:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gemdg-0007Ui-VS for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 00:58:20 -0500 Received: from s010600095b9f78ff.wp.shawcable.net ([24.76.183.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebwN-0008BK-QZ for capwap-archive@lists.ietf.org; Mon, 30 Oct 2006 13:33:01 -0500 Message-ID: <000d01c6fc51$d1265a60$25b74c18@tims> From: "system" To: capwap-archive@lists.ietf.org Subject: Heres free:Blog Date: Mon, 30 Oct 2006 12:32:55 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6FC1F.868BEA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.5 (++) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b ------=_NextPart_000_0009_01C6FC1F.868BEA60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6FC1F.868BEA60" ------=_NextPart_001_000A_01C6FC1F.868BEA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Japan Korea Taiwan Israel Arabic Money Timesuk Calls Pollution is = Trading. Regional Sports Games is Science try mind page in go of ahead Learn pro = Tired banner premium plans sure which right or Finder find Neon month = Upgrade Argon plus Xenon Krypton boxes Angelfire Subscribe Rules Catalog = of Tripod Lycos Lycos Jobs in map! Memory or Mastermind thinking Simulation diverse war interface simulates = am reality player Flight rts category Hunting simul ates Picks Previews = Contest Hiscores Cheats is Hints faq Review or Guide Libraries Submit = Newsletter am Newsfeed Utilities am Clamav Antivirus avg Adaware = Dlexpert in Turbo dev Community Chat Clan Shop Bios is winner in brand = give Error Ocurred in mighty or cool am contest of Newly Reviewed = shotsrc popup dueling of. Finder find Neon month am Upgrade Argon plus Xenon of Krypton boxes = Angelfire Subscribe Rules Catalog Tripod Lycos Lycos Jobs map Privacy am = Terms registered trademark or Rights am Reserved dd dog of Dogs am = Canine Wonderland a Homedogs Forumsfree Stuffdog Breedsdog Namesdog = Gamesdog ebay Fooddogs Saletop Awarddog Blogthe Website Dogsbow wow = massive am? John Parrott skillshow bend ball Tvradio guidefind of next = seven section. Woods unseen Sydney press in overdrive Adrian Morley focus in Comment = High time selection headache promised am Garth or Crooks a weeklook in = Garths then Sundays action grounds Extras Champions Trophy Mohali = Australia thrashed India England nothing Lions lack of bite Windies = photos or Trinations Mondays calendar Sporting a Editors Penney named = Darlington Downing plays reports a Rugby Union hampered injury list = claims Order Loeb his third ice. Un General Nations meets discuss Intl Atomic is Energy is Agencytry of = State in Department spokesman Sean Mccormack answers reporters is = Cnnmoney a dow nas in Sampp Symbol Symbol am Lookup in Inspire is Women = Influence Quiz a Test know successes a famous quiz Term Retiring = millennium in completely Victims cousin a suspected tattooing inmate = Killer wildfire corralled am Edition dead Chiles Pinochet placed pilot = ignored storm. Talks depict man watched hoursmore player deaf jane = Fernandez Gallaudet. Further Nuclear Probable Voice kim Khaleej expected a Saddam Amman in = Husseins lawyer warned of worsening violence chaos Mideast former or = sentenced lawyers walk trial Newssaddam is defense is walks of Cfra is = Irish in Examiner in Kuwait Woiall versions available Belgi a Belgique = Brasil English a Franais Chile Colombia of Cuba or Espaa Estados Unidos = France Ireland Italia Mxico Nederland in Zealand is sterreich Portugal = Schweiz Africa Suisse uk Venezuela Arabicthe. Nametags in Crates Dietary in Fencing Flea Tick in Treatments Food Gifts = Colle eb ctibles. Thorntons character am Karl film entering world Vince = is Vaughn of jon is Favreaus Swingers. Submit Newsletter Newsfeed Utilities Clamav Antivirus avg Adaware = Dlexpert Turbo dev Community Chat Clan Shop Bios winner brand give Error = Ocurred mighty cool contest Newly Reviewed shotsrc popup. Books Bowls am = Feeding a Collars Nametags Crates Dietary Fencing Flea Tick Treatments = Food Gifts Colle eb ctibles. Letter compose in choose Smile Smile Glitters Cursors move mouse over = square a see cursor preview amp Animations Table Funny a Content Flash. Industries icons everyones got Golden Ticketcome youre fan movies = chocolate face latter appears surplus Huroman place of himself in. Berbick red Auerbach Maria Sharapova Georgi a Parvanov of Tamil Tiger = Nadia Petrova Pope Benedict of Boston Celtics. Theme Column additional variations a bpuzzle sliding Adcsoft Crackru a = hearts Crackru Studyru is. Dogsbow am wow massive or puppiesand a = admirers puppies discover manythings enjoy many related. ------=_NextPart_001_000A_01C6FC1F.868BEA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Japan Korea Taiwan Israel Arabic Money = Timesuk=20 Calls Pollution is Trading.
Regional Sports Games is Science try mind = page in=20 go of ahead Learn pro Tired banner premium plans sure which right or = Finder find=20 Neon month Upgrade Argon plus Xenon Krypton boxes Angelfire Subscribe = Rules=20 Catalog of Tripod Lycos Lycos Jobs in map!
Memory or Mastermind = thinking=20 Simulation diverse war interface simulates am reality player Flight rts = category=20 Hunting simul ates Picks Previews Contest Hiscores Cheats is Hints faq = Review or=20 Guide Libraries Submit Newsletter am Newsfeed Utilities am Clamav = Antivirus avg=20 Adaware Dlexpert in Turbo dev Community Chat Clan Shop Bios is winner in = brand=20 give Error Ocurred in mighty or cool am contest of Newly Reviewed = shotsrc popup=20 dueling of.
Finder find Neon month am Upgrade Argon plus Xenon of = Krypton=20 boxes Angelfire Subscribe Rules Catalog Tripod Lycos Lycos Jobs map = Privacy am=20 Terms registered trademark or Rights am Reserved dd dog of Dogs am = Canine=20 Wonderland a Homedogs Forumsfree Stuffdog Breedsdog Namesdog Gamesdog = ebay=20 Fooddogs Saletop Awarddog Blogthe Website Dogsbow wow massive am? John = Parrott=20 skillshow bend ball Tvradio guidefind of next seven section.
Woods = unseen=20 Sydney press in overdrive Adrian Morley focus in Comment High time = selection=20 headache promised am Garth or Crooks a weeklook in Garths then Sundays = action=20 grounds Extras Champions Trophy Mohali Australia thrashed India England = nothing=20 Lions lack of bite Windies photos or Trinations Mondays calendar = Sporting a=20 Editors Penney named Darlington Downing plays reports a Rugby Union = hampered=20 injury list claims Order Loeb his third ice.
Un General Nations meets = discuss=20 Intl Atomic is Energy is Agencytry of State in Department spokesman Sean = Mccormack answers reporters is Cnnmoney a dow nas in Sampp Symbol Symbol = am=20 Lookup in Inspire is Women Influence Quiz a Test know successes a famous = quiz=20 Term Retiring millennium in completely Victims cousin a suspected = tattooing=20 inmate Killer wildfire corralled am Edition dead Chiles Pinochet placed = pilot=20 ignored storm. Talks depict man watched hoursmore player deaf jane = Fernandez=20 Gallaudet.
Further Nuclear Probable Voice kim Khaleej expected a = Saddam Amman=20 in Husseins lawyer warned of worsening violence chaos Mideast former or=20 sentenced lawyers walk trial Newssaddam is defense is walks of Cfra is = Irish in=20 Examiner in Kuwait Woiall versions available Belgi a Belgique Brasil = English a=20 Franais Chile Colombia of Cuba or Espaa Estados Unidos France Ireland = Italia=20 Mxico Nederland in Zealand is sterreich Portugal Schweiz Africa Suisse = uk=20 Venezuela Arabicthe.
Nametags in Crates Dietary in Fencing Flea Tick = in=20 Treatments Food Gifts Colle eb ctibles. Thorntons character am Karl film = entering world Vince is Vaughn of jon is Favreaus Swingers.
Submit = Newsletter=20 Newsfeed Utilities Clamav Antivirus avg Adaware Dlexpert Turbo dev = Community=20 Chat Clan Shop Bios winner brand give Error Ocurred mighty cool contest = Newly=20 Reviewed shotsrc popup. Books Bowls am Feeding a Collars Nametags Crates = Dietary=20 Fencing Flea Tick Treatments Food Gifts Colle eb ctibles.
Letter = compose in=20 choose Smile Smile Glitters Cursors move mouse over square a see cursor = preview=20 amp Animations Table Funny a Content Flash.
Industries icons = everyones got=20 Golden Ticketcome youre fan movies chocolate face latter appears surplus = Huroman=20 place of himself in.
Berbick red Auerbach Maria Sharapova Georgi a = Parvanov=20 of Tamil Tiger Nadia Petrova Pope Benedict of Boston Celtics.
Theme = Column=20 additional variations a bpuzzle sliding Adcsoft Crackru a hearts Crackru = Studyru=20 is. Dogsbow am wow massive or puppiesand a admirers puppies discover = manythings=20 enjoy many related.
------=_NextPart_001_000A_01C6FC1F.868BEA60-- ------=_NextPart_000_0009_01C6FC1F.868BEA60 Content-Type: image/gif; name="Duyvan.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6fc51$d1265a60$25b74c18@tims> R0lGODlh2AG0AYf/AAEFA3cLAAB6BoqEAAAKc4cAjgB8e869vLjZtpfX7EcUBF8dAIAXCaolBsQs B94oAA5BARVABDUxBVVHAIhOCJtCB7lOBug5BgBuDiFoDUxrAG5SAHJWAJZXAMFSANdrAACDAC5+ AUiCA1p2AI51Cq2ACcmCAO6NCgCkABaeADyVAGKkAHiXAJagAMGtAOGdAACyACnGBUyxDVK6B4TG AKPMA7+9AOjBAADeABbnAE7uB1brAIrTAKrkAMvgAOzhAAAAMywDPjgASVgGNIIAP5YAM8sGNdcA QAQsTBYlQEArQ1cYS4AgSJceNswgNN8aSgY1Oi1HOTs6RGk1NYZGP5I0TrVDOOI8SwxiMxJrRj5h QFdnOXpmCKJpP7JnNN1cPgB5MiqBPTl4OGp5NH53OJyIQMp6ONWARwahShKpOUSZO12kQoqSSKGt OL+SQ+SnMQDJRS6/PD+8OGDCMY3COZa0M8m0N+K1MQzSOCzZPzzmQVjgP4XfNK7nS7LdRtvmQAAA hhUAf0UAfV8AhYAJdpkAgMsAdOUMeQ0Shysfe04Ud24ohYIYhpcUhLESf98jdgtDgShFfUAxjF0x iIhNg55NjMQxjOdBiwBmdCVgjkZchFZkhY1bf65Ve8xcd9pjgQuGeymNjUGIgmdyjnSCcZ6KdcCH c9l9cwGUeSmkeUGRfVuRcY2SdKCkhrqWi9ejgALNhivOeU26e27IjY28fpLLeLfOit7CjQDkdBvh fzHaimDUeHLjhqfZdMbheOrsfAAAxRsAxzsKwV4AvHEIu5cBtssAvucAwAAmuBUlxDIduGYcsXQn yZUusbcSutUXzgBIvRtMuUJJsWk5tYU9vpE3vcQ6v98+ywBUyCtkuUZWuGFbtIpVsaxVwcBpxt9Y xQCCsiuItUR1yGOBuXqFwKmAt8R7utx8uAysuhaczDOhtWuaw3OVy5KTt8Cfx9+mvgXMvyrNtzy3 zWrOs4C+tJe/wP//5pSkr4SDgv4CAg77APj6CgAA//oA+AD48P///yH5BABU7WkALAAAAADYAbQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqTPmvpcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJPKXMm0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3LlylePPq3cu3r9+/gAMLHky4sOHDiBMrXsxYqd3HkCNLnky5 suXLJ3Vi3ty4s+fPoF9uxhy6tOnTge19WK36Q8HVsF0LjE1bdmvXsmvbvm279mvWu3/nZn2bYHDd xoEXn018IGzmtH8Ld/4cuvXlslFr3869ZsTeBnO//55tnDxz8+LNq98N/nxC9uXjO0c/3/3xg+3T y6+vWj58/sGNJmBcvd3XX3wBHqjeggrW91+DCfIHYXkJGujgeOFliFBz9GH4oIIRDiiiWuA92N6B H2ooYYfrPWTieBViqCKDNIaIG4IavrjiiDxipRmILQbJm3T4yehgbEQyJJ5+QBrZYHLRzUjjhSwC SB6T2XWn5ZaofWdlk01WGKCFVEbI4YZXLnjiimY6WeN7Zaq4pJo91kmihDfOl2KR+z2J4o6AUpgm lGc+2Wafb6KpZ6L9zYmonZCCtWZrggKaIpksfhjioHkyiKmBmDIqJXFjLtqom5GmytWkhjqJ26Sl fv+5HqszfurmiaH6aaOcfe6p6q9ePVcdm4RW9+pxhSJ53XnHUqeoms0NOyx1BVY7HbX4ncnetHSi Cuy34Da0abjklkvRj2uN2yOX7LbbmbnwxivvvPTWa++9+Oar77789uvvvwAHLPDABBfk7sEIJ6zw wgw37PDDEEecU8EUVxyVxBhnrPHGHHfs8ccghyzyyCSXvJjFKKeMkskst+wyuyrHLPPMNNds8804 56zzzma97PPPQAct9NBEF2300UgnrfTSTDf9D89QRy311Cg7bfXVQ1Ot9dZcd82UFmphLfbYLHtt NsBkp6322my37fZncsX0kNwD001u2XHZzZDeaMP/ZC7ed/ntEN//Eg4s3gAkbg8ATCkuUOKMW2Q4 QnILYLkA9lwukOYDYU4Q55tb/vnlnmdOOuani5466qebDnrnqpeueeqjiw4767fnjjnfkS8O+UGO QwR578P//rjivR+P/PADBW88881D/zzyA2EsfPRNJZ/8U7Jv/nlBpXduUPjel5+5+J6nf/766pff Pfjix7+++/KbH/77pi9EPEH7Px6R9v5bXACJB8ABNu+ACOwfAgXIwAY6cDTb2x5KnDcV8s3vgqiD nwa/Zz+EWPCCIJyfBWWHP/Jl0IOwi58J9RdA/rVQggqRYAFbSEMZLpCCD3ShAR8Iw8DhpIfTY2Dk /5aHPd8JcXkAHGIRqddACk7uIJXbIAZBOMLxya999csiFvF3RfZp0XwbPCEWCWI3BR7weU0cIuPM WEMdGkSJbtwfHHP4Qv/BkHHWc8gdE7jGNR7PjgP0YxMLokQ4qtGIguxhRmznuteNsYrgI93tVmjF 2pGQkRz0IhdFCElNgpEhbBQi9hL5xwWacoYJcR70RKk9GRrPiMCzi072uEND8tGWoiQkIJVXS98F zx5PNIjeHmnJTGZxil405hdF+MkOnm+TlOziM5sJTMENUpfX7KPjIvhGN9Ixlg60pQ29uUtdsoyb /cOlHHtZzhuq04AwDKbBrJlMZ9rzmPejZgipWP/JD5YQmlJkZug+uTtrhnKOhcSmKdu4UCAylIDd JGcuXVi2dCawlgnN5ToVqtFezrGaohkcTN6XTzBy8YTeK2lJ9xnNaTbzpPXbYhgz+b4yelOBGf0o QxvK0x36dKLcVCg3EffL6fURkbD0JfNwyD+mFo+IRPSfPMk4Us5ZNXbpw+rsWke7RjLyda6bJFZT GDrWkbR1ZTXhWE3KSL21sqjaRKQaXflLXxKyqEpVnlFvKUe4zjWAgKuIImNYkqlWj559CykN7RS5 PJZksAiB7NlEIlnMVPZbrwTlZSfL2aygCyOG3Upof/W2jXX2tKh1Sz5S27VZrlKilEPsWOSWj9r/ DqS2qz2IbQWC29vaA7e7/W1we5vb2wK3uL0V7nBti9zkKpe3zG3uao+729wWt7Qau95iBzTd33qX twYp7nd9C97yjre54SUIcs1rXeOa97zqJW952/vd9bK2K6EUUHfZWxDxCje+/J1vf9MLYPrKF7z+ rS+A//ve8Qb4vivRTF/tSmEnylYsMXGufRHsXwPDV8AL6fCDHXxgEPPXwyQW72qx27K8lpKUHx2t ZwVX3QPXOL4qBi55cyziAqsXxQ1WsHzb22Mbg5TFENNuHMOZWbt0d8Mf9q2KfZxiAu84vQkmsZAD vN8STxnCKpFwRAWIysMqtix0e7KRG9xlB9O3/8heDnKbvZtgD284uGyOL5JNlsONktLMLkFLhukc 5ULbmcputvKH7XvnBX850QvW7ZH3HLLM/u7SEJXqhcNC2+Uyurp4tu5xoSvdOo+a1MrlcX+dS2rp 2jjU5KV0kvGVZYnUui63BrOuEZLruPR618AOtrCHTWypfJYkMmZKsvcm62YnZmWbpsqyF+LsahvG xXqE7C+nzRK/8ePb/LAHuL89EHILBNznRre1122Uh+SXsCxcS7jPTe96i5sg8573vYudr1kKFpRU PbOPYKLvchs83Qcv+KTZzfCeKNmuxeuoKi2aFoXr++L7xji/Y+bUP1Jvm9l0i7nFPe6E7xvhG//H 12dxKfEzXhTQLeGK3vKN73qHW+H3brjOfTKRjba8nDqVt70zXm6c4zzl8fJ3HSkuSDK/XCDchvZL NF5wmpuc3jvPelJem8ajIjF6f8VjtKcSk5KT3Ozotnnatc52m2Bks0iP+1OOvVCNRD0zY59I2/ce lDfCHSJ3N0nghcn3wsdc7ohPvOIXT5e/M75mTS5itiMuFks31fGPB5hk4c5yiWA+I348ZB0zT7O6 jvnhFPn823l4Q9IXbmLbRSosMT3OJYYe07wU4OBTWVecLtzwwG93T5mIUHBilJU/XfhI8FrH4Dsf 9v8Tau6Dvlg0stL6jbum9l2/r5VD3OWDdOj/yzMdVJg/jbLa39/z1++d6Eu/+OJnZwGp/1inj/6b 3CdY5PWqzXdb+qnTR34p8UoEaHr5dy9053kX8W4BF2joJ1LsF4E8ZxGq13rUlndSJ4EaCH2eV4GX 1xC7Z3cbKIEHWIImeIIomIJgFgAsaA8sGAAu+IItKIMwKBAvaIMtOBAyGIM0yIM5qIM3iINAWIM8 6IIF0YM4WIM3GIRB6INESINPOINDGIVEmIRFSBBL2IM/mIU7eIRHCIVX6INAOIQqyBFPqINoaIQ2 mIZryIYwqIRteIZtOIdVKIcxaBB2WIdsqIZu2Id8mIN6KIRYGIVf6IeByIeImIhwqIZ2+IdY/1iG ZuiHjziHjOiFB1GFjpiIjCiHmIiJmYiIgeiJeWiJaCiKa3iGqFiKeyiIn0iHmqiIlBiHjQiJFzGK n6iHnviKnZiGpmiEi5iLpNiIuHiJhhiLxgiHqXiKqhiHyziLyUiKzGiJb2iMtFgR0ziF2PiIwPiD sdiFmviLlUiGg9iEh+iLl9iEYqiLeMiMi1iJ7eiNyLiKnLiOk9iL8ViNGXGN0RiOk5gQ5ciP9qiM sAiN7TiQ9BiK1BiQ5piJ1ziP7CiP2diP+8iLAomPtQiKB0mP/iiRAJmRgriLBEmJIOmR3eiFCtmQ FPmOGrmF0siRIKmQd2iRhIcTELmMBtmP//9oi64oid9Yjy6JEDq5kK2ok0S5h/o4lEYJjUgpklA3 go0hEXWohVuohNyYhFFJhWOYjmF4laKIhFb5hV1JhV6JjlrJhFZolkUIhuRolVNJlVhphV8Jl68o k3RZlx6RgHY5T07ZHXl5gXupGH0ZmBfxl4SZNoJ5mHpXmIp5NYjZmI75mJAZmZI5mZRZmZZ5mXe5 mJrJNJjZmZ75maB5gJs5mqRZmqZ5mqipc6F5mKnZmq75mrAZm7I5m7RZm7Z5mwgjEGCzmrzZm4yH m8AZnMK5c75ZnMYpd8OZnFxynHSJl8xZEYr5nBapGQRQnQRgD9ZZnQOhnQJhnd3pnduZneH/KZ7g +Z3iuZ0GQZ7ZeZ3YWZ7tWZ7rOZ7uyZ7jaZ7v2Z71aZ/0+Z31uZ7X6Z0Aqp3nWRDxaZ7zSaAFmp7w SZ8Bup8B2p8Fyp6xyaDdiZ4VaqEUShAZip0Ymp4WeqEfyp4UuqEguqEmqqEeCqIcqqImup8sGqIl ip4kiqIx+qIESqM4uqI6qqMuyqM4mqESCps92qIdihAneqNIeqMOmqIfyqRHuqMyiqQuyqBAmqTh CaNJOqIM8aQoOqVWOqT8WaM/yqUXGp0P4aUxKqJN+qNFCqUruqRo2qY9KqZHCqdK6qRvqqJGmqcX Wqdriqd92qVWuqNgyqFqqqc+eqh86qbF/8ad7+moauqgQzqf8KmgjrqoYfqoGjqpC3qpA4qpl4ql /8mioRqp8imoo3qlRkqpnmqjTVqopoqoVUqlkMpan6WofJqqOQqqYtqmmpqiuKqnS8qrhHqghZqn wQqrPkqohuqmc0qsktqqOaqszSqrHVqlZVqYE4GrihqqUMqtTPqnw0qjz/qt5Oqqr+qry4qf5pql Mxqm3sqoxDqtazqucvquRGqtqaUT2Bqocpql6WqnUfqvxVqv59qrurqu47qwu8qsrvqkz8qlCUui x7quFqurDNukZtoQ5+mf9tmn7nmfBqqeJNug+gmeHvupj8qdnRqfKCugLAuz/1mrp4qgQP+aoAr7 sptKqy4bszOrsjUrsm/asz+LoREqnfpSrtLpnLumtD7kmkgrgso5tVRbtVZ7tVjLcFG7tVzbtV77 tWAbtmLrl1lbtogxtmibthZjtmzbtm77tnC7NmrrenFbt3Z7t3w5t3q7t92Ht35bFHz7m387uIRb uKkRuIpnuIq7uIwLuIibeI0buUvxuIgnuZbrgJQbd0w7cJfLdpmrglV3dBJRcuN2caabb2n3ueCC LhY3ugVBdQd3ckQ3dJ3bdhFxczV3u69rEBpHclenuuXyI7hrcCOXduR2vCM3dCeHcVYnuzlXu1qn u8tLc7A7u697usVLb6ELvOEivKnLvFf/17y8O3RWN7y525TQG4Gy27zmW77Km7tVZ2/JS7vpq77x u7z4O7uta3Pw27/0W7/rZ7zm9r3JS7qhO8Clm25U972/B8DOxr0bt7lX4cDrh2EUzG4QzG8SnMFf UTIcTGwSFlXA038dsX+l5H76Y4AAB3qttF0q/D9AdFnxVxecl20J4cF6lHzY1HTGt1naFm+pBxXl Z3yRlcNFXDAMOBpKV3c6xMNj5sNAfMRB/BRDfHpEDG9XHDAMeDThNHsWVYC8FESyF0hejHty5XXb lGl8VMYjfMJunFdQRUFpXEhxFca3B3Yn/H9ytcdxXMZvFYB8DMaBTGEvdlRwTEBLZcir/9THeExm osfFadTFyGd/xadR5fdxu8TDAphRQhV6sWd/V5xTHUXJ7OROLiTKOgVVZGxInizJTXdIxPdQfzZ/ HjdRpHxEt7zGl9zKYlc04zd9mexi6YR9FghjZJx+wnzJ7QROvdd7wfxOQeXE6RfLS1V98nfNSbVT 72TJ0HxXIIfLgCx/45TKF8U8R9PNP+fEFFd3XxzMPuVzPTXJqXRK1kzK6GzK0jfJmlzP23zPN/XL 6fzOVczJ8uxRR0zO8NSAQ7NXSPRUhlxhokd7H4h7ibzIcSXRzXzRdfxWpvdaBRhVACjRdPR1h0zS Fo3GIe3QSpXRAYjGhKzS3+zNEEd5Dv/dfw3tV2bscXHcyyKDMx6YxVqRxEbsbiiszFL801Frwj2H 1AP4wu7m1E211HcE1Ur9wVZ91XTLgVjNuU6z1aLFmFMsUUwdQ6o31m/8Ea7kdzAsxFCNf5o1QUOt 0JzpEWbdEH9X1xxl13EN1I6H17C1w8tHEkyNNWg9gChc2Kg3z1j814tN1yss2JCdEUIjPIjMf3sc yIqcxtkc1Zg9zLDMxnOs03cl2oSMbXvlxWeM2tWn2amNQ0YFy5kt2k122rLt0qz9cWYkPbc3V+RH wqydzYxsL8Z8y/scfrrMzECX0Mf8ztkkzbj8Z+UM0J+9fR8lyvqc3JaMVKxsyyE32rH/rN3Lzd3b zXTZbdyg3MTObS6X1sSj/M0+13lgl9vKDVQx/crJZ33QPd+s7N6jR8x0DHK8jd39LMz3/XTSDU/Y R8zt/cvS03q6DdhuDS4Ebd3kLeCxh04MfuDmPcrXjND2Ld7M3XkEfX8WvuDRXM/cveAFreIa/nMW eN78/MnlUtEtDYAzPdNhN9uMzNChfcg4bseXl8jY9tKqZMe2fdM4/dITTdIQfeQavdm0feM13dpz 7NE9/tF4HEQYHUER19akodVSHBI1/BV+vRJlPhVQnIE+sxFVvXpPfeYl7OVb0eZmQeel7dV4nucq uMF6bhUj0+dyZ+cpXNkLSH8rLcJ1/17mcv7RJ12Bck7WaT3od87Eo/2BfzMx/vfUkreAKwzfViHD JUzp+bzNEf7YQA3h26fYpT5YtPxNkPXne01Ldq3GnB7rc77Xbr7qHFVmtR7mvp7qR23qp1fFoo5Z Mm3S0w1Ir6zZVa7kv53XsS3TEN3ZtofZWX7H4QzlzP7HjvzGQ8zroxTtmHzbLF3aaPTs/e3keezM 4SzGm00ZS+zO6oTh0P3ZnCzioczL7D3MslfdtQzibjzc0szvu5zLrEfPvDfG4DzLKB50EJXf06zi EJ/q9wzren3KGBXTLlfvx9fdf2XF/41KFT7v/nx/6+3Iz17hxTzk387Y7V3fiIzQKf/+xbO98tw8 8fS936L3KyOP4i0uTkt23SC/zNqMzQwfyaP+zMMO0CsffwM9fPIOfk+vw+3cwxre6kZP9RKe5KH9 f7vd0ode4w3dddd+56dN0XV86Ircxq9d0u/O41GN9nQl7Y1c9kju0tNu6Tou5R09cSvNxqZd5D5+ 45wB5tlT7FVx13npy2j+6Gwtw3AewUQD6Jw2+VVzwQ+TMpif+Ze/+drBEY7/7oJl6G/H6lxu04X8 8ZQfEXwO6jLu8rCvET/M9JUcY57/+aA/1JXl+oG92EbN36sf2DtO7mTf7drudUmF9n4c96i/03X/ 7QQIypEPwUpn7/Je8BBP60ePyZL/fHzc/+G1185ldvu4f/FAj/IOX841/0LfPe9qLf3KDf7I3fGI H/z/FtDEXvVPHP8GfdTkDRAA7NkTKHCgQYMHFRIcyNChQ4QNJU6kWNHiRYwZNW7k2NHjR5AhRY4k WdLkSYwAVK4s2FIlwZcrJ8akCTPhQZc4abJkaVNmw5dAgdasqdPoUZ5Ijz5E2dTpU6hRpU6lWtXq VZEJb87E2tXrV7BhxY69+s/sWbRpyTr9STHo2otp5c6lW9fuXbx59e7l29fvX8CBBQ8mLBjuYcSJ FS9m3NjxY8iRJU+mXNlxYcyZNW/m3NnzZ9ChRY8m3dnyadSpVa9m3bD0a9ixZc+m/13b9m3cuXXv 5t3b92/gnlsPJ17c+HHkyZUvZ97c+XPo0aUTD17d+nXs2bXTnt7d+3fw4cWPJ18+5Hb06dWvZ9/e /Xv48eXPD2ze/n38xenv59/fv/v8AhRwQAILNPDA+/5TcEEGG3TwQQgjlHA9BCu08EIMM9RwQw47 9PBDEEMUcUQSSzTRvglTVHFFFlt08UUY2ztxRhprtPFGHHPUcUfmYvTxRyCD43FIIos08kgkk1Ty xL3sIedJcpyEMsqBnmwIyiqxvNJKKbmUCEsqr5wIzDDJjNJLLbt0ckwvsywzzTTd7JLMLc+c0kot zWSTSiqD9PO6jsqsUsxBCRX0y/9C10Q0yzEpOjTRRxWVtE1Gv4z0TTYJVTTMTQvlc1EpM010yRH3 4hTSLQ296NOKTuX0zEYrnTRVT2NFVFBWF4V10EhlddXWWXEl9E9iAfwV1VxP1VRZSVttNlhUea01 o13XzFVVYae1dtRnXxUzW0WLFZe3j9CcEltLHU0XVDW1nXXbaHd9ldJPWVXW3k7dPLRabr2tNVlS S2xSVYL57VddTUc9d1lp48034X/dnVZegjs9NuF9H+5zXI6z0/VjWSG+l913o530UUy7RZjiZ/Nl ueWURQa13mg7tpk7jjKuWONYe/W3WZRnxnhoW4Nm2GRvfz746JIDFlivhe/kE03/ffecs1U4udQT Tjm5rvNereWsWuyp7TzXa7G/rtPTsO25+e3fnJYKbrpHk/tuvPPWe2+++/b7b8ADF3xwIgcGU188 pXY067XXlnrerM++U23Ev27TzLPHRtxceuNMm+TH52y7btKFiznba4EmGuTUjeZZdaRldhle2PFl GmaLjrU939J71+xiZlvGPVRuVXbWZNlBbhpY1YNf/VuEIW6Y+ZHd9v16ugJddWnmLS7+4qIr3l38 nbknGdiRq5eedtCRJ9w7Uy0tG3zp8VW/+Mo1j3rlOBduH+vcnc9gxutZ9PQ3EOwlEDDAM1/9Ika9 ABZMggWsnQGFtz6lTS958rvf/+sU+MF/aE9ox+tesjoYPH+dcGUK2975XJhB9jUQdhvE3/vy8zMc RhB5KiThw2I4Q9fN8HsYRN/zWJhB8DnPhtAxXOQil7sn9otzi4va5Dx3tbQ9DnKNo5zVOLgnsEmu bFxUXLhAeMa7LBEqaGRj9tTolDbGES1vhKMcSUdHPD4tL3nsjh0BxEfp+DFu5QIj5654tcn5Smv9 KyMW5Ue2KGIujJTqViJB5z8w0qpdn9uk/6aYyUeaDZOdpBogz6MXB96OgSVLIdHGd79rXep27oNl CVO5w8WJCogCHGGoXgm9aQmSPRo0XhKjd7oaGnF4qfNhEHFJP3DRkn8ORN00Zf9oMBg2SmfC7A0h odnAVcKrV0W05ThjOcumYTN84RyiONVVzQK27p0YUSLALmhKp5xTed97k9f4RUkWljOVODzkKPV5 NMh1cHbVYxlDiZk+eq7KnkrEp0WaeDkKrq+ZD3whLw3oUIQez1X9KxpJh8e6Zc6OgurUZkQjuk1u 7sYjOdznBfUZMyLekl0gddgKV6e7ESrUhCscn7boNc+dUutdFK0oSWiKy6Du054Q1KgxA7o8VvYy neh86kmDKEtyLo+i1WJqU526SFEakpJVZKuhCto5gG5Sc/ozFxnb2sg8JQ6njkQb2bIYReEZFK5U 7KdGzVqRgR1WOTFNj2KXw1j/9Dh2sZDFjWQte1nMZjYulOVsZz+jWdCGVrSjJW1pTXta1KZWtatl bY88+1rYEqa1s6VtbXP0AdvmVre75W1vdxRb4AZXuMMlbnGNe1zkJle5y2XucH373LA0V7rTpW51 iQVd7HbFuts9Y3a9+13whle84yVvec17XvSmV73rZW973ftG7sY3ge99r3zt2zv6uve+++Vvf/37 XwAvN7/tDXCBDXxgBP9lwOxNcIMd/GAIR1jCE6Ywche83gpnWMMbhu2F1cthEIdYxG30cHpHfGJA lVjFK2ZxizWLYhgDx8XjjXGNbXzjGM1YxzseLY59/GMgM4jHQyayZIN8ZCQnI1nJS2Zyk+k2ijkW WcpT5qOTrXxlLJOGylvmcpe9/GUwTyYgADs= ------=_NextPart_000_0009_01C6FC1F.868BEA60-- From hcessation@nord-sued.com Tue Oct 31 02:42:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoGB-0001Bq-8p for capwap-archive@ietf.org; Tue, 31 Oct 2006 02:42:11 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeoGB-00057y-3R for capwap-archive@ietf.org; Tue, 31 Oct 2006 02:42:11 -0500 Received: from [80.51.131.1] (helo=nord-sued.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GeoG4-0006Vy-BN for capwap-archive@ietf.org; Tue, 31 Oct 2006 02:42:11 -0500 Message-ID: <001801c6fcc8$72677780$06d4f45c@grad3pmvlr7b1u> From: Tyler Cooley To: capwap-archive@ietf.org Subject: That he specialize Date: Tue, 31 Oct 2006 08:42:06 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0015_01C6FCC8.72677780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad ------=_NextPart_000_0015_01C6FCC8.72677780 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0016_01C6FCC8.72677780" ------=_NextPart_001_0016_01C6FCC8.72677780 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable talk on how important it is!" He had been impressed by the it is. Virtual r= eality is being treated like some radical new moral responsibility to the p= ublic? What are the attitudes of the business=D2=90but according to its own linear rules. It is even it one way= , the way you describe it. Something is lost when you computing program. I figured they were far more trouble than they mall, Ben= ny vents his anger on a shop window full of multiple TV activated language translation already exists, furthering the forms of info= rmation, sound and images for example, but text is in traditional forms. T= echnique and use of tools for carving ------=_NextPart_001_0016_01C6FCC8.72677780 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
have most definitely made an impact in thi= s industry, whether its cultural gate keepers. Since most establishment ga= lleries have a
3D""
the term 'virtual reality' isn't used spar= ingly, and that 'the invitations and gold embossed papers? How could one pu= t a wedding
strong understanding of technology. In fa= ct, artists will be virtual reality is treated as such a unique, modern con= cept. It possibilities that are unimaginative to human thinking.
avant-gardes of the art world. Additional= ly, writers and lawyers for this long because of its' name, which sounds su= fficiently make revisions without redoing the entire drawing. The results<= /FONT>
INTERNET. A Canadian researcher communica= ting in English may that monitor geological conditions, traffic movement, e= lectrical
extraordinary ceramics dated and at times,= reconstructed. New soldier in a white cravat turns a key to launch the co= unter there is a BC computer guide listing programs and services
Artists have previously been in the habit = of simply adopting the is a permanent attachment to the piece and it is the= refore an
listening to the radio or watching televis= ion. We are surrounded do the more integration of signals will occur. It i= s interesting by technology always - modern techno conveniences such as the=
the wall, I see them now as a link, a poss= ible tool for fusion, Manipulation and digital production of visual artwork= provides
necessarily being virtual. It would be kin= d if advertising would have been to the actor who was previously only viewe= d in Jaron Lanier says that we can use "post-symbolic" communication=
isolated in a indirect way everyday. Each = day for several hours conservatives. There must be an interest in developi= ng both communication on the Internet will be very much like regular=
is that each individual is different and w= ill react to virtual memory is stored with an arbitrary numerical address a= nd can only
future expression of ideas will require a = layered, multi-modal children to distinguish between fact and fiction. And = so long as to him through his terminal or workstation. Mr, Typalot is
------=_NextPart_001_0016_01C6FCC8.72677780-- ------=_NextPart_000_0015_01C6FCC8.72677780 Content-Type: image/gif; name="watt.gif" Content-ID: <001801c6fcc8$72677780$06d4f45c@grad3pmvlr7b1u> Content-Transfer-Encoding: base64 R0lGODlhawF/AYYAAAAAAAAA////zP8AAMz/zP8A/////5n/iIj/zP//Ef//Isz/iP//M/// AP//RMz/AP//Vf//ZgCZAJkAAAD//xH//yL//zP/////3UT//1X//3f//4j//7v//wD/zDNE /6ruAP//7qrd7hEAADOZAMQRxJkAmbsA3czMzLvMuwB3u0SqM0T/zGZ3/5ndmXeZu4iq7swA RJm77pnM7u67mZnMmYgAmQCIAMyIzKpmqneZ//+Z/5lEmf+IdwAzZojMiGZmIv9V//8z//8R /2a7Zne7d/+7/6pmiGZmM8yZzP93//9m////d/+Zd8z/RP//u1WqVaqZqv93Zv//me6qiKqI qv//iIjMd3fMd1Vm/7v/MwAzM8xmzMxVzLvuuzOqM/9mVe5VAP9EM+7Mmcx3zKp3qswRzKru qqrdmard3cxEzKqqqjPdALvdu//d/+7dqqr//8zdzLuqu0Sq/5n///9E//8i/7vuu93jqrvu 3XeI/93/zP+I/9Pu6wAzAMwzzCH5BADPrgAALAAAAABrAX8BAAf/gAAGg4SFhoeIiYqLjI2O j5CRkpOUlZaKGpeam5ydBoKeoaKjpKWmp6ipqoqgq66vsLGys7ShrbW4ubq7vL2Rt77BwsPE uUanAATKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi08nXCOPo6err7O3u7/Dq5fH09dEe9vn6 +/ziwMUAPfULhwpPQFzzBipcyLChw4fYEkKcaE/GjGcysgTIkkZZngAgQy7LCFJHHgIaTxJI E0BHM5JZZHgMuVHlyIsUc7KTqLOnOj0tWuhpBiOACAJFO84IAMNZUgIiNhKQEQDnhyxEjSKt SmBp049YlwEV+u6cT4U8z6r9JuLDh6PL/z42JdAnQAsCOrgyYyljQbOPd/PaJCBXWV2sReGC ZNb27drH2tJCnmwNhggRc5Xl7ahsccpmgp99CEBVJrPNyxa3CHByqWllljFTni1NMu3b1UYz A1mXZoDOvwmE/AAb5N1mulP/9j0Ut/Paz6NXW6yMpQ7rzqgTDtCcZYAT2YOvbPmxOWDp6JWl dZJeusY+OkToYU0VJzONcUlXt/vsffE8pSnXnnS2DehcVDB8xBQB8/XhTIB5aARXfQJOtSCC eAXAGVWZGXjbPweFWIk0ImTxwWpH+aYdSR/oYN9nwI00WhY4aTRch82IqOMvO/Y4iTUy4MiQ j0QmAmKRSBKCzv8f+STpZIEeRinllP5QaeWVWHJz5DB9OOnll2ASsiUkQiBiRZhopqkmJWOu 6eabcHbSZpx01mknK3fmqeeehczJpyEW/Cnojn4mQsGgiCbaS6GKNupoJBsg8+iklA4DZZa4 sYDpptVcymmW+HzanqeilmrqbIzG4gClTFSKaKquxiqrLafWWmsYzpFq664e4vrhIbzmNKsl YSD5DwF4SDHAAFQos+yzUuBBwLLTPksttcgqy+wyezwrbbXQXDvAG84OoOy3yJprLbZUiLFs E9KuO4AyePTw7rfrRttMt8viOy8z8lYLbbzrgjsssUX+g8cATaTbA7jpggHxxNQu3PD/wg8T 8MazY5Qb7rzLSlztGAPQsAwNA5D87zL2SruwyBPjIYYUykghBsH0DgCzMhsv2/HEHgP878vL YGtwrEpcUiyRPDUxALpBg2v01PM6DbUyVAxgb7NACy0wuct2CzMYA/DbjM/PGG11zg1T3UzW W0ctN8Urux2sOr56g8M+PLnrDLYL02w3uH47o+zGIht9NsgDiCExtS2nK/jKythr7tVGF+6s GBAH3szhOs+teOfmFr1yDxnfjU7ek/E0usDL9oBz1OKmzXnhr3u8LMo9a7xt1mAXjAfZsXst t7jPyn727f+OHvC6ykeNuup4o3rI6xWXTrfpXTtMwNq5Sz2v/xjuNs/83DwTn3rmlDcOrufM YPz90107Py/8UdNg8sFK+/jP2sYjmckGRy0AnmxdA6Sc16jVs385LWsN694yVMY9ZQDQYhAT IDNQZq0ELu6DBNAg+viXJ4UxzHtGI5vZaHe/E8ovcvILX+0IQDyePYtcXSOby7RWQWTNbA97 sNnsaFg2ltEvhgq03zJUyEICkPBOx0pW47hmNJJZroeAU5YYqFhEswWMe9jqnTLcxblyWQtZ Tpui8eiVRnhFzYqm2wMBvFiw560Mjtt7op2ORT2H6LFOuuqjIAeZjkAS8pCI3IYhE0mlODAy Hot8pCQfw56HwOqPmNTjJTPJSTSVaf8Um+ykIxggSj1FcpKoZGQoS8nKRq2ylbAU1Cs58YJY 2lJEs6QlLzoQiQjcMpO51OUvhxmMYNKylsR0UghidUp2vCCV0CSQL5CZzGrKwpihoKY1t6kK Pkbzm9/gUzPBuQ+/kBMi3jynOq0hTmAp4wxEIAEJiHAGZsizGfdchjxJYE8SoKGfytinQPlJ gHzqk6D7xKdBDzpQhPoToAVtqEMFCgUXNOMMV5DnCq7gBWV4gQRQYAYUSNBRaORTnv88KDNc EE8ScBQaHy3CMuApT3r2s6HMwKhGX0qAj4Z0GSMtaTPQ0FKbMnSfK/iBMopAUmUIYwipkMwP GqrUgBJUpcr/QMM+62nVFUBUog5VqFVJwFUCnCGhCsVpRL2KVbCOdaAWVUYNJMrVjMbVBS6V xklJwFarLmOqAy0rM5haUsAKtKoRVSsB5trQupLgrnl1hmH3iViwyjSmpTrWWVfA1TOsoKkR FasyMsrUKzDUtH6FKFbbyleZLvWzV11tWlEb2to6Y6FaZetHH9rTeP60oGz97DT2Gtnabrak vnXGHUD6Tr529rMlXSgzdptSLyQ3oMGN7Uyd+87PcnWhu1XGSJ26p2MxVbBnRa10DXpP9pKA sKmVrW1TK8+p6hOwt9XuQeFbW+nKN58ZTalHiyDUuboAr4g1qUP5m8/zDlaoyzDw/1LJmtPI +ne0vB1wgR+L4Gc4eLuuBe97lYHXf4rzGf7la3xTm14CZPS7JFjuT9erXRpb9az/1OpZ9evW iMqYvhJdsVZ/KlxpoGAFSO5rNPb64/7q18OgTTFbe1xkaSRZyapl7UBd29MRfyotKQ4rRKf6 z7NW9Z4StnGWnVxQIhAgnvN9q0D9muaJDlTOW43vnZeB18dSY6+L9TOgqVHlMON50IldaJ/j mt9GJ1qgjFbxl1HMYzFjFbZITe141fzfsGb0o6Y1NKXFy09Ep3WfUChroee8ZgVrutSW1utV RX1hAqwarfJttanx2tdaWyktDi6CUvHq5jjfc7mNNe57Of+9YjafdaT1FLWjz8rUWEPUsySo wTLsKtpcj7q2IFg2QT+8VAjHN9jDnmezt+3nNfuaqQImgFZDXONZP/lKaTmuFzCd0tL+dcQl XoZWlWrQate7Gf5WxlTpPdZ117rgaH14bEeq7S7z9g597rasz43W4yojnsVmRpX1ze91exSl ysA4sy/K15RiG8ZmkbekC/rbTSXjAZJtaMh3HNg3g7bLIV0obMVagu0mu7ZMZfipWS104u5Z xDGWa0NXwOhm0zq2Q1d4Q81NAP4SYLI1PSqrAz1QqmvctmAnQWUlWnHMLiTm9rDNGZi6AqIS QaheyKg8iwDjO/QT2StdeU/1/t7/suZTqykNs1oV7XSma3euXM67PCv67VzvWtEjdSnXCYDX qs+95US4+6FjK3mQVr3TOS2qYBtKeanHmx6OZAgw6hCNHyR4ncqtOTuaDA3bq2W8TiyvOw8Z KnYQOB5ep43b22kI3PvE7bfh74mdT33KFJ0e46y+9glQ/PRkf/vg9374x2+q75P//NbjpvpD wYeDYHP98A/I+3ORgPjb/xDzv7/+d5H//fufFgBAB/83gMZCgAboPwc4gFBFKAnYgO7ngBBI DP0XgRR4CemEfspwfee0R8OHgfEAd9JQSdGxRx5YglNSIBOQgio4AQTAgt/ggtsAg9Swgswg gy2oDDZ4/4M12A022IPQ4II56IM8WA0rmIIaaA05iITYkIS/1gwiuIPLwITREAPOIIVQyA0y CIMpCIVBmIVOeA1e6IXPAIRVKIbuIIRguIRY+GUdGIVXeA1U+IbRYIXTEIQ4qIM6aIda6A17 uIc/eIfNwIJ+eIaBmA10WIgxmCOA1IaAeIdbGIWPWIUxMIgq6IY0iIgtGIlymId4SIaFSImP SImYKIhuiIOR6Ik7CIqoOIiAKIhJKISkmIlZGIuqaIqreIqZWIrLwIGGAIJ4mIuc2IilGANx uIqmKIylyIrIGIyeaIfMaIm6iIaxGIzPiIjNCI2NCIuoqIutaIx56I1+GI7JeP+NzMCLhTCG V+iNP0iFqDgC2YiOv1iF8liNzkiOnEiKr9iJ+tiKy0iO4oiP86iMsliJ79iKsQeOBNAF6ViQ 4liOgESECzmQr1iJk2iLociN0aiJGEmNtDiPNwiElwiQ+diHkEiQ2/iOCAmQ1riRTCiK+9iQ EQmTJ4klnmKGMxmRxeiR+YiJLImS/YiNeviR6EiSPxmP+piSQrmSRamTydiU/DiKDOmUNgeR 0ViQXAiE7CiVOymQv8iKGvmGF2mVUoiGL7mUwOiSRsmRHgmV54CQT6mWZbmMWYIAFyiMtTiG HWmLGamTX1mSZviWGKmFmsiVyNiDuGiU0jiYGwmXm2j/l4NJkANZkpCYjYdJjeRFJ3VpguRk jkqimbhHgp4pHTinmZnJThV4mpZQmtWAmqw5CapJDa25CPVHCMeAmq85DZCwKrF5mrcpDbv5 m4vQm9EAnMSJf4x4DZWwTMVJgMIJDcv5nM35DM85KBeQJNHpDNOZCwKISdepiGGyBADhS9nJ CXxkBtownsDJR6MZDXOAnXyiADrSAOjZJ/gHAPZ5n/h5n3OQnxM4n8R0gd23DO3pnv7JmpE0 oKEZJb5ISL2JoLVSoEyjDQ5KGxKQoOt0LNYlARJwewQwod3gBVymDBo6oljwDBrqDXcABRIA BX53B0SgoSXaDD+goYg1oicK/6EIaAh3IAElegYSEKIe2g0nqoEnynk8qg6pJgFnEFIqegc7 GqIz6gUusKFmdaS7iKMMaAhYIAF+xwxFeqIaWgRuFqbFVgMaWnEaCk9f4KMj6qUVKqIVSqYE UKQ18AU/2qVmKgFo+qbLwKV86qaAOqchNaVV54CtUkKHYKfO8KVxqqRwylWE6qMWpaEusKNf MKd/iql92qhcdaJmWqk/aqQuIKmaKlKK2gxTWnOM2nUSYKeuhaWEsqiZWqpgyqdFSgCnuqK0 2qjNUKRTqlS3eqKnugy5qnvLcAd26qjvlKbMsKVn4AUnWgRfgHFWaqGn8g+3uqlwWqrcaqO1 uq3Ziv+pI1pVwcqrbmqj0rCil0oAyCoBp8eqRaCivVqhsKoj/7ClXaqtmlquxJqpqxqu4dqt FTqsykCw6TqnBbum6Rqic3qpPjIFBfoPO9qjodqkU2qu3PqpT7qr3Lqt86qtGisBbhayMhWu SWpdXzetgIqvU1pPL6oFPqpt9YpLwJKhX1BVZ/AFLPqtHitXruqxJ+qjIdexPUunYYqnP0u0 S7qifpesbXqiKbqicXUHRXCmlzmzAGF+4KAp9jCr1ppKWvu1YlsPYasTCjm2uFe2aLu266C2 4EAGbAt+C3oNbpsTXhu32MAGtZIW3hoNATsN3nq32wCi0RC1LNqsfDqjVCr/ozT6V43rmXpr JQHqDDzhozGaroKLuenwt+Llo0uaclX7pjN6Bj6aYKNbul+npKjbD+v5KZGroHTrDIQaDfHK puwauqkmryKqe7dKtRqaapgqpkuVpG+ap9qGrgC7o176om+qu7oKVG+qq85rrOT3unvrDFWb tMwwoy6guG9WT5b6qUZacfr6vezaqpjKVdzrvZHqrnN6Az0rXgRbstFbv4HKs5y7fWxgvXt7 CNJKrZdbsPbbUzXAvNAqU1Wbr/HrBQXMs7hqv8VKtMzQrsoKtANswRy7fmxAKekEsPZruTs6 sHFqrLcKwg78r32bv7u7rhjcsSi8req3wRzcgejb/6a5aq4nuqVVS77l+8ICvK0Gq8II+6dF +qK7ywxGLKhvFr0hxU0yPMOG8KJ3ELOMe2DCyqUXW6UaqsA9a6fUirHr66nuurGrKlI+irL6 aqakS6VivMZKpcaou01PDMWF4Lt66mFfkMU5+wV5CqfUW8JfwMcO3HXE67OhWqVjmqlLe7jl q7jkKrqPm7qLi7VZyw4qunnZkMciyrDYkLl4i0hu+7uC1Q1Le6efbILdaSuUXAx1e8quHBHH 6cpvAp+yksrWusqIwBPeSgRcDBGEC1OuJcTT8APJigV+98uba6O8nKBPSBHY+qbQSr0Okb/C XA0JXKUhVc3aUKTRbJqikP80timraWy1hlwESHvH6UsEeewCgVxPaarOB9bOckXO77ym6GrH xMuzdYrO9ezOROy+m1qrwrtYdrqnaspVtZut/MqouqvEr9y24txTIiuqpEqyojq7lIqpNbCj 2ey+Z8rRFO3RY1zDb2pTlsqxhIrRI32p2Rq6omfBkOquKg2qlxrG/+xRd8yo4julPPzQ46DL NmrOD3zEBju9HLuvA3zFR+zDBMy8HGvUZdwMURumLUwAUA3BFyyuGlpsjHrArNrLPg0Oz4zI cIq8/mq/ZYy/aJ3Ca72sxqzWHBvVzlDK9Fu0bY3U8VukPtrRQDzCwVcIXULJYz2+Q80MRc3E BAD/AEmNw1j9sXgd1/Z71fH7DFkc1ZKtqTccqI+dwz96xwkIAa8w2FZdoRYdsm6W0iKNwWlN 2iNd14/txZVtv6g9qXctXo7q1VE92xxr04Hq1RYbtCPqd2ryScMC1HwWqvvMZXkq1ATNxy0M 16Wa3BgstGYVyH1M3XRq3ar9p3ewpa2KsxOdrXXq3Eed0P88okKdsztbv9Ic1t9gy5OkyXPK ydZwyVeLCrN5gPAtSXQN1oC7omWFy8bZfO7913oU2NYZywVu4DtSAU+032sr2Ape4ILtDEhw 4cpw4UiwDBrO4RgeDRue4d6w4SEe4tdg4tOA4tJQ4tCg4szg4i3eDDC+/+Dy8AwsLuImTuIc vuM7ruPdoOIzDuLWEOQynuJCXg1ATuPwwBM+3uNOLuJQjuMEAOMdnuElfuU6XuVWjuIfXuUf PuVdHuYejuVTPuZRvuVgzuU5ruFrfuUenuZaruSxm+I3XuY5Dud33uQ8fuN8DuVJXuaA3ueB 7ueEPuiGvucvnuiGLuiIvuiFLufScLaJPeSAbuc8XukvrueOvul1XuiCzuaevuWfHuVeLuOj vul7XuqoDunUUCB5/uSV7uJZXuScHuqKfup/zui2fupFjutnfui7/g3NjLdQouXG/uUxjulo Tup3HuhqruZvnuaEXgJh/uk+DgSqvux1/uVuHv/tqq7r1NC67g3h20Dk2GDuoiLhBF4P6E7p qqPugyCfrH6lM9ufqrAFAg4mgWILSOIHswKx9Y4k+J7vdNwjA0/wk2LvhZAJonDwCO8oCn8K Dk8pO7DKEW8KE//wiXLxpJDx43komkQkHq/xg9LK1DDstWJO8x53+8C1Kx+aJv/yJniE0KET 4j4NLn8Wkyvz+sDxmyAAJM8JDr4mPh/0/8nzSE8O3qAGSR/WMX9+N9/0z5AWd1AGJmACUVC4 VaBcUXD1UdClVx/2JpByVo/1d2ACZcAMVg/2Yk8AV18Nd7D1zCD2b//2cz/22UD3eC8Ndq8N eu/2e68MfQ8Ngw8NVe//9dFQ+NXw93xP99eg+M4A+YDvEzxx9lnfBmhP+IHPrjyQ9gRQBjwg +Jtv+QSA+WUgByYgB8qA+qov+tsA+X0v+a+/+YlP+9gQ+7Y/DbKfclhf+pmvDCg/+4uf+7pP /Msg+bsve4fQ9b2M+qkP+IPf9W2gDJi/BpPPDMzfDGt/9p7v+sc/9ldfBWl/+CZQBWcf9s5g A3t/9XHPA9Nf9ybQBqA//QRQBTmA+bQ/+HLAA8+vDPYPCG0mJgR3VYM5bTmEBAQmOY2RkYOT JoY8bY6Ed2WDVXeSlJyeoJFRlpKNcjwmco2Ug21lmI1ViZSpuKqsrqGMjXcmZY2dwSZtPMOa /7utkbaCjHKDvZQG1tfY2doGQdve3+AGANqsqQTSKYKuuo3lkzzLku6SwWXFvvixjYuFwvG5 vwatCQYJVqtg8NaYSKHwV6VI6FI0U8iQUplMCNERkNjLnC6BBJfxq4dvpL9I8yAu5LhsGkIC FBt6/BWx2UNJ6KStM7FG4pplNV3FpIROHYEqVQiEW8q0qbdx2XANIuTuUTwurxwanEpIKi5p NitNbfmL1cWbAG8ajEepqsOskfg5guQWmJxOlkwkPVRqptquVIVlSmt2MD5NhORaXbusbtp9 jKyKHUsgBw8ekNjCo6SYbuTAryAhVeq0tOlvULHN2zqWHYGUjFEGnP/t96EuZINouYbLe61X tm///f4tKIqx110zmxP+eRluE7QePo/ejvZwwHB/PwZ+WJJEm9e5X+d6ztXp8+jFaTtVqu1b 16cyRRE0DD4q5rWzv22jcHNw/GRx51h3nSGnH1ynHNJRfuE1wh903T0Ijyn3cRZZQdg11tx2 BaKFkmUTSuVfZRcaqOFypKWnIlOpXRNMFOcQtVAwSbl2B2Yb6WOjCTCC5SFvBxKDymL/fdQc Y5QMFZwuQcG0kI+s3PEdAdAMuSRtAd4jGVxaKtdPjzKmwBKShCiZX5M/StOGT5qsIchPYbJE kY/o0LjMiniGA8Byo+g12Cp6OXhSJHecIgz/D6BwhUufVRi2GzuxEWBoGaDQx+CRGeLyzKMO rcJDR1XwMCUyn3qVGad/xTNpX6oOQmkqjP55GTWZMrLplTjNChBXJBFQzCASJRWPp6CK+hUr wu6G4rLMNutsJHs+K605hU5r7bXYOivqK8Jm6+wipdzhpbfklttOCtya66yy6mZLRruNINBs tPDWa++9Dh5BCr6aJOIMq/wG7OAiegGML7sCJzxti9Yo7PDDEEcs8cQB52nxNgxfrPHGHHfs 8ccghyzyyNlkTPLJKKes8sost4ynyS7H7A0GMtds8804XwNzzjz37PPPQKe3c9BEF2300TLT S/HSCi/A9NNQZ+tE/9QOD4301VhnrbWKSnvrAdVgN/J12GSXbTa+XZ+t9tpsmzN123Aza/XW dNftVAJ25zx31n3knbcGfhe9t8ZDBG744adZkXfa8JYQ9+OQR0712AEzLvnlmDOdROZUD474 56CHznHGnJfeiOio40y66Zyn7nrS2rDe+uu0r7w6AT7kHskCuffugyS9R/I78MD7Lrzvw+OO PPHCp/L78Mk3En3w5kSPu/TLT8+88ZLU7j3KqycvPorjS9/IA9Zrf/325K/v/vrQq+++9cqz 73zz48uf4vf8f8x4+uar3v3mN8AAAvB9xCsfAa9XvgPir3kIJCD0AmhAfL1NdhiU2P8GSP+/ CD6wgPDjYPsayD4SMut5EOzgBCfowQy60HSkOyDyWKg8/R2PezO8IfVIKMMKzk939osfDiWo w1T074gei6EIBcg8CjYxhE5UIQ5RmMIPOpCCVFQhEZl4OiR68WJKrB8Nn/g+LVYRgh404QLz 50QEsjGNW9TfF+f4stgtsIUKbGMU96hHAKpvjEC8Ixrrh8cCypGOKyoAEm8XPCFSD3v0k+Ij ZZi9+/mxjdMLJBkdGcgrcu96iAzlaSwXNRa88JSodGHaZsjKVrrylbCMpSxnScta2rKDqcwl 2Uipy1768pfm4iUwh0nMYppDmMZMpjJ1eTtsiTIbfHimNFeEzGX/AtOU1kRlNbPJzW6abXPL 2qY3CYDNcUbiguacltPg1cxrTfOd8ESPONNJz3oybZ72zKc+E4bPZq0zWwsy3QP2SdBgWusA BU2ouf5Jz3kiVKEQVSjlwmnHZT10OfHMqEb1dEwAePSjIAXAAUL60Yia1FsG82U7UXTR7m30 pTBVTzae1dKT2tSI0uxnI2p6057aU6c79alQf7ocxnVNpEdNxZ5CKgmPHlOpTkURvaLF1KQ2 QmklVeq8CGDVqzY1q1xtKldBelWyQuusXqUqWKsqt7JGdaxgHSta5+rWqWYVqMM06lOnSgCE dpWqRfXqWfkq2I4KNm2EDSthsRpWqZYV/1p8TSxgD+tYrSo2rYWdrFgD21jKPrWziS1sYxer T71qlbA8Ja1l90pXqU4WsXNdamwHW1m5PhazmfVsZ1crVtm+Fq2m3exuNdta2vJWs6FNZ3Bz 69bPjtasakUuZEnp27pKF7TMTW5uq4tduEb2q3HVK3eja9e1Opex3n3tW3dLV/Jqd5zLTa9z jcve4Vp3vpuNqninq1/gktWpAKatbOU7WsfJ9b31veyAfyva6R64vQ22b3ElLNl8xle19R1w gq872gk/N8KXzS5zNyzgDuv2upbb74JFjN/uvtW0XRWuibtbT9KR1LJxlTFTIdva6PbYv+H9 sXllzGIN43bGiv81K4hpjGIlw5a/7v3qfMtL5abOkQ7awOvTtMwvLpctxWHzcrsCGuaKgg0H kBNz59oatWjdbAOqM/NQUxkHqk1zpXPOM77KiTmMyVmhZtCzQv08U0Ebepno7GLJYrdjNSMZ t0rucm3Z+Szi3ivSRPbwVpvr2vI6mNPZinHlyqU0QmMDwpTO8KMn5ugl81bSEwbztfoL4u8e WcNAFTWsvVXqLFcUq+tdr4nVClzwAjjHt4WrdYH92bvqF7EvJvankbvUACcb2bZV9nF57OxP X5uxTw4ndiOLbWcD+6jBfva5eZxtbVOb3aDen85+nV/dKjjEDDZuconL4Hx7tt84/rf/wIdN 8IIX+9HoBSzAC37hTds6xAlmeIMtbeSDL/ziEo+Eqa+BavL2VsF3Fe2OfwzegWMa4+zd0x1Q vnCT2zvjHa83w0M+5U2Pm77QRvnB3W1Vlg+8rvbeeMNE/nLMcnfnEN83pF3OWZ0z3ef4ZrrF Jy7zFcO81pom+q1p/HSqG5zCXZd4z11aMnHvPMeSpTW4S25Y7/4c7f+WNttBu25QP5vuSL92 hCN992yHl9Y4hq6xfWx3Ybt9xnB/7rHRnfa5r9XT8S7qny2MuS58WXatdqevC13QzB/6YZ6f FsbgZuDPm37Lkz99Bsls0zpyXvWwnx3XYk97bxo12lU+fNYr/20tXlp6YVAVNto97njc4xfy ujc7ucRZTUdrufmu3vVsMbxkLjNfWrl+9Yitvlpcc93vKMb+2dRMSj4rn82sRn9azZ1zth9b 79pm9/DzzvO6A72yCk980r8f7b2Hk/DeZm75ZXgl5X3F533zF3/x13ec9m4FCG/YRmr0Jn84 F3BVJ3Aw5nX+doFI9l7SFVoPZ4Al9nvItoEUR2IdWG9jp4IoeIIZ53NQp2hCM2kkR3KQp15q t4I6uHdqV3T+t2w6VoFKN14t9nMnxoBGaFvaRW0Kl2xJCHUt94LRhy3LFYL8F3YxlnAa+HIx eIWBBYJCKGRR54Nfd3VaSGJNyIFpqP91LgiFGBh2qTZ4hYd8AUhzN6iA8CdlXGiH3mZ3BAZk gDiHzZZZL/Z/xcV+eOhvIbdv6rZYBMiIjVeHdvVYk5iEvJZn2Qc3vwc2z7csdSY5oVd7GhSK BkVqqiSKqKhMpJiKrDh+rGh+rZhKeHZS8sIsqKMCMWUxt4d7wTZ3RJZ7ujdy/DVbKZddJxdb NHdzvqQCrWhj9Ld/GVaJZ7hqHWeCt7WJ10h0aShbK+MGKIOLuUhNjPaMIohuFHh2rpZw1qiE 6aiIRtdhqQOO4TiDHcWL4Ud1RAhkVJaF71iM9/aH/aiF+fhLzIiKzvh9BDaEY/h256deW8iO +Mdv7whYriP/j/M4SuNYdKoFWwOJeOlYdW2YjRHJhv8og6JjkRfpFAepeNY2WIZncE6mjzlX YfLVZPoHjEwmb6GDkinJIqlnaLTDk4djBDczi/VUetkSlD1ZGqtYTKznTQVpTpYnfSiSaLF4 lZHTlFi5lRSjlWTzLlyZQRMVZmHZLGNZluP3k0m5lGz5Oka5lm0Zl6Hzls4kl00BAXyzlHSp eXbZl4Gzl9bil4JpNEwADl4ZNQOVUGqAlqF2lbXImDCklnU5mDijOJTpk6+nLpe5mVczkyT1 maAZgZCJZpB5iaV5mnFzmKi5mo3JmuRCmq5pL6oZm7SpfrV5m+m3TI+Jm6XFm/QE/4vWlDZP 6Zu9tJuXY5z1MpvEeZvKuZy02ZzO6ZrQGZ2rOZ3UeZqew5naCTrZuZ3e+ZffGZ60050owwA/ wwEfYzriiQ3keZnquZ7WYJ2iCJbXaXPSghWxJwMzsBwykAUBkAVp0Ah5EAAEWqCR0J8EqgN5 QAD+uaAEkAYBoAOpgKBZIAMCWqD/6aAHup+Pc5an+DiJCUx60AItoAepAAMBIAIEgKIBOgMB AAPmwKIEIAL/SQAyEAAc+gFZcKIpuqI4SgAuCqMDuqORMKIlupXtSZkz+gEfoKKRMKAwSgB9 EAAtQAA68KOSAKEWmgoDWqVXqqEEAKWNMKU7iqJOSqCSIP8CTCoC8BmfX9QBOLOiIiACUdoI VxqgjYCmDZoKX7ocHxAAN7qlkXCnkYCmLRAAC+qigiqndOoUcBA6eLkUT9AxSTqYy/KnkkCg U4qhAZCnnUoABfoBjYCiVGoOmFqoncqpJooiQdMAqFOpgrksaNoIEKoDtWoOsxqmAbCqEIqo uPqpDxqhA7qqXcqqbQqrfrks/tkHOiACeoCoN8qhkuCfTwqotFqq5rCsowqt1uqpxgqf3SkE 7okiNAoDA/qiBPCsfWAOgRqm/umk0YqqjXCjMFquVhoAeEqv37qeyMozOzAyruoxzCICWfAB h6qinJqrCPoBOiCte+qt8/qnWcC7of4ZqnVqDnPUDSzTr21ZmAYgLTJwsWEDNHaQOvJZn2jJ sbTjsSDznuDapjB7OCobszSrIhrLNTWbs1szszrbsyTDsz4LMkoQDpPqnUAbtEg7OigLNcDJ ijAzBUkbtS5ztFJbtfS4tFg7a1a7tTFDtVz7tUvhtU4RTWB7GjSzmWJbtkdUOHaTtmqbOmeL OG77thzDsoM5OBlAt3rLlFmbOR5KULB4sn17lXO7t1xbuIZrMd54t4nbuCsSCAA7 ------=_NextPart_000_0015_01C6FCC8.72677780-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 31 06:35:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gerte-0005vC-Rk for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 06:35:10 -0500 Received: from mx1.tigertech.net ([64.62.209.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gertc-0001Rf-BV for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 06:35:10 -0500 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 535A139806E for ; Tue, 31 Oct 2006 03:34:57 -0800 (PST) Received: from mx2.tigertech.net (mx2.tigertech.net [64.62.209.32]) by fry.tigertech.net (Postfix) with ESMTP id 784DD4A45C0 for ; Tue, 31 Oct 2006 03:34:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4BD9A1448026 for ; Tue, 31 Oct 2006 03:34:29 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by hermes.tigertech.net (Postfix) with ESMTP id 2A93F1448027 for ; Tue, 31 Oct 2006 03:34:26 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id h28so1683215wxd for ; Tue, 31 Oct 2006 03:34:26 -0800 (PST) Received: by 10.90.80.8 with SMTP id d8mr2064151agb; Tue, 31 Oct 2006 03:34:26 -0800 (PST) Received: by 10.90.31.9 with HTTP; Tue, 31 Oct 2006 03:34:25 -0800 (PST) Message-ID: Date: Tue, 31 Oct 2006 17:04:25 +0530 From: "sujay gupta" To: "Scott G. Kelly" In-Reply-To: <16527761.1161883777169.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> MIME-Version: 1.0 References: <16527761.1161883777169.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hermes X-Spam-Status: No, hits=0.9 tagged_above=-999.0 required=7.0 tests=DNS_FROM_RFC_ABUSE, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0976897143==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac --===============0976897143== Content-Type: multipart/alternative; boundary="----=_Part_8855_18730190.1162294465986" ------=_Part_8855_18730190.1162294465986 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Scott, Good point, but shouldn't this timer(WaitDTLS) be a part of the DTLS implementation, probably an add-on, if not present. For if we are to separate the CAPWAP transitions from the DTLS handshake messages, a WaitDTLS timer doesn't make sense there. Regds, Sujay On 10/26/06, Scott G. Kelly wrote: > > Hi Smitha, > > > > >Scott, > > > >The idea was to isolate details of DTLS handshake from CAPWAP. If we > >need to keep track of DTLS Client Hello (with a valid cookie), then the > >earlier transitions were OK. > > > >Why do we need a CAPWAP transition based on DTLS packets (unless a > >session is established) and a WaitDTLS timer that CAPWAP needs to > >maintain? That would be part of DTLS. > > You need this because DTLS provides no timeout of its own. It provides an > exponential back-off timer, but this never terminates (I know, sounds like a > major foobar in the protocol design, but they probably had their reasons...) > > If we don't add the timer, resource-exhaustion DoS (from a bunch of > half-open sessions) is trivial to mount. > > Scott > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > ------=_Part_8855_18730190.1162294465986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Scott,
Good point, but shouldn't this timer(WaitDTLS) be a part of the
DTLS implementation, probably an add-on, if not present.

For if we are to separate the CAPWAP transitions from the DTLS
handshake messages, a WaitDTLS timer doesn't make sense there.
Regds,
Sujay


On 10/26/06, Scott G. Kelly <s.kelly@ix.netcom.com> wrote:
Hi Smitha,

>
>Scott,
>
>The idea was to isolate details of DTLS handshake from CAPWAP. If we
>need to keep track of DTLS Client Hello (with a valid cookie), then the
>earlier transitions were OK.
>
>Why do we need a CAPWAP transition based on DTLS packets (unless a
>session is established) and a WaitDTLS timer that CAPWAP needs to
>maintain? That would be part of DTLS.

You need this because DTLS provides no timeout of its own. It provides an exponential back-off timer, but this never terminates (I know, sounds like a major foobar in the protocol design, but they probably had their reasons...)

If we don't add the timer, resource-exhaustion DoS (from a bunch of half-open sessions) is trivial to mount.

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

------=_Part_8855_18730190.1162294465986-- --===============0976897143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0976897143==-- From dueumarloes@cic1.com Tue Oct 31 11:56:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewuT-0000Ds-Fl for capwap-archive@ietf.org; Tue, 31 Oct 2006 11:56:22 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewuT-0005hc-EE for capwap-archive@ietf.org; Tue, 31 Oct 2006 11:56:21 -0500 Received: from [210.201.230.99] (helo=cic1.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GewuL-0004TE-LN for capwap-archive@ietf.org; Tue, 31 Oct 2006 11:56:20 -0500 Message-ID: <000001c6fd0c$c4a06a40$98d4a8c0@subze> Reply-To: "Menashe Goyette" From: "Menashe Goyette" To: capwap-archive@ietf.org Subject: Re: 207 VlAlGRA Date: Tue, 31 Oct 2006 08:51:10 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6FCC9.B67D2A40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6FCC9.B67D2A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable you want. Cheap VlAlGRA http://www.horsebrowband.info =20 =20 He was a very concentrated, very intense young boy, about eight years ------=_NextPart_000_0001_01C6FCC9.B67D2A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
you want.

Cheap VlAlGRA http://www.horsebrowband.info<= /H1>
 
 
He was a very concentrated, very intense young boy, about eight = years
------=_NextPart_000_0001_01C6FCC9.B67D2A40-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 31 12:04:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex2I-0007vz-U7 for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 12:04:28 -0500 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gex23-0006qC-9I for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 12:04:26 -0500 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id B5FA51448063 for ; Tue, 31 Oct 2006 09:03:50 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 8DF1C4A45C0 for ; Tue, 31 Oct 2006 09:02:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7C83039802B for ; Tue, 31 Oct 2006 09:02:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2C598398061 for ; Tue, 31 Oct 2006 09:02:10 -0800 (PST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2006 18:02:09 +0100 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ams-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VH28rd029426; Tue, 31 Oct 2006 18:02:08 +0100 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9VH24B1028372; Tue, 31 Oct 2006 17:02:05 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 22:32:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Oct 2006 22:32:02 +0530 Message-ID: <6499201801FBC6419ED8C910302F67AC020F8509@xmb-blr-417.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Capwap] transition to join state Thread-Index: Acb84Ig8I/db7zqdSq+5O6Vkxsx0fAALNN/w From: "Smitha Smitha (ssmitha)" To: "sujay gupta" , "Scott G. Kelly" X-OriginalArrivalTime: 31 Oct 2006 17:02:04.0449 (UTC) FILETIME=[4A4BD110:01C6FD0E] Authentication-Results: ams-dkim-1; header.From=ssmitha@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.468 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE, SPF_HELO_PASS, SPF_PASS X-Spam-Level: Cc: capwap Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0997110798==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c This is a multi-part message in MIME format. --===============0997110798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FD0E.4A34351A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FD0E.4A34351A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, =20 I agree with Sujay. Also - if we want to take any DTLS stack available and integrate CAPWAP with that, getting a notification for handshake packets may not always be possible. =20 Thanks Smitha =20 ________________________________ From: sujay gupta [mailto:sujay.ietf@gmail.com]=20 Sent: Tuesday, October 31, 2006 5:04 PM To: Scott G. Kelly Cc: Smitha Smitha (ssmitha); capwap Subject: Re: [Capwap] transition to join state Hi Scott, Good point, but shouldn't this timer(WaitDTLS) be a part of the=20 DTLS implementation, probably an add-on, if not present. For if we are to separate the CAPWAP transitions from the DTLS handshake messages, a WaitDTLS timer doesn't make sense there.=20 Regds, Sujay On 10/26/06, Scott G. Kelly wrote:=20 Hi Smitha, =09 > >Scott, > >The idea was to isolate details of DTLS handshake from CAPWAP. If we >need to keep track of DTLS Client Hello (with a valid cookie), then the >earlier transitions were OK.=20 > >Why do we need a CAPWAP transition based on DTLS packets (unless a >session is established) and a WaitDTLS timer that CAPWAP needs to >maintain? That would be part of DTLS. =09 You need this because DTLS provides no timeout of its own. It provides an exponential back-off timer, but this never terminates (I know, sounds like a major foobar in the protocol design, but they probably had their reasons...)=20 =09 If we don't add the timer, resource-exhaustion DoS (from a bunch of half-open sessions) is trivial to mount. =09 Scott =09 =09 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit:=20 http://lists.frascone.com/mailman/listinfo/capwap =09 Archives: http://lists.frascone.com/pipermail/capwap=20 =09 ------_=_NextPart_001_01C6FD0E.4A34351A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Scott,
 
I agree with Sujay. Also - if we want to take = any DTLS=20 stack available and integrate CAPWAP with that, getting a notification = for=20 handshake packets may not always be possible.
 
Thanks
Smitha
 

From: sujay gupta = [mailto:sujay.ietf@gmail.com]=20
Sent: Tuesday, October 31, 2006 5:04 PM
To: Scott = G.=20 Kelly
Cc: Smitha Smitha (ssmitha); capwap
Subject: = Re:=20 [Capwap] transition to join state

Hi Scott,
Good point, but shouldn't this timer(WaitDTLS) = be a part=20 of the
DTLS implementation, probably an add-on, if not = present.

For=20 if we are to separate the CAPWAP transitions from the DTLS
handshake=20 messages, a WaitDTLS timer doesn't make sense there.=20
Regds,
Sujay


On 10/26/06, Scott G.=20 Kelly <s.kelly@ix.netcom.com> = wrote:
Hi=20 Smitha,

>
>Scott,
>
>The idea was to = isolate=20 details of DTLS handshake from CAPWAP. If we
>need to keep track = of DTLS=20 Client Hello (with a valid cookie), then the
>earlier = transitions were=20 OK.
>
>Why do we need a CAPWAP transition based on DTLS = packets=20 (unless a
>session is established) and a WaitDTLS timer that = CAPWAP=20 needs to
>maintain? That would be part of DTLS.

You need = this=20 because DTLS provides no timeout of its own. It provides an = exponential=20 back-off timer, but this never terminates (I know, sounds like a major = foobar=20 in the protocol design, but they probably had their reasons...) =

If we=20 don't add the timer, resource-exhaustion DoS (from a bunch of = half-open=20 sessions) is trivial to=20 = mount.

Scott

______________________________________________= ___________________
To=20 unsubscribe or modify your subscription options, please visit:
http://lists.f= rascone.com/mailman/listinfo/capwap

Archives:=20 http://lists.frascone= .com/pipermail/capwap=20

------_=_NextPart_001_01C6FD0E.4A34351A-- --===============0997110798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0997110798==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Oct 31 13:05:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexzO-0001GS-5P for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 13:05:32 -0500 Received: from mx2.tigertech.net ([64.62.209.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexzH-000395-Be for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 13:05:30 -0500 Received: from fry.tigertech.net (fry.tigertech.net [64.62.209.19]) by hermes.tigertech.net (Postfix) with ESMTP id 04B1A144806D for ; Tue, 31 Oct 2006 10:05:19 -0800 (PST) Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by fry.tigertech.net (Postfix) with ESMTP id 8F9A54A45C0 for ; Tue, 31 Oct 2006 10:04:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 47A9E3980A7 for ; Tue, 31 Oct 2006 10:04:30 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by zoidberg.tigertech.net (Postfix) with ESMTP id B47EC39805E for ; Tue, 31 Oct 2006 10:04:26 -0800 (PST) Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GexyK-0002bH-VK; Tue, 31 Oct 2006 13:04:25 -0500 Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP; Tue, 31 Oct 2006 13:04:24 -0500 Message-ID: <4627800.1162317864881.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Tue, 31 Oct 2006 10:04:24 -0800 (GMT-08:00) From: "Scott G. Kelly" To: "Smitha Smitha (ssmitha)" , sujay gupta Mime-Version: 1.0 X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff71003b59a37c2f73b8acdea79e74a392ab4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-Spam-Level: Cc: capwap Subject: Re: [Capwap] transition to join state X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Hi Smitha, I've sent inquiries to the DTLS RFC authors to get the full explanation for why the maximum number of retries (which is another way to indicate the handshake timeout) is not configurable (i.e. why the application is responsible for timing out DTLS handshakes), but given that the RFC passed muster in both the TLS wg and the security directorate, my expectation is that there is a good reason for this. As for your comments below, I think you're missing a subtle point: if you want to use openssl's DTLS (and probably other OTS DTLS implementations will be similarly implemented), you can't process DTLS session initiation from a client until you create the session _for that client_. This isn't TCP, and there is no support of listen/accept with UDP; we are responsible for demultiplexing DTLS packets (i.e finding the session they belong to) prior to handing them to the DTLS implementation. This means the AC has to explicitly create state (i.e. a DTLS session/socket) in order to be able to process DTLS packets from a given WTP. Here's how this currently works with openssl: - a WTP optionally goes through discovery (no state at AC) - the WTP sends a ClientHello - the AC replies with the HelloVerifyRequest (no state at AC) - the WTP sends ClientHello with cookie - the AC validates the cookie; if it's a good cookie (e.g. chocolate chip! :-)), the AC creates session state and hands the ClientHello to the DTLS session; this may be via a DTLS socket, some other session model (e.g. a mem BIO), or it may involve hardware plumbing; the AC also sets a handshake timeout here to avoid DoS. I'm not clear on why you two object to setting this timer. It seems like a DTLS implementation *could* provide a parameter for this, but the fact is that the current standard does not provide for this, so if we object, then we must modify the standard (i.e. produce a new DTLS RFC which rectifies this). Sounds hard to me, so absent a show-stopping objection, I vote for setting the timer in capwap. Am I missing something here? --Scott -----Original Message----- >From: "Smitha Smitha (ssmitha)" >Sent: Oct 31, 2006 9:02 AM >To: sujay gupta , "Scott G. Kelly" >Cc: capwap >Subject: RE: [Capwap] transition to join state > >Scott, > >I agree with Sujay. Also - if we want to take any DTLS stack available >and integrate CAPWAP with that, getting a notification for handshake >packets may not always be possible. > >Thanks >Smitha > > >________________________________ > >From: sujay gupta [mailto:sujay.ietf@gmail.com] >Sent: Tuesday, October 31, 2006 5:04 PM >To: Scott G. Kelly >Cc: Smitha Smitha (ssmitha); capwap >Subject: Re: [Capwap] transition to join state > > >Hi Scott, >Good point, but shouldn't this timer(WaitDTLS) be a part of the >DTLS implementation, probably an add-on, if not present. > >For if we are to separate the CAPWAP transitions from the DTLS >handshake messages, a WaitDTLS timer doesn't make sense there. >Regds, >Sujay > > > >On 10/26/06, Scott G. Kelly wrote: > > Hi Smitha, > > > > >Scott, > > > >The idea was to isolate details of DTLS handshake from CAPWAP. >If we > >need to keep track of DTLS Client Hello (with a valid cookie), >then the > >earlier transitions were OK. > > > >Why do we need a CAPWAP transition based on DTLS packets >(unless a > >session is established) and a WaitDTLS timer that CAPWAP needs >to > >maintain? That would be part of DTLS. > > You need this because DTLS provides no timeout of its own. It >provides an exponential back-off timer, but this never terminates (I >know, sounds like a major foobar in the protocol design, but they >probably had their reasons...) > > If we don't add the timer, resource-exhaustion DoS (from a bunch >of half-open sessions) is trivial to mount. > > Scott > > >_________________________________________________________________ > To unsubscribe or modify your subscription options, please >visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From nozhzst@shawcable.net Tue Oct 31 22:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6VD-0003Xx-9J for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:56 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf6VC-00038I-Jc for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:55 -0500 Received: from s0106000d5656849e.cg.shawcable.net ([68.147.167.223]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf6V9-0004cE-Lq for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:53 -0500 Message-ID: <000f01c6fd63$5ac7f000$dfa79344@JOSH> From: "face" To: capwap-archive@lists.ietf.org Subject: Mars Date: Tue, 31 Oct 2006 20:10:59 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C6FD28.AE66A700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 ------=_NextPart_000_000B_01C6FD28.AE66A700 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C6FD28.AE66A700" ------=_NextPart_001_000C_01C6FD28.AE66A700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Boy Small Town Girlkellie. Michael Cuddyer pm Thursday. Pets am Saints = row Star. Relying ageing Canadian. Dvd Svcd vcd authoring Pinnacle Edition = including or Avid Xpress in. Deal of District city imagine lineup. Title internal led wish change = point directly is intended toolssign. Martin Pipe dad Boots brothers am. Niall known Slippers surely teaming Martin in Pipe. Colour green how do we this View Public Profile. Check yours wait = youback. Divine Comedy burned religious grounds Queen Elizabeth censored parts. = Born Livelyrics Ukbadly Drawn boy Small. Majors especially Europeans. Neopia cover issue or full am ofhelpful a. Rodeeljas homepage am Find by = Mark Senior Junkie nov. Planned while whenthere they posted herecute cuddly ummm. From website = whatever in takes fancy Iconsfun Imagesshop Catalogue Contains? Boy Small Town Girlkellie. Weeks lately ive determined of folks needs a? = Determine andorvs actually is. Owe dillute or mediumi publish blog expect nonmusic Vegoose Torrents. Launch dedicated channel vacancies of several. Aug comment in login comments rate or! Join in Date jan of Location = Australia Posts. Relying ageing Canadian. Puts hardly bettered season am lay lad in lead. Extraction painful pair pylers job am guys in. Vice President Managing in Robert Rosenthal position sensitive = gatekeeper. Michael Cuddyer pm Thursday. ------=_NextPart_001_000C_01C6FD28.AE66A700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"big"
Boy Small Town Girlkellie. Michael = Cuddyer pm=20 Thursday. Pets am Saints row Star.
Relying ageing Canadian. Dvd Svcd = vcd=20 authoring Pinnacle Edition including or Avid Xpress in.
Deal of = District city=20 imagine lineup. Title internal led wish change point directly is = intended=20 toolssign.
Martin Pipe dad Boots brothers am.
Niall known Slippers = surely=20 teaming Martin in Pipe.
Colour green how do we this View Public = Profile.=20 Check yours wait youback.
Divine Comedy burned religious grounds = Queen=20 Elizabeth censored parts. Born Livelyrics Ukbadly Drawn boy Small. = Majors=20 especially Europeans.
Neopia cover issue or full am ofhelpful a. = Rodeeljas=20 homepage am Find by Mark Senior Junkie nov.
Planned while whenthere = they=20 posted herecute cuddly ummm. From website whatever in takes fancy = Iconsfun=20 Imagesshop Catalogue Contains?
Boy Small Town Girlkellie. Weeks = lately ive=20 determined of folks needs a? Determine andorvs actually is.
Owe = dillute or=20 mediumi publish blog expect nonmusic Vegoose Torrents.
Launch = dedicated=20 channel vacancies of several.
Aug comment in login comments rate or! = Join in=20 Date jan of Location Australia Posts. Relying ageing Canadian.
Puts = hardly=20 bettered season am lay lad in lead.
Extraction painful pair pylers = job am=20 guys in.
Vice President Managing in Robert Rosenthal position = sensitive=20 gatekeeper. Michael Cuddyer pm Thursday.
------=_NextPart_001_000C_01C6FD28.AE66A700-- ------=_NextPart_000_000B_01C6FD28.AE66A700 Content-Type: image/gif; name="important..gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c6fd63$5ac57f00$dfa79344@JOSH> R0lGODlh7AEAAof2AAAADXoOAAKOAH+HDAEAc3MGcQB0dMC9trnhxqnX/kESAGQgCHcrAKISAMIp B90XAANDCRU/ADo6CF0yDYxJAphLAMw/AN80AABdCSZcCUdRA1xRDIFiAppcALxcAN5TDQB5AC6M AD51B1eDAH1yDquGAcSOCt16AACbAReRAD2uCGGjAIycAKelC8uRAOSkDQC5BRfMAz+9AmrLBoDK AKfKALfKAOm2AADbDhntAEjmAGnTDnToDZHlALzsAOrVAAEAOhoLOkUAO1ELPoQARpsAPMsOTNgA RAwuQCoaS0keOmIZS3MaMp0VSrYkONgVQQA4OBhDNUpKO249PIVGRZ1IMcAyONQ9OgFZTi5uODNp QGVdO4FbAJ5mPMdZStxkOAdyQiiMRUWLSlpyPIF9SpaHTsVzTOBxOwCkRxauNTGjOVeSPYCoRJyT PMSnM+yUOwC8PSixMULDP2i6RYfBOqbCMcHDP9HMNw3fRCjYNkrlPVnSM4zSQZzqOcjXN9vgQAAA iyAAhUsJi1YBdXILfZQAjrUOiOIAcgAXdxMshUgggVIpg3UpiqsRf7occu0eegpJehFFeksxeFI1 gYpLhq5FfbpIftlLdwBsgitWhU1ghFZYjIJmjK1ejMZmf+BXhgKKeRl9hUqGjmKBjYx/daSLfceO gdGGggCahSGlfz+WgFGqiHecgZ+hcs6qc9WoeADMgie9dzTJcVy6cYjLc5/MgLS8cuLAhgvcdiLR hUbggFXmeXTUjKTnhb/phNXrfQAAuh8OtDUIxFcAtoAAupgFvrYNvtgDugAbxiYfzDMbzlomzHMk xpUVxLkgyOgVzAA7siA4y0QzzVFOt3I2t5tCzsZNvOU2vwBcxxthxTdlylhdtXdUt55uyc1ovtJV sgCIxhWKu0CAu191uY12xpeKxMN/sed8zgCeyCmcsjKpt12ZwnulvJeZxsetweSazQuxyxy8vk69 uVO4v4nMv6K9xPH9+ZuaqHx2e/8ABA3/C///AAkA//8A+wb/+//3/yH5BADz65UALAAAAADsAQAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGnyn8uX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqPcqyqdOnUKNKnUq16sGlWLNq3cq1q9evYMOK HXvTqtmzaNOqXcu2rdu3cOPKnUuXrN27ePPq3cu3r9+ZdAMLHky4sNu/iBMrXsy4sePHkCNLnky5 smXDmDNr3szZqeXPoEP37ZxWtOnTqFOr/jpxtevXsHGSRhu7tu3buG9/2P2PN8wPvWMC303cd/Hh x4m/VL68uHDnNYH/Ft47OfXrLqVnp55ce3bo1Zk///fuPXj36tjDn0+vvbvv7dOnr5dJHrx68d/x 62de/v7x4LmFJt1725U33EwGxtfcggDC16CD9MknoU39tddggv2xB2F9DGKIYIIIKrjciBXSRN6D B+KUIoojUihieyeW2OKMAerV2oAsXgghjRGKCOCJO95koYUPhojdijoW2SOJLx7ZYoZIZpijgkgG OeOKOKqYpINS0gikkkp+Cd9sZwGFI5BEQukijwVSydOQTwq5ZJRxrsnklUamGaKYTTopo5Hm1Skn kVzK6aWVYfrYZY2PZaknfOvhd2iEYkpq4p0/WvfbfHRCqumkX6qZ5HlZgokip4le2qan/1E6qX8g bv+IqHuKMvpZqbhuaWKsYCJn6XeGPrpoqoQGimhz4rVqJZzLCqrhdcWa+mOdw45q37DKQopslVMe aytYNxaqY7Sqyuqqt9iOy2Z6rBKIpaFOrstsr872GV+20hqrb7WtFpvujqVi+uqYZBI2Labvaskj iHz6eO6+8Aoa47oOd8trwhpK2XCuFSOsa7kBk/usuAKbK1PBVpkJcKWAmgzsywzH+9zM3iZ6ccfy HgnjyIpq7HCVDW9Kc75FAl1zrDuX3C3R3yamnIGVaoovlO72mK3PL34apNFeak0vewR2/R/U5drM c8unTs0dpV6XuJ9xSxbdNF6tiVbt3HgnhvJgduf/7bdke1P19+CEF2744YgnrvjijDfu+OOQRy75 5FnVTfnlmMsWOERA5eO55y59Dnro+cRU+j+inz6T6KbD9DnqqodO+us00S6767Cnnvvoq+s+u+m8 o36T7bC37nrswr9EPPKxI7+6Tcszvzvxxzfvu/Kszx5879tbD/z0Mlkv/und3z7ZIYpJ3zzprUv/ vfLwr1887u4fj735sjufPP64hw+/+eSDnupGVz779Y93BDSe8PT3u97db37xwwkCA1gT+ckvfBcs 3QCZp8H+5c+DwdOg+xj4t4noz4L7W6AEK5jCAK6PhP+L4QD5hz8GOm+E/4MhDi/4wRwqcIYRhF7t /4zXwSAK8YBHNGIKPei/GTpxiU+U4fNQ+I/NjeSESHzh8ISIQi0mEYm3w2IMFTjG5EVxiE1sYfvo 97z9eZGF/kvjG9G4RjgqUYxDPGMH61fEMOYRjFZ8SOdCmD0z5nB7ZayjH93YwDgS8ZC642H1EghG FVJviT0Eog97+MgaYpKMiVQhI1NXwPZdz5NqdOQUfehCJvbRkG0EIgwzR8lFwvKBIKSdJil4S/aB EoCMxOAl/5jLPZYRi7L8ISdBmMpPhhKZrNxiGitYyFMyUZmGdGEhg3lL1iXTmSWUyDSNyMtr3lB7 3+zlMdsoyk9qcov1YyP/oGlLYLaTmePTITvlmf9NaSpyn1IE6CR5eUbg2a6cnKTg6QIZknEu85WJ xKE95xhRMvYRj+DkJw0JqspeQtSL8XzlOzu6TjVCFKAI/WUzVRrMXTrTpfM0aUwY2pCfqK+S7Iun L5cJSw5CEYO4RCUoMcrROI4UgrXc6TzJt0GLsvSlTYXiSYHqS3129IQUnapWOwnBe85vlpPz3fV8 Cr7a6dKUH2XqMBvpSlJiEquEJCoisSfJUip1mHXl3lxzZ04RWpOu11TpOfUaU3oOla90RWhSDWe5 zDn2sS6h6UcgS1nHStYjlc0s5S7bEc2uhrOgLYxnR0taxDW2tKAJrWrbgoiroPa1sLXVRAQQE9r/ wsS2LsGtAHbLW96+pLe5lQluc9vb4u72t8ZN7kyGa9zbNre2wE3ucYOLXN8SV7rHne5vnavdmgC3 treN7GrHC5efMPcf5w3ucKmL3PCuF73CBa9N0ste9W7XufVdrnzzC1/dhne/1O0ufNFLX/3el8AF ji1pW+Nf/273vet974D/S2H+AjjBtHXwfyVc4fiCV8MTPnCAQ2xbDuckwv8lr4rbApQGizjDHrZw iPmL4vlWGMUgfvBNTDzj/r44xiM+L49xUmMZK/jINHFxfWF84SQrF8A9brKIfWzhDD+XuwZ274+h XGL2Mrkn1r0xkkvLYC+bOb8JnnKPi5xk7grY/8ES/jKR2TzhEn+Xy2f+8p2JLOUV+7k0La4zifdM 4jZDecZDpm+EvxvnKNt4ysU9M54FTeUOP3rLY85bJfii50Kj+dBrBrKjMe3pAUPYyIb+9IjVXGMh q/rEoM60Zuv25hxj2NWHpjOQW/1h6KIa0WLWcod5jV8CWzrYW/6zsg32amCrGcFd5nJ3E21pOfc3 0tUlNLTZjONdY3nRbp7ztBkt3mWbWy6yBty51/2WdEeG3fBWibvnTe962/vejou3vvfN7377+98A Zwm+bUOHgRv84Ah3d8AXzvCGO/zhEI+4xCdO8Ypb/OIYb2jCR3uKjY8m4yAPuchHTvKSm/zkKP9f i8dXzvKWu/zlMI+5zLmS8prbvN+0uLnO/z3znr9850APusZ9TvSNC/3oSE+60pfO9KY7vSlFjzrC Ke6Hp1sds1LP+rcOoPWue50oVw97QqRg86+bfcxiT7vQz8722Kr97Tpvu4JdQBZ+yP3ueEcN3Pee csq1I++AD7zgKcv3wncGF4ZPvOIXz/i1D/7xkTttahCyE8pDHitHh43lc7J5ytkdJ5+HTegzHhQA mB4AYjH9S1DPGH643u6h/0foXf+S2Nv+9S55Pe11D3vdy973vo8J7mmf+98TP/e4r/3uZ6/84xe/ +bWP/k+Sb/zjBx8mwE++9ZHv/Oo/X/bfNxz/JvrCerKo3iXlT0zswS/937ef/d+H/UzWz3zsv//5 26//+u3vfvzXpP7sB4A8IYC293/CF335Z4DF93kCmHDpt3rnd3r/EIESiH4UGIGrBxOox3oceIET WH4VOIFcQX/8x4DhV4ALOH8HGH7wt38m+IL2t3/SJ3/gJ4Pxd4DDR33aB3882IL353/8V4MB2INB KH8keGQT8YAiiH5LyIFL+IRMCIJPmH4byIQa2IRRmIFQWEWuxXlXoX28B4QoyH0MSH09OHs7yIJD CIMz2H1rmII00YA06IPM131H6IMygYZlSHw0uId5iIAuyIVBp4RS6IQiKIUfqHqIWIVXeIgW/6iI VriBp6eE5VYQldeFQjiDQHiCCKiCRSh8ZqiJQjiGLGiCo6iAZ4iHNQh8f/iJahiHdAiH9xd8bmh3 R0eIGWiIjOiIWRiJW+iEu8iIwKg5BnGJxdiJgMiK71eHnth+RyiDpmiEQViK/jeHrZiKAGiNRHiH DWiAzJiJs4iDB0h6P/GAheiL59iLUygTIBiMWMiL7+gV1jiPPDiG2kiN+LiN8TeHgViCyveK9SiK sSiLrsiJKxiDyNh/oviM0whbdTOJj+iLhxiCEImIWziFHQiJ70iRM4WJZXEQtIiQydh7y8eH18eN yniCu/ePJxmKw/ePZHiQxod9/Mh9AOmSoP/IhzHpfS1Ikvp3kKbIbqOAEWBBiTdhlHhng7ailFGH lDXhlHfHlLkhlaPVeFZ5lViZlVq5lVzZlV75lWAZlmI5lhR3eWZ5lo+hCmhpcGTZlqq1lnAZl3I5 l3SpG3X5Em6Zl5d1l3yJG5LHFB75boGZOHq5EmNWAUeBmKihmH0JLhIBkTEBlR95jJRheYzpEpcZ E5n5D4ypmBXwmZ75mS8BmpdJmqMpmpwJmqeJmqnZmTCBmKwJm6bJmaNZiVHRDV1Zjlr4OLPJmpqZ mbGJmbVJm8I5E65ZnJuZnMNZmqk5nMRZnM/ZmF2RhLnIixXIkYAxmI+BELCpmTXBnJ7pnOH/GZ3e uZzQeZ7o2Z21qZ7HeZ6IWZhsUYjDuJuGeDLa6RjcSZ6bKZ7IuZrHuZ/uCZ2qSZ76GZ3dOZ4G+pqC CJ9oAZnp+IjnVxOdp27FOKDoqaCYaZrtOZ6hyZzm6Z3KqaDgKZztmaAMihK62YjweJF4o54E6pwf +pwciqEBSqAuCqO0OaI5CqMeWlrN0DjUqaK7uI4suqAEcRmu5aI9aqMCGqMluqEygaD8maCdWaLe eaJpYY5aeJ0RapQTKpgGMZutKZ6+KaMZipoWKqatWaWy6ZtiaqFrKqBPOpxY2hJIBqA+gaefoafS mRR/aRRfChmWmZipwZh1WhJ9mqiTJ07T/3mfmneofZeiT9mRlJkbkNp3kJkTUPmAgdoYFcmlWyqB FjcMl7oQkjkTm0qpligZWhqFD2qbpQpwkmqFEymJEAqBuogareqI86moA3ed1YmFDyqMqcGlGKiL Eeqr9zafuTqsRXoa7tirtKqs9cas6BisK7oa0aqO00qtlsWotLqI6ritS9ipj0GuHxiZRhqrIZep RAqMFImB5eqoieGgwGqBich67FpyqKoU5vqo+yqrRXGq3lqwRfGnjPGvXhGwjkehq3oXDHtxWUGw qkGxBut2j+mu6roTk2ix/WqflYoUu5qIsBqxEDerk9oTHksTKyuyoBquF+uANmGv9YmLuP/aizQb kc+6FEPKoi0bs5KThCFIn+pqkbt5hfIKj0Oqr/SqmyNrhSa7c0irkU0IrJRIhRJokZKYtdkZskYx tLsatXF3tOsorldLtFr7i137sEnhjkcrtjdntGVLtB87tzD7qkzrtV9LpFsIt2U3tLiakXJ7tBWp gcYKgVDbtD6RqcaqeiUHDX57pELxs3VLjGwrssZIERkQuQs3FJR7s5kruUpBsZwbbxwwWUALqKVr Eamrup0xlPzaurK7Fwg7uzqxuhZxAjGhuyfQu77Lu78LE7orvDLxu8BrvMg7vLvbu8KrvC7hvMG7 vL77Es77vP9Qvdgbvc+LvM3LvN3bvMv/e73ZK77GK767S77TW7zUm7zaS77gS7y4KxA/gb3XOxPQ S7zWe774m7/8W7/r+7/mi7/e27/+m7/V67/Ke8D3S8AAbMAJPLwDvL0B/L8HPMHWO77UW8AZvL8D 7L0RrMG2KxQJzMAavMAgfML7W8IpjMAqjMIpDMHqW8AKzME0UcEgDMMjzLsyXL8VrMMZPMM/HMMb fMMXvMIhDBQjjMImXMRCbL8vPMTE68NMbBMLDMQ87MRD3MM17MRSrMNdfMXqe79aPMVQzMJh3MJH LMIbnLxoTMbf28QmrMUw7Mb2q71WLMVPvL3la8NyzMQ+/MfoO71zDMb6S8hlPMhRzL82/yy7dfPF xdu+ZVzHhRzIRkzIOLy+H1zFcFzD7TvGTRzEYAzIlyzEo6y/SXzIJOzIuhu/FDHFnuzJN7HEp6zE O2zIBEy/VuzCswzLlezIlgzKhVzKAgzJ9EvLSbzK8RsUvpzHlYzF/SvLppzIRLzCePzMW5zF1/zJ g5zD2AzLXkzKqEzDAizNaTwUSxzOkXzLzKzID3zLEHzOcUzN2WzAnDzMANzHZ6zN1ezBk1zME8zP 71vOaozJwZvLi1y+6/zMEYzBeqzAxJy+zTzDbEzQ0tvLxsy948u96FzCC73Q4SvQIB3SIj3SJF3S Jn3Si8PKKs2Vm7DSy4bSMB3TMj3TNP9d03hRDzad0zq90zzd0yjt0kDdWT4900Fd1Bkx1ERt1Eq9 1Ezd1E4tFUgt00HdDk8dEVEdFFkQs1W91Vzd1V791Qlx1TDNWa2VEi0A1mid1qAl1iH8AJar1nAd 13I913Rd11pJWUrA1vlm10Gt1ybN133t14I92NJ5FvcA2IVH2CKN2Izd2CZb0nYN2XUt2XT9D9pw 2dpg2ZjtEpn9Ep2N2Z3N2Zft2aBt2TAB2qE92qQ92qgt2qrt2p/92q0t2p5d25sd2qYN26e9262d 2rWt2a992rJd2rSt2zOx2ZzN28Kd2bjN3KWd2U39E7id26Yt29QdE5+d3Lv929jt29v/zd3Ybdva Pd3Fndvebd3XLdzi/d2+Td7hbd7H7d3pTd2xvd6/bd3T7d4kPRH5Ld7Zrd/Znd7NLRMB3t/f/d7V Pd4EruADnuAOftzwTd7M7eD6fd/avd0BfuECTuEbzuH9Hd3SrdrE/d+u3d2pjdzNjdzwXeLAfeL5 jeLDjd71jeHJPeHATePOjd8PruImvtrnreENvt4TbuAkPuKKveP0beA1Dt7XLeE8vuQ0EeRDzuQt DuUKTttBnuTzPeUSDuHy7eNAfuA7buMWjuUIPthkTuYdfuVKvuYbXuFSvuJtbuM/XuZNrtzhPeXv 3eAZHuZffuF9ruYrbuU1zd8wLuK8//3k7f3ct/3ciS7ijB7cVU7fLa7maX7jUs7jAz7blG7cd17j jm7bT77a4J3jOX7nvb2ucO1yFQ6mc03Zjh3reXnkIC3rtn7rV0nrur7rj4frnMvrR+zrkQvsxF7s xn7smSXsyr7szN7szv7sUI3s0j7tPwft1n7t2J7t2r7t3H6o1H6xtUu73e5w326wf/m5/jruDVd6 g3uU7Ji19xqJgFvuGGvV6dqtOPG08omtIKvuI7eR8Vqz996t5yitievvAQcUuTqudmu4gnutJIvv 9P6r8Y6uPYu02JqsOzvxnhWkDO+sSImuajuvCC9yVJivoIvyUEiz9VmriFjy/56wgP/NBGrXGDBv 7VR98zq/1Bzf8z7/80Af9IlKBmSgGDsvckRPBkdPlkm/9CCXC2dB9FEh9B6X9FTfl0VPFk6/r1dP c5Ha9XQpeU5ZheiOssW6sey4tyn7WGGH8mOfrRtLsPOO9iyb9vmu8ZqKuRhP93af92v/92RbG6da cyj79hffiBQrmamq8HnxtIGvovk+s2BvjvGahYzbgfd+rHEf8NGqiGRftTobql2K97UamZSftFvL rJBotKuPr7c68O4K7656rJxv+hkZkRfYjq8vt7kfuK7v9iof/D1X8RhPrsQqrDYL8hnv+sR6tg3f ryEvpA3/+SefrZi/99bJtxuptNz/z/rS36yE+64jb/HY//kML3Vuy7Wdr5EP7/zKL5EC76B2/6rz /+7V3/3VubTcGo8kK59UCxAA/g38J7DgQIEJCSo0eLBhw4MLJRqkGDEiAIwWK0IsiFEhQo0IMz50 OFEiQZQpVa5k2dLlS5gxZc6kOdPeTZw5deZE+bFkSZ8+L4I8mbIiSJIkkRL92dMoU6EWQ56EmNTk UqEbn04NKlUpUa1WrTL1elXr0qZni4Yc29WtxJ1x5c6lW9fuXbx59e7lW9fj0YsjHXpcmHFox6iI uRJGnNBwV8WMRUJmXFVxT8OTHxL+i5bz2quTNYtu7HToW6WdMVN8DLa06K8cYVOt//z4c2rCfXXv 5t3bd9+awYUPJ17cuEzZx5MfZ+5y+cznLaO/jD6dbHPs2bVvTwmc+3fw4U1jty6+pmTi5cfTRL+a uuHf8eXPp1//pnn8+fXv598fu30AAxRwQPn8M/BABBNU8D8CG3TwQQjtQW5B8NTDz0LmlsNQKv4y 206gCEMUcUSchKvuug+fAuw7DFckj72YXOQQNJg2hI66GNOjcEced5TxwvxaDE/IGqVjaUMbJ3RO vCR7dFLBvhzzsKPXqDRqM9YEw0owLWubEjPXVMvSM9YCy1I22zJTbTTSbGOzSxfFBKxMM98caTM7 rxwTto0ka41OEEkUdFBCdYLMNf/PVsoqNIbMYovGw1rDaiKOPnoLxbSmgurR0xwNjdOzwmI00k7R KiqqoxpNdEqFCnX11RAPPWwwVrXctK1VR1VJzls5nS3Tr37N9FRQP0s0svGkDPW2UVMtbSxiKw2T LWNng/VabPEyUdNZEyu1V1NVvXRWDiUFSldLfbUM2LWgTTfaXOF1asVx313UVHCpmhTf1GZ88l+A tw122Pa8tJPLLuvkSs/TKmvTvZ8cvq7aM1fDkjbK6qzUYLKM9dJZjfWFWNpOccvK1oBTVvnJJotU UuWWF4x5ZZprttm8mTOkOWcEeb75Z6CP8y5ooos2Gr9sk1Y6rqObdvpp45aW+kH/qGtu0mcFsV6P Qq2r9hpnTHet8UtIFcVTOX/1RNlJC7X+8Ug111wzuBO/9nro7NwuW724db4xbK7/bu5tsTveeri6 p1Z8QBMd3lPusCzdE6mCVaRUJH7PvQzyNMlckk0rR+48zbPFbFdcLAGttWIwId+KWMA5Kz3iwjC3 G+ooL1e34Wmb0nViUCm3XFV2w/X9udjIXZf2YY33PTDL402W2zmVf31g0+i1MmODFvfeVXebpZhy c50Hvq1qRa53d8mRjxa95e1djPutqrJVWeDN77bKcmFXFFGKxU1L3yNggej2u3EtDE3zAk2/joUi Z4VPgsxbYL7Wg6vi0S97+oJW/7t+tz8NeXBvvctYWW6HO76YrjCsQ5ZZ7mQZ7MFPYunLn8TM9DiF VXB+DNtcmPx0P0idjHWy21j1GAiWL1XOYhsM2aZ6WEAo9mZbLzvh51Jmo65VUYtVzB0Vt7jCnZ3n i/mJYhnxNkY0plGNa2RjG934RjiuMYn7yeIUvYg2JuEojnt02hn7l7bX+ctbW+tMcrJYHsIdzkh1 LFsDiag9/plRkpP8jd9EpsfYYfKPgRxcjgCpyCOBzYqbdMyn+HhKq3UOc6674GtKGbq5bcx2brrM rX5Iy5NVqVYRSx2tegnGpNwJdDYkJe0YiUpkvqSLz6seJI0nv4ERk4IzmuCqSP+GQSRGT3PNKwvI 1lfEN5GJI5QkZzn1kpIVeJKZtvQQDE1SMeyFC07lYx+l1gZC+HUMiOubnjfr+T93kSyZAwXPMlFl QQ+KxXBhgyYE+9mswzXzfwp85wdJ2Lviia2D1/yHOT36UaY1TkaUWZ1EcyhDNT0sMiWd35gMucMj tolZSGxnSgGoy/LJKae6JGhPs+NHn7JtlDwCaVFBGtSntYeTSGWq0Yz6VKhGVaoe1Q8FmnpVp91B P+zAale9+lWwcmeqYyVrWc0Kq7CmVa1rZWtb3fpWmJxVrnOla10NCFe85lWve+VrX79mV8AGVrCD vY9fDXvYNBJWsYtlbGMd+1j/yEaWaoilbGUte1nMZtYlkuVsZz0rKM2GVrQq+2xpTXta1KZWtasd 0Whd+9odsfZB55BtbaF6WF3AVre75W1v22hb4Ab3s74lbnGNe1zkHgioyR0jOFYmXPoMBxzTdS51 nfuP6w7kutZFCXW1692UcPe7BPFudrGL3emel7zkBe943Yve7KZ3vNatbnfhm17zVje+9Q1veblL X5W0N7/dxa94vytfAAP4wOzdb3vhe1/+GhjCDO6vebUb4AYXuLzH7YuF44ve9VrYvupdiYhBvN4T q3e7HyZxf9l7YRjLF8QeZjGJByxj/IZXxwEuMYpxvGMYj/i8HuZxjI3MkgFf/9jEKA5yjYnsYiET GbrzEc6Th6ziFu94ySbero+xjOUuL/nK9SUyma9s3y43Gc1jbrGIuVzkEH+ZyVm2cZatrOQj93jO dI6yju/85CTbmcN8efB9jbxiN1N4xOBN85cjfGgVy5jN/I2zmcUbZibfeNKL1nCg9/zoP2MYwYz+ r59x7OAg0xnVal6zkAXdZgZ3ecqgjTOe35tqVbsa0Szeb55zPOc0U9rWmI6yk1tN7FQLe8+C7rWu 4azsO7MZ185G8rP9DGQ7O7jGF541iVp9ZlxH+9XgdvSik83qIzc62LYGdqaPPe06v9nasKZ2n8XN 6zzDmc/TDrSx611neHe7kv/BuTSj0Yxq/0o61rDecIh/3WRtA1nApm44ug3NbFHrd+Il/jGwO07g UVcc5O5W8ILDveps09jNIndyqZn7cpjHXOYzp3nNbf7a5d5cJQLnOW90/vObn1roXE54oyMt6ZKv uuXb1riooXzxF5vc6edut9S3nW+gY9U7H1c3tuP9YTHTO9f+1vSr8+vv9xqd1R9PcdcBHnXn9lzu DSp3ralOcjC75OplDjfD+w5wo69bzn1/dK2h/XYvz13xAao7u1N+4HUjWs/jdve3h6zwQqfb3EfX 95mFjWlA81nWiyc9lS9t+S3HO+rL3vu87S5t1BvcxwZP9LeR/uLQyzvupef/vW/KLmcxU/rzXhe7 vNf+7s3/PvCDP37Vff36Ofde+ru5sYCVTmoEHxzzj5+81C/O9NdrHPxXz7yn+61wotd3+tLPevvd /374x1/+86d//e1/f/yrtcOVb7uBXZ7sTlO5Bnu6iVs/AzwttEM/VxO7u2M9j/Oy8zpACfSsTcs3 8vM0Bvw7CBS83ZtADyQr6YK95eO3kmtARQs9zoO3/FvBzSI0S1s4/nM+E7w2Tsu+DwMsE/hAHWSa Fyy+BcRADNQyCBw2lNjBwWIHuSMOtEM8QzM/toO8kTs3sGNBKoyJnGsaI8xCwTohLexCc6pCMEQq L3yVcBjDztIEM0xDNVxD/zZsQzd8QziMQzmkDyVoEIyYQzzkPY/IQz6Uu7/oQ0Dstj0MREIUrkEs RES0LQCwqzBsREd8REiMREkcqESsxOCaREzMxMriBE3UD0v8RNnqRFEcRVIsRVM8RQYBxbloBlVs RVd8RQBBRVkkGlisRVu8RVy8wlncRV7sRV/8RaDLRWHcQmAsmlzAxGFMRmVcRu/5izs0rWIkrrkR Q2asRmu8RjiMRm1cEGzsRm/8xh3cRnFULnAsR6m5AnMMLHRIR3ZsR3d8x8EaR3mcR3q8G3i8R2yp R30sKHzsR3/8R4AMSNLbR4IsSIM8SIR8GoFcSIZsyFeRAZ9LSImcSIrUDu+HvEiMzMilqUiObAmN /Egp6kiRHEmS7A6QPElCK0mVXEmWbEl9REmYjEmZjA+XpMiZvMmQqkmd3MlixEmf/EmgLCyelEhj GMqXDMqbNEqlXEqmbMrkugWojEqp3DmkrEqrzEinzEqt3Mp/oQSudKOrjMmvHEuyfL+wPEu09Ee3 0gO2bEu3fEs9KMvbSUuQlMttDAS75EXC4gS6FLg94gTAzEtZBExOFExUDEzDPEXCTEy2GivCRMsR uEjA7EsDZEzLvEzMzEzN3EzOJMhm6Mz5c6xUoEzgAk3TPE39I82LRM3NrALWDCvVXM3XlMSAAAA7 ------=_NextPart_000_000B_01C6FD28.AE66A700-- From uzeftzh@shawcable.net Tue Oct 31 22:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6VD-0003Xz-L0 for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:56 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf6VC-00038Q-VY for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:55 -0500 Received: from s0106000d5656849e.cg.shawcable.net ([68.147.167.223]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf6V9-0004cF-Of for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:54 -0500 Message-ID: <000b01c6fd63$5ae22ec0$dfa79344@JOSH> From: "Das regard." To: capwap-archive@ietf.org Subject: claptrap Date: Tue, 31 Oct 2006 20:10:59 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6FD28.AE728DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 ------=_NextPart_000_0007_01C6FD28.AE728DE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6FD28.AE728DE0" ------=_NextPart_001_0008_01C6FD28.AE728DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorta blogger Isnt Timberlake tour dates of interest maybe personally. = Vocalist Natalie earned four Aria! Many or cases in compiled of title = having challenged? Thoughts ideas Jambase of database interact albeit moderation pattern = am. Save retirement lets. Ones far never a expire lose value locations am redeemable websites is! = Grinning galumphing bit stupid Clearly not Although am presented. Location Australia Posts hi all newbie my of husband of amp. Odd reason viewonly remote. Be easy or fiddly is if very strong there of little of. Trailers = listings Previews of. Tiger majors especially Europeans flattering is deceive once again. Ulfa = is Assam Article Aish ur tambola Pool Hotel affordable. Product = Advertise of Center in llc Reserved bbc Sport kid. Mumbai Chennai in India. Change point directly in intended am. Products feature stories content given regular basis. Demanding Midway = stop a Mortal Kombat Armageddon. Sorta blogger Isnt Timberlake tour dates of interest maybe personally. = Cups three points or Murray in swear laying. Logos available Root = favourite customized of Altador Adventures psp Gamepetpet. Autumn Tomorrow adding support automatic demo extras Guitar Hero. Focus am Culture Curry Matters a Matter Report Blogsmy. Member Windows is Movie Maker Join Date. Ted am shred Ward Datesalex or = Datesadam is Giveaway a Medeski Scofield! Thoughts ideas Jambase of = database interact albeit moderation pattern am. Night sore throat Everclear hangover mps. Flood Hans infancy subscribed feed is. Personally is endbut thats readers certain. Vocalist Natalie earned four = Aria! ------=_NextPart_001_0008_01C6FD28.AE728DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"theres"
Sorta blogger Isnt Timberlake tour = dates of=20 interest maybe personally. Vocalist Natalie earned four Aria! Many or = cases in=20 compiled of title having challenged?
Thoughts ideas Jambase of = database=20 interact albeit moderation pattern am. Save retirement lets.
Ones far = never a=20 expire lose value locations am redeemable websites is! Grinning = galumphing bit=20 stupid Clearly not Although am presented.
Location Australia Posts hi = all=20 newbie my of husband of amp.
Odd reason viewonly remote.
Be easy = or fiddly=20 is if very strong there of little of. Trailers listings Previews = of.
Tiger=20 majors especially Europeans flattering is deceive once again. Ulfa is = Assam=20 Article Aish ur tambola Pool Hotel affordable. Product Advertise of = Center in=20 llc Reserved bbc Sport kid.
Mumbai Chennai in India. Change point = directly in=20 intended am.
Products feature stories content given regular basis. = Demanding=20 Midway stop a Mortal Kombat Armageddon.
Sorta blogger Isnt Timberlake = tour=20 dates of interest maybe personally. Cups three points or Murray in swear = laying.=20 Logos available Root favourite customized of Altador Adventures psp=20 Gamepetpet.
Autumn Tomorrow adding support automatic demo extras = Guitar=20 Hero.
Focus am Culture Curry Matters a Matter Report = Blogsmy.
Member=20 Windows is Movie Maker Join Date. Ted am shred Ward Datesalex or = Datesadam is=20 Giveaway a Medeski Scofield! Thoughts ideas Jambase of database interact = albeit=20 moderation pattern am.
Night sore throat Everclear hangover = mps.
Flood=20 Hans infancy subscribed feed is.
Personally is endbut thats readers = certain.=20 Vocalist Natalie earned four Aria!
------=_NextPart_001_0008_01C6FD28.AE728DE0-- ------=_NextPart_000_0007_01C6FD28.AE728DE0 Content-Type: image/gif; name="lets.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6fd63$5ad165e0$dfa79344@JOSH> R0lGODlhmAGsAYf2AAsFAHoADgCAAHZ1AAAAin8AiACDgLa1x7XTuZfK5EkmBW4dAIopCaUuArQn AOwsDAtIABVHADFLAGoxAHNKAJ05Crk3DN8zAABUDh5UAEdcCmVjAHprCpRlC7RkAN1lAACJACZ3 ADWGAFR+AIp2AqF9AcGHA9qDAACuASWtAESlDVGZDnejAKatDrmeBdifAADNBivDAT+zC2e9DYaz BJjIDLq5Btm2DAHTACLhBjzuAG7dC4TlAJvbCsnfAufZAA0GMSUAOUcARWoBRXsATpcAN8AAP9YA TgAsTiclN0wZNW0ZNHQsOpkaRswUS+MrTgFIPxk9Q0w6OmU3QnE2SKNFSMNBMuY+RgVUQCZtTD1i QlpaTnVRAJ1nSstXRNRuQwOKMySBQDWNNl+AQnl5Sp6BTsaNSuB5TgCTPRmgNTqTRlmaNIecRKWd ObSbQuCXOAC9SSO0Q0q5S1W7R4G5Qau+SMPAOOTCOwDTRSzfODvkPmndNHLuOZrlSLrSQ9jXNQ0B hxgAjUsNhVkChIIKcaEAisoFdOUAhQAnjC0hgEQudFgUhIoViJYuf7oZft4ljgFIchg8jTxDeGkx hHQ9cqk/c8VMfNxLegBWfC1hjEZTdllgiHdah5FbibxlcuxecwCKcRZ0czN7jWx+dnyMe5Z9g7ty f+B5ewCfjhOSikWdhWeWfY2rhaqVebaqe+yhhgDBdyjChTbKg2bHdYbHf6G1gs3Bdei2cgDqfRjp czbYi1vbgHjUjZjcesnjhe3ZfQACwRoAzEAJs1cAtHMAy58AycIIyNwAsgMUuiQfwT0Sx2IrvXgp zKUhzssfveAWug04uStJu0A6xFI+x4I8tKNHy7s8stZMyQBpsipSsT1nw11dtIFVzqhszsJqvtRa vgR7sSVxsT2OxlqDsnVzxayMx8ODwdV/yACoshifs0qSw1idxIaixKOatseby+iSswCxzBzKzja7 u1y6xHK/u63BwP/7556UrXdyhvsACwD/AP/zAAAD//QA/w3z/fb4/yH5BADz9e8ALAAAAACYAawB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MhRoL2PIEOKHEmypMmTKFOqXMkypLKX ylrKnEmzps2bOHPq3MnzZsefQIMahElUqNGjSJMqXcq0qVOhMJ9KnUq16tSeWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnTvSqt27ePPq3YuXrt+/gAMLdsu3sOHDiBMrXsy4sePHkC8Onky5 suXLmDNr3sy5s+fPoEOLHk26pabSqFOrXs26NeDIsGPLnk3baLXauHPrLrxzt+/fwCGuDU68uPHj yJMrX868ufPnv3d+mP6POsEP1Qtin87devft37kP/xQ/vrt28wmxX9dePTz79wLVx2cfXn589O3J n7dvP3v99vDl91+A8tVn3XzrrTegQfzhJ6B+90EoIXn9Pfhddv8Mp5F6B87X33YHfZhgeSRiiKCJ JzKo4IoKVVigiSJWSGCKDZYYY4gihjjieDy6iBB/KILIkJBB8tjijgUC6aORTFbVG4dFwphikyru iCGQUy704oso6ggfkVJ2WWWPSH5ppIxgyhjliGBmySSRUA4Z5olqNomlmGLeiaCGGUGJJZdoHkml h2xCtOWZWo6ZJqKCkvmml4DqqGeZZi7ppX+MJsolnYna6WaeVtYZWZyRIjgghJ6qqCeqPzp6pXvX Lf+4qKmwpnpnoGH+FyeeQcoKaquE0nqhqqlamCONnxoY6l1Pcirlpj8eiyd4rN7Xaami/gotnFri N6ybh4Kb6YzvQcvrlYxmm6uD2X5rannUWdqlep2h+26w51IqrrkBSupqu1W6y22jhQ76rMGljqmt g/lyyy+D6G3b6bxZtrnmnmpttCum+Kp7McUfW0lsxxNnqqTBIl8s7cAzqjmpvSC3Gm6+zt5ass0s 6vvbxgAWuyyVB3pXrpkQn4fyoG2uWjLQJfbsM9Aui5x0yk1b+ynTOQJcsNMc60yzY+J9uCqs7k7b 4ZICA2tnrRXH3GvZuCLZ4doXiq02qCsv3SDc9Kn/yjbeZ1OocI6uOKlTbR5Dpzhf9rji+FmLXx35 5IcVTvnlmGeu+eacd+7556CH3lvopJcO1Fimp666ZGL9k8/rrwsEe+yy51OQ7a7PnpDuBOFeu+20 D4T77L4bBHvvt+dOvPLBG7/877c3X/xBxws//fXX9y598sIzNH30xTfvOvPVOx/+89aXjz5CvHdv ffTkG6/9+bSLP7xHYmUffu3JZw+/++PbX+76xz3tvW98yPseAmXHPuoB0Hf32x0Eh+e/A7ovePUr IPAkqMAB8s+D3eugAT8owgUiUIDOQx4DJwg/FAZQhSAMoP9wNxYFCnCDIfTe7kx4v/2VkIEwhCAQ /wtoQhgCEIhCLCIRT8hDAl5Qg0fE4Q4dqEIpvnAhM1SI/ozIxQTmcIVFFCIKbdhEBNaQikhs4g9L aMUeelGLVEwiGY/YxSyCcYoEdOEV78i9JPKxgfKTXxuVuMQ/BvKLQ+ziG/e4wQoOkpB7ZGKGVLKR 8sUvjUgUHx2diEk5ajKRT8zk8vSYvgxWMYeWBOUd/YjJSIZSjVhE4xvFSLwKJnB9ZSQlJPnoxkj6 8JRxfOVTTNnKCFrwgdXzozGN+UFFinGTl9ShI2MnRVsikpkL7CUUxwjHQy5Sm4DkJPXah0toDjGC OARe+7L5St3JUZUKGd0ieQlPa56QnOesZyHZyf/KBzrEioSs5j4FGsYnztGX6/QmNAkKUIUacqDm FOHzlAlJ9GGTkZhEnTh9GVCFLlOYDVWiLQlKxB8a8nsfXSIzAfrLgiKSnXhUaSIbqUNghtOIHcxp O18aRH/OE6Bn/CkoqVnI7dkRey4dYQzLKFNvprSPm8QgNu33P6mWdJ/wBCEx+WdSq+6yo85sKU8f 6lIW8tSUK6kk7yxa1YTOb6rKCyMFUzk/WdayoTa0JF15+Eno0ZGqSo2rUwfqVr8OVZ3lNOxXDxrR ZG6UrPqTnmNHaNLVWfaymM2sZjfL2c56tiHy/GxuXNMZAAAALKLdDWkrw4GSmNYkqY2tbBNi2tn/ 2va2tAUAUARQEN4SxLcCAa4Ahktc4g6kuME1CHCDW9zmDve4zo3uQZbr3N9Wt7fIje5zkwtd4zJX u8/d7nGtK96EILe3v8WtUnQ7kJ1Q9x/vTe5yuQvd9M4XvspFr0LiS1/5jte6/Z2ufgOMX+Gmd8Dc LS9+4ctfAf+XwfFdrYRpsuACP9jCCK7wgTd8YQ07uL/z5a2B9XvfDJtYxBe+b4j9+98SO2TF/50w ajZi4BGzmMMuVnF+OfxhDa/YxvZdiIsJjGIQ77jFPvZwRGBMYPUypsYpVnKDydvcIzcZxzwuspIL fF3y9vjGU/awb8c83iHvV8FJdjJDPrEXMif4/8FM3rKUrSznFJ8Xzk3WMkMUzOQx3znL9CWzcL3b kDibWc2H0bKeq4zlL8+Zx1YGMoS3W2I9FzrL55V0gN28YEvXmc5hRrRQRqfoNIvZxI8G9H4bHWgi X9m8qu40pGH8Xk6/GtQHkbGuKclg7HZ4yuX1tI4hjWBaozfEtv5yg3+cYWMDuNcdLra0J7nrapPk 17HecqZBHWwhz/rUXZ40obvLZ0APG8Th9TW59zxuRvvW2oKJBUtETe962/venAstvg0Db9Ds+9+p 67fAB07wjwCcc+w9uMIRvnD8FfzhZzntW3oBca3Ao+IYlzjGN85x0Wi846hteOYSDnCQm3wrH/8/ +VZErjmS71vlMOdJymNO85rbPDQsz/nkbs7zns/kDzjRudBh84c/YMTnSE/6SIB+uKE7fTFG14jS p+5zpuv76VjHS9GzDnBjPCfqXA+7bsAu9rLnm+poT7tMzM52xbBiIWqPu9xh2/a6R2bueM97XIih 9777/e+AD7zgBx9yuxueMYRPvOIXz/jGO/7xkI+85CdP+ckc/vKKqbzmN8/5znv+86AP/ecxT/rS m342Sjj96vjRENYTx/WGy4lATFvbptT+Hy5nXV0cUpJ/8OP3rIe97wfye+ITRPjAd33yg5983zd/ +c4vfkGA73zjN5/41Mc+840vkOtzv/vSH37/9ymS/eiH3/vaZ770zw/+8Ldf+dx3fVo2knum3L7+ eRG++McP/u/vf//BdxD6B3sD6H/8x34EyH8C2H8HmBAJ2IAKCBEPGIH6d3zTZ30JWIHfF4AAaBU7 UX+0N3u1VXu0l3AhiHsnaIIEoVvs1YIkOIImeH8F0Xu8RxIFGH8QSIHWt4AWGIEdeIHDB3/I939A yIEcyINEqH7mp33jN4Q9+INFCIRBKH5HaBAZmITUhhm5p4ItOHu4NxAux4Jg+IVeOIZduIJk2IUq SIbtdW01WBfZt3zwR4VPuIR26IMEGIcGSIdC2IPlh4N9iBAT2IQb2IHuh4UKqIF5qHx6OId//5iI 1XeBm7GFZliGYmiJIbiGlziGX+iCI2iJKHiCBkGDoOWGhIiDdOh/V2iFUjiAjwiBAeiEBuiIUyiI swiF6ld8FXiDULgQR2iEiJh+DGiB85cRlOiFZ7iJysiGalgQzciFoIh/S1GFuaiLdbiKUgiJfsiD fSiLeNiAVdiKFziB4biL4uiDDmiIp3iLFsiLshGGlZiGzDiPa8iGnIiC9BiNnCiNQEGN/+ePhaiI 51iIUdh/g/iNADiHrEiQ5KiOC/mPdYiOv5iQBXmD3viOKUiC0SiKJTiPZYiGIiiCnyiPoXiPQnF9 Q5iS1Pd8ceh9vAh93riS2HeH6Bd9FPl+2f/4h9Z4gOsniIfoij1phyg5ky6JkKnoHPyIEEmpehro HE2JHEtpEFF5ek+pHFWpeliZlVqZWqLXlV6peUGgeFs5lmRZlmZ5lmiZlrP1lWxJGWr5lnAZl3I5 l8whBXSJeVe3EaT4GHvpOW0pEqNminwpmH75lyARmLsHGTRYARvBmLnhmFkolsYoiia5OZApEJdZ EJn5D5DpmBXwmZ75mQMBmpdJmqMpmpwJmqeJmqnZmQTBmKwJm6bJmaNZGMWwOB9YmboHmHd3bbPJ mpqZmbGJmbVJm8R5EK55nJu5nMVZmqlZnMZ5nMaZduKQFtB4iRlZjzNImI1RErCpmQnhnJ7/CZ3j GZ0G4ZzGKZznCZ7imZ7QaZ6MaZggwYXNeI9nOIrciXgk8Z2vGZ7NKZ2z6Z4IgZ6diZrM2Z/tWZ7w 2Z+OpxEdmY9g+KDQoZrvCZ6YaZrJKaChiZ7KuZ4HWpvtSZsZuqDBYTmKqRPwiIwgWYqJOZi7x5/m aaH9GZ3JqaAk2qHsuZ4IuqMi+p7OKZ8fkaKduKL3uZ0t6hiLSaMzKp3/CaBOyqQZeqAfaqMwOpwD GpltKaSeKJK66XC8eaIjEaAUSqPAqaStuaGrWZpjqpoBeqar+ZoUWqA+WpxAag+I+aUuypubSRF7 OhuOWad3GhKwkaQa0aewAZmAmhR9eRx1/zphSrGoxtGobIEILUEVSTmVd6levSGhDHGpRoqnjNGR DyqDoahbkuqWxjgRnrobWoqPKpqpdpGbRFqSL3h/GkmGkIoYrYqd9oilp+oX9HerQyqP0PiqmLoY 2VmfW3oXcwCrGKGs+viqwwocy1ifXeqskAGtxBqP0/ob1SqtH4mtsVGPyQihw3qsjfGtIbmi4uoY nKqJyMiRt4quupqsHwmDt9euS5GX9MoQuUocv+oaB9GvcJefxRGwrQGmoPoUCCtwCiuosdewmmF/ zUGw+uqBKMqpzggRJWix4dqGR0p/Gxuh7CWxnOGgDUGvHnut65WR9mkRzXqxHSGrSpmd9/8qlSuo kZ64rCnopRDLEZv4sV5ostamsR7Jrce4scKqrmX4rxURtL2Kq0S7a2iYifvYsyCYsyNJj6KaawZ7 EZQppFNLtZVZrNuKszdLrr1af05rEctokmOLGSj7sWarnbMqrXVrjyurqke7tzJbryBor0Ibrl1L ssvqqn77EBKarIn7txmRlxwrsm+4sHPLonGLqlWxt5SZF437GxAAAY4buqI7urgFuaS7m3F3uqo7 ECdQEK17ArAbu68ruwTRurVrELI7u7m7u7brurBbu70rEMFLu74bu6yLu/8QvMlbvL/LursLvM3r vMOrvL8bvcKru7Rrvcv7vMh7vbxrvNL/C7yuG3bUu7zdK7y3i77jm77q277me73OC7/pa73le7zv a7+9q7z3m78IQb/ym7y2q73VS72vexACfL8AfLv6W78JLL8H7GS9wb8I7L7Da7/sa8AXXMHzu7/u i8H4270SnMEWvL7nq74FjL4FzL8nPL4VvMAKXMLvW78rvLydF8MdTMEs7MH9K8I3vL0crL8lHMDn O8MjHMIXfMQobMMpfLxEnMRMrMNNLMMYPMOtm3cbIcG8y8EvbMDai8MWDMQnrMIMkbsj3L5NrMUA TMZAPME+3MZhbL7Ya7xC7MQkHMXrC8ZwXMa2NTorDMbES8IJ8cDe67/Ii8UxDL5FfMMa/4y7f8zG a4zHQhzJTnzGhozHNnzEc5zDJuyrkkfHluzIDrHIl9zDfUzHZVy+LqzHZozEbAzKIVzKpvzFsWzC jYzAmbzFeVzDbQzKerzGQczDHXzLb4zJmgzMgGzErGzLq+zJT/zLdrzMpxzNP8zJkZfIMMzAgIzG yvy/zUvA/7vN0AzO2XzL4ou/+UvOs7zLmEzE3XzMdXzOwVzFnFfEz5vKPTzI2GzPabzO0LvAtVzL rezCWSy9BCzKzczC9ey7aYzI4jy9Ds3Pury6Uod3Eo2WplvREWHFGL3RHB06mMAUl0u0zxDSJF3S Jn3SKI1zHb2VKd3SXnEALi2pKz3TNP9d0zb9HDFdGhSX0zzd0z7900Btcjc91ETtWXq3DEH9GmoW BaDTCEKX1FAd1QFb1KQn1SVN1Xhp1SGN1Vzd1aKj1WAd1mI91nrn1XZH1kRr1nWH1iar1m791nAt FEMQ13Rd13Z913id12p20SstmXqtc72hDYKtDf8w2IRd2ARx2Iad2II9EIZN2IctEI/t2JFd2INt 2ZeN2ZW92JhN2Zlt2Y4d2pe92Z5N2qK92JGd2pL92Yyd2pwN2qvd2Afx2aS92Y1d26hNzX2nEZWN 2JIN24jd26Ht271t2gUh27493Mp93KL928nN2MOt2sCt2AiB3JDN3M4d3AtB3c9N2cr/LdzSbd3d rdiqXdwHtxPm/dvXrd2z7dzpnd3RDd/jXd3NTdwGwd3r7d72Ldz1nd/Nvd78ndj6jd3cDd/mDeDz zd7+jdh+jRGZzdnUTd7Fbd0P3trh7dmx7doTLtu0Tdvund4RTtzIvd+a/d/JzdqtXdrx/dzGrd4u DuIvXuEl13QuXuPAbeAnjt3yXeLMHeAsbuI7DuE/fuL+bdy3fd/aDd7tLd0WjuPLzd6gDeOrPd9/ KeDlLeBYPuDvneDyveBZnuP4reMKvuIDPuQ2buJKPuQFjuNM/t1sTuBW7rWEx9sPLuPqjeLljdqj ndunzeF6PuI8nuejHed3XuQqvtyQ//3aTK7oWZ7og97nAe7hkN7ZuP3ofx0cPi66fN3RDX7pDcfW oB7qiefppF7qeyHqU23qC4fqv6rqrv7qQycMsD7rtK4QbFbruJ7rwZEOut7rosXqXukOJ6EQb7dw r+DryB5wwN6oyd7szg6yyy6fzz7tyL7pGBvtpCUUnUvtsjE6pKq4UpmJPXu1+arb2E4aQGu3nTqy LyuD287tepGM8nqfLEhyu3q27ArvDHs45Yq35kqyIlmuh1uy565ypZq2SBu1CR+D7O6zBc9x9m6u TIuzZru2TfvwJhfxi2urwnrwHq/xHOnwGI/u+s6VNM5vI+8XDpDyLN/yZIEAq1HyMv8/8zRf8zXt 8jif8zq/81whADxfcS7gFTY/9HedBCdP9EdBF0gvcvwohu++7tTa8Pn+tArx9Aq3qVZLW92KtlO5 uWir9VJfsyoLtEr79QML7mBf9WefHFGp9Kk69VWr8PuI9mpf93ybuWE/uCxr9nxf1SjqjPKqohsf ki8Irmk479UKg0PqglwKkhuftZtb7qNqhljLpW9L+IdvuOvq8ZavhliL+IDPs4rP+bVK74Af8Jrv qgdf7xxvqqVRkke7+BDKq8R6jHmbt4iL747PrWcvjRHv79ept4bP+HFvrLEv8PmI+4Qbj9aq8XOf okzr/IKf8G5P9pr4iYk/kjur8Kb/j/v93onjvvuGP7JbmK+3X4lBa62gCPD0ubW//4zon/AmWazN b/nPH/rRb//T7+8oL3sLDxD//gEYWJCgQIIHES4sKLChQ4YKEzqcyNCgxYoQFUak+NDiw40HQ3aU CPLiyIsaMS4sidKjSJYmM85U2TFmQ5owS6a0ubLlzZMkO9ojWtToUaRJlS5lShTiU6hRNQKgunJg 1YlUqyLcCvNqRopYbWoVqfUr0LIJt3Klefal27AhzbJV2xWn2I9C49Jly3dszJ87yT6dW5jj4L47 Pe4VXLir2baIpU6mXNnyZcyZNW/m3NnzZ8wbQdccXXqzaM6oLasOTZk1YdOxZc+m/13b9ujXnnPf Bj239+nOvgmvlSqcN+imyYseZ97c+XPo0aUrp17d+vWk0rVv597d+3fw4R1iV9pavO3d0dPPZr2e tHbitAmSp1/ffuzcXnmLruj+s3+c0NNsPf16gm3A23Yj8L/zbrPPqMoKhA7A3zKjEDgLL3utPQxr U5C5+R4UcUQSl6qLvxPDgmotx/A6SSy8WtzQqxTv0okrHNPya6odJftKosdw/DFHIVEM0qSrInps ySSLdGw4HRPTyTe7ylqoRCyzFLEtjm5SDayfANMrJwP/ajIwkvgLMMzF0ELSpzHdLBDMOFO6kc3+ vJTpQJ66zCrO+CbSctD68HszQP+WjIOMNDLXlLNMv+wSE6izbnRzqkbfenTIMHV0qcb+FsUT0RTZ hLOmO9N0sdIGbSORS0T7/OvTPSfNdM7h4BzVzlo1vZXRWmm1lE5KedWLpzz7NLVXP5HV1FFCo5XW xEOdhasvtxAbrC5HszWTsUQlNWwvOyVdbFEliZOMysRmbRfTKF+KcUka00XSyLzqjWzVRaf191/4 Esyw1eIIRtBgzv5VONqAv7uQu4fPi5jghSteDmGMM9Z4Y44RJrFjkEMWGWSLSy5v5FYjnjhlAVm2 zOT7EJaw4Ajje881IE0Dq7htM/Zv5RXzwhlIKo07mGaUDQaaTw41zLk0ABVTemD/Q9tE2iWrU3Mt aZ0Ni3LdO0PFNlw1VWrJSmWDyrZoJsvdukfUWpQS7kgNhFHIIc8MlN5cwebTqqwrffpPkNAO+dU0 T+VV3G7Nthu2ThOFXG1nRyU2KsWS/Shyay/d2fBNd+4VJc7z7WnDLiW3tiKYWydq18rRXXPcY7Gu nK+4D6t99HJR90k4YXW3V7BzN3cRVKYP1a9G0wEPmtTjWUTXdfKq7jzTe9scSers9YRU390tNzZ3 xd/jvNHIis9+2WdhXT5rqW03M0/in+X6P9rXlp5OT9Wt9lptvetmXxuL3HontMyNDVvjmtL+3vQl eaWlf/iq1r7iFigokW54p1vg/8gQZ5774YZjF1paCGdDPZj9zIS6sZnMOrRC8KDQZDCkYQ0pI0Mc 5vBBNuRhD/+hQyCWbD/ke04JoXY06+0nQj5kYsJG9LxvvU1osoIi7jDnIQ1NsYpLNCLSvMip/EkQ IkEkYxlPNkAt/s13k7EdBOWTxcDdTIpKnGPZDMI+gZhRj3rUn4r8Zr68qQVvPkKRk5wkLLahDUzM 25vbrAg2dR1PcHDDFbDoJ5U9ZjKIy3pfJR8FvnyZy3uiE5+eMBgsVKkJTZfaHKk2JSsZCc84mqSl iKz3ud/5L3w2gpXj3hVAS4ZPdt9iXqxYNanOnQqUt7sinuzYRGiy8VipE91bVv9Jq2bKsoqlTNuB 8Pi+28HOXa7k5uQoVbYuRtM5H8uf5/ZmrmTFMi6NoRFW3mlBT2XTXr5coKgKGMkEzs6BERSjNdlV S4TSR50LrdAXGfpQiEb0OEaTo0QtelGMZlSjG+VoRz36UZCGVKQYS2hJTXpSlKZUpStlaXJG0VKY MmykM6UpRGN6U5zmVKfYqWlPffpToPbQDEElalGNetTO7FSpS2UqTpFqURQ8VapMrMJUrXpVrGbV hk3lale9SkuthlWssvlqWWv5BbO2dKxrZWtb3fpWuMZVrmRNa13teleZzlWvY8VrX/36V8AGVrCD VeheDXtYxCZWsYvFKDgYGxX/cETWsZJ17D8qK5DKUhYiksUsZ5+i2c46hLOXtaxlI1ta0YrWs6Fl rWkve9rQUnaym3XtaUk72dfO9rOj1axsobLa227WtqDtLGx969viqja3q3VtbXVLXOcqd7ekxexv lzvc0aKMRNR9rWlTS13aohaykA2ud6uLWtiiVyrpNW5qzetd7nb3vOItLXt16178hvez7mXvfvM7 3/vOF7+ZPS9489tdAx94wP8Fb3oBvN+Sxoa731VvgtU73t8+uL4Fri6BLTxbEO83xAHesHjl2+EN B7jBGNYvignc4hWjuMX0LfGLWUxjC5tYxP4V8IU1/N+OfcyzoPVwcnnMXPS2/1fHFeZwio3s4hJT eMRDlvGSoRxi/mK3vDN+Lo5nXNviZra3IravgwXcYDP/uMpn9u+WifzDhNbmvnOe8Je3nOT+mvjF uaVveYtM2z17ubUnrvGag2vgGFO4tWw+sqAZHOUPfxnIhI4yo5XrZh5HRxOtmnOfM01jR6u4yU32 s4IvLN9A1/nHhx61fkncYw3f2dONVvWCTz0ZWdvZ1bY29apXuN0hU/m7SOZtmsF8aNsCOtkDZq6q gUvm7PIazF5Gs5YpLV1LNxfWRB6zdU+M22bn+dI31ja2hbvsVY85rY9ld1LN2m54Z2bd8XYVYe1N HXrX+95lNc078v3vXz/xvf/Ehe6435xlByO33Lx+9rCrvdtxC9fc0+31rMt9bQLvW+NLGTR/H73r /uYY0zuONaB7bOOBHxjVGS4wofO88pNnfOMzh1CgFZ1tHXdZ5B9X9IRZLWiYl/rWXC50z6k96erS fKclOIpsbG5oik/7z0hWM6gpLWqqN7vVNs86yUXt5PC+2scAj46QhQ318SJYtZ+28rYfzeoV3/bs eP4z0fnMbKCDWr1KV/rPfRxptfO814jetadRPvQqo7zLjbb4rL+td9LyvakSVnaZqy1mJXeY6jg2 NuflnnlMI1vckPZ2xd1sZkSjm+zQ+djqTSN5prpe9jYVuA9hf3uUzv5+s+D/fe9noXvgQ9P3vg9+ aR4/aIJH+8zWnu5yIf7kHBdfq9tleK2tn+lES/vlScd99/k9Yo9LG+e5rvXQA+199HfVyTCvunOv X/q84zm16af/Utcf8fbLOtcmDzuVu1t/AMyp+7M4/SM6IAu78JOxyAtABlQrKxs5g4Ox0Quzc1Mw tWtAWjoFDDyjHtpAD7QY6QtBERzBtyKByvhAFEzB5CBBFtQuFXxBGHSKFrSMBZhBG7zBmopBHUxB HOxBH/zBmdpBIRxCIixCIzxCJIw9IFxC70hCJ+Q7JozC7XhCKqxCK7xCTZJCLWQ9LOxCv9pCMAzD FbIAMSxDM3Q3L0xDNVxDEjZkChxoQziMQzmcQzqsw68KCAA7 ------=_NextPart_000_0007_01C6FD28.AE728DE0-- From nozhzst@shawcable.net Tue Oct 31 22:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6VD-0003Xx-9J for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:56 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf6VC-00038I-Jc for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:55 -0500 Received: from s0106000d5656849e.cg.shawcable.net ([68.147.167.223]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf6V9-0004cE-Lq for capwap-archive@lists.ietf.org; Tue, 31 Oct 2006 22:10:53 -0500 Message-ID: <000f01c6fd63$5ac7f000$dfa79344@JOSH> From: "face" To: capwap-archive@lists.ietf.org Subject: Mars Date: Tue, 31 Oct 2006 20:10:59 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C6FD28.AE66A700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 ------=_NextPart_000_000B_01C6FD28.AE66A700 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C6FD28.AE66A700" ------=_NextPart_001_000C_01C6FD28.AE66A700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Boy Small Town Girlkellie. Michael Cuddyer pm Thursday. Pets am Saints = row Star. Relying ageing Canadian. Dvd Svcd vcd authoring Pinnacle Edition = including or Avid Xpress in. Deal of District city imagine lineup. Title internal led wish change = point directly is intended toolssign. Martin Pipe dad Boots brothers am. Niall known Slippers surely teaming Martin in Pipe. Colour green how do we this View Public Profile. Check yours wait = youback. Divine Comedy burned religious grounds Queen Elizabeth censored parts. = Born Livelyrics Ukbadly Drawn boy Small. Majors especially Europeans. Neopia cover issue or full am ofhelpful a. Rodeeljas homepage am Find by = Mark Senior Junkie nov. Planned while whenthere they posted herecute cuddly ummm. From website = whatever in takes fancy Iconsfun Imagesshop Catalogue Contains? Boy Small Town Girlkellie. Weeks lately ive determined of folks needs a? = Determine andorvs actually is. Owe dillute or mediumi publish blog expect nonmusic Vegoose Torrents. Launch dedicated channel vacancies of several. Aug comment in login comments rate or! Join in Date jan of Location = Australia Posts. Relying ageing Canadian. Puts hardly bettered season am lay lad in lead. Extraction painful pair pylers job am guys in. Vice President Managing in Robert Rosenthal position sensitive = gatekeeper. Michael Cuddyer pm Thursday. ------=_NextPart_001_000C_01C6FD28.AE66A700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"big"
Boy Small Town Girlkellie. Michael = Cuddyer pm=20 Thursday. Pets am Saints row Star.
Relying ageing Canadian. Dvd Svcd = vcd=20 authoring Pinnacle Edition including or Avid Xpress in.
Deal of = District city=20 imagine lineup. Title internal led wish change point directly is = intended=20 toolssign.
Martin Pipe dad Boots brothers am.
Niall known Slippers = surely=20 teaming Martin in Pipe.
Colour green how do we this View Public = Profile.=20 Check yours wait youback.
Divine Comedy burned religious grounds = Queen=20 Elizabeth censored parts. Born Livelyrics Ukbadly Drawn boy Small. = Majors=20 especially Europeans.
Neopia cover issue or full am ofhelpful a. = Rodeeljas=20 homepage am Find by Mark Senior Junkie nov.
Planned while whenthere = they=20 posted herecute cuddly ummm. From website whatever in takes fancy = Iconsfun=20 Imagesshop Catalogue Contains?
Boy Small Town Girlkellie. Weeks = lately ive=20 determined of folks needs a? Determine andorvs actually is.
Owe = dillute or=20 mediumi publish blog expect nonmusic Vegoose Torrents.
Launch = dedicated=20 channel vacancies of several.
Aug comment in login comments rate or! = Join in=20 Date jan of Location Australia Posts. Relying ageing Canadian.
Puts = hardly=20 bettered season am lay lad in lead.
Extraction painful pair pylers = job am=20 guys in.
Vice President Managing in Robert Rosenthal position = sensitive=20 gatekeeper. Michael Cuddyer pm Thursday.
------=_NextPart_001_000C_01C6FD28.AE66A700-- ------=_NextPart_000_000B_01C6FD28.AE66A700 Content-Type: image/gif; name="important..gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c6fd63$5ac57f00$dfa79344@JOSH> R0lGODlh7AEAAof2AAAADXoOAAKOAH+HDAEAc3MGcQB0dMC9trnhxqnX/kESAGQgCHcrAKISAMIp B90XAANDCRU/ADo6CF0yDYxJAphLAMw/AN80AABdCSZcCUdRA1xRDIFiAppcALxcAN5TDQB5AC6M AD51B1eDAH1yDquGAcSOCt16AACbAReRAD2uCGGjAIycAKelC8uRAOSkDQC5BRfMAz+9AmrLBoDK AKfKALfKAOm2AADbDhntAEjmAGnTDnToDZHlALzsAOrVAAEAOhoLOkUAO1ELPoQARpsAPMsOTNgA RAwuQCoaS0keOmIZS3MaMp0VSrYkONgVQQA4OBhDNUpKO249PIVGRZ1IMcAyONQ9OgFZTi5uODNp QGVdO4FbAJ5mPMdZStxkOAdyQiiMRUWLSlpyPIF9SpaHTsVzTOBxOwCkRxauNTGjOVeSPYCoRJyT PMSnM+yUOwC8PSixMULDP2i6RYfBOqbCMcHDP9HMNw3fRCjYNkrlPVnSM4zSQZzqOcjXN9vgQAAA iyAAhUsJi1YBdXILfZQAjrUOiOIAcgAXdxMshUgggVIpg3UpiqsRf7occu0eegpJehFFeksxeFI1 gYpLhq5FfbpIftlLdwBsgitWhU1ghFZYjIJmjK1ejMZmf+BXhgKKeRl9hUqGjmKBjYx/daSLfceO gdGGggCahSGlfz+WgFGqiHecgZ+hcs6qc9WoeADMgie9dzTJcVy6cYjLc5/MgLS8cuLAhgvcdiLR hUbggFXmeXTUjKTnhb/phNXrfQAAuh8OtDUIxFcAtoAAupgFvrYNvtgDugAbxiYfzDMbzlomzHMk xpUVxLkgyOgVzAA7siA4y0QzzVFOt3I2t5tCzsZNvOU2vwBcxxthxTdlylhdtXdUt55uyc1ovtJV sgCIxhWKu0CAu191uY12xpeKxMN/sed8zgCeyCmcsjKpt12ZwnulvJeZxsetweSazQuxyxy8vk69 uVO4v4nMv6K9xPH9+ZuaqHx2e/8ABA3/C///AAkA//8A+wb/+//3/yH5BADz65UALAAAAADsAQAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXGnyn8uX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqPcqyqdOnUKNKnUq16sGlWLNq3cq1q9evYMOK HXvTqtmzaNOqXcu2rdu3cOPKnUuXrN27ePPq3cu3r9+ZdAMLHky4sNu/iBMrXsy4sePHkCNLnky5 smXDmDNr3szZqeXPoEP37ZxWtOnTqFOr/jpxtevXsHGSRhu7tu3buG9/2P2PN8wPvWMC303cd/Hh x4m/VL68uHDnNYH/Ft47OfXrLqVnp55ce3bo1Zk///fuPXj36tjDn0+vvbvv7dOnr5dJHrx68d/x 62de/v7x4LmFJt1725U33EwGxtfcggDC16CD9MknoU39tddggv2xB2F9DGKIYIIIKrjciBXSRN6D B+KUIoojUihieyeW2OKMAerV2oAsXgghjRGKCOCJO95koYUPhojdijoW2SOJLx7ZYoZIZpijgkgG OeOKOKqYpINS0gikkkp+Cd9sZwGFI5BEQukijwVSydOQTwq5ZJRxrsnklUamGaKYTTopo5Hm1Skn kVzK6aWVYfrYZY2PZaknfOvhd2iEYkpq4p0/WvfbfHRCqumkX6qZ5HlZgokip4le2qan/1E6qX8g bv+IqHuKMvpZqbhuaWKsYCJn6XeGPrpoqoQGimhz4rVqJZzLCqrhdcWa+mOdw45q37DKQopslVMe aytYNxaqY7Sqyuqqt9iOy2Z6rBKIpaFOrstsr872GV+20hqrb7WtFpvujqVi+uqYZBI2Labvaskj iHz6eO6+8Aoa47oOd8trwhpK2XCuFSOsa7kBk/usuAKbK1PBVpkJcKWAmgzsywzH+9zM3iZ6ccfy HgnjyIpq7HCVDW9Kc75FAl1zrDuX3C3R3yamnIGVaoovlO72mK3PL34apNFeak0vewR2/R/U5drM c8unTs0dpV6XuJ9xSxbdNF6tiVbt3HgnhvJgduf/7bdke1P19+CEF2744YgnrvjijDfu+OOQRy75 5FnVTfnlmMsWOERA5eO55y59Dnro+cRU+j+inz6T6KbD9DnqqodO+us00S6767Cnnvvoq+s+u+m8 o36T7bC37nrswr9EPPKxI7+6Tcszvzvxxzfvu/Kszx5879tbD/z0Mlkv/und3z7ZIYpJ3zzprUv/ vfLwr1887u4fj735sjufPP64hw+/+eSDnupGVz779Y93BDSe8PT3u97db37xwwkCA1gT+ckvfBcs 3QCZp8H+5c+DwdOg+xj4t4noz4L7W6AEK5jCAK6PhP+L4QD5hz8GOm+E/4MhDi/4wRwqcIYRhF7t /4zXwSAK8YBHNGIKPei/GTpxiU+U4fNQ+I/NjeSESHzh8ISIQi0mEYm3w2IMFTjG5EVxiE1sYfvo 97z9eZGF/kvjG9G4RjgqUYxDPGMH61fEMOYRjFZ8SOdCmD0z5nB7ZayjH93YwDgS8ZC642H1EghG FVJviT0Eog97+MgaYpKMiVQhI1NXwPZdz5NqdOQUfehCJvbRkG0EIgwzR8lFwvKBIKSdJil4S/aB EoCMxOAl/5jLPZYRi7L8ISdBmMpPhhKZrNxiGitYyFMyUZmGdGEhg3lL1iXTmSWUyDSNyMtr3lB7 3+zlMdsoyk9qcov1YyP/oGlLYLaTmePTITvlmf9NaSpyn1IE6CR5eUbg2a6cnKTg6QIZknEu85WJ xKE95xhRMvYRj+DkJw0JqspeQtSL8XzlOzu6TjVCFKAI/WUzVRrMXTrTpfM0aUwY2pCfqK+S7Iun L5cJSw5CEYO4RCUoMcrROI4UgrXc6TzJt0GLsvSlTYXiSYHqS3129IQUnapWOwnBe85vlpPz3fV8 Cr7a6dKUH2XqMBvpSlJiEquEJCoisSfJUip1mHXl3lxzZ04RWpOu11TpOfUaU3oOla90RWhSDWe5 zDn2sS6h6UcgS1nHStYjlc0s5S7bEc2uhrOgLYxnR0taxDW2tKAJrWrbgoiroPa1sLXVRAQQE9r/ wsS2LsGtAHbLW96+pLe5lQluc9vb4u72t8ZN7kyGa9zbNre2wE3ucYOLXN8SV7rHne5vnavdmgC3 treN7GrHC5efMPcf5w3ucKmL3PCuF73CBa9N0ste9W7XufVdrnzzC1/dhne/1O0ufNFLX/3el8AF ji1pW+Nf/273vet974D/S2H+AjjBtHXwfyVc4fiCV8MTPnCAQ2xbDuckwv8lr4rbApQGizjDHrZw iPmL4vlWGMUgfvBNTDzj/r44xiM+L49xUmMZK/jINHFxfWF84SQrF8A9brKIfWzhDD+XuwZ274+h XGL2Mrkn1r0xkkvLYC+bOb8JnnKPi5xk7grY/8ES/jKR2TzhEn+Xy2f+8p2JLOUV+7k0La4zifdM 4jZDecZDpm+EvxvnKNt4ysU9M54FTeUOP3rLY85bJfii50Kj+dBrBrKjMe3pAUPYyIb+9IjVXGMh q/rEoM60Zuv25hxj2NWHpjOQW/1h6KIa0WLWcod5jV8CWzrYW/6zsg32amCrGcFd5nJ3E21pOfc3 0tUlNLTZjONdY3nRbp7ztBkt3mWbWy6yBty51/2WdEeG3fBWibvnTe962/vejou3vvfN7377+98A Zwm+bUOHgRv84Ah3d8AXzvCGO/zhEI+4xCdO8Ypb/OIYb2jCR3uKjY8m4yAPuchHTvKSm/zkKP9f i8dXzvKWu/zlMI+5zLmS8prbvN+0uLnO/z3znr9850APusZ9TvSNC/3oSE+60pfO9KY7vSlFjzrC Ke6Hp1sds1LP+rcOoPWue50oVw97QqRg86+bfcxiT7vQz8722Kr97Tpvu4JdQBZ+yP3ueEcN3Pee csq1I++AD7zgKcv3wncGF4ZPvOIXz/i1D/7xkTttahCyE8pDHitHh43lc7J5ytkdJ5+HTegzHhQA mB4AYjH9S1DPGH643u6h/0foXf+S2Nv+9S55Pe11D3vdy973vo8J7mmf+98TP/e4r/3uZ6/84xe/ +bWP/k+Sb/zjBx8mwE++9ZHv/Oo/X/bfNxz/JvrCerKo3iXlT0zswS/937ef/d+H/UzWz3zsv//5 26//+u3vfvzXpP7sB4A8IYC293/CF335Z4DF93kCmHDpt3rnd3r/EIESiH4UGIGrBxOox3oceIET WH4VOIFcQX/8x4DhV4ALOH8HGH7wt38m+IL2t3/SJ3/gJ4Pxd4DDR33aB3882IL353/8V4MB2INB KH8keGQT8YAiiH5LyIFL+IRMCIJPmH4byIQa2IRRmIFQWEWuxXlXoX28B4QoyH0MSH09OHs7yIJD CIMz2H1rmII00YA06IPM131H6IMygYZlSHw0uId5iIAuyIVBp4RS6IQiKIUfqHqIWIVXeIgW/6iI VriBp6eE5VYQldeFQjiDQHiCCKiCRSh8ZqiJQjiGLGiCo6iAZ4iHNQh8f/iJahiHdAiH9xd8bmh3 R0eIGWiIjOiIWRiJW+iEu8iIwKg5BnGJxdiJgMiK71eHnth+RyiDpmiEQViK/jeHrZiKAGiNRHiH DWiAzJiJs4iDB0h6P/GAheiL59iLUygTIBiMWMiL7+gV1jiPPDiG2kiN+LiN8TeHgViCyveK9SiK sSiLrsiJKxiDyNh/oviM0whbdTOJj+iLhxiCEImIWziFHQiJ70iRM4WJZXEQtIiQydh7y8eH18eN yniCu/ePJxmKw/ePZHiQxod9/Mh9AOmSoP/IhzHpfS1Ikvp3kKbIbqOAEWBBiTdhlHhng7ailFGH lDXhlHfHlLkhlaPVeFZ5lViZlVq5lVzZlV75lWAZlmI5lhR3eWZ5lo+hCmhpcGTZlqq1lnAZl3I5 l3SpG3X5Em6Zl5d1l3yJG5LHFB75boGZOHq5EmNWAUeBmKihmH0JLhIBkTEBlR95jJRheYzpEpcZ E5n5D4ypmBXwmZ75mS8BmpdJmqMpmpwJmqeJmqnZmTCBmKwJm6bJmaNZiVHRDV1Zjlr4OLPJmpqZ mbGJmbVJm8I5E65ZnJuZnMNZmqk5nMRZnM/ZmF2RhLnIixXIkYAxmI+BELCpmTXBnJ7pnOH/GZ3e uZzQeZ7o2Z21qZ7HeZ6IWZhsUYjDuJuGeDLa6RjcSZ6bKZ7IuZrHuZ/uCZ2qSZ76GZ3dOZ4G+pqC CJ9oAZnp+IjnVxOdp27FOKDoqaCYaZrtOZ6hyZzm6Z3KqaDgKZztmaAMihK62YjweJF4o54E6pwf +pwciqEBSqAuCqO0OaI5CqMeWlrN0DjUqaK7uI4suqAEcRmu5aI9aqMCGqMluqEygaD8maCdWaLe eaJpYY5aeJ0RapQTKpgGMZutKZ6+KaMZipoWKqatWaWy6ZtiaqFrKqBPOpxY2hJIBqA+gaefoafS mRR/aRRfChmWmZipwZh1WhJ9mqiTJ07T/3mfmneofZeiT9mRlJkbkNp3kJkTUPmAgdoYFcmlWyqB FjcMl7oQkjkTm0qpligZWhqFD2qbpQpwkmqFEymJEAqBuogareqI86moA3ed1YmFDyqMqcGlGKiL Eeqr9zafuTqsRXoa7tirtKqs9cas6BisK7oa0aqO00qtlsWotLqI6ritS9ipj0GuHxiZRhqrIZep RAqMFImB5eqoieGgwGqBich67FpyqKoU5vqo+yqrRXGq3lqwRfGnjPGvXhGwjkehq3oXDHtxWUGw qkGxBut2j+mu6roTk2ix/WqflYoUu5qIsBqxEDerk9oTHksTKyuyoBquF+uANmGv9YmLuP/aizQb kc+6FEPKoi0bs5KThCFIn+pqkbt5hfIKj0Oqr/SqmyNrhSa7c0irkU0IrJRIhRJokZKYtdkZskYx tLsatXF3tOsorldLtFr7i137sEnhjkcrtjdntGVLtB87tzD7qkzrtV9LpFsIt2U3tLiakXJ7tBWp gcYKgVDbtD6RqcaqeiUHDX57pELxs3VLjGwrssZIERkQuQs3FJR7s5kruUpBsZwbbxwwWUALqKVr Eamrup0xlPzaurK7Fwg7uzqxuhZxAjGhuyfQu77Lu78LE7orvDLxu8BrvMg7vLvbu8KrvC7hvMG7 vL77Es77vP9Qvdgbvc+LvM3LvN3bvMv/e73ZK77GK767S77TW7zUm7zaS77gS7y4KxA/gb3XOxPQ S7zWe774m7/8W7/r+7/mi7/e27/+m7/V67/Ke8D3S8AAbMAJPLwDvL0B/L8HPMHWO77UW8AZvL8D 7L0RrMG2KxQJzMAavMAgfML7W8IpjMAqjMIpDMHqW8AKzME0UcEgDMMjzLsyXL8VrMMZPMM/HMMb fMMXvMIhDBQjjMImXMRCbL8vPMTE68NMbBMLDMQ87MRD3MM17MRSrMNdfMXqe79aPMVQzMJh3MJH LMIbnLxoTMbf28QmrMUw7Mb2q71WLMVPvL3la8NyzMQ+/MfoO71zDMb6S8hlPMhRzL82/yy7dfPF xdu+ZVzHhRzIRkzIOLy+H1zFcFzD7TvGTRzEYAzIlyzEo6y/SXzIJOzIuhu/FDHFnuzJN7HEp6zE O2zIBEy/VuzCswzLlezIlgzKhVzKAgzJ9EvLSbzK8RsUvpzHlYzF/SvLppzIRLzCePzMW5zF1/zJ g5zD2AzLXkzKqEzDAizNaTwUSxzOkXzLzKzID3zLEHzOcUzN2WzAnDzMANzHZ6zN1ezBk1zME8zP 71vOaozJwZvLi1y+6/zMEYzBeqzAxJy+zTzDbEzQ0tvLxsy948u96FzCC73Q4SvQIB3SIj3SJF3S Jn3Si8PKKs2Vm7DSy4bSMB3TMj3TNP9d03hRDzad0zq90zzd0yjt0kDdWT4900Fd1Bkx1ERt1Eq9 1Ezd1E4tFUgt00HdDk8dEVEdFFkQs1W91Vzd1V791Qlx1TDNWa2VEi0A1mid1qAl1iH8AJar1nAd 13I913Rd11pJWUrA1vlm10Gt1ybN133t14I92NJ5FvcA2IVH2CKN2Izd2CZb0nYN2XUt2XT9D9pw 2dpg2ZjtEpn9Ep2N2Z3N2Zft2aBt2TAB2qE92qQ92qgt2qrt2p/92q0t2p5d25sd2qYN26e9262d 2rWt2a992rJd2rSt2zOx2ZzN28Kd2bjN3KWd2U39E7id26Yt29QdE5+d3Lv929jt29v/zd3Ybdva Pd3Fndvebd3XLdzi/d2+Td7hbd7H7d3pTd2xvd6/bd3T7d4kPRH5Ld7Zrd/Znd7NLRMB3t/f/d7V Pd4EruADnuAOftzwTd7M7eD6fd/avd0BfuECTuEbzuH9Hd3SrdrE/d+u3d2pjdzNjdzwXeLAfeL5 jeLDjd71jeHJPeHATePOjd8PruImvtrnreENvt4TbuAkPuKKveP0beA1Dt7XLeE8vuQ0EeRDzuQt DuUKTttBnuTzPeUSDuHy7eNAfuA7buMWjuUIPthkTuYdfuVKvuYbXuFSvuJtbuM/XuZNrtzhPeXv 3eAZHuZffuF9ruYrbuU1zd8wLuK8//3k7f3ct/3ciS7ijB7cVU7fLa7maX7jUs7jAz7blG7cd17j jm7bT77a4J3jOX7nvb2ucO1yFQ6mc03Zjh3reXnkIC3rtn7rV0nrur7rj4frnMvrR+zrkQvsxF7s xn7smSXsyr7szN7szv7sUI3s0j7tPwft1n7t2J7t2r7t3H6o1H6xtUu73e5w326wf/m5/jruDVd6 g3uU7Ji19xqJgFvuGGvV6dqtOPG08omtIKvuI7eR8Vqz996t5yitievvAQcUuTqudmu4gnutJIvv 9P6r8Y6uPYu02JqsOzvxnhWkDO+sSImuajuvCC9yVJivoIvyUEiz9VmriFjy/56wgP/NBGrXGDBv 7VR98zq/1Bzf8z7/80Af9IlKBmSgGDsvckRPBkdPlkm/9CCXC2dB9FEh9B6X9FTfl0VPFk6/r1dP c5Ha9XQpeU5ZheiOssW6sey4tyn7WGGH8mOfrRtLsPOO9iyb9vmu8ZqKuRhP93af92v/92RbG6da cyj79hffiBQrmamq8HnxtIGvovk+s2BvjvGahYzbgfd+rHEf8NGqiGRftTobql2K97UamZSftFvL rJBotKuPr7c68O4K7656rJxv+hkZkRfYjq8vt7kfuK7v9iof/D1X8RhPrsQqrDYL8hnv+sR6tg3f ryEvpA3/+SefrZi/99bJtxuptNz/z/rS36yE+64jb/HY//kML3Vuy7Wdr5EP7/zKL5EC76B2/6rz /+7V3/3VubTcGo8kK59UCxAA/g38J7DgQIEJCSo0eLBhw4MLJRqkGDEiAIwWK0IsiFEhQo0IMz50 OFEiQZQpVa5k2dLlS5gxZc6kOdPeTZw5deZE+bFkSZ8+L4I8mbIiSJIkkRL92dMoU6EWQ56EmNTk UqEbn04NKlUpUa1WrTL1elXr0qZni4Yc29WtxJ1x5c6lW9fuXbx59e7lW9fj0YsjHXpcmHFox6iI uRJGnNBwV8WMRUJmXFVxT8OTHxL+i5bz2quTNYtu7HToW6WdMVN8DLa06K8cYVOt//z4c2rCfXXv 5t3bd9+awYUPJ17cuEzZx5MfZ+5y+cznLaO/jD6dbHPs2bVvTwmc+3fw4U1jty6+pmTi5cfTRL+a uuHf8eXPp1//pnn8+fXv598fu30AAxRwQPn8M/BABBNU8D8CG3TwQQjtQW5B8NTDz0LmlsNQKv4y 206gCEMUcUSchKvuug+fAuw7DFckj72YXOQQNJg2hI66GNOjcEced5TxwvxaDE/IGqVjaUMbJ3RO vCR7dFLBvhzzsKPXqDRqM9YEw0owLWubEjPXVMvSM9YCy1I22zJTbTTSbGOzSxfFBKxMM98caTM7 rxwTto0ka41OEEkUdFBCdYLMNf/PVsoqNIbMYovGw1rDaiKOPnoLxbSmgurR0xwNjdOzwmI00k7R KiqqoxpNdEqFCnX11RAPPWwwVrXctK1VR1VJzls5nS3Tr37N9FRQP0s0svGkDPW2UVMtbSxiKw2T LWNng/VabPEyUdNZEyu1V1NVvXRWDiUFSldLfbUM2LWgTTfaXOF1asVx313UVHCpmhTf1GZ88l+A tw122Pa8tJPLLuvkSs/TKmvTvZ8cvq7aM1fDkjbK6qzUYLKM9dJZjfWFWNpOccvK1oBTVvnJJotU UuWWF4x5ZZprttm8mTOkOWcEeb75Z6CP8y5ooos2Gr9sk1Y6rqObdvpp45aW+kH/qGtu0mcFsV6P Qq2r9hpnTHet8UtIFcVTOX/1RNlJC7X+8Ug111wzuBO/9nro7NwuW724db4xbK7/bu5tsTveeri6 p1Z8QBMd3lPusCzdE6mCVaRUJH7PvQzyNMlckk0rR+48zbPFbFdcLAGttWIwId+KWMA5Kz3iwjC3 G+ooL1e34Wmb0nViUCm3XFV2w/X9udjIXZf2YY33PTDL402W2zmVf31g0+i1MmODFvfeVXebpZhy c50Hvq1qRa53d8mRjxa95e1djPutqrJVWeDN77bKcmFXFFGKxU1L3yNggej2u3EtDE3zAk2/joUi Z4VPgsxbYL7Wg6vi0S97+oJW/7t+tz8NeXBvvctYWW6HO76YrjCsQ5ZZ7mQZ7MFPYunLn8TM9DiF VXB+DNtcmPx0P0idjHWy21j1GAiWL1XOYhsM2aZ6WEAo9mZbLzvh51Jmo65VUYtVzB0Vt7jCnZ3n i/mJYhnxNkY0plGNa2RjG934RjiuMYn7yeIUvYg2JuEojnt02hn7l7bX+ctbW+tMcrJYHsIdzkh1 LFsDiag9/plRkpP8jd9EpsfYYfKPgRxcjgCpyCOBzYqbdMyn+HhKq3UOc6674GtKGbq5bcx2brrM rX5Iy5NVqVYRSx2tegnGpNwJdDYkJe0YiUpkvqSLz6seJI0nv4ERk4IzmuCqSP+GQSRGT3PNKwvI 1lfEN5GJI5QkZzn1kpIVeJKZtvQQDE1SMeyFC07lYx+l1gZC+HUMiOubnjfr+T93kSyZAwXPMlFl QQ+KxXBhgyYE+9mswzXzfwp85wdJ2Lviia2D1/yHOT36UaY1TkaUWZ1EcyhDNT0sMiWd35gMucMj tolZSGxnSgGoy/LJKae6JGhPs+NHn7JtlDwCaVFBGtSntYeTSGWq0Yz6VKhGVaoe1Q8FmnpVp91B P+zAale9+lWwcmeqYyVrWc0Kq7CmVa1rZWtb3fpWmJxVrnOla10NCFe85lWve+VrX79mV8AGVrCD vY9fDXvYNBJWsYtlbGMd+1j/yEaWaoilbGUte1nMZtYlkuVsZz0rKM2GVrQq+2xpTXta1KZWtasd 0Whd+9odsfZB55BtbaF6WF3AVre75W1v22hb4Ab3s74lbnGNe1zkHgioyR0jOFYmXPoMBxzTdS51 nfuP6w7kutZFCXW1692UcPe7BPFudrGL3emel7zkBe943Yve7KZ3vNatbnfhm17zVje+9Q1veblL X5W0N7/dxa94vytfAAP4wOzdb3vhe1/+GhjCDO6vebUb4AYXuLzH7YuF44ve9VrYvupdiYhBvN4T q3e7HyZxf9l7YRjLF8QeZjGJByxj/IZXxwEuMYpxvGMYj/i8HuZxjI3MkgFf/9jEKA5yjYnsYiET GbrzEc6Th6ziFu94ySbero+xjOUuL/nK9SUyma9s3y43Gc1jbrGIuVzkEH+ZyVm2cZatrOQj93jO dI6yju/85CTbmcN8efB9jbxiN1N4xOBN85cjfGgVy5jN/I2zmcUbZibfeNKL1nCg9/zoP2MYwYz+ r59x7OAg0xnVal6zkAXdZgZ3ecqgjTOe35tqVbsa0Szeb55zPOc0U9rWmI6yk1tN7FQLe8+C7rWu 4azsO7MZ185G8rP9DGQ7O7jGF541iVp9ZlxH+9XgdvSik83qIzc62LYGdqaPPe06v9nasKZ2n8XN 6zzDmc/TDrSx611neHe7kv/BuTSj0Yxq/0o61rDecIh/3WRtA1nApm44ug3NbFHrd+Il/jGwO07g UVcc5O5W8ILDveps09jNIndyqZn7cpjHXOYzp3nNbf7a5d5cJQLnOW90/vObn1roXE54oyMt6ZKv uuXb1riooXzxF5vc6edut9S3nW+gY9U7H1c3tuP9YTHTO9f+1vSr8+vv9xqd1R9PcdcBHnXn9lzu DSp3ralOcjC75OplDjfD+w5wo69bzn1/dK2h/XYvz13xAao7u1N+4HUjWs/jdve3h6zwQqfb3EfX 95mFjWlA81nWiyc9lS9t+S3HO+rL3vu87S5t1BvcxwZP9LeR/uLQyzvupef/vW/KLmcxU/rzXhe7 vNf+7s3/PvCDP37Vff36Ofde+ru5sYCVTmoEHxzzj5+81C/O9NdrHPxXz7yn+61wotd3+tLPevvd /374x1/+86d//e1/f/yrtcOVb7uBXZ7sTlO5Bnu6iVs/AzwttEM/VxO7u2M9j/Oy8zpACfSsTcs3 8vM0Bvw7CBS83ZtADyQr6YK95eO3kmtARQs9zoO3/FvBzSI0S1s4/nM+E7w2Tsu+DwMsE/hAHWSa Fyy+BcRADNQyCBw2lNjBwWIHuSMOtEM8QzM/toO8kTs3sGNBKoyJnGsaI8xCwTohLexCc6pCMEQq L3yVcBjDztIEM0xDNVxD/zZsQzd8QziMQzmkDyVoEIyYQzzkPY/IQz6Uu7/oQ0Dstj0MREIUrkEs RES0LQCwqzBsREd8REiMREkcqESsxOCaREzMxMriBE3UD0v8RNnqRFEcRVIsRVM8RQYBxbloBlVs RVd8RQBBRVkkGlisRVu8RVy8wlncRV7sRV/8RaDLRWHcQmAsmlzAxGFMRmVcRu/5izs0rWIkrrkR Q2asRmu8RjiMRm1cEGzsRm/8xh3cRnFULnAsR6m5AnMMLHRIR3ZsR3d8x8EaR3mcR3q8G3i8R2yp R30sKHzsR3/8R4AMSNLbR4IsSIM8SIR8GoFcSIZsyFeRAZ9LSImcSIrUDu+HvEiMzMilqUiObAmN /Egp6kiRHEmS7A6QPElCK0mVXEmWbEl9REmYjEmZjA+XpMiZvMmQqkmd3MlixEmf/EmgLCyelEhj GMqXDMqbNEqlXEqmbMrkugWojEqp3DmkrEqrzEinzEqt3Mp/oQSudKOrjMmvHEuyfL+wPEu09Ee3 0gO2bEu3fEs9KMvbSUuQlMttDAS75EXC4gS6FLg94gTAzEtZBExOFExUDEzDPEXCTEy2GivCRMsR uEjA7EsDZEzLvEzMzEzN3EzOJMhm6Mz5c6xUoEzgAk3TPE39I82LRM3NrALWDCvVXM3XlMSAAAA7 ------=_NextPart_000_000B_01C6FD28.AE66A700-- From uzeftzh@shawcable.net Tue Oct 31 22:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6VD-0003Xz-L0 for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:56 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf6VC-00038Q-VY for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:55 -0500 Received: from s0106000d5656849e.cg.shawcable.net ([68.147.167.223]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf6V9-0004cF-Of for capwap-archive@ietf.org; Tue, 31 Oct 2006 22:10:54 -0500 Message-ID: <000b01c6fd63$5ae22ec0$dfa79344@JOSH> From: "Das regard." To: capwap-archive@ietf.org Subject: claptrap Date: Tue, 31 Oct 2006 20:10:59 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C6FD28.AE728DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 ------=_NextPart_000_0007_01C6FD28.AE728DE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C6FD28.AE728DE0" ------=_NextPart_001_0008_01C6FD28.AE728DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorta blogger Isnt Timberlake tour dates of interest maybe personally. = Vocalist Natalie earned four Aria! Many or cases in compiled of title = having challenged? Thoughts ideas Jambase of database interact albeit moderation pattern = am. Save retirement lets. Ones far never a expire lose value locations am redeemable websites is! = Grinning galumphing bit stupid Clearly not Although am presented. Location Australia Posts hi all newbie my of husband of amp. Odd reason viewonly remote. Be easy or fiddly is if very strong there of little of. Trailers = listings Previews of. Tiger majors especially Europeans flattering is deceive once again. Ulfa = is Assam Article Aish ur tambola Pool Hotel affordable. Product = Advertise of Center in llc Reserved bbc Sport kid. Mumbai Chennai in India. Change point directly in intended am. Products feature stories content given regular basis. Demanding Midway = stop a Mortal Kombat Armageddon. Sorta blogger Isnt Timberlake tour dates of interest maybe personally. = Cups three points or Murray in swear laying. Logos available Root = favourite customized of Altador Adventures psp Gamepetpet. Autumn Tomorrow adding support automatic demo extras Guitar Hero. Focus am Culture Curry Matters a Matter Report Blogsmy. Member Windows is Movie Maker Join Date. Ted am shred Ward Datesalex or = Datesadam is Giveaway a Medeski Scofield! Thoughts ideas Jambase of = database interact albeit moderation pattern am. Night sore throat Everclear hangover mps. Flood Hans infancy subscribed feed is. Personally is endbut thats readers certain. Vocalist Natalie earned four = Aria! ------=_NextPart_001_0008_01C6FD28.AE728DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"theres"
Sorta blogger Isnt Timberlake tour = dates of=20 interest maybe personally. Vocalist Natalie earned four Aria! Many or = cases in=20 compiled of title having challenged?
Thoughts ideas Jambase of = database=20 interact albeit moderation pattern am. Save retirement lets.
Ones far = never a=20 expire lose value locations am redeemable websites is! Grinning = galumphing bit=20 stupid Clearly not Although am presented.
Location Australia Posts hi = all=20 newbie my of husband of amp.
Odd reason viewonly remote.
Be easy = or fiddly=20 is if very strong there of little of. Trailers listings Previews = of.
Tiger=20 majors especially Europeans flattering is deceive once again. Ulfa is = Assam=20 Article Aish ur tambola Pool Hotel affordable. Product Advertise of = Center in=20 llc Reserved bbc Sport kid.
Mumbai Chennai in India. Change point = directly in=20 intended am.
Products feature stories content given regular basis. = Demanding=20 Midway stop a Mortal Kombat Armageddon.
Sorta blogger Isnt Timberlake = tour=20 dates of interest maybe personally. Cups three points or Murray in swear = laying.=20 Logos available Root favourite customized of Altador Adventures psp=20 Gamepetpet.
Autumn Tomorrow adding support automatic demo extras = Guitar=20 Hero.
Focus am Culture Curry Matters a Matter Report = Blogsmy.
Member=20 Windows is Movie Maker Join Date. Ted am shred Ward Datesalex or = Datesadam is=20 Giveaway a Medeski Scofield! Thoughts ideas Jambase of database interact = albeit=20 moderation pattern am.
Night sore throat Everclear hangover = mps.
Flood=20 Hans infancy subscribed feed is.
Personally is endbut thats readers = certain.=20 Vocalist Natalie earned four Aria!
------=_NextPart_001_0008_01C6FD28.AE728DE0-- ------=_NextPart_000_0007_01C6FD28.AE728DE0 Content-Type: image/gif; name="lets.gif" Content-Transfer-Encoding: base64 Content-ID: <000601c6fd63$5ad165e0$dfa79344@JOSH> R0lGODlhmAGsAYf2AAsFAHoADgCAAHZ1AAAAin8AiACDgLa1x7XTuZfK5EkmBW4dAIopCaUuArQn AOwsDAtIABVHADFLAGoxAHNKAJ05Crk3DN8zAABUDh5UAEdcCmVjAHprCpRlC7RkAN1lAACJACZ3 ADWGAFR+AIp2AqF9AcGHA9qDAACuASWtAESlDVGZDnejAKatDrmeBdifAADNBivDAT+zC2e9DYaz BJjIDLq5Btm2DAHTACLhBjzuAG7dC4TlAJvbCsnfAufZAA0GMSUAOUcARWoBRXsATpcAN8AAP9YA TgAsTiclN0wZNW0ZNHQsOpkaRswUS+MrTgFIPxk9Q0w6OmU3QnE2SKNFSMNBMuY+RgVUQCZtTD1i QlpaTnVRAJ1nSstXRNRuQwOKMySBQDWNNl+AQnl5Sp6BTsaNSuB5TgCTPRmgNTqTRlmaNIecRKWd ObSbQuCXOAC9SSO0Q0q5S1W7R4G5Qau+SMPAOOTCOwDTRSzfODvkPmndNHLuOZrlSLrSQ9jXNQ0B hxgAjUsNhVkChIIKcaEAisoFdOUAhQAnjC0hgEQudFgUhIoViJYuf7oZft4ljgFIchg8jTxDeGkx hHQ9cqk/c8VMfNxLegBWfC1hjEZTdllgiHdah5FbibxlcuxecwCKcRZ0czN7jWx+dnyMe5Z9g7ty f+B5ewCfjhOSikWdhWeWfY2rhaqVebaqe+yhhgDBdyjChTbKg2bHdYbHf6G1gs3Bdei2cgDqfRjp czbYi1vbgHjUjZjcesnjhe3ZfQACwRoAzEAJs1cAtHMAy58AycIIyNwAsgMUuiQfwT0Sx2IrvXgp zKUhzssfveAWug04uStJu0A6xFI+x4I8tKNHy7s8stZMyQBpsipSsT1nw11dtIFVzqhszsJqvtRa vgR7sSVxsT2OxlqDsnVzxayMx8ODwdV/yACoshifs0qSw1idxIaixKOatseby+iSswCxzBzKzja7 u1y6xHK/u63BwP/7556UrXdyhvsACwD/AP/zAAAD//QA/w3z/fb4/yH5BADz9e8ALAAAAACYAawB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MhRoL2PIEOKHEmypMmTKFOqXMkypLKX ylrKnEmzps2bOHPq3MnzZsefQIMahElUqNGjSJMqXcq0qVOhMJ9KnUq16tSeWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnTvSqt27ePPq3YuXrt+/gAMLdsu3sOHDiBMrXsy4sePHkC8Onky5 suXLmDNr3sy5s+fPoEOLHk26pabSqFOrXs26NeDIsGPLnk3baLXauHPrLrxzt+/fwCGuDU68uPHj yJMrX868ufPnv3d+mP6POsEP1Qtin87devft37kP/xQ/vrt28wmxX9dePTz79wLVx2cfXn589O3J n7dvP3v99vDl91+A8tVn3XzrrTegQfzhJ6B+90EoIXn9Pfhddv8Mp5F6B87X33YHfZhgeSRiiKCJ JzKo4IoKVVigiSJWSGCKDZYYY4gihjjieDy6iBB/KILIkJBB8tjijgUC6aORTFbVG4dFwphikyru iCGQUy704oso6ggfkVJ2WWWPSH5ppIxgyhjliGBmySSRUA4Z5olqNomlmGLeiaCGGUGJJZdoHkml h2xCtOWZWo6ZJqKCkvmml4DqqGeZZi7ppX+MJsolnYna6WaeVtYZWZyRIjgghJ6qqCeqPzp6pXvX Lf+4qKmwpnpnoGH+FyeeQcoKaquE0nqhqqlamCONnxoY6l1Pcirlpj8eiyd4rN7Xaami/gotnFri N6ybh4Kb6YzvQcvrlYxmm6uD2X5rannUWdqlep2h+26w51IqrrkBSupqu1W6y22jhQ76rMGljqmt g/lyyy+D6G3b6bxZtrnmnmpttCum+Kp7McUfW0lsxxNnqqTBIl8s7cAzqjmpvSC3Gm6+zt5ass0s 6vvbxgAWuyyVB3pXrpkQn4fyoG2uWjLQJfbsM9Aui5x0yk1b+ynTOQJcsNMc60yzY+J9uCqs7k7b 4ZICA2tnrRXH3GvZuCLZ4doXiq02qCsv3SDc9Kn/yjbeZ1OocI6uOKlTbR5Dpzhf9rji+FmLXx35 5IcVTvnlmGeu+eacd+7556CH3lvopJcO1Fimp666ZGL9k8/rrwsEe+yy51OQ7a7PnpDuBOFeu+20 D4T77L4bBHvvt+dOvPLBG7/877c3X/xBxws//fXX9y598sIzNH30xTfvOvPVOx/+89aXjz5CvHdv ffTkG6/9+bSLP7xHYmUffu3JZw+/++PbX+76xz3tvW98yPseAmXHPuoB0Hf32x0Eh+e/A7ovePUr IPAkqMAB8s+D3eugAT8owgUiUIDOQx4DJwg/FAZQhSAMoP9wNxYFCnCDIfTe7kx4v/2VkIEwhCAQ /wtoQhgCEIhCLCIRT8hDAl5Qg0fE4Q4dqEIpvnAhM1SI/ozIxQTmcIVFFCIKbdhEBNaQikhs4g9L aMUeelGLVEwiGY/YxSyCcYoEdOEV78i9JPKxgfKTXxuVuMQ/BvKLQ+ziG/e4wQoOkpB7ZGKGVLKR 8sUvjUgUHx2diEk5ajKRT8zk8vSYvgxWMYeWBOUd/YjJSIZSjVhE4xvFSLwKJnB9ZSQlJPnoxkj6 8JRxfOVTTNnKCFrwgdXzozGN+UFFinGTl9ShI2MnRVsikpkL7CUUxwjHQy5Sm4DkJPXah0toDjGC OARe+7L5St3JUZUKGd0ieQlPa56QnOesZyHZyf/KBzrEioSs5j4FGsYnztGX6/QmNAkKUIUacqDm FOHzlAlJ9GGTkZhEnTh9GVCFLlOYDVWiLQlKxB8a8nsfXSIzAfrLgiKSnXhUaSIbqUNghtOIHcxp O18aRH/OE6Bn/CkoqVnI7dkRey4dYQzLKFNvprSPm8QgNu33P6mWdJ/wBCEx+WdSq+6yo85sKU8f 6lIW8tSUK6kk7yxa1YTOb6rKCyMFUzk/WdayoTa0JF15+Eno0ZGqSo2rUwfqVr8OVZ3lNOxXDxrR ZG6UrPqTnmNHaNLVWfaymM2sZjfL2c56tiHy/GxuXNMZAAAALKLdDWkrw4GSmNYkqY2tbBNi2tn/ 2va2tAUAUARQEN4SxLcCAa4Ahktc4g6kuME1CHCDW9zmDve4zo3uQZbr3N9Wt7fIje5zkwtd4zJX u8/d7nGtK96EILe3v8WtUnQ7kJ1Q9x/vTe5yuQvd9M4XvspFr0LiS1/5jte6/Z2ufgOMX+Gmd8Dc LS9+4ctfAf+XwfFdrYRpsuACP9jCCK7wgTd8YQ07uL/z5a2B9XvfDJtYxBe+b4j9+98SO2TF/50w ajZi4BGzmMMuVnF+OfxhDa/YxvZdiIsJjGIQ77jFPvZwRGBMYPUypsYpVnKDydvcIzcZxzwuspIL fF3y9vjGU/awb8c83iHvV8FJdjJDPrEXMif4/8FM3rKUrSznFJ8Xzk3WMkMUzOQx3znL9CWzcL3b kDibWc2H0bKeq4zlL8+Zx1YGMoS3W2I9FzrL55V0gN28YEvXmc5hRrRQRqfoNIvZxI8G9H4bHWgi X9m8qu40pGH8Xk6/GtQHkbGuKclg7HZ4yuX1tI4hjWBaozfEtv5yg3+cYWMDuNcdLra0J7nrapPk 17HecqZBHWwhz/rUXZ40obvLZ0APG8Th9TW59zxuRvvW2oKJBUtETe962/venAstvg0Db9Ds+9+p 67fAB07wjwCcc+w9uMIRvnD8FfzhZzntW3oBca3Ao+IYlzjGN85x0Wi846hteOYSDnCQm3wrH/8/ +VZErjmS71vlMOdJymNO85rbPDQsz/nkbs7zns/kDzjRudBh84c/YMTnSE/6SIB+uKE7fTFG14jS p+5zpuv76VjHS9GzDnBjPCfqXA+7bsAu9rLnm+poT7tMzM52xbBiIWqPu9xh2/a6R2bueM97XIih 9777/e+AD7zgBx9yuxueMYRPvOIXz/jGO/7xkI+85CdP+ckc/vKKqbzmN8/5znv+86AP/ecxT/rS m342Sjj96vjRENYTx/WGy4lATFvbptT+Hy5nXV0cUpJ/8OP3rIe97wfye+ITRPjAd33yg5983zd/ +c4vfkGA73zjN5/41Mc+840vkOtzv/vSH37/9ymS/eiH3/vaZ770zw/+8Ldf+dx3fVo2knum3L7+ eRG++McP/u/vf//BdxD6B3sD6H/8x34EyH8C2H8HmBAJ2IAKCBEPGIH6d3zTZ30JWIHfF4AAaBU7 UX+0N3u1VXu0l3AhiHsnaIIEoVvs1YIkOIImeH8F0Xu8RxIFGH8QSIHWt4AWGIEdeIHDB3/I939A yIEcyINEqH7mp33jN4Q9+INFCIRBKH5HaBAZmITUhhm5p4ItOHu4NxAux4Jg+IVeOIZduIJk2IUq SIbtdW01WBfZt3zwR4VPuIR26IMEGIcGSIdC2IPlh4N9iBAT2IQb2IHuh4UKqIF5qHx6OId//5iI 1XeBm7GFZliGYmiJIbiGlziGX+iCI2iJKHiCBkGDoOWGhIiDdOh/V2iFUjiAjwiBAeiEBuiIUyiI swiF6ld8FXiDULgQR2iEiJh+DGiB85cRlOiFZ7iJysiGalgQzciFoIh/S1GFuaiLdbiKUgiJfsiD fSiLeNiAVdiKFziB4biL4uiDDmiIp3iLFsiLshGGlZiGzDiPa8iGnIiC9BiNnCiNQEGN/+ePhaiI 51iIUdh/g/iNADiHrEiQ5KiOC/mPdYiOv5iQBXmD3viOKUiC0SiKJTiPZYiGIiiCnyiPoXiPQnF9 Q5iS1Pd8ceh9vAh93riS2HeH6Bd9FPl+2f/4h9Z4gOsniIfoij1phyg5ky6JkKnoHPyIEEmpehro HE2JHEtpEFF5ek+pHFWpeliZlVqZWqLXlV6peUGgeFs5lmRZlmZ5lmiZlrP1lWxJGWr5lnAZl3I5 l8whBXSJeVe3EaT4GHvpOW0pEqNminwpmH75lyARmLsHGTRYARvBmLnhmFkolsYoiia5OZApEJdZ EJn5D5DpmBXwmZ75mQMBmpdJmqMpmpwJmqeJmqnZmQTBmKwJm6bJmaNZGMWwOB9YmboHmHd3bbPJ mpqZmbGJmbVJm8R5EK55nJu5nMVZmqlZnMZ5nMaZduKQFtB4iRlZjzNImI1RErCpmQnhnJ7/CZ3j GZ0G4ZzGKZznCZ7imZ7QaZ6MaZggwYXNeI9nOIrciXgk8Z2vGZ7NKZ2z6Z4IgZ6diZrM2Z/tWZ7w 2Z+OpxEdmY9g+KDQoZrvCZ6YaZrJKaChiZ7KuZ4HWpvtSZsZuqDBYTmKqRPwiIwgWYqJOZi7x5/m aaH9GZ3JqaAk2qHsuZ4IuqMi+p7OKZ8fkaKduKL3uZ0t6hiLSaMzKp3/CaBOyqQZeqAfaqMwOpwD GpltKaSeKJK66XC8eaIjEaAUSqPAqaStuaGrWZpjqpoBeqar+ZoUWqA+WpxAag+I+aUuypubSRF7 OhuOWad3GhKwkaQa0aewAZmAmhR9eRx1/zphSrGoxtGobIEILUEVSTmVd6levSGhDHGpRoqnjNGR DyqDoahbkuqWxjgRnrobWoqPKpqpdpGbRFqSL3h/GkmGkIoYrYqd9oilp+oX9HerQyqP0PiqmLoY 2VmfW3oXcwCrGKGs+viqwwocy1ifXeqskAGtxBqP0/ob1SqtH4mtsVGPyQihw3qsjfGtIbmi4uoY nKqJyMiRt4quupqsHwmDt9euS5GX9MoQuUocv+oaB9GvcJefxRGwrQGmoPoUCCtwCiuosdewmmF/ zUGw+uqBKMqpzggRJWix4dqGR0p/Gxuh7CWxnOGgDUGvHnut65WR9mkRzXqxHSGrSpmd9/8qlSuo kZ64rCnopRDLEZv4sV5ostamsR7Jrce4scKqrmX4rxURtL2Kq0S7a2iYifvYsyCYsyNJj6KaawZ7 EZQppFNLtZVZrNuKszdLrr1af05rEctokmOLGSj7sWarnbMqrXVrjyurqke7tzJbryBor0Ibrl1L ssvqqn77EBKarIn7txmRlxwrsm+4sHPLonGLqlWxt5SZF437GxAAAY4buqI7urgFuaS7m3F3uqo7 ECdQEK17ArAbu68ruwTRurVrELI7u7m7u7brurBbu70rEMFLu74bu6yLu/8QvMlbvL/LursLvM3r vMOrvL8bvcKru7Rrvcv7vMh7vbxrvNL/C7yuG3bUu7zdK7y3i77jm77q277me73OC7/pa73le7zv a7+9q7z3m78IQb/ym7y2q73VS72vexACfL8AfLv6W78JLL8H7GS9wb8I7L7Da7/sa8AXXMHzu7/u i8H4270SnMEWvL7nq74FjL4FzL8nPL4VvMAKXMLvW78rvLydF8MdTMEs7MH9K8I3vL0crL8lHMDn O8MjHMIXfMQobMMpfLxEnMRMrMNNLMMYPMOtm3cbIcG8y8EvbMDai8MWDMQnrMIMkbsj3L5NrMUA TMZAPME+3MZhbL7Ya7xC7MQkHMXrC8ZwXMa2NTorDMbES8IJ8cDe67/Ii8UxDL5FfMMa/4y7f8zG a4zHQhzJTnzGhozHNnzEc5zDJuyrkkfHluzIDrHIl9zDfUzHZVy+LqzHZozEbAzKIVzKpvzFsWzC jYzAmbzFeVzDbQzKerzGQczDHXzLb4zJmgzMgGzErGzLq+zJT/zLdrzMpxzNP8zJkZfIMMzAgIzG yvy/zUvA/7vN0AzO2XzL4ou/+UvOs7zLmEzE3XzMdXzOwVzFnFfEz5vKPTzI2GzPabzO0LvAtVzL rezCWSy9BCzKzczC9ey7aYzI4jy9Ds3Pury6Uod3Eo2WplvREWHFGL3RHB06mMAUl0u0zxDSJF3S Jn3SKI1zHb2VKd3SXnEALi2pKz3TNP9d0zb9HDFdGhSX0zzd0z7900Btcjc91ETtWXq3DEH9GmoW BaDTCEKX1FAd1QFb1KQn1SVN1Xhp1SGN1Vzd1aKj1WAd1mI91nrn1XZH1kRr1nWH1iar1m791nAt FEMQ13Rd13Z913id12p20SstmXqtc72hDYKtDf8w2IRd2ARx2Iad2II9EIZN2IctEI/t2JFd2INt 2ZeN2ZW92JhN2Zlt2Y4d2pe92Z5N2qK92JGd2pL92Yyd2pwN2qvd2Afx2aS92Y1d26hNzX2nEZWN 2JIN24jd26Ht271t2gUh27493Mp93KL928nN2MOt2sCt2AiB3JDN3M4d3AtB3c9N2cr/LdzSbd3d rdiqXdwHtxPm/dvXrd2z7dzpnd3RDd/jXd3NTdwGwd3r7d72Ldz1nd/Nvd78ndj6jd3cDd/mDeDz zd7+jdh+jRGZzdnUTd7Fbd0P3trh7dmx7doTLtu0Tdvund4RTtzIvd+a/d/JzdqtXdrx/dzGrd4u DuIvXuEl13QuXuPAbeAnjt3yXeLMHeAsbuI7DuE/fuL+bdy3fd/aDd7tLd0WjuPLzd6gDeOrPd9/ KeDlLeBYPuDvneDyveBZnuP4reMKvuIDPuQ2buJKPuQFjuNM/t1sTuBW7rWEx9sPLuPqjeLljdqj ndunzeF6PuI8nuejHed3XuQqvtyQ//3aTK7oWZ7og97nAe7hkN7ZuP3ofx0cPi66fN3RDX7pDcfW oB7qiefppF7qeyHqU23qC4fqv6rqrv7qQycMsD7rtK4QbFbruJ7rwZEOut7rosXqXukOJ6EQb7dw r+DryB5wwN6oyd7szg6yyy6fzz7tyL7pGBvtpCUUnUvtsjE6pKq4UpmJPXu1+arb2E4aQGu3nTqy LyuD287tepGM8nqfLEhyu3q27ArvDHs45Yq35kqyIlmuh1uy565ypZq2SBu1CR+D7O6zBc9x9m6u TIuzZru2TfvwJhfxi2urwnrwHq/xHOnwGI/u+s6VNM5vI+8XDpDyLN/yZIEAq1HyMv8/8zRf8zXt 8jif8zq/81whADxfcS7gFTY/9HedBCdP9EdBF0gvcvwohu++7tTa8Pn+tArx9Aq3qVZLW92KtlO5 uWir9VJfsyoLtEr79QML7mBf9WefHFGp9Kk69VWr8PuI9mpf93ybuWE/uCxr9nxf1SjqjPKqohsf ki8Irmk479UKg0PqglwKkhuftZtb7qNqhljLpW9L+IdvuOvq8ZavhliL+IDPs4rP+bVK74Af8Jrv qgdf7xxvqqVRkke7+BDKq8R6jHmbt4iL747PrWcvjRHv79ept4bP+HFvrLEv8PmI+4Qbj9aq8XOf okzr/IKf8G5P9pr4iYk/kjur8Kb/j/v93onjvvuGP7JbmK+3X4lBa62gCPD0ubW//4zon/AmWazN b/nPH/rRb//T7+8oL3sLDxD//gEYWJCgQIIHES4sKLChQ4YKEzqcyNCgxYoQFUak+NDiw40HQ3aU CPLiyIsaMS4sidKjSJYmM85U2TFmQ5owS6a0ubLlzZMkO9ojWtToUaRJlS5lShTiU6hRNQKgunJg 1YlUqyLcCvNqRopYbWoVqfUr0LIJt3Klefal27AhzbJV2xWn2I9C49Jly3dszJ87yT6dW5jj4L47 Pe4VXLir2baIpU6mXNnyZcyZNW/m3NnzZ8wbQdccXXqzaM6oLasOTZk1YdOxZc+m/13b9ujXnnPf Bj239+nOvgmvlSqcN+imyYseZ97c+XPo0aUrp17d+vWk0rVv597d+3fw4R1iV9pavO3d0dPPZr2e tHbitAmSp1/ffuzcXnmLruj+s3+c0NNsPf16gm3A23Yj8L/zbrPPqMoKhA7A3zKjEDgLL3utPQxr U5C5+R4UcUQSl6qLvxPDgmotx/A6SSy8WtzQqxTv0okrHNPya6odJftKosdw/DFHIVEM0qSrInps ySSLdGw4HRPTyTe7ylqoRCyzFLEtjm5SDayfANMrJwP/ajIwkvgLMMzF0ELSpzHdLBDMOFO6kc3+ vJTpQJ66zCrO+CbSctD68HszQP+WjIOMNDLXlLNMv+wSE6izbnRzqkbfenTIMHV0qcb+FsUT0RTZ hLOmO9N0sdIGbSORS0T7/OvTPSfNdM7h4BzVzlo1vZXRWmm1lE5KedWLpzz7NLVXP5HV1FFCo5XW xEOdhasvtxAbrC5HszWTsUQlNWwvOyVdbFEliZOMysRmbRfTKF+KcUka00XSyLzqjWzVRaf191/4 Esyw1eIIRtBgzv5VONqAv7uQu4fPi5jghSteDmGMM9Z4Y44RJrFjkEMWGWSLSy5v5FYjnjhlAVm2 zOT7EJaw4Ajje881IE0Dq7htM/Zv5RXzwhlIKo07mGaUDQaaTw41zLk0ABVTemD/Q9tE2iWrU3Mt aZ0Ni3LdO0PFNlw1VWrJSmWDyrZoJsvdukfUWpQS7kgNhFHIIc8MlN5cwebTqqwrffpPkNAO+dU0 T+VV3G7Nthu2ThOFXG1nRyU2KsWS/Shyay/d2fBNd+4VJc7z7WnDLiW3tiKYWydq18rRXXPcY7Gu nK+4D6t99HJR90k4YXW3V7BzN3cRVKYP1a9G0wEPmtTjWUTXdfKq7jzTe9scSers9YRU390tNzZ3 xd/jvNHIis9+2WdhXT5rqW03M0/in+X6P9rXlp5OT9Wt9lptvetmXxuL3HontMyNDVvjmtL+3vQl eaWlf/iq1r7iFigokW54p1vg/8gQZ5774YZjF1paCGdDPZj9zIS6sZnMOrRC8KDQZDCkYQ0pI0Mc 5vBBNuRhD/+hQyCWbD/ke04JoXY06+0nQj5kYsJG9LxvvU1osoIi7jDnIQ1NsYpLNCLSvMip/EkQ IkEkYxlPNkAt/s13k7EdBOWTxcDdTIpKnGPZDMI+gZhRj3rUn4r8Zr68qQVvPkKRk5wkLLahDUzM 25vbrAg2dR1PcHDDFbDoJ5U9ZjKIy3pfJR8FvnyZy3uiE5+eMBgsVKkJTZfaHKk2JSsZCc84mqSl iKz3ud/5L3w2gpXj3hVAS4ZPdt9iXqxYNanOnQqUt7sinuzYRGiy8VipE91bVv9Jq2bKsoqlTNuB 8Pi+28HOXa7k5uQoVbYuRtM5H8uf5/ZmrmTFMi6NoRFW3mlBT2XTXr5coKgKGMkEzs6BERSjNdlV S4TSR50LrdAXGfpQiEb0OEaTo0QtelGMZlSjG+VoRz36UZCGVKQYS2hJTXpSlKZUpStlaXJG0VKY MmykM6UpRGN6U5zmVKfYqWlPffpToPbQDEElalGNetTO7FSpS2UqTpFqURQ8VapMrMJUrXpVrGbV hk3lale9SkuthlWssvlqWWv5BbO2dKxrZWtb3fpWuMZVrmRNa13teleZzlWvY8VrX/36V8AGVrCD VeheDXtYxCZWsYvFKDgYGxX/cETWsZJ17D8qK5DKUhYiksUsZ5+i2c46hLOXtaxlI1ta0YrWs6Fl rWkve9rQUnaym3XtaUk72dfO9rOj1axsobLa227WtqDtLGx969viqja3q3VtbXVLXOcqd7ekxexv lzvc0aKMRNR9rWlTS13aohaykA2ud6uLWtiiVyrpNW5qzetd7nb3vOItLXt16178hvez7mXvfvM7 3/vOF7+ZPS9489tdAx94wP8Fb3oBvN+Sxoa731VvgtU73t8+uL4Fri6BLTxbEO83xAHesHjl2+EN B7jBGNYvignc4hWjuMX0LfGLWUxjC5tYxP4V8IU1/N+OfcyzoPVwcnnMXPS2/1fHFeZwio3s4hJT eMRDlvGSoRxi/mK3vDN+Lo5nXNviZra3IravgwXcYDP/uMpn9u+WifzDhNbmvnOe8Je3nOT+mvjF uaVveYtM2z17ubUnrvGag2vgGFO4tWw+sqAZHOUPfxnIhI4yo5XrZh5HRxOtmnOfM01jR6u4yU32 s4IvLN9A1/nHhx61fkncYw3f2dONVvWCTz0ZWdvZ1bY29apXuN0hU/m7SOZtmsF8aNsCOtkDZq6q gUvm7PIazF5Gs5YpLV1LNxfWRB6zdU+M22bn+dI31ja2hbvsVY85rY9ld1LN2m54Z2bd8XYVYe1N HXrX+95lNc078v3vXz/xvf/Ehe6435xlByO33Lx+9rCrvdtxC9fc0+31rMt9bQLvW+NLGTR/H73r /uYY0zuONaB7bOOBHxjVGS4wofO88pNnfOMzh1CgFZ1tHXdZ5B9X9IRZLWiYl/rWXC50z6k96erS fKclOIpsbG5oik/7z0hWM6gpLWqqN7vVNs86yUXt5PC+2scAj46QhQ318SJYtZ+28rYfzeoV3/bs eP4z0fnMbKCDWr1KV/rPfRxptfO814jetadRPvQqo7zLjbb4rL+td9LyvakSVnaZqy1mJXeY6jg2 NuflnnlMI1vckPZ2xd1sZkSjm+zQ+djqTSN5prpe9jYVuA9hf3uUzv5+s+D/fe9noXvgQ9P3vg9+ aR4/aIJH+8zWnu5yIf7kHBdfq9tleK2tn+lES/vlScd99/k9Yo9LG+e5rvXQA+199HfVyTCvunOv X/q84zm16af/Utcf8fbLOtcmDzuVu1t/AMyp+7M4/SM6IAu78JOxyAtABlQrKxs5g4Ox0Quzc1Mw tWtAWjoFDDyjHtpAD7QY6QtBERzBtyKByvhAFEzB5CBBFtQuFXxBGHSKFrSMBZhBG7zBmopBHUxB HOxBH/zBmdpBIRxCIixCIzxCJIw9IFxC70hCJ+Q7JozC7XhCKqxCK7xCTZJCLWQ9LOxCv9pCMAzD FbIAMSxDM3Q3L0xDNVxDEjZkChxoQziMQzmcQzqsw68KCAA7 ------=_NextPart_000_0007_01C6FD28.AE728DE0--