[Capwap] You are correct, I would add a second InetAddressType field
young <young@h3c.com> Tue, 26 January 2010 10:00 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 B2D973A691E for <ietfarch-capwap-archive@core3.amsl.com>; Tue, 26 Jan 2010 02:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.788
X-Spam-Level:
X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 EOiMB-YSC+gu for <ietfarch-capwap-archive@core3.amsl.com>; Tue, 26 Jan 2010 02:00:06 -0800 (PST)
Received: from lists.tigertech.net (lists.tigertech.net [64.62.209.34]) by core3.amsl.com (Postfix) with ESMTP id D12DF3A6904 for <capwap-archive@lists.ietf.org>; Tue, 26 Jan 2010 02:00:06 -0800 (PST)
Received: from zoidberg.tigertech.net (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B0209E181CF for <capwap-archive@lists.ietf.org>; Tue, 26 Jan 2010 02:00:16 -0800 (PST)
Received: from mx3.tigertech.net (morbo.tigertech.net [67.131.251.53]) by lists.tigertech.net (Postfix) with ESMTP id D13CAE240E1 for <capwap@lists.tigertech.net>; Tue, 26 Jan 2010 02:00:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 8D15A19DD3C for <capwap@frascone.com>; Tue, 26 Jan 2010 02:00:07 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at morbo.tigertech.net
Received: from mx3.tigertech.net (localhost [127.0.0.1]) by mx3.tigertech.net (Postfix) with ESMTP id 6843219DD33 for <capwap@frascone.com>; Tue, 26 Jan 2010 02:00:06 -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.56]) by mx3.tigertech.net (Postfix) with ESMTP for <capwap@frascone.com>; Tue, 26 Jan 2010 02:00:06 -0800 (PST)
Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KWU00KAIN0J4J@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 26 Jan 2010 18:12:20 +0800 (CST)
Received: from h3cmta02-ds.h3c.com ([172.25.12.70]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KWU00KD4N0GNV@h3cml02-in.huawei-3com.com> for capwap@frascone.com; Tue, 26 Jan 2010 18:12:19 +0800 (CST)
Received: from smtp1.h3c.com ([172.25.14.252]) by h3cmta02-ds.h3c.com (Lotus Domino Release 8.5FP1) with ESMTP id 2010012618000061-1853396 ; Tue, 26 Jan 2010 18:00:00 +0800
Received: from unknown (HELO s00338) ([10.154.68.122]) by smtp1.h3c.com with ESMTP; Tue, 26 Jan 2010 17:56:52 +0800
Date: Tue, 26 Jan 2010 17:59:50 +0800
From: young <young@h3c.com>
In-reply-to: <808FD6E27AD4884E94820BC333B2DB775841199B3F@NOK-EUMSG-01.mgdnok.nokia.com>
To: Pasi.Eronen@nokia.com
Message-id: <007601ca9e6e$4d038d30$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-26 18:00:00, Serialize by Router on h3cmta02-ds/h3c(Release 8.5FP1|June 15, 2009) at 2010-01-26 18:00:03, Serialize complete at 2010-01-26 18:00:03
Thread-index: Acqc5ww6YpBolkM+TNGcQOYzRM31DwAmy8BgADqxcKAAADlt8A==
Cc: capwap@frascone.com, yozhang@gmail.com, iesg@ietf.org
Subject: [Capwap] You are correct, I would add a second InetAddressType field
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: Thanks a lot. Yes, you are correct, it may happen. So I would add a second InetAddressType field. For this change, is there any comment from WG or IESG? Regards Richard -----邮件原件----- 发件人: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 发送时间: 2010年1月26日 17:53 收件人: young@h3c.com 抄送: capwap@frascone.com; yozhang@gmail.com; dromasca@avaya.com; iesg@ietf. org 主题: RE: Whether such changes could close the NAT related issues? Thanks. Hi, I think you also need to add a second InetAddressType field; it is not impossible that the address in the message element could be IPv6, but the IP header would have IPv4, or vice versa. Otherwise, this looks good! Best regards, Pasi > -----Original Message----- > From: ext young [mailto:young@h3c.com] > Sent: 25 January, 2010 08:13 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: capwap@frascone.com; 'Yong Zhang'; 'Romascanu, Dan (Dan)'; > iesg@ietf.org > Subject: Whether such changes could close the NAT related issues? > Thanks. > > 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