[Capwap] Whether such changes could close the NAT related issues? Thanks.
young <young@h3c.com> Mon, 25 January 2010 06:14 UTC
Return-Path: <capwap-bounces+capwap-archive=lists.ietf.org@frascone.com>
X-Original-To: ietfarch-capwap-archive@core3.amsl.com
Delivered-To: ietfarch-capwap-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB803A67BD for <ietfarch-capwap-archive@core3.amsl.com>; Sun, 24 Jan 2010 22:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.618
X-Spam-Level: *
X-Spam-Status: No, score=1.618 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moOPXGL-GHJD for <ietfarch-capwap-archive@core3.amsl.com>; Sun, 24 Jan 2010 22:14:00 -0800 (PST)
Received: from lists.tigertech.net (lists.tigertech.net [64.62.209.34]) by core3.amsl.com (Postfix) with ESMTP id F26D33A67E1 for <capwap-archive@lists.ietf.org>; Sun, 24 Jan 2010 22:13:59 -0800 (PST)
Received: from zoidberg.tigertech.net (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 35CE5E18035 for <capwap-archive@lists.ietf.org>; Sun, 24 Jan 2010 22:14:05 -0800 (PST)
Received: from mx1.tigertech.net (mx1.tigertech.net [64.62.209.31]) by lists.tigertech.net (Postfix) with ESMTP id 0C1FAE240E1 for <capwap@lists.tigertech.net>; Sun, 24 Jan 2010 22:13:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id EA4E134AC025 for <capwap@frascone.com>; Sun, 24 Jan 2010 22:13:57 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from mx1.tigertech.net (localhost [127.0.0.1]) by mx1.tigertech.net (Postfix) with ESMTP id 0058734AC026 for <capwap@frascone.com>; Sun, 24 Jan 2010 22:13:57 -0800 (PST)
X-TigerTech-Content-Filter: Clean
X-TigerTech-Spam-Status: Level 0 (High) (P0); Whitelisted TTSSA (young@h3c.com whitelisted)
Received: from huawei-3com.com (unknown [60.191.123.50]) by mx1.tigertech.net (Postfix) with ESMTP for <capwap@frascone.com>; Sun, 24 Jan 2010 22:13:56 -0800 (PST)
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 <0KWS00CITHAUGN@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 25 Jan 2010 14:13:42 +0800 (CST)
Received: from h3cmta02-ds.h3c.com ([172.25.12.70]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KWS009G8HAUZF@h3cml01-in.huawei-3com.com> for capwap@frascone.com; Mon, 25 Jan 2010 14:13:42 +0800 (CST)
Received: from smtp1.h3c.com ([172.25.14.252]) by h3cmta02-ds.h3c.com (Lotus Domino Release 8.5FP1) with ESMTP id 2010012514134230-1795362 ; Mon, 25 Jan 2010 14:13:42 +0800
Received: from unknown (HELO s00338) ([10.154.68.122]) by smtp1.h3c.com with ESMTP; Mon, 25 Jan 2010 14:10:37 +0800
Date: Mon, 25 Jan 2010 14:13:19 +0800
From: young <young@h3c.com>
In-reply-to: <mailman.97.1264331939.2407.capwap@frascone.com>
To: pasi.eronen@nokia.com
Message-id: <000601ca9d85$7ea05b50$7a449a0a@h3c.huawei3com.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook, Build 10.0.6856
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-MIMETrack: Itemize by SMTP Server on h3cmta02-ds/h3c(Release 8.5FP1|June 15, 2009) at 2010-01-25 14:13:42, Serialize by Router on h3cmta02-ds/h3c(Release 8.5FP1|June 15, 2009) at 2010-01-25 14:13:42, Serialize complete at 2010-01-25 14:13:42
Thread-index: Acqc5ww6YpBolkM+TNGcQOYzRM31DwAmy8Bg
Cc: capwap@frascone.com, 'Yong Zhang' <yozhang@gmail.com>, iesg@ietf.org
Subject: [Capwap] Whether such changes could close the NAT related issues? Thanks.
X-BeenThere: capwap@frascone.com
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: A list for CAPWAP technical discussions <capwap.frascone.com>
List-Post: <mailto:capwap@frascone.com>
X-Tigertech-Mailman-Hint: 636170776170
List-Subscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=subscribe>
List-Unsubscribe: <http://lists.frascone.com/mailman/listinfo/capwap>, <mailto:capwap-request@frascone.com?subject=unsubscribe>
List-Archive: <http://lists.frascone.com/pipermail/capwap>
List-Help: <mailto:capwap-request@frascone.com?subject=help>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com
Hi, Pasi: I thought about the NAT issues again. For NAT issues, how about to do the following change? Whether could it close your two comments? Thanks your comments. 1) Update the description and clarify the address is IP packet header capwapBaseWtpStateWtpIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the IP address of a WTP which corresponds to IP address in the IP packet header. The format of this IP address is determined by the corresponding instance of object capwapBaseWtpStateWtpIpAddressType." REFERENCE "Section 4. of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 3 } 2) Add a new object capwapBaseWtpStateWtpLocalIpAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the local IP address of a WTP and which models the CAPWAP field [RFC5415] CAPWAP Local IPv4 Address or CAPWAP Local IPv6 Address. If a Network Address Translation (NAT) device is present between WTP and AC, the value of capwapBaseWtpStateWtpLocalIpAddress will be different to the vale of capwapBaseWtpStateWtpIpAddress. The format of this IP address is determined by the corresponding instance of object capwapBaseWtpStateWtpIpAddressType." REFERENCE "Section 4.6.11 and 4.6.12. of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 4 } Then the comment would be updated as followed: >> - capwapBaseWtpStateWtpIpAddressType: is this the IP address of the >> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6 >> Address" message element? > > [Richard] > In case that a MIB object of InetAddress type is defined, > one more MIB object of InetAddressType type is required. > For this reason, the capwapBaseWtpStateWtpIpAddressType is defined. This does not answer my question: is this the address as seen by the AC, or the address sent in the message element? (which will be different if the WTP is behind a NAT) ////////////////////////// [Richard] Please see the update of capwapBaseWtpStateWtpIpAddress. >> - A question: Did the WG consider including NAT-related information >> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and >> what the other address (depending on the question above) was? >> [Richard] > > Yes, CAPWAP has NAT Considerations. But other tunnel protocol > (suppose GRE or any other example) may also have such function. I > think there should have a generic MIB interface (no matter it exists > or not) Which would offer NAT-related information, while such > function is not A part of CAPWAP MIB (or other similar tunnel > protocol). I disagree. The NAT traversal functionality here is a functionality of the CAPWAP protocol, and probably cannot be managed by any generic MIB. However, the question I asked was whether this was discussed in the WG. Chairs, you do recall? //////////// [Richard] Besides the capwapBaseWtpStateWtpIpAddress, a new MIB object capwapBaseWtpStateWtpLocalIpAddress which indicates the local address Would be added. Regards Richard -----邮件原件----- 发件人: capwap-request@frascone.com [mailto:capwap-request@frascone.com] 发送时间: 2010年1月24日 19:19 收件人: capwap@frascone.com 主题: Capwap Digest, Vol 50, Issue 13 Send Capwap mailing list submissions to capwap@frascone.com 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 capwap-request@frascone.com You can reach the person managing the list at capwap-owner@frascone.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Capwap digest..." Today's Topics: 1. Please check my comments,thanks (shiyang 00338) ---------------------------------------------------------------------- Message: 1 Date: Sun, 24 Jan 2010 11:38:10 +0800 From: shiyang 00338 <young@h3c.com> Subject: [Capwap] Please check my comments,thanks To: Pasi.Eronen@nokia.com Cc: capwap-chairs@tools.ietf.org, capwap@frascone.com, yozhang@gmail.com, iesg@ietf.org, draft-ietf-capwap-base-mib@tools.ietf.org Message-ID: <38fcf3389d19.389d1938fcf3@huawei-3com.com> Content-Type: text/plain; charset=gb2312 Hi, Pasi: Thanks. Please check my comments under "///". BTW, I am (have to) using web mail which may cause the format looks ugly. Sorry. Regards Richard young@h3c.com wrote: >> - The MIB provides a writable object for switching between X.509 certs >> and PSK authentication for DTLS. Since the MIB can't actually >> configure the PSK (or X.509 certificate and corresponding private key, >> for that matter), is this object actually useful? > [Richard] I think the configurations such as X.509 certificate > belong to the configuration of DTLS protocol parameters, DTLS > protocol should have (I don't know) a MIB corresponding to such > function, I think such function is out of the scope of CAPWAP base > MIB. When operators do such function, he should operate DTLS' MIB. > For this reason, Base MIB does not offer such interface. The > writable object in the Base MIB is only to let operator choose the > DTLS Authentication policy from CAPWAP tunnel security > perspective. This operation is from CAWPAP perspective, although > this MIB object felt lonely in the Base MIB. I'm still not sure the MIB object is useful. First of all, such DTLS configuration MIB does not currently exist (and is not even planned). Second, it hard-codes an assumption that all WTPs connected to an AC use same type of authentication. The CAPWAP protocol itself would allow some WTPs so use X.509 and others PSK, so if your AC implementation supports this, it can't implement this MIB object. BTW, the same limitation seems to apply to e.g. capwapBaseDataChannelDTLSPolicyConfig, too -- if your AC supports configuring DTLS for only some WTPs (perhaps those located in physically less secure environments), it cannot implement this MIB object. If the WG feels this MIB object is anyway useful, at the very least it should point out that many ACs may not be able to implement it. //////////////////// [Richard] Any way, the configuration of such authentication parameter should not be in the scope of CAPWAP MIB (I explained it in the last email). As per Pasi's comments, I agree to remove both capwapBaseControlChannelAuthenConfig and capwapBaseDataChannelDTLSPolicyConfig. >> - It seems capwapBaseWtpState indicates the AC's CAPWAP FSM state >> for each WTP, not the WTP's FSM? (which, at any single point of >> time, be slighly different) > > [Richard] > Yes, capwapBaseWtpState indicates the AC's CAPWAP FSM state for > each WTP, not the WTP's FSM. The capwapBaseWtpState is a MIB object > on the AC. OK; please clarify the description accordingly. ////////// [Richard] The description would be modified: capwapBaseWtpStateTable OBJECT-TYPE SYNTAX SEQUENCE OF CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that indicate the AC's CAPWAP FSM state for each WTP, and helps the operator to query the WTPs' current configuration." ::= { capwapBaseWtps 2 } capwapBaseWtpStateEntry OBJECT-TYPE SYNTAX CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the AC's CAPWAP FSM state for each WTP. Also, the operator could query the current configuration of a WTP by using the identifier of the corresponding WTP profile." INDEX { capwapBaseWtpStateWtpId } ::= { capwapBaseWtpStateTable 1 } capwapBaseWtpStateEntry OBJECT-TYPE SYNTAX CapwapBaseWtpStateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A set of objects that display the AC's CAPWAP FSM state for each WTP. Also, the operator could query the current configuration of a WTP by using the identifier of the corresponding WTP profile." INDEX { capwapBaseWtpStateWtpId } ::= { capwapBaseWtpStateTable 1 } capwapBaseWtpState OBJECT-TYPE SYNTAX INTEGER { dtls(1), join(2), image(3), configure(4), dataCheck(5), run(6), reset(7), dtlsTeardown(8), unknown(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the various possible the AC's CAPWAP FSM state for each WTP. The following enumerated values are supported: dtls(1) - DTLS negotiation states, which include DTLS setup, authorize, DTLS connect join(2) - The WTP is joining with the AC image(3) - The WTP is downloading software configure(4) - The WTP is getting configuration from the AC dataCheck(5) - The AC is waiting for the Data Channel Keep Alive Packet run(6) - The WTP enters the running state reset(7) - The AC transmits a reset request message to the WTP dtlsTeardown(8) - DTLS session is tear down unknown(9) - Operator already prepared configuration for the WTP, while the WTP has not contact with the AC till now" REFERENCE "Section 2.3.1. of CAPWAP Protocol Specification, RFC 5415." ::= { capwapBaseWtpStateEntry 5 } The section 6 also needs change: 4) capwapBaseWtpStateTable The WTPs status table is used to indicate the AC's CAPWAP FSM state for each WTP, and helps operator to query WTPs' current configuration. > >- Section 9.1/9.2: it looks like these should be new CAPWAP Message > >Element Types, not Vendor Specific Payloads? (and the current text > >doesn't say what vendor ID would be used) > > [Richard] The Section 9.1/9.2 to let those CAPWAP variables > manageable. The messages are important. Yes, the current text > doesn't say what vendor ID would be used. Could I put my company's > ID (now it is H3C which belongs to 3com, would be HP soon since HP > acquire 3com)? I don't know whether it is a acceptable way. The > vendor use their private ID could work, but not a good way. This is not compatible with the way Vendor Specific Payloads are defined in RFC 5415: unless the AC is from the same vendor (or explicitly supports the other vendor's extensions), it cannot know what Element ID value "1" means (or what the contents are). Since these payloads are supposed to be work even when the AC and WTP are from different vendors, they need to be normal message elements. //////////////// [Richard] What's CAPWAP WG opionion? > > - Why is "dns" allowed as capwapBaseWtpStateWtpIpAddressType? (the AC > > obviously sees the IP address the WTP's connection comes from, but not > > the DNS name?) > > [Richard] > You are correct. "dns"?should be removed. OK. >> - capwapBaseWtpStateWtpIpAddressType: is this the IP address of the >> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6 >> Address" message element? > > [Richard] > In case that a MIB object of InetAddress type is defined, > one more MIB object of InetAddressType type is required. > For this reason, the capwapBaseWtpStateWtpIpAddressType is defined. This does not answer my question: is this the address as seen by the AC, or the address sent in the message element? (which will be different if the WTP is behind a NAT) ////////////////////////// [Richard] Should be the address sent in the message element. I would give confirm after checking RFC5415 more. >> - A question: Did the WG consider including NAT-related information >> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and >> what the other address (depending on the question above) was? >> [Richard] > > Yes, CAPWAP has NAT Considerations. But other tunnel protocol > (suppose GRE or any other example) may also have such function. I > think there should have a generic MIB interface (no matter it exists > or not) Which would offer NAT-related information, while such > function is not A part of CAPWAP MIB (or other similar tunnel > protocol). I disagree. The NAT traversal functionality here is a functionality of the CAPWAP protocol, and probably cannot be managed by any generic MIB. However, the question I asked was whether this was discussed in the WG. Chairs, you do recall? //////////// [Richard] Yes, it is valid to have such NAT info. I do fully agree. The question in my mind is how to design MIB to support such function. For MIB design, I alway try to keep the MIB file short and reuse any existing MIBs. My initial point is that may could have a generic MIB for NAT function. I am not sure and want to ask: Anyone could you tell me whether it could have? Thanks. I am ok to add such MIB objects in the CAPWAP MIB, but I really want to give a good design without any unnessary redundancy. > >- capwapBaseMacAclId: this seems to limit the number of ACL entries to > >255 -- why? (although RFC 5415 doesn't support sending more than 255 > >ACL entries in a single "Add MAC ACL Entry" message element, the AC > >could send more than one of those) > > [Richard] You are correct, it is not required to give a scope limit > to the capwapBaseMacAclId. The editors misunderstood the value 255 > mentioned in the RFC5415. OK. //////////////// [Richard] the change would be: capwapBaseMacAclId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the unique identifier of an ACL." ::= { capwapBaseMacAclEntry 1 } >> - capwapBaseWtpProfileWtpStaticIpType: How would the "ipv4z" type >> be used by the CAPWAP protocol? (it doesn't seem to use the zone >> index in any way) > > [Richard] In fact, I am not sure. Dan, Could you confirm whether > CAPWAP support it? OK; looking forward to hearing the answer... Best regards, Pasi ----- ??? ----- ?: Pasi.Eronen@nokia.com ??: ???, ?? 22?, 2010 ??10:18 ??: RE: comments to Pasi's opinion (draft-ietf-capwap-base-mib) > young@h3c.com wrote: > > >> - The MIB provides a writable object for switching between > X.509 certs > >> and PSK authentication for DTLS. Since the MIB can't actually > >> configure the PSK (or X.509 certificate and corresponding > private key, > >> for that matter), is this object actually useful? > > > [Richard] I think the configurations such as X.509 certificate > > belong to the configuration of DTLS protocol parameters, DTLS > > protocol should have (I don't know) a MIB corresponding to such > > function, I think such function is out of the scope of CAPWAP base > > MIB. When operators do such function, he should operate DTLS' MIB. > > For this reason, Base MIB does not offer such interface. The > > writable object in the Base MIB is only to let operator choose the > > DTLS Authentication policy from CAPWAP tunnel security > > perspective. This operation is from CAWPAP perspective, although > > this MIB object felt lonely in the Base MIB. > > I'm still not sure the MIB object is useful. First of all, such DTLS > configuration MIB does not currently exist (and is not even > planned). Second, it hard-codes an assumption that all WTPs connected > to an AC use same type of authentication. The CAPWAP protocol itself > would allow some WTPs so use X.509 and others PSK, so if your AC > implementation supports this, it can't implement this MIB object. > > BTW, the same limitation seems to apply to > e.g. capwapBaseDataChannelDTLSPolicyConfig, too -- if your AC supports > configuring DTLS for only some WTPs (perhaps those located in > physically less secure environments), it cannot implement this MIB > object. > > If the WG feels this MIB object is anyway useful, at the very > least it > should point out that many ACs may not be able to implement it. > > >> - It seems capwapBaseWtpState indicates the AC's CAPWAP FSM state > >> for each WTP, not the WTP's FSM? (which, at any single point of > >> time, be slighly different) > > > > [Richard] > > Yes, capwapBaseWtpState indicates the AC's CAPWAP FSM state for > > each WTP, not the WTP's FSM. The capwapBaseWtpState is a MIB object > > on the AC. > > OK; please clarify the description accordingly. > > > >- Section 9.1/9.2: it looks like these should be new CAPWAP Message > > >Element Types, not Vendor Specific Payloads? (and the current text > > >doesn't say what vendor ID would be used) > > > > [Richard] The Section 9.1/9.2 to let those CAPWAP variables > > manageable. The messages are important. Yes, the current text > > doesn't say what vendor ID would be used. Could I put my company's > > ID (now it is H3C which belongs to 3com, would be HP soon since HP > > acquire 3com)? I don't know whether it is a acceptable way. The > > vendor use their private ID could work, but not a good way. > > This is not compatible with the way Vendor Specific Payloads are > defined in RFC 5415: unless the AC is from the same vendor (or > explicitly supports the other vendor's extensions), it cannot > know what Element ID value "1" means (or what the contents are). > > Since these payloads are supposed to be work even when the AC and WTP > are from different vendors, they need to be normal message elements. > > > > - Why is "dns" allowed as capwapBaseWtpStateWtpIpAddressType? > (the AC > > > obviously sees the IP address the WTP's connection comes from, > but not > > > the DNS name?) > > > > [Richard] > > You are correct. "dns"?should be removed. > > OK. > > >> - capwapBaseWtpStateWtpIpAddressType: is this the IP address of the > >> WTP as seen by the AC, or as sent in the "CAPWAP Local IPv4/6 > >> Address" message element? > > > > [Richard] > > In case that a MIB object of InetAddress type is defined, > > one more MIB object of InetAddressType type is required. > > For this reason, the capwapBaseWtpStateWtpIpAddressType is defined. > > This does not answer my question: is this the address as seen by the > AC, or the address sent in the message element? (which will be > different if the WTP is behind a NAT) > > >> - A question: Did the WG consider including NAT-related information > >> CapwapBaseWtpStateEntry? For example, whether NAT was detected, and > >> what the other address (depending on the question above) was? > >> [Richard] > > > > Yes, CAPWAP has NAT Considerations. But other tunnel protocol > > (suppose GRE or any other example) may also have such function. I > > think there should have a generic MIB interface (no matter it exists > > or not) Which would offer NAT-related information, while such > > function is not A part of CAPWAP MIB (or other similar tunnel > > protocol). > > I disagree. The NAT traversal functionality here is a > functionality of > the CAPWAP protocol, and probably cannot be managed by any generic > MIB. > > However, the question I asked was whether this was discussed > in the WG. Chairs, you do recall? > > > >- capwapBaseMacAclId: this seems to limit the number of ACL > entries to > > >255 -- why? (although RFC 5415 doesn't support sending more > than 255 > > >ACL entries in a single "Add MAC ACL Entry" message element, > the AC > > >could send more than one of those) > > > > [Richard] You are correct, it is not required to give a scope limit > > to the capwapBaseMacAclId. The editors misunderstood the value 255 > > mentioned in the RFC5415. > > OK. > > >> - capwapBaseWtpProfileWtpStaticIpType: How would the "ipv4z" type > >> be used by the CAPWAP protocol? (it doesn't seem to use the zone > >> index in any way) > > > > [Richard] In fact, I am not sure. Dan, Could you confirm whether > > CAPWAP support it? > > OK; looking forward to hearing the answer... > > Best regards, > Pasi > > ------------------------------ _________________________________________________________________ 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 50, Issue 13 ************************************** _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap