[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