Re: [Capwap] NAT issue and new message element

["Romascanu, Dan (Dan)" <[e-mail]>]

Second thought - adding a new message element would require the document to be Standards Track because it updates RFC 5415. Another IETF Last Call would be mandatory for this purpose. I was not thinking about reissuing 5415, but working in sections 9.1 and 9.2 of this document. 

To stay with informational status you need to use the vendorID. Would existing implementations accept vendorID = 0 as the 'CAPWAP vendorID' or would they report an error for a zero value? The protocol implementers need again have their saying, bit if zero can be an error than you can apply for a CAPWAP WG vendor ID (the registry at http://www.iana.org/assignments/enterprise-numbers is FCFS) and use it leaving the rest exactly as defined currently in the document.  

BTW - the current problem is a good example of the consequences of defining the management interface after the protocol, and not while the protocol is designed. Unfortunately many WGs in the IETF make this mistake. 

Regards,

Dan 

> -----Original Message-----
> From: young [mailto:[e-mail]] 
> Sent: Tuesday, January 26, 2010 12:14 PM
> To: Romascanu, Dan (Dan); [e-mail]; Mani, Mahalingam (Mani)
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 'Richard'
> Subject: NAT issue and new message element
> 
> 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