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

["Mani, Mahalingam (Mani)" <[e-mail]>]

Dear WG members,

Richard et al are on the threshold of IESG approval of (informational
track) MIB drafts: pending a valid issue raised by IESG (Pasi) to be
cleared up. Below is one of them. Please provide your recommendations or
positions on this query below on the authors' proposal.

You have till Feb 2, 2010 to mail to the list on this matter before we
conclude if the proposal is the one to go with.

Do comment at your earliest convenience without waiting till Feb 2.

Regards,
-mani
-----Original Message-----
From: young [mailto:[e-mail]] 
Sent: Wednesday, January 27, 2010 12:14 AM
To: [e-mail]
Cc: 'Yong Zhang'; [e-mail]
Subject: [Capwap] draft-ietf-capwap-base-mib-08: How about the base MIB
draft removes the section 9, and related MIB objects?

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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