Subject: [Capwap] Vendor specific information

From: "Sudhanshu" <[email-masked]>
Date: Tue, 30 Jan 2007 18:34:25 -0800

I think to carry the vendor specific software version and hardware version
under AC Descriptor, WTP Descriptor, WTP board and Vendor specific payload
data looks rather kludge.

Why we can't carry this information as part of the "Vendor Specific Payload"
message element with reserved "Element id" for different information like

0 - HW

1 - SW

2 - boot etc.

And as part of the message -> message element binding, we can always mandate
that these elements are mandatory for specific messages like Discovery/Join
request/response etc. 

Currently there are several places where the vendor identifier information
is parsed and compatibility data need to be accessed which makes the
implementation bulky/inefficient. Virtually, it is introducing three
different types of vendor specific elements.

Any comments??

_Suds

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 30 Jan 2007 19:17:45 -0800

It is the way it is currently defined to allow other vendors to be able
to parse this data. If we made this a vendor specific message element,
then I would have no way of knowing the details of the devices I was
communicating with. It's not about inefficiency, it's about
interoperability.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Sudhanshu [mailto:[email-masked]] 
	Sent: Tuesday, January 30, 2007 6:34 PM
	To: [email-masked]
	Subject: [Capwap] Vendor specific information

	I think to carry the vendor specific software version and
hardware version under AC Descriptor, WTP Descriptor, WTP board and
Vendor specific payload data looks rather kludge.

	Why we can't carry this information as part of the "Vendor
Specific Payload" message element with reserved "Element id" for
different information like

	0 - HW

	1 - SW

	2 - boot etc.

	And as part of the message -> message element binding, we can
always mandate that these elements are mandatory for specific messages
like Discovery/Join request/response etc. 

	Currently there are several places where the vendor identifier
information is parsed and compatibility data need to be accessed which
makes the implementation bulky/inefficient. Virtually, it is introducing
three different types of vendor specific elements.

	Any comments??

	_Suds