[Capwap] NAT issue and new message element

[young <[e-mail]>]

Dear Dan and chairs:

According to Pasi' comments, there is only issue left.
Please confirm whether the changes to the NAT issue is ok (two new MIB
objects would be added)?

Also, I need you give confirm:
////////////
To issue "section 9.1 and 9.2", I am clear with VendorID = 0. For method of
new CAPWAP message element, I need double confirm your suggestion. It means:
1) Remove the 9.1 and 9.2 in the MIB draft (also need update the MIB
object's reference part). Corresponding to them, add new messages elements
in the RFC5415. 
or
2) Defines an extensible messages element in the RFC5415. Based on this new
message format, updates the section 9.1 and 9.2 in the MIB drafts.

I suppose all of you mean 1), since this question is very important, I have
To double confirm with all of you before I send the proposal text to Pasi.

Regards
Richard


-----邮件原件-----
发件人: young [mailto:[e-mail]] 
发送时间: 2010年1月26日 18:05
收件人: '[e-mail]'
抄送: '[e-mail]'; '[e-mail]';
'[e-mail]'; '[e-mail]'; '[e-mail]';
'[e-mail]'
主题: There is one issue (commented by Pasi) left

Hi, Pasi:

Thanks a lot. 
So for your comments, there is only one issue (about section 9.1/9.2) left.
I would try to give reply by tomorrow.

BTW, in the end, once we could close this last issue, I would
Put all the changes required in one email, then asked you
give a double Confirm.
Thanks for your guidance. 

Regards
Richard

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2010年1月26日 17:49
收件人: [e-mail]
抄送: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
主题: RE: Please check my comments,thanks (draft-ietf-capwap-base-mib)

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



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

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