Subject: RE: [Capwap] Addition to MIB issue

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Jan 2006 07:08:31 -0800

Dan is correct. The WG has already stated that we would create a CAPWAP
MIB. Therefore, I don't think that adding a tracker entry is in order
given that I am using tracker for the base draft.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
	Sent: Monday, January 23, 2006 6:12 AM
	To: Richard Gwee; Pat Calhoun (pacalhou); [email-masked]
	Subject: RE: [Capwap] Addition to MIB issue

	In other words, are you talking about defining a MIB? A SMIv2
definition of the management objects (for 'monitoring purposes, security
purposes, congestion control, feedback etc') could be used either
in-band with CAPWAP or out-of-band with SNMP.
	 
	I would like to observe that the WG has a chartered item for the
definition of a MIB module. It should go to WGLC this month actually.
The chairs would probably ask for a time extension. 
	 
	Regards,
	 
	Dan

________________________________

		From: Richard Gwee [mailto:[email-masked]] 
		Sent: Monday, January 23, 2006 3:55 PM
		To: Pat Calhoun (pacalhou); [email-masked]
		Subject: RE: [Capwap] Addition to MIB issue

		Hi Pat,

		I am sorry over the confusion. In this case, can you
create an issue thread?

		Issue: There exists a need for the CAPWAP protocol to
define its own current statistics and configuration items. It will be
good if the definition of such items can be explicitly stated at a
sufficient level. Functionalities for the use of such items should be
considered such as QoS monitoring, security purposes, congestion
control, feedback for example. To a certain extent, this can help to
improve the performance of the CAPWAP protocol.

		Recommendation: To include definition of the protocol's
own definition of configuration and statistics items. To also include
the purpose of these items in the area of monitoring purposes, security
purposes, congestion control, feedback etc.

		Thanks and regards

		Richard

________________________________

		From: Pat Calhoun (pacalhou) [mailto:[email-masked]]

		Sent: Saturday, January 21, 2006 3:38 AM
		To: Richard Gwee; [email-masked]
		Subject: RE: [Capwap] Addition to MIB issue

		Richard,

		Sorry, you've lost me, but the original request was to
provide a pointer of some form to the IEEE MIB variables.

		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

________________________________

			From: Richard Gwee [mailto:[email-masked]] 
			Sent: Thursday, January 19, 2006 8:11 PM
			To: Pat Calhoun (pacalhou); [email-masked]
			Subject: [Capwap] Addition to MIB issue

			Hi Pat,

			I refer to the issue on "Using MIB variable
names instead" on the issue tracker. In addition to using MIBs, there is
also a need for the protocol to define its own statistics and
configuration items. Such items can be used for functionalities that
include congestion monitoring, feedback etc.

			Thus I will like to recommend to include the
definition of the protocol's own statistics and configuration items and
that one of these statistics items to be used for congestion control and
feedback.

			Thanks and regards

			Richard

________________________________

			From: Pat Calhoun (pacalhou)
[mailto:[email-masked]] 
			Sent: Thursday, January 19, 2006 5:57 AM
			To: [email-masked]
			Subject: [Capwap] Done w/ Issue Tracker

			All,

			I believe that I've entered all entries posted
to the list after November 1st. If you have any change requests on the
list prior to that date, please forward them to me.

			The issue tracker can be found at
www.capwap.org. Please note that if you search with no filters, you will
find both open and resolved bugs. A normal "Show All" does not display
the resolved issues.

			Pat Calhoun
			CTO, Wireless Networking Business Unit
			Cisco Systems

________________________________

Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922
. www.rp.sg <http://www.rp.sg>  . Fax: +65 6415-1310 . 
 From March 2006, we will be located in our new home at 9 Woodlands
Avenue 9, Singapore 738964.

Republic Polytechnic, the first Institute of Higher Learning to fully
adopt the Problem-Based Learning approach in Singapore, continues to
strive towards best practices and maintain excellence in service
standards with the following certifications: Singapore Innovation Class
(SIC), Singapore Quality Class (SQC), People Developer Standards and
QEHS (ISO 9001, 14001 and OHSAS 18001)

________________________________

CONFIDENTIALITY CAUTION: This message is intended only for the use of
the individual or entity to whom it is addressed and contains
information that is privileged and confidential. If you, the reader of
this message, are not the intended recipient, you should not
disseminate, distribute or copy this communication. If you have received
this communication in error, please notify us immediately by return
email and delete the original message. Thank you. 

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

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

---

From: Darren <[email-masked]>
Date: Wed, 25 Jan 2006 10:41:37 -0700

I also support focusing monitoring and statistics efforts via the CAPWAP
MIB.

The base draft should maintain focus on configuration and control.

-Darren Loher

On 1/23/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> MIB. Therefore, I don't think that adding a tracker entry is in order given
> that I am using tracker for the base draft.
>
>
> Pat Calhoun
>  ------------------------------
> *From:* Romascanu, Dan (Dan) [mailto:[email-masked]]
> *Sent:* Monday, January 23, 2006 6:12 AM
> *To:* Richard Gwee; Pat Calhoun (pacalhou); [email-masked]
> *Subject:* RE: [Capwap] Addition to MIB issue
>
>  *In other words, are you talking about defining a MIB? A SMIv2 definition
> of the management objects (for 'monitoring purposes, security purposes,
> congestion control, feedback etc') could be used either in-band with CAPWAP
> or out-of-band with SNMP.*
> **
> *I would like to observe that the WG has a chartered item for the
> definition of a MIB module. It should go to WGLC this month actually. The
> chairs would probably ask for a time extension. *
> **
> *Regards,*
> **
> *Dan*
> **
>
>
> **
>
>  ------------------------------
> *From:* Richard Gwee [mailto:[email-masked]]
> *Sent:* Monday, January 23, 2006 3:55 PM
> *To:* Pat Calhoun (pacalhou); [email-masked]
> *Subject:* RE: [Capwap] Addition to MIB issue
>
>  Hi Pat,
>
>
>
> I am sorry over the confusion. In this case, can you create an issue
> thread?
>
>
>
> Issue: There exists a need for the CAPWAP protocol to define its own
> current statistics and configuration items. It will be good if the
> definition of such items can be explicitly stated at a sufficient level.
> Functionalities for the use of such items should be considered such as QoS
> monitoring, security purposes, congestion control, feedback for example. To
> a certain extent, this can help to improve the performance of the CAPWAP
> protocol.
>
>
>
> Recommendation: To include definition of the protocol's own definition of
> configuration and statistics items. To also include the purpose of these
> items in the area of monitoring purposes, security purposes, congestion
> control, feedback etc.
>
>
>
> Thanks and regards
>
> Richard
>
>
>
>
>  ------------------------------
>
> *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]]
> *Sent:* Saturday, January 21, 2006 3:38 AM
> *To:* Richard Gwee; [email-masked]
> *Subject:* RE: [Capwap] Addition to MIB issue
>
>
>
> Richard,
>
>
>
> Sorry, you've lost me, but the original request was to provide a pointer
> of some form to the IEEE MIB variables.
>
>
>
> Pat Calhoun
>  ------------------------------
>
> *From:* Richard Gwee [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2006 8:11 PM
> *To:* Pat Calhoun (pacalhou); [email-masked]
> *Subject:* [Capwap] Addition to MIB issue
>
> Hi Pat,
>
>
>
> I refer to the issue on "Using MIB variable names instead" on the issue
> tracker. In addition to using MIBs, there is also a need for the protocol to
> define its own statistics and configuration items. Such items can be used
> for functionalities that include congestion monitoring, feedback etc.
>
>
>
> Thus I will like to recommend to include the definition of the protocol's
> own statistics and configuration items and that one of these statistics
> items to be used for congestion control and feedback.
>
>
>
> Thanks and regards
>
> Richard
>
>
>  ------------------------------
>
> *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]]
> *Sent:* Thursday, January 19, 2006 5:57 AM
> *To:* [email-masked]
> *Subject:* [Capwap] Done w/ Issue Tracker
>
>
>
> All,
>
>
>
> I believe that I've entered all entries posted to the list after November
> 1st. If you have any change requests on the list prior to that date, please
> forward them to me.
>
>
>
> The issue tracker can be found at www.capwap.org. Please note that if you
> search with no filters, you will find both open and resolved bugs. A normal
> "Show All" does not display the resolved issues.
>
>
>
> Pat Calhoun
>  ------------------------------
>
> . www.rp.sg . Fax: +65 6415-1310 .
> * From March 2006, we will be located in our new home at 9 Woodlands
> Avenue 9, Singapore 738964.*
>
> *Republic Polytechnic, the first Institute of Higher Learning to fully
> adopt the Problem-Based Learning approach in Singapore, continues to strive
> towards best practices and maintain excellence in service standards with the
> following certifications: Singapore Innovation Class (SIC), Singapore
> Quality Class (SQC), People Developer Standards and QEHS (ISO 9001, 14001
> and OHSAS 18001)*
>  ------------------------------
>
> CONFIDENTIALITY CAUTION: This message is intended only for the use of the
> individual or entity to whom it is addressed and contains information that
> is privileged and confidential. If you, the reader of this message, are not
> the intended recipient, you should not disseminate, distribute or copy this
> communication. If you have received this communication in error, please
> notify us immediately by return email and delete the original message. Thank
> you.
>
>
>
>