Capwap Mailing List: Re: draft-ietf-capwap-base-mib-08: How about the base MIB draft removes the section 9, and related MIB objects?

[Margaret Wasserman (mrw]

<chair hat=off>

As a former CAPWAP implementor (although I no longer work for that  
company), I think it would be fine to remove section 9 from the MIB  
module.  The rest of the MIB would still be useful for managing a  
CAPWAP system.

</chair>

Margaret


On Jan 27, 2010, at 3:14 AM, young wrote:

> Hi, All:
>
> I have one question here. How about the base MIB draft
> (draft-ietf-capwap-base-mib-08) removes the section 9,
> and related MIB objects?
>
> Before I list the changes the editors intend to make,
> I give some background info and reason here.
>
> As you know, in order to make some CAPWAP (RFC5415) variable and
> timer such as DataChannelKeepAlive (MIB draft, section 9)
> viewable by SNMP, the base MIB defines some MIB objects to model them.
> Although RFC5415 already defines lots of CAPWAP message elements for
> protocol variable and timer, some variables such as  
> DataChannelKeepAlive
> are not there.
> To make such variables (like DataChannelKeepAlive) manageable,
> the base MIB has to define some messages in the draft section 9  
> based on
> the Vendor Specific Payload defined in the RFC5415.
> During the IESG review, Pasi raised a question: Which vendor ID would
> be used here? Yes, it is a problem.
>
> But it also gives editors a chance to re-think.
> I think the first version (RFC) of this MIB draft should be tight,
> and should try to reuse existing MIB modules.
> I think the section 9 are important from CAPWAP protocol perspective,
> but from operators perspective, they may not need observe so many
> details of a protocol by MIB module.
> Any way, the other more important (key) info such as WTP, station
> are already fully defined. The core part of MIB is ready.
>
> This MIB draft is informational and not a standard track.
> It has chance to "grow up" when there are more vendors support and  
> more
> feedback from operators. Later, when and if the protocol is revised,  
> some
> new message elements would become part of a revision of RFC5415.
> If such message offer such variable and timer, also such info require
> MIB support, then we would like add them in future.
>
> It should be clarified:
> 1) All the MIB objects (corresponding to Section 9)
> to be removed are optional objects in the current MIB draft.
> 2) Even above MIB objects are removed, the MIB draft still offer lots
> of info of CAPWAP variable and timer. See: CAPWAP Base Parameters  
> Group.
> It has the capwapBaseAcDataCheckTimer which models the element in the
> Section 4.7.4,RFC 5415.
>
> current post:
> http://www.ietf.org/id/draft-ietf-capwap-base-mib-08.txt
>
> If WG agree to it, editors suggest the following changes would be  
> made.
> 1) Remove the section 9 CAPWAP Message Element Extension. BTW, the  
> section
> is very independent.
> 2) Remove the related MIB objects corresponding to the Message  
> elements
> in the section 9.
> a) In the CapwapBaseWtpTable, it would remove the objects:
> capwapBaseWtpMaxDiscoveries, capwapBaseWtpMaxFailedDTLSSessionRetry,
> capwapBaseWtpMaxRetransmit, capwapBaseWtpDataChannelKeepAliveTimer,
> capwapBaseWtpDataChannelDeadInterval, capwapBaseWtpDiscoveryInterval,
> capwapBaseWtpDTLSSessionDeleteTimer, capwapBaseWtpImageDataStartTimer,
> capwapBaseWtpRetransmitInterval
> b)In the CapwapBaseWtpProfileTable,  it would remove the objects:
> capwapBaseWtpProfileWtpSilentInterval,  
> capwapBaseWtpProfileWtpWaitDTLSTimer
> 3)Since section 8 has a example of above tables, the related text
> need to be updated.
>
> Kindly give your comments, thanks a lot.
>
> Regards
> Richard
>
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap