Subject: Re: [Capwap] Capwap Digest, Vol 11, Issue 32

From: zhang zhifei <[email-masked]>
Date: Tue, 19 Sep 2006 21:16:05 +0530

I would support the split.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 2006年9月19日 18:47
To: [email-masked]
Subject: Capwap Digest, Vol 11, Issue 32

Send Capwap mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."

Today's Topics:

   1. Re: Consensus call on Split CAPWAP draft by 9/29. (sujay)
   2. Re: Issue 43 - Explanation for 802.11i Considerations
      (Michael Montemurro)

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

Message: 1
Date: Tue, 19 Sep 2006 16:40:38 +0530
From: sujay <[email-masked]>
Subject: Re: [Capwap] Consensus call on Split CAPWAP draft by 9/29.
To: [email-masked], [email-masked]
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

I would support for the Split.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229
<http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=
h&hl=en> &spn=4.724852,7.525085&t=h&hl=en

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! 

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 15, 2006 11:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Capwap] 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20060919/f67c8fd7/att
achment.htm 

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

Message: 2
Date: Tue, 19 Sep 2006 09:17:09 -0400
From: "Michael Montemurro" <[email-masked]>
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
	Considerations
To: "David T. Perkins" <[email-masked]>
Cc: Saravanan Govindan <[email-masked]>,
	[email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

I support Pat assessment of this issue. I think what we have in the draft
today provides adequate flexibility for centralized security.

Mike

On 9/19/06, David T. Perkins <[email-masked]> wrote:
>
> HI,
>
> I totally agree with Pat's technical assessment on this issue.
>
> Regards,
> /david t. perkins
>
> On Mon, 18 Sep 2006, 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. The only thing that is not there is the
> > ability to move various pieces of the authenticator function across both
> > the WTP and the AC, which I feel is unnecessary because it doesn't add
> > any features. It just adds modes of operations to the protocol that
> > creates further interoperability issues between the two devices.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: Saravanan Govindan [mailto:[email-masked]]
> > > Sent: Monday, September 18, 2006 1:08 AM
> > > To: Pat Calhoun (pacalhou); [email-masked]
> > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > Pat,
> > >
> > > The requirement goes beyond distinguishing local / split MAC
> > > support. It is explicit in the need to support authenticator
> > > and cyrpto elements located at AC and WTP, respectively.
> > >
> > > I find it difficult to interpret it in another way.
> > >
> > > I do not think it is right to arbitrarily dismiss a
> > > compulsory requirement.
> > >
> > > The fundamental goal of RFC4564 was to put forth key
> > > requirements that the protocol has to satisfy. It is a "MUST"
> > > - I do not see why we are having this extensive discussion.
> > >
> > > Saravanan
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > > Sent: Monday, September 18, 2006 12:07 PM
> > > To: Saravanan Govindan; [email-masked]
> > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > >
> > > My thoughts is that the protocol, as defined today, can
> > > provide complete support for 802.11i in both Local and Split
> > > MAC. So while we may have agreed on a requirement, my
> > > objective is to try to keep the protocol as simple as
> > > possible. I do not see making this change as necessary,
> > > because there is nothing the protocol is unable to do today.
> > > Furthermore, I do not see making this change as necessary,
> > > because it would introduce additional optional features in
> > > the protocol - and consequently increase complexity.
> > >
> > > So I disagree with your comment of not confusing between need
> > > and stated requirement. When we agreed on requirements, I'm
> > > not sure we all understood how they could be interpreted. I
> > > believe we have a very flexible approach today.
> > >
> > > so my thought is that if we believe we need to interpret the
> > > requirement in the way you have, this requirement is not
> > > required. If we interpret the requirement the way I have (see
> > > above), then we have already.
> > >
> > > Pat Calhoun
> > > CTO, Wireless Networking Business Unit
> > > Cisco Systems
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan
> > > [mailto:[email-masked]]
> > > > Sent: Sunday, September 17, 2006 7:24 PM
> > > > To: Pat Calhoun (pacalhou); [email-masked]
> > > > Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
> > > > Considerations
> > > >
> > > > 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.
> > > >
> > > > The proposal is a way to realize this requirement.
> > > >
> > > > Let's not confuse between actual need and stated requirements. We
> > > > achieved consensus on the mandatory requirement because there is
> > > > indeed a need for it.
> > > >
> > > > Given that this topic has been discussed for a while, I
> > > would really
> > > > like to understand your concerns. What are your thoughts on
> > > realizing
> > > > this requirement?
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> > > > Sent: Saturday, September 16, 2006 1:36 AM
> > > > To: Saravanan Govindan; [email-masked]
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > > Considerations
> > > >
> > > > The "protocol" performs the function of 802.1X/802.11i without any
> > > > issues in both the SplitMAC and LocalMAC operation.
> > > >
> > > > Are you stating this is required because RFC4564 states that
> > > > flexibility is required, or because there is an actual need
> > > for this
> > > > feature?
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Saravanan Govindan [mailto:[email-masked]]
> > > > > Sent: Friday, September 15, 2006 9:00 AM
> > > > > To: Pat Calhoun (pacalhou); [email-masked]
> > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > > > Considerations
> > > > >
> > > > > I want to emphasize that this is not an "additional" feature
> > > > > - it is a mandatory requirement from RFC 4564. The protocol
> > > > currently
> > > > > does not meet the requirement.
> > > > >
> > > > > Saravanan
> > > > >
> > > > >
> > > > >
> > > > > ----Original Message Follows----
> > > > > From: "Pat Calhoun (pacalhou)" <[email-masked]>
> > > > > To: "Saravanan Govindan"
> > > > > <[email-masked]>,<[email-masked]>
> > > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > > > Considerations
> > > > > Date: Fri, 15 Sep 2006 08:01:32 -0700
> > > > >
> > > > > I understand the proposal, but stand firm on my belief that this
> > > > > additional mode of operation is unnecessary. While it is
> > > > possible to
> > > > > implement, as everything is in a protocol, I believe the WG
> > > > needs to
> > > > > focus on fixing the protocol in the areas where it is broken, as
> > > > > opposed to adding more optional modes that really do not
> > > change the
> > > > > outcome of the functions.
> > > > >
> > > > > Perhaps what would be more useful is not to describe the
> > > > method, but
> > > > > the reason why this is being proposed. I still fail to
> > > > understand why
> > > > > you believe this mode of operation is necessary.
> > > > >
> > > > >
> > > > > Pat Calhoun
> > > > > CTO, Wireless Networking Business Unit Cisco Systems
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > >         From: Saravanan Govindan
> > > > > [mailto:[email-masked]]
> > > > >         Sent: Friday, September 15, 2006 2:03 AM
> > > > >         To: [email-masked]
> > > > >         Subject: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > > >
> > > > >
> > > > >
> > > > >         All,
> > > > >
> > > > >
> > > > >         I wanted to give a more detailed explanation for the
> > > > > IEEE 802.11i Considerations requirement. This note describes
> > > > > how CAPWAP can be updated to satisfy this requirement
> > > > >
> > > > >
> > > > >
> > > > >         I would like to use this to highlight the proposal
> > > > > being put forward.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations
> > > > >
> > > > >
> > > > >
> > > > >            Protocol Requirement:
> > > > >
> > > > >
> > > > >
> > > > >            The CAPWAP protocol MUST determine the exact structure
> of the
> > > > >
> > > > >            centralized WLAN architecture in which
> > > > > authentication needs to be
> > > > >
> > > > >            supported, i.e., the location of major
> > > > > authentication components.
> > > > >
> > > > >            This may be achieved during WTP initialization where
> major
> > > > >
> > > > >            capabilities are distinguished.
> > > > >
> > > > >
> > > > >
> > > > >            The protocol MUST allow for the exchange of key
> > > > > information when
> > > > >
> > > > >            authenticator and encryption roles are located in
> > > > > distinct entities.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         Following the requirement, CAPWAP needs;
> > > > >
> > > > >
> > > > >
> > > > >         1. to incorporate authentication & encryption locations in
> > > > >
> > > > >            capabilities exchange
> > > > >
> > > > >
> > > > >
> > > > >         2. to exchange key information when authentication and
> crypt are
> > > > >
> > > > >            located in different network entities
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         Basic case:
> > > > >
> > > > >
> > > > >
> > > > >         AC does both IEEE 802.11i authentication and
> > > > > cryptography. For 4-way
> > > > >
> > > > >         exchange, AC tracks the KeyRSC, which it then uses for
> > > > > Message-3,
> > > > >
> > > > >         i.e., AC calculates KeyMIC and updates EAPoL frame.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >                                                           -
> > > > > 802.11i Authentication
> > > > >
> > > > >                                                           -
> > > > > 802.11i Crypto
> > > > >
> > > > >
> > > > > (KeyRSC maintained here)
> > > > >
> > > > >
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >            | Terminal |                 | WTP
> |                     |
> > > > > AC  |
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                    802.1x Authentication
> > > > > |
> > > > >
> > > > >
> > > > > |<=====================================================>|
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                PMK                         |
> > > > > PMK
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >               Generate                     |
> > > > > Generate
> > > > >
> > > > >                SNonce                      |
> > > > > ANonce
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                      Message-1
> > > > > |
> > > > >
> > > > >
> > > > > |<-------------------------|<---------------------------|
> > > > >
> > > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >               Receive                      |
> > > > > |
> > > > >
> > > > >                ANonce                      |
> > > > > |
> > > > >
> > > > >               Generate                     |
> > > > > |
> > > > >
> > > > >                PTK                         |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                      Message-2
> > > > > |
> > > > >
> > > > >
> > > > > |------------------------->|--------------------------->|
> > > > >
> > > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > Receive
> > > > >
> > > > >                 |                          |
> > > > > SNonce
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > Generate
> > > > >
> > > > >                 |                          |
> > > > > PTK
> > > > >
> > > > >                 |                          |
> > > > > GTK
> > > > >
> > > > >                 |                      Message-3
> > > > > |
> > > > >
> > > > >
> > > > > |<-------------------------|<---------------------------|
> > > > >
> > > > >                 |       EAPoL Packet       |   CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |      |
> > > > > |
> > > > >
> > > > >                 |                          |      |
> > > > > +-----------------------+
> > > > >
> > > > >                 |                          |       \|- EAPoL Frame
> > > > > |
> > > > >
> > > > >               Receive                      |
> > > > > +-----------------------+
> > > > >
> > > > >                GTK                         |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                      Message-4
> > > > > |
> > > > >
> > > > >
> > > > > |------------------------->|--------------------------->|
> > > > >
> > > > >                 |       EAPoL Packet       |         CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         Case specified by RFC 4564:
> > > > >
> > > > >
> > > > >
> > > > >         The 802.11i Considerations requirement considers the
> > > > > case where 802.11i
> > > > >
> > > > >         authentication is at AC and 802.11i crypto is at WTP.
> > > > > So now, the WTP
> > > > >
> > > > >         maintains the KeyRSC while the AC requires this
> > > > > information to generate
> > > > >
> > > > >         the EAPoL frame for Message-3 of the 4-way handshake.
> > > > >
> > > > >
> > > > >
> > > > >         The diagram below shows this;
> > > > >
> > > > >
> > > > >
> > > > >                                     - 802.11i Crypto
> > > > >
> > > > >                                  (KeyRSC maintained here)      -
> 802.11i
> > > > > Authentication
> > > > >
> > > > >
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >            | Terminal |                 | WTP
> |                     |
> > > > > AC  |
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                    802.1x Authentication
> > > > > |
> > > > >
> > > > >
> > > > > |<=====================================================>|
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                PMK                         |
> > > > > PMK
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >               Generate                     |
> > > > > Generate
> > > > >
> > > > >                SNonce                      |
> > > > > ANonce
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         In this case, the EAPoL frame generated by the AC will
> > > > > not be based on
> > > > >
> > > > >         the prevailing value of the KeyRSC, as this counter is
> > > > > maintained by
> > > > >
> > > > >         the WTP.
> > > > >
> > > > >
> > > > >
> > > > >         This problem is currently not solved in the CAPWAP
> > > > > specifications.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         Proposal:
> > > > >
> > > > >
> > > > >
> > > > >         The proposal is to include a CAPWAP Key Configuration
> > > > > message that can
> > > > >
> > > > >         transport the EAPoL frame between AC and WTP before
> > > > > being sent to the
> > > > >
> > > > >         client (terminal).
> > > > >
> > > > >
> > > > >
> > > > >         Key Configuration is a control message sent by the AC
> > > > > to the WTP. The
> > > > >
> > > > >         message contains Message-3 of the 4-way handshake -
> > > > > including the
> > > > >
> > > > >         EAPoL-frame. However, the EAPoL frame has its KeyMIC
> > > > > field unassigned as
> > > > >
> > > > >         the AC cannot accurately calculate this.
> > > > >
> > > > >
> > > > >
> > > > >         So on receiving the Key Configuration - containing
> > > > > EAPoL frame with
> > > > >
> > > > >         unassigned KeyMIC field, the WTP retrieves the value of
> > > > > the KeyRSC it
> > > > >
> > > > >         maintains and computes the corresponding KeyMIC.
> > > > >
> > > > >
> > > > >
> > > > >         The EAPoL frame is then updated and Message-3 of the
> > > > > 4-way handshake is
> > > > >
> > > > >         reconstructed before being sent over the wireless link
> > > > > to the client.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         The diagram below illustrates this;
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >                                     - 802.11i Crypto
> > > > >
> > > > >                                  (KeyRSC maintained here)      -
> 802.11i
> > > > > Authentication
> > > > >
> > > > >
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >            | Terminal |                 | WTP
> |                     |
> > > > > AC  |
> > > > >
> > > > >            +----------+                 +-----+
> > > > > +------+
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                    802.1x Authentication
> > > > > |
> > > > >
> > > > >
> > > > > |<=====================================================>|
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                PMK                         |
> > > > > PMK
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >               Generate                     |
> > > > > Generate
> > > > >
> > > > >                SNonce                      |
> > > > > ANonce
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                      Message 1
> > > > > |
> > > > >
> > > > >
> > > > > |<-------------------------|<---------------------------|
> > > > >
> > > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >               Receive                      |
> > > > > |
> > > > >
> > > > >                ANonce                      |
> > > > > |
> > > > >
> > > > >               Generate                     |
> > > > > |
> > > > >
> > > > >                PTK                         |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                      Message 2
> > > > > |
> > > > >
> > > > >
> > > > > |------------------------->|--------------------------->|
> > > > >
> > > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > Receive
> > > > >
> > > > >                 |                          |
> > > > > SNonce
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > Generate
> > > > >
> > > > >                 |                          |
> > > > > PTK
> > > > >
> > > > >                 |                          |
> > > > > GTK
> > > > >
> > > > >                 |                          |          Message 3
> > > > > |
> > > > >
> > > > >                 |
> > > > > |<===========================|
> > > > >
> > > > >                 |                          |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |      (Key
> Configuration)
> > > > > |
> > > > >
> > > > >                 |                          |      |
> > > > > +-----------------------+
> > > > >
> > > > >                 |                          |       \|- GTK-Flag
> > > > > |
> > > > >
> > > > >                 |                 -Retrieve KeyRSC  |-
> > > > > Encryption-Data(PTK) |
> > > > >
> > > > >                 |                 -Update KeyMIC    |-
> > > > > Encryption-Data(GTK) |
> > > > >
> > > > >                 |                 -Reconstruct      |- EAP-Frame
> > > > > |
> > > > >
> > > > >                 |                     Message-3
> > > > > +-----------------------+
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >                 |<-------------------------|
> > > > > |
> > > > >
> > > > >                 |       EAPoL Packet       |
> > > > > |
> > > > >
> > > > >              Receive                       |
> > > > > |
> > > > >
> > > > >               GTK                          |
> > > > > |
> > > > >
> > > > >                 |                      Message 4
> > > > > |
> > > > >
> > > > >
> > > > > |------------------------->|--------------------------->|
> > > > >
> > > > >                 |       EAPoL Packet       |        CAPWAP Packet
> > > > > |
> > > > >
> > > > >                 |                          |
> > > > > |
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         This proposal very simply solves the problem while
> > > > > directly addressing
> > > > >
> > > > >         the requirement for IEEE 802.11i Considerations.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         Cheers,
> > > > >
> > > > >
> > > > >
> > > > >         Saravanan
> > > > >
> > > > >
> > > > >
> > > > > _________________________________________________________________
> > > > > To unsubscribe or modify your subscription options, please visit:
> > > > > http://lists.frascone.com/mailman/listinfo/capwap
> > > > >
> > > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > > >
> > > > > _________________________________________________________________
> > > > > Get cheap fares online with MSN Travel
> > > http://www.msn.com.sg/travel/
> > > > >
> > > > _________________________________________________________________
> > > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20060919/9f9d0a4a/att
achment.htm 

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

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

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

End of Capwap Digest, Vol 11, Issue 32
**************************************

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

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