| Re: Please check my comments, thanks (draft-ietf-capwap-base-mib) | <– Date –> <– Thread –> |
|
From: Pasi.Eronen (Pasi.Eronen |
|
| Date: Tue, 26 Jan 2010 01:50:03 -0800 (PST) | |
shiyang 00338 wrote:
>> 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.
OK.
>>> [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.
Looks good!
<snip>
(I see there're separate emails about the NAT-related things,
so I'm omitting those from here.)
<snip>
>>> [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 }
Looks good!
Best regards,
Pasi
-
Please check my comments,thanks shiyang 00338, January 23 2010
- Re: Please check my comments, thanks (draft-ietf-capwap-base-mib) Pasi.Eronen, January 26 2010
- There is one issue (commented by Pasi) left young, January 26 2010
Results generated by Tiger Technologies using MHonArc.