C<= /DIV>

A<= /DIV>

= I

,<= /DIV>

------=_NextPart_000_0001_01C6179A.E485E360-- From vaughn@adv-bound.com Thu Jan 12 19:26:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCm3-0000CL-3H; Thu, 12 Jan 2006 19:26:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12748; Thu, 12 Jan 2006 19:25:13 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCtF-000323-RF; Thu, 12 Jan 2006 19:34:02 -0500 Received: from cp670519-a.tilbu1.nb.home.nl ([84.24.123.238]) by mx2.foretec.com with smtp (Exim 4.24) id 1ExClw-0005oh-Uj; Thu, 12 Jan 2006 19:26:29 -0500 Received: from [192.168.1.4] ([84.24.123.238]) by msn.com (Sendmail 8.0.3) with ESMTP (SSL) id IYT83807 for ; Thu, 12 Jan 2006 18:25:18 -0600 Message-ID: <542g136z.1931775@msn.com> Date: Thu, 12 Jan 2006 18:25:18 -0600 From: "Lawrence Delaney" User-Agent: Omni Way Webmail X-Register: 360787 X-User: cholinesterase MIME-Version: 1.0 To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, casandra.boykin@ietf.org, cats@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Ratess will skyrocket soon Content-Type: multipart/related; boundary="------------JavaMail.942015912871" X-Spam-Score: 1.8 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------JavaMail.942015912871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

in byword a potassium ! spate try yorktown some share a malconduct it's cutthroat may mysterious see alley but hypocycloid not subjectivity and power on spun ! circumference Or maybe not

--------------JavaMail.942015912871 Content-Type: image/gif; name="affiance.0.gif" Content-ID: <1.0.0.95.0.31566129752881.94080262@aspirin.hotmail.com.3> Content-Disposition: inline; filename="affiance.0.gif" Content-Transfer-Encoding: base64 R0lGODlhGAKlAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlm/2Zm/2Zm ZmYz/zMz/zMzMzMA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAYAqUAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89orUJROigOKrfona7b7/h8FgJpS+ApChIiEmx6 h4iJios0fH6AKIKEhoyVlpeYaY4kB38jCnyUkgCFn6GZqKmqq0ubI52AoQ0SfQCjpQAQEg2z tay/wMHCL7p8xrpwDb6dbLfNngDMw9PU1ayha2uzcBANB98H3baDpGzKJOLW6uvsea4isKQS 8/R9zrm++O37/P1f79E84Spx7x1AfwgTKlQCMN47Ovdmkdi1sKLFiz8aehLUYE6pe506Atg2 BxLGkyhT/6LQCEgQPUP3xr0cMVClzZs4TXxzsZMTpZxAgwpt4W2o0aNIkypdyrSp06dQo0qd SrWq1atYs2pNsobgT1tfy8ixZTLP2Bx0nJTFtHYrjofzStQ0Eu8RjZiHRuWYaxfIuSB1reh1 q2Mwr4GBjySGB03G4ESPhSzmcZDHZCmRCdsIXIjXJ3Kg0nl9RWls6KLRzHWDc2AWaniuWyoT eaI1hDWgAdl+bWs2vLRg5/j+NHz0J0O7IQGX46Y1bY+vZrdUrvwrHTnSo8WGvfq3c+4NSs+G eYqgm1OgwpMY/+m8gu22Vnedw4d3+uambkdyzlqZ/mi6pHWaZjTgIole4rgGSv9jIkgkgi4j OKJLeMiM082C3xTzUzi0mLMLhiYIcpsu5JTSyYjQKEhLQJA4wpGIHoW3YgkOBvQMioYMJEkn u+Qzjkc45kLbjKQ8V46FFP7BoX4vBhhQjwHd5tqDUpYyC5E0hTIhiqx1OGUutCSpn2tX1jIh iGAehossWNK0izcnvrfighAk82GFBMLwl2dHliNIi0ZKQ8p/hYRDyUe4SDNZPIIWaYIrcR05 iqKJFtqYhLWAwk2mdfoBkyeubKLjICGdMEqo9oAG4ThlIYqciZ40ek6pD9L2Z13/VTbjiYx5 +Bk35LBoI2N9GErTMy1ZuQxfRIIygoOj/BmhkXmucKr/IZ7Bogw4rQVLU0fpgcugG4hOxMai GzVWY6/PlviMfY112WIfswA3UqEpbOJIo9KOKmyIpI76jZXK+CrXM+YKe+s3t0LDDLeW/heh j5McazFF7LoSz2ANCaLaK6WsBo5oFuu06ijbgrNutSvAUteBg5BIT6Tr0SvjSJzOjLDF6MIx 2GOBxVTmpzpdauY8EpMoMQkNnxuvQKIE3NaOT3PTkZRXU1suz+nOPM/Aunk9zzPzoKbroWj3 WbHG6aKT80zvlCJ2m2rjPDN0YIrN8gud5dPZ1RQDHM8fFIVEx9YV9/zjZ30tXpOcqRY9L2lO /lY5J2+SE9jgUf9LkNQg29kJ/6vM7px425Iz1pZwkZ5d8pE1hbysz97u+yEcsifMlwkD1Us7 3pXtTVTB69V7b3Un7EJON6gPOxisa2080EEYg1nxe+2OQ8ltgTmiHpUjbR+4MUPS5mDvoANM iPmgQVmktxY/7zTtpc3/LdPf2Apq4AP1z4YrHtOH6oYVpcU5DxoBfMha+sc+vJFkDmERnqnw RJ9Y0YJ21LqXSFzikXM5SX4ExJwh+EA/E5CEg5Iykb46FUCM9eJ4wyJJo5g2tnZ1SSQklInn aNggCw4JF186mAGPJKgKhaNY6jLRNmjlINdV7HoqNNOyRlgIOmkPQLjokEve1UHeic8j7SMW BksiQf8U8EouweJQ2SJRKdrILDRDzGL13NQRNe7uXmFyVw+Rpps3grFHxZJZLewYOELA70rV 41Eed8i4Pc7xgQH0YhxzVDhByms9Ovujgb4mxCf2ySUXBB8d9+ifB71kE2qMJCh3NyqkBZBH HqTHkCJYRhiAowY94UlbcplLM64OHr0Epk6iF8xb5otaxuTEL1sWzB7wspnDjKYyN7PMaLAG HbQpZieF+YJmJjOZtcTKZZwiqBkKziPVDKc6W1aMq/SinSsoxuXWSc8YzOcqbrintdaQznr6 858ADahAB0rQghpUDWHBDw3OIhlaPoGhtrQlLYuzBH0SoZ+FcehBiRDJidn/IDM+AOkTRKqC v7ggMwpyQvB+QNKWMSiehdxoER4Iwxq0tDDww0xOW7BSU+20p0YAKg9umoJxytQKu+rdhdpD GsFlhzv/UWhqwBPBPxGPaeXJjyjeQFFOPJU+otFLcrzandCIIqvauU1kzNqf7pSEF2t5j2ik 2pV8Lk2AaS0KXamT15+YFR4BKssbQHEu/+gVPgMy1bkGu1TjQBA8JpFrVLm6QbT+UxpJrZJI /PW5O1mwSkikxKy8NEcwHsYXbEItaKnUjRf6gUs9TNLvxpGkT3GpTFSCHJAWlFOlkStI8oAr jTx7SfBt0UibENGC2NDGXsXpS2SiCJ3KUgz1kJZU/xrSIJrcFiXgZo9dTdpkbZ90juhmkJ69 SFGw+tW5z72qGb5ooi8oEtaXRlIaJsXvFMGULMFqDlGA+pGspHi/TeQ3d4Y8wQo9OqjaMNBz LtrdgsFnYAPHTH+4w1amfrpeBFqQdgEuge3cGKhNDky0ZnIjEmfZoJiu83KJlFt7efg6wLYP xA8Dx1ykVSshcUscIssQ4EL3Od6kLH+DgBm3mvYKUQY5HN5An4JD+6u6VbmHEI7clEP4p2uB Kspv0PH/dvzTwHXrkkfu1qOQODkRE3hh5BKs7Vp0x3+C8GIzbuQTlXG3GCJRbNapXR/mNmix 9YFtaxmaKfUGM7GBbc2G9P9anRqTmTkTeXc/S58+QGpp1T0sZm+wFKCxuItkbdkUM7ukzPrM 3e5RjMmrpEd/ZsbmV5CINwC9c8U4S+OK+c6AjijcS9XnUVZGENGReGFlYObgtYgqoZQus+c4 51MeunqIra6akJzFC6r90jbN426MdKxqF4Pv2n44DN54xz19LAbcGBUex3zRQtHmFITVq5HH oDFHe7HKYgrEK1nwuhjsYZmmXYFZ/db3rEMTmKnVW5WbGY5lK3fx3EbDNoPzTY6UhqQW/c4f JBAnbrxKKx4ID0unBT6xdHSUOdOrtXZGrtFwZtqDUqTdvb2FYBQ+Kb5KtG8oT4ixAHKki8im Ic7/ozTGU8XKwjcU4NGvSHRpw5BWd8xhJF04p50KUIYY4xEganivwgqEheFm8NU5SSm0U2vl yyY7fwG04h7KfFAgTk1LkFPzrTwGlJ160iI/lzDAd3RCmJyJexUvE7mvcoSzM2E9+ihLvBES EojcICcf367BT9yRLK6NH/9YSk4DfY0RChZNEVmpyj/pK2x7CcbWaMcMwr2QNCN1KPGYuWnP TCS42jBAvRnvNhQfmtOUpvFnAE5gfpv4Jukl8W2JfF/WpvjKxL41le98FkDzmdo/5jDL0vzr H/X8RjEq+tdvlSWx//2EsSj850//+tv//vjPv/73z//+Q5D88scE/KQT//6GSw/1a7XhFRaV TxrFgIKVDW0AgSngH30XUhCRFrx0HEhALrjWZD6xgNkQfkWgGwWod9UAI+hQZ0lAQZ9RgSxA U0rAesOGJ3bULLS2S15jb/XwGZN3AmUigjZQIRUSSQ+Ue0MQayoXbT0oeHInBWfUUUpnDYhn d1PAghd3A1Z4BFukPD5yJYAwJRziNJ4QRCl4I0CSIbAyhqVlSi7oA0aULFQ0dl73A2OjPIfE SU9iJziEKOamBE+IaSq4CrCUh8LRWMHhHbVhWFjlVodogjQ4G8ajE+NxT6dBHqVmKuyRGvVD HoaoDXflMaNDMqAkh8mSKsBnhAVkSnbyKeJyiv/3diZg9RqemFD+ITG2cVep5zNhpiELUhQ0 U4mBYFjKkYmvRQr8wYMe5oqpOHchIoyKNSCJBVVbJVfq0S1M8iZZBYXT4BKDiEe3lmBXCDK0 AE9KQ3a/GDJdM3qYQws76I1rpI6d94080i4ewo6zhzQ+olw5pUjx8hkdEYnM6I/0yIzzCJBW SGt5QyKUNI68M441xCPf+Cig8geA50eRUiao11kyA0YKWTSEQ36p1kPbQ5EcFxYusZENaY9I g3oniTSLZo+hRg+NF5HaOA2CxBgWJBAdFhZfEiAoiILnOGbAIoY8iTHthIJiF5Di2CUTSUm/ hZO4YyIpORdlk4WDSEH/VthRLcRzMXMpM5guGwZyUklDYUlbT6JgE1lCzBgXSImHEwENQogo tvcSJlGVcOmV5BI1YYGHWfiQfrk8a4KOG1ZHM8KNZ3lF6qBIycI+zLWTEkmC3XIoOtmC/DWP IvmYQFJ2KoOOcVWSGmQhmolkjVlUrBcLK2KFPLKHdOZfeikPbxmQWVghAMlJqPgKs5YqY4mZ QxiYchiakZmA8aGG+vFLnAcmh3aXq6mVu9MSfRksNBMXlmmWlcMrf/hD4VgNQaSco3mdrili eNmdV4QMZ4SYr0kseZODSnmFrxQXxrNqM1GbmEMiePQGgSWObvSdUdhFuRcXWPmVwLKa4Bki /6t2NGXTFnGplnjCn3NDi17DlAWqAvbYLYVSn/2Zl5TZBjK4QM65ocvIKzS4In8omQO0DtpJ mUHZkJipiuCZQEpig3uZRqdZKNzynwDTmmBimIE1owHqEwPDX+7pkjLxHAYpdIxJkOw5Pf4J m5PpUx+Cgr0ha7qZLnGYYDnKLQ2pVhQkJ6iIH39QLz+6IkPKgQOJRlg6bM/JoePpoQ4DooXZ P/8FhJWgnKglN6rHF5XDEUFEm3UqlOA5T2xIhdlJB1nopJWTXrUQqFGJAr7TlQy4BrC4RUWG k0Uzp6sYI2Z5mN6ph26SqGhpW/HxhXaaloiZoIOAqMWooiaVlSvSpf9VlA29yEVnOZ6oSSTN 6Sa2Gp1T8qFItGEiaoIkGjuIAphkY5IXFIZJ6VofVENxKS58sUUn+XoyMZTJE6zi2Hpkw6kA Uwja2lt3qVYQmJRTqFBO4loigoZiCCxzyZR2IpaKKmxgWqx+One7uYeUBK2GuY52MpGE+VKw tK3Utab6+qeuha94pKG2Co6IB65ruqtXGClSZQ1QiISa1ISp146sF3ixxpm6R7GOBKSxJhJX Qi0SW7HK4TWbNYcymIQOipC856ITS2eu17KFhCcX25tMupKA2Y6ZOnfPGrLd+bFoWQ/uGrM0 9HspKrPI6JYpKLRaw6HgWIOqaZ6K2VGRUpP/09B8DviBVvqMGyKBpBFmO9FLIQh9OrYMIcg0 AZi12ReBA8hNZoSAy+d8Ovob+mQsdOtvrsq2DiV9Xrt9ZvSt1RGAfptLEgi4X1uCEHQdJNi2 tcERuwSAIMi4ITKA0+e2Ysu40re4Wzu41fdPhRqITjiHOKB+RzFs/mcHJymfvwBRp9u6zKeI rhu7sju7tFu7tnu7uEtQArC7vBsAMRAAAuC7QAC8IhC8L8C7vVsDxOsEAkAABDAAKIC8uyu8 RAC8wku9O4C92LtQbbgDcOoDtiG5zNe9F1UEgltUGrgCBFAAzuu8BQC9LxAABbC9PCAABSAC BSAAACC/9FsC69u+/+sLvzJgv04QwANQAPNrAuwLwO9bBPwLAARcv/crAgSgvzdAVDxgUlEQ WKBrLaLLFW8KBEJVM2qXAs5LAvZrwS3wwEAQwSPAwiZMACicvzPgwkpgv9fbwCVAwyNgvwIc BA9swzngwjz8UR/shn2IBB18UkeshSGcEUmsdkJ1wiRQxM37vNQbAANQwTh8AlqMxcWrxQPg u188ACq8v1u8uxMcvFr8vv07AlQ8Ajz8xWC8v/q7xWNcvBMMwfoLvM0bvMZbvH0MyHVcvM47 yFkMyD8cx3J8xhC8xxB8yCRQxmd8xSo8vXgsx/u7voHcw8Aryc1rxi+8xWAcAJwMvOxrwf+U 7MkDkMfVBlm+OnBkRBrfkVb/8Vdg5VddxTQU6B18MlYR2CEDR4lntTThGxnNkR5+ZVnt8VfK HB3lYazwAcxkIVyIOMtkQUIUdYucCHkswMjya8EB3LwJLL8VvL4JXAL2e84JjMCtHADmLAAH DL/rTM4TnL+mnMoqAM48nMoHvMbsa8br67sRPNCPnL9jnM4AcMLmzM7Ca8BuXMQHbALhrMCO XNEL/b4HLMP76886PM/zTMHO28rsW7yRzL7bu8DknMYGDQAefb/kTAD5/LwdXcEh7dIa/cbR 0iFO0lwhRF67qlu4hQ+6RVtOSkPjlZqmuFxtIE9HAnY4tFoWwlv/kwpcEzKwE6ElPQIizzUn xbAk78LUwcUbPs0Mt+ZaXU0vQDrFXCzPOmzKKkzDE03BCg3HHO3S0FvSFCzAXRzHCIy/fVzX J3DIu3vTXfzIBD3HNEzALZ3CIgDDDK3XeI3YemzKd63DLyzZVezILq2/h13RNF3ZnS0CW0zX wnvYenwCem3Oj73Y6dzFRCzOfN3Od81GoqQPFXao8EMr8fFdFQYy/8MpzqZiAXGKKJY8OQJ5 R9RiwI1XWxpx4hI2ezlISQVf3zUpFnTcDQZpOKPbzCgtzlJxqPLNC+y+tf3Yjh3alD3JRSy8 is3G8IzPEn3Pgf3GcFze/0vRB5zYm/3I/y39yJlNvZGtwhNd2i9M2Y6d2efdyBYNAAa+1+EM z/Gtv5zsv3cNwwDe4IDN4JO83xk+2hEu4TRcxLbNLyT5INJCMoxkY04GJ0KmmS0ARy+jJAxj pslNLHDp4lAmK/uYcRqs4mrjP00dRgpD43FmcYtzG19GcPy6Kq7AJ/tc25ZtyAiMwPrb3oKN 4Rve0VVe5cGr0BFMw1puAuBMxfaMwPzN4PZr5T28x5AtwzDM2As+2Q8u0ilA4hvOyM4rv13O 5vnsxnbe2tgrxFs+2lt+5gkc21ze51fO2YS3OS0aarkQal+RGHwmkwJEaIuGi9qBkDPuaJKk NrNpaEHT45NjEP8UI+R7tmqW1zUNiuSfNunSkHSX3jr01neMDODya8a+O+IqrOVjrtj0G+f0 3dH2Heht/shjHN9pvuE47OEf/ubGnuy5Ttrzi9mFruFt7rt6LtOC3eEGHccYTuiGXu6uvexB vMdi/u3lXuLadiE2g8xJBBHLA3J7K9ZZLagyR1RZJJnzBW0lmzoUlg/Ukza+hi87PUAglXUU MhI3w+SrOFsAhOvnPdEuDNp3jdpyLMClXcTYbryYvb4bPuYWXgITHcewDcmuHegXr9CRLcA0 PdcdHdj//dj2jedULPOT/fHw7MqjLe51Te4eH9cUnvGJru4WzPPt/socF1tOo8Ej6ij/4v1w ZPQ9LNconfZyEdTvbGiU+XA49ynw+rAua6jqsNNAiyM9C4fk2lXcVD84aK8x6bTnEn7Ani3m Fe7YfE6/Hr7r5W73aJzAHr7mIz/Hjk73PS/X5YzmHz7aEVzRNvzRJb33jxzY8Avt+a3ON4/u 5JzDly/4Yu7hKE3ZQD/okMzh5n7Hi3/0G2/tfSz6KlyAKONDUGlIAM9gKJRcRWcl2Z1uVNg9 T8c/N2506aJ5HqJzYj9iPbRABn8kuk/kRRT8nuQH/LYmkff8t32+993lFbz9+WvmVQ7tJh/+ 2f7PbG7tAV3sOA295I7OVd79i56/DRz5dz8C+23Da/6+L+/l/20OAoUoAKVQDKUKFOS6ijEa rGfsAoPsBnIKEAiqHm04erVUyVKyd0MBnCRCQZjbMXESxQugkKgaknFjBQGXxIfuQbIufceQ Lze+jo+5gMNZ3gWIkYntuanwjUlAvL1slWy1lZVAQMAhNqbJDb60LU5WIuoxhl4CNOLNNbY1 ku31Jb6Rdp2FFQJ4lnB6IaLWja3d/gX/BRS9EAsPHSMrrzAPF1khP0tTTxsRFzdnA5xsV1c7 J3eFU2N/j3ubR2WTG4YKH8SfU8tvLu7d49b/xefz788LBlBfwBUDC+JjU29fP4QBDx50KHEi wgA/KGIMRmRekIweP4I818BfyJImT/+iTKlyJcuWLssV8BZMABWZL2/izKlzJ8+ePn8C/WZz mIChQY8iTap0KdOmTp9CjSp1KtWqVq9izap1K9euXr+CDSt2LNmyZs+iTat2Ldu2bt/CjSt3 Lt26du/izat3L9++fv8CDix4MOHChg8jTqx4MePGjh9Djix5MuXKli9jzqx5M+fOnj+DDi16 NOnSpk+jTq16NevWrl/Dji17Nu3atsUaWODAAYMEKxIkMNDFAPAXCXY78K2CuHAVCIq/YG5c OXHg1oELr349+PLt1pt3945dRQIGuxeAF1Z+N4P04ou/h/5nfDD6JaQv181bOTIE5nkjsIJ2 34U3H3fdIYf/noHgxSecfQD4x16ABf524Hz/WQgAfuTxV8J6Dih4X3wavpceawlEEMEDDqT4 gAosmqhhBA4sl+KMNjaHIn8oRtChhz2+kOKPNhLpG49Eppgjkjb6aMCSOGr4QIoOSBnBAurZ SGWKDKjwpJAsPknjH06qKMyUvwFZwgItgvlAjC+2WKWYMi7JpYxzrgCjCmuqCGaa5G3ZpZe+ 6VlCm3LW+CcAhUaXZZU7KgqAkPfJWeWVABy5JKaDvkZmcwZIeSmjNc6ZIn8MlLmpcjz6+KOP k+pY358GoCpmrOfcqoKUdtLZaq+JKjcpMsJimWQwTAK6qrEloOriH81+uut9MyYa/6CTeMKp ZAQMLmuojcNRm+e2zKoYbQR2kjmut28GOqSSr0ag67nAvjBqrrNJ2aGTzo46rZhr8lqCsbGy Kiu8rhocZLyqznMvigHT+WykKIpJ7LELI5PvvH8Q+a7A6sLZ6r5dGHvtCmv6ZnIXhXZLLn/7 otwotnqOrHB2Njq7KMiAQkwxwivAunGi9e58r2wWa5gtuGJKaSK3wJmK5cEMz6comT9/c6+U E66wNckYCygoNUi/gMC8ZEt6brixmp2zc6mebGUXa16psst3/kEz3Mulh3LNpBItHN1zy71v vut24bXCWH9cguJdR8C1zu5FCpvdee/sb+NYIso5crsFnf/cdj+2ZwBx0m4q+nXI3Et2zALu zXGP25mItgqoBvj64lETXHnaK2cOIbX7Wseis5crjeKlwy7cNOwzj9uv8DRe6+nkX2PuYKST uq6ovTN612m4wUivsu2bFun550E/OSSSc2ZKJOuKkm203cd9/vGSUwdT899Ax4tHDDPa5sQV I5Oli0hiQh7icqWf85AugoAz4PVkhrdaVRCA2aOa2H7XhXt9r32u+R/wDhiu87GKR2/i4OYI SDoDIAB1jKNG68C2p0j9DX9gKqCZbPgCPiEnRZLbHIt6AyTlyQ54Q5we3u6DQQZeD4lq2o2U mNYnLYENeXpi0RLNRr0T9kh6ZHP/ntG450MA6C6DLDyaDx/gJjVqTmdDZMADjCQ3ADQrYRpc Y7LkBSlfSW0FqGqV82yGPQ8yj3mfk2EHyXQ4Eqbug0K7HZCQJyQo6s1tmiPTImc1vgZO8m4q M5uKgseiJgVteZsbZOJ29j1AuoaVb1tY+db2SevlipF93KMLOWg9Ps6vQyjS5DAlBjEPno+H xoldyxB5JOUcDnIia5n1Lnc1TKormm+jEapU2bYJKu2X0xqX3VDVzE0562GostM3AZXO2BWT grukDZkUVDCdBcd0pmsiAKqYnSpijUytKuPCHqbPg7JwTe8s3UFXuEbjWUuFF3PAhBJQpY81 dJ97xJyP/2TZQW+lSaDCieEn0ZSme+5LnxadV0obWkEytYdEgWpmIbWornui9JNQAp6bQLXT tD0AAbmJmreCKtPMfY+hCBUfkpbnJ/nZzacKnCf6TERQ971vjYeLX5YC+QJz4myJy3nqlprj pZ2h7WplY2YWiQqhKtnomCZN3zizSickEQpkUk1fPOOGrpIyiqsv+yQpVwhWIsX0rnH9KpKM Gri52hU2z3lQRjWq0fBkSJ/Ruex9OKuhT1V2n5oVkGhD69DRRsc6Yh3OddJj2s0Kw7OdhS1p TTTZDKnHOsNxaW1dKlvtcA21pOUbbSskH+ION7aqNcApV3DbNwG3f0577W2qG60bh1o3u9rd rlPO6t3vgje84h0vectr3vOiN73qXS972+ve98JXvNgFjWnra9/74je/+t0vf/vr3/8COMAC HjCBC9zgA+eXuwpeMIMb7OAHQzjCEp4whSts4wBx4MMa3jCHO+zLKOT4xCIeMYlLbOITozjF Kl4xi1vs4hfDOMYynjGNa2Y7lRM4xzreMY516OMLAY1IQh4ykYts5CMjOclKXjKTm+zkJ0M5 yogJAQA7 --------------JavaMail.942015912871-- From lilasian@geocities.com Thu Jan 12 21:01:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExEFe-0005lW-Ov for capwap-archive@megatron.ietf.org; Thu, 12 Jan 2006 21:01:14 -0500 Received: from pguygnn.com ([219.129.121.29]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19284 for ; Thu, 12 Jan 2006 20:59:45 -0500 (EST) Received: from scold by microsoft.com with local (Exim 4.41 (FreeBSD)) id 67-4-2 for tripe; Thu, 12 Jan 2006 23:30:01 -0500 Message-ID: <63886@grenoble> From: Melody York To: capwap-archive@ietf.org Subject: Amazing, Kelley Date: Thu, 12 Jan 2006 23:09:34 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 91102737.32235998.634517.9332 X-MimeOLE: Produced By Microsoft MimeOLE 436450.83705.6964.1367 Content-Type: multipart/mixed; boundary="------=892044067620" Content-Transfer-Encoding: 8bit --------=892044067620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package	Quantity	Price in your local drugstore*	Our price	Learn More Now
10 softtabs	20 doses	~~$149.95~~	$119.95
20 softtabs	40 doses	~~$299.95~~	$159.95
30 softtabs	60 doses	~~$849.95~~	$169.95
60 softtabs	120 doses	~~$1 999.95~~	$259.95
90 softtabs	180 doses	~~$3 099.95~~	$299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

In bad fortune hold out, in good hold in.How many famous and high-spirited heroes have lived a day too long?
Be the green grass above me, with showers and dewdrops wet and if thou wilt, remember, and if thou wilt, forget. --------=892044067620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Audrey-> http://luwawc.pinkocean.net/?vbbvhhxwpqqyfmmempzpokeglgl --------=892044067620-- From surfeur@earthlink.net Fri Jan 13 02:05:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJ0F-0002pm-07 for capwap-archive@megatron.ietf.org; Fri, 13 Jan 2006 02:05:39 -0500 Received: from softbank219033070018.bbtec.net (softbank219033070018.bbtec.net [219.33.70.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07430 for ; Fri, 13 Jan 2006 02:04:15 -0500 (EST) Received: from spike by microsoft.com with local (Exim 4.41 (FreeBSD)) id 54-7-0 for callaghan; Thu, 12 Jan 2006 22:36:41 -0500 To: capwap-archive@ietf.org Subject: Amazing, Sherry From: Gilberto Champagne Message-ID: <569079.166223@earthlink.net:67370> X-Priority: 3 X-Mailer: atlas Mail loci PHP Date: Fri, 13 Jan 2006 00:20:34 -0500 Content-Type: multipart/mixed; boundary="------=1087728678751" Content-Transfer-Encoding: quoted-printable --------=1087728678751 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Package	Quantity	Price in your local drugstore*	Our price	Learn More Now
10 softtabs	20 doses	~~$149.95~~	$119.95
20 softtabs	40 doses	~~$299.95~~	$159.95
30 softtabs	60 doses	~~$849.95~~	$169.95
60 softtabs	120 doses	~~$1 999.95~~	$259.95
90 softtabs	180 doses	~~$3 099.95~~	$299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

Forgive, O Lord, my little jokes on Thee and I'll forgive Thy great big one on me.
Sometimes you gotta create what you want to be a part of. --------=1087728678751 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Rodrick-> http://contacroca.com/?a=1065 --------=1087728678751-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 13 12:39:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExStC-00005T-FV for capwap-archive@megatron.ietf.org; Fri, 13 Jan 2006 12:39:02 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24222 for ; Fri, 13 Jan 2006 12:37:37 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EF3C84300D7 for ; Fri, 13 Jan 2006 09:38:58 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id BE011430077 for ; Fri, 13 Jan 2006 09:38:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AD35180C147 for ; Fri, 13 Jan 2006 09:38:17 -0800 (PST) X-Greylist-Status: Sender first seen 00:43:43 ago Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by hermes.tigertech.net (Postfix) with ESMTP id 6328280C13C for ; Fri, 13 Jan 2006 09:38:16 -0800 (PST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0DGq7A6007160 for ; Fri, 13 Jan 2006 11:52:07 -0500 Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k0DGpScS011989 for ; Fri, 13 Jan 2006 11:51:29 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Question on LWAPP-03 draft Date: Fri, 13 Jan 2006 11:54:24 -0500 Message-ID: <5844A41F4E146044A2E8356C632858800A7A2E40@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Question on LWAPP-03 draft Thread-Index: AcYRxLrlq9xPFdKYSlqnnrOiInGSnQAT/fYQAAJWJVAAAr/CQAADb6mwAAIZt8AABZdcMADE3JOQAL3R50A= From: "Sadot, Emek (Emek)" To: "Puneet Agarwal" , "Changming Liu" , "Darren Loher" , "Pat Calhoun (pacalhou)" , "sujay" , "Vishwas Manral" , "Abhijit Choudhury" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable A question about former tunneling protocols architectures (just out of = my ignorance): what is the landscape and motivations of other tunneling = protocol that adopted a fragmentation at application level solution? Out of curiosity, would it be fair to assume that most of the CAPWAP = installations would be confined by a localized mobility domain were = intermediate firewall is not likely to reside? Regards, Emek -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Monday, January 09, 2006 5:29 PM To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; Vishwas = Manral; Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft Hi Changming, (a) For CAPWAP data frames (C=3D0), you are "tunneling" wireless client = frames inside the CAPWAP hdr (between the AC and WTP). Hence from the = perspective of the wireless client frames - they are tunneled inside a = CAPWAP/UDP/IP between WTP<-->AC. This CAPWAP/UDP/IP could be called the = "transport tunnel" from the perspective of the wireless client frames. >From the perspective of UDP, the UDP port numbers generally defines the = application (in this case CAPWAP). Hence from the perspective of UDP, = CAPWAP is an application. So tunnel and UDP application are not mutually exclusive (it is a = question of which layer's perspective one is talking about). (b) I took Pat's comments to agree with my statements. Both he and I = seem to be talking about fragmenting at the CAPWAP level before = attaching a UDP/IP header. Maybe Pat can elaborate more on this. Thanks. -Puneet=20 -----Original Message----- From: Changming Liu [mailto:cliu@juniper.net] Sent: Thursday, January 05, 2006 4:50 PM To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou); sujay; Vishwas = Manral; Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft Hi Puneet, Thanks for your quick reply. One thing I am confused about is the = definition of a tunnel vs. a UDP application. Traditionally running an = application on UDP/IP then over some kind of layer 2 is not defined as a = tunnel rather just a normal UDP application. Otherwise, DNS, RTP, SIP = or any application on top of UDP will become a tunnel instead of an = application. So is CAPWAP an application of UDP or UDP/IP is tunnel to = CAPWAP? As a application, it is usually does not deal with fragmentation = issue because it deems it as IP layer issue. Otherwise, each application = will have its own built-in fragmentation algorithm and this will defeat = the purpose of having fragmentation functionality at IP layer. As a = tunnel, a MTU may be optionally defined to avoid tunneled packet = fragmentation. But my experience with IPsec tunnel tells me that = sometimes the pre and post encapsulation are both needed to be supported = at the same time unless the MTU of entire path of a tunnel is known. = The "transport tunnel" is a definitely interesting definition. Not sure = where this fits in. The reason I talked about the tunnel vs application is that your answer = to the fragmentation requirement is different from Pat's. His answer is = about the middle box. Having worked on the firewall business for several = years, I have hardly come across any middle box (firewall) to be = configured to drop the fragmented IP packets. The customers or end users = will screen at the IT if they chose to do that :-) Who knows how many = layers of encap a packet will be subjected to after many layers of = tunneling? Just for an example, IP over GRE over IPsec.... Whatever = running on the inner IP may be encapsulated with its own layers of = tunnels.... As having been pointed out, the fragmentation is not = avoidable in today's networks, simply dropping it is usually not an = option at all for any serious and real deployment. This may be true for = some old stateless packet filtering firewalls. Not sure how many really = still be deployed there. Changming -----Original Message----- From: Puneet Agarwal [mailto:pagarwal@broadcom.com] Sent: Thursday, January 05, 2006 1:55 PM To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay; Vishwas = Manral; Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft Hi Changming, 1) Each transport tunnel has an MTU. If you know that you are going to = be exceeding that MTU when encapsulating the wireless frame, then it is = better to fragment at the LWAPP/CAPWAP level to avoid IP fragments (when = UDP/IP is the transport). It is not a question of whether middleboxes = (eg: firewalls) can handle IP fragments or not (I assume that most can = but there are of course legacy issues) - but the most common = configuration of these deployed middleboxes is to drop IP fragments. If routers in the path of the WTP and AC want to IP fragment, then that = is definitely allowed and valid (with the caveat that some middleboxes = might drop these fragmented pkts). Even if path MTU discovery is not = done, one could argue that setting the UDP/IP transport MTU to = (1500-20-8)=3D 1472 would work under most circumstances without the = packet getting further IP fragmented by intervening routers (assuming = you don't have any other VPN tunnels etc in the path). 2) Packet/fragment reordering is not really an issue for CAPWAP (and I = agree with you). Thanks. -Puneet=20 -----Original Message----- From: Changming Liu [mailto:cliu@juniper.net] Sent: Thursday, January 05, 2006 12:51 PM To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas = Manral; Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft A couple of questions about the benefits of this application = fragmentation just out of my ignorance. 1) Most commercial firewalls handles IP fragments well to an acceptable = degree (I don't think anybody will buy one which does not) since = fragmentation is common norm in IPv4. I guess it needs to be handled one = way or another even by the non-commercial ones. Not sure why this issue = is particular different for CAPWAP? If AC and APs are connected via = routers in several hops (this may be a likely case that a firewall = exists between the AC and APs), IPv4 fragmentation may still be = encountered because IPv4 path MTU is not used widely as we'd like to. 2) Packet and fragment re-ordering are two different issues and should = be handled differently. Packet re-ordering is an issue that application = needs to handle if the order is important to it like RTP stream. The IP = fragmentation is an IP layer issue and should be dealt with at IP layer. = There should some solution today at IP layer. Not sure this is = particularly important to CAPWAP. Do I miss anything? Changming=20 -----Original Message----- From: Darren Loher [mailto:dloher@rovingplanet.com] Sent: Thursday, January 05, 2006 11:05 AM To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas Manral; = Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft Thanks for the full explanation Puneet. With fragmentation done at the = application (CAPWAP/LWAPP) layer this means every frame must have a = LWAPP header. =20 I agree that this is especially important to get right as Pat pointed = out that tunneled data packets will commonly need to be fragmented. =20 I another reason it's important not to have a standard IP stack = reassemble frames is due to possible packet/fragment reordering. If the = network were to reorder the CAPWAP/LWAPP UDP tunnel packets for any = reason, it would result in corrupting the data frames inside the tunnel. = We need the FragID field of the LWAPP/CAPWAP header to help us there. = -Darren > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Thursday, January 05, 2006 10:52 AM > To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;=20 > capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi All, >=20 > Just to remove any confusion, by application level fragmentation, I=20 > mean the LWAPP level fragmentation (as LWAPP is the application from=20 > the UDP/IP transport perspective). Hopefully this answers your = question Sujoy. >=20 > Hence the proposal is to fragment the wireless frame at the LWAPP=20 > level (F, L, Frag-Id would be valid - even for UDP/IP transport)=20 > before encapsulating the wireless frame in the transport (UDP/IP)=20 > headers (just like it is proposed in the spec for L2 transport). >=20 > So conceptually LWAPP/CAPWAP should be agnostic of transport and=20 > assumes that the transport does not support fragmentation. This gets=20 > rid of the middlebox problem (for IP fragments) and is architecturally = clean too. >=20 > Thanks. >=20 > -Puneet >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Thursday, January 05, 2006 8:28 AM > To: sujay; Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > If we let IP handle fragmentation, then we do not have control over=20 > adding LWAPP headers to it. It is true that having LWAPP perform=20 > fragmentation, and add an independent header, would allow for any=20 > middlebox (including > firewall) traversal. Given the likelihood of fragmentated frames is=20 > certain (given we are tunneling MTU sized frames), I agree with=20 > Puneet's recommendation. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: sujay [mailto:sujayg@huawei.com] > > Sent: Wednesday, January 04, 2006 10:45 PM > > To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury';=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > Hi Vishwas, > > > > The F, L and Frag-id fields should be of use only for L2 transport. > > > > Fragmentation causes issues at the firewalls, essentially because=20 > > the lwapp header is carried in the first fragment alone. > > > > If the MTU is pre-determined for IPv4/6, the application has to take = > > care of re-assembly. > > There the F, L and Frag- id fields could be of use. > > Additionally a few more fields may be required ! > > > > Puneet, > > IMO there is no advantage by pushing the fragmentation/ assembly to=20 > > the application. > > > > If firewall is the issue, is it possible to add the lwapp header in = > > all fragments..?? > > > > Regds, > > Sujay > > > > > > > > > > > > > > -----Original Message----- > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > Sent: Thursday, January 05, 2006 10:09 AM > > To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > Hi Puneet, > > > > One small typo!! I had stated "I guess for IPv6 it is already stated = > > that we do not do fragmentation at LWAPP level" I meant at > > "IPv6 level" > > I meant. > > > > Thanks, > > Vishwas > > -----Original Message----- > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > Sent: Thursday, January 05, 2006 9:54 AM > > To: Puneet Agarwal; Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > Hi Puneet, > > > > I think you mean all middleboxes and not just firewalls. > > > > I guess for IPv6 it is already stated that we do not do=20 > > fragmentation at LWAPP level because we have to do MTU discovery and = > > hence fragments can be done at the application level itself. I think = > > only if Path MTU discovery is done for IPv4 too, can we avoid = fragmentation. > > > > Are you saying that the F, L and Fragment Id fields were only valid=20 > > for > > Layer-2 transport and not for Layer-3 transport earlier? > > > > Thanks, > > Vishwas > > ________________________________________ > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Thursday, January 05, 2006 4:16 AM > > To: Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > The main issue is passing IP fragments via firewalls. Most firewalls = > > drop fragmented packets (in fact the note is section 3.3.4 also=20 > > refers to that). Hence the question. > > > > Hope this helps. > > > > Thanks. > > > > -Puneet > > > > ________________________________________ > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > Sent: Wednesday, January 04, 2006 11:42 AM > > To: Puneet Agarwal; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft For L3 transport,=20 > > as the spec says, only the first IP fragment would have an LWAPP = header. > > Standard IP reassembly is used to put the fragments together.=A0 F, = L,=20 > > and FragID fields in the LWAPP header are not neeed for reassembly. > > > > Am I missing something ? > > > > Thanks, > > =A0=A0 Abhijit > > -----Original Message----- > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Tuesday, January 03, 2006 7:57 PM > > To: capwap@frascone.com; Pat Calhoun (pacalhou) > > Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4=20 > > frag/reassembly (Section 3.3.4): > > > > There=A0was some talk=A0in the past about performing the=20 > > fragmentation/reassembly at the application level to avoid IP=20 > > fragments. > > In that case, the F,L and FragID bits would need to be used even for > > L3 transport. Did we ever reach a consensus on this one? > > > > My recommendation would be to do the frag/reassembly at application=20 > > level. > > > > Thanks. > > > > -Puneet > > > > > > _________________________________________________________________ > > 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 > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > 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 _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 13 13:44:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTuq-0007Nf-Sf for capwap-archive@megatron.ietf.org; Fri, 13 Jan 2006 13:44:49 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27986 for ; Fri, 13 Jan 2006 13:43:26 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7CA3743011B for ; Fri, 13 Jan 2006 10:44:46 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id B6D114300A7 for ; Fri, 13 Jan 2006 10:44:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AA0E780C152 for ; Fri, 13 Jan 2006 10:44:07 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 5209A80C0F6 for ; Fri, 13 Jan 2006 10:44:05 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Jan 2006 10:44:05 -0800 X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="391531829:sNHT45168364" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0DIhPWL003837; Fri, 13 Jan 2006 10:44:04 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 10:43:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Question on LWAPP-03 draft Date: Fri, 13 Jan 2006 10:43:53 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D8C77@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Question on LWAPP-03 draft Thread-Index: AcYRxLrlq9xPFdKYSlqnnrOiInGSnQAT/fYQAAJWJVAAAr/CQAADb6mwAAIZt8AABZdcMADE3JOQAL3R50AABDzwQA== From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , "Puneet Agarwal" , "Changming Liu" , "Darren Loher" , "sujay" , "Vishwas Manral" , "Abhijit Choudhury" , X-OriginalArrivalTime: 13 Jan 2006 18:43:56.0127 (UTC) FILETIME=[4EEE9EF0:01C61871] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I'm aware of several of my customers using FWs to remote sites with = WTPs. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 > Sent: Friday, January 13, 2006 8:54 AM > To: Puneet Agarwal; Changming Liu; Darren Loher; Pat Calhoun=20 > (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;=20 > capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > A question about former tunneling protocols architectures=20 > (just out of my ignorance): what is the landscape and=20 > motivations of other tunneling protocol that adopted a=20 > fragmentation at application level solution? >=20 > Out of curiosity, would it be fair to assume that most of the=20 > CAPWAP installations would be confined by a localized=20 > mobility domain were intermediate firewall is not likely to reside? >=20 > Regards, > Emek >=20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Monday, January 09, 2006 5:29 PM > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou);=20 > sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Changming, >=20 > (a) For CAPWAP data frames (C=3D0), you are "tunneling"=20 > wireless client frames inside the CAPWAP hdr (between the AC=20 > and WTP). Hence from the perspective of the wireless client=20 > frames - they are tunneled inside a CAPWAP/UDP/IP between=20 > WTP<-->AC. This CAPWAP/UDP/IP could be called the "transport=20 > tunnel" from the perspective of the wireless client frames. >=20 > >From the perspective of UDP, the UDP port numbers generally=20 > defines the application (in this case CAPWAP). Hence from the=20 > perspective of UDP, CAPWAP is an application. >=20 > So tunnel and UDP application are not mutually exclusive (it=20 > is a question of which layer's perspective one is talking about). >=20 > (b) I took Pat's comments to agree with my statements. Both=20 > he and I seem to be talking about fragmenting at the CAPWAP=20 > level before attaching a UDP/IP header. Maybe Pat can=20 > elaborate more on this. >=20 > Thanks. >=20 > -Puneet=20 >=20 > -----Original Message----- > From: Changming Liu [mailto:cliu@juniper.net] > Sent: Thursday, January 05, 2006 4:50 PM > To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou);=20 > sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Puneet, >=20 > Thanks for your quick reply. One thing I am confused about is=20 > the definition of a tunnel vs. a UDP application.=20 > Traditionally running an application on UDP/IP then over some=20 > kind of layer 2 is not defined as a tunnel rather just a =20 > normal UDP application. Otherwise, DNS, RTP, SIP or any=20 > application on top of UDP will become a tunnel instead of an=20 > application. So is CAPWAP an application of UDP or UDP/IP is=20 > tunnel to CAPWAP? As a application, it is usually does not=20 > deal with fragmentation issue because it deems it as IP layer=20 > issue. Otherwise, each application will have its own built-in=20 > fragmentation algorithm and this will defeat the purpose of=20 > having fragmentation functionality at IP layer. As a tunnel,=20 > a MTU may be optionally defined to avoid tunneled packet=20 > fragmentation. But my experience with IPsec tunnel tells me=20 > that sometimes the pre and post encapsulation are both needed=20 > to be supported at the same time unless the MTU of entire=20 > path of a tunnel is known. The "transport tunnel" is a=20 > definitely interesting definition. Not sure where this fits in. >=20 > The reason I talked about the tunnel vs application is that=20 > your answer to the fragmentation requirement is different=20 > from Pat's. His answer is about the middle box. Having worked=20 > on the firewall business for several years, I have hardly=20 > come across any middle box (firewall) to be configured to=20 > drop the fragmented IP packets. The customers or end users=20 > will screen at the IT if they chose to do that :-) Who knows=20 > how many layers of encap a packet will be subjected to after=20 > many layers of tunneling? Just for an example, IP over GRE=20 > over IPsec.... Whatever running on the inner IP may be=20 > encapsulated with its own layers of tunnels.... As having=20 > been pointed out, the fragmentation is not avoidable in=20 > today's networks, simply dropping it is usually not an option=20 > at all for any serious and real deployment. This may be true=20 > for some old stateless packet filtering firewalls. Not sure=20 > how many really still be deployed there. >=20 > Changming >=20 >=20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Thursday, January 05, 2006 1:55 PM > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou);=20 > sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Changming, >=20 > 1) Each transport tunnel has an MTU. If you know that you are=20 > going to be exceeding that MTU when encapsulating the=20 > wireless frame, then it is better to fragment at the=20 > LWAPP/CAPWAP level to avoid IP fragments (when UDP/IP is the=20 > transport). It is not a question of whether middleboxes (eg:=20 > firewalls) can handle IP fragments or not (I assume that most=20 > can but there are of course legacy issues) - but the most=20 > common configuration of these deployed middleboxes is to drop=20 > IP fragments. >=20 > If routers in the path of the WTP and AC want to IP fragment,=20 > then that is definitely allowed and valid (with the caveat=20 > that some middleboxes might drop these fragmented pkts). Even=20 > if path MTU discovery is not done, one could argue that=20 > setting the UDP/IP transport MTU to (1500-20-8)=3D 1472 would=20 > work under most circumstances without the packet getting=20 > further IP fragmented by intervening routers (assuming you=20 > don't have any other VPN tunnels etc in the path). >=20 > 2) Packet/fragment reordering is not really an issue for=20 > CAPWAP (and I agree with you). >=20 > Thanks. >=20 > -Puneet=20 >=20 > -----Original Message----- > From: Changming Liu [mailto:cliu@juniper.net] > Sent: Thursday, January 05, 2006 12:51 PM > To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou);=20 > sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > A couple of questions about the benefits of this application=20 > fragmentation just out of my ignorance. >=20 > 1) Most commercial firewalls handles IP fragments well to an=20 > acceptable degree (I don't think anybody will buy one which=20 > does not) since fragmentation is common norm in IPv4. I guess=20 > it needs to be handled one way or another even by the=20 > non-commercial ones. Not sure why this issue is particular=20 > different for CAPWAP? If AC and APs are connected via routers=20 > in several hops (this may be a likely case that a firewall=20 > exists between the AC and APs), IPv4 fragmentation may still=20 > be encountered because IPv4 path MTU is not used widely as=20 > we'd like to. >=20 > 2) Packet and fragment re-ordering are two different issues=20 > and should be handled differently. Packet re-ordering is an=20 > issue that application needs to handle if the order is=20 > important to it like RTP stream. The IP fragmentation is an=20 > IP layer issue and should be dealt with at IP layer. There=20 > should some solution today at IP layer. Not sure this is=20 > particularly important to CAPWAP. >=20 > Do I miss anything? >=20 > Changming=20 >=20 > -----Original Message----- > From: Darren Loher [mailto:dloher@rovingplanet.com] > Sent: Thursday, January 05, 2006 11:05 AM > To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas=20 > Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Thanks for the full explanation Puneet. With fragmentation=20 > done at the application (CAPWAP/LWAPP) layer this means every=20 > frame must have a LWAPP header. =20 >=20 > I agree that this is especially important to get right as Pat=20 > pointed out that tunneled data packets will commonly need to=20 > be fragmented. =20 >=20 > I another reason it's important not to have a standard IP=20 > stack reassemble frames is due to possible packet/fragment=20 > reordering. If the network were to reorder the CAPWAP/LWAPP=20 > UDP tunnel packets for any reason, it would result in=20 > corrupting the data frames inside the tunnel. We need the=20 > FragID field of the LWAPP/CAPWAP header to help us there. =20 >=20 > -Darren >=20 > > -----Original Message----- > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Thursday, January 05, 2006 10:52 AM > > To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit=20 > Choudhury;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Hi All, > >=20 > > Just to remove any confusion, by application level fragmentation, I=20 > > mean the LWAPP level fragmentation (as LWAPP is the=20 > application from=20 > > the UDP/IP transport perspective). Hopefully this answers=20 > your question Sujoy. > >=20 > > Hence the proposal is to fragment the wireless frame at the LWAPP=20 > > level (F, L, Frag-Id would be valid - even for UDP/IP transport)=20 > > before encapsulating the wireless frame in the transport (UDP/IP)=20 > > headers (just like it is proposed in the spec for L2 transport). > >=20 > > So conceptually LWAPP/CAPWAP should be agnostic of transport and=20 > > assumes that the transport does not support fragmentation.=20 > This gets=20 > > rid of the middlebox problem (for IP fragments) and is=20 > architecturally clean too. > >=20 > > Thanks. > >=20 > > -Puneet > >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, January 05, 2006 8:28 AM > > To: sujay; Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > If we let IP handle fragmentation, then we do not have control over=20 > > adding LWAPP headers to it. It is true that having LWAPP perform=20 > > fragmentation, and add an independent header, would allow for any=20 > > middlebox (including > > firewall) traversal. Given the likelihood of fragmentated frames is=20 > > certain (given we are tunneling MTU sized frames), I agree with=20 > > Puneet's recommendation. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sujay [mailto:sujayg@huawei.com] > > > Sent: Wednesday, January 04, 2006 10:45 PM > > > To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury';=20 > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > Hi Vishwas, > > > > > > The F, L and Frag-id fields should be of use only for L2=20 > transport. > > > > > > Fragmentation causes issues at the firewalls, essentially because=20 > > > the lwapp header is carried in the first fragment alone. > > > > > > If the MTU is pre-determined for IPv4/6, the application=20 > has to take=20 > > > care of re-assembly. > > > There the F, L and Frag- id fields could be of use. > > > Additionally a few more fields may be required ! > > > > > > Puneet, > > > IMO there is no advantage by pushing the fragmentation/=20 > assembly to=20 > > > the application. > > > > > > If firewall is the issue, is it possible to add the lwapp=20 > header in=20 > > > all fragments..?? > > > > > > Regds, > > > Sujay > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > Sent: Thursday, January 05, 2006 10:09 AM > > > To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > Hi Puneet, > > > > > > One small typo!! I had stated "I guess for IPv6 it is=20 > already stated=20 > > > that we do not do fragmentation at LWAPP level" I meant at > > > "IPv6 level" > > > I meant. > > > > > > Thanks, > > > Vishwas > > > -----Original Message----- > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > Sent: Thursday, January 05, 2006 9:54 AM > > > To: Puneet Agarwal; Abhijit Choudhury; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > Hi Puneet, > > > > > > I think you mean all middleboxes and not just firewalls. > > > > > > I guess for IPv6 it is already stated that we do not do=20 > > > fragmentation at LWAPP level because we have to do MTU=20 > discovery and=20 > > > hence fragments can be done at the application level=20 > itself. I think=20 > > > only if Path MTU discovery is done for IPv4 too, can we=20 > avoid fragmentation. > > > > > > Are you saying that the F, L and Fragment Id fields were=20 > only valid=20 > > > for > > > Layer-2 transport and not for Layer-3 transport earlier? > > > > > > Thanks, > > > Vishwas > > > ________________________________________ > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > Sent: Thursday, January 05, 2006 4:16 AM > > > To: Abhijit Choudhury; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > The main issue is passing IP fragments via firewalls.=20 > Most firewalls=20 > > > drop fragmented packets (in fact the note is section 3.3.4 also=20 > > > refers to that). Hence the question. > > > > > > Hope this helps. > > > > > > Thanks. > > > > > > -Puneet > > > > > > ________________________________________ > > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > > Sent: Wednesday, January 04, 2006 11:42 AM > > > To: Puneet Agarwal; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft For L3=20 > transport,=20 > > > as the spec says, only the first IP fragment would have=20 > an LWAPP header. > > > Standard IP reassembly is used to put the fragments=20 > together.=A0 F, L,=20 > > > and FragID fields in the LWAPP header are not neeed for=20 > reassembly. > > > > > > Am I missing something ? > > > > > > Thanks, > > > =A0=A0 Abhijit > > > -----Original Message----- > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > Sent: Tuesday, January 03, 2006 7:57 PM > > > To: capwap@frascone.com; Pat Calhoun (pacalhou) > > > Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4=20 > > > frag/reassembly (Section 3.3.4): > > > > > > There=A0was some talk=A0in the past about performing the=20 > > > fragmentation/reassembly at the application level to avoid IP=20 > > > fragments. > > > In that case, the F,L and FragID bits would need to be=20 > used even for > > > L3 transport. Did we ever reach a consensus on this one? > > > > > > My recommendation would be to do the frag/reassembly at=20 > application=20 > > > level. > > > > > > Thanks. > > > > > > -Puneet > > > > > > > > > _________________________________________________________________ > > > 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 > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > >=20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 13 17:45:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExXg9-0003ly-Kw for capwap-archive@megatron.ietf.org; Fri, 13 Jan 2006 17:45:54 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18062 for ; Fri, 13 Jan 2006 17:44:29 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 26B414300EB for ; Fri, 13 Jan 2006 14:45:51 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id AFEBD4300A2 for ; Fri, 13 Jan 2006 14:45:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 99BE580C12C for ; Fri, 13 Jan 2006 14:45:14 -0800 (PST) X-Greylist-Status: Sender first seen 00:46:34 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id 4EE6C80C11B for ; Fri, 13 Jan 2006 14:45:12 -0800 (PST) Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0DKuZRA032630 for ; Fri, 13 Jan 2006 15:56:35 -0500 Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k0DLhFPk028106 for ; Fri, 13 Jan 2006 16:43:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Question on LWAPP-03 draft Date: Fri, 13 Jan 2006 16:58:17 -0500 Message-ID: <5844A41F4E146044A2E8356C632858800A7A3077@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Question on LWAPP-03 draft Thread-Index: AcYRxLrlq9xPFdKYSlqnnrOiInGSnQAT/fYQAAJWJVAAAr/CQAADb6mwAAIZt8AABZdcMADE3JOQAL3R50AABDzwQAAGESkQ From: "Sadot, Emek (Emek)" To: "Pat Calhoun (pacalhou)" , "Puneet Agarwal" , "Changming Liu" , "Darren Loher" , "sujay" , "Vishwas Manral" , "Abhijit Choudhury" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Using a firewall seems as a reasonable choice for a topology where the = AC and WTP are in separate geographical sites. The immediate follow up = question that came in mind would be: does your solution employ a = fragmentation scheme at the application level or let the IP transport = layer handle it? Another point is the use of VPN gateway. I'd think that it's rational to = assume that the remote WTP is probably the only topology in which = firewall make sense, thus wouldn't the VPN gateway at both ends moot the = issue? Regards, Emek -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Friday, January 13, 2006 1:44 PM To: Sadot, Emek (Emek); Puneet Agarwal; Changming Liu; Darren Loher; = sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com Subject: RE: [Capwap] Question on LWAPP-03 draft I'm aware of several of my customers using FWs to remote sites with = WTPs. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > Sent: Friday, January 13, 2006 8:54 AM > To: Puneet Agarwal; Changming Liu; Darren Loher; Pat Calhoun=20 > (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;=20 > capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > A question about former tunneling protocols architectures (just out of = > my ignorance): what is the landscape and motivations of other=20 > tunneling protocol that adopted a fragmentation at application level=20 > solution? >=20 > Out of curiosity, would it be fair to assume that most of the CAPWAP=20 > installations would be confined by a localized mobility domain were=20 > intermediate firewall is not likely to reside? >=20 > Regards, > Emek >=20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Monday, January 09, 2006 5:29 PM > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Changming, >=20 > (a) For CAPWAP data frames (C=3D0), you are "tunneling"=20 > wireless client frames inside the CAPWAP hdr (between the AC and WTP). = > Hence from the perspective of the wireless client frames - they are=20 > tunneled inside a CAPWAP/UDP/IP between WTP<-->AC. This CAPWAP/UDP/IP=20 > could be called the "transport tunnel" from the perspective of the=20 > wireless client frames. >=20 > >From the perspective of UDP, the UDP port numbers generally > defines the application (in this case CAPWAP). Hence from the=20 > perspective of UDP, CAPWAP is an application. >=20 > So tunnel and UDP application are not mutually exclusive (it is a=20 > question of which layer's perspective one is talking about). >=20 > (b) I took Pat's comments to agree with my statements. Both he and I=20 > seem to be talking about fragmenting at the CAPWAP level before=20 > attaching a UDP/IP header. Maybe Pat can elaborate more on this. >=20 > Thanks. >=20 > -Puneet >=20 > -----Original Message----- > From: Changming Liu [mailto:cliu@juniper.net] > Sent: Thursday, January 05, 2006 4:50 PM > To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Puneet, >=20 > Thanks for your quick reply. One thing I am confused about is the=20 > definition of a tunnel vs. a UDP application. > Traditionally running an application on UDP/IP then over some kind of=20 > layer 2 is not defined as a tunnel rather just a normal UDP=20 > application. Otherwise, DNS, RTP, SIP or any application on top of UDP = > will become a tunnel instead of an application. So is CAPWAP an=20 > application of UDP or UDP/IP is tunnel to CAPWAP? As a application, it = > is usually does not deal with fragmentation issue because it deems it=20 > as IP layer issue. Otherwise, each application will have its own=20 > built-in fragmentation algorithm and this will defeat the purpose of=20 > having fragmentation functionality at IP layer. As a tunnel, a MTU may = > be optionally defined to avoid tunneled packet fragmentation. But my=20 > experience with IPsec tunnel tells me that sometimes the pre and post=20 > encapsulation are both needed to be supported at the same time unless=20 > the MTU of entire path of a tunnel is known. The "transport tunnel"=20 > is a definitely interesting definition. Not sure where this fits in. >=20 > The reason I talked about the tunnel vs application is that your=20 > answer to the fragmentation requirement is different from Pat's. His=20 > answer is about the middle box. Having worked on the firewall business = > for several years, I have hardly come across any middle box (firewall) = > to be configured to drop the fragmented IP packets. The customers or=20 > end users will screen at the IT if they chose to do that :-) Who knows = > how many layers of encap a packet will be subjected to after many=20 > layers of tunneling? Just for an example, IP over GRE over IPsec....=20 > Whatever running on the inner IP may be encapsulated with its own=20 > layers of tunnels.... As having been pointed out, the fragmentation is = > not avoidable in today's networks, simply dropping it is usually not=20 > an option at all for any serious and real deployment. This may be true = > for some old stateless packet filtering firewalls. Not sure how many=20 > really still be deployed there. >=20 > Changming >=20 >=20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Thursday, January 05, 2006 1:55 PM > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Hi Changming, >=20 > 1) Each transport tunnel has an MTU. If you know that you are going to = > be exceeding that MTU when encapsulating the wireless frame, then it=20 > is better to fragment at the LWAPP/CAPWAP level to avoid IP fragments=20 > (when UDP/IP is the transport). It is not a question of whether=20 > middleboxes (eg: > firewalls) can handle IP fragments or not (I assume that most can but=20 > there are of course legacy issues) - but the most common configuration = > of these deployed middleboxes is to drop IP fragments. >=20 > If routers in the path of the WTP and AC want to IP fragment, then=20 > that is definitely allowed and valid (with the caveat that some=20 > middleboxes might drop these fragmented pkts). Even if path MTU=20 > discovery is not done, one could argue that setting the UDP/IP=20 > transport MTU to (1500-20-8)=3D 1472 would work under most = circumstances=20 > without the packet getting further IP fragmented by intervening=20 > routers (assuming you don't have any other VPN tunnels etc in the=20 > path). >=20 > 2) Packet/fragment reordering is not really an issue for CAPWAP (and I = > agree with you). >=20 > Thanks. >=20 > -Puneet >=20 > -----Original Message----- > From: Changming Liu [mailto:cliu@juniper.net] > Sent: Thursday, January 05, 2006 12:51 PM > To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay;=20 > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > A couple of questions about the benefits of this application=20 > fragmentation just out of my ignorance. >=20 > 1) Most commercial firewalls handles IP fragments well to an=20 > acceptable degree (I don't think anybody will buy one which does not)=20 > since fragmentation is common norm in IPv4. I guess it needs to be=20 > handled one way or another even by the non-commercial ones. Not sure=20 > why this issue is particular different for CAPWAP? If AC and APs are=20 > connected via routers in several hops (this may be a likely case that=20 > a firewall exists between the AC and APs), IPv4 fragmentation may=20 > still be encountered because IPv4 path MTU is not used widely as we'd=20 > like to. >=20 > 2) Packet and fragment re-ordering are two different issues and should = > be handled differently. Packet re-ordering is an issue that=20 > application needs to handle if the order is important to it like RTP=20 > stream. The IP fragmentation is an IP layer issue and should be dealt=20 > with at IP layer. There should some solution today at IP layer. Not=20 > sure this is particularly important to CAPWAP. >=20 > Do I miss anything? >=20 > Changming >=20 > -----Original Message----- > From: Darren Loher [mailto:dloher@rovingplanet.com] > Sent: Thursday, January 05, 2006 11:05 AM > To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas Manral;=20 > Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Thanks for the full explanation Puneet. With fragmentation done at=20 > the application (CAPWAP/LWAPP) layer this means every frame must have=20 > a LWAPP header. >=20 > I agree that this is especially important to get right as Pat pointed=20 > out that tunneled data packets will commonly need to be fragmented. >=20 > I another reason it's important not to have a standard IP stack=20 > reassemble frames is due to possible packet/fragment reordering. If=20 > the network were to reorder the CAPWAP/LWAPP UDP tunnel packets for=20 > any reason, it would result in corrupting the data frames inside the=20 > tunnel. We need the > FragID field of the LWAPP/CAPWAP header to help us there. =20 >=20 > -Darren >=20 > > -----Original Message----- > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Thursday, January 05, 2006 10:52 AM > > To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit > Choudhury; > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Hi All, > >=20 > > Just to remove any confusion, by application level fragmentation, I=20 > > mean the LWAPP level fragmentation (as LWAPP is the > application from > > the UDP/IP transport perspective). Hopefully this answers > your question Sujoy. > >=20 > > Hence the proposal is to fragment the wireless frame at the LWAPP=20 > > level (F, L, Frag-Id would be valid - even for UDP/IP transport)=20 > > before encapsulating the wireless frame in the transport (UDP/IP)=20 > > headers (just like it is proposed in the spec for L2 transport). > >=20 > > So conceptually LWAPP/CAPWAP should be agnostic of transport and=20 > > assumes that the transport does not support fragmentation. > This gets > > rid of the middlebox problem (for IP fragments) and is > architecturally clean too. > >=20 > > Thanks. > >=20 > > -Puneet > >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Thursday, January 05, 2006 8:28 AM > > To: sujay; Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > If we let IP handle fragmentation, then we do not have control over=20 > > adding LWAPP headers to it. It is true that having LWAPP perform=20 > > fragmentation, and add an independent header, would allow for any=20 > > middlebox (including > > firewall) traversal. Given the likelihood of fragmentated frames is=20 > > certain (given we are tunneling MTU sized frames), I agree with=20 > > Puneet's recommendation. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sujay [mailto:sujayg@huawei.com] > > > Sent: Wednesday, January 04, 2006 10:45 PM > > > To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury';=20 > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > Hi Vishwas, > > > > > > The F, L and Frag-id fields should be of use only for L2 > transport. > > > > > > Fragmentation causes issues at the firewalls, essentially because=20 > > > the lwapp header is carried in the first fragment alone. > > > > > > If the MTU is pre-determined for IPv4/6, the application > has to take > > > care of re-assembly. > > > There the F, L and Frag- id fields could be of use. > > > Additionally a few more fields may be required ! > > > > > > Puneet, > > > IMO there is no advantage by pushing the fragmentation/ > assembly to > > > the application. > > > > > > If firewall is the issue, is it possible to add the lwapp > header in > > > all fragments..?? > > > > > > Regds, > > > Sujay > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > Sent: Thursday, January 05, 2006 10:09 AM > > > To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > Hi Puneet, > > > > > > One small typo!! I had stated "I guess for IPv6 it is > already stated > > > that we do not do fragmentation at LWAPP level" I meant at > > > "IPv6 level" > > > I meant. > > > > > > Thanks, > > > Vishwas > > > -----Original Message----- > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > Sent: Thursday, January 05, 2006 9:54 AM > > > To: Puneet Agarwal; Abhijit Choudhury; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > Hi Puneet, > > > > > > I think you mean all middleboxes and not just firewalls. > > > > > > I guess for IPv6 it is already stated that we do not do=20 > > > fragmentation at LWAPP level because we have to do MTU > discovery and > > > hence fragments can be done at the application level > itself. I think > > > only if Path MTU discovery is done for IPv4 too, can we > avoid fragmentation. > > > > > > Are you saying that the F, L and Fragment Id fields were > only valid > > > for > > > Layer-2 transport and not for Layer-3 transport earlier? > > > > > > Thanks, > > > Vishwas > > > ________________________________________ > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > Sent: Thursday, January 05, 2006 4:16 AM > > > To: Abhijit Choudhury; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > The main issue is passing IP fragments via firewalls.=20 > Most firewalls > > > drop fragmented packets (in fact the note is section 3.3.4 also=20 > > > refers to that). Hence the question. > > > > > > Hope this helps. > > > > > > Thanks. > > > > > > -Puneet > > > > > > ________________________________________ > > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > > Sent: Wednesday, January 04, 2006 11:42 AM > > > To: Puneet Agarwal; capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft For L3 > transport, > > > as the spec says, only the first IP fragment would have > an LWAPP header. > > > Standard IP reassembly is used to put the fragments > together.=A0 F, L, > > > and FragID fields in the LWAPP header are not neeed for > reassembly. > > > > > > Am I missing something ? > > > > > > Thanks, > > > =A0=A0 Abhijit > > > -----Original Message----- > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > Sent: Tuesday, January 03, 2006 7:57 PM > > > To: capwap@frascone.com; Pat Calhoun (pacalhou) > > > Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4=20 > > > frag/reassembly (Section 3.3.4): > > > > > > There=A0was some talk=A0in the past about performing the=20 > > > fragmentation/reassembly at the application level to avoid IP=20 > > > fragments. > > > In that case, the F,L and FragID bits would need to be > used even for > > > L3 transport. Did we ever reach a consensus on this one? > > > > > > My recommendation would be to do the frag/reassembly at > application > > > level. > > > > > > Thanks. > > > > > > -Puneet > > > > > > > > > _________________________________________________________________ > > > 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 > > > > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > >=20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From abimvanderbi@gosouththai.com Sun Jan 15 12:04:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBJ0-0004ah-CH for capwap-archive@megatron.ietf.org; Sun, 15 Jan 2006 12:04:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11944 for ; Sun, 15 Jan 2006 12:00:09 -0500 (EST) Received: from bzq-84-110-51-154.red.bezeqint.net ([84.110.51.154] helo=gosouththai.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Exhbd-0000eH-Gi for capwap-archive@ietf.org; Sat, 14 Jan 2006 04:21:54 -0500 Message-ID: <000001c618ea$d89fc100$cf40a8c0@persistence> Reply-To: "Abimelech Vanderbilt" From: "Abimelech Vanderbilt" To: "Bethan Breaux" Subject: Phrmaceutfi cal Excellent Date: Sat, 14 Jan 2006 04:13:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C618C0.EFC9B900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C618C0.EFC9B900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.cenreitsel.com =20 =20 Xan So VA VlA ClA Am ax ma=20 LIU GR LIS bie M A n from=20 $1. $1. $1. $3. $3. $2. 42 12 21 75 75 89 =20 ------=_NextPart_000_0001_01C618C0.EFC9B900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.cenreitsel.com

Xan
So
VA
VlA
ClA
Am

ax
ma
LIU
GR
LIS
bie

M
A

n

from

$1.
$1.
$1.
$3.
$3.
$2.

42
12
21
75
75
89

------=_NextPart_000_0001_01C618C0.EFC9B900-- From Xtvniuoju@optonline.com Sun Jan 15 14:00:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyD4q-0004NV-LU; Sun, 15 Jan 2006 13:58:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29399; Sun, 15 Jan 2006 11:12:25 -0500 (EST) Message-Id: <200601151612.LAA29399@ietf.org> Received: from e182055229.adsl.alicedsl.de ([85.182.55.229] helo=lh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyAcY-0006s5-H5; Sun, 15 Jan 2006 11:20:47 -0500 From: "Hilary Costa" To: rip@ietf.org Subject: MBA-degr3ees not for sale- get it. Date: Sun, 15 Jan 2006 13:04:45 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_GTQVPDTS.XJRDGXYB" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0000_GTQVPDTS.XJRDGXYB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit UNIVERSITY DIPLOMAS OBTAIN A PROSPEROUS FUTURE, MONEY-EARNING POWER, AND THE PRESTIGE THAT COMES WITH THE DEGREE YOU HAVE ALWAYS DREAMED OF. NON-ACCREDITED UNIVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND LIFE EXPERIENCE. If you qualify, no tests, study, books or exams. We have Bachelor's, MBA's, Doctorate & PhD degrees available in your field. CONFIDENTIALITY ASSURED CALL NOW TO GET YOUR DIPLOMA WITHIN 2 WEEKS 1-206-984-0106 CALL 24 HOURS, 7 DAYS A WEEK ------=_NextPart_000_0000_GTQVPDTS.XJRDGXYB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit UNIVERSITY DIPLOMAS

OBTAIN A PROSPEROUS FUTURE, MONEY-EARNING POWER, AND THE PRESTIGE THAT COMES WITH THE DEGREE YOU HAVE ALWAYS DREAMED OF.

NON-ACCREDITED UNIVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND LIFE EXPERIENCE.

If you qualify, no tests, study, books or exams.

We have Bachelor's, MBA's, Doctorate & PhD degrees available in your field.

CONFIDENTIALITY ASSURED

CALL NOW TO GET YOUR DIPLOMA WITHIN 2 WEEKS

1-206-984-0106

CALL 24 HOURS, 7 DAYS A WEEK

------=_NextPart_000_0000_GTQVPDTS.XJRDGXYB-- From info@mail.gpvv.com Sun Jan 15 22:48:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyLLt-0004rt-TB for capwap-archive@megatron.ietf.org; Sun, 15 Jan 2006 22:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08450 for ; Sun, 15 Jan 2006 22:46:53 -0500 (EST) Received: from [202.127.114.2] (helo=mail.gpvv.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyLTi-0008LF-5h for capwap-archive@ietf.org; Sun, 15 Jan 2006 22:56:24 -0500 Received: (qmail 14710 invoked by uid 509); 16 Jan 2006 10:35:36 +0900 Date: 16 Jan 2006 10:35:36 +0900 Message-ID: <20060116013536.14708.qmail@mail.gpvv.com> From: info@gpvv.com To: capwap-archive@ietf.org Subject: $BB(F|?6$j9~$_7hDj(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 $B!Z9b3[$NJs=7![(B $B"#=w@-$H$N8r>D$7$F$$$kM}7CMM$HD>@\8r>D(B $B$7$FD:$-A06b$GH>3[(B(7$BK|0J>e(B)$B?6$j9~$_$G=w@-$NMWK>$rK~$?$;$?8e7@Ls6b(B $BA43[$r(BGET$B$7$F$$$?$@$/%7%9%F%`$K$J$j$^$9!#(B $B?69~$_4uK>$NJ}$OAa5^$K2<5-$h$j!Z40A4L5NA![$N(B $BEPO?$r:Q$^$;$F2<$5$$(B $B!Z40A4L5NA![$NEPO?3NG'8e!">R2pAj@\$*Fs?M$G:#8e$NM=Dj$r$*7h$a2<$5$$!#(B $B"(EPO?$N:]!Z(B*1$B![$r$*IU$1$$$@$1$l$P!ZM}7CMM![MM$KM%@h$7$F%a!<%k$,(B $BAw$l$k@_Dj$K$5$;$F$$$?$@$-$^$9!#KtM}7CMM$OD$9$k!&$7$J$$$NH=CG$r$7$F$$$@$1$l$P$H;W$$$^$9(B $B:#8eG[?.$r5qH]$5$l$kJ}$O(B refuse@renai-h1.com From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jan 15 23:02:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyLZz-0007oX-8j for capwap-archive@megatron.ietf.org; Sun, 15 Jan 2006 23:02:51 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09045 for ; Sun, 15 Jan 2006 23:01:26 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8149E4300BC for ; Sun, 15 Jan 2006 20:02:49 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 9F3DB430048 for ; Sun, 15 Jan 2006 20:02:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8C971398051 for ; Sun, 15 Jan 2006 20:02:06 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5A544398044 for ; Sun, 15 Jan 2006 20:02:02 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 15 Jan 2006 20:02:03 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0G421Qi009567; Sun, 15 Jan 2006 20:02:02 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 15 Jan 2006 20:02:01 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Question on LWAPP-03 draft X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Jan 2006 20:02:01 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D8FEA@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Question on LWAPP-03 draft Thread-Index: AcYRxLrlq9xPFdKYSlqnnrOiInGSnQAT/fYQAAJWJVAAAr/CQAADb6mwAAIZt8AABZdcMADE3JOQAL3R50AABDzwQAAGESkQAGzt9kA= From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , "Puneet Agarwal" , "Changming Liu" , "Darren Loher" , "sujay" , "Vishwas Manral" , "Abhijit Choudhury" , X-OriginalArrivalTime: 16 Jan 2006 04:02:01.0889 (UTC) FILETIME=[9AD3E910:01C61A51] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable The LWAPP protocol does allow for the packets to be fragmented at the = application layer, and yes, we have found this to be more transparent to = any middlebox (FW or not) system, that would otherwise have store any = fragments and reassemble in order to determine whether they comply to a = corporate policy. Yes, you are correct that the simple inclusion of a = site-to-site IPSec tunnel would resolve this problem, but we are = unfortunately not always in a position to require that customers change = their network deployments (hence cost) in order to deploy WLANs. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 > Sent: Friday, January 13, 2006 1:58 PM > To: Pat Calhoun (pacalhou); Puneet Agarwal; Changming Liu;=20 > Darren Loher; sujay; Vishwas Manral; Abhijit Choudhury;=20 > capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > Using a firewall seems as a reasonable choice for a topology=20 > where the AC and WTP are in separate geographical sites. The=20 > immediate follow up question that came in mind would be: does=20 > your solution employ a fragmentation scheme at the=20 > application level or let the IP transport layer handle it? >=20 > Another point is the use of VPN gateway. I'd think that it's=20 > rational to assume that the remote WTP is probably the only=20 > topology in which firewall make sense, thus wouldn't the VPN=20 > gateway at both ends moot the issue? >=20 > Regards, > Emek >=20 > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Friday, January 13, 2006 1:44 PM > To: Sadot, Emek (Emek); Puneet Agarwal; Changming Liu; Darren=20 > Loher; sujay; Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > Subject: RE: [Capwap] Question on LWAPP-03 draft >=20 > I'm aware of several of my customers using FWs to remote=20 > sites with WTPs. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > > -----Original Message----- > > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] > > Sent: Friday, January 13, 2006 8:54 AM > > To: Puneet Agarwal; Changming Liu; Darren Loher; Pat Calhoun=20 > > (pacalhou); sujay; Vishwas Manral; Abhijit Choudhury;=20 > > capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > A question about former tunneling protocols architectures=20 > (just out of=20 > > my ignorance): what is the landscape and motivations of other=20 > > tunneling protocol that adopted a fragmentation at=20 > application level=20 > > solution? > >=20 > > Out of curiosity, would it be fair to assume that most of=20 > the CAPWAP=20 > > installations would be confined by a localized mobility domain were=20 > > intermediate firewall is not likely to reside? > >=20 > > Regards, > > Emek > >=20 > > -----Original Message----- > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Monday, January 09, 2006 5:29 PM > > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Hi Changming, > >=20 > > (a) For CAPWAP data frames (C=3D0), you are "tunneling"=20 > > wireless client frames inside the CAPWAP hdr (between the=20 > AC and WTP).=20 > > Hence from the perspective of the wireless client frames - they are=20 > > tunneled inside a CAPWAP/UDP/IP between WTP<-->AC. This=20 > CAPWAP/UDP/IP=20 > > could be called the "transport tunnel" from the perspective of the=20 > > wireless client frames. > >=20 > > >From the perspective of UDP, the UDP port numbers generally > > defines the application (in this case CAPWAP). Hence from the=20 > > perspective of UDP, CAPWAP is an application. > >=20 > > So tunnel and UDP application are not mutually exclusive (it is a=20 > > question of which layer's perspective one is talking about). > >=20 > > (b) I took Pat's comments to agree with my statements. Both=20 > he and I=20 > > seem to be talking about fragmenting at the CAPWAP level before=20 > > attaching a UDP/IP header. Maybe Pat can elaborate more on this. > >=20 > > Thanks. > >=20 > > -Puneet > >=20 > > -----Original Message----- > > From: Changming Liu [mailto:cliu@juniper.net] > > Sent: Thursday, January 05, 2006 4:50 PM > > To: Puneet Agarwal; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Hi Puneet, > >=20 > > Thanks for your quick reply. One thing I am confused about is the=20 > > definition of a tunnel vs. a UDP application. > > Traditionally running an application on UDP/IP then over=20 > some kind of=20 > > layer 2 is not defined as a tunnel rather just a normal UDP=20 > > application. Otherwise, DNS, RTP, SIP or any application on=20 > top of UDP=20 > > will become a tunnel instead of an application. So is CAPWAP an=20 > > application of UDP or UDP/IP is tunnel to CAPWAP? As a=20 > application, it=20 > > is usually does not deal with fragmentation issue because=20 > it deems it=20 > > as IP layer issue. Otherwise, each application will have its own=20 > > built-in fragmentation algorithm and this will defeat the=20 > purpose of=20 > > having fragmentation functionality at IP layer. As a=20 > tunnel, a MTU may=20 > > be optionally defined to avoid tunneled packet=20 > fragmentation. But my=20 > > experience with IPsec tunnel tells me that sometimes the=20 > pre and post=20 > > encapsulation are both needed to be supported at the same=20 > time unless=20 > > the MTU of entire path of a tunnel is known. The "transport tunnel" > > is a definitely interesting definition. Not sure where this fits in. > >=20 > > The reason I talked about the tunnel vs application is that your=20 > > answer to the fragmentation requirement is different from=20 > Pat's. His=20 > > answer is about the middle box. Having worked on the=20 > firewall business=20 > > for several years, I have hardly come across any middle box=20 > (firewall)=20 > > to be configured to drop the fragmented IP packets. The=20 > customers or=20 > > end users will screen at the IT if they chose to do that=20 > :-) Who knows=20 > > how many layers of encap a packet will be subjected to after many=20 > > layers of tunneling? Just for an example, IP over GRE over IPsec.... > > Whatever running on the inner IP may be encapsulated with its own=20 > > layers of tunnels.... As having been pointed out, the=20 > fragmentation is=20 > > not avoidable in today's networks, simply dropping it is=20 > usually not=20 > > an option at all for any serious and real deployment. This=20 > may be true=20 > > for some old stateless packet filtering firewalls. Not sure=20 > how many=20 > > really still be deployed there. > >=20 > > Changming > >=20 > >=20 > > -----Original Message----- > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > Sent: Thursday, January 05, 2006 1:55 PM > > To: Changming Liu; Darren Loher; Pat Calhoun (pacalhou); sujay;=20 > > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Hi Changming, > >=20 > > 1) Each transport tunnel has an MTU. If you know that you=20 > are going to=20 > > be exceeding that MTU when encapsulating the wireless=20 > frame, then it=20 > > is better to fragment at the LWAPP/CAPWAP level to avoid IP=20 > fragments=20 > > (when UDP/IP is the transport). It is not a question of whether=20 > > middleboxes (eg: > > firewalls) can handle IP fragments or not (I assume that=20 > most can but=20 > > there are of course legacy issues) - but the most common=20 > configuration=20 > > of these deployed middleboxes is to drop IP fragments. > >=20 > > If routers in the path of the WTP and AC want to IP fragment, then=20 > > that is definitely allowed and valid (with the caveat that some=20 > > middleboxes might drop these fragmented pkts). Even if path MTU=20 > > discovery is not done, one could argue that setting the UDP/IP=20 > > transport MTU to (1500-20-8)=3D 1472 would work under most=20 > circumstances=20 > > without the packet getting further IP fragmented by intervening=20 > > routers (assuming you don't have any other VPN tunnels etc in the=20 > > path). > >=20 > > 2) Packet/fragment reordering is not really an issue for=20 > CAPWAP (and I=20 > > agree with you). > >=20 > > Thanks. > >=20 > > -Puneet > >=20 > > -----Original Message----- > > From: Changming Liu [mailto:cliu@juniper.net] > > Sent: Thursday, January 05, 2006 12:51 PM > > To: Darren Loher; Puneet Agarwal; Pat Calhoun (pacalhou); sujay;=20 > > Vishwas Manral; Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > A couple of questions about the benefits of this application=20 > > fragmentation just out of my ignorance. > >=20 > > 1) Most commercial firewalls handles IP fragments well to an=20 > > acceptable degree (I don't think anybody will buy one which=20 > does not)=20 > > since fragmentation is common norm in IPv4. I guess it needs to be=20 > > handled one way or another even by the non-commercial ones.=20 > Not sure=20 > > why this issue is particular different for CAPWAP? If AC=20 > and APs are=20 > > connected via routers in several hops (this may be a likely=20 > case that=20 > > a firewall exists between the AC and APs), IPv4 fragmentation may=20 > > still be encountered because IPv4 path MTU is not used=20 > widely as we'd=20 > > like to. > >=20 > > 2) Packet and fragment re-ordering are two different issues=20 > and should=20 > > be handled differently. Packet re-ordering is an issue that=20 > > application needs to handle if the order is important to it=20 > like RTP=20 > > stream. The IP fragmentation is an IP layer issue and=20 > should be dealt=20 > > with at IP layer. There should some solution today at IP layer. Not=20 > > sure this is particularly important to CAPWAP. > >=20 > > Do I miss anything? > >=20 > > Changming > >=20 > > -----Original Message----- > > From: Darren Loher [mailto:dloher@rovingplanet.com] > > Sent: Thursday, January 05, 2006 11:05 AM > > To: Puneet Agarwal; Pat Calhoun (pacalhou); sujay; Vishwas Manral;=20 > > Abhijit Choudhury; capwap@frascone.com > > Subject: RE: [Capwap] Question on LWAPP-03 draft > >=20 > > Thanks for the full explanation Puneet. With fragmentation done at=20 > > the application (CAPWAP/LWAPP) layer this means every frame=20 > must have=20 > > a LWAPP header. > >=20 > > I agree that this is especially important to get right as=20 > Pat pointed=20 > > out that tunneled data packets will commonly need to be fragmented. > >=20 > > I another reason it's important not to have a standard IP stack=20 > > reassemble frames is due to possible packet/fragment=20 > reordering. If=20 > > the network were to reorder the CAPWAP/LWAPP UDP tunnel packets for=20 > > any reason, it would result in corrupting the data frames=20 > inside the=20 > > tunnel. We need the > > FragID field of the LWAPP/CAPWAP header to help us there. =20 > >=20 > > -Darren > >=20 > > > -----Original Message----- > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > Sent: Thursday, January 05, 2006 10:52 AM > > > To: Pat Calhoun (pacalhou); sujay; Vishwas Manral; Abhijit > > Choudhury; > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > >=20 > > > Hi All, > > >=20 > > > Just to remove any confusion, by application level=20 > fragmentation, I=20 > > > mean the LWAPP level fragmentation (as LWAPP is the > > application from > > > the UDP/IP transport perspective). Hopefully this answers > > your question Sujoy. > > >=20 > > > Hence the proposal is to fragment the wireless frame at the LWAPP=20 > > > level (F, L, Frag-Id would be valid - even for UDP/IP transport)=20 > > > before encapsulating the wireless frame in the transport (UDP/IP)=20 > > > headers (just like it is proposed in the spec for L2 transport). > > >=20 > > > So conceptually LWAPP/CAPWAP should be agnostic of transport and=20 > > > assumes that the transport does not support fragmentation. > > This gets > > > rid of the middlebox problem (for IP fragments) and is > > architecturally clean too. > > >=20 > > > Thanks. > > >=20 > > > -Puneet > > >=20 > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Thursday, January 05, 2006 8:28 AM > > > To: sujay; Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > > capwap@frascone.com > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > >=20 > > > If we let IP handle fragmentation, then we do not have=20 > control over=20 > > > adding LWAPP headers to it. It is true that having LWAPP perform=20 > > > fragmentation, and add an independent header, would allow for any=20 > > > middlebox (including > > > firewall) traversal. Given the likelihood of fragmentated=20 > frames is=20 > > > certain (given we are tunneling MTU sized frames), I agree with=20 > > > Puneet's recommendation. > > >=20 > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: sujay [mailto:sujayg@huawei.com] > > > > Sent: Wednesday, January 04, 2006 10:45 PM > > > > To: 'Vishwas Manral'; 'Puneet Agarwal'; 'Abhijit Choudhury';=20 > > > > capwap@frascone.com > > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > > > > Hi Vishwas, > > > > > > > > The F, L and Frag-id fields should be of use only for L2 > > transport. > > > > > > > > Fragmentation causes issues at the firewalls,=20 > essentially because=20 > > > > the lwapp header is carried in the first fragment alone. > > > > > > > > If the MTU is pre-determined for IPv4/6, the application > > has to take > > > > care of re-assembly. > > > > There the F, L and Frag- id fields could be of use. > > > > Additionally a few more fields may be required ! > > > > > > > > Puneet, > > > > IMO there is no advantage by pushing the fragmentation/ > > assembly to > > > > the application. > > > > > > > > If firewall is the issue, is it possible to add the lwapp > > header in > > > > all fragments..?? > > > > > > > > Regds, > > > > Sujay > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > > Sent: Thursday, January 05, 2006 10:09 AM > > > > To: Vishwas Manral; Puneet Agarwal; Abhijit Choudhury;=20 > > > > capwap@frascone.com > > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > > > > > Hi Puneet, > > > > > > > > One small typo!! I had stated "I guess for IPv6 it is > > already stated > > > > that we do not do fragmentation at LWAPP level" I meant at > > > > "IPv6 level" > > > > I meant. > > > > > > > > Thanks, > > > > Vishwas > > > > -----Original Message----- > > > > From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > > Sent: Thursday, January 05, 2006 9:54 AM > > > > To: Puneet Agarwal; Abhijit Choudhury; capwap@frascone.com > > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > Hi Puneet, > > > > > > > > I think you mean all middleboxes and not just firewalls. > > > > > > > > I guess for IPv6 it is already stated that we do not do=20 > > > > fragmentation at LWAPP level because we have to do MTU > > discovery and > > > > hence fragments can be done at the application level > > itself. I think > > > > only if Path MTU discovery is done for IPv4 too, can we > > avoid fragmentation. > > > > > > > > Are you saying that the F, L and Fragment Id fields were > > only valid > > > > for > > > > Layer-2 transport and not for Layer-3 transport earlier? > > > > > > > > Thanks, > > > > Vishwas > > > > ________________________________________ > > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > > Sent: Thursday, January 05, 2006 4:16 AM > > > > To: Abhijit Choudhury; capwap@frascone.com > > > > Subject: RE: [Capwap] Question on LWAPP-03 draft > > > > > > > > The main issue is passing IP fragments via firewalls.=20 > > Most firewalls > > > > drop fragmented packets (in fact the note is section 3.3.4 also=20 > > > > refers to that). Hence the question. > > > > > > > > Hope this helps. > > > > > > > > Thanks. > > > > > > > > -Puneet > > > > > > > > ________________________________________ > > > > From: Abhijit Choudhury [mailto:Abhijit@sinett.com] > > > > Sent: Wednesday, January 04, 2006 11:42 AM > > > > To: Puneet Agarwal; capwap@frascone.com > > > > Subject: RE: [Capwap] Question on LWAPP-03 draft For L3 > > transport, > > > > as the spec says, only the first IP fragment would have > > an LWAPP header. > > > > Standard IP reassembly is used to put the fragments > > together.=A0 F, L, > > > > and FragID fields in the LWAPP header are not neeed for > > reassembly. > > > > > > > > Am I missing something ? > > > > > > > > Thanks, > > > > =A0=A0 Abhijit > > > > -----Original Message----- > > > > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > > > > Sent: Tuesday, January 03, 2006 7:57 PM > > > > To: capwap@frascone.com; Pat Calhoun (pacalhou) > > > > Subject: [Capwap] Question on LWAPP-03 draft Question of IPv4=20 > > > > frag/reassembly (Section 3.3.4): > > > > > > > > There=A0was some talk=A0in the past about performing the=20 > > > > fragmentation/reassembly at the application level to avoid IP=20 > > > > fragments. > > > > In that case, the F,L and FragID bits would need to be > > used even for > > > > L3 transport. Did we ever reach a consensus on this one? > > > > > > > > My recommendation would be to do the frag/reassembly at > > application > > > > level. > > > > > > > > Thanks. > > > > > > > > -Puneet > > > > > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > >=20 > _________________________________________________________________ > > > > To unsubscribe or modify your subscription options,=20 > please visit: > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > >=20 > > >=20 > > > _________________________________________________________________ > > > To unsubscribe or modify your subscription options, please visit: > > > http://lists.frascone.com/mailman/listinfo/capwap > > >=20 > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > >=20 > >=20 > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > >=20 > > Archives: http://lists.frascone.com/pipermail/capwap > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 16 07:54:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyTsl-00036B-4u for capwap-archive@megatron.ietf.org; Mon, 16 Jan 2006 07:54:47 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09670 for ; Mon, 16 Jan 2006 07:53:21 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5EDBA43005F for ; Mon, 16 Jan 2006 04:54:44 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id A5360430058 for ; Mon, 16 Jan 2006 04:54:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9565880C0E8 for ; Mon, 16 Jan 2006 04:54:06 -0800 (PST) Received: from mail.sbs.be (mail.sbs.be [193.109.72.11]) by hermes.tigertech.net (Postfix) with ESMTP id 2C35580C117 for ; Mon, 16 Jan 2006 04:54:03 -0800 (PST) Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GCs2bN023826 for ; Mon, 16 Jan 2006 13:54:02 +0100 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GCs17W027442 for ; Mon, 16 Jan 2006 13:54:02 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.64]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 13:54:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jan 2006 13:54:00 +0100 Message-ID: <9C04C4589B6701468A7F8AFAFA432DC4031389@BRU0038A.ww018.siemens.net> Thread-Topic: Capwap Digest, Vol 3, Issue 10 Thread-Index: AcYajoPOpvS7Lw3WRiSfnZnRx97DMgADWf5i From: "Steel, Dirk" To: X-OriginalArrivalTime: 16 Jan 2006 12:54:01.0030 (UTC) FILETIME=[EC1E4E60:01C61A9B] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] Re: Capwap Digest, Vol 3, Issue 10 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864778594==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com --===============1864778594== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2VudCB0byB5b3UgdXNpbmcgQmxhY2tCZXJy eSBlbWFpbCBvbiBteSBTaWVtZW5zIFNLNjUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogY2Fwd2FwLXJlcXVlc3RAZnJhc2NvbmUuY29tIDxjYXB3YXAtcmVxdWVzdEBmcmFz Y29uZS5jb20+DQpUbzogY2Fwd2FwQGZyYXNjb25lLmNvbSA8Y2Fwd2FwQGZyYXNjb25lLmNvbT4N ClNlbnQ6IE1vbiBKYW4gMTYgMTI6MTc6MzYgMjAwNg0KU3ViamVjdDogQ2Fwd2FwIERpZ2VzdCwg Vm9sIDMsIElzc3VlIDEwDQoNClNlbmQgQ2Fwd2FwIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0 bw0KCWNhcHdhcEBmcmFzY29uZS5jb20NCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZp YSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQoJaHR0cDovL2xpc3RzLmZyYXNjb25lLmNvbS9t YWlsbWFuL2xpc3RpbmZvL2NhcHdhcA0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0 aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQoJY2Fwd2FwLXJlcXVlc3RAZnJhc2NvbmUuY29t DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KCWNhcHdh cC1vd25lckBmcmFzY29uZS5jb20NCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBT dWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9m IENhcHdhcCBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIFJFOiBRdWVz dGlvbiBvbiBMV0FQUC0wMyBkcmFmdCAoUGF0IENhbGhvdW4gKHBhY2FsaG91KSkNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDENCkRhdGU6IFN1biwgMTUgSmFuIDIwMDYgMjA6MDI6MDEg LTA4MDANCkZyb206ICJQYXQgQ2FsaG91biAocGFjYWxob3UpIiA8cGNhbGhvdW5AY2lzY28uY29t Pg0KU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQpUbzog IlNhZG90LCBFbWVrIChFbWVrKSIgPGVzYWRvdEBhdmF5YS5jb20+LAkiUHVuZWV0IEFnYXJ3YWwi DQoJPHBhZ2Fyd2FsQGJyb2FkY29tLmNvbT4sCSJDaGFuZ21pbmcgTGl1IiA8Y2xpdUBqdW5pcGVy Lm5ldD4sCSJEYXJyZW4NCglMb2hlciIgPGRsb2hlckByb3ZpbmdwbGFuZXQuY29tPiwJInN1amF5 IiA8c3VqYXlnQGh1YXdlaS5jb20+LA0KCSJWaXNod2FzIE1hbnJhbCIgPFZpc2h3YXNAc2luZXR0 LmNvbT4sCSJBYmhpaml0IENob3VkaHVyeSINCgk8QWJoaWppdEBzaW5ldHQuY29tPiwgPGNhcHdh cEBmcmFzY29uZS5jb20+DQpNZXNzYWdlLUlEOg0KCTw0RkY4NEIwQkMyNzdGRjQ1QUEyN0ZFOTY5 REQ5NTZBMjAxM0Q4RkVBQHhtYi1zamMtMjM1LmFtZXIuY2lzY28uY29tPg0KQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOwljaGFyc2V0PSJpc28tODg1OS0xIg0KDQpUaGUgTFdBUFAgcHJvdG9jb2wg ZG9lcyBhbGxvdyBmb3IgdGhlIHBhY2tldHMgdG8gYmUgZnJhZ21lbnRlZCBhdCB0aGUgYXBwbGlj YXRpb24gbGF5ZXIsIGFuZCB5ZXMsIHdlIGhhdmUgZm91bmQgdGhpcyB0byBiZSBtb3JlIHRyYW5z cGFyZW50IHRvIGFueSBtaWRkbGVib3ggKEZXIG9yIG5vdCkgc3lzdGVtLCB0aGF0IHdvdWxkIG90 aGVyd2lzZSBoYXZlIHN0b3JlIGFueSBmcmFnbWVudHMgYW5kIHJlYXNzZW1ibGUgaW4gb3JkZXIg dG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhleSBjb21wbHkgdG8gYSBjb3Jwb3JhdGUgcG9saWN5LiBZ ZXMsIHlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBzaW1wbGUgaW5jbHVzaW9uIG9mIGEgc2l0ZS10 by1zaXRlIElQU2VjIHR1bm5lbCB3b3VsZCByZXNvbHZlIHRoaXMgcHJvYmxlbSwgYnV0IHdlIGFy ZSB1bmZvcnR1bmF0ZWx5IG5vdCBhbHdheXMgaW4gYSBwb3NpdGlvbiB0byByZXF1aXJlIHRoYXQg Y3VzdG9tZXJzIGNoYW5nZSB0aGVpciBuZXR3b3JrIGRlcGxveW1lbnRzIChoZW5jZSBjb3N0KSBp biBvcmRlciB0byBkZXBsb3kgV0xBTnMuDQoNClBhdCBDYWxob3VuDQpDVE8sIFdpcmVsZXNzIE5l dHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KQ2lzY28gU3lzdGVtcw0KDQogDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2Fkb3QsIEVtZWsgKEVtZWspIFttYWlsdG86ZXNh ZG90QGF2YXlhLmNvbV0gDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAxMywgMjAwNiAxOjU4IFBN DQo+IFRvOiBQYXQgQ2FsaG91biAocGFjYWxob3UpOyBQdW5lZXQgQWdhcndhbDsgQ2hhbmdtaW5n IExpdTsgDQo+IERhcnJlbiBMb2hlcjsgc3VqYXk7IFZpc2h3YXMgTWFucmFsOyBBYmhpaml0IENo b3VkaHVyeTsgDQo+IGNhcHdhcEBmcmFzY29uZS5jb20NCj4gU3ViamVjdDogUkU6IFtDYXB3YXBd IFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+IA0KPiBVc2luZyBhIGZpcmV3YWxsIHNlZW1z IGFzIGEgcmVhc29uYWJsZSBjaG9pY2UgZm9yIGEgdG9wb2xvZ3kgDQo+IHdoZXJlIHRoZSBBQyBh bmQgV1RQIGFyZSBpbiBzZXBhcmF0ZSBnZW9ncmFwaGljYWwgc2l0ZXMuIFRoZSANCj4gaW1tZWRp YXRlIGZvbGxvdyB1cCBxdWVzdGlvbiB0aGF0IGNhbWUgaW4gbWluZCB3b3VsZCBiZTogZG9lcyAN Cj4geW91ciBzb2x1dGlvbiBlbXBsb3kgYSBmcmFnbWVudGF0aW9uIHNjaGVtZSBhdCB0aGUgDQo+ IGFwcGxpY2F0aW9uIGxldmVsIG9yIGxldCB0aGUgSVAgdHJhbnNwb3J0IGxheWVyIGhhbmRsZSBp dD8NCj4gDQo+IEFub3RoZXIgcG9pbnQgaXMgdGhlIHVzZSBvZiBWUE4gZ2F0ZXdheS4gSSdkIHRo aW5rIHRoYXQgaXQncyANCj4gcmF0aW9uYWwgdG8gYXNzdW1lIHRoYXQgdGhlIHJlbW90ZSBXVFAg aXMgcHJvYmFibHkgdGhlIG9ubHkgDQo+IHRvcG9sb2d5IGluIHdoaWNoIGZpcmV3YWxsIG1ha2Ug c2Vuc2UsIHRodXMgd291bGRuJ3QgdGhlIFZQTiANCj4gZ2F0ZXdheSBhdCBib3RoIGVuZHMgbW9v dCB0aGUgaXNzdWU/DQo+IA0KPiBSZWdhcmRzLA0KPiBFbWVrDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQYXQgQ2FsaG91biAocGFjYWxob3UpIFttYWlsdG86cGNh bGhvdW5AY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTMsIDIwMDYgMTo0NCBQ TQ0KPiBUbzogU2Fkb3QsIEVtZWsgKEVtZWspOyBQdW5lZXQgQWdhcndhbDsgQ2hhbmdtaW5nIExp dTsgRGFycmVuIA0KPiBMb2hlcjsgc3VqYXk7IFZpc2h3YXMgTWFucmFsOyBBYmhpaml0IENob3Vk aHVyeTsgY2Fwd2FwQGZyYXNjb25lLmNvbQ0KPiBTdWJqZWN0OiBSRTogW0NhcHdhcF0gUXVlc3Rp b24gb24gTFdBUFAtMDMgZHJhZnQNCj4gDQo+IEknbSBhd2FyZSBvZiBzZXZlcmFsIG9mIG15IGN1 c3RvbWVycyB1c2luZyBGV3MgdG8gcmVtb3RlIA0KPiBzaXRlcyB3aXRoIFdUUHMuDQo+IA0KPiBQ YXQgQ2FsaG91bg0KPiBDVE8sIFdpcmVsZXNzIE5ldHdvcmtpbmcgQnVzaW5lc3MgVW5pdA0KPiBD aXNjbyBTeXN0ZW1zDQo+IA0KPiAgDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogU2Fkb3QsIEVtZWsgKEVtZWspIFttYWlsdG86ZXNhZG90QGF2YXlhLmNvbV0N Cj4gPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTMsIDIwMDYgODo1NCBBTQ0KPiA+IFRvOiBQdW5l ZXQgQWdhcndhbDsgQ2hhbmdtaW5nIExpdTsgRGFycmVuIExvaGVyOyBQYXQgQ2FsaG91biANCj4g PiAocGFjYWxob3UpOyBzdWpheTsgVmlzaHdhcyBNYW5yYWw7IEFiaGlqaXQgQ2hvdWRodXJ5OyAN Cj4gPiBjYXB3YXBAZnJhc2NvbmUuY29tDQo+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0 aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+ID4gDQo+ID4gQSBxdWVzdGlvbiBhYm91dCBmb3JtZXIg dHVubmVsaW5nIHByb3RvY29scyBhcmNoaXRlY3R1cmVzIA0KPiAoanVzdCBvdXQgb2YgDQo+ID4g bXkgaWdub3JhbmNlKTogd2hhdCBpcyB0aGUgbGFuZHNjYXBlIGFuZCBtb3RpdmF0aW9ucyBvZiBv dGhlciANCj4gPiB0dW5uZWxpbmcgcHJvdG9jb2wgdGhhdCBhZG9wdGVkIGEgZnJhZ21lbnRhdGlv biBhdCANCj4gYXBwbGljYXRpb24gbGV2ZWwgDQo+ID4gc29sdXRpb24/DQo+ID4gDQo+ID4gT3V0 IG9mIGN1cmlvc2l0eSwgd291bGQgaXQgYmUgZmFpciB0byBhc3N1bWUgdGhhdCBtb3N0IG9mIA0K PiB0aGUgQ0FQV0FQIA0KPiA+IGluc3RhbGxhdGlvbnMgd291bGQgYmUgY29uZmluZWQgYnkgYSBs b2NhbGl6ZWQgbW9iaWxpdHkgZG9tYWluIHdlcmUgDQo+ID4gaW50ZXJtZWRpYXRlIGZpcmV3YWxs IGlzIG5vdCBsaWtlbHkgdG8gcmVzaWRlPw0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gRW1law0K PiA+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUHVuZWV0IEFn YXJ3YWwgW21haWx0bzpwYWdhcndhbEBicm9hZGNvbS5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBK YW51YXJ5IDA5LCAyMDA2IDU6MjkgUE0NCj4gPiBUbzogQ2hhbmdtaW5nIExpdTsgRGFycmVuIExv aGVyOyBQYXQgQ2FsaG91biAocGFjYWxob3UpOyBzdWpheTsgDQo+ID4gVmlzaHdhcyBNYW5yYWw7 IEFiaGlqaXQgQ2hvdWRodXJ5OyBjYXB3YXBAZnJhc2NvbmUuY29tDQo+ID4gU3ViamVjdDogUkU6 IFtDYXB3YXBdIFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+ID4gDQo+ID4gSGkgQ2hhbmdt aW5nLA0KPiA+IA0KPiA+IChhKSBGb3IgQ0FQV0FQIGRhdGEgZnJhbWVzIChDPTApLCB5b3UgYXJl ICJ0dW5uZWxpbmciIA0KPiA+IHdpcmVsZXNzIGNsaWVudCBmcmFtZXMgaW5zaWRlIHRoZSBDQVBX QVAgaGRyIChiZXR3ZWVuIHRoZSANCj4gQUMgYW5kIFdUUCkuIA0KPiA+IEhlbmNlIGZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIHRoZSB3aXJlbGVzcyBjbGllbnQgZnJhbWVzIC0gdGhleSBhcmUgDQo+ ID4gdHVubmVsZWQgaW5zaWRlIGEgQ0FQV0FQL1VEUC9JUCBiZXR3ZWVuIFdUUDwtLT5BQy4gVGhp cyANCj4gQ0FQV0FQL1VEUC9JUCANCj4gPiBjb3VsZCBiZSBjYWxsZWQgdGhlICJ0cmFuc3BvcnQg dHVubmVsIiBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgDQo+ID4gd2lyZWxlc3MgY2xpZW50 IGZyYW1lcy4NCj4gPiANCj4gPiA+RnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgVURQLCB0aGUgVURQ IHBvcnQgbnVtYmVycyBnZW5lcmFsbHkNCj4gPiBkZWZpbmVzIHRoZSBhcHBsaWNhdGlvbiAoaW4g dGhpcyBjYXNlIENBUFdBUCkuIEhlbmNlIGZyb20gdGhlIA0KPiA+IHBlcnNwZWN0aXZlIG9mIFVE UCwgQ0FQV0FQIGlzIGFuIGFwcGxpY2F0aW9uLg0KPiA+IA0KPiA+IFNvIHR1bm5lbCBhbmQgVURQ IGFwcGxpY2F0aW9uIGFyZSBub3QgbXV0dWFsbHkgZXhjbHVzaXZlIChpdCBpcyBhIA0KPiA+IHF1 ZXN0aW9uIG9mIHdoaWNoIGxheWVyJ3MgcGVyc3BlY3RpdmUgb25lIGlzIHRhbGtpbmcgYWJvdXQp Lg0KPiA+IA0KPiA+IChiKSBJIHRvb2sgUGF0J3MgY29tbWVudHMgdG8gYWdyZWUgd2l0aCBteSBz dGF0ZW1lbnRzLiBCb3RoIA0KPiBoZSBhbmQgSSANCj4gPiBzZWVtIHRvIGJlIHRhbGtpbmcgYWJv dXQgZnJhZ21lbnRpbmcgYXQgdGhlIENBUFdBUCBsZXZlbCBiZWZvcmUgDQo+ID4gYXR0YWNoaW5n IGEgVURQL0lQIGhlYWRlci4gTWF5YmUgUGF0IGNhbiBlbGFib3JhdGUgbW9yZSBvbiB0aGlzLg0K PiA+IA0KPiA+IFRoYW5rcy4NCj4gPiANCj4gPiAtUHVuZWV0DQo+ID4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBDaGFuZ21pbmcgTGl1IFttYWlsdG86Y2xpdUBq dW5pcGVyLm5ldF0NCj4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAwNiA0OjUwIFBN DQo+ID4gVG86IFB1bmVldCBBZ2Fyd2FsOyBEYXJyZW4gTG9oZXI7IFBhdCBDYWxob3VuIChwYWNh bGhvdSk7IHN1amF5OyANCj4gPiBWaXNod2FzIE1hbnJhbDsgQWJoaWppdCBDaG91ZGh1cnk7IGNh cHdhcEBmcmFzY29uZS5jb20NCj4gPiBTdWJqZWN0OiBSRTogW0NhcHdhcF0gUXVlc3Rpb24gb24g TFdBUFAtMDMgZHJhZnQNCj4gPiANCj4gPiBIaSBQdW5lZXQsDQo+ID4gDQo+ID4gVGhhbmtzIGZv ciB5b3VyIHF1aWNrIHJlcGx5LiBPbmUgdGhpbmcgSSBhbSBjb25mdXNlZCBhYm91dCBpcyB0aGUg DQo+ID4gZGVmaW5pdGlvbiBvZiBhIHR1bm5lbCB2cy4gYSBVRFAgYXBwbGljYXRpb24uDQo+ID4g VHJhZGl0aW9uYWxseSBydW5uaW5nIGFuIGFwcGxpY2F0aW9uIG9uIFVEUC9JUCB0aGVuIG92ZXIg DQo+IHNvbWUga2luZCBvZiANCj4gPiBsYXllciAyIGlzIG5vdCBkZWZpbmVkIGFzIGEgdHVubmVs IHJhdGhlciBqdXN0IGEgbm9ybWFsIFVEUCANCj4gPiBhcHBsaWNhdGlvbi4gT3RoZXJ3aXNlLCBE TlMsIFJUUCwgU0lQIG9yIGFueSBhcHBsaWNhdGlvbiBvbiANCj4gdG9wIG9mIFVEUCANCj4gPiB3 aWxsIGJlY29tZSBhIHR1bm5lbCBpbnN0ZWFkIG9mIGFuIGFwcGxpY2F0aW9uLiBTbyBpcyBDQVBX QVAgYW4gDQo+ID4gYXBwbGljYXRpb24gb2YgVURQIG9yIFVEUC9JUCBpcyB0dW5uZWwgdG8gQ0FQ V0FQPyBBcyBhIA0KPiBhcHBsaWNhdGlvbiwgaXQgDQo+ID4gaXMgdXN1YWxseSBkb2VzIG5vdCBk ZWFsIHdpdGggZnJhZ21lbnRhdGlvbiBpc3N1ZSBiZWNhdXNlIA0KPiBpdCBkZWVtcyBpdCANCj4g PiBhcyBJUCBsYXllciBpc3N1ZS4gT3RoZXJ3aXNlLCBlYWNoIGFwcGxpY2F0aW9uIHdpbGwgaGF2 ZSBpdHMgb3duIA0KPiA+IGJ1aWx0LWluIGZyYWdtZW50YXRpb24gYWxnb3JpdGhtIGFuZCB0aGlz IHdpbGwgZGVmZWF0IHRoZSANCj4gcHVycG9zZSBvZiANCj4gPiBoYXZpbmcgZnJhZ21lbnRhdGlv biBmdW5jdGlvbmFsaXR5IGF0IElQIGxheWVyLiBBcyBhIA0KPiB0dW5uZWwsIGEgTVRVIG1heSAN Cj4gPiBiZSBvcHRpb25hbGx5IGRlZmluZWQgdG8gYXZvaWQgdHVubmVsZWQgcGFja2V0IA0KPiBm cmFnbWVudGF0aW9uLiBCdXQgbXkgDQo+ID4gZXhwZXJpZW5jZSB3aXRoIElQc2VjIHR1bm5lbCB0 ZWxscyBtZSB0aGF0IHNvbWV0aW1lcyB0aGUgDQo+IHByZSBhbmQgcG9zdCANCj4gPiBlbmNhcHN1 bGF0aW9uIGFyZSBib3RoIG5lZWRlZCB0byBiZSBzdXBwb3J0ZWQgYXQgdGhlIHNhbWUgDQo+IHRp bWUgdW5sZXNzIA0KPiA+IHRoZSBNVFUgb2YgZW50aXJlIHBhdGggb2YgYSB0dW5uZWwgaXMga25v d24uICBUaGUgInRyYW5zcG9ydCB0dW5uZWwiDQo+ID4gaXMgYSBkZWZpbml0ZWx5IGludGVyZXN0 aW5nIGRlZmluaXRpb24uIE5vdCBzdXJlIHdoZXJlIHRoaXMgZml0cyBpbi4NCj4gPiANCj4gPiBU aGUgcmVhc29uIEkgdGFsa2VkIGFib3V0IHRoZSB0dW5uZWwgdnMgYXBwbGljYXRpb24gaXMgdGhh dCB5b3VyIA0KPiA+IGFuc3dlciB0byB0aGUgZnJhZ21lbnRhdGlvbiByZXF1aXJlbWVudCBpcyBk aWZmZXJlbnQgZnJvbSANCj4gUGF0J3MuIEhpcyANCj4gPiBhbnN3ZXIgaXMgYWJvdXQgdGhlIG1p ZGRsZSBib3guIEhhdmluZyB3b3JrZWQgb24gdGhlIA0KPiBmaXJld2FsbCBidXNpbmVzcyANCj4g PiBmb3Igc2V2ZXJhbCB5ZWFycywgSSBoYXZlIGhhcmRseSBjb21lIGFjcm9zcyBhbnkgbWlkZGxl IGJveCANCj4gKGZpcmV3YWxsKSANCj4gPiB0byBiZSBjb25maWd1cmVkIHRvIGRyb3AgdGhlIGZy YWdtZW50ZWQgSVAgcGFja2V0cy4gVGhlIA0KPiBjdXN0b21lcnMgb3IgDQo+ID4gZW5kIHVzZXJz IHdpbGwgc2NyZWVuIGF0IHRoZSBJVCBpZiB0aGV5IGNob3NlIHRvIGRvIHRoYXQgDQo+IDotKSBX aG8ga25vd3MgDQo+ID4gaG93IG1hbnkgbGF5ZXJzIG9mIGVuY2FwIGEgcGFja2V0IHdpbGwgYmUg c3ViamVjdGVkIHRvIGFmdGVyIG1hbnkgDQo+ID4gbGF5ZXJzIG9mIHR1bm5lbGluZz8gSnVzdCBm b3IgYW4gZXhhbXBsZSwgSVAgb3ZlciBHUkUgb3ZlciBJUHNlYy4uLi4NCj4gPiBXaGF0ZXZlciBy dW5uaW5nIG9uIHRoZSBpbm5lciBJUCBtYXkgYmUgZW5jYXBzdWxhdGVkIHdpdGggaXRzIG93biAN Cj4gPiBsYXllcnMgb2YgdHVubmVscy4uLi4gQXMgaGF2aW5nIGJlZW4gcG9pbnRlZCBvdXQsIHRo ZSANCj4gZnJhZ21lbnRhdGlvbiBpcyANCj4gPiBub3QgYXZvaWRhYmxlIGluIHRvZGF5J3MgbmV0 d29ya3MsIHNpbXBseSBkcm9wcGluZyBpdCBpcyANCj4gdXN1YWxseSBub3QgDQo+ID4gYW4gb3B0 aW9uIGF0IGFsbCBmb3IgYW55IHNlcmlvdXMgYW5kIHJlYWwgZGVwbG95bWVudC4gVGhpcyANCj4g bWF5IGJlIHRydWUgDQo+ID4gZm9yIHNvbWUgb2xkIHN0YXRlbGVzcyBwYWNrZXQgZmlsdGVyaW5n IGZpcmV3YWxscy4gTm90IHN1cmUgDQo+IGhvdyBtYW55IA0KPiA+IHJlYWxseSBzdGlsbCBiZSBk ZXBsb3llZCB0aGVyZS4NCj4gPiANCj4gPiBDaGFuZ21pbmcNCj4gPiANCj4gPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFB1bmVldCBBZ2Fyd2FsIFttYWlsdG86 cGFnYXJ3YWxAYnJvYWRjb20uY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAy MDA2IDE6NTUgUE0NCj4gPiBUbzogQ2hhbmdtaW5nIExpdTsgRGFycmVuIExvaGVyOyBQYXQgQ2Fs aG91biAocGFjYWxob3UpOyBzdWpheTsgDQo+ID4gVmlzaHdhcyBNYW5yYWw7IEFiaGlqaXQgQ2hv dWRodXJ5OyBjYXB3YXBAZnJhc2NvbmUuY29tDQo+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1 ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+ID4gDQo+ID4gSGkgQ2hhbmdtaW5nLA0KPiA+IA0K PiA+IDEpIEVhY2ggdHJhbnNwb3J0IHR1bm5lbCBoYXMgYW4gTVRVLiBJZiB5b3Uga25vdyB0aGF0 IHlvdSANCj4gYXJlIGdvaW5nIHRvIA0KPiA+IGJlIGV4Y2VlZGluZyB0aGF0IE1UVSB3aGVuIGVu Y2Fwc3VsYXRpbmcgdGhlIHdpcmVsZXNzIA0KPiBmcmFtZSwgdGhlbiBpdCANCj4gPiBpcyBiZXR0 ZXIgdG8gZnJhZ21lbnQgYXQgdGhlIExXQVBQL0NBUFdBUCBsZXZlbCB0byBhdm9pZCBJUCANCj4g ZnJhZ21lbnRzIA0KPiA+ICh3aGVuIFVEUC9JUCBpcyB0aGUgdHJhbnNwb3J0KS4gSXQgaXMgbm90 IGEgcXVlc3Rpb24gb2Ygd2hldGhlciANCj4gPiBtaWRkbGVib3hlcyAoZWc6DQo+ID4gZmlyZXdh bGxzKSBjYW4gaGFuZGxlIElQIGZyYWdtZW50cyBvciBub3QgKEkgYXNzdW1lIHRoYXQgDQo+IG1v c3QgY2FuIGJ1dCANCj4gPiB0aGVyZSBhcmUgb2YgY291cnNlIGxlZ2FjeSBpc3N1ZXMpIC0gYnV0 IHRoZSBtb3N0IGNvbW1vbiANCj4gY29uZmlndXJhdGlvbiANCj4gPiBvZiB0aGVzZSBkZXBsb3ll ZCBtaWRkbGVib3hlcyBpcyB0byBkcm9wIElQIGZyYWdtZW50cy4NCj4gPiANCj4gPiBJZiByb3V0 ZXJzIGluIHRoZSBwYXRoIG9mIHRoZSBXVFAgYW5kIEFDIHdhbnQgdG8gSVAgZnJhZ21lbnQsIHRo ZW4gDQo+ID4gdGhhdCBpcyBkZWZpbml0ZWx5IGFsbG93ZWQgYW5kIHZhbGlkICh3aXRoIHRoZSBj YXZlYXQgdGhhdCBzb21lIA0KPiA+IG1pZGRsZWJveGVzIG1pZ2h0IGRyb3AgdGhlc2UgZnJhZ21l bnRlZCBwa3RzKS4gRXZlbiBpZiBwYXRoIE1UVSANCj4gPiBkaXNjb3ZlcnkgaXMgbm90IGRvbmUs IG9uZSBjb3VsZCBhcmd1ZSB0aGF0IHNldHRpbmcgdGhlIFVEUC9JUCANCj4gPiB0cmFuc3BvcnQg TVRVIHRvICgxNTAwLTIwLTgpPSAxNDcyIHdvdWxkIHdvcmsgdW5kZXIgbW9zdCANCj4gY2lyY3Vt c3RhbmNlcyANCj4gPiB3aXRob3V0IHRoZSBwYWNrZXQgZ2V0dGluZyBmdXJ0aGVyIElQIGZyYWdt ZW50ZWQgYnkgaW50ZXJ2ZW5pbmcgDQo+ID4gcm91dGVycyAoYXNzdW1pbmcgeW91IGRvbid0IGhh dmUgYW55IG90aGVyIFZQTiB0dW5uZWxzIGV0YyBpbiB0aGUgDQo+ID4gcGF0aCkuDQo+ID4gDQo+ ID4gMikgUGFja2V0L2ZyYWdtZW50IHJlb3JkZXJpbmcgaXMgbm90IHJlYWxseSBhbiBpc3N1ZSBm b3IgDQo+IENBUFdBUCAoYW5kIEkgDQo+ID4gYWdyZWUgd2l0aCB5b3UpLg0KPiA+IA0KPiA+IFRo YW5rcy4NCj4gPiANCj4gPiAtUHVuZWV0DQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBDaGFuZ21pbmcgTGl1IFttYWlsdG86Y2xpdUBqdW5pcGVyLm5ldF0N Cj4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAwNiAxMjo1MSBQTQ0KPiA+IFRvOiBE YXJyZW4gTG9oZXI7IFB1bmVldCBBZ2Fyd2FsOyBQYXQgQ2FsaG91biAocGFjYWxob3UpOyBzdWph eTsgDQo+ID4gVmlzaHdhcyBNYW5yYWw7IEFiaGlqaXQgQ2hvdWRodXJ5OyBjYXB3YXBAZnJhc2Nv bmUuY29tDQo+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRy YWZ0DQo+ID4gDQo+ID4gQSBjb3VwbGUgb2YgcXVlc3Rpb25zIGFib3V0IHRoZSBiZW5lZml0cyBv ZiB0aGlzIGFwcGxpY2F0aW9uIA0KPiA+IGZyYWdtZW50YXRpb24ganVzdCBvdXQgb2YgbXkgaWdu b3JhbmNlLg0KPiA+IA0KPiA+IDEpIE1vc3QgY29tbWVyY2lhbCBmaXJld2FsbHMgaGFuZGxlcyBJ UCBmcmFnbWVudHMgd2VsbCB0byBhbiANCj4gPiBhY2NlcHRhYmxlIGRlZ3JlZSAoSSBkb24ndCB0 aGluayBhbnlib2R5IHdpbGwgYnV5IG9uZSB3aGljaCANCj4gZG9lcyBub3QpIA0KPiA+IHNpbmNl IGZyYWdtZW50YXRpb24gaXMgY29tbW9uIG5vcm0gaW4gSVB2NC4gSSBndWVzcyBpdCBuZWVkcyB0 byBiZSANCj4gPiBoYW5kbGVkIG9uZSB3YXkgb3IgYW5vdGhlciBldmVuIGJ5IHRoZSBub24tY29t bWVyY2lhbCBvbmVzLiANCj4gTm90IHN1cmUgDQo+ID4gd2h5IHRoaXMgaXNzdWUgaXMgcGFydGlj dWxhciBkaWZmZXJlbnQgZm9yIENBUFdBUD8gSWYgQUMgDQo+IGFuZCBBUHMgYXJlIA0KPiA+IGNv bm5lY3RlZCB2aWEgcm91dGVycyBpbiBzZXZlcmFsIGhvcHMgKHRoaXMgbWF5IGJlIGEgbGlrZWx5 IA0KPiBjYXNlIHRoYXQgDQo+ID4gYSBmaXJld2FsbCBleGlzdHMgYmV0d2VlbiB0aGUgQUMgYW5k IEFQcyksIElQdjQgZnJhZ21lbnRhdGlvbiBtYXkgDQo+ID4gc3RpbGwgYmUgZW5jb3VudGVyZWQg YmVjYXVzZSBJUHY0IHBhdGggTVRVIGlzIG5vdCB1c2VkIA0KPiB3aWRlbHkgYXMgd2UnZCANCj4g PiBsaWtlIHRvLg0KPiA+IA0KPiA+IDIpIFBhY2tldCBhbmQgZnJhZ21lbnQgcmUtb3JkZXJpbmcg YXJlIHR3byBkaWZmZXJlbnQgaXNzdWVzIA0KPiBhbmQgc2hvdWxkIA0KPiA+IGJlIGhhbmRsZWQg ZGlmZmVyZW50bHkuIFBhY2tldCByZS1vcmRlcmluZyBpcyBhbiBpc3N1ZSB0aGF0IA0KPiA+IGFw cGxpY2F0aW9uIG5lZWRzIHRvIGhhbmRsZSBpZiB0aGUgb3JkZXIgaXMgaW1wb3J0YW50IHRvIGl0 IA0KPiBsaWtlIFJUUCANCj4gPiBzdHJlYW0uIFRoZSBJUCBmcmFnbWVudGF0aW9uIGlzIGFuIElQ IGxheWVyIGlzc3VlIGFuZCANCj4gc2hvdWxkIGJlIGRlYWx0IA0KPiA+IHdpdGggYXQgSVAgbGF5 ZXIuIFRoZXJlIHNob3VsZCBzb21lIHNvbHV0aW9uIHRvZGF5IGF0IElQIGxheWVyLiBOb3QgDQo+ ID4gc3VyZSB0aGlzIGlzIHBhcnRpY3VsYXJseSBpbXBvcnRhbnQgdG8gQ0FQV0FQLg0KPiA+IA0K PiA+IERvIEkgbWlzcyBhbnl0aGluZz8NCj4gPiANCj4gPiBDaGFuZ21pbmcNCj4gPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhcnJlbiBMb2hlciBbbWFpbHRv OmRsb2hlckByb3ZpbmdwbGFuZXQuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1 LCAyMDA2IDExOjA1IEFNDQo+ID4gVG86IFB1bmVldCBBZ2Fyd2FsOyBQYXQgQ2FsaG91biAocGFj YWxob3UpOyBzdWpheTsgVmlzaHdhcyBNYW5yYWw7IA0KPiA+IEFiaGlqaXQgQ2hvdWRodXJ5OyBj YXB3YXBAZnJhc2NvbmUuY29tDQo+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0aW9uIG9u IExXQVBQLTAzIGRyYWZ0DQo+ID4gDQo+ID4gVGhhbmtzIGZvciB0aGUgZnVsbCBleHBsYW5hdGlv biBQdW5lZXQuICBXaXRoIGZyYWdtZW50YXRpb24gZG9uZSBhdCANCj4gPiB0aGUgYXBwbGljYXRp b24gKENBUFdBUC9MV0FQUCkgbGF5ZXIgdGhpcyBtZWFucyBldmVyeSBmcmFtZSANCj4gbXVzdCBo YXZlIA0KPiA+IGEgTFdBUFAgaGVhZGVyLg0KPiA+IA0KPiA+IEkgYWdyZWUgdGhhdCB0aGlzIGlz IGVzcGVjaWFsbHkgaW1wb3J0YW50IHRvIGdldCByaWdodCBhcyANCj4gUGF0IHBvaW50ZWQgDQo+ ID4gb3V0IHRoYXQgdHVubmVsZWQgZGF0YSBwYWNrZXRzIHdpbGwgY29tbW9ubHkgbmVlZCB0byBi ZSBmcmFnbWVudGVkLg0KPiA+IA0KPiA+IEkgYW5vdGhlciByZWFzb24gaXQncyBpbXBvcnRhbnQg bm90IHRvIGhhdmUgYSBzdGFuZGFyZCBJUCBzdGFjayANCj4gPiByZWFzc2VtYmxlIGZyYW1lcyBp cyBkdWUgdG8gcG9zc2libGUgcGFja2V0L2ZyYWdtZW50IA0KPiByZW9yZGVyaW5nLiAgSWYgDQo+ ID4gdGhlIG5ldHdvcmsgd2VyZSB0byByZW9yZGVyIHRoZSBDQVBXQVAvTFdBUFAgVURQIHR1bm5l bCBwYWNrZXRzIGZvciANCj4gPiBhbnkgcmVhc29uLCBpdCB3b3VsZCByZXN1bHQgaW4gY29ycnVw dGluZyB0aGUgZGF0YSBmcmFtZXMgDQo+IGluc2lkZSB0aGUgDQo+ID4gdHVubmVsLiAgV2UgbmVl ZCB0aGUNCj4gPiBGcmFnSUQgZmllbGQgb2YgdGhlIExXQVBQL0NBUFdBUCBoZWFkZXIgdG8gaGVs cCB1cyB0aGVyZS4gICANCj4gPiANCj4gPiAtRGFycmVuDQo+ID4gDQo+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogUHVuZWV0IEFnYXJ3YWwgW21haWx0bzpwYWdh cndhbEBicm9hZGNvbS5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAw NiAxMDo1MiBBTQ0KPiA+ID4gVG86IFBhdCBDYWxob3VuIChwYWNhbGhvdSk7IHN1amF5OyBWaXNo d2FzIE1hbnJhbDsgQWJoaWppdA0KPiA+IENob3VkaHVyeTsNCj4gPiA+IGNhcHdhcEBmcmFzY29u ZS5jb20NCj4gPiA+IFN1YmplY3Q6IFJFOiBbQ2Fwd2FwXSBRdWVzdGlvbiBvbiBMV0FQUC0wMyBk cmFmdA0KPiA+ID4gDQo+ID4gPiBIaSBBbGwsDQo+ID4gPiANCj4gPiA+IEp1c3QgdG8gcmVtb3Zl IGFueSBjb25mdXNpb24sIGJ5IGFwcGxpY2F0aW9uIGxldmVsIA0KPiBmcmFnbWVudGF0aW9uLCBJ IA0KPiA+ID4gbWVhbiB0aGUgTFdBUFAgbGV2ZWwgZnJhZ21lbnRhdGlvbiAoYXMgTFdBUFAgaXMg dGhlDQo+ID4gYXBwbGljYXRpb24gZnJvbQ0KPiA+ID4gdGhlIFVEUC9JUCB0cmFuc3BvcnQgcGVy c3BlY3RpdmUpLiBIb3BlZnVsbHkgdGhpcyBhbnN3ZXJzDQo+ID4geW91ciBxdWVzdGlvbiBTdWpv eS4NCj4gPiA+IA0KPiA+ID4gSGVuY2UgdGhlIHByb3Bvc2FsIGlzIHRvIGZyYWdtZW50IHRoZSB3 aXJlbGVzcyBmcmFtZSBhdCB0aGUgTFdBUFAgDQo+ID4gPiBsZXZlbCAoRiwgTCwgRnJhZy1JZCB3 b3VsZCBiZSB2YWxpZCAtIGV2ZW4gZm9yIFVEUC9JUCB0cmFuc3BvcnQpIA0KPiA+ID4gYmVmb3Jl IGVuY2Fwc3VsYXRpbmcgdGhlIHdpcmVsZXNzIGZyYW1lIGluIHRoZSB0cmFuc3BvcnQgKFVEUC9J UCkgDQo+ID4gPiBoZWFkZXJzIChqdXN0IGxpa2UgaXQgaXMgcHJvcG9zZWQgaW4gdGhlIHNwZWMg Zm9yIEwyIHRyYW5zcG9ydCkuDQo+ID4gPiANCj4gPiA+IFNvIGNvbmNlcHR1YWxseSBMV0FQUC9D QVBXQVAgc2hvdWxkIGJlIGFnbm9zdGljIG9mIHRyYW5zcG9ydCBhbmQgDQo+ID4gPiBhc3N1bWVz IHRoYXQgdGhlIHRyYW5zcG9ydCBkb2VzIG5vdCBzdXBwb3J0IGZyYWdtZW50YXRpb24uDQo+ID4g VGhpcyBnZXRzDQo+ID4gPiByaWQgb2YgdGhlIG1pZGRsZWJveCBwcm9ibGVtIChmb3IgSVAgZnJh Z21lbnRzKSBhbmQgaXMNCj4gPiBhcmNoaXRlY3R1cmFsbHkgY2xlYW4gdG9vLg0KPiA+ID4gDQo+ ID4gPiBUaGFua3MuDQo+ID4gPiANCj4gPiA+IC1QdW5lZXQNCj4gPiA+IA0KPiA+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFBhdCBDYWxob3VuIChwYWNhbGhvdSkg W21haWx0bzpwY2FsaG91bkBjaXNjby5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFy eSAwNSwgMjAwNiA4OjI4IEFNDQo+ID4gPiBUbzogc3VqYXk7IFZpc2h3YXMgTWFucmFsOyBQdW5l ZXQgQWdhcndhbDsgQWJoaWppdCBDaG91ZGh1cnk7IA0KPiA+ID4gY2Fwd2FwQGZyYXNjb25lLmNv bQ0KPiA+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0 DQo+ID4gPiANCj4gPiA+IElmIHdlIGxldCBJUCBoYW5kbGUgZnJhZ21lbnRhdGlvbiwgdGhlbiB3 ZSBkbyBub3QgaGF2ZSANCj4gY29udHJvbCBvdmVyIA0KPiA+ID4gYWRkaW5nIExXQVBQIGhlYWRl cnMgdG8gaXQuIEl0IGlzIHRydWUgdGhhdCBoYXZpbmcgTFdBUFAgcGVyZm9ybSANCj4gPiA+IGZy YWdtZW50YXRpb24sIGFuZCBhZGQgYW4gaW5kZXBlbmRlbnQgaGVhZGVyLCB3b3VsZCBhbGxvdyBm b3IgYW55IA0KPiA+ID4gbWlkZGxlYm94IChpbmNsdWRpbmcNCj4gPiA+IGZpcmV3YWxsKSB0cmF2 ZXJzYWwuIEdpdmVuIHRoZSBsaWtlbGlob29kIG9mIGZyYWdtZW50YXRlZCANCj4gZnJhbWVzIGlz IA0KPiA+ID4gY2VydGFpbiAoZ2l2ZW4gd2UgYXJlIHR1bm5lbGluZyBNVFUgc2l6ZWQgZnJhbWVz KSwgSSBhZ3JlZSB3aXRoIA0KPiA+ID4gUHVuZWV0J3MgcmVjb21tZW5kYXRpb24uDQo+ID4gPiAN Cj4gPiA+IFBhdCBDYWxob3VuDQo+ID4gPiBDVE8sIFdpcmVsZXNzIE5ldHdvcmtpbmcgQnVzaW5l c3MgVW5pdCBDaXNjbyBTeXN0ZW1zDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IHN1amF5IFttYWlsdG86c3Vq YXlnQGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAwNCwgMjAw NiAxMDo0NSBQTQ0KPiA+ID4gPiBUbzogJ1Zpc2h3YXMgTWFucmFsJzsgJ1B1bmVldCBBZ2Fyd2Fs JzsgJ0FiaGlqaXQgQ2hvdWRodXJ5JzsgDQo+ID4gPiA+IGNhcHdhcEBmcmFzY29uZS5jb20NCj4g PiA+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBdIFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEhpIFZpc2h3YXMsDQo+ID4gPiA+DQo+ID4gPiA+IFRo ZSBGLCBMIGFuZCBGcmFnLWlkIGZpZWxkcyBzaG91bGQgYmUgb2YgdXNlIG9ubHkgZm9yIEwyDQo+ ID4gdHJhbnNwb3J0Lg0KPiA+ID4gPg0KPiA+ID4gPiBGcmFnbWVudGF0aW9uIGNhdXNlcyBpc3N1 ZXMgYXQgdGhlIGZpcmV3YWxscywgDQo+IGVzc2VudGlhbGx5IGJlY2F1c2UgDQo+ID4gPiA+IHRo ZSBsd2FwcCBoZWFkZXIgaXMgY2FycmllZCBpbiB0aGUgZmlyc3QgZnJhZ21lbnQgYWxvbmUuDQo+ ID4gPiA+DQo+ID4gPiA+IElmIHRoZSBNVFUgaXMgcHJlLWRldGVybWluZWQgZm9yIElQdjQvNiwg dGhlIGFwcGxpY2F0aW9uDQo+ID4gaGFzIHRvIHRha2UNCj4gPiA+ID4gY2FyZSBvZiByZS1hc3Nl bWJseS4NCj4gPiA+ID4gVGhlcmUgdGhlIEYsIEwgYW5kIEZyYWctIGlkIGZpZWxkcyBjb3VsZCBi ZSBvZiB1c2UuDQo+ID4gPiA+IEFkZGl0aW9uYWxseSBhIGZldyBtb3JlIGZpZWxkcyBtYXkgYmUg cmVxdWlyZWQgIQ0KPiA+ID4gPg0KPiA+ID4gPiBQdW5lZXQsDQo+ID4gPiA+IElNTyB0aGVyZSBp cyBubyBhZHZhbnRhZ2UgYnkgcHVzaGluZyB0aGUgZnJhZ21lbnRhdGlvbi8NCj4gPiBhc3NlbWJs eSB0bw0KPiA+ID4gPiB0aGUgYXBwbGljYXRpb24uDQo+ID4gPiA+DQo+ID4gPiA+IElmIGZpcmV3 YWxsIGlzIHRoZSBpc3N1ZSwgaXMgaXQgcG9zc2libGUgdG8gYWRkIHRoZSBsd2FwcA0KPiA+IGhl YWRlciAgaW4NCj4gPiA+ID4gYWxsIGZyYWdtZW50cy4uPz8NCj4gPiA+ID4NCj4gPiA+ID4gUmVn ZHMsDQo+ID4gPiA+IFN1amF5DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiA+IEZyb206IFZpc2h3YXMgTWFucmFsIFttYWlsdG86VmlzaHdhc0BzaW5ldHQuY29tXQ0KPiA+ ID4gPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAwNiAxMDowOSBBTQ0KPiA+ID4gPiBU bzogVmlzaHdhcyBNYW5yYWw7IFB1bmVldCBBZ2Fyd2FsOyBBYmhpaml0IENob3VkaHVyeTsgDQo+ ID4gPiA+IGNhcHdhcEBmcmFzY29uZS5jb20NCj4gPiA+ID4gU3ViamVjdDogUkU6IFtDYXB3YXBd IFF1ZXN0aW9uIG9uIExXQVBQLTAzIGRyYWZ0DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEhp IFB1bmVldCwNCj4gPiA+ID4NCj4gPiA+ID4gT25lIHNtYWxsIHR5cG8hISBJIGhhZCBzdGF0ZWQg IkkgZ3Vlc3MgZm9yIElQdjYgaXQgaXMNCj4gPiBhbHJlYWR5IHN0YXRlZA0KPiA+ID4gPiB0aGF0 IHdlIGRvIG5vdCBkbyBmcmFnbWVudGF0aW9uIGF0IExXQVBQIGxldmVsIiBJIG1lYW50IGF0DQo+ ID4gPiA+ICJJUHY2IGxldmVsIg0KPiA+ID4gPiBJIG1lYW50Lg0KPiA+ID4gPg0KPiA+ID4gPiBU aGFua3MsDQo+ID4gPiA+IFZpc2h3YXMNCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+ID4gRnJvbTogVmlzaHdhcyBNYW5yYWwgW21haWx0bzpWaXNod2FzQHNpbmV0dC5j b21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDA2IDk6NTQgQU0NCj4g PiA+ID4gVG86IFB1bmVldCBBZ2Fyd2FsOyBBYmhpaml0IENob3VkaHVyeTsgY2Fwd2FwQGZyYXNj b25lLmNvbQ0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW0NhcHdhcF0gUXVlc3Rpb24gb24gTFdBUFAt MDMgZHJhZnQNCj4gPiA+ID4NCj4gPiA+ID4gSGkgUHVuZWV0LA0KPiA+ID4gPg0KPiA+ID4gPiBJ IHRoaW5rIHlvdSBtZWFuIGFsbCBtaWRkbGVib3hlcyBhbmQgbm90IGp1c3QgZmlyZXdhbGxzLg0K PiA+ID4gPg0KPiA+ID4gPiBJIGd1ZXNzIGZvciBJUHY2IGl0IGlzIGFscmVhZHkgc3RhdGVkIHRo YXQgd2UgZG8gbm90IGRvIA0KPiA+ID4gPiBmcmFnbWVudGF0aW9uIGF0IExXQVBQIGxldmVsIGJl Y2F1c2Ugd2UgaGF2ZSB0byBkbyBNVFUNCj4gPiBkaXNjb3ZlcnkgYW5kDQo+ID4gPiA+IGhlbmNl IGZyYWdtZW50cyBjYW4gYmUgZG9uZSBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwNCj4gPiBpdHNl bGYuIEkgdGhpbmsNCj4gPiA+ID4gb25seSBpZiBQYXRoIE1UVSBkaXNjb3ZlcnkgaXMgZG9uZSBm b3IgSVB2NCB0b28sIGNhbiB3ZQ0KPiA+IGF2b2lkIGZyYWdtZW50YXRpb24uDQo+ID4gPiA+DQo+ ID4gPiA+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIEYsIEwgYW5kIEZyYWdtZW50IElkIGZpZWxk cyB3ZXJlDQo+ID4gb25seSB2YWxpZA0KPiA+ID4gPiBmb3INCj4gPiA+ID4gTGF5ZXItMiB0cmFu c3BvcnQgYW5kIG5vdCBmb3IgTGF5ZXItMyB0cmFuc3BvcnQgZWFybGllcj8NCj4gPiA+ID4NCj4g PiA+ID4gVGhhbmtzLA0KPiA+ID4gPiBWaXNod2FzDQo+ID4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gRnJvbTogUHVuZWV0IEFnYXJ3YWwgW21h aWx0bzpwYWdhcndhbEBicm9hZGNvbS5jb21dDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51 YXJ5IDA1LCAyMDA2IDQ6MTYgQU0NCj4gPiA+ID4gVG86IEFiaGlqaXQgQ2hvdWRodXJ5OyBjYXB3 YXBAZnJhc2NvbmUuY29tDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ2Fwd2FwXSBRdWVzdGlvbiBv biBMV0FQUC0wMyBkcmFmdA0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgbWFpbiBpc3N1ZSBpcyBwYXNz aW5nIElQIGZyYWdtZW50cyB2aWEgZmlyZXdhbGxzLiANCj4gPiBNb3N0IGZpcmV3YWxscw0KPiA+ ID4gPiBkcm9wIGZyYWdtZW50ZWQgcGFja2V0cyAoaW4gZmFjdCB0aGUgbm90ZSBpcyBzZWN0aW9u IDMuMy40IGFsc28gDQo+ID4gPiA+IHJlZmVycyB0byB0aGF0KS4gSGVuY2UgdGhlIHF1ZXN0aW9u Lg0KPiA+ID4gPg0KPiA+ID4gPiBIb3BlIHRoaXMgaGVscHMuDQo+ID4gPiA+DQo+ID4gPiA+IFRo YW5rcy4NCj4gPiA+ID4NCj4gPiA+ID4gLVB1bmVldA0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEZyb206IEFiaGlqaXQg Q2hvdWRodXJ5IFttYWlsdG86QWJoaWppdEBzaW5ldHQuY29tXQ0KPiA+ID4gPiBTZW50OiBXZWRu ZXNkYXksIEphbnVhcnkgMDQsIDIwMDYgMTE6NDIgQU0NCj4gPiA+ID4gVG86IFB1bmVldCBBZ2Fy d2FsOyBjYXB3YXBAZnJhc2NvbmUuY29tDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbQ2Fwd2FwXSBR dWVzdGlvbiBvbiBMV0FQUC0wMyBkcmFmdCBGb3IgTDMNCj4gPiB0cmFuc3BvcnQsDQo+ID4gPiA+ IGFzIHRoZSBzcGVjIHNheXMsIG9ubHkgdGhlIGZpcnN0IElQIGZyYWdtZW50IHdvdWxkIGhhdmUN Cj4gPiBhbiBMV0FQUCBoZWFkZXIuDQo+ID4gPiA+IFN0YW5kYXJkIElQIHJlYXNzZW1ibHkgaXMg dXNlZCB0byBwdXQgdGhlIGZyYWdtZW50cw0KPiA+IHRvZ2V0aGVyLsKgIEYsIEwsDQo+ID4gPiA+ IGFuZCBGcmFnSUQgZmllbGRzIGluIHRoZSBMV0FQUCBoZWFkZXIgYXJlIG5vdCBuZWVlZCBmb3IN Cj4gPiByZWFzc2VtYmx5Lg0KPiA+ID4gPg0KPiA+ID4gPiBBbSBJIG1pc3Npbmcgc29tZXRoaW5n ID8NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiDCoMKgIEFiaGlqaXQNCj4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogUHVuZWV0IEFnYXJ3 YWwgW21haWx0bzpwYWdhcndhbEBicm9hZGNvbS5jb21dDQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMDMsIDIwMDYgNzo1NyBQTQ0KPiA+ID4gPiBUbzogY2Fwd2FwQGZyYXNjb25lLmNv bTsgUGF0IENhbGhvdW4gKHBhY2FsaG91KQ0KPiA+ID4gPiBTdWJqZWN0OiBbQ2Fwd2FwXSBRdWVz dGlvbiBvbiBMV0FQUC0wMyBkcmFmdCBRdWVzdGlvbiBvZiBJUHY0IA0KPiA+ID4gPiBmcmFnL3Jl YXNzZW1ibHkgKFNlY3Rpb24gMy4zLjQpOg0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZcKgd2FzIHNv bWUgdGFsa8KgaW4gdGhlIHBhc3QgYWJvdXQgcGVyZm9ybWluZyB0aGUgDQo+ID4gPiA+IGZyYWdt ZW50YXRpb24vcmVhc3NlbWJseSBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwgdG8gYXZvaWQgSVAg DQo+ID4gPiA+IGZyYWdtZW50cy4NCj4gPiA+ID4gSW4gdGhhdCBjYXNlLCB0aGUgRixMIGFuZCBG cmFnSUQgYml0cyB3b3VsZCBuZWVkIHRvIGJlDQo+ID4gdXNlZCBldmVuIGZvcg0KPiA+ID4gPiBM MyB0cmFuc3BvcnQuIERpZCB3ZSBldmVyIHJlYWNoIGEgY29uc2Vuc3VzIG9uIHRoaXMgb25lPw0K PiA+ID4gPg0KPiA+ID4gPiBNeSByZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSB0byBkbyB0aGUgZnJh Zy9yZWFzc2VtYmx5IGF0DQo+ID4gYXBwbGljYXRpb24NCj4gPiA+ID4gbGV2ZWwuDQo+ID4gPiA+ DQo+ID4gPiA+IFRoYW5rcy4NCj4gPiA+ID4NCj4gPiA+ID4gLVB1bmVldA0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gVG8gdW5zdWJzY3JpYmUgb3IgbW9k aWZ5IHlvdXIgc3Vic2NyaXB0aW9uIG9wdGlvbnMsIA0KPiBwbGVhc2UgdmlzaXQ6DQo+ID4gPiA+ IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9jYXB3YXANCj4gPiA+ ID4NCj4gPiA+ID4gQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vcGlwZXJtYWls L2NhcHdhcA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4g VG8gdW5zdWJzY3JpYmUgb3IgbW9kaWZ5IHlvdXIgc3Vic2NyaXB0aW9uIG9wdGlvbnMsIA0KPiBw bGVhc2UgdmlzaXQ6DQo+ID4gPiA+IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vbWFpbG1hbi9s aXN0aW5mby9jYXB3YXANCj4gPiA+ID4NCj4gPiA+ID4gQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy5m cmFzY29uZS5jb20vcGlwZXJtYWlsL2NhcHdhcA0KPiA+ID4gPg0KPiA+ID4gPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+ID4gVG8gdW5zdWJzY3JpYmUgb3IgbW9kaWZ5IHlvdXIgc3Vic2NyaXB0aW9uIG9w dGlvbnMsIA0KPiBwbGVhc2UgdmlzaXQ6DQo+ID4gPiA+IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5j b20vbWFpbG1hbi9saXN0aW5mby9jYXB3YXANCj4gPiA+ID4NCj4gPiA+ID4gQXJjaGl2ZXM6IGh0 dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vcGlwZXJtYWlsL2NhcHdhcA0KPiA+ID4gPg0KPiA+ID4g DQo+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBUbyB1bnN1YnNjcmliZSBvciBtb2RpZnkg eW91ciBzdWJzY3JpcHRpb24gb3B0aW9ucywgcGxlYXNlIHZpc2l0Og0KPiA+ID4gaHR0cDovL2xp c3RzLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2NhcHdhcA0KPiA+ID4gDQo+ID4gPiBB cmNoaXZlczogaHR0cDovL2xpc3RzLmZyYXNjb25lLmNvbS9waXBlcm1haWwvY2Fwd2FwDQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBUbyB1bnN1YnNjcmliZSBvciBtb2RpZnkgeW91ciBzdWJzY3JpcHRpb24g b3B0aW9ucywgcGxlYXNlIHZpc2l0Og0KPiA+IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vbWFp bG1hbi9saXN0aW5mby9jYXB3YXANCj4gPiANCj4gPiBBcmNoaXZlczogaHR0cDovL2xpc3RzLmZy YXNjb25lLmNvbS9waXBlcm1haWwvY2Fwd2FwDQo+ID4gDQo+ID4gDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBUbyB1bnN1YnNjcmliZSBvciBtb2RpZnkgeW91ciBzdWJzY3JpcHRpb24gb3B0aW9ucywgcGxl YXNlIHZpc2l0Og0KPiA+IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5m by9jYXB3YXANCj4gPiANCj4gPiBBcmNoaXZlczogaHR0cDovL2xpc3RzLmZyYXNjb25lLmNvbS9w aXBlcm1haWwvY2Fwd2FwDQo+ID4gDQo+IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVG8gdW5zdWJzY3JpYmUgb3IgbW9kaWZ5IHlvdXIgc3Vic2NyaXB0 aW9uIG9wdGlvbnMsIHBsZWFzZSB2aXNpdDoNCmh0dHA6Ly9saXN0cy5mcmFzY29uZS5jb20vbWFp bG1hbi9saXN0aW5mby9jYXB3YXANCg0KQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy5mcmFzY29uZS5j b20vcGlwZXJtYWlsL2NhcHdhcA0KDQpFbmQgb2YgQ2Fwd2FwIERpZ2VzdCwgVm9sIDMsIElzc3Vl IDEwDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo= --===============1864778594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1864778594==-- From Cgvypdsi@optonline.com Mon Jan 16 08:03:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyU0z-0005mQ-E0; Mon, 16 Jan 2006 08:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10462; Mon, 16 Jan 2006 08:01:52 -0500 (EST) Message-Id: <200601161301.IAA10462@ietf.org> Received: from [219.128.249.91] (helo=lh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EyU8h-000823-ET; Mon, 16 Jan 2006 08:11:29 -0500 From: "Andrea Kramer" To: capwap-archive@ietf.org, rtgwg@ietf.org, simple-bounces@ietf.org Subject: RE: Your Job is at stake. Date: Mon, 16 Jan 2006 15:55:49 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_XUVPLWDP.YBAFXQST" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 This is a multi-part message in MIME format. ------=_NextPart_000_0000_XUVPLWDP.YBAFXQST Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit UNIVERSITY DIPLOMAS OBTAIN A PROSPEROUS FUTURE, MONEY-EARNING POWER, AND THE PRESTIGE THAT COMES WITH THE DEGREE YOU HAVE ALWAYS DREAMED OF. NON-ACCREDITED UNIVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND LIFE EXPERIENCE. If you qualify, no tests, study, books or exams. We have Bachelor's, MBA's, Doctorate & PhD degrees available in your field. CONFIDENTIALITY ASSURED CALL NOW TO GET YOUR DIPLOMA WITHIN 2 WEEKS 1-206-984-0106 CALL 24 HOURS, 7 DAYS A WEEK ------=_NextPart_000_0000_XUVPLWDP.YBAFXQST Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit UNIVERSITY DIPLOMAS

OBTAIN A PROSPEROUS FUTURE, MONEY-EARNING POWER, AND THE PRESTIGE THAT COMES WITH THE DEGREE YOU HAVE ALWAYS DREAMED OF.

NON-ACCREDITED UNIVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND LIFE EXPERIENCE.

If you qualify, no tests, study, books or exams.

We have Bachelor's, MBA's, Doctorate & PhD degrees available in your field.

CONFIDENTIALITY ASSURED

CALL NOW TO GET YOUR DIPLOMA WITHIN 2 WEEKS

1-206-984-0106

CALL 24 HOURS, 7 DAYS A WEEK

------=_NextPart_000_0000_XUVPLWDP.YBAFXQST-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 16 14:19:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyZsi-0004Ol-PS for capwap-archive@megatron.ietf.org; Mon, 16 Jan 2006 14:19:10 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08126 for ; Mon, 16 Jan 2006 14:17:42 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 979E14300CD for ; Mon, 16 Jan 2006 11:19:05 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 564C9430058 for ; Mon, 16 Jan 2006 11:18:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1C6F180C123 for ; Mon, 16 Jan 2006 11:18:38 -0800 (PST) Received: from web51406.mail.yahoo.com (web51406.mail.yahoo.com [206.190.38.185]) by hermes.tigertech.net (Postfix) with SMTP id 03B9C80C0FD for ; Mon, 16 Jan 2006 11:18:35 -0800 (PST) Received: (qmail 77849 invoked by uid 60001); 16 Jan 2006 19:18:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gDFWUI2Xy6qJJYh/oYOCuCq4MfUk19LUfJuyLQ7Ph3R5Ii9hOUnMQZ2I0iTq3q1nqxgi/UGSv0fkmoEg28aPh1FmdgUl+kl/oRTX9jAOG5sUohCq+6y8S+n0oS3LI+8sehzQSVsO4GkrTLFLN4J7/KY+b2bdRWgA2iXzDGxce5o= ; Message-ID: <20060116191835.77847.qmail@web51406.mail.yahoo.com> Received: from [64.1.198.186] by web51406.mail.yahoo.com via HTTP; Mon, 16 Jan 2006 19:18:34 GMT Date: Mon, 16 Jan 2006 19:18:34 +0000 (GMT) From: sitarama penumatsa To: capwap@frascone.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Subject: [Capwap] Question about vlan tagging of 802.11 data frames X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 8bit Hi All, I recently joined this group and i am delighted to see emails from many industry experts in this group. I have a quick questions about vlan tagging of 802.11 data frames. According to any of existing or drafting 802.11 standards, is it allowed to insert vlan tags in a 802.11 data frames? I have recently come across an AP that inserts vlan tags in 802.11 data frames in the frame payload right after the LLC header. Are WLAN NIC cards expected to decode such packets? I thought that the most common way of implementing vlans in 802.11 is through multiple BSSIDs and not through vlan tags. Is this correct? Any responses are greaty appreciated. Thanks a lot, Sitaram ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From info@mail.fwxd.com Mon Jan 16 20:30:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyffs-00080g-6M for capwap-archive@megatron.ietf.org; Mon, 16 Jan 2006 20:30:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02187 for ; Mon, 16 Jan 2006 20:28:50 -0500 (EST) Received: from [222.161.19.102] (helo=mail.fwxd.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eyfnk-0004rl-1f for capwap-archive@ietf.org; Mon, 16 Jan 2006 20:38:34 -0500 Received: (qmail 20551 invoked by uid 510); 17 Jan 2006 09:29:53 +0900 Date: 17 Jan 2006 09:29:53 +0900 Message-ID: <20060117002953.20550.qmail@mail.fwxd.com> From: info@fwxd.com To: capwap-archive@ietf.org Subject: $B"c?7Ce%a!<%k"d$,FO$-$^$7$?(B X-Spam-Score: 4.4 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 $B$"$J$?MM$K3p@E9aMM$+$i?7Ce0l7o$,FO$-$^$7$?!#$I$&$J$5$$$^$9$+!)(B =$B%a%C%;!<%8(B= 21$B:P$N3p@E9a$G$9!";R6!(B2$B?M$$$^$9!#(B $BC6Fa$K$OFb=o$J$N$G!"=K!&F|0J30$NCk4V$J$i$"$($^$9!#(B $BHkL)@\!"3p@E9aMM$HD>@\F|DxEy$*7h$a2<$5$$!#(B $B:#8eG[?.$r4uK>$5$l$J$$J}$O$*; Mon, 16 Jan 2006 23:24:03 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 372C9430058 for ; Mon, 16 Jan 2006 20:25:27 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id AA776430058 for ; Mon, 16 Jan 2006 20:25:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9B3FD80C119 for ; Mon, 16 Jan 2006 20:25:01 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by hermes.tigertech.net (Postfix) with ESMTP id CCE0D80C10C for ; Mon, 16 Jan 2006 20:24:59 -0800 (PST) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k0H4gt5U014357 for ; Mon, 16 Jan 2006 21:42:55 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k0H4folv016381 for ; Mon, 16 Jan 2006 22:41:51 -0600 (CST) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Jan 2006 23:24:52 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810C4E6BEB@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: sitarama penumatsa Subject: RE: [Capwap] Question about vlan tagging of 802.11 data frames Date: Mon, 16 Jan 2006 23:24:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com As far as I know, you are correct. 802.11 does not know about VLANs currently. Donald -----Original Message----- From: sitarama penumatsa [mailto:skcpenumatsa@yahoo.com] Sent: Monday, January 16, 2006 2:19 PM To: capwap@frascone.com Subject: [Capwap] Question about vlan tagging of 802.11 data frames Hi All, I recently joined this group and i am delighted to see emails from many industry experts in this group. I have a quick questions about vlan tagging of 802.11 data frames. According to any of existing or drafting 802.11 standards, is it allowed to insert vlan tags in a 802.11 data frames? I have recently come across an AP that inserts vlan tags in 802.11 data frames in the frame payload right after the LLC header. Are WLAN NIC cards expected to decode such packets? I thought that the most common way of implementing vlans in 802.11 is through multiple BSSIDs and not through vlan tags. Is this correct? Any responses are greaty appreciated. Thanks a lot, Sitaram ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com _________________________________________________________________ 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 From timycuts@hivelocity.net Tue Jan 17 23:18:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez4lu-0004oy-CI for capwap-archive@megatron.ietf.org; Tue, 17 Jan 2006 23:18:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00917 for ; Tue, 17 Jan 2006 23:16:43 -0500 (EST) Received: from [218.74.202.53] (helo=hivelocity.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ez4u6-0008S3-Tp for capwap-archive@ietf.org; Tue, 17 Jan 2006 23:26:40 -0500 Message-ID: <000001c61be6$22311d70$06f8a8c0@avertible> Reply-To: "Tim Cutshall" From: "Tim Cutshall" To: "Fabiana Sloat" Subject: Get P hwaramacy Date: Tue, 17 Jan 2006 23:17:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C61BBC.395D5F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C61BBC.395D5F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Via Val Cia gra ium=20 lis only only only=20 $3 $1 $3 ,3 ,2 ,7 3 1 5 And many other http://www.ateminig.com =20 ------=_NextPart_000_0001_01C61BBC.395D5F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Via
Val
Cia

gra
ium
lis

only
only
only

$3
$1
$3

,3
,2
,7

3
1
5

And many other http://www.ateminig.com

------=_NextPart_000_0001_01C61BBC.395D5F60-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 03:13:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8S5-0005L1-Qv for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 03:13:57 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16033 for ; Wed, 18 Jan 2006 03:12:31 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 698DA43008F for ; Wed, 18 Jan 2006 00:13:52 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 160A1430058 for ; Wed, 18 Jan 2006 00:13:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0527C80C12E for ; Wed, 18 Jan 2006 00:13:22 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 7731880C11E for ; Wed, 18 Jan 2006 00:13:17 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITA00MR93ZGFP@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 18 Jan 2006 00:09:16 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITA00I953ZEOR@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 18 Jan 2006 00:09:16 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Wed, 18 Jan 2006 13:12:29 +0500 Date: Wed, 18 Jan 2006 13:12:29 +0500 From: zhaoyujin 31390 Subject: Re:[Capwap] Question about vlan tagging of 802.11 data frames To: skcpenumatsa@yahoo.com Message-id: <361fa7362599.362599361fa7@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT Hi: I think this is a good concept. Maybe in the future, station can support protocol vlan. But at present, station is a vlan-unware device , so that station does not insert vlan tag in 802.11 frame. And when AP receives 802.11 frame, it can transform to 802.3 frames or directly send to AC. Only AP or AC is a vlan-ware device, it may insert a vlan tag for received frames. Best regards Michael ----- Original Message ----- From: "sitarama penumatsa" To: Sent: Tuesday, January 17, 2006 12:48 AM Subject: [Capwap] Question about vlan tagging of 802.11 data frames > Hi All, > > I recently joined this group and i am delighted to > see emails from many industry experts in this group. I > have a quick questions about vlan tagging of 802.11 > data frames. > > According to any of existing or drafting 802.11 > standards, is it allowed to insert vlan tags in a > 802.11 data frames? I have recently come across an AP > that inserts vlan tags in 802.11 data frames in the > frame payload right after the LLC header. Are WLAN NIC > cards expected to decode such packets? I thought that > the most common way of implementing vlans in 802.11 is > through multiple BSSIDs and not through vlan tags. Is > this correct? > > Any responses are greaty appreciated. > > Thanks a lot, > Sitaram > > > > ___________________________________________________________ > How much free photo storage do you get? Store your holiday > snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > _________________________________________________________________ > 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 07:11:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzC9X-000800-Bq for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 07:11:04 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03644 for ; Wed, 18 Jan 2006 07:09:36 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D38774300E8 for ; Wed, 18 Jan 2006 04:11:00 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id E9E5643005F for ; Wed, 18 Jan 2006 04:10:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id E94CE39802B for ; Wed, 18 Jan 2006 04:10:14 -0800 (PST) Received: from alpha.it.teithe.gr (alpha.it.teithe.gr [195.251.240.232]) by zoidberg.tigertech.net (Postfix) with ESMTP id 52FD0398018 for ; Wed, 18 Jan 2006 04:10:04 -0800 (PST) Received: from [195.251.123.108] ([195.251.123.108]) by alpha.it.teithe.gr (8.13.4/8.13.4) with ESMTP id k0ICAG04006524 for ; Wed, 18 Jan 2006 14:10:17 +0200 (EET) Message-ID: <43CE3074.2000809@it.teithe.gr> Date: Wed, 18 Jan 2006 14:11:32 +0200 From: Periklis Chatzimisios Organization: TEI of Thessaloniki User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: capwap@frascone.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.55 tagged_above=-999 required=7 tests=HTML_20_30, HTML_MESSAGE, HTML_TITLE_EMPTY Subject: [Capwap] CFP: Workshop on multiMedia Applications over Wireless Networks (MediaWiN 2006) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pchatzimisios@ieee.org List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0903008823==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0903008823== Content-Type: multipart/alternative; boundary="------------090406020007050801060709" This is a multi-part message in MIME format. --------------090406020007050801060709 Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit (Apologies if you receive multiple copies of this message) C A L L F O R P A P E R S ============================= 1st Workshop on multiMedia Applications over Wireless Networks (MediaWiN 2006) (http://mediaWiN.it.teithe.gr) April 2, 2006 Athens, Greece In conjunction with 12th European Wireless Conference (EW 2006) (http://www.telecom.ece.ntua.gr/EW2006) Scope The purpose of the MediaWiN 2006 Workshop is to provide a forum for presenting and discussing recent advances in multimedia systems, services and applications over wireless networks. In particular, the Workshop will bring together leading researchers, industry professionals and academics from companies, governmental agencies, and universities around the world to exchange information and new findings as well as to study the special problems and challenges of the multimedia mobile and wireless environments. Topics of Interest The workshop will only accept for review original papers that have not been previously published and are not currently under review by another conference or journal. Topics of particular interest include, but are not limited to the following: Quality and Reliability of Wireless Multimedia * Providing QoS over wireless networks (Scheduling, Call admission Control and Rate control,packetization schemes, prioritization schemes) * Cross-Layer techniques for multimedia communications over wireless networks * Provisioning, monitoring, and management of IP services for WPANs/WLANs * Traffic charging and accounting of integrated systems and services * Multimedia support over multi-hop wireless networks (mesh, ad-hoc, sensor networks) Performance Modeling and Analysis of High-speed Wireless PANs and LANs * Performance evaluation of multimedia services via analysis, simulation and experiments (voice, video, interactive gaming) * Design, implementation and testbed/experimental results for wireless multimedia systems * Energy efficiency in wireless multimedia protocols Emerging Standards and Technologies for Wireless Multimedia Communications * Performance of VoIP, VoD services and related protocols (IPv4, IPv6, H.323, SIP,RTP,RTCP) * Standardization activities in emerging standards: IEEE 802.11, 802.15, 802.16 * New network architectures and management solutions for WLANs (IEEE 802.11v,CAPWAP) * Emerging and visionary multimedia applications for wireless mobile networks * Authentication and security issues in wireless multimedia systems Important dates Submission of research papers: February 5, 2006 Notification of paper acceptance: February 25, 2006 Submission of camera-ready papers: March 6, 2006 Workshop date: April 2, 2006 Submission Guidelines We encourage submission of high-quality technical papers reporting original work and previously unpublished research in the above theoretical and experimental research areas. Submitted papers must be submitted to any of the Chairs as a .PDF file and must not exceed 7 A4 pages, double columned, single-spaced format, using 12-point font size. All submissions must also contain full contact information of the authors along with an abstract no more than 150 words describing the presented research content. Organizing Committee Workshop Co-Chairs Periklis Chatzimisios, TEI of Thessaloniki, Greece Vasileios Vitsas, TEI of Thessaloniki, Greece Program Co-Chairs Ilenia Tinnirello, University of Palermo, Italy Andrea Zanella, University of Padova, Italy Technical Program Committee Dimitrios Amanatiadis (TEI of Thessaloniki, Greece) Leonardo Badia (University of Ferrara, Italy) Frank Ball (Bournemouth University, UK) Paolo Bellavista (University of Bologna, Italy) Giuseppe Bianchi (University of Rome Tor Vergata, Italy) Anthony Boucouvalas (Bournemouth University, UK) David Everitt (University of Sydney, Australia) Fary Z. Ghassemlooy (Northumbria University, UK) Fabrizio Granelli (University of Trento, Italy) Ibrahim Habib (City University of New York, USA) Pi Huang (Bournemouth University, UK) Christos Ilioudis (TEI of Larissa, Greece) Alexandros Kaloxylos (University of Peloponnese, Greece) Michael Logothetis (University of Patras, Greece) Vasileios Lourdas (TEI of Thessaloniki, Greece) Stefan Mangold (Swisscom Innovations, Switzerland) Ioannis Mavridis (University of Macedonia, Greece) Georgios Papadimitriou (Aristotle University, Greece) Kostas Pentikousis (VTT Tech. Research Centre, Finland) Luca Scalia (University of Palermo, Italy) Antonio Servetti (Politecnico di Torino, Italy) Yang Xiao (University of Memphis, USA) Michele Zorzi (University of Padova, Italy) -- Dr. Periklis Chatzimisios Researcher in Wireless Communications & Multimedia Networks Department of Informatics, TEI of Thessaloniki, GR-574 00 Thessaloniki, Greece E-mail: pchatzimisios@ieee.org URL: http://decweb.bournemouth.ac.uk/staff/pchatzimisios Tel: +30 2310-791604 Fax: +30 2310-791290 --------------090406020007050801060709 Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA03644

=A0 (Apologies if you receive multiple copies of this message)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 C A L L=A0=A0 F O R=A0=A0 = P A P E R S
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1st Wo= rkshop on=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0 multiMedia Applications over Wireless Network= s=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 (MediaWi= N 2006)
=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 (http://mediaWiN.it.teithe.gr)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 April= 2, 2006
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ath= ens, Greece

=A0=A0 In conjunction with 12th European Wireless Conference (EW 2006) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (http://www.telecom.ece.nt= ua.gr/EW2006)

Scope
The purpose of the MediaWiN 2006 Workshop is to provide a forum for presenting and
discussing recent advances in multimedia systems, services and applications over wireless
networks. In particular, the Workshop will bring together leading researchers, industry
professionals and academics from companies, governmental agencies, and universities
around the world to exchange information and new findings as well as to study the special
problems and challenges of the multimedia mobile and wireless environments.

Topics of Interest
The workshop will only accept for review original papers that have not been
previously published and are not currently under review by another conference or journal.
Topics of particular interest include, but are not limited to the following:

Quality and Reliability of Wireless Multimedia

Providing QoS over wireless networks (Scheduling, Call admission Control and Rate control,packetization schemes, prioritization schemes)
Cross-Layer techniques for multimedia communications over wireless networks
Provisioning, monitoring, and management of IP services for WPANs/WLANs
Traffic charging and accounting of integrated systems and services
Multimedia support over multi-hop wireless networks (mesh, ad-hoc, sensor networks)

Performance Modeling and Analysis of High-speed Wireless PANs and LANs

Performance evaluation of multimedia services via analysis, simulation and experiments (voice, video, interactive gaming)
Design, implementation and testbed/experimental results for wireless multimedia systems
Energy efficiency in wireless multimedia protocols

Emerging Standards and Technologies for Wireless Multimedia Communications

Performance of VoIP, VoD services and related protocols (IPv4, IPv6, H.323, SIP,RTP,RTCP)
Standardization activities in emerging standards: IEEE 802.11, 802.15, 802.16
New network architectures and management solutions for WLANs (IEEE 802.11v,CAPWAP)
Emerging and visionary multimedia applications for wireless mobile networks
Authentication and security issues in wireless multimedia systems

Important dates
Submission of research papers:=A0=A0=A0=A0 February 5, 2006
Notification of paper acceptance:=A0 February 25, 2006
Submission of camera-ready papers: March 6, 2006
Workshop date:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= April 2, 2006

Submission Guidelines
We encourage submission of high-quality technical papers reporting original work and
previously unpublished research in the above theoretical and experimental research areas.
Submitted papers must be submitted to any of the Chairs as a .PDF file and must not
exceed 7 A4 pages, double columned, single-spaced format, using 12-point font size. All
submissions must also contain full contact information of the authors along with an
abstract no more than 150 words describing the presented research content.

Organizing Committee

Workshop Co-Chairs

Periklis Chatzimisios, TEI of Thessaloniki, Greece
Vasileios Vitsas, TEI of Thessaloniki, Greece

Program Co-Chairs

Ilenia Tinnirello, University of Palermo, Italy
Andrea Zanella, University of Padova, Italy

Technical Program Committee

Dimitrios Amanatiadis (TEI of Thessaloniki, Greece)
Leonardo Badia (University of Ferrara, Italy)
Frank Ball (Bournemouth University, UK)
Paolo Bellavista (University of Bologna, Italy)
Giuseppe Bianchi (University of Rome Tor Vergata, Italy)
Anthony Boucouvalas (Bournemouth University, UK)
David Everitt (University of Sydney, Australia)
Fary Z. Ghassemlooy (Northumbria University, UK)
Fabrizio Granelli (University of Trento, Italy)
Ibrahim Habib (City University of New York, USA)
Pi Huang (Bournemouth University, UK)
Christos Ilioudis (TEI of Larissa, Greece)
Alexandros Kaloxylos (University of Peloponnese, Greece)
Michael Logothetis (University of Patras, Greece)
Vasileios Lourdas (TEI of Thessaloniki, Greece)
Stefan Mangold (Swisscom Innovations, Switzerland)
Ioannis Mavridis (University of Macedonia, Greece)
Georgios Papadimitriou (Aristotle University, Greece)
Kostas Pentikousis (VTT Tech. Research Centre, Finland)
Luca Scalia (University of Palermo, Italy)
Antonio Servetti (Politecnico di Torino, Italy)
Yang Xiao (University of Memphis, USA)
Michele Zorzi (University of Padova, Italy)

--
Dr. Periklis Chatzimisios
Researcher in Wireless Communications & Multimedia Networks
Department of Informatics,
TEI of Thessaloniki, GR-574 00
Thessaloniki, Greece

E-mail: pchatzimisios@ieee.org
URL: http://decw= eb.bournemouth.ac.uk/staff/pchatzimisios
Tel: +30 2310-791604
Fax: +30 2310-791290

--------------090406020007050801060709-- --===============0903008823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0903008823==-- From ajflv@yahoo.com Wed Jan 18 08:45:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzDcj-0001OT-R1 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 08:45:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13844 for ; Wed, 18 Jan 2006 08:43:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzDl4-00026n-1l for capwap-archive@ietf.org; Wed, 18 Jan 2006 08:53:55 -0500 Received: from 82-34-238-44.cable.ubr04.gill.blueyonder.co.uk ([82.34.238.44]) by mx2.foretec.com with smtp (Exim 4.24) id 1EzDcg-0002R6-Qq for capwap-archive@ietf.org; Wed, 18 Jan 2006 08:45:16 -0500 From: " Dowdy" To: capwap-archive@ietf.org Subject: �碽�ܷi*^D^*j Date: Wed, 18 Jan 2006 05:45:16 -0800 X-Info: capwap-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" List-Id: 8 Message-Id: X-Spam-Score: 4.9 (++++) X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id IAA13844 i32CyIKyiMST4IOBgVuDi4FBkF6CyY64l+eSdoK1gtyCtygqXoFCXiopDQoNCoKzgquC2YLH MpBsgsyJnJdsgqqCoILIgr2CzJCrgZWQtoqIgvCJ/JFQgrWCvYKigsaCzJhBl42Cqg0KgqCC wYK9grGCxoLwgqiSbYLngrmCooK9grWC3IK3gUINCg0KgXlJRIFAMTAwNjUzICCCqYKoguiB epKyi7OJwg0KgXlJRIFAMTAwODU1ICCCoIK3gqmBepTUjYaM9opKicINCiANCiAgDQogkKWU 8Yjqk3iQ5pX7gsaCqInvgqKCyYLIgsGCxILdguqCzoLGjnaCwYLEgqiC6ILcgreBQg0KDQqB QIm9kbKLWIK1gq2CqIrogqKQXIK1j+OCsILcgrcoKl6BQl4qKQ0KDQoggrKV1I6Wgs2BQYm6 i0yCzFVSTILMj5eQq4LMieaRnILwg06DioNig06BRYNOg4qDYoNODQoNCoFAaHR0cDovL3d3 dy5hcmlnYXRvdW8ubmV0P3Bpbmt5DQoNCoGagsiCqIFBlUuCuIKoMZBsgsWCqI5mgqKCtYLE gqKCvYK+gquC3IK3gZoNCg0KgUBodHRwOi8vd3d3LmFyaWdhdG91by5uZXQ/cGlua3kNCg0K DQoNCo7zkE2LkZTbhKooKoFMhESBTSmDbQ0KDQpiYWRsdWNrQGFyaWdhdG91by5uZXQNCg== From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 11:30:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGCP-0004Yg-6Y for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 11:30:17 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01391 for ; Wed, 18 Jan 2006 11:28:46 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6BC92430130 for ; Wed, 18 Jan 2006 08:30:09 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id F227B43005F for ; Wed, 18 Jan 2006 08:29:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0E67F398020 for ; Wed, 18 Jan 2006 08:29:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 949C1398032 for ; Wed, 18 Jan 2006 08:29:36 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 08:29:34 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0IGTYQi029288 for ; Wed, 18 Jan 2006 08:29:34 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 08:29:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 08:29:33 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D96BF@xmb-sjc-235.amer.cisco.com> Thread-Topic: Closing on 9.2.3 Thread-Index: AcYGO+nV7KYHWI/9RDuLpKwwr8DnNgWEExWw From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 16:29:34.0315 (UTC) FILETIME=[5DC87BB0:01C61C4C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Subject: [Capwap] Closing on 9.2.3 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable In order to make sure that we can close on the request in section 9.2.3 of the recommendations document: Summary: Either use L2TP or GRE for encapsulation WG Update: Although I raised the issue, no discussion on this topic on the list Pat's Recommendation: While I understand the overall recommendation, I believe that there are=20 misunderstandings of what this really means (see=20 http://lists.frascone.com/pipermail/capwap/msg01864.html ). My recommendation is=20 that do not implement this change. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 11:37:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzGJp-0005SN-EI for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 11:37:57 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01960 for ; Wed, 18 Jan 2006 11:36:29 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C867D430139 for ; Wed, 18 Jan 2006 08:37:55 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id E348043005F for ; Wed, 18 Jan 2006 08:37:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C74E3398031 for ; Wed, 18 Jan 2006 08:37:19 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 8BC9D39802F for ; Wed, 18 Jan 2006 08:37:16 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2006 08:37:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IGbFjv001354; Wed, 18 Jan 2006 08:37:15 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 08:36:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 08:36:56 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D96CE@xmb-sjc-235.amer.cisco.com> Thread-Topic: Issue Tracker now available Thread-Index: AcYcTWWLrxPhPWL7RLSthFJ8vx4AQA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 16:36:57.0901 (UTC) FILETIME=[662E55D0:01C61C4D] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.461 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_40_50, HTML_MESSAGE Subject: [Capwap] Issue Tracker now available X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1382733212==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1382733212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C4D.65F41C60" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C4D.65F41C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 At the request of the chairs, Dave Frascone has graciously setup an issue tracker to help track the pending change requests, and make sure nothing falls through the crack. Over the course of the next few days, I will be adding each request that has come up on the list into the issue tracker, helping me identify what's completed, pending and under discussion. As a result, I will most likely be initiating a bunch of discussions based on the change requests for which we do not have agreement. =20 Given human nature, it is possible that I miss a request or two, so I would appreciate that you keep an eye on the issue tracker to make sure that all of your requests are present. This verification request is only for the first batch as I believe there may be at least a hundred such requests scattered across e-mails and the eval draft. The issue tracker can be found at http://www.capwap.org/roundup. =20 Moving forward, I will volunteer to manually add new change requests for the base draft to tracker in order to limit who has read/write access, but the information will be available for read only for everyone. =20 Thanks, Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C61C4D.65F41C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

At the = request of=20 the chairs, Dave Frascone has graciously setup an issue tracker to help = track=20 the pending change requests, and make sure nothing falls through the = crack. Over=20 the course of the next few days, I will be adding each request that has = come up=20 on the list into the issue tracker, helping me identify what's = completed,=20 pending and under discussion. As a result, I will most likely be = initiating a=20 bunch of discussions based on the change requests for which we do not = have=20 agreement.

Given = human nature,=20 it is possible that I miss a request or two, so I would appreciate that = you keep=20 an eye on the issue tracker to make sure that all of your requests are = present.=20 This verification request is only for the first batch as I believe there = may be=20 at least a hundred such requests scattered across e-mails and the eval = draft.=20 The issue tracker can be found at http://www.capwap.org/roundup.=

Moving = forward, I=20 will volunteer to manually add new change requests for the base = draft to=20 tracker in order to limit who has read/write access, but the information = will be=20 available for read only for everyone.

Thanks,

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

------_=_NextPart_001_01C61C4D.65F41C60-- --===============1382733212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1382733212==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 13:37:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIBT-0007Et-In for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:37:27 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11660 for ; Wed, 18 Jan 2006 13:36:01 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A299943005F for ; Wed, 18 Jan 2006 10:37:25 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 4C4CB43005F for ; Wed, 18 Jan 2006 10:36:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 316BA39803F for ; Wed, 18 Jan 2006 10:36:51 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id B9A66398043 for ; Wed, 18 Jan 2006 10:36:47 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 10:36:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0IIajWp002226 for ; Wed, 18 Jan 2006 10:36:47 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 10:36:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 10:36:45 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D978A@xmb-sjc-235.amer.cisco.com> Thread-Topic: Radio Type change request Thread-Index: AcYcXiJambBdEwU3SaOnR2+bTeOjgg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 18:36:46.0594 (UTC) FILETIME=[22F9D620:01C61C5E] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.47 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE Subject: [Capwap] Radio Type change request X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0994974245==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0994974245== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C5E.22DB311B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C5E.22DB311B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Change request (c) in http://lists.frascone.com/pipermail/capwap/msg02056.html states that the radio types in the specification are incorrect. The comment reads: =20 Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n -- no superG -- no superA =20 I wonder whether it is really worth including an 802.11b only enumeration, given that all 2.4Ghz devices I am aware of these days that I am aware of support both b and g. Further, including SuperG and SuperA is ill advised since it is not a standard. I will add 802.11n. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C61C5E.22DB311B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Change = request (c)=20 in http://= lists.frascone.com/pipermail/capwap/msg02056.html states=20 that the radio types in the specification are incorrect. The comment=20 reads:

Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n --=20 no
superG -- no superA

I = wonder whether it=20 is really worth including an 802.11b only enumeration, given that all = 2.4Ghz=20 devices I am aware of these days that I am aware of support both b and = g.=20 Further, including SuperG and SuperA is ill advised since it is not a = standard.=20 I will add 802.11n.

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

------_=_NextPart_001_01C61C5E.22DB311B-- --===============0994974245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0994974245==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 13:44:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIIG-0000i1-D3 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:44:28 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12073 for ; Wed, 18 Jan 2006 13:43:02 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A87B3430108 for ; Wed, 18 Jan 2006 10:44:26 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id D61E343005F for ; Wed, 18 Jan 2006 10:43:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C465A80C13B for ; Wed, 18 Jan 2006 10:43:59 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by hermes.tigertech.net (Postfix) with ESMTP id 9240D80C12E for ; Wed, 18 Jan 2006 10:43:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id D086F3601AF; Wed, 18 Jan 2006 18:30:30 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Wed, 18 Jan 2006 18:30:30 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id BCF9C360193; Wed, 18 Jan 2006 18:30:30 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11695-04; Wed, 18 Jan 2006 18:30:21 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 1A3BD360041; Wed, 18 Jan 2006 18:30:20 +0000 (GMT) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2013D978A@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2013D978A@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Rakity Subject: Re: [Capwap] Radio Type change request Date: Wed, 18 Jan 2006 10:43:38 -0800 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit Pat, Some devices I have come across have a configuration option to support ONLY G and not B/G. So maybe there room to enumerate things. Philip On Jan 18, 2006, at 10:36 AM, Pat Calhoun (pacalhou) wrote: > Change request (c) in http://lists.frascone.com/pipermail/capwap/ > msg02056.html states that the radio types in the specification are > incorrect. The comment reads: > > Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n -- no > superG -- no superA > > I wonder whether it is really worth including an 802.11b only > enumeration, given that all 2.4Ghz devices I am aware of these days > that I am aware of support both b and g. Further, including SuperG > and SuperA is ill advised since it is not a standard. I will add > 802.11n. > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 13:47:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzILX-0001p7-5B for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:47:51 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12328 for ; Wed, 18 Jan 2006 13:46:23 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 42EF74300E1 for ; Wed, 18 Jan 2006 10:47:48 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id D2744430063 for ; Wed, 18 Jan 2006 10:47:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C2F9C80C0E8 for ; Wed, 18 Jan 2006 10:47:25 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id 78C1680C141 for ; Wed, 18 Jan 2006 10:47:23 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 10:47:23 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0IIlEWZ010159; Wed, 18 Jan 2006 10:47:22 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 10:47:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Radio Type change request Date: Wed, 18 Jan 2006 10:47:03 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2013D97A4@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Radio Type change request Thread-Index: AcYcXyg4nQNYjfYbTQ6hPXcrer3ZoQAAGWZQ From: "Pat Calhoun (pacalhou)" To: "Philip Rakity" X-OriginalArrivalTime: 18 Jan 2006 18:47:04.0903 (UTC) FILETIME=[93844D70:01C61C5F] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Ok, I will make the change for completeness. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip Rakity [mailto:philip.rakity@u4eatech.com]=20 > Sent: Wednesday, January 18, 2006 10:44 AM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: Re: [Capwap] Radio Type change request >=20 >=20 > Pat, >=20 > Some devices I have come across have a configuration option=20 > to support ONLY G and not B/G. So maybe there room to=20 > enumerate things. >=20 > Philip >=20 > On Jan 18, 2006, at 10:36 AM, Pat Calhoun (pacalhou) wrote: >=20 > > Change request (c) in http://lists.frascone.com/pipermail/capwap/ > > msg02056.html states that the radio types in the specification are=20 > > incorrect. The comment reads: > > > > Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n=20 > -- no superG=20 > > -- no superA > > > > I wonder whether it is really worth including an 802.11b only=20 > > enumeration, given that all 2.4Ghz devices I am aware of these days=20 > > that I am aware of support both b and g. Further, including=20 > SuperG and=20 > > SuperA is ill advised since it is not a standard. I will=20 > add 802.11n. > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap >=20 > Philip Rakity > prakity@u4eatech.com >=20 >=20 > This message is hereby marked U4EA CONFIDENTIAL, is intended=20 > only for the use of the individual or individuals to which it=20 > is addressed and shall notbe disclose or made available to=20 > any other party except with the prior written consent of the=20 > sender. If the reader of this message is not the intended=20 > recipient, you are hereby notified that any dissemination,=20 > distribution or copying of this message is strictly=20 > prohibited. If you have received this communication in error,=20 > please notify us immediately by replying to the sender of this E-Mail. >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 14:11:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIik-0000hq-4M for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 14:11:50 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14266 for ; Wed, 18 Jan 2006 14:10:23 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C5B804300FD for ; Wed, 18 Jan 2006 11:11:48 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id A475B430063 for ; Wed, 18 Jan 2006 11:11:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3A5F398026 for ; Wed, 18 Jan 2006 11:11:20 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id C476739803F for ; Wed, 18 Jan 2006 11:11:08 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0IJ4ePO011296 for ; Wed, 18 Jan 2006 14:04:40 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 18 Jan 2006 14:11:04 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 18 Jan 2006 14:11:04 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Jan 2006 14:11:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Closing on 9.2.3 Date: Wed, 18 Jan 2006 14:11:04 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B7B9@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] Closing on 9.2.3 Thread-Index: AcYGO+nV7KYHWI/9RDuLpKwwr8DnNgWEExWwAAWg9wA= From: "Nelson, David" To: X-OriginalArrivalTime: 18 Jan 2006 19:11:04.0390 (UTC) FILETIME=[ED849660:01C61C62] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:79.5348 M:99.8514 P:95.9108 R:95.9108 S: 5.3138 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Pat Calhoun writes... > Pat's Recommendation: While I understand the overall recommendation, I > believe that there are misunderstandings of what this really means (see > http://lists.frascone.com/pipermail/capwap/msg01864.html. > My recommendation is that do not implement this change. I agree. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From eowynoquiri@networkone.com Wed Jan 18 14:14:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIl6-0001Ad-1A for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 14:14:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14447 for ; Wed, 18 Jan 2006 14:12:49 -0500 (EST) Received: from [200.89.113.211] (helo=networkone.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EzItO-0005y7-MY for capwap-archive@ietf.org; Wed, 18 Jan 2006 14:22:56 -0500 Message-ID: <000001c61c63$4ac82ad0$b74da8c0@organgrinder> Reply-To: "Eowyn Quirion" From: "Eowyn Quirion" To: "Fidelma Harrell" Subject: Go od Phar amjacy Date: Wed, 18 Jan 2006 14:13:40 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C61C39.61F222D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.7 (++++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C61C39.61F222D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 View these and many other at http://www.ismadepo.com =20 =20 Via So Xa Va Am Cia Me Le gr m na liu bi lis rid vit a a x m en =20 ia ra $ =20 =20 $ =20 $ =20 =20 3 =20 =20 1 =20 3 =20 =20 33 =20 =20 21 =20 75 =20 =20 =20 ------=_NextPart_000_0001_01C61C39.61F222D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

View these and many other at http://www.ismadepo.com

Via

Cia

Me=

liu

lis

rid

vit

&nbs= p;

.33

.21

.75

------=_NextPart_000_0001_01C61C39.61F222D0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 14:42:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJCh-00015G-Qb for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 14:42:47 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17172 for ; Wed, 18 Jan 2006 14:41:21 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1D40D4300BC for ; Wed, 18 Jan 2006 11:42:46 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 67A57430063 for ; Wed, 18 Jan 2006 11:42:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4DB2280C0E8 for ; Wed, 18 Jan 2006 11:42:13 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id D4F0980C103 for ; Wed, 18 Jan 2006 11:42:11 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2006 11:42:11 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0IJgBWF026503 for ; Wed, 18 Jan 2006 11:42:11 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 11:42:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 11:42:10 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014373C0@xmb-sjc-235.amer.cisco.com> Thread-Topic: Using MIB variable names Thread-Index: AcYcZ0XJyQEtvYRzT32fPyDr7opvNg== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 19:42:11.0475 (UTC) FILETIME=[46632630:01C61C67] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.47 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_50_60, HTML_MESSAGE Subject: [Capwap] Using MIB variable names X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0734825593==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0734825593== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C67.4636382F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C67.4636382F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Change request (j) in http://lists.frascone.com/pipermail/capwap/msg02056.html includes the following request: "why not use the text in the 802.11 MIB definitions and the name of the MIB entry where these are used to configure the WTP". =20 The text in the LWAPP spec was pulled from the MIB, but we are not using the variable names (note that the names are nearly identical, but do not have MIB variable name formats). I believe that adding a reference to the MIB object is a valuable addition. =20 Is this ok? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C61C67.4636382F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Change request (j) in http://lists.frascone.com/pipermail/capwap/msg02056.html<= /A> includes the following request: "why not use the = text in the=20 802.11 MIB definitions and the = name of the=20 MIB entry where these are used to configure the WTP".

The text in the LWAPP spec was pulled = from the MIB,=20 but we are not using the variable names (note that the names are nearly=20 identical, but do not have MIB = variable=20 name formats). I believe that adding a reference to the MIB object is a = valuable=20 addition.

Is = this=20 ok?

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

------_=_NextPart_001_01C61C67.4636382F-- --===============0734825593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0734825593==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 14:49:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJIl-0003VF-5U for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 14:49:03 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17639 for ; Wed, 18 Jan 2006 14:47:36 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 489FF430106 for ; Wed, 18 Jan 2006 11:46:47 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 27FF543006D for ; Wed, 18 Jan 2006 11:46:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1426E80C131 for ; Wed, 18 Jan 2006 11:46:18 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id CC3FE80C12A for ; Wed, 18 Jan 2006 11:46:15 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2006 11:46:15 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IJkFjt014256 for ; Wed, 18 Jan 2006 11:46:15 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 11:46:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 11:46:14 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014373CB@xmb-sjc-235.amer.cisco.com> Thread-Topic: WLAN Field Thread-Index: AcYcZ9dH1kHxFmMvQWa8oh+NcQmbmA== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 19:46:15.0451 (UTC) FILETIME=[D7CEEEB0:01C61C67] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Subject: [Capwap] WLAN Field X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Just following up on Philip's previous question: >> k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT =20 >> understand >> how setting a bit relates to the WLAN ID's used later in the >> document -- >> can you give an example or two ? Only 16 WLAN ID's allowed ??/ > > Well the text specifically states that if the AC wants to send a > broadcast or multicast packet, it sets the BSSIDs that it wishes to > transmit the packets on. This eliminates the need for the AC to =20 > have to > replicate the packet n times. In terms of the number of WLAN IDs > allowed, 16 is actually a large number because each BSSID has to > transmit beacons every beacon interval period (typically 100ms), so > that's 16 packets per 100ms of pure overhead. > > > Can you give an example showing how this is used for say 3 different =20 > WLAN ID's. I am confused. Can we put the example as an appendix ?=20 Let's assume that I have three WLANs (1, 2 and 3). If the AC gets a broadcast Packet that needs to be forwarded only to the BSSID associated with WLAN 1, it Would set the bitfield to 0x01. However, if VLANs associated with WLANs 1 and 2 required the AC to forward a broadcast packet to both WLANs, the WLAN field Would be set to 0x03. Makes sense? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 15:18:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJkm-0003Ev-L3 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:18:00 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20044 for ; Wed, 18 Jan 2006 15:16:33 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E23004300FB for ; Wed, 18 Jan 2006 12:17:58 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 7BDBD430092 for ; Wed, 18 Jan 2006 12:17:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F0B6A398023 for ; Wed, 18 Jan 2006 12:17:30 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6074439802B for ; Wed, 18 Jan 2006 12:17:25 -0800 (PST) Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 18 Jan 2006 12:17:14 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 327D867421; Wed, 18 Jan 2006 12:17:14 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id EFFD667420; Wed, 18 Jan 2006 12:17:13 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSP37361; Wed, 18 Jan 2006 12:17:12 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id B364B20501; Wed, 18 Jan 2006 12:17:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Closing on 9.2.3 Date: Wed, 18 Jan 2006 12:17:11 -0800 Message-ID: <8954613CA6BB3242A1531D916A527A4152EC90@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [Capwap] Closing on 9.2.3 Thread-Index: AcYGO+nV7KYHWI/9RDuLpKwwr8DnNgWEExWwAAf7CvA= From: "Puneet Agarwal" To: "Pat Calhoun (pacalhou)" , capwap@frascone.com X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011807; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34334345413131392E303030322D412D; ENG=IBF; TS=20060118201716; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011807_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD07DC041W2186166-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I agree. -Puneet=20 -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Wednesday, January 18, 2006 8:30 AM To: capwap@frascone.com Subject: [Capwap] Closing on 9.2.3 In order to make sure that we can close on the request in section 9.2.3 of the recommendations document: Summary: Either use L2TP or GRE for encapsulation WG Update: Although I raised the issue, no discussion on this topic on the list Pat's Recommendation: While I understand the overall recommendation, I believe that there are misunderstandings of what this really means (see http://lists.frascone.com/pipermail/capwap/msg01864.html ). My recommendation is that do not implement this change. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 15:24:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJqp-0004rp-45 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:24:15 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20516 for ; Wed, 18 Jan 2006 15:22:47 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id F28BA4300CE for ; Wed, 18 Jan 2006 12:24:12 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 30C4143009F for ; Wed, 18 Jan 2006 12:23:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5D40D39802F for ; Wed, 18 Jan 2006 12:23:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id CD9A4398022 for ; Wed, 18 Jan 2006 12:23:38 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2006 12:23:37 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IKNak5010639; Wed, 18 Jan 2006 12:23:36 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 12:23:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP Date: Wed, 18 Jan 2006 12:23:32 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014373FD@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Comments on Draft 3 -- LWAPP Thread-Index: AcYARfBU7D9UjOAURVO6CDd3eGYH8gcJfXng From: "Pat Calhoun (pacalhou)" To: "Philip Rakity" , X-OriginalArrivalTime: 18 Jan 2006 20:23:34.0522 (UTC) FILETIME=[0E660DA0:01C61C6D] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable > On Dec 12, 2005, at 11:42 PM, sujay wrote: > > b) page 32 -- section 5.1 "Discovery requests MUST be sent=20 > by an ... > > AND when no echo responses are received and the WTP" I think it > > should say that "Discovery requests MUST be sent by a WTP when the > > WTP returns to the idle state. This can occur for example when no > > echo responses are received for NeibhborDeadInteval. " > > > > Suj> IMHO in the Idle State No Discovery requests are sent, once > > entering > > the Idle state, the SM moves to Discovery state before sending Disc=20 > > Req messages. > > > > The section talks about when as you rightly pointed out no echo=20 > > responses are Received for NeighborDeadInterval. > > > Thanks -- So does idle state wait the random time interval=20 > and then move to discovery or is done in the discovery phase ? > If the initial delay is done in the idle phase then the=20 > requirement is after no echo packets -- transition to idle phase. Does the following text solve the issue, or do you need additional clarification/changes in the spec? Discovery requests MUST be sent by a WTP when no echo responses are=20 received for NeighborDeadInterval and the WTP returns to the Idle=20 state. Discovery requests are sent after NeighborDeadInterval, they=20 MUST be sent after waiting for a random delay less than=20 MaxDiscoveryInterval. A WTP MAY send up to a maximum of MaxDiscoveries=20 discoveries, waiting for a random delay less than MaxDiscoveryInterval=20 between each successive discovery. >=20 > > d) Page 37 -- Section 5.2.4 WTP manager control IPV4 address -- do=20 > > not understand the text -- is there only one ip address ? =20 > if so --=20 > > then the ip address is used to return the interface of the AC. If=20 > > only one address -- how is load balancing done ? > > > > Suj> If the AC has more than one Interfaces open for the WTP to > > join, it > > specifies each of these ip address's with Individual TLV's, > > - right, for single ip interface load balancing cannot be=20 > done ,(given=20 > > only one AC) the AC should return its own interface Ip address. >=20 > So the problem is the ip address CAN repeat but this is not=20 > reflected in the definition of the length? An AC would include one such message element per interface it has. So the length is correct. > > > > > > h) Page 65 -- Blacklist Entry's -- This whole area is not good =20 > > from my > > point of view. When I configure a firewall I say what is allowed > > (explicitly) and forbid everything else -- there is no way I can =20 > > give a > > list of trusted stations and forbid everything else. This=20 > makes live > > very difficult. There is room for a blacklist -- but an allowed =20 > > list is > > also needed. > > > > > > Suj> In my opinion blacklisting is to prevent any .11 mgt=20 > frames from > > passing upto the AC for the current WTP-AC session. > > - to blacklist one MAC address and allow others is more exact and > > specific rather than knowing ALL those which are > > Allowed, either way the one which is allowed will is kept=20 > the Radius, > > you could put your 'allowed' list there ! >=20 > I think there is a use for BOTH cases. in a secure environment I do =20 > not want control frames from rogue AP's. Looks like we are still not in complete agreement on this one. Typical 802.11 Devices include an approved list (known as MAC Filter). It is assumed that this function is provided w/o CAPWAP involvement, while a blacklist is provided by CAPWAP. If I understsand correct, you would like a replicated set of messages to serve as the permit list? Do others agree? > > > > > > i) Page 70 -- Image Data -- do not understand how this can work -- =20 > > only > > 2 fragments allowed -- no count of what is being sent etc=20 > -- no way to > > detect packet loss --- why not use data xfer mechanism of=20 > tftp ? -- > > the blocks are numbered =3D=3D etc BUT define a md5 hash of the = whole =20 > > image > > and give its length in the initial request. > > > > Suj> LWAPP has the in-band Image transfer mechanism, some=20 > protocols =20 > > use > > what you have specified. > > >=20 > I do not understand how this can work as defined in the text. I =20 > understand I could overlay it but it needs a definition. Could you help identify what needs a definition? > > k) Page 72 -- Section 8.5.2 Duplicate IP address =3D=3D what is a > > host ? Is this a mobile station ? What about the case of a mobile > > station having the SAME mac address as a already connected mobile > > station to the WTP. =3D=3D only useful if NOT split mac > > > > Suj> host here is the WTP itself, MAC address are unique so there =20 > > should > > not be a case of a mobile station having > > the same MAC address as another one. > > > Can we change text to say WTP -- thanks > Just like there should not be a duplicate IP address in the network =20 > there should not be a duplicate MAC address, but MAC addresses are =20 > also soft > the linux command > ifconfig hwether allows one to change the mac address I'm confused here because the text reads fine to me. I did change host to IP device, but I don't think this is addressing your original comment. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 15:35:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK1Y-0007Xh-9j for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:35:20 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21340 for ; Wed, 18 Jan 2006 15:33:53 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C2024300D8 for ; Wed, 18 Jan 2006 12:35:18 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 3380D4300A4 for ; Wed, 18 Jan 2006 12:34:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1F7BC39801A for ; Wed, 18 Jan 2006 12:34:49 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id EBB80398023 for ; Wed, 18 Jan 2006 12:34:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 54F463601AF for ; Wed, 18 Jan 2006 20:21:17 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Wed, 18 Jan 2006 20:21:17 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 3B554360054 for ; Wed, 18 Jan 2006 20:21:17 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15302-18 for ; Wed, 18 Jan 2006 20:21:13 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 756D3360193 for ; Wed, 18 Jan 2006 20:21:13 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v746.2) References: <4F61FB92-8021-4EB8-B47D-3B190B3154AC@u4eatech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Rakity Subject: Fwd: [Capwap] WLAN Field Date: Wed, 18 Jan 2006 12:34:36 -0800 To: capwap@frascone.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit > > > Hi Pat, > > Makes sense --- just define which bit is bit 0 and bit 1 etc. Got it > > Philip > > On Jan 18, 2006, at 11:46 AM, Pat Calhoun (pacalhou) wrote: > >> Just following up on Philip's previous question: >> >>>> k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT >>>> understand >>>> how setting a bit relates to the WLAN ID's used later in the >>>> document -- >>>> can you give an example or two ? Only 16 WLAN ID's allowed ??/ >>> >>> Well the text specifically states that if the AC wants to send a >>> broadcast or multicast packet, it sets the BSSIDs that it wishes to >>> transmit the packets on. This eliminates the need for the AC to >>> have to >>> replicate the packet n times. In terms of the number of WLAN IDs >>> allowed, 16 is actually a large number because each BSSID has to >>> transmit beacons every beacon interval period (typically 100ms), so >>> that's 16 packets per 100ms of pure overhead. >>> >>> >>> Can you give an example showing how this is used for say 3 different >>> WLAN ID's. I am confused. Can we put the example as an appendix ? >> >> Let's assume that I have three WLANs (1, 2 and 3). If the AC gets a >> broadcast >> Packet that needs to be forwarded only to the BSSID associated >> with WLAN >> 1, it >> Would set the bitfield to 0x01. However, if VLANs associated with >> WLANs >> 1 and >> 2 required the AC to forward a broadcast packet to both WLANs, the >> WLAN >> field >> Would be set to 0x03. >> >> Makes sense? >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap >> > > Philip Rakity > prakity@u4eatech.com > > > This message is hereby marked U4EA CONFIDENTIAL, is intended only > for the use of the individual or individuals to which it is > addressed and shall notbe disclose or made available to any other > party except with the prior written consent of the sender. If the > reader of this message is not the intended recipient, you are > hereby notified that any dissemination, distribution or copying of > this message is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to > the sender of this E-Mail. > > > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 15:39:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK5N-0008Qw-5T for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:39:17 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21606 for ; Wed, 18 Jan 2006 15:37:50 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 848FB430101 for ; Wed, 18 Jan 2006 12:39:15 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 67B444300A7 for ; Wed, 18 Jan 2006 12:38:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5AAE739801A for ; Wed, 18 Jan 2006 12:38:41 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by zoidberg.tigertech.net (Postfix) with ESMTP id 85BCA398023 for ; Wed, 18 Jan 2006 12:38:36 -0800 (PST) Received: by zproxy.gmail.com with SMTP id l1so36112nzf for ; Wed, 18 Jan 2006 12:38:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GeA/EhuTMctXXV4PIk6cAo15MFK7SEzzi3In3kFMHWdWlBxEUKv2cdnJ9gTMP3Ob6eGcVu5X2gZ8/vyg1MW3lkIUCvf5nzTnAW/tPfrefPJP5XuCgrbPtlykfe2nf87prK0LRu8rfRbBvYHTaI2fLCtleDddxcGpCGKp4piBoGE= Received: by 10.36.77.13 with SMTP id z13mr2041370nza; Wed, 18 Jan 2006 12:38:35 -0800 (PST) Received: by 10.36.10.19 with HTTP; Wed, 18 Jan 2006 12:38:35 -0800 (PST) Message-ID: <5e6e0f30601181238x13030716jd46b28e9ade1200a@mail.gmail.com> Date: Wed, 18 Jan 2006 13:38:35 -0700 From: Darren To: "Pat Calhoun (pacalhou)" Subject: Re: [Capwap] Closing on 9.2.3 In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2013D96BF@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4FF84B0BC277FF45AA27FE969DD956A2013D96BF@xmb-sjc-235.amer.cisco.com> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I agree that this issue should not be implemented and can be closed. While the intent to reuse code and go with an existing standard of some kind for data encapsulation is the right idea, Pat and Puneet convinced me that that using GRE or L2TP will not actually help LWAPP. Upon closer examination, both would need some modification or addition to carry the RSSI/SNR for data frames. Regarding firewall/NAT traversal, since L2TP and LWAPP are based on regular UDP they are effectively equivalent. GRE is not often NAT'd automatically by firewalls because it is not based on UDP or TCP. In addition, supporting more than one GRE tunnel is not possible without an application layer (GRE layer) gateway in the firewall. This is a significant disadvantage compared to using the existing LWAPP header for tunneling. -Darren Loher On 1/18/06, Pat Calhoun (pacalhou) wrote: > In order to make sure that we can close on the request in section 9.2.3 > of the recommendations document: > > Summary: Either use L2TP or GRE for encapsulation > > WG Update: Although I raised the issue, no discussion on this topic on > the list > > Pat's Recommendation: While I understand the overall recommendation, I > believe that there are > misunderstandings of what this really means (see > http://lists.frascone.com/pipermail/capwap/msg01864.html > ). My > recommendation is > that do not implement this change. > > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 15:42:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzK85-00016L-Hz for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:42:06 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21846 for ; Wed, 18 Jan 2006 15:40:38 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 49D014300E2 for ; Wed, 18 Jan 2006 12:42:03 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id E8E894300AB for ; Wed, 18 Jan 2006 12:41:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D902080C119 for ; Wed, 18 Jan 2006 12:41:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id E775180C0FB for ; Wed, 18 Jan 2006 12:41:23 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 12:41:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0IKfMQi014463; Wed, 18 Jan 2006 12:41:23 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 12:41:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP Date: Wed, 18 Jan 2006 12:41:21 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20143741C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Comments on Draft 3 -- LWAPP Thread-Index: AcX/Y7B3bgU7IpOSRvCH5LO06L+vKAB4j+KwBspV/RA= From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , "Philip Rakity" , X-OriginalArrivalTime: 18 Jan 2006 20:41:22.0796 (UTC) FILETIME=[8B23BAC0:01C61C6F] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Saravanan, In order to ensure that I am tracking all of the issues properly, could you please be more specific in your change recommendations below? I do have the field size one already, as this was in the eval draft. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, December 14, 2005 11:08 PM > To: Philip Rakity; capwap@frascone.com > Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP >=20 > Hi Philip, >=20 > You have clearly reviewed the draft in detail! I think the=20 > points you raise are very important for the protocol.=20 >=20 > Perhaps some recommendations can be made based on the points=20 > raised. I think it would be helpful for the WG to see how the=20 > recommendations can fit in to the current LWAPP specifications.=20 >=20 > On a related note, I think the first WG version of the=20 > protocol can also include those issues which were discussed=20 > during the last meeting. There seemed to be some agreement in=20 > the issues such as information elements field size, firmware=20 > operations and local-MAC mode operations.=20 >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 >=20 > -----Original Message----- > From: Philip Rakity [mailto:philip.rakity@u4eatech.com] > Sent: Tuesday, December 13, 2005 5:35 AM > To: capwap@frascone.com > Subject: [Capwap] Comments on Draft 3 -- LWAPP >=20 >=20 > I am a newbie to the group and this the first time that I have read > the internet draft. I have a number of comments on the draft that > are below. Most a minor editorial things but some are areas I do not > understand >=20 > a) Use of "integer" is not consistent in the document --- most of the > time it means unsigned, sometimes signed (but marked as signed), but > sometimes the phrase "unsigned integer" is used and this then makes > me wonder if the fields marked integer are signed or not. >=20 > b) page 32 -- section 5.1 "Discovery requests MUST be sent by an ... > AND when no echo responses are received and the WTP" I think it > should say that "Discovery requests MUST be sent by a WTP when the > WTP returns to the idle state. This can occur for example when no > echo responses are received for NeibhborDeadInteval. " >=20 > c) Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n -- no > superG -- no superA >=20 > d) Page 37 -- Section 5.2.4 WTP manager control IPV4 address -- do > not understand the text -- is there only one ip address ? if so -- > then the ip address is used to return the interface of the AC. If > only one address -- how is load balancing done ? >=20 > e) Page 41 -- Section 6.1 Join Request -- 3rd paragraph -- Why the > 1596 MTU limit -- how was this number chosen ? =3D=3D (RIF routes if > vlan ?) if I use 802.3 then I have seen h/w do 1522 (4 byte vlan > tag) -- some number a little bigger than 1522 and h/w do 16K bytes -- > (intel ixp 4xx series) --- The 16K number is bigger than the 4k SDU > for wireless medium... Would it be better to base the discovery on > the MTU of the wireless media and work down ? >=20 > f) Page 52 -- Section 6.5 and Section 6.6 -- Change item that says > see Figure 2 -- to read see section 2.2 >=20 > g) Page 60 -- REboot Statistics =3D=3D this requires the WTP maintain > state to know if the last Failure Type was LWAPP initiated. Same > comment for Crash count. No value defined for state not maintained > by WTP. Add cross reference to section where AC tells WTP to reboot. >=20 > h) Page 65 -- Blacklist Entry's -- This whole area is not good from > my point of view. When I configure a firewall I say what is allowed > (explicitly) and forbid everything else -- there is no way I can give > a list of trusted stations and forbid everything else. This makes > live very difficult. There is room for a blacklist -- but an allowed > list is also needed. >=20 > i) Page 70 -- Image Data -- do not understand how this can work -- > only 2 fragments allowed -- no count of what is being sent etc -- no > way to detect packet loss --- why not use data xfer mechanism of > tftp ? -- the blocks are numbered =3D=3D etc BUT define a md5 hash of > the whole image and give its length in the initial request. >=20 > j) Page 72 -- Section 8.5.1 Decryption Error Report =3D=3D add note > about only useful if split mac. >=20 > k) Page 72 -- Section 8.5.2 Duplicate IP address =3D=3D what is a > host ? Is this a mobile station ? What about the case of a mobile > station having the SAME mac address as a already connected mobile > station to the WTP. =3D=3D only useful if NOT split mac >=20 > l) General comment -- there is no command to synchronize time (set > the clocks) in the WTP to a common time base >=20 > j) General comment -- why not use the text in the 802.11 MIB > definitions and the name of the MIB entry where these are used to > configure the WTP >=20 > k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT > understand how setting a bit relates to the WLAN ID's used later in > the document -- can you give an example or two ? Only 16 WLAN ID's > allowed ??/ >=20 > l) Page 97 -- WLAN ID -- field is 8 bits -- other places in document > 16 bits >=20 > m) Page 102 -- IEEE 802.11 stats -- Why not pad out Radio ID with 3 > bytes of "reserved field" so all other fields are 32 bit aligned or > move it to the end of definition (after decryption errors). >=20 > n) Page 105 -- WLAN ID -- picture is 8 bits -- text is 16 bits >=20 > o) Page 109 WLAN Capability -- can you rename this and ALL other > fields to use the same terms as the 802.11 base standard or the MIB > (very confusing) -- or cross reference >=20 > p) Page 113 -- Country Code -- reference 802.11d since this is the > definition >=20 > q) Page 113 -- Rate Set -- is length wrong ? should be >=3D 2 > otherwise what is definition for rates NOT used >=20 > r) Page 115 -- RTS Threshold etc -- use wording from the MIB > definitions for all of these entries and reference mib object >=20 > s) Page 119 -- IEEE Antenna length -- length sound be >=3D 5 >=20 > t) Page 120 -- Supported rates -- length >=3D 2 and <=3D 9 >=20 > u) Page 122 - WTP Qos -- length is 2 if untagged or 802.1p -- if > dscp it is 2 + (10)*dscp entries >=20 > v) Security -- any reason ssl could not be used even for level 2 > encryption? since the link is PT to PT -- the ip address/header is > not need -- then almost same code as layer 3 -- and the package is > public domain so easy to hack >=20 > regards, >=20 > Philip >=20 > Philip Rakity > prakity@u4eatech.com >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 16:30:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKtH-0003L5-OQ for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:30:54 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03843 for ; Wed, 18 Jan 2006 16:29:22 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B46974300C0 for ; Wed, 18 Jan 2006 13:30:44 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 99E9443005F for ; Wed, 18 Jan 2006 13:30:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6F14039806C for ; Wed, 18 Jan 2006 13:30:18 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 369D7398027 for ; Wed, 18 Jan 2006 13:30:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 43F113601C0; Wed, 18 Jan 2006 21:16:47 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Wed, 18 Jan 2006 21:16:47 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 284B3360193; Wed, 18 Jan 2006 21:16:47 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20379-13; Wed, 18 Jan 2006 21:16:44 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 1FC6B360041; Wed, 18 Jan 2006 21:16:42 +0000 (GMT) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2014373FD@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2014373FD@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12F9AA6C-7C82-4BFC-9A19-A644ACD662C8@u4eatech.com> Content-Transfer-Encoding: 7bit From: Philip Rakity Subject: Re: [Capwap] Comments on Draft 3 -- LWAPP Date: Wed, 18 Jan 2006 13:30:06 -0800 To: Pat Calhoun (pacalhou) X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit Comments belowl On Jan 18, 2006, at 12:23 PM, Pat Calhoun (pacalhou) wrote: >> On Dec 12, 2005, at 11:42 PM, sujay wrote: >>> b) page 32 -- section 5.1 "Discovery requests MUST be sent >> by an ... >>> AND when no echo responses are received and the WTP" I think it >>> should say that "Discovery requests MUST be sent by a WTP when the >>> WTP returns to the idle state. This can occur for example when no >>> echo responses are received for NeibhborDeadInteval. " >>> >>> Suj> IMHO in the Idle State No Discovery requests are sent, once >>> entering >>> the Idle state, the SM moves to Discovery state before sending Disc >>> Req messages. >>> >>> The section talks about when as you rightly pointed out no echo >>> responses are Received for NeighborDeadInterval. >>> >> Thanks -- So does idle state wait the random time interval >> and then move to discovery or is done in the discovery phase ? >> If the initial delay is done in the idle phase then the >> requirement is after no echo packets -- transition to idle phase. > > Does the following text solve the issue, or do you need additional > clarification/changes in the spec? > > Discovery requests MUST be sent by a WTP when no echo > responses > are > received for NeighborDeadInterval and the WTP returns to the > Idle > state. Discovery requests are sent after > NeighborDeadInterval, > they > MUST be sent after waiting for a random delay less than > MaxDiscoveryInterval. A WTP MAY send up to a maximum of > MaxDiscoveries > discoveries, waiting for a random delay less than > MaxDiscoveryInterval > between each successive discovery. TEXT above is fine -- Thank You. >> >>> d) Page 37 -- Section 5.2.4 WTP manager control IPV4 address -- do >>> not understand the text -- is there only one ip address ? >> if so -- >>> then the ip address is used to return the interface of the AC. If >>> only one address -- how is load balancing done ? >>> >>> Suj> If the AC has more than one Interfaces open for the WTP to >>> join, it >>> specifies each of these ip address's with Individual TLV's, >>> - right, for single ip interface load balancing cannot be >> done ,(given >>> only one AC) the AC should return its own interface Ip address. >> >> So the problem is the ip address CAN repeat but this is not >> reflected in the definition of the length? > An AC would include one such message element per interface it has. So > the length is correct. Could you add a note that message element is repeated per interface being sent to the WTP. > >>> >>> >>> h) Page 65 -- Blacklist Entry's -- This whole area is not good >>> from my >>> point of view. When I configure a firewall I say what is allowed >>> (explicitly) and forbid everything else -- there is no way I can >>> give a >>> list of trusted stations and forbid everything else. This >> makes live >>> very difficult. There is room for a blacklist -- but an allowed >>> list is >>> also needed. >>> >>> >>> Suj> In my opinion blacklisting is to prevent any .11 mgt >> frames from >>> passing upto the AC for the current WTP-AC session. >>> - to blacklist one MAC address and allow others is more exact and >>> specific rather than knowing ALL those which are >>> Allowed, either way the one which is allowed will is kept >> the Radius, >>> you could put your 'allowed' list there ! >> >> I think there is a use for BOTH cases. in a secure environment I do >> not want control frames from rogue AP's. > > Looks like we are still not in complete agreement on this one. Typical > 802.11 > Devices include an approved list (known as MAC Filter). It is assumed > that this > function is provided w/o CAPWAP involvement, while a blacklist is > provided > by CAPWAP. If I understsand correct, you would like a replicated > set of > messages > to serve as the permit list? Do others agree? Yes -- My Point. In a secure environment I want to say what is allowed and forbid other things. > >>> >>> >>> i) Page 70 -- Image Data -- do not understand how this can work -- >>> only >>> 2 fragments allowed -- no count of what is being sent etc >> -- no way to >>> detect packet loss --- why not use data xfer mechanism of >> tftp ? -- >>> the blocks are numbered == etc BUT define a md5 hash of the whole >>> image >>> and give its length in the initial request. >>> >>> Suj> LWAPP has the in-band Image transfer mechanism, some >> protocols >>> use >>> what you have specified. >>> >> >> I do not understand how this can work as defined in the text. I >> understand I could overlay it but it needs a definition. > > Could you help identify what needs a definition? I did not understand (and now do) how this mechanism works. But I do not understand how one knows the transfer is finished? Is there also another end-case to know if the xfer is beginning ? > >>> k) Page 72 -- Section 8.5.2 Duplicate IP address == what is a >>> host ? Is this a mobile station ? What about the case of a mobile >>> station having the SAME mac address as a already connected mobile >>> station to the WTP. == only useful if NOT split mac >>> >>> Suj> host here is the WTP itself, MAC address are unique so there >>> should >>> not be a case of a mobile station having >>> the same MAC address as another one. >>> >> Can we change text to say WTP -- thanks >> Just like there should not be a duplicate IP address in the network >> there should not be a duplicate MAC address, but MAC addresses are >> also soft >> the linux command >> ifconfig hwether allows one to change the mac address > > I'm confused here because the text reads fine to me. I did change host > to > IP device, but I don't think this is addressing your original comment. > The change to IP device addresses my concern. > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 16:51:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLDQ-0005bb-Il for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:51:40 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10789 for ; Wed, 18 Jan 2006 16:50:13 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C856B43006D for ; Wed, 18 Jan 2006 13:51:38 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id BA7C943005F for ; Wed, 18 Jan 2006 13:51:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id A2002398023 for ; Wed, 18 Jan 2006 13:51:15 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7745F398075 for ; Wed, 18 Jan 2006 13:51:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 42894360041; Wed, 18 Jan 2006 21:37:44 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Wed, 18 Jan 2006 21:37:44 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 23E77360193; Wed, 18 Jan 2006 21:37:44 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20948-14; Wed, 18 Jan 2006 21:37:42 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id AE425360041; Wed, 18 Jan 2006 21:37:41 +0000 (GMT) In-Reply-To: <12F9AA6C-7C82-4BFC-9A19-A644ACD662C8@u4eatech.com> References: <4FF84B0BC277FF45AA27FE969DD956A2014373FD@xmb-sjc-235.amer.cisco.com> <12F9AA6C-7C82-4BFC-9A19-A644ACD662C8@u4eatech.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D0130BB-BA54-4FEA-99F8-4557FC8EE145@u4eatech.com> Content-Transfer-Encoding: 7bit From: Philip Rakity Date: Wed, 18 Jan 2006 13:51:05 -0800 To: capwap@frascone.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] MTU Discovery Section 6.1 (possible wording) X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit We should require MTU discovery and if this is not available then require the JOIN request to do this Change If the transport used does not provide MTU path discovery, the initial Join Request is padded with the Test message element to 1596 bytes. If a Join Response is received, the WTP can forward frames without requiring any fragmentation. If no Join Response is received, it issues a second Join Request padded with the Test payload to a total of 1500 bytes. The WTP continues to cycle from large (1596) to small (1500) packets until a Join Response has been received , or until both packets sizes have been retransmitted 3 times . If the Join Response is not received after the maximum number of retransmissions, the WTP MUST abandon the AC and restart the discovery phase. To If the transport used does not provide MTU path discovery, the initial Join Request is used to perform this function. The Test message element is used to pad the join request (including all headers) to the lesser of the Ethernet MTU and Wireless MTU. If a Join Response is received, the WTP can forward frames without requiring any fragmentation. If no Join Response is received, it issues a second Join Request padded with the Test payload to a total of 1500 bytes. The WTP continues to cycle from lesser of the Ethernet MTU and Wireless MTU to small (1500) packets until a Join Response has been received , or until both packets sizes have been retransmitted 3 times . If the Join Response is not received after the maximum number of retransmissions, the WTP MUST abandon the AC and restart the discovery phase. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 16:56:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLHg-0008CQ-U2 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:56:05 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12437 for ; Wed, 18 Jan 2006 16:54:36 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 74F764300CD for ; Wed, 18 Jan 2006 13:56:01 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 23C8243005F for ; Wed, 18 Jan 2006 13:55:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 0D84E80C103 for ; Wed, 18 Jan 2006 13:55:37 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id D012380C006 for ; Wed, 18 Jan 2006 13:55:35 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 13:55:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0ILtYjt014260; Wed, 18 Jan 2006 13:55:34 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 13:55:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP Date: Wed, 18 Jan 2006 13:55:32 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20143749A@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Comments on Draft 3 -- LWAPP Thread-Index: AcYNx6Gn1cZV3VhRQR6OZCpopCCA0wOqP8tw From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 18 Jan 2006 21:55:34.0627 (UTC) FILETIME=[E8A33B30:01C61C79] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Addressing the next round of comments. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip.Rakity@u4eatech.com [mailto:Philip.Rakity@u4eatech.com]=20 > Sent: Friday, December 30, 2005 9:03 PM > To: capwap@frascone.com > Subject: [Capwap] Comments on Draft 3 -- LWAPP >=20 >=20 > I was re-reading the specification on the airplane and found=20 > the following items that may need addressing. I do not have=20 > access to my previous e-mail so I may have duplicate comments=20 > from before. >=20 > regards, >=20 > Philip >=20 >=20 > Page 15 Join to Join Confirm > WTP -- the Join Response must include a valid <=3D=3D valid is = mis-spelled Done >=20 > Page 16: Image Data to Image Data > WTP: Response that indicates that the AC has more data to send >=20 > I did not see in the definition of the Image Data how the WTP=20 > knows there is more data to come from the AC. The Image Data message element specifies: The Image Data field contains 1024 characters, unless the payload=20 being sent is the last one (end of file) This means that a packet whose field does not include 1024 characters is the last one. However, if the last packet is of length 1024, a clause is required that specifies that a zero length payload needs to be transmitted. >=20 > Page 18: 4th item -- This is the AC's normal state of operation, ... > delete the phrasethat says [, and there are many events that=20 > cause this to occur.] Ok >=20 > Page 26 last paragraph > In the event the WTP and AC are separated by a NAT, delete=20 > the remark in between the comma's with the WTP using private=20 > IP address space, I agree >=20 > It is always the responsibility of NAT to manage the connection >=20 > Page 27: LWAPP Packet Definitions >=20 > is the 802.11 FCS included in the LWAPP packets or not. If=20 > so, how does one know that this is occuring. Yes, I caught this during the fixups. So I have cleaned up the "LWAPP Data Messages" section to include: 4.1. LWAPP Data Messages An LWAPP data message is a forwarded wireless frame. When forwarding wireless frames, the sender simply encapsulates the wireless frame in an LWAPP data packet, using the appropriate transport rules defined in section Section 3. In the event that the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for the fragmentation of the frame, as specified in the transport specific section of Section 3. The actual format of the encapsulated LWAPP data frame is subject to the rules defined under the specific wireless technology binding. As a consequence, each wireless technology binding MUST define a section entitled "Payload encapsulation", which defines the format of the wireless payload that is encapsulated within the LWAPP Data messages. Then I created the IEEE 802.11 binding section text: 11.3.1. Payload encapsulation The LWAPP protocol defines the data frame, which allows a wireless payload to be encapsulated. For IEEE 802.11, the 802.11 header and payload is encapsulated. However, it is important to note that the 802.11 FCS checksum is handled by the WTP. This allows the WTP to validate a frame prior to sending it to the AC. Similarly, when an AC wishes to transmit a frame towards a station, the WTP computes and adds the FCS checksum. >=20 > Page 59: 7.2.6 WTP Static IP Address Information >=20 > add note to say that IP Address/ Netmask/ Gateway are only=20 > valid if static is 1 =3D=3D or rearrange structure so that static=20 > is first element and other elements follow if static is 1. Fixed >=20 > Page 90: 2nd sentence should read: The probe request is then sent Done >=20 > Page 95: > WLAN ID bit mask -- define which bit maps to which BSSID in=20 > reading the ieee spec the bits start of the left but I think=20 > here bit 0 is on the right. Sorry, I don't follow >=20 > Page 97: Supported Rates > I think this IE is between 1 and 8 octets -- if the length of=20 > the IE is not passed than the VLAN Name's starting position=20 > cannot be known. Changed the data structure to: [...] | 802.11e Mode | Qos |Length of Rates|Supported Rates| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Rates | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Supported Rates| VLAN Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Page 99: VLAN Name -- do not understand "with local MAC WTPs" Changed text to: An optional variable string containing the VLAN Name on which the WTP is to locally bridge user data. Note this field is only valid with WTPs configured in Local MAC mode. >=20 > Page 101: VLAN Identifier: PRC =3D=3D What is a PRC ? A PRC is an editor who forgets to remove his initials from the draft. The new Text reads: The VLAN to assign to the mobile station being updated. Note that this field is only valid if per station VLAN assignment is being enforced on the WTP. >=20 > Page 113: Add note on Number of BSSID's : range 1 to 16 Done. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 16:58:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLJh-0000hw-53 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:58:09 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13135 for ; Wed, 18 Jan 2006 16:56:41 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 2D7E34300BC for ; Wed, 18 Jan 2006 13:58:07 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id C643B43005F for ; Wed, 18 Jan 2006 13:57:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B3CB339803B for ; Wed, 18 Jan 2006 13:57:35 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by zoidberg.tigertech.net (Postfix) with ESMTP id DB329398073 for ; Wed, 18 Jan 2006 13:57:32 -0800 (PST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2006 13:57:08 -0800 X-IronPort-AV: i="3.99,381,1131350400"; d="scan'208,217"; a="1767886277:sNHT4121820026" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0ILv8c5025098 for ; Wed, 18 Jan 2006 13:57:08 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 13:56:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 13:56:57 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20143749F@xmb-sjc-235.amer.cisco.com> Thread-Topic: Done w/ Issue Tracker Thread-Index: AcYcehnLehEPfW3lSAGbqYvk46RYQQ== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 18 Jan 2006 21:56:58.0064 (UTC) FILETIME=[1A5EB500:01C61C7A] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.402 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE Subject: [Capwap] Done w/ Issue Tracker X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0954785671==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0954785671== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C7A.1A2CFD3E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C7A.1A2CFD3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C61C7A.1A2CFD3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

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

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

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

------_=_NextPart_001_01C61C7A.1A2CFD3E-- --===============0954785671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0954785671==-- From krista@hammerhead.com Wed Jan 18 17:22:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLhc-0002tf-UP for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 17:22:52 -0500 Received: from user-142gn90.cable.mindspring.com (user-142gn90.cable.mindspring.com [72.40.93.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15866 for ; Wed, 18 Jan 2006 17:21:25 -0500 (EST) Received: from videotape.irresolute.com (condemn [99.231.93.201]) by eloquent.com (abound) with equilibria id 670842995040 for ; Wed, 18 Jan 2006 21:21:15 -0500 From: Rocky Payne To: capwap-archive@ietf.org Subject: Amazing, Gregorio X-Mailer: taxation 63.82.258483 Date: Wed, 18 Jan 2006 23:46:16 -0500 Message-ID: <565458385112533152281.26647@hammerhead.com> Content-Type: multipart/mixed;boundary="------=7143481843263" Content-Transfer-Encoding: quoted-printable --------=7143481843263 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Package	Quantity	Price in your local drugstore*	Our price	Learn More Now
10 softtabs	20 doses	~~$149.95~~	$119.95
20 softtabs	40 doses	~~$299.95~~	$159.95
30 softtabs	60 doses	~~$849.95~~	$169.95
60 softtabs	120 doses	~~$1 999.95~~	$259.95
90 softtabs	180 doses	~~$3 099.95~~	$299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

A goal properly set is halfway reached.There is nothing in the world so much admired as a man who knows how to bear unhappiness with courage.
A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes.The most important part of teaching is to teach what it is to know.Treasure the love you receive above all. It will survive long after your gold and good health have vanished. --------=7143481843263 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, James-> http://olikorin.com/?a=1065 --------=7143481843263-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 17:54:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMBy-0007rt-8D for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 17:54:16 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18112 for ; Wed, 18 Jan 2006 17:52:46 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8A1FB4300A4 for ; Wed, 18 Jan 2006 14:54:12 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id A8B37430063 for ; Wed, 18 Jan 2006 14:53:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9A2B380C0E8 for ; Wed, 18 Jan 2006 14:53:43 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by hermes.tigertech.net (Postfix) with ESMTP id 6F55180C0F3 for ; Wed, 18 Jan 2006 14:53:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 243853601C8; Wed, 18 Jan 2006 22:40:10 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Wed, 18 Jan 2006 22:40:10 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id 098383601C5; Wed, 18 Jan 2006 22:40:10 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25601-08; Wed, 18 Jan 2006 22:40:01 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id BBE983601C0; Wed, 18 Jan 2006 22:40:00 +0000 (GMT) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A20143749A@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A20143749A@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Rakity Date: Wed, 18 Jan 2006 14:53:20 -0800 To: capwap@frascone.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] WLAN ID comment and thanks X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit Thanks -- My WLAN ID comment is probably clearer. I hope. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is bit 0 == indicating the base bssid ? I think it the field labeled 15 and the field labeled 00 is the 16th entry (counting from one). Philip On Jan 18, 2006, at 1:55 PM, Pat Calhoun (pacalhou) wrote: > Addressing the next round of comments. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: Philip.Rakity@u4eatech.com [mailto:Philip.Rakity@u4eatech.com] >> Sent: Friday, December 30, 2005 9:03 PM >> To: capwap@frascone.com >> Subject: [Capwap] Comments on Draft 3 -- LWAPP >> >> >> I was re-reading the specification on the airplane and found >> the following items that may need addressing. I do not have >> access to my previous e-mail so I may have duplicate comments >> from before. >> >> regards, >> >> Philip >> >> >> Page 15 Join to Join Confirm >> WTP -- the Join Response must include a valid <== valid is mis- >> spelled > Done > >> >> Page 16: Image Data to Image Data >> WTP: Response that indicates that the AC has more data to send >> >> I did not see in the definition of the Image Data how the WTP >> knows there is more data to come from the AC. > > The Image Data message element specifies: > > The Image Data field contains 1024 characters, unless the payload > being sent is the last one (end of file) > > This means that a packet whose field does not include 1024 > characters is > the last one. However, if the last packet is of length 1024, a > clause is > > required that specifies that a zero length payload needs to be > transmitted. > >> >> Page 18: 4th item -- This is the AC's normal state of operation, ... >> delete the phrasethat says [, and there are many events that >> cause this to occur.] > Ok > >> >> Page 26 last paragraph >> In the event the WTP and AC are separated by a NAT, delete >> the remark in between the comma's with the WTP using private >> IP address space, > I agree > >> >> It is always the responsibility of NAT to manage the connection >> >> Page 27: LWAPP Packet Definitions >> >> is the 802.11 FCS included in the LWAPP packets or not. If >> so, how does one know that this is occuring. > > Yes, I caught this during the fixups. So I have cleaned up the "LWAPP > Data Messages" section to include: > 4.1. LWAPP Data Messages > > An LWAPP data message is a forwarded wireless frame. When > forwarding > wireless frames, the sender simply encapsulates the wireless > frame in > an LWAPP data packet, using the appropriate transport rules defined > in section Section 3. > > In the event that the encapsulated frame would exceed the transport > layer's MTU, the sender is responsible for the fragmentation of the > frame, as specified in the transport specific section of Section 3. > > The actual format of the encapsulated LWAPP data frame is > subject to > the rules defined under the specific wireless technology > binding. As > a consequence, each wireless technology binding MUST define a > section > entitled "Payload encapsulation", which defines the format of the > wireless payload that is encapsulated within the LWAPP Data > messages. > > Then I created the IEEE 802.11 binding section text: > > 11.3.1. Payload encapsulation > > The LWAPP protocol defines the data frame, which allows a wireless > payload to be encapsulated. For IEEE 802.11, the 802.11 header and > payload is encapsulated. However, it is important to note that the > 802.11 FCS checksum is handled by the WTP. This allows the WTP to > validate a frame prior to sending it to the AC. Similarly, when an > AC wishes to transmit a frame towards a station, the WTP > computes and > adds the FCS checksum. > >> >> Page 59: 7.2.6 WTP Static IP Address Information >> >> add note to say that IP Address/ Netmask/ Gateway are only >> valid if static is 1 == or rearrange structure so that static >> is first element and other elements follow if static is 1. > > Fixed > >> >> Page 90: 2nd sentence should read: The probe request is then sent > Done > >> >> Page 95: >> WLAN ID bit mask -- define which bit maps to which BSSID in >> reading the ieee spec the bits start of the left but I think >> here bit 0 is on the right. > Sorry, I don't follow > >> >> Page 97: Supported Rates >> I think this IE is between 1 and 8 octets -- if the length of >> the IE is not passed than the VLAN Name's starting position >> cannot be known. > Changed the data structure to: > > [...] > | 802.11e Mode | Qos |Length of Rates|Supported Rates| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Supported Rates | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Supported Rates| VLAN Name... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Page 99: VLAN Name -- do not understand "with local MAC WTPs" > Changed text to: > An optional variable string containing the VLAN Name on which > the > WTP is to locally bridge user data. Note this field is only > valid > with WTPs configured in Local MAC mode. >> >> Page 101: VLAN Identifier: PRC == What is a PRC ? > A PRC is an editor who forgets to remove his initials from the draft. > The new > Text reads: > The VLAN to assign to the mobile station being updated. Note > that this > field is only valid if per station VLAN assignment is being > enforced > on the WTP. > >> >> Page 113: Add note on Number of BSSID's : range 1 to 16 > > Done. > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 20:09:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOIb-0005Qi-Dk for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:09:13 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27464 for ; Wed, 18 Jan 2006 20:07:46 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 848FC4300CB for ; Wed, 18 Jan 2006 17:09:10 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 34FB4430063 for ; Wed, 18 Jan 2006 17:08:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 18D6E80C119 for ; Wed, 18 Jan 2006 17:08:42 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id C332E80C0E9 for ; Wed, 18 Jan 2006 17:08:38 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J18Zce012943; Thu, 19 Jan 2006 10:08:35 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k0J18a519262; Thu, 19 Jan 2006 10:08:36 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k0J18Z913845; Thu, 19 Jan 2006 10:08:35 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 09:09:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E37A4@pslexc01.psl.local> Thread-topic: [Capwap] Comments on Draft 3 -- LWAPP Thread-index: AcX/Y7B3bgU7IpOSRvCH5LO06L+vKAB4j+KwBspV/RAACWDpEA== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , "Philip Rakity" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Hi Pat, I'll send the issues in separate notes. In general, they follow the issues list from the last meeting. Saravanan -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 4:41 AM To: Saravanan Govindan; Philip Rakity; capwap@frascone.com Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP Saravanan, In order to ensure that I am tracking all of the issues properly, could you please be more specific in your change recommendations below? I do have the field size one already, as this was in the eval draft. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 > Sent: Wednesday, December 14, 2005 11:08 PM > To: Philip Rakity; capwap@frascone.com > Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP >=20 > Hi Philip, >=20 > You have clearly reviewed the draft in detail! I think the=20 > points you raise are very important for the protocol.=20 >=20 > Perhaps some recommendations can be made based on the points=20 > raised. I think it would be helpful for the WG to see how the=20 > recommendations can fit in to the current LWAPP specifications.=20 >=20 > On a related note, I think the first WG version of the=20 > protocol can also include those issues which were discussed=20 > during the last meeting. There seemed to be some agreement in=20 > the issues such as information elements field size, firmware=20 > operations and local-MAC mode operations.=20 >=20 > Cheers, >=20 > Saravanan >=20 >=20 >=20 >=20 > -----Original Message----- > From: Philip Rakity [mailto:philip.rakity@u4eatech.com] > Sent: Tuesday, December 13, 2005 5:35 AM > To: capwap@frascone.com > Subject: [Capwap] Comments on Draft 3 -- LWAPP >=20 >=20 > I am a newbie to the group and this the first time that I have read > the internet draft. I have a number of comments on the draft that > are below. Most a minor editorial things but some are areas I do not > understand >=20 > a) Use of "integer" is not consistent in the document --- most of the > time it means unsigned, sometimes signed (but marked as signed), but > sometimes the phrase "unsigned integer" is used and this then makes > me wonder if the fields marked integer are signed or not. >=20 > b) page 32 -- section 5.1 "Discovery requests MUST be sent by an ... > AND when no echo responses are received and the WTP" I think it > should say that "Discovery requests MUST be sent by a WTP when the > WTP returns to the idle state. This can occur for example when no > echo responses are received for NeibhborDeadInteval. " >=20 > c) Page 35 -- Radio Type -- no 802.11b (only) -- no 802.11n -- no > superG -- no superA >=20 > d) Page 37 -- Section 5.2.4 WTP manager control IPV4 address -- do > not understand the text -- is there only one ip address ? if so -- > then the ip address is used to return the interface of the AC. If > only one address -- how is load balancing done ? >=20 > e) Page 41 -- Section 6.1 Join Request -- 3rd paragraph -- Why the > 1596 MTU limit -- how was this number chosen ? =3D=3D (RIF routes if > vlan ?) if I use 802.3 then I have seen h/w do 1522 (4 byte vlan > tag) -- some number a little bigger than 1522 and h/w do 16K bytes -- > (intel ixp 4xx series) --- The 16K number is bigger than the 4k SDU > for wireless medium... Would it be better to base the discovery on > the MTU of the wireless media and work down ? >=20 > f) Page 52 -- Section 6.5 and Section 6.6 -- Change item that says > see Figure 2 -- to read see section 2.2 >=20 > g) Page 60 -- REboot Statistics =3D=3D this requires the WTP maintain > state to know if the last Failure Type was LWAPP initiated. Same > comment for Crash count. No value defined for state not maintained > by WTP. Add cross reference to section where AC tells WTP to reboot. >=20 > h) Page 65 -- Blacklist Entry's -- This whole area is not good from > my point of view. When I configure a firewall I say what is allowed > (explicitly) and forbid everything else -- there is no way I can give > a list of trusted stations and forbid everything else. This makes > live very difficult. There is room for a blacklist -- but an allowed > list is also needed. >=20 > i) Page 70 -- Image Data -- do not understand how this can work -- > only 2 fragments allowed -- no count of what is being sent etc -- no > way to detect packet loss --- why not use data xfer mechanism of > tftp ? -- the blocks are numbered =3D=3D etc BUT define a md5 hash of > the whole image and give its length in the initial request. >=20 > j) Page 72 -- Section 8.5.1 Decryption Error Report =3D=3D add note > about only useful if split mac. >=20 > k) Page 72 -- Section 8.5.2 Duplicate IP address =3D=3D what is a > host ? Is this a mobile station ? What about the case of a mobile > station having the SAME mac address as a already connected mobile > station to the WTP. =3D=3D only useful if NOT split mac >=20 > l) General comment -- there is no command to synchronize time (set > the clocks) in the WTP to a common time base >=20 > j) General comment -- why not use the text in the 802.11 MIB > definitions and the name of the MIB entry where these are used to > configure the WTP >=20 > k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT > understand how setting a bit relates to the WLAN ID's used later in > the document -- can you give an example or two ? Only 16 WLAN ID's > allowed ??/ >=20 > l) Page 97 -- WLAN ID -- field is 8 bits -- other places in document > 16 bits >=20 > m) Page 102 -- IEEE 802.11 stats -- Why not pad out Radio ID with 3 > bytes of "reserved field" so all other fields are 32 bit aligned or > move it to the end of definition (after decryption errors). >=20 > n) Page 105 -- WLAN ID -- picture is 8 bits -- text is 16 bits >=20 > o) Page 109 WLAN Capability -- can you rename this and ALL other > fields to use the same terms as the 802.11 base standard or the MIB > (very confusing) -- or cross reference >=20 > p) Page 113 -- Country Code -- reference 802.11d since this is the > definition >=20 > q) Page 113 -- Rate Set -- is length wrong ? should be >=3D 2 > otherwise what is definition for rates NOT used >=20 > r) Page 115 -- RTS Threshold etc -- use wording from the MIB > definitions for all of these entries and reference mib object >=20 > s) Page 119 -- IEEE Antenna length -- length sound be >=3D 5 >=20 > t) Page 120 -- Supported rates -- length >=3D 2 and <=3D 9 >=20 > u) Page 122 - WTP Qos -- length is 2 if untagged or 802.1p -- if > dscp it is 2 + (10)*dscp entries >=20 > v) Security -- any reason ssl could not be used even for level 2 > encryption? since the link is PT to PT -- the ip address/header is > not need -- then almost same code as layer 3 -- and the package is > public domain so easy to hack >=20 > regards, >=20 > Philip >=20 > Philip Rakity > prakity@u4eatech.com >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 20:16:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOPy-0007qj-9v for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:16:50 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28272 for ; Wed, 18 Jan 2006 20:15:23 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0648343010B for ; Wed, 18 Jan 2006 17:16:49 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 88C99430063 for ; Wed, 18 Jan 2006 17:16:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B682A398027 for ; Wed, 18 Jan 2006 17:16:13 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6B7439801A for ; Wed, 18 Jan 2006 17:16:11 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J1G8ce021011; Thu, 19 Jan 2006 10:16:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k0J1GA209427; Thu, 19 Jan 2006 10:16:10 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k0J1GAd15138; Thu, 19 Jan 2006 10:16:10 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 09:17:04 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E37A9@pslexc01.psl.local> Thread-topic: Firmware Trigger Thread-index: AcYclg78tR1+2HsGTVCSJJCCN1yIww== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] Firmware Trigger X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0949623765==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0949623765== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C95.D9FA141E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C95.D9FA141E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Issue: The Evaluation draft (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of firmware checks and updates independent of other operations.=20 =20 My recommendation: To introduce a Firmware-Update state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section 2.2. =20 Saravanan ------_=_NextPart_001_01C61C95.D9FA141E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

Issue: The Evaluation draft = (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of = firmware checks and updates independent of other operations. =

My recommendation: To introduce a Firmware-Update = state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section = 2.2.

Saravanan

------_=_NextPart_001_01C61C95.D9FA141E-- --===============0949623765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0949623765==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 20:28:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOax-0002Fd-Rd for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:28:11 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00089 for ; Wed, 18 Jan 2006 20:26:44 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id AA4B5430109 for ; Wed, 18 Jan 2006 17:28:09 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 9CA9B430063 for ; Wed, 18 Jan 2006 17:27:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7009D80C0F3 for ; Wed, 18 Jan 2006 17:27:34 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 6A49C80C0E9 for ; Wed, 18 Jan 2006 17:27:32 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id k0J1RTD1011314; Thu, 19 Jan 2006 10:27:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k0J1RUm20705; Thu, 19 Jan 2006 10:27:30 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k0J1RUJ00888; Thu, 19 Jan 2006 10:27:30 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 09:28:24 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E37B8@pslexc01.psl.local> Thread-topic: Default mode for logical groups Thread-index: AcYcl5TWMIIGbIwiRmOufZe4zQIvuQ== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] Default mode for logical groups X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167928434==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1167928434== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C97.6ED91FC7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C97.6ED91FC7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 Saravanan ------_=_NextPart_001_01C61C97.6ED91FC7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

Issue:

Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. = This makes for consistent configuration and management across logical groups. =

My recommendation:

Introduce a message element in the WLAN Config = message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment = VLANs to wireless-segment BSSIDs. This is the simplest and most common case for = logical groups.

Then include description of logical group = configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section = 11.4).

Saravanan

------_=_NextPart_001_01C61C97.6ED91FC7-- --===============1167928434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1167928434==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 20:40:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOmW-0000vR-P8 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:40:09 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04121 for ; Wed, 18 Jan 2006 20:38:40 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C4744300D2 for ; Wed, 18 Jan 2006 17:40:05 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id CFB78430063 for ; Wed, 18 Jan 2006 17:39:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B8A3080C0F7 for ; Wed, 18 Jan 2006 17:39:29 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id BB7F180C0F3 for ; Wed, 18 Jan 2006 17:39:28 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J1dPce013483; Thu, 19 Jan 2006 10:39:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k0J1dR219425; Thu, 19 Jan 2006 10:39:27 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k0J1dRJ13531; Thu, 19 Jan 2006 10:39:27 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 09:40:22 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E37C4@pslexc01.psl.local> Thread-topic: PMK Sharing Thread-index: AcYcmU+6qksdXfRCS8Sx+WQAWUWX3A== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] PMK Sharing X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060518159==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1060518159== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61C99.1AD0E9A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61C99.1AD0E9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Issue: In the case of an AC managing a same PMK across many WTPs, IEEE 802.11 stations cannot distinguish between PMKs that are validly shared and those that have been compromised (I0 of Issues/Recommendations). =20 My recommendation: Include text in the Security Considerations (draft-ohara-capwap-lwapp-03.txt) Section 15 along the lines; =20 "The CAPWAP protocol may be used in scenarios in which an AC manages a PMK across many WTPs. In such scenarios, IEEE 802.11 stations moving across WTPs cannot distinguish between PMKs that are legitimately shared and PMKs that have been compromised.=20 =20 The CAPWAP WG recognizes this ambiguity and recommends implementers of the protocol to review the outcome of IEEE 802.11r efforts for resolution." =20 Saravanan=20 =20 =20 ------_=_NextPart_001_01C61C99.1AD0E9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

Issue:

In the case of an AC managing a same PMK across many = WTPs, IEEE 802.11 stations cannot distinguish between PMKs that are validly shared = and those that have been compromised (I0 of = Issues/Recommendations).

My recommendation:

Include text in the Security Considerations = (draft-ohara-capwap-lwapp-03.txt) Section 15 along the lines;

“The CAPWAP protocol may be used in scenarios = in which an AC manages a PMK across many WTPs. In such scenarios, IEEE 802.11 = stations moving across WTPs cannot distinguish between PMKs that are legitimately shared = and PMKs that have been compromised.

The CAPWAP WG recognizes this ambiguity and = recommends implementers of the protocol to review the outcome of IEEE 802.11r = efforts for resolution.”

Saravanan

------_=_NextPart_001_01C61C99.1AD0E9A0-- --===============1060518159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1060518159==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 21:46:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPp4-0006gL-HV for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 21:46:50 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09721 for ; Wed, 18 Jan 2006 21:45:22 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D46EC430102 for ; Wed, 18 Jan 2006 18:46:47 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 8969343006D for ; Wed, 18 Jan 2006 18:46:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 693EA398022 for ; Wed, 18 Jan 2006 18:46:04 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id B4348398030 for ; Wed, 18 Jan 2006 18:46:01 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J2jwce019393; Thu, 19 Jan 2006 11:45:58 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k0J2k0m25752; Thu, 19 Jan 2006 11:46:00 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k0J2k0J24655; Thu, 19 Jan 2006 11:46:00 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 10:46:47 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E3801@pslexc01.psl.local> Thread-topic: IEEE 802.11i Considerations Thread-index: AcYcopcAGkfToB7cQrGzyxfD5YykkA== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] IEEE 802.11i Considerations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394325857==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0394325857== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA2.629D3315" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA2.629D3315 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, Issue: In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE 802.11i authenticator is located in an AC, there is a mismatch in tracking KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP protocol must allow the 4-way and Group-key exchanges to use accurate values of KeyRSC and KeyMIC in all cases.=20 =20 My recommendation: Introduce new Key Configuration & Key Configuration Response messages as part of Message Types (draft-ohara-capwap-lwapp-03.txt) Section 4.2.1.1. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields).=20 =20 Describe use of Key Configuration as part of WTP Configuration Management (draft-ohara-capwap-lwapp-o3.txt) Section 7.=20 =20 =20 Saravanan=20 =20 =20 ------_=_NextPart_001_01C61CA2.629D3315 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

Issue:

In cases where IEEE 802.11i encryption/decryption is = located in a WTP and IEEE 802.11i authenticator is located in an AC, there is a = mismatch in tracking KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section = 5.1.10. The CAPWAP protocol must allow the 4-way and Group-key exchanges to use accurate values of KeyRSC and KeyMIC in all cases. =

My recommendation:

Introduce new Key Configuration & Key = Configuration Response messages as part of Message Types = (draft-ohara-capwap-lwapp-03.txt) Section 4.2.1.1. Key Configuration message will be used to exchange = 3^rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC = fields) and 1^st message (for group-key exchange & with unassigned = KeyMIC and KeyRSC fields).

Describe use of Key Configuration as part of WTP = Configuration Management (draft-ohara-capwap-lwapp-o3.txt) Section 7. =

Saravanan

------_=_NextPart_001_01C61CA2.629D3315-- --===============0394325857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0394325857==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 21:49:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPrP-0007Lp-Mm for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 21:49:15 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09945 for ; Wed, 18 Jan 2006 21:47:48 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 1883E430129 for ; Wed, 18 Jan 2006 18:49:14 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id BE80243006D for ; Wed, 18 Jan 2006 18:48:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9749880C123 for ; Wed, 18 Jan 2006 18:48:48 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 5DB3880C10C for ; Wed, 18 Jan 2006 18:48:47 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2006 18:48:47 -0800 X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="393473388:sNHT38636228" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0J2mkQi029708; Wed, 18 Jan 2006 18:48:46 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 18:48:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 18:48:44 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437655@xmb-sjc-235.amer.cisco.com> Thread-Topic: Local MAC Tunneling Mode Thread-Index: AcYHe2JXbjfQ/iSmSNGzkQlPLn0lqgVJrOjQ From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 02:48:46.0664 (UTC) FILETIME=[DE4F0C80:01C61CA2] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Subject: [Capwap] RE: Local MAC Tunneling Mode X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Saravanan, =20 Thanks for the contributed text. I have slightly changed the text you proposed in order to allow a WTP to provide more than one mode of operation and allow the AC to pick which mode it wants (based on some internal policy). =20 The Discovery Request now includes:=20 5.1.4. WTP MAC Type The WTP MAC-Type message element allows the WTP to communicate its mode of operation to the AC. A WTP that advertises support for both modes allows the AC to dictate the mode to use, based on some local policy decision. 0 =20 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MAC Type | +-+-+-+-+-+-+-+-+ Type: TBD for WTP MAC Type Length: 1 MAC Type: The MAC mode of operation supported by the WTP. The following values are supported 0 - Local-MAC: Local-MAC is the default mode that MUST be supported by all WTPs. 1 - Split-MAC: Split-MAC support is optional, and allows the AC to receive and process native wireless frames. 2 - Both: WTP is capable of supporting both Local-MAC and Split- MAC. 5.1.5. WTP Frame Type The WTP Frame-Type message element allows the WTP to communicate its supported tunneling modes of operation to the AC. A WTP that advertises support for all modes allows the AC to dictate which mode whill be used, based on its local policy. 0 =20 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Frame Type | +-+-+-+-+-+-+-+-+ Type: TBD for WTP Frame Type Length: 1 Frame Type: The Frame type specifies the encapsulation modes supported by the WTP. The following values are supported 0 - Local Briding: Local Bridging allows the WTP to perform the bridging function. Note this value MUST NOT be used when the MAC Type is set to Split-MAC. 1 - 802.3 Bridging: 802.3 Bridging requires the WTP and AC to encapsulate all user payload as native 802.3 frames (see Section 4.2). Note this value MUST NOT be used when the MAC Type is set to Split-MAC. 2 - Native Bridging: Native Bridging requires the WTP and AC to encapsulate all user payloads as native wireless frames, as defined by the wireless binding (see Section 4.2). 3 - All: The WTP is capable of supporting all frame types. However, I have also allowed the message elements to be included in the Join Response, allowing the AC to specify which modes it wants the WTP to use. I have also included your proposed text under Configuration Consistency, but it is less clear to me that this specific text is mandatory, but would like to hear from others on whether they feel this helps clarify the protocol. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, December 22, 2005 8:43 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Local MAC Tunneling Mode =09 =09 Pat,=20 =20 Thank you for summarizing the major recommendations.=20 =09 The following is some proposed additions relating to the local MAC tunneling mode recommendation. In essence, it adds identifiers for the WTP variations and their modes of operation. I look forward to the WG's review on this. =20 =20 Section: 5.1 Discover Request=20 Type of change: Additional text after 1st paragraph, ("The Discovery Request is used by the WTP...") Proposal:=20 "The Discovery Request provides ACs with primary functionalities of the WTP. A WTP must exchange this information to ensure subsequent exchanges with the ACs are consistent with the WTP's functional characteristics." ------------------ =20 Section: 5 LWAPP Discovery Operations=20 Type of change: Additional message elements Proposal-1: "5.1.3 WTP MAC-Type The WTP MAC-Type message element distinguishes between local-MAC and split-MAC WTPs. It is used by the AC to determine subsequent exchanges with the WTP. Type:=20 Length: 1 MAC-Type: An 8-bits value indicating the type of MAC used by the WTP.=20 =20 The following values are supported: 0 - Split-MAC 1 - Local-MAC" =20 Proposal-2: "5.1.4 WTP Frame Type The WTP Frame Type message element is used to determine the nature of frames to be exchanged between the AC and WTP. Type:=20 Length: 1 Frame Type: An 8-bits value indicating the type of frames to be exchanged between the AC and WTP.=20 =20 The following values are supported: 0 - Native frames=20 1 - Tunneled frames (IEEE 802.3) 2 - No frames (local bridge at WTP)" --------------------- =20 Section: 7.1 Configuration Consistency=20 Type of change: Addition of sub-section to Section 7.1=20 Proposal:=20 "7.1.1 Configuration Flexibility "The protocol also provides the flexibility to configure and manage WTPs of varying design and functional characteristics. When a WTP first discovers an AC, it provides primary functional information relating to its type of MAC and to the nature of frames to be exchanged. The AC configures the WTP appropriately. The AC also establishes corresponding internal operations to deal with the WTP according to its functionalities." ---------------------- =20 It may be useful to use a figure to show how the modes are selected and what happens afterwards. I can help prepare one if there is agreement to do so. =09 Saravanan=20 =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 21:54:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzPwv-0000ku-VQ for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 21:54:58 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10337 for ; Wed, 18 Jan 2006 21:53:31 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CB6D3430135 for ; Wed, 18 Jan 2006 18:54:56 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 0675243009F for ; Wed, 18 Jan 2006 18:54:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC34E80C119 for ; Wed, 18 Jan 2006 18:54:31 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id 013BA80C121 for ; Wed, 18 Jan 2006 18:54:29 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2006 18:54:30 -0800 X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="393475053:sNHT31647216" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0J2sTQi002412; Wed, 18 Jan 2006 18:54:29 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 18:54:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 18:54:28 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437659@xmb-sjc-235.amer.cisco.com> Thread-Topic: PMK Sharing Thread-Index: AcYcmU+6qksdXfRCS8Sx+WQAWUWX3AACaS3w From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 02:54:29.0747 (UTC) FILETIME=[AACD5C30:01C61CA3] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Subject: [Capwap] RE: PMK Sharing X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I guess I will once more raise my concern that there is nothing specific about CAPWAP that changes how one implements 802.11, or 802.1X for that matter. Could I get a better understanding of why the eval team believe this statement is required in the CAPWAP protocol? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:40 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: PMK Sharing =09 =09 Pat, =20 Issue: In the case of an AC managing a same PMK across many WTPs, IEEE 802.11 stations cannot distinguish between PMKs that are validly shared and those that have been compromised (I0 of Issues/Recommendations). =20 My recommendation: Include text in the Security Considerations (draft-ohara-capwap-lwapp-03.txt) Section 15 along the lines; =20 "The CAPWAP protocol may be used in scenarios in which an AC manages a PMK across many WTPs. In such scenarios, IEEE 802.11 stations moving across WTPs cannot distinguish between PMKs that are legitimately shared and PMKs that have been compromised.=20 =20 The CAPWAP WG recognizes this ambiguity and recommends implementers of the protocol to review the outcome of IEEE 802.11r efforts for resolution." =20 =09 Saravanan=20 =20 =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 21:58:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQ00-0001a8-BJ for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 21:58:08 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10503 for ; Wed, 18 Jan 2006 21:56:41 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E2F494300D8 for ; Wed, 18 Jan 2006 18:58:06 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id B119543009F for ; Wed, 18 Jan 2006 18:57:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 93B89398027 for ; Wed, 18 Jan 2006 18:57:32 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by zoidberg.tigertech.net (Postfix) with ESMTP id AB574398008 for ; Wed, 18 Jan 2006 18:57:28 -0800 (PST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2006 18:57:27 -0800 X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208,217"; a="249907258:sNHT51672880" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0J2vRQJ013245; Wed, 18 Jan 2006 18:57:27 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 18:57:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 18:57:25 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A20143765A@xmb-sjc-235.amer.cisco.com> Thread-Topic: Default mode for logical groups Thread-Index: AcYcl5TWMIIGbIwiRmOufZe4zQIvuQADEECQ From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 02:57:27.0330 (UTC) FILETIME=[14A66020:01C61CA4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE Subject: [Capwap] RE: Default mode for logical groups X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1340850987==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1340850987== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA4.145ED4C5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA4.145ED4C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the e-mail. I recall this conversation, but I believe where I am getting confused is what we believe is missing.=20 =20 I believe we can agree that if *any* form of tunneling is occuring, then no mapping is required since VLANs will be enforced on the AC. Further, the protocol already has a provision to specify the VLAN to associate with a given user when Local MAC is used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:28 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Default mode for logical groups =09 =09 Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 =09 Saravanan ------_=_NextPart_001_01C61CA4.145ED4C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks=20 for the e-mail. I recall this conversation, but I believe where I am = getting=20 confused is what we believe is missing.

I=20 believe we can agree that if *any* form of tunneling is occuring, then = no=20 mapping is required since VLANs will be enforced on the AC. Further, the = protocol already has a provision to specify the VLAN to associate with a = given=20 user when Local MAC is used.

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Wednesday,=20 January 18, 2006 5:28 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: Default mode for logical=20 groups

Pat,

Issue:=20

Assign a default mode = for=20 configuring logical groups (draft-ietf-capwap-objectives-04.txt) = Section 5.1.1=20 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless = segments.=20 This makes for consistent configuration and management across logical = groups.=20

My=20 recommendation:

Introduce a message = element in the=20 WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 = to map=20 wired-segment VLANs to wireless-segment BSSIDs. This is the simplest = and most=20 common case for logical groups.

Then include description = of=20 logical group configuration in BSSID to WLAN ID Mapping=20 (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20

Saravanan

------_=_NextPart_001_01C61CA4.145ED4C5-- --===============1340850987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1340850987==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 22:05:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQ6h-0003jC-QS for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:05:03 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10860 for ; Wed, 18 Jan 2006 22:03:36 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 5C33F4300C5 for ; Wed, 18 Jan 2006 19:05:02 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id A413B43008F for ; Wed, 18 Jan 2006 19:04:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id CEFE1398008 for ; Wed, 18 Jan 2006 19:04:02 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 292BB398022 for ; Wed, 18 Jan 2006 19:03:57 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 19:03:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0J33tjt006577; Wed, 18 Jan 2006 19:03:55 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 19:03:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 19:03:54 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437660@xmb-sjc-235.amer.cisco.com> Thread-Topic: Firmware Trigger Thread-Index: AcYclg78tR1+2HsGTVCSJJCCN1yIwwADuEjg From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 03:03:55.0755 (UTC) FILETIME=[FC2B53B0:01C61CA4] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE Subject: [Capwap] RE: Firmware Trigger X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1838307097==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1838307097== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA4.FBED6D9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA4.FBED6D9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would have thought that the group would want it after the Run state, no?=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Firmware Trigger =09 =09 Pat, =20 Issue: The Evaluation draft (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of firmware checks and updates independent of other operations.=20 =20 My recommendation: To introduce a Firmware-Update state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section 2.2. =20 Saravanan ------_=_NextPart_001_01C61CA4.FBED6D9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I=20 would have thought that the group would want it after the Run state, no? =

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Wednesday,=20 January 18, 2006 5:17 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: Firmware = Trigger

Pat,

Issue: The Evaluation = draft=20 (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state = machine to=20 support triggering of firmware checks and updates independent of other = operations.

My recommendation: To = introduce a=20 Firmware-Update state after the Configure state=20 (draft-ohara-capwap-lwapp-03.txt) in Section = 2.2.

Saravanan

------_=_NextPart_001_01C61CA4.FBED6D9D-- --===============1838307097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1838307097==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 22:06:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQ7t-0004Vi-KM for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:06:17 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10912 for ; Wed, 18 Jan 2006 22:04:50 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E587043010A for ; Wed, 18 Jan 2006 19:06:15 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 310094300C5 for ; Wed, 18 Jan 2006 19:05:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1AC9F80C119 for ; Wed, 18 Jan 2006 19:05:09 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 1B90A80C0F7 for ; Wed, 18 Jan 2006 19:05:04 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J352ce010066; Thu, 19 Jan 2006 12:05:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k0J354m04625; Thu, 19 Jan 2006 12:05:04 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with SMTP id k0J354J16806; Thu, 19 Jan 2006 12:05:04 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 11:05:54 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E3816@pslexc01.psl.local> Thread-topic: Local-MAC & Split-MAC Negotiations Thread-index: AcYcpUMf740yQ5RlQquDnQJZAhQclw== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] Local-MAC & Split-MAC Negotiations X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590418790==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1590418790== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA5.0F7C5507" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA5.0F7C5507 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Issue: The CAPWAP protocol is expected to support major WTP designs. It is important for information on these design types to be exchanged during configuration so that subsequent protocol operations are consistent and accurate.=20 =20 My recommendation: To specify WTP characteristics as part of Discovery state (draft-ohara-capwap-lwapp-03.txt) Section 5. The following message elements to be included to Discovery Request (draft-ohara-capwap-lwapp-03.txt) Section 5.1; =20 MAC Type - Split-MAC, Local-MAC MAC Frame Type - Native (IEEE 802.11), IEEE 802.3, No frames (local bridging) IEEE 802.11i Design - Encryption & Authenticator on same entity, Encryption on WTP & Authenticator on AC =20 =20 =20 Saravanan=20 ------_=_NextPart_001_01C61CA5.0F7C5507 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

Issue:

The CAPWAP protocol is expected to support major WTP designs. It is important for information on these design types to be = exchanged during configuration so that subsequent protocol operations are = consistent and accurate.

My recommendation:

To specify WTP characteristics as part of Discovery = state (draft-ohara-capwap-lwapp-03.txt) Section 5. The following message elements to be included to Discovery = Request (draft-ohara-capwap-lwapp-03.txt) Section 5.1;

MAC Type – Split-MAC, = Local-MAC

MAC Frame Type – Native (IEEE 802.11), IEEE = 802.3, No frames (local bridging)

IEEE 802.11i Design – Encryption & = Authenticator on same entity, Encryption on WTP & Authenticator on = AC

Saravanan

------_=_NextPart_001_01C61CA5.0F7C5507-- --===============1590418790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1590418790==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 22:16:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQHc-0007qZ-Tu for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:16:21 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11489 for ; Wed, 18 Jan 2006 22:14:53 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 368D743011F for ; Wed, 18 Jan 2006 19:16:19 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 4265C43006D for ; Wed, 18 Jan 2006 19:15:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3542480C10C for ; Wed, 18 Jan 2006 19:15:41 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 17DCC80C0F7 for ; Wed, 18 Jan 2006 19:15:39 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id k0J3FbD1001319; Thu, 19 Jan 2006 12:15:37 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k0J3Fd516723; Thu, 19 Jan 2006 12:15:39 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id k0J3FcG14162; Thu, 19 Jan 2006 12:15:38 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 11:16:31 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E381F@pslexc01.psl.local> Thread-topic: Default mode for logical groups Thread-index: AcYcl5TWMIIGbIwiRmOufZe4zQIvuQADEECQAACAcEA= From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] RE: Default mode for logical groups X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2109756993==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============2109756993== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA6.891DADCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA6.891DADCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 I see your point.=20 =20 My concern is with the operation of the consistent operation of the protocol. So if we were to design in such a way that each logical group - or WLAN - is a VLAN + a BSSID, then it makes configuring local-MAC and split-MAC WTPs similar.=20 =20 I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical group configuration works is a common way for local-MAC and split-MAC WTPs. =20 Do you think this is the case? Saravanan=20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 10:57 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 Thanks for the e-mail. I recall this conversation, but I believe where I am getting confused is what we believe is missing.=20 =20 I believe we can agree that if *any* form of tunneling is occuring, then no mapping is required since VLANs will be enforced on the AC. Further, the protocol already has a provision to specify the VLAN to associate with a given user when Local MAC is used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:28 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Default mode for logical groups Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 =09 Saravanan ------_=_NextPart_001_01C61CA6.891DADCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

I see your point.

My concern is with the operation of the consistent = operation of the protocol. So if we were to design in such a way that each logical = group - or WLAN - is a VLAN + a BSSID, then it makes configuring local-MAC = and split-MAC WTPs similar.

I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical = group configuration works is a common way for local-MAC and split-MAC = WTPs.

Do you think this is the case?

Saravanan

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 10:57 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: RE: Default mode = for logical groups

Thanks for the e-mail. I recall = this conversation, but I believe where I am getting confused is what we = believe is missing.

I believe we can agree that if = *any* form of tunneling is occuring, then no mapping is required since VLANs will = be enforced on the AC. Further, the protocol already has a provision to = specify the VLAN to associate with a given user when Local MAC is = used.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January = 18, 2006 5:28 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: Default mode for = logical groups

Pat,

Issue:

Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. = This makes for consistent configuration and management across logical groups. =

My recommendation:

Introduce a message element in the WLAN Config = message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment = VLANs to wireless-segment BSSIDs. This is the simplest and most common case for = logical groups.

Then include description of logical group = configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section = 11.4).

Saravanan

------_=_NextPart_001_01C61CA6.891DADCB-- --===============2109756993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2109756993==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 22:19:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQL0-00009z-Q1 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:19:52 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11737 for ; Wed, 18 Jan 2006 22:18:23 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id B9A3F430128 for ; Wed, 18 Jan 2006 19:19:36 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 0C92F43006D for ; Wed, 18 Jan 2006 19:18:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D83E7398023 for ; Wed, 18 Jan 2006 19:18:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id C6013398027 for ; Wed, 18 Jan 2006 19:18:19 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 19:18:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0J3IJWF020257; Wed, 18 Jan 2006 19:18:19 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 19:18:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2006 19:18:17 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437666@xmb-sjc-235.amer.cisco.com> Thread-Topic: Default mode for logical groups Thread-Index: AcYcl5TWMIIGbIwiRmOufZe4zQIvuQADEECQAACAcEAAADoTAA== From: "Pat Calhoun (pacalhou)" To: "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 03:18:19.0422 (UTC) FILETIME=[FEF473E0:01C61CA6] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.375 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE Subject: [Capwap] RE: Default mode for logical groups X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0180540668==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0180540668== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CA6.FEBC4C72" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CA6.FEBC4C72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the crux of the problem is that in Local MAC the bridging function is provided by the WTP, and therefore it needs a VLAN. However, pushing this to a WTP when bridging is performed in the AC would be pointless since the WTP is never connected to a trunk. Unfortunately, by relocating the bridging function, there is no way to make this common :( =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 7:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Default mode for logical groups =09 =09 Pat, =20 I see your point.=20 =20 My concern is with the operation of the consistent operation of the protocol. So if we were to design in such a way that each logical group - or WLAN - is a VLAN + a BSSID, then it makes configuring local-MAC and split-MAC WTPs similar.=20 =20 I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical group configuration works is a common way for local-MAC and split-MAC WTPs. =20 Do you think this is the case? =09 Saravanan=20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 10:57 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 Thanks for the e-mail. I recall this conversation, but I believe where I am getting confused is what we believe is missing.=20 =20 I believe we can agree that if *any* form of tunneling is occuring, then no mapping is required since VLANs will be enforced on the AC. Further, the protocol already has a provision to specify the VLAN to associate with a given user when Local MAC is used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:28 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Default mode for logical groups Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 =09 Saravanan ------_=_NextPart_001_01C61CA6.FEBC4C72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I=20 think the crux of the problem is that in Local MAC the bridging function = is=20 provided by the WTP, and therefore it needs a VLAN. However, pushing = this to a=20 WTP when bridging is performed in the AC would be pointless since the = WTP is=20 never connected to a trunk. Unfortunately, by relocating the bridging = function,=20 there is no way to make this common :(

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: = Wednesday,=20 January 18, 2006 7:17 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: Default mode for logical=20 groups

Pat,

I see your point.=20

My concern is with the = operation=20 of the consistent operation of the protocol. So if we were to design = in such a=20 way that each logical group - or WLAN - is a VLAN + a BSSID, = then it=20 makes configuring local-MAC and split-MAC WTPs similar.=20

I think the current = protocol=20 already does what we are talking about in some form. It would be nice = to bring=20 out how logical group configuration works is a common way for = local-MAC and=20 split-MAC WTPs.

Do you think this is the = case?

Saravanan

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January 19, = 2006 10:57=20 AM
To: = Saravanan Govindan; = capwap@frascone.com
Subject: RE: Default mode for = logical=20 groups

Thanks for = the=20 e-mail. I recall this conversation, but I believe where I am getting = confused=20 is what we believe is missing.

I believe = we can=20 agree that if *any* form of tunneling is occuring, then no mapping is = required=20 since VLANs will be enforced on the AC. Further, the protocol already = has a=20 provision to specify the VLAN to associate with a given user when = Local MAC is=20 used.

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

From:=20 Saravanan Govindan=20 [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January 18, = 2006 5:28=20 PM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: Default mode for = logical=20 groups

Pat,

Issue:=20

Assign a default mode = for=20 configuring logical groups (draft-ietf-capwap-objectives-04.txt) = Section=20 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and = wireless=20 segments. This makes for consistent configuration and management = across=20 logical groups.

My=20 recommendation:

Introduce a message = element in=20 the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section = 11.8.2 to=20 map wired-segment VLANs to wireless-segment BSSIDs. This is the = simplest and=20 most common case for logical groups.

Then include = description of=20 logical group configuration in BSSID to WLAN ID Mapping=20 (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20

Saravanan

------_=_NextPart_001_01C61CA6.FEBC4C72-- --===============0180540668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0180540668==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Wed Jan 18 22:30:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQVX-0003q6-M3 for capwap-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:30:44 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12534 for ; Wed, 18 Jan 2006 22:29:16 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C47D430129 for ; Wed, 18 Jan 2006 19:30:42 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 8311843006D for ; Wed, 18 Jan 2006 19:30:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 73D9B80C114 for ; Wed, 18 Jan 2006 19:30:19 -0800 (PST) Received: from flyer.cs.umd.edu (flyer.cs.umd.edu [128.8.128.178]) by hermes.tigertech.net (Postfix) with ESMTP id 96BE280C10C for ; Wed, 18 Jan 2006 19:30:16 -0800 (PST) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by flyer.cs.umd.edu (8.12.11/8.12.5) with ESMTP id k0J3U2hF026233; Wed, 18 Jan 2006 22:30:02 -0500 Date: Wed, 18 Jan 2006 22:28:03 -0500 (EST) From: "T. Charles Clancy" X-X-Sender: clancy@ismene To: Saravanan Govindan Subject: Re: [Capwap] PMK Sharing In-Reply-To: <5F09D220B62F79418461A978CA0921BD9E37C4@pslexc01.psl.local> Message-ID: References: <5F09D220B62F79418461A978CA0921BD9E37C4@pslexc01.psl.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com On Thu, 19 Jan 2006, Saravanan Govindan wrote: > Issue: > > In the case of an AC managing a same PMK across many WTPs, IEEE 802.11 > stations cannot distinguish between PMKs that are validly shared and > those that have been compromised (I0 of Issues/Recommendations). It was my impression that the PMK would never be transported from the AC to the WTPs. The AC transports the *PTK* to the WTPs in the add mobile message. Since the 802.11i four-way handshake is re-executed after each handoff, a fresh PTK is used in each add mobile message. So, I still don't understand why PMK sharing is something people are concerned about. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 00:22:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSFJ-00076o-SR for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 00:22:05 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19901 for ; Thu, 19 Jan 2006 00:20:35 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 691D2430108 for ; Wed, 18 Jan 2006 21:21:59 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id BF04543006D for ; Wed, 18 Jan 2006 21:21:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AEB2F80C0F7 for ; Wed, 18 Jan 2006 21:21:14 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 6D08D80C113 for ; Wed, 18 Jan 2006 21:21:13 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0J5L8ce012406; Thu, 19 Jan 2006 14:21:08 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k0J5L8506667; Thu, 19 Jan 2006 14:21:08 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/indians) with SMTP id k0J5L9803202; Thu, 19 Jan 2006 14:21:09 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 13:21:59 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E3864@pslexc01.psl.local> Thread-topic: WGLC timeline for Evaluation draft Thread-index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3A== From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] WGLC timeline for Evaluation draft X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105592111==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1105592111== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CB8.10271ED6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CB8.10271ED6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 This is a general issue for the WG milestones. I wanted to get the group's input on it, so I was hoping you could help add it to the issues-tracker for resolution. =20 =20 Issue: The proposed timeline for WGLC on the Evaluation draft is January 2006. However, as I went through the presentation on the Comparative Analysis draft (draft-gwee-capwap-comparative-analysis-00) from the last meeting, I notice that there a number of important points that are currently not in the Evaluation draft. Particularly, there are issues regarding joint wireless and VLAN Resource Control (Slide 7) and structured approach to Logical Groups (Slide 6) of the IETF64 CAPWAP Comparative Analysis presentation.=20 =20 While some of these have been included in the issues list, I think would be good to formalize them so as to make it easier during protocol development.=20 =20 =20 My recommendation: To have discussions on the key recommendations of the Comparative Analysis draft and then incorporate them in the final Evaluation draft based on consensus.=20 =20 So extending the timeline for the WGLC on the draft would help in this direction.=20 =20 =20 Thanks, Saravanan=20 ------_=_NextPart_001_01C61CB8.10271ED6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pat,

This is a general issue for the WG milestones. I = wanted to get the group’s input on it, so I was hoping you could help add it = to the issues-tracker for resolution.

Issue:

The proposed timeline for WGLC on the Evaluation = draft is January 2006. However, as I went through the presentation on the Comparative = Analysis draft (draft-gwee-capwap-comparative-analysis-00) from the last meeting, = I notice that there a number of important points that are currently not in = the Evaluation draft. Particularly, there are issues regarding joint = wireless and VLAN Resource Control (Slide 7) and structured approach to Logical = Groups (Slide 6) of the IETF64 CAPWAP Comparative Analysis presentation. =

While some of these have been included in the issues = list, I think would be good to formalize them so as to make it easier during = protocol development.

My recommendation:

To have discussions on the key recommendations of the Comparative Analysis draft and then incorporate them in the final = Evaluation draft based on consensus.

So extending the timeline for the WGLC on the draft = would help in this direction.

Thanks,

Saravanan

------_=_NextPart_001_01C61CB8.10271ED6-- --===============1105592111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1105592111==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 01:05:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzSvC-0003J3-V9 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 01:05:24 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21984 for ; Thu, 19 Jan 2006 01:03:56 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D1D494300DB for ; Wed, 18 Jan 2006 22:05:20 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id C156343006D for ; Wed, 18 Jan 2006 22:04:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 443CE398037 for ; Wed, 18 Jan 2006 22:04:33 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 95642398027 for ; Wed, 18 Jan 2006 22:04:28 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id k0J64PKb008608; Thu, 19 Jan 2006 15:04:25 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k0J64Q212789; Thu, 19 Jan 2006 15:04:26 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k0J64R906601; Thu, 19 Jan 2006 15:04:27 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 19 Jan 2006 14:05:17 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD9E3897@pslexc01.psl.local> Thread-topic: Default mode for logical groups Thread-index: AcYcl5TWMIIGbIwiRmOufZe4zQIvuQADEECQAACAcEAAADoTAAAFXYug From: "Saravanan Govindan" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE Subject: [Capwap] RE: Default mode for logical groups X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1302642896==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1302642896== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CBE.1BF45791" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CBE.1BF45791 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 My point here is not with the location of the bridging function, rather the way the protocol manages logical groups in general.=20 =20 It is a need arising from two objectives (draft-ietf-objectives-04) - Logical Groups (Section 5.1.1) and Resource Control Objective (5.1.7). So the need is to provide logical subsets - with the ability to manage resources on both wireless segment and the wired segment. I see this as requiring a type of mapping between the wired segment, say VLAN, and wireless segment, say BSSID.=20 =20 So even in the case of an AC doing bridging, it needs to be able to configure its WTPs so that the WTPs can map between the right wired segment VLAN and right wireless segment BSSID.=20 I think this can be provided by including a configuration element for the WTP, which maps VLAN to BSSID for each of the logical groups being configured in the WLAN system.=20 =20 I'm open to any other ways of realizing these two objectives.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 11:18 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 I think the crux of the problem is that in Local MAC the bridging function is provided by the WTP, and therefore it needs a VLAN. However, pushing this to a WTP when bridging is performed in the AC would be pointless since the WTP is never connected to a trunk. Unfortunately, by relocating the bridging function, there is no way to make this common :( =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 7:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Default mode for logical groups Pat, =20 I see your point.=20 =20 My concern is with the operation of the consistent operation of the protocol. So if we were to design in such a way that each logical group - or WLAN - is a VLAN + a BSSID, then it makes configuring local-MAC and split-MAC WTPs similar.=20 =20 I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical group configuration works is a common way for local-MAC and split-MAC WTPs. =20 Do you think this is the case? =09 Saravanan=20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 10:57 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 Thanks for the e-mail. I recall this conversation, but I believe where I am getting confused is what we believe is missing.=20 =20 I believe we can agree that if *any* form of tunneling is occuring, then no mapping is required since VLANs will be enforced on the AC. Further, the protocol already has a provision to specify the VLAN to associate with a given user when Local MAC is used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:28 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Default mode for logical groups Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 =09 Saravanan ------_=_NextPart_001_01C61CBE.1BF45791 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pat,

My point here is not with the location of the = bridging function, rather the way the protocol manages logical groups in general. =

It is a need arising from two objectives (draft-ietf-objectives-04) – Logical Groups (Section 5.1.1) and = Resource Control Objective (5.1.7). So the need is to provide logical subsets = – with the ability to manage resources on both wireless segment and the = wired segment. I see this as requiring a type of mapping between the wired = segment, say VLAN, and wireless segment, say BSSID.

So even in the case of an AC doing bridging, it needs = to be able to configure its WTPs so that the WTPs can map between the right = wired segment VLAN and right wireless segment BSSID.

I think this can be provided by including a configuration element for = the WTP, which maps VLAN to BSSID for each of the logical groups being configured = in the WLAN system.

I’m open to any other ways of realizing these = two objectives.

Saravanan

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 11:18 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: RE: Default mode = for logical groups

I think the crux of the problem is = that in Local MAC the bridging function is provided by the WTP, and therefore it = needs a VLAN. However, pushing this to a WTP when bridging is performed in the = AC would be pointless since the WTP is never connected to a trunk. = Unfortunately, by relocating the bridging function, there is no way to make this common = :(

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January = 18, 2006 7:17 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: RE: Default mode = for logical groups

Pat,

I see your point.

My concern is with the operation of the consistent = operation of the protocol. So if we were to design in such a way that each logical = group - or WLAN - is a VLAN + a BSSID, then it makes configuring = local-MAC and split-MAC WTPs similar.

I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical = group configuration works is a common way for local-MAC and split-MAC = WTPs.

Do you think this is the case?

Saravanan

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 10:57 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: RE: Default mode = for logical groups

Thanks for the e-mail. I recall = this conversation, but I believe where I am getting confused is what we = believe is missing.

I believe we can agree that if = *any* form of tunneling is occuring, then no mapping is required since VLANs will = be enforced on the AC. Further, the protocol already has a provision to = specify the VLAN to associate with a given user when Local MAC is = used.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January = 18, 2006 5:28 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: Default mode for = logical groups

Pat,

Issue:

Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. = This makes for consistent configuration and management across logical groups. =

My recommendation:

Introduce a message element in the WLAN Config = message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment = VLANs to wireless-segment BSSIDs. This is the simplest and most common case for = logical groups.

Then include description of logical group = configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section = 11.4).

Saravanan

------_=_NextPart_001_01C61CBE.1BF45791-- --===============1302642896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1302642896==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 05:19:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWsk-0008Ao-31 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 05:19:06 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08710 for ; Thu, 19 Jan 2006 05:17:37 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E9C5E430119 for ; Thu, 19 Jan 2006 02:19:03 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 6FC1343006D for ; Thu, 19 Jan 2006 02:18:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 535B6398022 for ; Thu, 19 Jan 2006 02:18:32 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by zoidberg.tigertech.net (Postfix) with ESMTP id 26178398040 for ; Thu, 19 Jan 2006 02:18:29 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 11:18:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jan 2006 11:18:26 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B003486660@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Questions regarding LWAPP draft v03 Thread-Index: AcYc4a+gr9vzgFp2Q/SRfBE/LCm2FA== From: "BOURDON Gilles RD-CORE-ISS" To: X-OriginalArrivalTime: 19 Jan 2006 10:18:27.0295 (UTC) FILETIME=[B0049EF0:01C61CE1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.431 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_30_40, HTML_MESSAGE Subject: [Capwap] Questions regarding LWAPP draft v03 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1597695787==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1597695787== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61CE1.AFEF4239" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61CE1.AFEF4239 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I read the LWAPP draft, and I have questions/comments (maybe already addressed, but I did not find any trace of that): 1- The Control Message format (section 4.2.1) indicates the message type is 8-bit encoded. Don't you think this numbering space could be too small, for further extensions? The section might also mention how this numbering space is managed (IANA?). Same thing for section 4.2.2. (Message Element Format), refering to section 16 which is empty. 2- I know that the evaluation team asked for an extension of the Type field. It might seem obvious, but I think that having its length equal to the Element ID field of the Vendor-Specific element would make sense. 3- I cannot figure out why Clear Config Indication is the only message that doesn't need acknowledgment from the WTP. Any particular reason? Gilles. ------_=_NextPart_001_01C61CE1.AFEF4239 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions regarding LWAPP draft v03

Hi all,

I read the LWAPP draft, and I have = questions/comments (maybe already addressed, but I did not find any = trace of that):

1- The Control Message format (section = 4.2.1) indicates the message type is 8-bit encoded. Don't you think this = numbering space could be too small, for further extensions? The section = might also mention how this numbering space is managed (IANA?). Same = thing for section 4.2.2. (Message Element Format), refering to section = 16 which is empty.

2- I know that the evaluation team = asked for an extension of the Type field. It might seem obvious, but I = think that having its length equal to the Element ID field of the = Vendor-Specific element would make sense.

3- I cannot figure out why Clear Config = Indication is the only message that doesn't need acknowledgment from the = WTP. Any particular reason?

Gilles.

------_=_NextPart_001_01C61CE1.AFEF4239-- --===============1597695787== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1597695787==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 07:09:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYbL-0008CA-4q for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 07:09:15 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15645 for ; Thu, 19 Jan 2006 07:07:48 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4D6364300B0 for ; Thu, 19 Jan 2006 04:09:13 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id E6E7443005A for ; Thu, 19 Jan 2006 04:08:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CE05880C12B for ; Thu, 19 Jan 2006 04:08:45 -0800 (PST) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by hermes.tigertech.net (Postfix) with ESMTP id 23EFD80C114 for ; Thu, 19 Jan 2006 04:08:37 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITC00HZT9VI40@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 19 Jan 2006 20:11:42 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITC00INS9VIOQ@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 19 Jan 2006 20:11:42 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITC0092XA4NTF@szxml01-in.huawei.com>; Thu, 19 Jan 2006 20:17:13 +0800 (CST) Date: Thu, 19 Jan 2006 17:32:13 +0530 From: sujay Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP In-reply-to: <12F9AA6C-7C82-4BFC-9A19-A644ACD662C8@u4eatech.com> To: "'Philip Rakity'" , "'Pat Calhoun (pacalhou)'" Message-id: <000001c61cf0$2faacf90$3904120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT Hi, Albeit a late reply; See SUJ>> below; -----Original Message----- From: Philip Rakity [mailto:philip.rakity@u4eatech.com] Sent: Thursday, January 19, 2006 3:00 AM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Re: [Capwap] Comments on Draft 3 -- LWAPP Comments belowl On Jan 18, 2006, at 12:23 PM, Pat Calhoun (pacalhou) wrote: >>> >>> >>> h) Page 65 -- Blacklist Entry's -- This whole area is not good from >>> my point of view. When I configure a firewall I say what is allowed >>> (explicitly) and forbid everything else -- there is no way I can >>> give a >>> list of trusted stations and forbid everything else. This >> makes live >>> very difficult. There is room for a blacklist -- but an allowed >>> list is also needed. >>> >>> >>> Suj> In my opinion blacklisting is to prevent any .11 mgt >> frames from >>> passing upto the AC for the current WTP-AC session. >>> - to blacklist one MAC address and allow others is more exact and >>> specific rather than knowing ALL those which are Allowed, either way >>> the one which is allowed will is kept >> the Radius, >>> you could put your 'allowed' list there ! >> >> I think there is a use for BOTH cases. in a secure environment I do >> not want control frames from rogue AP's. > > Looks like we are still not in complete agreement on this one. Typical > 802.11 Devices include an approved list (known as MAC Filter). It is > assumed that this > function is provided w/o CAPWAP involvement, while a blacklist is > provided > by CAPWAP. If I understsand correct, you would like a replicated > set of > messages > to serve as the permit list? Do others agree? Yes -- My Point. In a secure environment I want to say what is allowed and forbid other things. SUJ>> AFAIK it should be best suited on the 'default' mode of 802.11 Device behaviour , if it blocks ALL, use a permit list. If it allows ALL , use a deny list. Possibly the default mode is allow ALL ! > >>> >>> >>> i) Page 70 -- Image Data -- do not understand how this can work -- >>> only 2 fragments allowed -- no count of what is being sent etc >> -- no way to >>> detect packet loss --- why not use data xfer mechanism of >> tftp ? -- >>> the blocks are numbered == etc BUT define a md5 hash of the whole >>> image and give its length in the initial request. >>> >>> Suj> LWAPP has the in-band Image transfer mechanism, some >> protocols >>> use >>> what you have specified. >>> >> >> I do not understand how this can work as defined in the text. I >> understand I could overlay it but it needs a definition. > > Could you help identify what needs a definition? I did not understand (and now do) how this mechanism works. But I do not understand how one knows the transfer is finished? Is there also another end-case to know if the xfer is beginning ? SUJ>> it is by the length of Image Data , iff less than 1024 indicates operation over, else if the op-code indicates a failure. > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > Philip Rakity prakity@u4eatech.com This message is hereby marked U4EA CONFIDENTIAL, is intended only for the use of the individual or individuals to which it is addressed and shall notbe disclose or made available to any other party except with the prior written consent of the sender. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail. _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 07:10:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYcH-0008PS-Tj for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 07:10:13 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15697 for ; Thu, 19 Jan 2006 07:08:47 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7C6914300B4 for ; Thu, 19 Jan 2006 04:10:12 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 6958343005A for ; Thu, 19 Jan 2006 04:08:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5E70A80C103 for ; Thu, 19 Jan 2006 04:08:47 -0800 (PST) Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by hermes.tigertech.net (Postfix) with ESMTP id 5F43F80C127 for ; Thu, 19 Jan 2006 04:08:44 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITC00HPKA6940@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 19 Jan 2006 20:18:10 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITC00IXJA69OQ@szxga01-in.huawei.com> for capwap@frascone.com; Thu, 19 Jan 2006 20:18:09 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITC009UBAFFTF@szxml01-in.huawei.com>; Thu, 19 Jan 2006 20:23:40 +0800 (CST) Date: Thu, 19 Jan 2006 17:38:40 +0530 From: sujay Subject: RE: [Capwap] RE: Firmware Trigger In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A201437660@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" , "'Saravanan Govindan'" , capwap@frascone.com Message-id: <000101c61cf1$16739f10$3904120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0448342537==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0448342537== Content-type: multipart/alternative; boundary="Boundary_(ID_eZ7ESKJX6djPrv5J1V253g)" This is a multi-part message in MIME format. --Boundary_(ID_eZ7ESKJX6djPrv5J1V253g) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT My recommendation would be to keep it as a trigger message allowed only in the Run state. Sujay -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, January 19, 2006 8:34 AM To: Saravanan Govindan; capwap@frascone.com Subject: [Capwap] RE: Firmware Trigger I would have thought that the group would want it after the Run state, no? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, January 18, 2006 5:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Firmware Trigger Pat, Issue: The Evaluation draft (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of firmware checks and updates independent of other operations. My recommendation: To introduce a Firmware-Update state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section 2.2. Saravanan --Boundary_(ID_eZ7ESKJX6djPrv5J1V253g) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message

My recommendation would be to keep it as a

trigger message allowed only in the Run state.

Sujay

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January 19, 2006 8:34 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: [Capwap] RE: Firmware Trigger

I would have thought that the group would want it after the Run state, no?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January 18, 2006 5:17 PM
To: Pat Calhoun (pacalhou); capwap@frascone.com
Subject: Firmware Trigger

Pat,

Issue: The Evaluation draft (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of firmware checks and updates independent of other operations.

My recommendation: To introduce a Firmware-Update state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section 2.2.

Saravanan

--Boundary_(ID_eZ7ESKJX6djPrv5J1V253g)-- --===============0448342537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0448342537==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 10:42:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbvy-0002Fx-Fr for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 10:42:46 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01730 for ; Thu, 19 Jan 2006 10:41:14 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 6D9034300DB for ; Thu, 19 Jan 2006 07:42:40 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 74E0443005A for ; Thu, 19 Jan 2006 07:42:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 5CF99398025 for ; Thu, 19 Jan 2006 07:42:16 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 6049B39800B for ; Thu, 19 Jan 2006 07:42:06 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0JFZZPO028225 for ; Thu, 19 Jan 2006 10:35:35 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 19 Jan 2006 10:41:59 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 19 Jan 2006 10:41:59 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Jan 2006 10:41:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Thu, 19 Jan 2006 10:41:59 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B7BF@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsg From: "Nelson, David" To: X-OriginalArrivalTime: 19 Jan 2006 15:41:59.0664 (UTC) FILETIME=[E2B10F00:01C61D0E] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Saravanan Govindan writes... > To have discussions on the key recommendations of the=20 > Comparative Analysis draft and then incorporate them in > the final Evaluation draft based on consensus. With all due respect, the Evaluation Team draft (and eventual Informational RFC) documents the proceedings and findings of the CAPWAP WG Evaluation Team, during a specific period of time when the Eval Team was in operation. The draft is intended to accurately reflect that process, as an historical record. The recommendations of the Eval Team are not binding upon the WG. However, the WG is not expected to *revise* the record of the Eval Team proceedings, except to correct errors of fact. For that reason, adding substantive comments and recommendations, that did not come from the Eval Team proceedings, into the Eval Team draft would not be appropriate. Regards, Dave =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 11:23:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcZK-00013D-73 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 11:23:26 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB04332 for ; Thu, 19 Jan 2006 11:21:57 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 79D13430109 for ; Thu, 19 Jan 2006 08:23:24 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 7269F43005A for ; Thu, 19 Jan 2006 08:22:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5A8B780C0F7 for ; Thu, 19 Jan 2006 08:22:53 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 8A27580C114 for ; Thu, 19 Jan 2006 08:22:51 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2006 08:22:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0JGMojt007259; Thu, 19 Jan 2006 08:22:51 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 08:22:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] RE: Firmware Trigger Date: Thu, 19 Jan 2006 08:22:49 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437712@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] RE: Firmware Trigger Thread-Index: AcYclg78tR1+2HsGTVCSJJCCN1yIwwADuEjgAAF9XBA= From: "Pat Calhoun (pacalhou)" To: "Pat Calhoun (pacalhou)" , "Saravanan Govindan" , X-OriginalArrivalTime: 19 Jan 2006 16:22:50.0762 (UTC) FILETIME=[97A8EEA0:01C61D14] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable The following state machine is the result of the requested change to allow for firmware to be triggered while in the run state. I've had to change much of the figure in order to allow for an ackward ASCII state machine to be able to take into account the new state transition, and do believe I have it correct, but will spend more time later this week verifying it once more. /-------------\ | v | +------------+ | C| Idle |<--------------------------------------\ | +------------+<--------------------------\ | | ^ |a ^ | | | | | | +------------+ 5 +------------+ | | | | | | Key Update |------->| Key Confirm| | | | | | +------------+ +------------+ | | | | | ^ | | | | | | | u |w | | | | | \------\ | | | | | |y | v t | | | | +------------+ +------------+------/ | / | | Reset |<-------| Run |C | / | r+-----------+ s +------------+ | / | ^ ^ 7| ^ | | v | \ | p | | | +--------------+ o| ---------+------\ q| | | C| Discovery | | V +-----------+ | | b+--------------+ +-------------+ | Configure | | | |d f| ^ C| Image Data |--->+-----------+ | | | | | n+-------------+p ^ | |e v | | ^ ^ | | +---------+ v |i |m 4| 2| | C| Sulking | +--------------+ +--------------+ | +---------+ C| Join |--->| Join-Confirm | | g+--------------+z +--------------+ | |h 3| \------------------/ | \------------------------------------/=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Pat Calhoun (pacalhou)=20 Sent: Wednesday, January 18, 2006 7:04 PM To: Saravanan Govindan; capwap@frascone.com Subject: [Capwap] RE: Firmware Trigger =09 =09 I would have thought that the group would want it after the Run state, no?=20 =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Firmware Trigger =09 =09 Pat, =20 Issue: The Evaluation draft (draft-ietf-capwap-eval-00.txt) in Section 6.5 recommends the state machine to support triggering of firmware checks and updates independent of other operations.=20 =20 My recommendation: To introduce a Firmware-Update state after the Configure state (draft-ohara-capwap-lwapp-03.txt) in Section 2.2. =20 Saravanan _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 11:45:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcuy-00081W-Nt for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 11:45:51 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05978 for ; Thu, 19 Jan 2006 11:44:19 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0B12B43017C for ; Thu, 19 Jan 2006 08:45:46 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id AC470430149 for ; Thu, 19 Jan 2006 08:45:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9806080C127 for ; Thu, 19 Jan 2006 08:45:15 -0800 (PST) Received: from pop-tawny.atl.sa.earthlink.net (pop-tawny.atl.sa.earthlink.net [207.69.195.67]) by hermes.tigertech.net (Postfix) with ESMTP id 94BBB80C006 for ; Thu, 19 Jan 2006 08:45:13 -0800 (PST) Received: from elwamui-darkeyed.atl.sa.earthlink.net ([209.86.224.33]) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EzcuO-0002Qt-00 for capwap@frascone.com; Thu, 19 Jan 2006 11:45:12 -0500 Message-ID: <5999516.1137689112339.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Thu, 19 Jan 2006 08:45:12 -0800 (GMT-08:00) From: "Scott G. Kelly" To: capwap Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] DTLS X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Scott G. Kelly" List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit The eval team recommended that DTLS be used to secure the CAPWAP protocol, and several others have been suggesting this same thing for some time now. Two revisions of a draft explaining how to do this have been published - the first elicited a few minor comments, and the second (modified to reflect those comments) has drawn no fire. Are we done with this discussion? If so, let's get DTLS incorporated into the next rev of the draft. If not, let's hear why not. --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 13:17:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeLz-0005Ei-Ct for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 13:17:47 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12946 for ; Thu, 19 Jan 2006 13:16:20 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 837DC43015C for ; Thu, 19 Jan 2006 10:17:44 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 4E40543005A for ; Thu, 19 Jan 2006 10:17:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 35B8580C13C for ; Thu, 19 Jan 2006 10:17:20 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by hermes.tigertech.net (Postfix) with ESMTP id 2191380C134 for ; Thu, 19 Jan 2006 10:17:16 -0800 (PST) Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id B44521C29; Thu, 19 Jan 2006 18:17:14 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 614kassRm0316Mo2; Thu, 19 Jan 2006 18:17:13 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 613kassRL0096Mo2; Thu, 19 Jan 2006 18:17:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 19 Jan 2006 18:17:11 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID103kassRL4449Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 11:17:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] DTLS Date: Thu, 19 Jan 2006 11:17:04 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0202EB0E88@VS4.EXCHPROD.USA.NET> Thread-Topic: [Capwap] DTLS Thread-Index: AcYdF8SGXCcTiq2vSV+lfBmWgFZk5wADLVsg From: "Susan Hares" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 19 Jan 2006 18:17:11.0088 (UTC) FILETIME=[90BB9B00:01C61D24] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Scott: I would like to forward concerns about DTLS draft 2.=20 I will send them by Monday. =20 Sue Hares -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Thursday, January 19, 2006 11:45 AM To: capwap Subject: [Capwap] DTLS The eval team recommended that DTLS be used to secure the CAPWAP protocol, and several others have been suggesting this same thing for some time now. Two revisions of a draft explaining how to do this have been published - the first elicited a few minor comments, and the second (modified to reflect those comments) has drawn no fire. Are we done with this discussion? If so, let's get DTLS incorporated into the next rev of the draft.=20 If not, let's hear why not. --Scott _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 14:13:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfDW-0003Gv-65 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 14:13:06 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17268 for ; Thu, 19 Jan 2006 14:11:39 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 08F73430112 for ; Thu, 19 Jan 2006 11:13:05 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 4D88843005A for ; Thu, 19 Jan 2006 11:12:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 423D680C0E8 for ; Thu, 19 Jan 2006 11:12:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 4E11580C127 for ; Thu, 19 Jan 2006 11:12:35 -0800 (PST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 11:12:34 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250116365:sNHT40170488" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JJCYc1024261; Thu, 19 Jan 2006 11:12:34 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 11:12:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] DTLS Date: Thu, 19 Jan 2006 11:12:33 -0800 Message-ID: <08A9A3213527A6428774900A80DBD8D801569BAE@xmb-sjc-222.amer.cisco.com> Thread-Topic: [Capwap] DTLS Thread-Index: AcYdF9EGID0UIpiqSXm7qpjqAWzEsAAE/Sog From: "Nancy Winget (ncamwing)" To: "Scott G. Kelly" , "capwap" X-OriginalArrivalTime: 19 Jan 2006 19:12:34.0530 (UTC) FILETIME=[4DA89C20:01C61D2C] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Scott, I will provide some comments by next week. Nancy. =20 -----Original Message----- From: Scott G. Kelly [mailto:s.kelly@ix.netcom.com]=20 Sent: Thursday, January 19, 2006 8:45 AM To: capwap Subject: [Capwap] DTLS The eval team recommended that DTLS be used to secure the CAPWAP protocol, and several others have been suggesting this same thing for some time now. Two revisions of a draft explaining how to do this have been published - the first elicited a few minor comments, and the second (modified to reflect those comments) has drawn no fire. Are we done with this discussion? If so, let's get DTLS incorporated into the next rev of the draft.=20 If not, let's hear why not. --Scott _________________________________________________________________ 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 From trplj@cyberhighway.net Thu Jan 19 14:19:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfK9-0005gc-JA for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 14:19:57 -0500 Received: from c-66-41-155-139.hsd1.mn.comcast.net (c-66-41-155-139.hsd1.mn.comcast.net [66.41.155.139]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17874 for ; Thu, 19 Jan 2006 14:18:30 -0500 (EST) Received: from respiration by microsoft.com with local (Exim 4.41 (FreeBSD)) id 79-6-89 for dhabi; Thu, 19 Jan 2006 10:30:37 -0500 To: capwap-archive@ietf.org Subject: Amazing, Janette From: Gretchen Coates Message-ID: <896160.53363@cyberhighway.net:2911144> X-Priority: 3 X-Mailer: brow Mail heisenberg PHP Date: Thu, 19 Jan 2006 14:12:24 -0500 Content-Type: multipart/mixed; boundary="------=05099385506" Content-Transfer-Encoding: base64 --------=05099385506 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Package	Quantity	Price in your local drugstore*	Our price	Learn More Now
10 softtabs	20 doses	~~$149.95~~	$119.95
20 softtabs	40 doses	~~$299.95~~	$159.95
30 softtabs	60 doses	~~$849.95~~	$169.95
60 softtabs	120 doses	~~$1 999.95~~	$259.95
90 softtabs	180 doses	~~$3 099.95~~	$299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

You have the courage and power to live your dreams.Glory, built on selfish principles, is shame and guilt.
Labor is the curse of the world, and nobody can meddle with it without becoming proportionately brutified.The speed of the boss is the speed of the team. --------=05099385506 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Pete-> http://jcptbd.saudichamber.com/?18168533 --------=05099385506-- From wildimabe@grill4all.com Thu Jan 19 20:19:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezkw8-0005eH-Dr for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 20:19:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18521 for ; Thu, 19 Jan 2006 20:18:05 -0500 (EST) Received: from 200-204-117-117.dsl.telesp.net.br ([200.204.117.117] helo=grill4all.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezl4k-0005vK-Pt for capwap-archive@ietf.org; Thu, 19 Jan 2006 20:28:28 -0500 Message-ID: <000001c61d5f$88081ed0$f485a8c0@daffodilly> Reply-To: "Mabel Wildermuth" From: "Mabel Wildermuth" To: "Yu Hannon" Subject: Essenitial P haramabcy Date: Thu, 19 Jan 2006 20:19:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C61D35.9F3216D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C61D35.9F3216D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 These and many other at http://www.ofheciwil.com Va Via Xa Cia liu gr na lis m a x =20 $ $ =20 $ 1. 3. =20 3. 21 33 =20 75 ------=_NextPart_000_0001_01C61D35.9F3216D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These and many other at http://www.ofheciwil.com

Va

Via

Xa

Cia

liu
gr

na
lis

m

a

x

$
$

$

1.

3.

3.

21
33

75

------=_NextPart_000_0001_01C61D35.9F3216D0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 20:41:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlHN-0004S2-LU for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 20:41:29 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20070 for ; Thu, 19 Jan 2006 20:40:01 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9F9114300DB for ; Thu, 19 Jan 2006 17:41:26 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id DBACB43008C for ; Thu, 19 Jan 2006 17:40:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C3BDB398032 for ; Thu, 19 Jan 2006 17:40:26 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4C5D939800C for ; Thu, 19 Jan 2006 17:40:23 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id k0K1eMce019240; Fri, 20 Jan 2006 10:40:22 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k0K1eMH05833; Fri, 20 Jan 2006 10:40:22 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/redsox) with SMTP id k0K1eMd11787; Fri, 20 Jan 2006 10:40:22 +0900 (JST) Subject: RE: [Capwap] RE: Default mode for logical groups MIME-Version: 1.0 Date: Fri, 20 Jan 2006 09:41:18 +0800 Content-class: urn:content-classes:message X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BDA3B12C@pslexc01.psl.local> Thread-Topic: [Capwap] RE: Default mode for logical groups Thread-Index: AcYc+T3B9Jlrsy8+SYmQVSMX2xMvHQAaIjBg From: "Saravanan Govindan" To: "sujay" , "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.425 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO, HTML_MESSAGE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1366426703==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1366426703== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D62.64EBFB97" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D62.64EBFB97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sujay, =20 VLAN + BSSID is a common way for realizing logical groups due to its relative ease in implementation.=20 =20 I realize there are cases where using VLAN information may not be directly required at a WTP. However, for the protocol to work consistently for local-MAC and split-MAC WTPs, I believe there is a need for this.=20 =20 Saravanan =20 =20 =20 =20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Thursday, January 19, 2006 9:03 PM To: Saravanan Govindan; 'Pat Calhoun (pacalhou)' Subject: RE: [Capwap] RE: Default mode for logical groups =20 Hi Saravanan, =20 Is talking of a WLAN logical group comprising of VLAN + BSSID always true? =20 The VLAN mapping to is from Mobile MAC address<-->VLAN Name As in the 'Add Mobile' message. and not from WLANID <--> VLAN ID =20 However; as a measure of resource control and uniformity its a nice idea in having the VLAN info on the WTP whether it is of use there or not. =20 =20 Does it make sense to make the VLAN name as a mandotory element in=20 the Add mobile message?? =20 Regds, Sujay =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Thursday, January 19, 2006 11:35 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: [Capwap] RE: Default mode for logical groups Hi Pat, =20 My point here is not with the location of the bridging function, rather the way the protocol manages logical groups in general.=20 =20 It is a need arising from two objectives (draft-ietf-objectives-04) - Logical Groups (Section 5.1.1) and Resource Control Objective (5.1.7). So the need is to provide logical subsets - with the ability to manage resources on both wireless segment and the wired segment. I see this as requiring a type of mapping between the wired segment, say VLAN, and wireless segment, say BSSID.=20 =20 So even in the case of an AC doing bridging, it needs to be able to configure its WTPs so that the WTPs can map between the right wired segment VLAN and right wireless segment BSSID.=20 =09 I think this can be provided by including a configuration element for the WTP, which maps VLAN to BSSID for each of the logical groups being configured in the WLAN system.=20 =20 I'm open to any other ways of realizing these two objectives.=20 =20 Saravanan =20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 11:18 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 I think the crux of the problem is that in Local MAC the bridging function is provided by the WTP, and therefore it needs a VLAN. However, pushing this to a WTP when bridging is performed in the AC would be pointless since the WTP is never connected to a trunk. Unfortunately, by relocating the bridging function, there is no way to make this common :( =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 7:17 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: Default mode for logical groups Pat, =20 I see your point.=20 =20 My concern is with the operation of the consistent operation of the protocol. So if we were to design in such a way that each logical group - or WLAN - is a VLAN + a BSSID, then it makes configuring local-MAC and split-MAC WTPs similar.=20 =20 I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical group configuration works is a common way for local-MAC and split-MAC WTPs. =20 Do you think this is the case? =09 Saravanan=20 =20 =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, January 19, 2006 10:57 AM To: Saravanan Govindan; capwap@frascone.com Subject: RE: Default mode for logical groups =20 Thanks for the e-mail. I recall this conversation, but I believe where I am getting confused is what we believe is missing.=20 =20 I believe we can agree that if *any* form of tunneling is occuring, then no mapping is required since VLANs will be enforced on the AC. Further, the protocol already has a provision to specify the VLAN to associate with a given user when Local MAC is used. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Wednesday, January 18, 2006 5:28 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Default mode for logical groups Pat, =20 Issue:=20 Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. This makes for consistent configuration and management across logical groups.=20 =20 =20 My recommendation: Introduce a message element in the WLAN Config message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment VLANs to wireless-segment BSSIDs. This is the simplest and most common case for logical groups.=20 =20 Then include description of logical group configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section 11.4).=20 =20 =09 Saravanan ------_=_NextPart_001_01C61D62.64EBFB97 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi Sujay,

VLAN + BSSID is a common way for realizing logical = groups due to its relative ease in implementation. =

I realize there are cases where using VLAN = information may not be directly required at a WTP. However, for the protocol to work consistently for local-MAC and split-MAC WTPs, I believe there is a need = for this.

Saravanan

From: sujay [mailto:sujayg@huawei.com]
Sent: Thursday, January = 19, 2006 9:03 PM
To: Saravanan Govindan; = 'Pat Calhoun (pacalhou)'
Subject: RE: [Capwap] RE: = Default mode for logical groups

Hi = Saravanan,

Is = talking of a WLAN logical group comprising

of = VLAN + BSSID always true?

The = VLAN mapping to is from Mobile MAC address<-->VLAN = Name

As in the 'Add Mobile' message.

and = not from WLANID <--> VLAN ID

However; as a measure of resource control and uniformity its a nice = idea

in = having the VLAN info on the WTP whether it is of use there or = not.

Does = it make sense to make the VLAN name as a mandotory element in =

the = Add mobile message??

Regds,

Sujay

-----Original = Message-----
From: Saravanan Govindan = [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Thursday, January = 19, 2006 11:35 AM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: [Capwap] RE: = Default mode for logical groups

Hi Pat,

My point here is not with the location of the = bridging function, rather the way the protocol manages logical groups in general. =

It is a need arising from two objectives (draft-ietf-objectives-04) – Logical Groups (Section 5.1.1) and = Resource Control Objective (5.1.7). So the need is to provide logical subsets = – with the ability to manage resources on both wireless segment and the = wired segment. I see this as requiring a type of mapping between the wired = segment, say VLAN, and wireless segment, say BSSID.

So even in the case of an AC doing bridging, it needs = to be able to configure its WTPs so that the WTPs can map between the right = wired segment VLAN and right wireless segment BSSID.

I think this can be provided by including a configuration element for = the WTP, which maps VLAN to BSSID for each of the logical groups being configured = in the WLAN system.

I’m open to any other ways of realizing these = two objectives.

Saravanan

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 11:18 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: RE: Default mode = for logical groups

I think the crux of the problem is = that in Local MAC the bridging function is provided by the WTP, and therefore it = needs a VLAN. However, pushing this to a WTP when bridging is performed in the = AC would be pointless since the WTP is never connected to a trunk. = Unfortunately, by relocating the bridging function, there is no way to make this common = :(

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January = 18, 2006 7:17 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: RE: Default mode = for logical groups

Pat,

I see your point.

My concern is with the operation of the consistent = operation of the protocol. So if we were to design in such a way that each logical = group - or WLAN - is a VLAN + a BSSID, then it makes configuring = local-MAC and split-MAC WTPs similar.

I think the current protocol already does what we are talking about in some form. It would be nice to bring out how logical = group configuration works is a common way for local-MAC and split-MAC = WTPs.

Do you think this is the case?

Saravanan

From: Pat = Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 10:57 AM
To: Saravanan Govindan; capwap@frascone.com
Subject: RE: Default mode = for logical groups

Thanks for the e-mail. I recall = this conversation, but I believe where I am getting confused is what we = believe is missing.

I believe we can agree that if = *any* form of tunneling is occuring, then no mapping is required since VLANs will = be enforced on the AC. Further, the protocol already has a provision to = specify the VLAN to associate with a given user when Local MAC is = used.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January = 18, 2006 5:28 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
Subject: Default mode for = logical groups

Pat,

Issue:

Assign a default mode for configuring logical groups (draft-ietf-capwap-objectives-04.txt) Section 5.1.1 and (draft-ietf-eval-00.txt) Section 6.1 across wired and wireless segments. = This makes for consistent configuration and management across logical groups. =

My recommendation:

Introduce a message element in the WLAN Config = message (draft-ohara-capwap-lwapp-03.txt) Section 11.8.2 to map wired-segment = VLANs to wireless-segment BSSIDs. This is the simplest and most common case for = logical groups.

Then include description of logical group = configuration in BSSID to WLAN ID Mapping (draft-ohara-capwap-lwapp-03.txt) in Section = 11.4).

Saravanan

------_=_NextPart_001_01C61D62.64EBFB97-- --===============1366426703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1366426703==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 22:20:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezmoi-0004ry-Gv for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 22:20:00 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27801 for ; Thu, 19 Jan 2006 22:18:32 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8376B430127 for ; Thu, 19 Jan 2006 19:19:58 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 1D66A430073 for ; Thu, 19 Jan 2006 19:19:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 0B32939803A for ; Thu, 19 Jan 2006 19:19:33 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1D86D39800C for ; Thu, 19 Jan 2006 19:19:29 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id k0K3JIKb008486; Fri, 20 Jan 2006 12:19:18 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k0K3JJc05715; Fri, 20 Jan 2006 12:19:19 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with SMTP id k0K3JK926597; Fri, 20 Jan 2006 12:19:20 +0900 (JST) Content-class: urn:content-classes:message Subject: RE: [Capwap] WGLC timeline for Evaluation draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2006 11:20:10 +0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BDA3B1B3@pslexc01.psl.local> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfA= From: "Saravanan Govindan" To: "Nelson, David" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Dave, I think the Evaluation Team has made solid recommendations based on its review.=20 My concern is that as a WG document, which is an output from the CAPWAP WG as a whole, the Evaluation draft should also incorporate key findings made outside the Evaluation Team review.=20 For consideration, these 'other' findings can be included in a separate section that clearly highlights their origins.=20 This way, the Evaluation document will cover greater analyses of the protocols and help implementers understand the CAPWAP protocol better.=20 I hope this helps to better understand my concern.=20 Cheers, Saravanan -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Thursday, January 19, 2006 11:42 PM To: capwap@frascone.com Subject: RE: [Capwap] WGLC timeline for Evaluation draft Saravanan Govindan writes... > To have discussions on the key recommendations of the=20 > Comparative Analysis draft and then incorporate them in > the final Evaluation draft based on consensus. With all due respect, the Evaluation Team draft (and eventual Informational RFC) documents the proceedings and findings of the CAPWAP WG Evaluation Team, during a specific period of time when the Eval Team was in operation. The draft is intended to accurately reflect that process, as an historical record. The recommendations of the Eval Team are not binding upon the WG. However, the WG is not expected to *revise* the record of the Eval Team proceedings, except to correct errors of fact. For that reason, adding substantive comments and recommendations, that did not come from the Eval Team proceedings, into the Eval Team draft would not be appropriate. Regards, Dave =20 _________________________________________________________________ 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 22:53:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EznLU-00082o-O1 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 22:53:53 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00894 for ; Thu, 19 Jan 2006 22:52:24 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 272D44300FD for ; Thu, 19 Jan 2006 19:53:51 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id CE6C4430073 for ; Thu, 19 Jan 2006 19:53:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BF77C80C123 for ; Thu, 19 Jan 2006 19:53:28 -0800 (PST) Received: from staff-mail.rp.edu.sg (staff-mail.rp.edu.sg [202.21.158.80]) by hermes.tigertech.net (Postfix) with ESMTP id D509D80C0EB for ; Thu, 19 Jan 2006 19:53:23 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Fri, 20 Jan 2006 11:53:15 +0800 Message-ID: <9C374CF75527504394E573E1937136C4022661FA@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft thread-index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfAAAmXl0A== From: "Richard Gwee" To: "Saravanan Govindan" , "Nelson, David" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Hi, I agree with the recommendation to incorporate the key recommendations of the Comparative Analysis draft into the final Evaluation draft. It is a pity that I am not able to present the recommendations during the 64th IETF meeting but I feel that the recommendations highlighted in the Comparative Analysis draft are valid points for discussion. I do understand the Evaluation draft is the official working item but I do believe that we can actually look into recommendations outside the Evaluation draft if they are valid and help in the development of a better CAPWAP protocol standard. Thanks and regards Richard -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]=20 Sent: Friday, January 20, 2006 11:20 AM To: Nelson, David; capwap@frascone.com Subject: RE: [Capwap] WGLC timeline for Evaluation draft Dave, I think the Evaluation Team has made solid recommendations based on its review.=20 My concern is that as a WG document, which is an output from the CAPWAP WG as a whole, the Evaluation draft should also incorporate key findings made outside the Evaluation Team review.=20 For consideration, these 'other' findings can be included in a separate section that clearly highlights their origins.=20 This way, the Evaluation document will cover greater analyses of the protocols and help implementers understand the CAPWAP protocol better.=20 I hope this helps to better understand my concern.=20 Cheers, Saravanan -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Thursday, January 19, 2006 11:42 PM To: capwap@frascone.com Subject: RE: [Capwap] WGLC timeline for Evaluation draft Saravanan Govindan writes... > To have discussions on the key recommendations of the=20 > Comparative Analysis draft and then incorporate them in > the final Evaluation draft based on consensus. With all due respect, the Evaluation Team draft (and eventual Informational RFC) documents the proceedings and findings of the CAPWAP WG Evaluation Team, during a specific period of time when the Eval Team was in operation. The draft is intended to accurately reflect that process, as an historical record. The recommendations of the Eval Team are not binding upon the WG. However, the WG is not expected to *revise* the record of the Eval Team proceedings, except to correct errors of fact. For that reason, adding substantive comments and recommendations, that did not come from the Eval Team proceedings, into the Eval Team draft would not be appropriate. Regards, Dave =20 _________________________________________________________________ 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 Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 >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. =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 23:07:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EznYI-0003yZ-KN for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 23:07:06 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01962 for ; Thu, 19 Jan 2006 23:05:37 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 88DB74300AB for ; Thu, 19 Jan 2006 20:07:04 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 1B635430073 for ; Thu, 19 Jan 2006 20:06:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id F2C33398045 for ; Thu, 19 Jan 2006 20:06:40 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 022B539803B for ; Thu, 19 Jan 2006 20:06:30 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0K404PO012305 for ; Thu, 19 Jan 2006 23:00:04 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 19 Jan 2006 23:06:29 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 19 Jan 2006 23:06:29 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Jan 2006 23:06:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Thu, 19 Jan 2006 23:06:28 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B501@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfAAAoppwA== References: <5F09D220B62F79418461A978CA0921BDA3B1B3@pslexc01.psl.local> From: "Nelson, David" To: "Saravanan Govindan" , X-OriginalArrivalTime: 20 Jan 2006 04:06:29.0281 (UTC) FILETIME=[E3DBB110:01C61D76] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:65.2823 M:98.9607 P:95.9108 R:95.9108 S:52.5666 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Saravanan Govindan writes... > My concern is that as a WG document, which is an output from the = CAPWAP > WG as a whole, the Evaluation draft should also incorporate key = findings > made outside the Evaluation Team review. >=20 > For consideration, these 'other' findings can be included in a = separate > section that clearly highlights their origins. I understand your concerns, but this is not the process that was agreed = to by the Evaluation Team, the WG Chairs and the Area Directors. The = Eval Team draft reports the procedings and findings of the Eval Team. = It is what it is. It is, in fact, *not* the output of the WG as a = whole, but specifically the output of the Evaluation Team. This same = process has been used multiple times in various IETF WGs. The WG is free to publish whatever additional evaluation documents it = wishes, but I don't beleive it is appropriate to add opinions and = recommendations to the Eval Team document that did not originate from = within the Eval Team process. Regards, Dave =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 23:11:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzncU-0005kw-HF for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 23:11:26 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02252 for ; Thu, 19 Jan 2006 23:09:57 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 8375F4300A5 for ; Thu, 19 Jan 2006 20:11:24 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 4FC46430073 for ; Thu, 19 Jan 2006 20:10:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 40BD980C103 for ; Thu, 19 Jan 2006 20:10:50 -0800 (PST) Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by hermes.tigertech.net (Postfix) with ESMTP id CDD9880C0EB for ; Thu, 19 Jan 2006 20:10:46 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: [Capwap] Addition to MIB issue Date: Fri, 20 Jan 2006 12:10:42 +0800 Message-ID: <9C374CF75527504394E573E1937136C402266241@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] Addition to MIB issue thread-index: AcYcehnLehEPfW3lSAGbqYvk46RYQQA/B0NQ From: "Richard Gwee" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.412 tagged_above=-999 required=7 tests=HTML_60_70, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, HTML_TEXT_AFTER_BODY X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0560300435==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0560300435== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D77.7B2A5694" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D77.7B2A5694 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: FA2A3B62-EAFB-4442-8FDE-270EE0772300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 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. =20 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. =20 Thanks and regards Richard =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 5:57 AM To: capwap@frascone.com Subject: [Capwap] Done w/ Issue Tracker =20 All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 >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. =20 ------_=_NextPart_001_01C61D77.7B2A5694 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 79479C40-7294-40B1-BB19-DB531F032BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 5:57 AM
To: = capwap@frascone.com
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 . 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.

------_=_NextPart_001_01C61D77.7B2A5694-- --===============0560300435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0560300435==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 23:17:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzniN-0006U2-3y for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 23:17:31 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02599 for ; Thu, 19 Jan 2006 23:16:03 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id CA97D430119 for ; Thu, 19 Jan 2006 20:17:29 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id D17BE430073 for ; Thu, 19 Jan 2006 20:17:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id B6BF039800C for ; Thu, 19 Jan 2006 20:17:08 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id 99B42398009 for ; Thu, 19 Jan 2006 20:17:00 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0K4AYPO012682 for ; Thu, 19 Jan 2006 23:10:34 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 19 Jan 2006 23:16:59 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 19 Jan 2006 23:16:59 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Jan 2006 23:16:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Thu, 19 Jan 2006 23:16:59 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B502@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfAAAmXl0AAAhQjI References: <9C374CF75527504394E573E1937136C4022661FA@staff-mail.rp.edu.sg> From: "Nelson, David" To: "Richard Gwee" , X-OriginalArrivalTime: 20 Jan 2006 04:16:59.0421 (UTC) FILETIME=[5B736CD0:01C61D78] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:86.9899 M:99.2571 P:95.9108 R:95.9108 S:77.3686 ) X-pstn-settings: 4 (0.2500:0.2500) p:14 m:14 c:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Richard Gwee writes... > I agree with the recommendation to incorporate the key recommendations > of the Comparative Analysis draft into the final Evaluation draft. =20 I respectfully disagree, for the reasons I've explained. =20 > ...but I feel that the recommendations highlighted in the > Comparative Analysis draft are valid points for discussion.=20 =20 Indeed, they are valid points for discussion. They are simply not the = output of the official CAPWAP WG Evaluation Team, and should be = documented, and discussed separately. The tradition of using an = Evaluation Team, within the IETF, includes the issuance of a report of = findings from that panel that stands alone as the historical record of = the Evaluation Team's work, process and findings. =20 The Evaluation Team document is clearly *not*, nor does it portend to = be, the WG's consensus position on protocol selection and evaluation. = It is the work product and recommendations of the Evaluation Team. =20 Regards, Dave =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Thu Jan 19 23:24:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EznpX-0002lU-32 for capwap-archive@megatron.ietf.org; Thu, 19 Jan 2006 23:24:55 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03113 for ; Thu, 19 Jan 2006 23:23:26 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 65A524300FD for ; Thu, 19 Jan 2006 20:24:50 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id C31C5430073 for ; Thu, 19 Jan 2006 20:24:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AB95680C0EB for ; Thu, 19 Jan 2006 20:24:11 -0800 (PST) Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by hermes.tigertech.net (Postfix) with ESMTP id 4321D80C0EA for ; Thu, 19 Jan 2006 20:24:08 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jan 2006 12:24:04 +0800 Message-ID: <9C374CF75527504394E573E1937136C402266273@staff-mail.rp.edu.sg> Thread-Topic: Issue on Combining messages thread-index: AcYdeVjf9PrOg89YQ9+rTfh33uJntQ== From: "Richard Gwee" To: "Pat Calhoun (pacalhou)" X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.412 tagged_above=-999 required=7 tests=HTML_60_70, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, HTML_TEXT_AFTER_BODY Cc: capwap@frascone.com Subject: [Capwap] Issue on Combining messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0618947758==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0618947758== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D79.5954A763" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D79.5954A763 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 271C1B0D-41B9-4635-8259-62ED7BF483AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 I will like to propose a new thread on the issue tracker. Appreciate if you can help to add it in. =20 Issue: =20 Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can lead to high overhead. Initial analysis have shown that these overhead can be reduced significantly if the messages can be combined. =20 Recommendation: =20 To combine the keepalive and statistics message into one combined message, thus reducing overhead significantly. =20 Thanks and regards Richard Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 >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. =20 ------_=_NextPart_001_01C61D79.5954A763 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 8C0EAEAA-0F64-4577-BC83-9C628714CFFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pat,

I will like to propose a new thread on the issue = tracker. Appreciate if you can help to add it in.

Issue:

Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can = lead to high overhead. Initial analysis have shown that these overhead can be = reduced significantly if the messages can be combined.

Recommendation:

To combine the keepalive and statistics message into = one combined message, thus reducing overhead = significantly.

Thanks and regards

Richard

------_=_NextPart_001_01C61D79.5954A763-- --===============0618947758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0618947758==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 01:30:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezpmy-0001zl-Ut for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 01:30:25 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10724 for ; Fri, 20 Jan 2006 01:28:57 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 185DA4300D2 for ; Thu, 19 Jan 2006 22:30:23 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 6FA89430073 for ; Thu, 19 Jan 2006 22:30:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 5D5B680C0EC for ; Thu, 19 Jan 2006 22:30:02 -0800 (PST) Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by hermes.tigertech.net (Postfix) with ESMTP id 64E9780C0EB for ; Thu, 19 Jan 2006 22:29:59 -0800 (PST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id k0K6Tn9X027221; Fri, 20 Jan 2006 15:29:49 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id k0K6Toj00097; Fri, 20 Jan 2006 15:29:50 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/dodgers) with SMTP id k0K6To906940; Fri, 20 Jan 2006 15:29:50 +0900 (JST) Content-class: urn:content-classes:message Subject: RE: [Capwap] WGLC timeline for Evaluation draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2006 14:30:42 +0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <5F09D220B62F79418461A978CA0921BDA3B230@pslexc01.psl.local> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfAAAoppwAAEdLCA From: "Saravanan Govindan" To: "Nelson, David" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.424 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, FORGED_RCVD_HELO X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Dave, I respect your view on the current state of the Evaluation document.=20 However, since the Evaluation document is subject to WG consensus, I think it should represent that.=20 In the spirit of a quick resolution, maybe we can get the Chairs' input in this.=20 Cheers, Saravanan -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Friday, January 20, 2006 12:06 PM To: Saravanan Govindan; capwap@frascone.com Subject: RE: [Capwap] WGLC timeline for Evaluation draft Saravanan Govindan writes... > My concern is that as a WG document, which is an output from the CAPWAP > WG as a whole, the Evaluation draft should also incorporate key findings > made outside the Evaluation Team review. >=20 > For consideration, these 'other' findings can be included in a separate > section that clearly highlights their origins. I understand your concerns, but this is not the process that was agreed to by the Evaluation Team, the WG Chairs and the Area Directors. The Eval Team draft reports the procedings and findings of the Eval Team. It is what it is. It is, in fact, *not* the output of the WG as a whole, but specifically the output of the Evaluation Team. This same process has been used multiple times in various IETF WGs. The WG is free to publish whatever additional evaluation documents it wishes, but I don't beleive it is appropriate to add opinions and recommendations to the Eval Team document that did not originate from within the Eval Team process. Regards, Dave =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From info@mail.bxbbx.com Fri Jan 20 03:50:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzryN-0003tI-Cy for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 03:50:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22564 for ; Fri, 20 Jan 2006 03:48:51 -0500 (EST) Received: from [219.239.208.42] (helo=mail.bxbbx.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ezs6r-0003ar-A8 for capwap-archive@ietf.org; Fri, 20 Jan 2006 03:59:18 -0500 Received: (qmail 23646 invoked by uid 507); 18 Jan 2006 20:33:20 +0900 Date: 18 Jan 2006 20:33:20 +0900 Message-ID: <20060118113320.23644.qmail@mail.bxbbx.com> From: info@bxbbx.com To: capwap-archive@ietf.org Subject: $B5.J}$X$NLsB+(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 $B!X5<;w6a?FAj4/4jK>!Y!X#H%U%l%s%I4jK>!Y(B $B!X#M=wD4654jK>!Y!X%(%m%a%$%I4jK>!Y(B http://www.bfzu.com?1231 $B?M$=$l$>$l!"%7!<%/%l%C%H$K$7$?$$;v$O?'!9!*(B $B"#5.J}$X$NLsB+(B $B"((BH$B$X$N$*Ni6b$OI,$:$*;YJ'$$$7$^$9!#4pK\E*$K$O$44uK>3[(B $B$r$*;YJ'$$$7$?$$$H;W$$$^$9$,!"(BH1$B2s(B20$BK|1_$H;W$C$FD:$1$l$P(B $B$H;W$$$^$9!#(B $B"((BH$B$OK\Ev$K9%$-$G$9!#$I$s$J(BH$B$b5q$_$^$;$s!"Bt;365$($F!"(B $B65$(9g$C$F!"=c?h$K0&$79g$($k;~4V$r2a$4$7$?$$!#!#!#(B $B",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",(B $BEv%0%k!<%W$K9b3[G<@G$7$?$$$H8@$C$F$*$j$^$9$N$G$*AjA0$N8e$K!Z(B H $B![$*IU$12<$5$$!#(B $B@^$jJV$7=w@-$+$iJV;v$,FO$-$^$9$N$G%W%l%$!@\(B $B$*Fs?M$G$*7h$a2<$5$$!#(B $B$*; Fri, 20 Jan 2006 08:15:04 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 62A08430122 for ; Fri, 20 Jan 2006 05:16:29 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id DCA7443009A for ; Fri, 20 Jan 2006 05:16:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C111180C104 for ; Fri, 20 Jan 2006 05:16:03 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by hermes.tigertech.net (Postfix) with ESMTP id C12B780C0EB for ; Fri, 20 Jan 2006 05:15:52 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0KD9QPO015890 for ; Fri, 20 Jan 2006 08:09:26 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 20 Jan 2006 08:15:51 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 20 Jan 2006 08:15:51 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Jan 2006 08:15:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Fri, 20 Jan 2006 08:15:50 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B503@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYcuEXXgsVdSDySRmKLHXgbPHFu3AAVaCsgABdfXfAAAoppwAAEdLCAAA7fQUI= References: <5F09D220B62F79418461A978CA0921BDA3B230@pslexc01.psl.local> From: "Nelson, David" To: "Saravanan Govindan" , X-OriginalArrivalTime: 20 Jan 2006 13:15:50.0992 (UTC) FILETIME=[A291A500:01C61DC3] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:95.0766 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Saravanan Govindan writes... =20 > However, since the Evaluation document is subject to WG consensus, I > think it should represent that. =20 Well, in fact ,the Evaluation Team document was *not* intended to be = subject to WG consensus, when the Chairs and Area Director initially set = the ground rules for the Evaluation Team process. That's the basis of = my issue with your suggestion to incorporate other opinions.=20 > In the spirit of a quick resolution, maybe we can get the Chairs' = input > in this. =20 Yes, I agree. I would appreciate clarification from the Chairs. =20 Regards, Dave _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 11:49:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzRr-0008MG-BT for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 11:49:15 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29250 for ; Fri, 20 Jan 2006 11:47:46 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A343A4300FE for ; Fri, 20 Jan 2006 08:49:12 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 138D34300B0 for ; Fri, 20 Jan 2006 08:48:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1A265398052 for ; Fri, 20 Jan 2006 08:48:46 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by zoidberg.tigertech.net (Postfix) with ESMTP id A08F9398033 for ; Fri, 20 Jan 2006 08:48:34 -0800 (PST) Received: by zproxy.gmail.com with SMTP id l1so481937nzf for ; Fri, 20 Jan 2006 08:48:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fMOZyIL1TBU4xO5kZLGklrDuYrET4N9HBpspk+t/WkS6bhPjUTXWoxNbmwFWPYlG6/c15dUTkeveTxTuzQYskc7v47GEFQxy8W0+dRHplHAmbIsblGxjiihFgihFhRG5+0mkNk0hnBwqursKL1ig1OkhjKfldg8s8u22v/it9fM= Received: by 10.37.2.79 with SMTP id e79mr1555081nzi; Fri, 20 Jan 2006 08:48:24 -0800 (PST) Received: by 10.36.9.6 with HTTP; Fri, 20 Jan 2006 08:48:23 -0800 (PST) Message-ID: <5e6e0f30601200848m3efa91e6rf3066ffa5b12a90@mail.gmail.com> Date: Fri, 20 Jan 2006 09:48:24 -0700 From: Darren To: Richard Gwee Subject: Re: [Capwap] WGLC timeline for Evaluation draft In-Reply-To: <9C374CF75527504394E573E1937136C4022661FA@staff-mail.rp.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9C374CF75527504394E573E1937136C4022661FA@staff-mail.rp.edu.sg> X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP Cc: Saravanan Govindan , capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable The evaluation draft will stand as is for the purpose of documenting the evaluation team's efforts. The draft and informational RFC is the historical record of the evaluation team's efforts at that point in time. It's primary goal was to help the working group consolidate it's efforts around one protocol to deliver on the CAPWAP objectives.=20 The draft is not intended to be an exclusive list of issues and recommendations for the life of the working group. I agree that Richard's comparative analysis draft brings up some important points that are not in the official evaluation draft. These issues can be considered by the working group in without editing the evaluation draft. If there is sufficient support from the working group to addresss those issues, they should be addressed. This includes consensus that they are important issues that must be resolved and volunteers to develop the solutions. -Darren On 1/19/06, Richard Gwee wrote: > Hi, > > I agree with the recommendation to incorporate the key recommendations > of the Comparative Analysis draft into the final Evaluation draft. It is > a pity that I am not able to present the recommendations during the 64th > IETF meeting but I feel that the recommendations highlighted in the > Comparative Analysis draft are valid points for discussion. I do > understand the Evaluation draft is the official working item but I do > believe that we can actually look into recommendations outside the > Evaluation draft if they are valid and help in the development of a > better CAPWAP protocol standard. > > Thanks and regards > Richard > > -----Original Message----- > From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] > Sent: Friday, January 20, 2006 11:20 AM > To: Nelson, David; capwap@frascone.com > Subject: RE: [Capwap] WGLC timeline for Evaluation draft > > Dave, > > I think the Evaluation Team has made solid recommendations based on its > review. > > My concern is that as a WG document, which is an output from the CAPWAP > WG as a whole, the Evaluation draft should also incorporate key findings > made outside the Evaluation Team review. > > For consideration, these 'other' findings can be included in a separate > section that clearly highlights their origins. > > This way, the Evaluation document will cover greater analyses of the > protocols and help implementers understand the CAPWAP protocol better. > > I hope this helps to better understand my concern. > > Cheers, > > Saravanan > > > > > > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, January 19, 2006 11:42 PM > To: capwap@frascone.com > Subject: RE: [Capwap] WGLC timeline for Evaluation draft > > > Saravanan Govindan writes... > > > To have discussions on the key recommendations of the > > Comparative Analysis draft and then incorporate them in > > the final Evaluation draft based on consensus. > > With all due respect, the Evaluation Team draft (and eventual > Informational RFC) documents the proceedings and findings of the CAPWAP > WG Evaluation Team, during a specific period of time when the Eval Team > was in operation. The draft is intended to accurately reflect that > process, as an historical record. The recommendations of the Eval Team > are not binding upon the WG. However, the WG is not expected to > *revise* the record of the Eval Team proceedings, except to correct > errors of fact. > > For that reason, adding substantive comments and recommendations, that > did not come from the Eval Team proceedings, into the Eval Team draft > would not be appropriate. > > Regards, > > Dave > > _________________________________________________________________ > 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 > > > Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 > . www.rp.sg . Fax: +65 6415-1310 . > >From March 2006, we will be located in our new home at 9 Woodlands Avenu= e 9, Singapore 738964. Republic Polytechnic, the first Institute of Higher = Learning to fully adopt the Problem-Based Learning approach in Singapore, c= ontinues to strive towards best practices and maintain excellence in servic= e standards with the following certifications: Singapore Innovation Class (= SIC), Singapore Quality Class (SQC), People Developer Standards and QEHS (I= SO 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 no= t the intended recipient, you should not disseminate, distribute or copy th= is communication. If you have received this communication in error, please = notify us immediately by return email and delete the original message. Than= k you. > > > _________________________________________________________________ > 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 13:12:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00kY-0004RO-FE for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 13:12:40 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06970 for ; Fri, 20 Jan 2006 13:11:08 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EFD4143009A for ; Fri, 20 Jan 2006 10:12:35 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id A664B43009A for ; Fri, 20 Jan 2006 10:12:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8982580C106 for ; Fri, 20 Jan 2006 10:12:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 393A080C104 for ; Fri, 20 Jan 2006 10:12:06 -0800 (PST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 10:12:06 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="250354682:sNHT35726288" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KIC5c1001428; Fri, 20 Jan 2006 10:12:05 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 10:12:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] WGLC timeline for Evaluation draft Date: Fri, 20 Jan 2006 10:12:03 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437CE9@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] WGLC timeline for Evaluation draft Thread-Index: AcYd4XXkbm8gx38ERcuwgCrEzPbZEQAC2/5Q From: "Pat Calhoun (pacalhou)" To: "Darren" , "Richard Gwee" X-OriginalArrivalTime: 20 Jan 2006 18:12:05.0083 (UTC) FILETIME=[04C0B2B0:01C61DED] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Cc: Saravanan Govindan , capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Personally, I think we can start dealing with these change requests via e-mail. I don't see value in documenting changes in a separate document when we are in the process of editing. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Darren [mailto:dplore@gmail.com]=20 > Sent: Friday, January 20, 2006 8:48 AM > To: Richard Gwee > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] WGLC timeline for Evaluation draft >=20 > The evaluation draft will stand as is for the purpose of=20 > documenting the evaluation team's efforts. The draft and=20 > informational RFC is the historical record of the evaluation=20 > team's efforts at that point in time. It's primary goal was=20 > to help the working group consolidate it's efforts around one=20 > protocol to deliver on the CAPWAP objectives.=20 > The draft is not intended to be an exclusive list of issues=20 > and recommendations for the life of the working group. >=20 > I agree that Richard's comparative analysis draft brings up=20 > some important points that are not in the official evaluation=20 > draft. These issues can be considered by the working group=20 > in without editing the evaluation draft. If there is=20 > sufficient support from the working group to addresss those=20 > issues, they should be addressed. This includes consensus=20 > that they are important issues that must be resolved and=20 > volunteers to develop the solutions. >=20 > -Darren >=20 >=20 > On 1/19/06, Richard Gwee wrote: > > Hi, > > > > I agree with the recommendation to incorporate the key=20 > recommendations=20 > > of the Comparative Analysis draft into the final Evaluation=20 > draft. It=20 > > is a pity that I am not able to present the recommendations=20 > during the=20 > > 64th IETF meeting but I feel that the recommendations=20 > highlighted in=20 > > the Comparative Analysis draft are valid points for=20 > discussion. I do=20 > > understand the Evaluation draft is the official working=20 > item but I do=20 > > believe that we can actually look into recommendations outside the=20 > > Evaluation draft if they are valid and help in the development of a=20 > > better CAPWAP protocol standard. > > > > Thanks and regards > > Richard > > > > -----Original Message----- > > From: Saravanan Govindan=20 > [mailto:Saravanan.Govindan@sg.panasonic.com] > > Sent: Friday, January 20, 2006 11:20 AM > > To: Nelson, David; capwap@frascone.com > > Subject: RE: [Capwap] WGLC timeline for Evaluation draft > > > > Dave, > > > > I think the Evaluation Team has made solid recommendations based on=20 > > its review. > > > > My concern is that as a WG document, which is an output from the=20 > > CAPWAP WG as a whole, the Evaluation draft should also=20 > incorporate key=20 > > findings made outside the Evaluation Team review. > > > > For consideration, these 'other' findings can be included in a=20 > > separate section that clearly highlights their origins. > > > > This way, the Evaluation document will cover greater=20 > analyses of the=20 > > protocols and help implementers understand the CAPWAP=20 > protocol better. > > > > I hope this helps to better understand my concern. > > > > Cheers, > > > > Saravanan > > > > > > > > > > > > -----Original Message----- > > From: Nelson, David [mailto:dnelson@enterasys.com] > > Sent: Thursday, January 19, 2006 11:42 PM > > To: capwap@frascone.com > > Subject: RE: [Capwap] WGLC timeline for Evaluation draft > > > > > > Saravanan Govindan writes... > > > > > To have discussions on the key recommendations of the Comparative=20 > > > Analysis draft and then incorporate them in the final Evaluation=20 > > > draft based on consensus. > > > > With all due respect, the Evaluation Team draft (and eventual=20 > > Informational RFC) documents the proceedings and findings of the=20 > > CAPWAP WG Evaluation Team, during a specific period of time=20 > when the=20 > > Eval Team was in operation. The draft is intended to accurately=20 > > reflect that process, as an historical record. The=20 > recommendations of=20 > > the Eval Team are not binding upon the WG. However, the WG is not=20 > > expected to > > *revise* the record of the Eval Team proceedings, except to correct=20 > > errors of fact. > > > > For that reason, adding substantive comments and=20 > recommendations, that=20 > > did not come from the Eval Team proceedings, into the Eval=20 > Team draft=20 > > would not be appropriate. > > > > Regards, > > > > Dave > > > > _________________________________________________________________ > > 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 > > > > > > Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore=20 > > 248922 . www.rp.sg . Fax: +65 6415-1310 . > > >From March 2006, we will be located in our new home at 9 Woodlands=20 > > >Avenue 9, Singapore 738964. Republic Polytechnic, the=20 > first Institute=20 > > >of Higher Learning to fully adopt the Problem-Based=20 > Learning approach=20 > > >in Singapore, continues to strive towards best practices=20 > and maintain=20 > > >excellence in service standards with the following certifications:=20 > > >Singapore Innovation Class (SIC), Singapore Quality Class (SQC),=20 > > >People Developer Standards and QEHS (ISO 9001, 14001 and=20 > OHSAS 18001) > >=20 > ---------------------------------------------------------------------- > > ---------- CONFIDENTIALITY CAUTION: This message is=20 > intended only for=20 > > the use of the individual or entity to whom it is addressed=20 > and contains information that is privileged and confidential.=20 > If you, the reader of this message, are not the intended=20 > recipient, you should not disseminate, distribute or copy=20 > this communication. If you have received this communication=20 > in error, please notify us immediately by return email and=20 > 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 > > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From kenney@fgmc.com Fri Jan 20 13:13:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00l0-0004bz-Tk; Fri, 20 Jan 2006 13:13:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07082; Fri, 20 Jan 2006 13:11:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00tn-0005xQ-8V; Fri, 20 Jan 2006 13:22:11 -0500 Received: from lan31-7-82-241-249-137.fbx.proxad.net ([82.241.249.137]) by mx2.foretec.com with smtp (Exim 4.24) id 1F00ks-00012p-9m; Fri, 20 Jan 2006 13:12:59 -0500 Received: by 10.11.98.4 with HTTP; Wed, 21 Apr 2004 21:40:49 -0600 Message-ID: <526f871f.7106200@yahoo.com> Date: Wed, 21 Apr 2004 21:40:49 -0600 From: "Maryann Call" User-Agent: Apple Mail (2.728) X-PGP-Key: khFe7FhwGx2gbvVCZ9HBCcleJNSmg4ArjoCKJEL4EcOI2iMHNMBxwizMuXKv0XDh== X-Load: 16% MIME-Version: 1.0 To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, casandra.boykin@ietf.org, cats@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Pre-approved Application #HWFDJ951612459 Content-Type: multipart/related; boundary="------------AttPart_86565043==.OLA" X-Spam-Score: 3.0 (+++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_86565043==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

it purl may judd try campfire it's crochet ! francisco the ashland not ellipsoidal not barter a madeline not trompe may dilatation some awake ! phrasemake it appointee Or maybe not

--------------AttPart_86565043==.OLA Content-Type: image/gif; name="patroness.1.gif" Content-ID: <9.0.0.50.0.05682599181191.83900051@often.hotmail.com.5> Content-Disposition: inline; filename="patroness.1.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFnMAD46NqPDROeHJXlLdFa0k1ZeM5vHdv13wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKBFZRhDIzrRiCRfmxvt6EcGQzrShAwBADs= --------------AttPart_86565043==.OLA-- From lross@brtph8a0.bnr.ca Fri Jan 20 13:39:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01Ar-0005M0-GD; Fri, 20 Jan 2006 13:39:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09088; Fri, 20 Jan 2006 13:38:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01JX-0006s0-Jl; Fri, 20 Jan 2006 13:48:54 -0500 Received: from user-85-201-6-144.tvcablenet.be ([85.201.6.144]) by mx2.foretec.com with smtp (Exim 4.24) id 1F01Ad-0002KL-An; Fri, 20 Jan 2006 13:39:35 -0500 Received: from [192.168.1.7] ([82.227.172.226]) by yahoo.com (Sendmail 8.0.3) with ESMTP (SSL) id IYT94221 for ; Fri, 20 Jan 2006 12:39:17 -0600 Message-ID: <523c787g.7600990@yahoo.com> Date: Fri, 20 Jan 2006 12:39:17 -0600 From: "Brain Lackey" User-Agent: Omni Way Webmail X-Register: 321494 X-User: turbinate MIME-Version: 1.0 To: capwap-archive@ietf.org Cc: casandra.boykin@ietf.org, cats@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org, chive@ietf.org, christine.fontenot@ietf.org Subject: Pre-approved Application #5030452 Fri, 20 Jan 2006 12:39:17 -0600 Content-Type: multipart/related; boundary="------------JavaMail.868197025481" X-Spam-Score: 1.8 (+) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multi-part message in MIME format. --------------JavaMail.868197025481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

on bisque it soda but mire or ripe ! germicidal it's inattentive but odorous or alphonse , bodice try cubic or cretinous try leila it ecosystem may cottonwood Or maybe not

--------------JavaMail.868197025481 Content-Type: image/gif; name="capella.8.gif" Content-ID: <5.0.0.77.0.72528410268594.74362849@carbone.msn.com.7> Content-Disposition: inline; filename="capella.8.gif" Content-Transfer-Encoding: base64 R0lGODlhGAKlAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlm/2Zm/2Zm ZmYz/zMz/zMzMzMA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAYAqUAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89orUJROigOKrfona7b7/h8FgJpS+ApChIiEmx6 h4iJios0fH6AKIKEhoyVlpeYaY4kB38jCnyUkgCFn6GZqKmqq0ubI52AoQ0SfQCjpQAQEg2z tay/wMHCL7p8xrpwDb6dbLfNngDMw9PU1ayha2uzcBANB98H3baDpGzKJOLW6uvsea4isKQS 8/R9zrm++O37/P1f79E84Spx7x1AfwgTKlQCMN47Ovdmkdi1sKLFiz8aehLUYE6pe506Atg2 BxLGkyhT/6LQCEgQPUP3xr0cMVClzZs4TXxzsZMTpZxAgwpt4W2o0aNIkypdyrSp06dQo0qd SrWq1atYs2pNsobgT1tfy8ixZTLP2Bx0nJTFtHYrjofzStQ0Eu8RjZiHRuWYaxfIuSB1reh1 q2Mwr4GBjySGB03G4ESPhSzmcZDHZCmRCdsIXIjXJ3Kg0nl9RWls6KLRzHWDc2AWaniuWyoT eaI1hDWgAdl+bWs2vLRg5/j+NHz0J0O7IQGX46Y1bY+vZrdUrvwrHTnSo8WGvfq3c+4NSs+G eYqgm1OgwpMY/+m8gu22Vnedw4d3+uambkdyzlqZ/mi6pHWaZjTgIole4rgGSv9jIkgkgi4j OKJLeMiM082C3xTzUzi0mLMLhiYIcpsu5JTSyYjQKEhLQJA4wpGIHoW3YgkOBvQMioYMJEkn u+Qzjkc45kLbjKQ8V46FFP7BoX4vBhhQjwHd5tqDUpYyC5E0hTIhiqx1OGUutCSpn2tX1jIh iGAehossWNK0izcnvrfighAk82GFBMLwl2dHliNIi0ZKQ8p/hYRDyUe4SDNZPIIWaYIrcR05 iqKJFtqYhLWAwk2mdfoBkyeubKLjICGdMEqo9oAG4ThlIYqciZ40ek6pD9L2Z13/VTbjiYx5 +Bk35LBoI2N9GErTMy1ZuQxfRIIygoOj/BmhkXmucKr/IZ7Bogw4rQVLU0fpgcugG4hOxMai GzVWY6/PlviMfY112WIfswA3UqEpbOJIo9KOKmyIpI76jZXK+CrXM+YKe+s3t0LDDLeW/heh j5McazFF7LoSz2ANCaLaK6WsBo5oFuu06ijbgrNutSvAUteBg5BIT6Tr0SvjSJzOjLDF6MIx 2GOBxVTmpzpdauY8EpMoMQkNnxuvQKIE3NaOT3PTkZRXU1suz+nOPM/Aunk9zzPzoKbroWj3 WbHG6aKT80zvlCJ2m2rjPDN0YIrN8gud5dPZ1RQDHM8fFIVEx9YV9/zjZ30tXpOcqRY9L2lO /lY5J2+SE9jgUf9LkNQg29kJ/6vM7px425Iz1pZwkZ5d8pE1hbysz97u+yEcsifMlwkD1Us7 3pXtTVTB69V7b3Un7EJON6gPOxisa2080EEYg1nxe+2OQ8ltgTmiHpUjbR+4MUPS5mDvoANM iPmgQVmktxY/7zTtpc3/LdPf2Apq4AP1z4YrHtOH6oYVpcU5DxoBfMha+sc+vJFkDmERnqnw RJ9Y0YJ21LqXSFzikXM5SX4ExJwh+EA/E5CEg5Iykb46FUCM9eJ4wyJJo5g2tnZ1SSQklInn aNggCw4JF186mAGPJKgKhaNY6jLRNmjlINdV7HoqNNOyRlgIOmkPQLjokEve1UHeic8j7SMW BksiQf8U8EouweJQ2SJRKdrILDRDzGL13NQRNe7uXmFyVw+Rpps3grFHxZJZLewYOELA70rV 41Eed8i4Pc7xgQH0YhxzVDhByms9Ovujgb4mxCf2ySUXBB8d9+ifB71kE2qMJCh3NyqkBZBH HqTHkCJYRhiAowY94UlbcplLM64OHr0Epk6iF8xb5otaxuTEL1sWzB7wspnDjKYyN7PMaLAG HbQpZieF+YJmJjOZtcTKZZwiqBkKziPVDKc6W1aMq/SinSsoxuXWSc8YzOcqbrintdaQznr6 858ADahAB0rQghpUDWHBDw3OIhlaPoGhtrQlLYuzBH0SoZ+FcehBiRDJidn/IDM+AOkTRKqC v7ggMwpyQvB+QNKWMSiehdxoER4Iwxq0tDDww0xOW7BSU+20p0YAKg9umoJxytQKu+rdhdpD GsFlhzv/UWhqwBPBPxGPaeXJjyjeQFFOPJU+otFLcrzandCIIqvauU1kzNqf7pSEF2t5j2ik 2pV8Lk2AaS0KXamT15+YFR4BKssbQHEu/+gVPgMy1bkGu1TjQBA8JpFrVLm6QbT+UxpJrZJI /PW5O1mwSkikxKy8NEcwHsYXbEItaKnUjRf6gUs9TNLvxpGkT3GpTFSCHJAWlFOlkStI8oAr jTx7SfBt0UibENGC2NDGXsXpS2SiCJ3KUgz1kJZU/xrSIJrcFiXgZo9dTdpkbZ90juhmkJ69 SFGw+tW5z72qGb5ooi8oEtaXRlIaJsXvFMGULMFqDlGA+pGspHi/TeQ3d4Y8wQo9OqjaMNBz LtrdgsFnYAPHTH+4w1amfrpeBFqQdgEuge3cGKhNDky0ZnIjEmfZoJiu83KJlFt7efg6wLYP xA8Dx1ykVSshcUscIssQ4EL3Od6kLH+DgBm3mvYKUQY5HN5An4JD+6u6VbmHEI7clEP4p2uB Kspv0PH/dvzTwHXrkkfu1qOQODkRE3hh5BKs7Vp0x3+C8GIzbuQTlXG3GCJRbNapXR/mNmix 9YFtaxmaKfUGM7GBbc2G9P9anRqTmTkTeXc/S58+QGpp1T0sZm+wFKCxuItkbdkUM7ukzPrM 3e5RjMmrpEd/ZsbmV5CINwC9c8U4S+OK+c6AjijcS9XnUVZGENGReGFlYObgtYgqoZQus+c4 51MeunqIra6akJzFC6r90jbN426MdKxqF4Pv2n44DN54xz19LAbcGBUex3zRQtHmFITVq5HH oDFHe7HKYgrEK1nwuhjsYZmmXYFZ/db3rEMTmKnVW5WbGY5lK3fx3EbDNoPzTY6UhqQW/c4f JBAnbrxKKx4ID0unBT6xdHSUOdOrtXZGrtFwZtqDUqTdvb2FYBQ+Kb5KtG8oT4ixAHKki8im Ic7/ozTGU8XKwjcU4NGvSHRpw5BWd8xhJF04p50KUIYY4xEganivwgqEheFm8NU5SSm0U2vl yyY7fwG04h7KfFAgTk1LkFPzrTwGlJ160iI/lzDAd3RCmJyJexUvE7mvcoSzM2E9+ihLvBES EojcICcf367BT9yRLK6NH/9YSk4DfY0RChZNEVmpyj/pK2x7CcbWaMcMwr2QNCN1KPGYuWnP TCS42jBAvRnvNhQfmtOUpvFnAE5gfpv4Jukl8W2JfF/WpvjKxL41le98FkDzmdo/5jDL0vzr H/X8RjEq+tdvlSWx//2EsSj850//+tv//vjPv/73z//+Q5D88scE/KQT//6GSw/1a7XhFRaV TxrFgIKVDW0AgSngH30XUhCRFrx0HEhALrjWZD6xgNkQfkWgGwWod9UAI+hQZ0lAQZ9RgSxA U0rAesOGJ3bULLS2S15jb/XwGZN3AmUigjZQIRUSSQ+Ue0MQayoXbT0oeHInBWfUUUpnDYhn d1PAghd3A1Z4BFukPD5yJYAwJRziNJ4QRCl4I0CSIbAyhqVlSi7oA0aULFQ0dl73A2OjPIfE SU9iJziEKOamBE+IaSq4CrCUh8LRWMHhHbVhWFjlVodogjQ4G8ajE+NxT6dBHqVmKuyRGvVD HoaoDXflMaNDMqAkh8mSKsBnhAVkSnbyKeJyiv/3diZg9RqemFD+ITG2cVep5zNhpiELUhQ0 U4mBYFjKkYmvRQr8wYMe5oqpOHchIoyKNSCJBVVbJVfq0S1M8iZZBYXT4BKDiEe3lmBXCDK0 AE9KQ3a/GDJdM3qYQws76I1rpI6d94080i4ewo6zhzQ+olw5pUjx8hkdEYnM6I/0yIzzCJBW SGt5QyKUNI68M441xCPf+Cig8geA50eRUiao11kyA0YKWTSEQ36p1kPbQ5EcFxYusZENaY9I g3oniTSLZo+hRg+NF5HaOA2CxBgWJBAdFhZfEiAoiILnOGbAIoY8iTHthIJiF5Di2CUTSUm/ hZO4YyIpORdlk4WDSEH/VthRLcRzMXMpM5guGwZyUklDYUlbT6JgE1lCzBgXSImHEwENQogo tvcSJlGVcOmV5BI1YYGHWfiQfrk8a4KOG1ZHM8KNZ3lF6qBIycI+zLWTEkmC3XIoOtmC/DWP IvmYQFJ2KoOOcVWSGmQhmolkjVlUrBcLK2KFPLKHdOZfeikPbxmQWVghAMlJqPgKs5YqY4mZ QxiYchiakZmA8aGG+vFLnAcmh3aXq6mVu9MSfRksNBMXlmmWlcMrf/hD4VgNQaSco3mdrili eNmdV4QMZ4SYr0kseZODSnmFrxQXxrNqM1GbmEMiePQGgSWObvSdUdhFuRcXWPmVwLKa4Bki /6t2NGXTFnGplnjCn3NDi17DlAWqAvbYLYVSn/2Zl5TZBjK4QM65ocvIKzS4In8omQO0DtpJ mUHZkJipiuCZQEpig3uZRqdZKNzynwDTmmBimIE1owHqEwPDX+7pkjLxHAYpdIxJkOw5Pf4J m5PpUx+Cgr0ha7qZLnGYYDnKLQ2pVhQkJ6iIH39QLz+6IkPKgQOJRlg6bM/JoePpoQ4DooXZ P/8FhJWgnKglN6rHF5XDEUFEm3UqlOA5T2xIhdlJB1nopJWTXrUQqFGJAr7TlQy4BrC4RUWG k0Uzp6sYI2Z5mN6ph26SqGhpW/HxhXaaloiZoIOAqMWooiaVlSvSpf9VlA29yEVnOZ6oSSTN 6Sa2Gp1T8qFItGEiaoIkGjuIAphkY5IXFIZJ6VofVENxKS58sUUn+XoyMZTJE6zi2Hpkw6kA Uwja2lt3qVYQmJRTqFBO4loigoZiCCxzyZR2IpaKKmxgWqx+One7uYeUBK2GuY52MpGE+VKw tK3Utab6+qeuha94pKG2Co6IB65ruqtXGClSZQ1QiISa1ISp146sF3ixxpm6R7GOBKSxJhJX Qi0SW7HK4TWbNYcymIQOipC856ITS2eu17KFhCcX25tMupKA2Y6ZOnfPGrLd+bFoWQ/uGrM0 9HspKrPI6JYpKLRaw6HgWIOqaZ6K2VGRUpP/09B8DviBVvqMGyKBpBFmO9FLIQh9OrYMIcg0 AZi12ReBA8hNZoSAy+d8Ovob+mQsdOtvrsq2DiV9Xrt9ZvSt1RGAfptLEgi4X1uCEHQdJNi2 tcERuwSAIMi4ITKA0+e2Ysu40re4Wzu41fdPhRqITjiHOKB+RzFs/mcHJymfvwBRp9u6zKeI rhu7sju7tFu7tnu7uEtQArC7vBsAMRAAAuC7QAC8IhC8L8C7vVsDxOsEAkAABDAAKIC8uyu8 RAC8wku9O4C92LtQbbgDcOoDtiG5zNe9F1UEgltUGrgCBFAAzuu8BQC9LxAABbC9PCAABSAC BSAAACC/9FsC69u+/+sLvzJgv04QwANQAPNrAuwLwO9bBPwLAARcv/crAgSgvzdAVDxgUlEQ WKBrLaLLFW8KBEJVM2qXAs5LAvZrwS3wwEAQwSPAwiZMACicvzPgwkpgv9fbwCVAwyNgvwIc BA9swzngwjz8UR/shn2IBB18UkeshSGcEUmsdkJ1wiRQxM37vNQbAANQwTh8AlqMxcWrxQPg u188ACq8v1u8uxMcvFr8vv07AlQ8Ajz8xWC8v/q7xWNcvBMMwfoLvM0bvMZbvH0MyHVcvM47 yFkMyD8cx3J8xhC8xxB8yCRQxmd8xSo8vXgsx/u7voHcw8Aryc1rxi+8xWAcAJwMvOxrwf+U 7MkDkMfVBlm+OnBkRBrfkVb/8Vdg5VddxTQU6B18MlYR2CEDR4lntTThGxnNkR5+ZVnt8VfK HB3lYazwAcxkIVyIOMtkQUIUdYucCHkswMjya8EB3LwJLL8VvL4JXAL2e84JjMCtHADmLAAH DL/rTM4TnL+mnMoqAM48nMoHvMbsa8br67sRPNCPnL9jnM4AcMLmzM7Ca8BuXMQHbALhrMCO XNEL/b4HLMP76886PM/zTMHO28rsW7yRzL7bu8DknMYGDQAefb/kTAD5/LwdXcEh7dIa/cbR 0iFO0lwhRF67qlu4hQ+6RVtOSkPjlZqmuFxtIE9HAnY4tFoWwlv/kwpcEzKwE6ElPQIizzUn xbAk78LUwcUbPs0Mt+ZaXU0vQDrFXCzPOmzKKkzDE03BCg3HHO3S0FvSFCzAXRzHCIy/fVzX J3DIu3vTXfzIBD3HNEzALZ3CIgDDDK3XeI3YemzKd63DLyzZVezILq2/h13RNF3ZnS0CW0zX wnvYenwCem3Oj73Y6dzFRCzOfN3Od81GoqQPFXao8EMr8fFdFQYy/8MpzqZiAXGKKJY8OQJ5 R9RiwI1XWxpx4hI2ezlISQVf3zUpFnTcDQZpOKPbzCgtzlJxqPLNC+y+tf3Yjh3alD3JRSy8 is3G8IzPEn3Pgf3GcFze/0vRB5zYm/3I/y39yJlNvZGtwhNd2i9M2Y6d2efdyBYNAAa+1+EM z/Gtv5zsv3cNwwDe4IDN4JO83xk+2hEu4TRcxLbNLyT5INJCMoxkY04GJ0KmmS0ARy+jJAxj pslNLHDp4lAmK/uYcRqs4mrjP00dRgpD43FmcYtzG19GcPy6Kq7AJ/tc25ZtyAiMwPrb3oKN 4Rve0VVe5cGr0BFMw1puAuBMxfaMwPzN4PZr5T28x5AtwzDM2As+2Q8u0ilA4hvOyM4rv13O 5vnsxnbe2tgrxFs+2lt+5gkc21ze51fO2YS3OS0aarkQal+RGHwmkwJEaIuGi9qBkDPuaJKk NrNpaEHT45NjEP8UI+R7tmqW1zUNiuSfNunSkHSX3jr01neMDODya8a+O+IqrOVjrtj0G+f0 3dH2Heht/shjHN9pvuE47OEf/ubGnuy5Ttrzi9mFruFt7rt6LtOC3eEGHccYTuiGXu6uvexB vMdi/u3lXuLadiE2g8xJBBHLA3J7K9ZZLagyR1RZJJnzBW0lmzoUlg/Ukza+hi87PUAglXUU MhI3w+SrOFsAhOvnPdEuDNp3jdpyLMClXcTYbryYvb4bPuYWXgITHcewDcmuHegXr9CRLcA0 PdcdHdj//dj2jedULPOT/fHw7MqjLe51Te4eH9cUnvGJru4WzPPt/socF1tOo8Ej6ij/4v1w ZPQ9LNconfZyEdTvbGiU+XA49ynw+rAua6jqsNNAiyM9C4fk2lXcVD84aK8x6bTnEn7Ani3m Fe7YfE6/Hr7r5W73aJzAHr7mIz/Hjk73PS/X5YzmHz7aEVzRNvzRJb33jxzY8Avt+a3ON4/u 5JzDly/4Yu7hKE3ZQD/okMzh5n7Hi3/0G2/tfSz6KlyAKONDUGlIAM9gKJRcRWcl2Z1uVNg9 T8c/N2506aJ5HqJzYj9iPbRABn8kuk/kRRT8nuQH/LYmkff8t32+993lFbz9+WvmVQ7tJh/+ 2f7PbG7tAV3sOA295I7OVd79i56/DRz5dz8C+23Da/6+L+/l/20OAoUoAKVQDKUKFOS6ijEa rGfsAoPsBnIKEAiqHm04erVUyVKyd0MBnCRCQZjbMXESxQugkKgaknFjBQGXxIfuQbIufceQ Lze+jo+5gMNZ3gWIkYntuanwjUlAvL1slWy1lZVAQMAhNqbJDb60LU5WIuoxhl4CNOLNNbY1 ku31Jb6Rdp2FFQJ4lnB6IaLWja3d/gX/BRS9EAsPHSMrrzAPF1khP0tTTxsRFzdnA5xsV1c7 J3eFU2N/j3ubR2WTG4YKH8SfU8tvLu7d49b/xefz788LBlBfwBUDC+JjU29fP4QBDx50KHEi wgA/KGIMRmRekIweP4I818BfyJImT/+iTKlyJcuWLssV8BZMABWZL2/izKlzJ8+ePn8C/WZz mIChQY8iTap0KdOmTp9CjSp1KtWqVq9izap1K9euXr+CDSt2LNmyZs+iTat2Ldu2bt/CjSt3 Lt26du/izat3L9++fv8CDix4MOHChg8jTqx4MePGjh9Djix5MuXKli9jzqx5M+fOnj+DDi16 NOnSpk+jTq16NevWrl/Dji17Nu3atsUaWODAAYMEKxIkMNDFAPAXCXY78K2CuHAVCIq/YG5c OXHg1oELr349+PLt1pt3945dRQIGuxeAF1Z+N4P04ou/h/5nfDD6JaQv181bOTIE5nkjsIJ2 34U3H3fdIYf/noHgxSecfQD4x16ABf524Hz/WQgAfuTxV8J6Dih4X3wavpceawlEEMEDDqT4 gAosmqhhBA4sl+KMNjaHIn8oRtChhz2+kOKPNhLpG49Eppgjkjb6aMCSOGr4QIoOSBnBAurZ SGWKDKjwpJAsPknjH06qKMyUvwFZwgItgvlAjC+2WKWYMi7JpYxzrgCjCmuqCGaa5G3ZpZe+ 6VlCm3LW+CcAhUaXZZU7KgqAkPfJWeWVABy5JKaDvkZmcwZIeSmjNc6ZIn8MlLmpcjz6+KOP k+pY358GoCpmrOfcqoKUdtLZaq+JKjcpMsJimWQwTAK6qrEloOriH81+uut9MyYa/6CTeMKp ZAQMLmuojcNRm+e2zKoYbQR2kjmut28GOqSSr0ag67nAvjBqrrNJ2aGTzo46rZhr8lqCsbGy Kiu8rhocZLyqznMvigHT+WykKIpJ7LELI5PvvH8Q+a7A6sLZ6r5dGHvtCmv6ZnIXhXZLLn/7 otwotnqOrHB2Njq7KMiAQkwxwivAunGi9e58r2wWa5gtuGJKaSK3wJmK5cEMz6comT9/c6+U E66wNckYCygoNUi/gMC8ZEt6brixmp2zc6mebGUXa16psst3/kEz3Mulh3LNpBItHN1zy71v vut24bXCWH9cguJdR8C1zu5FCpvdee/sb+NYIso5crsFnf/cdj+2ZwBx0m4q+nXI3Et2zALu zXGP25mItgqoBvj64lETXHnaK2cOIbX7Wseis5crjeKlwy7cNOwzj9uv8DRe6+nkX2PuYKST uq6ovTN612m4wUivsu2bFun550E/OSSSc2ZKJOuKkm203cd9/vGSUwdT899Ax4tHDDPa5sQV I5Oli0hiQh7icqWf85AugoAz4PVkhrdaVRCA2aOa2H7XhXt9r32u+R/wDhiu87GKR2/i4OYI SDoDIAB1jKNG68C2p0j9DX9gKqCZbPgCPiEnRZLbHIt6AyTlyQ54Q5we3u6DQQZeD4lq2o2U mNYnLYENeXpi0RLNRr0T9kh6ZHP/ntG450MA6C6DLDyaDx/gJjVqTmdDZMADjCQ3ADQrYRpc Y7LkBSlfSW0FqGqV82yGPQ8yj3mfk2EHyXQ4Eqbug0K7HZCQJyQo6s1tmiPTImc1vgZO8m4q M5uKgseiJgVteZsbZOJ29j1AuoaVb1tY+db2SevlipF93KMLOWg9Ps6vQyjS5DAlBjEPno+H xoldyxB5JOUcDnIia5n1Lnc1TKormm+jEapU2bYJKu2X0xqX3VDVzE0562GostM3AZXO2BWT grukDZkUVDCdBcd0pmsiAKqYnSpijUytKuPCHqbPg7JwTe8s3UFXuEbjWUuFF3PAhBJQpY81 dJ97xJyP/2TZQW+lSaDCieEn0ZSme+5LnxadV0obWkEytYdEgWpmIbWornui9JNQAp6bQLXT tD0AAbmJmreCKtPMfY+hCBUfkpbnJ/nZzacKnCf6TERQ971vjYeLX5YC+QJz4myJy3nqlprj pZ2h7WplY2YWiQqhKtnomCZN3zizSickEQpkUk1fPOOGrpIyiqsv+yQpVwhWIsX0rnH9KpKM Gri52hU2z3lQRjWq0fBkSJ/Ruex9OKuhT1V2n5oVkGhD69DRRsc6Yh3OddJj2s0Kw7OdhS1p TTTZDKnHOsNxaW1dKlvtcA21pOUbbSskH+ION7aqNcApV3DbNwG3f0577W2qG60bh1o3u9rd rlPO6t3vgje84h0vectr3vOiN73qXS972+ve98JXvNgFjWnra9/74je/+t0vf/vr3/8COMAC HjCBC2zgA+eXuwpeMIMb7OAHQzjCEp4whSts4T6tZMMa3jCHO+zNhlW4xCIeMYlLbOITozjF Kl4xi1vs4hfDOMYynjGNa23SwMM4xzreMY581OMbWulIQh4ykYts5CMjOclKXjKTm+zkJ0M5 yogJAQA7 --------------JavaMail.868197025481-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:13:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01gz-0001dX-Vp for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:13:02 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11519 for ; Fri, 20 Jan 2006 14:11:34 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id EEA48430118 for ; Fri, 20 Jan 2006 11:12:59 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id B40C343009A for ; Fri, 20 Jan 2006 11:12:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9C79F80C13A for ; Fri, 20 Jan 2006 11:12:33 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by hermes.tigertech.net (Postfix) with ESMTP id C237D80C127 for ; Fri, 20 Jan 2006 11:12:31 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2006 11:12:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0KJCUQm008552; Fri, 20 Jan 2006 11:12:31 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 11:12:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Additional Comments on LWAPP Date: Fri, 20 Jan 2006 11:12:18 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437D76@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Additional Comments on LWAPP Thread-Index: AcYBB9Hpbdh1FGdKTeeL9oLQHvwYfgbZgoXg From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 20 Jan 2006 19:12:19.0298 (UTC) FILETIME=[6EFE2420:01C61DF5] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable > General Comment: Radio ID's are limited to be between 0 and=20 > 7 inclusive.=20 > The definition of Radio ID in the fields should show this=20 > limited range -- one byte allocated but only 8 values allowed. A previous comment of yours caught caused me to catch this one already. It will be fixed in the first rev. >=20 > Page 35 -- 5.2.1 AC address > I do not understand this. It is not useful with a layer 3=20 > transport. If using a layer 2 transport then I would assume=20 > the broadcast or multicast from the Discovery Message would=20 > have been heard by any other AC's -- so rather than respond=20 > -- would it not be best to stay silent? I believe you are correct that this information element is not required for layer 3, and can be removed. I've added this to tracker. >=20 > General Comment: Is there a case where one has a simple=20 > discovery agent running in dumb hardware -- its only purpose=20 > is to redirect the WTP to the real AC? There seems to be=20 > hints of this possibility but it is not spelled out. There are many things one can do with the protocol, but I think we=20 should leave implementors determine what they can, and cannot, do. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip.Rakity@u4eatech.com [mailto:Philip.Rakity@u4eatech.com]=20 > Sent: Wednesday, December 14, 2005 3:40 PM > To: capwap@frascone.com > Subject: [Capwap] Additional Comments on LWAPP >=20 >=20 >=20 >=20 >=20 > Philip >=20 >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:20:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01o3-000426-UL for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:20:20 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12076 for ; Fri, 20 Jan 2006 14:18:51 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 29C364300F9 for ; Fri, 20 Jan 2006 11:20:17 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 08EC143009A for

------_=_NextPart_001_01C61DF8.039268F5-- --===============0566476127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0566476127==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:35:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F022y-00024T-9M for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:35:44 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13268 for ; Fri, 20 Jan 2006 14:34:16 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4E61E430127 for ; Fri, 20 Jan 2006 11:35:42 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 83CE043009A for ; Fri, 20 Jan 2006 11:35:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 715EC80C13A for ; Fri, 20 Jan 2006 11:35:19 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by hermes.tigertech.net (Postfix) with ESMTP id EE21780C138 for ; Fri, 20 Jan 2006 11:35:17 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2006 11:35:17 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="394328982:sNHT29808404" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KJZHWF008730; Fri, 20 Jan 2006 11:35:17 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 11:35:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Questions regarding LWAPP draft v03 Date: Fri, 20 Jan 2006 11:35:16 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437D9C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Questions regarding LWAPP draft v03 Thread-Index: AcYc4a+gr9vzgFp2Q/SRfBE/LCm2FABFpJKg From: "Pat Calhoun (pacalhou)" To: "BOURDON Gilles RD-CORE-ISS" , X-OriginalArrivalTime: 20 Jan 2006 19:35:17.0499 (UTC) FILETIME=[A476ECB0:01C61DF8] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable 1- The Control Message format (section 4.2.1) indicates the message type is 8-bit encoded. Don't you think this numbering space could be too small, for further extensions? The section might also mention how this numbering space is managed (IANA?). Same thing for section 4.2.2. (Message Element Format), refering to section 16 which is empty. Created tracker entry 44 2- I know that the evaluation team asked for an extension of the Type field. It might seem obvious, but I think that having its length equal to the Element ID field of the Vendor-Specific element would make sense. This request already exists by the eval team, and has already been taken care of. 3- I cannot figure out why Clear Config Indication is the only message that doesn't need acknowledgment from the WTP. Any particular reason? Indication messages are acknowledged at the reliable link layer, and no response is required. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:37:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F024K-0002ee-Uq for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:37:09 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13375 for ; Fri, 20 Jan 2006 14:35:41 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A504543015C for ; Fri, 20 Jan 2006 11:37:07 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 9BAF94300B4 for ; Fri, 20 Jan 2006 11:36:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 7E660398033 for ; Fri, 20 Jan 2006 11:36:47 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by zoidberg.tigertech.net (Postfix) with ESMTP id 66C0F398032 for ; Fri, 20 Jan 2006 11:36:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id E41E83601C5; Fri, 20 Jan 2006 19:22:45 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Fri, 20 Jan 2006 19:22:45 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id D08433601CF; Fri, 20 Jan 2006 19:22:45 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24372-09; Fri, 20 Jan 2006 19:22:42 +0000 (GMT) Received: from [172.16.4.50] (rrcs-67-52-95-254.west.biz.rr.com [67.52.95.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.u4eatech.com (Postfix) with ESMTP id 10A3E3601C5; Fri, 20 Jan 2006 19:22:41 +0000 (GMT) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A201437D7E@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A201437D7E@xmb-sjc-235.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E0382AA-3B8D-4410-914B-0C37BE2B5D3A@u4eatech.com> Content-Transfer-Encoding: 7bit From: Philip Rakity Date: Fri, 20 Jan 2006 11:36:31 -0800 To: capwap@frascone.com X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] MTU Discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit I understand the LWAPP will no longer layer 2 transport. Is there any reason why we should just not require MTU discovery and remove the option from the spec. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:38:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F025v-00034Q-On for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:38:49 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13546 for ; Fri, 20 Jan 2006 14:37:19 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A5B7543010B for ; Fri, 20 Jan 2006 11:38:45 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 469F94300B4 for ; Fri, 20 Jan 2006 11:38:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 37F7580C13B for ; Fri, 20 Jan 2006 11:38:00 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by hermes.tigertech.net (Postfix) with ESMTP id 8D8E780C106 for ; Fri, 20 Jan 2006 11:37:54 -0800 (PST) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 11:37:53 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208,217"; a="250374868:sNHT59047552" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0KJboQZ016560; Fri, 20 Jan 2006 11:37:53 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 11:37:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Addition to MIB issue Date: Fri, 20 Jan 2006 11:37:45 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437DA0@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Addition to MIB issue Thread-Index: AcYcehnLehEPfW3lSAGbqYvk46RYQQA/B0NQACCreEA= From: "Pat Calhoun (pacalhou)" To: "Richard Gwee" , X-OriginalArrivalTime: 20 Jan 2006 19:37:46.0798 (UTC) FILETIME=[FD7424E0:01C61DF8] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.608 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594811323==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0594811323== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61DF8.FD2EF2D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61DF8.FD2EF2D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, =20 Sorry, you've lost me, but the original request was to provide a pointer of some form to the IEEE MIB variables. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Thursday, January 19, 2006 8:11 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: [Capwap] Addition to MIB issue =09 =09 Hi Pat, =20 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. =20 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. =20 Thanks and regards Richard =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 5:57 AM To: capwap@frascone.com Subject: [Capwap] Done w/ Issue Tracker =20 All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =09 ________________________________ =09 =09 Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 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) ________________________________ =09 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. =09 ------_=_NextPart_001_01C61DF8.FD2EF2D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

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

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Richard Gwee = [mailto:richard_gwee@rp.sg]=20
Sent: Thursday, January 19, 2006 8:11 PM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: [Capwap] Addition = to MIB=20 issue

Hi=20 Pat,

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

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

Thanks and=20 regards

Richard

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January 19, = 2006 5:57=20 AM
To:=20 capwap@frascone.com
Subject:=20 [Capwap] Done w/ Issue Tracker

All,

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

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

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

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

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

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

= ------_=_NextPart_001_01C61DF8.FD2EF2D7-- --===============0594811323== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0594811323==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:41:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0285-0003ea-87 for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:41:03 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13697 for ; Fri, 20 Jan 2006 14:39:33 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E968C4300CB for ; Fri, 20 Jan 2006 11:40:59 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id E89A74300B4 for ; Fri, 20 Jan 2006 11:40:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D5151398044 for ; Fri, 20 Jan 2006 11:40:36 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1FED9398029 for ; Fri, 20 Jan 2006 11:40:35 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2006 11:40:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0KJeXkH004038; Fri, 20 Jan 2006 11:40:34 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 11:40:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jan 2006 11:40:32 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437DA6@xmb-sjc-235.amer.cisco.com> Thread-Topic: MTU Discovery Thread-Index: AcYd+N4K37zLnZi5SEyWbMX3O5w8EgAAG62Q From: "Pat Calhoun (pacalhou)" To: "Philip Rakity" , X-OriginalArrivalTime: 20 Jan 2006 19:40:33.0448 (UTC) FILETIME=[60C8EA80:01C61DF9] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Subject: [Capwap] RE: MTU Discovery X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable No, we've agreed to do application layer fragmentation/reassembly, and therefore we have a need to identify the link layer's MTU size. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip Rakity [mailto:philip.rakity@u4eatech.com]=20 > Sent: Friday, January 20, 2006 11:37 AM > To: capwap@frascone.com > Cc: Pat Calhoun (pacalhou) > Subject: MTU Discovery >=20 >=20 > I understand the LWAPP will no longer layer 2 transport. Is=20 > there any reason why we should just not require MTU discovery=20 > and remove the option from the spec. >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:42:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F029B-0004Ai-4X for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:42:09 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13825 for ; Fri, 20 Jan 2006 14:40:41 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 28A1F430130 for ; Fri, 20 Jan 2006 11:42:07 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 60F934300B4 for ; Fri, 20 Jan 2006 11:41:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 4CF05398032 for ; Fri, 20 Jan 2006 11:41:30 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2A2C1398029 for ; Fri, 20 Jan 2006 11:41:25 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2006 11:41:25 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208,217"; a="394331886:sNHT64027158" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0KJfPjt004348; Fri, 20 Jan 2006 11:41:25 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 11:41:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jan 2006 11:41:22 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201437DAB@xmb-sjc-235.amer.cisco.com> Thread-Topic: Issue on Combining messages Thread-Index: AcYdeVjf9PrOg89YQ9+rTfh33uJntQAgCHHA From: "Pat Calhoun (pacalhou)" To: "Richard Gwee" X-OriginalArrivalTime: 20 Jan 2006 19:41:23.0510 (UTC) FILETIME=[7E9FC560:01C61DF9] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=3.635 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_60_70, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, RCVD_IN_BL_SPAMCOP_NET X-Spam-Level: *** Cc: capwap@frascone.com Subject: [Capwap] RE: Issue on Combining messages X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2040896929==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============2040896929== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61DF9.7E45EFB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61DF9.7E45EFB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 45 created. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Thursday, January 19, 2006 8:24 PM To: Pat Calhoun (pacalhou) Cc: capwap@frascone.com Subject: Issue on Combining messages =09 =09 Hi Pat, =20 I will like to propose a new thread on the issue tracker. Appreciate if you can help to add it in. =20 Issue: =20 Currently, the keepalive and statistics messages are separated. Separate messages for keepalive signaling and statistics can lead to high overhead. Initial analysis have shown that these overhead can be reduced significantly if the messages can be combined. =20 Recommendation: =20 To combine the keepalive and statistics message into one combined message, thus reducing overhead significantly. =20 Thanks and regards Richard =09 ________________________________ =09 =09 Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 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) ________________________________ =09 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. =09 ------_=_NextPart_001_01C61DF9.7E45EFB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Issue=20 45 created.

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Richard Gwee = [mailto:richard_gwee@rp.sg]=20
Sent: Thursday, January 19, 2006 8:24 PM
To: Pat = Calhoun=20 (pacalhou)
Cc: capwap@frascone.com
Subject: Issue = on=20 Combining messages

Hi = Pat,

I will like to propose a = new=20 thread on the issue tracker. Appreciate if you can help to add it=20 in.

Issue:

Currently, the keepalive = and=20 statistics messages are separated. Separate messages for keepalive = signaling=20 and statistics can lead to high overhead. Initial analysis have shown = that=20 these overhead can be reduced significantly if the messages can be=20 combined.

Recommendation:

To combine the keepalive = and=20 statistics message into one combined message, thus reducing overhead=20 significantly.

Thanks and=20 regards

Richard

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

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

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

= ------_=_NextPart_001_01C61DF9.7E45EFB4-- --===============2040896929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============2040896929==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Fri Jan 20 14:59:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02PU-0001oY-NU for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:59:00 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14946 for ; Fri, 20 Jan 2006 14:57:33 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3137B4300B0 for ; Fri, 20 Jan 2006 11:58:59 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 722F44300C9 for ; Fri, 20 Jan 2006 11:58:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id D6F2E398044 for ; Fri, 20 Jan 2006 11:58:24 -0800 (PST) Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by zoidberg.tigertech.net (Postfix) with ESMTP id 64ADB39804C for ; Fri, 20 Jan 2006 11:58:19 -0800 (PST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0KJvt3v011064 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 20 Jan 2006 14:58:05 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0KJvrob012403 for ; Fri, 20 Jan 2006 14:57:53 -0500 (EST) To: capwap@frascone.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: Michael Lohman Date: Fri, 20 Jan 2006 14:57:58 -0500 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 6.5.1|January 21, 2004) at 01/20/2006 14:55:53, Serialize complete at 01/20/2006 14:55:53 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.714 tagged_above=-999 required=7 tests=HTML_MESSAGE, HTML_SHORT_LENGTH Subject: [Capwap] Re: Capwap Digest, Vol 3, Issue 26 X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896167229==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multipart message in MIME format. --===============0896167229== Content-Type: multipart/alternative; boundary="=_alternative 006DAD5B852570FC_=" This is a multipart message in MIME format. --=_alternative 006DAD5B852570FC_= Content-Type: text/plain; charset="us-ascii" unsubsribe help --=_alternative 006DAD5B852570FC_= Content-Type: text/html; charset="us-ascii"
unsubsribe help --=_alternative 006DAD5B852570FC_=-- --===============0896167229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0896167229==-- From bonatiphan@demmon.com.br Fri Jan 20 22:39:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F09am-0003HO-KT for capwap-archive@megatron.ietf.org; Fri, 20 Jan 2006 22:39:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26169 for ; Fri, 20 Jan 2006 22:37:40 -0500 (EST) Received: from [218.150.64.11] (helo=demmon.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F09jb-0001Oh-JR for capwap-archive@ietf.org; Fri, 20 Jan 2006 22:48:18 -0500 Message-ID: <000001c61e3c$31a05520$4719a8c0@waiter> Reply-To: "Tiphanie Bonaparte" From: "Tiphanie Bonaparte" To: "York Shugart" Subject: A dditional info Ph aramacy Date: Fri, 20 Jan 2006 22:38:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C61E12.48CC9710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C61E12.48CC9710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 http://www.operorsan.com =20 =20 VAL Xan CIA Amb VIA Som IUM ax=20 LIS ien GRA a =20 from=20 $1, $1, $3, $2, $3, $1, 21 42 75 89 75 12 =20 ------=_NextPart_000_0001_01C61E12.48CC9710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.operorsan.com

VAL
Xan
CIA
Amb
VIA
Som

IUM
ax
LIS
ien
GRA
a
=

from

$1,
$1,
$3,
$2,
$3,
$1,

21
42
75
89
75
12

------=_NextPart_000_0001_01C61E12.48CC9710-- From info@mail.ecnq.com Sat Jan 21 01:06:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0BtS-0000IZ-4Z for capwap-archive@megatron.ietf.org; Sat, 21 Jan 2006 01:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04018 for ; Sat, 21 Jan 2006 01:05:04 -0500 (EST) Received: from ip-127-133-66-202.rev.dyxnet.com ([202.66.133.127] helo=mail.ecnq.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0C2F-00056p-Ah for capwap-archive@ietf.org; Sat, 21 Jan 2006 01:15:44 -0500 Received: (qmail 30827 invoked by uid 509); 21 Jan 2006 14:04:16 +0900 Date: 21 Jan 2006 14:04:16 +0900 Message-ID: <20060121050416.30826.qmail@mail.ecnq.com> From: info@ecnq.com To: capwap-archive@ietf.org Subject: $B5.J}$X$NLsB+(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 $B!X5<;w6a?FAj4/4jK>!Y!X#H%U%l%s%I4jK>!Y(B $B!X#M=wD4654jK>!Y!X%(%m%a%$%I4jK>!Y(B http://www.bfzu.com?1231 $B?M$=$l$>$l!"%7!<%/%l%C%H$K$7$?$$;v$O?'!9!*(B $B"#5.J}$X$NLsB+(B $B"((BH$B$X$N$*Ni6b$OI,$:$*;YJ'$$$7$^$9!#4pK\E*$K$O$44uK>3[(B $B$r$*;YJ'$$$7$?$$$H;W$$$^$9$,!"(BH1$B2s(B20$BK|1_$H;W$C$FD:$1$l$P(B $B$H;W$$$^$9!#(B $B"((BH$B$OK\Ev$K9%$-$G$9!#$I$s$J(BH$B$b5q$_$^$;$s!"Bt;365$($F!"(B $B65$(9g$C$F!"=c?h$K0&$79g$($k;~4V$r2a$4$7$?$$!#!#!#(B $B",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",!!",(B $BEv%0%k!<%W$K9b3[G<@G$7$?$$$H8@$C$F$*$j$^$9$N$G$*AjA0$N8e$K!Z(B H $B![$*IU$12<$5$$!#(B $B@^$jJV$7=w@-$+$iJV;v$,FO$-$^$9$N$G%W%l%$!@\(B $B$*Fs?M$G$*7h$a2<$5$$!#(B $B$*; Sat, 21 Jan 2006 08:38:10 -0500 (EST) Received: from [202.127.114.21] (helo=mail.irbj.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0J6m-0000ie-Tf for capwap-archive@ietf.org; Sat, 21 Jan 2006 08:48:53 -0500 Received: (qmail 27557 invoked by uid 509); 21 Jan 2006 21:48:06 +0900 Date: 21 Jan 2006 21:48:06 +0900 Message-ID: <20060121124806.27556.qmail@mail.irbj.com> From: info@irbj.com To: capwap-archive@ietf.org Subject: ($BL5NA(BID$B!&L5NA%Q%9(B)$BH/9T$G!"=P2q$$L5NAF~>lL5NA(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a $B%5%$%HFb!Z40A4L5NA![EPO?8e%a!<%k$N$d$j$7$?$$$H8@$C$F$*$j$^$9!#(B $BJV?.4|8B$O(B7$BF|4V!*(BVIP$B=w@-%G!<%?$NM%@h$40FFb$NEE!&D>%a![Ey$G!Z$_$5$-![MM$H$*LsB+$r(B $B$*; Sat, 21 Jan 2006 11:19:24 -0500 (EST) Received: from [85.97.79.231] (helo=futurescape.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0Lct-00056I-S7 for capwap-archive@ietf.org; Sat, 21 Jan 2006 11:30:09 -0500 Message-ID: <000001c61ea6$969eed00$a780a8c0@mores> Reply-To: "Meg Currey" From: "Meg Currey" To: "Naseer Renner" Subject: Re: infection Ph aramacy Date: Sat, 21 Jan 2006 11:20:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C61E7C.ADC8E500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.3 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C61E7C.ADC8E500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 He miss Phar ss S fer! =09 llo Don't maExpre pecial Of=09 =20 Amb Lev VIA Xan CIA VAL ien itra GRA Now $ ax LIS Now $ IUM Now $ =20 =20 3.33 =20 3.75 1.21 =20 =20 plus other - http://www.exterasite.com =20 =20 Home Best Fast Easy Delivery Prices Shipping Ordering =20 ------=_NextPart_000_0001_01C61E7C.ADC8E500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= He		=0A= miss Phar		=0A= ss S		=0A= fer!
=0A= llo Don't	=0A= maExpre	=0A= =0A= pecial Of

=0A=

=0A= =0A= =0A= =0A= =0A= =0A= =0A=

=0A= Amb
Lev
VIA
Xan
CIA
VAL

=0A= ien
itra
GRA Now $
ax
LIS Now $
IUM Now = $

=0A=

3.33

3.75
1.21<= /FONT>

=0A=

plus other - http://www.exterasite.com

=0A=

=0A= =0A= =0A= =0A= =0A=

=0A= Home
Best
Fast
Easy

=0A= Delivery
Prices
Shipping
Ordering

------=_NextPart_000_0001_01C61E7C.ADC8E500-- From info@mail.daisuki-coco.net Sun Jan 22 14:28:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ksw-0006S9-TG for capwap-archive@megatron.ietf.org; Sun, 22 Jan 2006 14:28:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11547 for ; Sun, 22 Jan 2006 14:26:52 -0500 (EST) Received: from [202.127.114.238] (helo=mail.daisuki-coco.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F0l27-000161-C4 for capwap-archive@ietf.org; Sun, 22 Jan 2006 14:37:52 -0500 Received: (qmail 27214 invoked by uid 509); 23 Jan 2006 00:49:37 +0900 Date: 23 Jan 2006 00:49:37 +0900 Message-ID: <20060122154937.27213.qmail@mail.daisuki-coco.net> From: info@daisuki-coco.net To: capwap-archive@ietf.org Subject: $B!!59$7$$$G$9$+!)(B X-Spam-Score: 4.9 (++++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 $B$*K;$7$$$H$3$m?=$7LuM-$j$^$;$s$,!"(B <$B!!(Bhttp://www.livedear1.com?num=1210 >$B!!$NCO0h0[@->R2p$rC4(B $BEv$7$F$$$kAa:d!!M';R$H?=$7$^$9$,!":#2sCO0h>R2pBP>]Jg=8$N7o$K(B $B$D$$$F$4O"Mm$5$;$FD:$-$^$7$?!#(B $B:#2s$N$4>7BT$K$"$?$C$F!"Ev7BT$G$9$N$G!"G[?.$5$l$?%"%I%l%9$G$NEPO?NA5Z$S(B $B>7BTNA$J$I0l@ZL5NA$H@_Dj$5$;$FD:$-$^$7$?!#$=$l$@$1$G$O$J$/!"(B $B"c(B1,000$B1_J,"d$N%5!<%S%9%]%$%s%H$bEPO?D>8e$K<+F0DI2C$HCW$7$^(B $B$9!#99$K-d3NG'(B($BIT@5@A5a$J$I$N0-MQ$O0l@Z$4$6$$$^$;$s$N$G!"$4(B $B0B?42<$5$$(B)$B$r9T$C$?D>8e!"BgNL(B(12,000$B1_J,(B)$B$NL5NA%]%$%s%H$b(B24 $B;~4VBP1~$GDI2CCW$7$^$9!#(B $B""5.J}$NEPO?>pJs$rF1CO0h0[@-$X?o;~DLC#CW$7$^$9$N$G!"0[@-$+$i(B $B$N%a!<%k$,D>@\5.J}$NJ}$KFO$-$^$9!#EvHVAH$G$O0[@-A4$F$N>pJs$r(B $B3NG'2DG=$H$J$C$F$*$j$^$9!#(B $B"#CK@-$NJ}$J$i!"KhF|4uK>CO0h$+$i:GDc#1L>$N5U!_=u4uK>=w@-$rL5(B $BNA$G$4>R2pCW$7$^$9!#(B($BEvHVAH$K$4>R2p$5$l$?>l9g$O:GDc6b3[#5K|(B $B$K$J$C$F$*$j$^$9!#(B) $B8"Mx3+;O"*!!(B<$B!!(Bhttp://www.livedear1.com?num=1210 > $B"(?M?t8BDj$N$4>7BT$G$9$N$G!"<+F0GQ4~$HG'$a$?>l9g$O8"Mx2s<}$H(B $B$J$j$^$9$N$G!"$J$k$Y$/%a!<%k3+Iu$7$F(B24$B;~4V0JFb$K$4EPO?$r40@.(B $B$9$k$h$&$*4j$$CW$7$^$9!#(B $B5qH]$O:!J}(B $B!J(BPlease inform the following address if this mail is unnecessary.$B!K(B cancel@livedear.com From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 23 06:12:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0zce-00059w-5B for capwap-archive@megatron.ietf.org; Mon, 23 Jan 2006 06:12:32 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07892 for ; Mon, 23 Jan 2006 06:11:01 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id C098C4300B2 for ; Mon, 23 Jan 2006 03:12:29 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 44BA143006B for ; Mon, 23 Jan 2006 03:11:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3195980C0F8 for ; Mon, 23 Jan 2006 03:11:45 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 26AB280C0EE for ; Mon, 23 Jan 2006 03:11:42 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITJ00LK8LKNVT@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 23 Jan 2006 03:07:36 -0800 (PST) Received: from huawei.com ([172.17.1.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITJ00CDNLKM05@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 23 Jan 2006 03:07:35 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Mon, 23 Jan 2006 16:10:51 +0500 Date: Mon, 23 Jan 2006 16:10:51 +0500 From: zhaoyujin 31390 Subject: Re:[Capwap] RE: Local-MAC & Split-MAC Negotiations To: "Pat Calhoun (pacalhou)" Message-id: <59cc2459f509.59f50959cc24@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.286 tagged_above=-999 required=7 tests=HTML_MESSAGE, MIME_HTML_MOSTLY Cc: Saravanan Govindan , capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg) Content-type: text/plain; charset=gb2312 Content-disposition: inline Content-Transfer-Encoding: quoted-printable Dear all For this feature Section 11=2E9=2E12 =22IEEE 802=2E11 WTP Mode and Type=22 Can LWAPP redefine the type=3A (Next LWAPP can extend to manage all types= of AP) 0 - Split MAC 1 - Remote MAC 2 - Local MAC 3 - Fat AP Next give comments=3A = The encapsulated data should be in the form of 802=2E3 for Fat AP and L= ocal MAC=2E And the encapsulated data should be in the form of 802=2E11 = for Split AP and Remote MAC=2E Best regards Michael This request is already encompased in tracker entries 3 and 4=2C which I = have already addressed and sent text earlier this week=2E = Pat Calhoun CTO=2C Wireless Networking Business Unit Cisco Systems = -------------------------------------------------------------------------= ------- From=3A Saravanan Govindan =5Bmailto=3ASaravanan=2EGovindan=40sg=2Epanaso= nic=2Ecom=5D = Sent=3A Wednesday=2C January 18=2C 2006 7=3A06 PM To=3A Pat Calhoun (pacalhou)=3B capwap=40frascone=2Ecom Subject=3A Local-MAC =26 Split-MAC Negotiations Pat=2C = Issue=3A The CAPWAP protocol is expected to support major WTP designs=2E It is imp= ortant for information on these design types to be exchanged during confi= guration so that subsequent protocol operations are consistent and accura= te=2E = = My recommendation=3A To specify WTP characteristics as part of Discovery state (draft-ohara-ca= pwap-lwapp-03=2Etxt) Section 5=2E The following message elements to be in= cluded to Discovery Request (draft-ohara-capwap-lwapp-03=2Etxt) Section 5= =2E1=3B = MAC Type =A8C Split-MAC=2C Local-MAC MAC Frame Type =A8C Native (IEEE 802=2E11)=2C IEEE 802=2E3=2C No frames (= local bridging) IEEE 802=2E11i Design =A8C Encryption =26 Authenticator on same entity=2C= Encryption on WTP =26 Authenticator on AC = = = Saravanan = -------------------------------------------------------------------------= ------- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F To unsubscribe or modify your subscription options=2C please visit=3A http=3A//lists=2Efrascone=2Ecom/mailman/listinfo/capwap Archives=3A http=3A//lists=2Efrascone=2Ecom/pipermail/capwap = = --Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg) Content-type: multipart/alternative; boundary="Boundary_(ID_BlpTjlVqlTd+z7sLZDzxtg)" Content-class: urn:content-classes:message --Boundary_(ID_BlpTjlVqlTd+z7sLZDzxtg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT This request is already encompased in tracker entries 3 and 4, which I have already addressed and sent text earlier this week. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com] Sent: Wednesday, January 18, 2006 7:06 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Local-MAC & Split-MAC Negotiations Pat, Issue: The CAPWAP protocol is expected to support major WTP designs. It is important for information on these design types to be exchanged during configuration so that subsequent protocol operations are consistent and accurate. My recommendation: To specify WTP characteristics as part of Discovery state (draft-ohara-capwap-lwapp-03.txt) Section 5. The following message elements to be included to Discovery Request (draft-ohara-capwap-lwapp-03.txt) Section 5.1; MAC Type - Split-MAC, Local-MAC MAC Frame Type - Native (IEEE 802.11), IEEE 802.3, No frames (local bridging) IEEE 802.11i Design - Encryption & Authenticator on same entity, Encryption on WTP & Authenticator on AC Saravanan --Boundary_(ID_BlpTjlVqlTd+z7sLZDzxtg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

This request is already encompased in tracker entries 3 and 4, which I have already addressed and sent text earlier this week.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

From: Saravanan Govindan [mailto:Saravanan.Govindan@sg.panasonic.com]
Sent: Wednesday, January 18, 2006 7:06 PM
To: Pat Calhoun (pacalhou); capwap@frascone.com
Subject: Local-MAC & Split-MAC Negotiations

Pat,

Issue:

The CAPWAP protocol is expected to support major WTP designs. It is important for information on these design types to be exchanged during configuration so that subsequent protocol operations are consistent and accurate.

My recommendation:

To specify WTP characteristics as part of Discovery state (draft-ohara-capwap-lwapp-03.txt) Section 5. The following message elements to be included to Discovery Request (draft-ohara-capwap-lwapp-03.txt) Section 5.1;

MAC Type – Split-MAC, Local-MAC

MAC Frame Type – Native (IEEE 802.11), IEEE 802.3, No frames (local bridging)

IEEE 802.11i Design – Encryption & Authenticator on same entity, Encryption on WTP & Authenticator on AC

Saravanan

--Boundary_(ID_BlpTjlVqlTd+z7sLZDzxtg)-- --Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Content-Transfer-Encoding: 7BIT _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --Boundary_(ID_3RKo2ulpdPSkQR6oaxTlTg)-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 23 08:55:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12Ah-0002om-VA for capwap-archive@megatron.ietf.org; Mon, 23 Jan 2006 08:55:52 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19540 for ; Mon, 23 Jan 2006 08:54:20 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9F40B4300DB for ; Mon, 23 Jan 2006 05:55:49 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 2C500430058 for ; Mon, 23 Jan 2006 05:55:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1ECAF39801B for ; Mon, 23 Jan 2006 05:55:02 -0800 (PST) Received: from staff-mail.rp.edu.sg (staff-mail.rp.edu.sg [202.21.158.80]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1111139806C for ; Mon, 23 Jan 2006 05:54:55 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Subject: RE: [Capwap] Addition to MIB issue Date: Mon, 23 Jan 2006 21:54:49 +0800 Message-ID: <9C374CF75527504394E573E1937136C4022A85E8@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] Addition to MIB issue thread-index: AcYcehnLehEPfW3lSAGbqYvk46RYQQA/B0NQACCreEAAipnZUA== From: "Richard Gwee" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.001 tagged_above=-999 required=7 tests=HTML_MESSAGE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1216824942==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============1216824942== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62024.95297932" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62024.95297932 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 9DD6115D-D980-4AB8-B957-A2EB7A17EEC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pat, =20 I am sorry over the confusion. In this case, can you create an issue thread? =20 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. =20 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. =20 Thanks and regards Richard =20 =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, January 21, 2006 3:38 AM To: Richard Gwee; capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =20 Richard, =20 Sorry, you've lost me, but the original request was to provide a pointer of some form to the IEEE MIB variables. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Thursday, January 19, 2006 8:11 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: [Capwap] Addition to MIB issue Hi Pat, =20 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. =20 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. =20 Thanks and regards Richard =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 5:57 AM To: capwap@frascone.com Subject: [Capwap] Done w/ Issue Tracker =20 All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =09 ________________________________ Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 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) =09 ________________________________ 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.=20 =20 ------_=_NextPart_001_01C62024.95297932 X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: D5CEF3DD-FA87-4B67-8B19-5090D58D857E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:pcalhoun@cisco.com]
Sent: Saturday, January = 21, 2006 3:38 AM
To: Richard Gwee; capwap@frascone.com
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:richard_gwee@rp.sg]
Sent: Thursday, January = 19, 2006 8:11 PM
To: Pat Calhoun = (pacalhou); capwap@frascone.com
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:pcalhoun@cisco.com]
Sent: Thursday, January = 19, 2006 5:57 AM
To: = capwap@frascone.com
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= . 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.

------_=_NextPart_001_01C62024.95297932-- --===============1216824942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============1216824942==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 23 09:16:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12V9-0001Av-6K for capwap-archive@megatron.ietf.org; Mon, 23 Jan 2006 09:16:59 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22478 for ; Mon, 23 Jan 2006 09:15:27 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7CBB44300DA for ; Mon, 23 Jan 2006 06:16:57 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 5BDC6430058 for ; Mon, 23 Jan 2006 06:16:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 4349080C111 for ; Mon, 23 Jan 2006 06:16:00 -0800 (PST) X-Greylist-Status: Sender first seen 00:04:12 ago Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by hermes.tigertech.net (Postfix) with ESMTP id C4F8380C0EE for ; Mon, 23 Jan 2006 06:15:57 -0800 (PST) Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0ND9JFe010065 for ; Mon, 23 Jan 2006 08:09:19 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k0NDuTYj015504 for ; Mon, 23 Jan 2006 08:56:30 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Capwap] Addition to MIB issue MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 23 Jan 2006 16:11:39 +0200 Message-ID: Thread-Topic: [Capwap] Addition to MIB issue Thread-Index: AcYcehnLehEPfW3lSAGbqYvk46RYQQA/B0NQACCreEAAipnZUAAAvgIA From: "Romascanu, Dan (Dan)" To: "Richard Gwee" , "Pat Calhoun (pacalhou)" , X-Scanner: InterScan AntiVirus for Sendmail X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.234 tagged_above=-999 required=7 tests=HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0594134312==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0594134312== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62026.EDA339C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62026.EDA339C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 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.=20 =20 Regards, =20 Dan =20 =20 =20 =20 _____ =20 From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Monday, January 23, 2006 3:55 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =09 =09 Hi Pat, =20 I am sorry over the confusion. In this case, can you create an issue thread? =20 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. =20 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. =20 Thanks and regards Richard =20 =20 =09 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, January 21, 2006 3:38 AM To: Richard Gwee; capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =20 Richard, =20 Sorry, you've lost me, but the original request was to provide a pointer of some form to the IEEE MIB variables. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 _____ =20 From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Thursday, January 19, 2006 8:11 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: [Capwap] Addition to MIB issue Hi Pat, =20 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. =20 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. =20 Thanks and regards Richard =20 =09 _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, January 19, 2006 5:57 AM To: capwap@frascone.com Subject: [Capwap] Done w/ Issue Tracker =20 All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =09 _____ =20 Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 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) =09 _____ =20 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.=20 =20 ------_=_NextPart_001_01C62026.EDA339C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In other words, are you talking = about=20 defining a MIB? A SMIv2 definition of the management objects (for = 'monitoring=20 purposes, security purposes, congestion control, feedback etc') could be = used=20 either in-band with CAPWAP or out-of-band with=20 SNMP.

I would like to observe that the WG has a chartered item for = the=20 definition of a MIB module. It should go to WGLC this month actually. = The chairs=20 would probably ask for a time extension. =

Regards,

Dan

From: Richard Gwee = [mailto:richard_gwee@rp.sg]=20
Sent: Monday, January 23, 2006 3:55 PM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: RE: [Capwap] = Addition to=20 MIB issue

Hi=20 Pat,

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

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

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

Thanks and=20 regards

Richard

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Saturday, January 21, = 2006 3:38=20 AM
To: Richard = Gwee;=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Addition to MIB issue

Richard,

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

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

From:=20 Richard Gwee [mailto:richard_gwee@rp.sg]
Sent: Thursday, January 19, = 2006 8:11=20 PM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: [Capwap] Addition to = MIB=20 issue

Hi=20 Pat,

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

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

Thanks = and=20 regards

Richard

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January 19, = 2006 5:57=20 AM
To:=20 capwap@frascone.com
Subject: [Capwap] Done w/ = Issue=20 Tracker

All,

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

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

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

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

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

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

------_=_NextPart_001_01C62026.EDA339C2-- --===============0594134312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap --===============0594134312==-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 23 10:09:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13KA-0006Vi-6u for capwap-archive@megatron.ietf.org; Mon, 23 Jan 2006 10:09:42 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25920 for ; Mon, 23 Jan 2006 10:08:12 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 40EED4300F5 for ; Mon, 23 Jan 2006 07:09:39 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 1BD16430058 for ; Mon, 23 Jan 2006 07:08:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 2945A39801D for ; Mon, 23 Jan 2006 07:08:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by zoidberg.tigertech.net (Postfix) with ESMTP id 228A9398061 for ; Mon, 23 Jan 2006 07:08:34 -0800 (PST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2006 07:08:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0NF8WWF005716; Mon, 23 Jan 2006 07:08:32 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 07:08:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Addition to MIB issue Date: Mon, 23 Jan 2006 07:08:31 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A201438150@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Addition to MIB issue Thread-Index: AcYcehnLehEPfW3lSAGbqYvk46RYQQA/B0NQACCreEAAipnZUAAAvgIAAAIhZLA= From: "Pat Calhoun (pacalhou)" To: "Romascanu, Dan (Dan)" , "Richard Gwee" , X-OriginalArrivalTime: 23 Jan 2006 15:08:32.0169 (UTC) FILETIME=[DFC8A190:01C6202E] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.608 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565786703==" Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com This is a multi-part message in MIME format. --===============0565786703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6202E.DF7FF766" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6202E.DF7FF766 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, January 23, 2006 6:12 AM To: Richard Gwee; Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =09 =09 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. =20 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.=20 =20 Regards, =20 Dan =20 =20 =20 =20 ________________________________ From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Monday, January 23, 2006 3:55 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =09 =09 Hi Pat, =20 I am sorry over the confusion. In this case, can you create an issue thread? =20 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. =20 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. =20 Thanks and regards Richard =20 =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, January 21, 2006 3:38 AM To: Richard Gwee; capwap@frascone.com Subject: RE: [Capwap] Addition to MIB issue =20 Richard, =20 Sorry, you've lost me, but the original request was to provide a pointer of some form to the IEEE MIB variables. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Richard Gwee [mailto:richard_gwee@rp.sg]=20 Sent: Thursday, January 19, 2006 8:11 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: [Capwap] Addition to MIB issue Hi Pat, =20 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. =20 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. =20 Thanks and regards Richard =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, January 19, 2006 5:57 AM To: capwap@frascone.com Subject: [Capwap] Done w/ Issue Tracker =20 All, =20 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. =20 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. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =09 ________________________________ Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 . www.rp.sg . Fax: +65 6415-1310 .=20 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) =09 ________________________________ 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.=20 =20 ------_=_NextPart_001_01C6202E.DF7FF766 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Monday, January 23, 2006 = 6:12=20 AM
To: Richard Gwee; Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Addition to MIB=20 issue

In other words, are you talking = about=20 defining a MIB? A SMIv2 definition of the management objects (for = 'monitoring=20 purposes, security purposes, congestion control, feedback etc') could = be used=20 either in-band with CAPWAP or out-of-band with=20 SNMP.

I would like to observe that the WG has a chartered item for = the=20 definition of a MIB module. It should go to WGLC this month actually. = The=20 chairs would probably ask for a time extension.=20

Regards,

Dan

From: Richard Gwee=20 [mailto:richard_gwee@rp.sg]
Sent: Monday, January 23, = 2006 3:55=20 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Addition to MIB=20 issue

Hi=20 Pat,

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

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

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

Thanks = and=20 regards

Richard

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Saturday, January 21, = 2006 3:38=20 AM
To: Richard = Gwee;=20 capwap@frascone.com
Subject: RE: [Capwap] = Addition to MIB=20 issue

Richard,

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

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

From:=20 Richard Gwee [mailto:richard_gwee@rp.sg]
Sent: Thursday, January 19, = 2006 8:11=20 PM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: [Capwap] Addition = to MIB=20 issue

Hi=20 Pat,

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

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

Thanks = and=20 regards

Richard

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, January 19, = 2006 5:57=20 AM
To:=20 capwap@frascone.com
Subject: [Capwap] Done w/ = Issue=20 Tracker

All,

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

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

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

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

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

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

C i I v A s L q I & = S q

http://www.parlametan.com

; Fri, 27 Jan 2006 13:07:42 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADE50430108 for ; Fri, 27 Jan 2006 10:09:14 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 56EF943006D for ; Fri, 27 Jan 2006 10:08:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 41CE980C101 for ; Fri, 27 Jan 2006 10:08:48 -0800 (PST) Received: from htr2.enterasys.com (htr2.enterasys.com [63.160.138.51]) by hermes.tigertech.net (Postfix) with ESMTP id 3F13C80C0EB for ; Fri, 27 Jan 2006 10:08:38 -0800 (PST) Received: from NHROCAVG2.ets.enterasys.com (nhrocavg2 [134.141.79.124]) by htr2.enterasys.com (0.25.1/8.12.6) with ESMTP id k0RI27T5002155 for ; Fri, 27 Jan 2006 13:02:08 -0500 (EST) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 27 Jan 2006 13:08:35 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Fri, 27 Jan 2006 13:08:35 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 Jan 2006 13:08:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] lwapp-dtls edits Date: Fri, 27 Jan 2006 13:08:35 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B7F7@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Capwap] lwapp-dtls edits Thread-Index: AcYjYNMr3wVBX1hvRciS4Ci34erVtwAC2X5w From: "Nelson, David" To: "capwap" X-OriginalArrivalTime: 27 Jan 2006 18:08:35.0156 (UTC) FILETIME=[B084A140:01C6236C] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:79.5348 M:94.5022 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.024 tagged_above=-999 required=7 tests=RCVD_BY_IP X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Scott G. Kelly writes... [mailto:s.kelly@ix.netcom.com] > As for the PSK algorithms, the text currently says plain psk's must not be > used due to their vulnerability to dictionary attacks.. Some have > suggested this is too restrictive, and after thinking it over, I think I > agree. It seems like allowing plain psk's but adding the standard > admonishments regarding weak passphrases and dictionary attacks might make > sense. I don't have any problem with PSK methods, using suitable crypto-suites, key lengths, and key entropy. I would recommend including one of there. As you say, the risk is in generating keys from pass-phrases that have low entropy and are subject to dictionary attack.=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From fernandez@journalnow.com Fri Jan 27 15:00:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Zly-00023Q-D1; Fri, 27 Jan 2006 15:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09842; Fri, 27 Jan 2006 14:59:09 -0500 (EST) Received: from rob76-3-82-228-210-185.fbx.proxad.net ([82.228.210.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2Zw7-0003ZR-C8; Fri, 27 Jan 2006 15:11:16 -0500 Received: from [192.168.1.7] ([82.228.210.185]) by msn.com (Sendmail 8.7.2) with ESMTP (SSL) id IYT71414 for ; Wed, 28 Apr 2004 23:28:52 -0600 Message-ID: <418h254s.0055300@msn.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=abide; d=msn.com; b=udBnpdHgdgiwdThNeHSLsMHiZvzC7gM1Ax6Ppn5gmqC0MLd3rHqQV8yC0ow8ce0q5bpr6A25PdPVUF1w; X-Display: Full X-List: assassin.usenet Date: Wed, 28 Apr 2004 23:28:52 -0600 From: "Jeff Holland" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: calsch@ietf.org Subject: Notification: Loww ratess Content-Type: multipart/related; boundary="------------AttPart_54496788==.OLA" X-Spam-Score: 4.2 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --------------AttPart_54496788==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

or quash on turgid ! quarrel in deus the porterhouse be cervix and shiny see pacify but glum and haag but comparative may chain in toyota but deterring Or maybe not

--------------AttPart_54496788==.OLA Content-Type: image/gif; name="schantz.7.gif" Content-ID: <0.0.0.59.0.56878451592553.51066043@belong.msn.com.3> Content-Disposition: inline; filename="schantz.7.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1labt7hYGIcxnagd5USoGF5gg5Z5IiXfhhr5UeWbcJxevtl1DZe5QsaZt IWqL+9iCBs6Y3p0nUqOtCGqOl7zJvCzg5prhY9E3vvKdL33ra9/74MESQt0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_54496788==.OLA-- From info@mail.gsagh.com Sat Jan 28 00:55:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2j3j-0006wN-4m for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 00:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28694 for ; Sat, 28 Jan 2006 00:54:04 -0500 (EST) Received: from ip-208-133-66-202.rev.dyxnet.com ([202.66.133.208] helo=mail.gsagh.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2jDv-0000gd-0A for capwap-archive@ietf.org; Sat, 28 Jan 2006 01:06:17 -0500 Received: (qmail 9796 invoked by uid 509); 28 Jan 2006 01:32:10 +0900 Date: 28 Jan 2006 01:32:10 +0900 Message-ID: <20060127163210.9795.qmail@mail.gsagh.com> From: info@gsagh.com To: capwap-archive@ietf.org Subject: $B$*$a$G$H$&(B(~o~) X-Spam-Score: 4.6 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 $B$*$a$G$H$&$4$6$$$^$9!"C4Ev$N>.I49g$G$9(B(^^$B"v!#(B $B$3$N$?$S!"$"$J$?$O40A4L5NA$G%"%I8r498"Mx$r3MF@$5$l$?$N$GO"Mm$7$^$7$?!#(B $B$*L>A0$N:G8e$K!V!w!W$rIU$1$F$$$?$@$1$l$P!"EvHVAHA4$F$N=w@-%"%I$r<+M3$K$4MxMQ$J$I$$$?$@$1$^$9"v(B $B:#$J$i!"K\F|EPO?$7$?$P$+$j$N=w@-$+$iD>%aJV?.$5$l$^$9$h!y(B $B=w$N;R$N$_$G@=:n$7$?3Z$7$$%5%$%H$G$9(B(^-^) http://www.livedear3.com?num=1515 $B$^$:$O$*;n$7463P$G$I$&$>(Bp(^^)q $B5qH]$O(B $B!J(BPlease inform the following address if this mail is unnecessary.$B!K(B cancel@livedear.com From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jan 28 04:46:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2mf0-0005Ah-Hd for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 04:46:22 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09763 for ; Sat, 28 Jan 2006 04:44:48 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 3411C430075 for ; Sat, 28 Jan 2006 01:46:20 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id C408543006B for ; Sat, 28 Jan 2006 01:45:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ABDB780C181 for ; Sat, 28 Jan 2006 01:45:56 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id D206A80C183 for ; Sat, 28 Jan 2006 01:45:54 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS00KCHQYVCQ@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 01:42:31 -0800 (PST) Received: from huawei.com ([172.17.1.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS00EPNQYT4R@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 01:42:31 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Sat, 28 Jan 2006 14:45:49 +0500 Date: Sat, 28 Jan 2006 14:45:49 +0500 From: zhaoyujin 31390 To: "Pat Calhoun (pacalhou)" Message-id: <76dedb772428.77242876dedb@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com Subject: [Capwap] Re:RE: About BSS number "Issue 50" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT Yes. I think current protocol definition is sufficient for product. Best regards Michael > So you are stating that the current text is sufficient, right? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > Sent: Thursday, January 26, 2006 11:37 PM > > To: Pat Calhoun (pacalhou) > > Cc: capwap@frascone.com > > Subject: About BSS number "Issue 50" > > > > Issue50 (wish): > > > Page 34, Section 5.1.3. LWAPP seems to assume that WLAN radios > will > > > support > > > 16 BSS's per Radio. It would be better not assume that every > WTP > > > supports 16 radios and add a field to indicate the number > > of virtual > > > networks per radio. > > At one point, the sheer number of beacons will saturate the > > air waves, so we need to pick a maximum. What number do we want? > > > > > > > > Hi: > > > > Sorry, I can not get the information. > > > > "3.1.2 RID Field" defines LWAPP supports 8 radios. I think > > this performance is enough. If AP supports "every WTP > > supports 16 radios", the AP should has 16 wireless chipset, > > and it will be too expensive. So that AP supports virtual > > multiple wireless networks on same radio. > > > > And there is no limitation about how many BSS are supported > > by one radio, because "3.1.8 Status and WLANS" defines > > 16-bits "WLAN ID". The product can define corresponding BSS > > number per radio based on product performance. > > > > So I think that current definition for "radio and WLAN" is enough. > > > > Best regard > > Michael > > > > > > > _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jan 28 05:09:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2n17-0004t1-Bk for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 05:09:13 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10744 for ; Sat, 28 Jan 2006 05:07:39 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 119914300AB for ; Sat, 28 Jan 2006 02:09:12 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id 9DBB143006B for ; Sat, 28 Jan 2006 02:08:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 30A2539801F for ; Sat, 28 Jan 2006 02:08:39 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by zoidberg.tigertech.net (Postfix) with ESMTP id E8A7E39803E for ; Sat, 28 Jan 2006 02:08:34 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS00KVXS0RCQ@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 02:05:15 -0800 (PST) Received: from huawei.com ([172.17.1.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS00EVDS0Q4R@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 02:05:15 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Sat, 28 Jan 2006 15:08:33 +0500 Date: Sat, 28 Jan 2006 15:08:33 +0500 From: zhaoyujin 31390 Subject: Re:RE: [Capwap] About "IEEE 802.11 Binding" To: "Pat Calhoun (pacalhou)" Message-id: <7707c876e747.76e7477707c8@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT Because deifferent product has different process mechanism, LWAPP need give clear description about process. I suggest: >11.8.2 IEEE 802.11 WLAN Config Response > > The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the > AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN > Configuration Request. > This LWAPP control message does not include any message elements. change to: 11.8.2 IEEE 802.11 WLAN Config Response The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN Configuration Request. Before this LWAPP control message is sent, the IEEE 802.11 WLAN Cofiguration should be successfully implemented. This LWAPP control message does not include any message elements. >9.2 Mobile Config Response > > The Mobile Configuration Response is used to acknowledge a previously > received Mobile Configuration Request, and includes a Result Code > message element which indicates whether an error occured on the WTP. > > This message requires no special processing, and is only used to > acknowledge the Mobile Configuration Request. > > The data transfer request message MUST contain the message elements > described in the next subsection. change to: 9.2 Mobile Config Response The Mobile Configuration Response is used to acknowledge a previously received Mobile Configuration Request, and includes a Result Code message element which indicates whether an error occured on the WTP. Before this message is sent, the Mobile Cofiguration should be implemented. The Result Code indicate if Mobile Cofiguration is successfully on WTP. This message requires no special processing, and is only used to acknowledge the Mobile Configuration Request. The data transfer request message MUST contain the message elements described in the next subsection. And if "IEEE 802.11 WLAN Configuration Response" also has a Result Code message element as "Mobile Config Response", 802.11 protocol may be better to control WLAN configuration. Best regards Michael > They do have to be processed prior to responding. What would you > like to > see changed to make this clearer? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > -----Original Message----- > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > Sent: Thursday, January 26, 2006 9:47 PM > > To: capwap@frascone.com > > Subject: [Capwap] About "IEEE 802.11 Binding" > > > > Hi all: > > > > I have a doubt about AP configuration. > > > > All WLAN configurations are on AC. When LWAPP transmits > > WLAN configuration using "11.8.1.1 IEEE 802.11 Add WLAN". > > > > But on AP device, configuration process may be > > asynchronous. This means AP responses the "11.8.1.1 IEEE > > 802.11 Add WLAN" message before finishing configuration > > process. If configuration is fail (For example memory is not > > enough), how to notify AC about this error. > > > > Can LWAPP defines notification message for "11. IEEE > > 802.11 Binding". Or LWAPP appends mention that all "11. IEEE > > 802.11 Binding" message should firstly be processed before AP > > sends corresponding response. > > > > Best regards > > Michael > > > > _________________________________________________________________ > > 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jan 28 05:25:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2nGo-0002dg-Tr for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 05:25:27 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11505 for ; Sat, 28 Jan 2006 05:23:53 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 9AC774300DF for ; Sat, 28 Jan 2006 02:25:25 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id E781243006B for ; Sat, 28 Jan 2006 02:25:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ADF7280C190 for ; Sat, 28 Jan 2006 02:25:01 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id D393A80C18B for ; Sat, 28 Jan 2006 02:24:59 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS00KD9SSBCQ@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 02:21:47 -0800 (PST) Received: from huawei.com ([172.17.1.101]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITS0073RSSABN@usaga01-in.huawei.com> for capwap@frascone.com; Sat, 28 Jan 2006 02:21:47 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Sat, 28 Jan 2006 15:25:05 +0500 Date: Sat, 28 Jan 2006 15:25:05 +0500 From: zhaoyujin 31390 Subject: Re:RE: [Capwap] lwapp-dtls edits "LWAPP need support "NULL-Authentication" and "NLL-Encryption" feature" To: "Nelson, David" Message-id: <770e5d7717b9.7717b9770e5d@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT LWAPP need support "NULL-Authentication" and "NLL-Encryption" feature. We have discussed many security issues. But factly many "fit AP"scenarioes may be interior of one company. The company current wired network does not need secruity. In "5.2.2 AC Descriptor" only defines two type authentication, this will limit user's application and increase user cost. Fit AP should support to get "shared-key" or "Certificate ". > Security: A 8 bit bit mask specifying the security schemes supported > by the AC. The following values are supported (see Section 10): > > 1 - X.509 Certificate Based > > 2 - Pre-Shared Secret Can LWAPP add new Security: 3- NULL-Authentication Best regards Michael > Scott G. Kelly writes... [s.kelly@ix.netcom.com] > > > As for the PSK algorithms, the text currently says plain psk's must > not be > > used due to their vulnerability to dictionary attacks.. Some have > > suggested this is too restrictive, and after thinking it over, I > thinkI > > agree. It seems like allowing plain psk's but adding the standard > > admonishments regarding weak passphrases and dictionary attacks > mightmake > > sense. > > I don't have any problem with PSK methods, using suitable crypto- > suites,key lengths, and key entropy. I would recommend including > one of there. > As you say, the risk is in generating keys from pass-phrases that have > low entropy and are subject to dictionary attack. > > _________________________________________________________________ > 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 From maro@rrader.com Sat Jan 28 09:16:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2qs3-0007f3-Cd for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 09:16:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20886 for ; Sat, 28 Jan 2006 09:14:21 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2r2C-0003kG-KD for capwap-archive@ietf.org; Sat, 28 Jan 2006 09:26:37 -0500 Received: from 218-160-92-206.dynamic.hinet.net ([218.160.92.206] helo=rrader.com) by mx2.foretec.com with smtp (Exim 4.24) id 1F2qrj-0006BH-PT for capwap-archive@ietf.org; Sat, 28 Jan 2006 09:15:48 -0500 Message-ID: <000001c62415$40fd8ef0$15aaa8c0@preoccupation> Reply-To: "Marjolaine Poirrier" From: "Marjolaine Poirrier" To: "Morgane Woolridge" Subject: Re: don P hharamacy Date: Sat, 28 Jan 2006 09:15:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C623EB.582786F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.6 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C623EB.582786F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X h A f N l A s X s=20 V m A d L t I g U s M y $1.2 V u I q A q G f R n A e $3.3 C m I d A b L k I i S c $3.7 http://www.luiselager.com ------=_NextPart_000_0001_01C623EB.582786F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

X h A f N l A s X s = =20
V m =20 A d L = t I g =20 U s M = y $1.2
V u I = q A q G f R n =20 A e $3.3
C m =20 I d A = b L k I i S c = $3.7

http://www.luiselager.com ------=_NextPart_000_0001_01C623EB.582786F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sat Jan 28 10:00:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2rYX-0004YS-Bi for capwap-archive@megatron.ietf.org; Sat, 28 Jan 2006 10:00:01 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23193 for ; Sat, 28 Jan 2006 09:58:27 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id DB8AA430092 for ; Sat, 28 Jan 2006 06:59:56 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id D3DA243004F for ; Sat, 28 Jan 2006 06:59:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C227280C1BB for ; Sat, 28 Jan 2006 06:59:35 -0800 (PST) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by hermes.tigertech.net (Postfix) with ESMTP id 8780D80C1B3 for ; Sat, 28 Jan 2006 06:59:32 -0800 (PST) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc14) with ESMTP id <20060128145931m1400ll9cte>; Sat, 28 Jan 2006 14:59:31 +0000 Message-ID: <43DB86D2.3050406@hyperthought.com> Date: Sat, 28 Jan 2006 06:59:30 -0800 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhaoyujin 31390 Subject: Re: [Capwap] lwapp-dtls edits "LWAPP need support "NULL-Authentication" and "NLL-Encryption" feature" References: <770e5d7717b9.7717b9770e5d@huawei.com> In-Reply-To: <770e5d7717b9.7717b9770e5d@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit zhaoyujin 31390 wrote: > LWAPP need support "NULL-Authentication" and "NLL-Encryption" > feature. > > We have discussed many security issues. > > But factly many "fit AP"scenarioes may be interior of one company. > The company current wired network does not need secruity. I assume you mean "fat AP" - if not, please define "fit AP" (maybe it's one that works out for the customer :-)) > In "5.2.2 AC Descriptor" only defines two type authentication, this > will limit user's application and increase user cost. Fit AP should > support to get "shared-key" or "Certificate ". These are both defined authentication methods, so I'm missing something. Can you re-phrase your request? >> Security: A 8 bit bit mask specifying the security schemes >> supported by the AC. The following values are supported (see >> Section 10): >> >> 1 - X.509 Certificate Based >> >> 2 - Pre-Shared Secret > > > Can LWAPP add new Security: 3- NULL-Authentication Do you mean no security, e.g. TLS_NULL_WITH_NULL_NULL? --Scott _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From pavonadiethel@websolute.it Sun Jan 29 06:37:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Ark-0000BJ-3X for capwap-archive@megatron.ietf.org; Sun, 29 Jan 2006 06:37:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22105 for ; Sun, 29 Jan 2006 06:35:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3AqR-0004Vo-3C for capwap-archive@ietf.org; Sun, 29 Jan 2006 06:35:48 -0500 Received: from bsn-77-20-53.dial-up.dsl.siol.net ([193.77.20.53] helo=websolute.it) by mx2.foretec.com with smtp (Exim 4.24) id 1F3Afb-0006H3-Ka for capwap-archive@ietf.org; Sun, 29 Jan 2006 06:24:35 -0500 Message-ID: <000001c624c6$8370f360$f975a8c0@arose> Reply-To: "Diethelm Pavon" From: "Diethelm Pavon" To: "Angelia Croff" Subject: Re: rest Ph haramacy Date: Sun, 29 Jan 2006 06:24:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6249C.9A9D3550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6249C.9A9D3550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xann f ax Cialli t s Via s ggra Valli a um http://www.asrecedile.com ------=_NextPart_000_0001_01C6249C.9A9D3550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xann f ax

Cialli t s

Via s ggra

Valli a um

http://www.asrecedile.com

------=_NextPart_000_0001_01C6249C.9A9D3550-- From info@mail.rwpu.com Sun Jan 29 09:05:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3DAp-0002bf-QE for capwap-archive@megatron.ietf.org; Sun, 29 Jan 2006 09:05:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29978 for ; Sun, 29 Jan 2006 09:03:23 -0500 (EST) Received: from ip-25-135-66-202.rev.dyxnet.com ([202.66.135.25] helo=mail.rwpu.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3DLL-0000ZK-FH for capwap-archive@ietf.org; Sun, 29 Jan 2006 09:15:55 -0500 Received: (qmail 19518 invoked by uid 509); 29 Jan 2006 22:40:34 +0900 Date: 29 Jan 2006 22:40:34 +0900 Message-ID: <20060129134034.19517.qmail@mail.rwpu.com> From: info@rwpu.com To: capwap-archive@ietf.org Subject: $BFbED$G$9(B X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 $B$*Hh$lMM$G$9!*:#F|=i$a$F;XL>$r$7$F$^$9!#(B $B5U!}(BOK$B$G$9(B(^0_0^)$B!Y(B $B$H$$$&%a%C%;!<%8$,F~$j$^$7$?!#(B $B;XL>$r!"8f=P$G$/$@$5$$!#(B $B8D<<$G?4B!BQ$($J$$J}$*Bg;v$K(B $B5qH]!'(Bbadluck@arigatouo.net From timmons@fas.pgr.bms.com Sun Jan 29 16:45:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3KMU-0002ia-9H; Sun, 29 Jan 2006 16:45:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01911; Sun, 29 Jan 2006 16:43:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3KWv-00055F-S2; Sun, 29 Jan 2006 16:56:20 -0500 Received: from mic92-3-81-56-67-148.fbx.proxad.net ([81.56.67.148]) by mx2.foretec.com with smtp (Exim 4.24) id 1F3KMC-0006ZQ-Cr; Sun, 29 Jan 2006 16:45:12 -0500 Received: from [192.168.1.2] ([81.56.67.148]) by msn.com (Sendmail 8.7.0) with ESMTP (SSL) id IYT61121 for ; Sat, 01 May 2004 01:13:31 -0600 Message-ID: <672p759d.9794470@msn.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=coach; d=msn.com; b=IfG6DJ4aqtGcatNEquXrbXYkWRPhpzTcyLvP9BSEpmHXiJm6bOjA9PJMba1m1mwp8mKRgqsc9SqiwhjQ; X-Display: Full X-List: buzzy.usenet Date: Sat, 01 May 2004 01:13:31 -0600 From: "Juanita Humphrey" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bounces-ietf@ietf.org Subject: Urgent Notification #92814939062157832 Content-Type: multipart/related; boundary="------------AttPart_74067676==.OLA" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 This is a multi-part message in MIME format. --------------AttPart_74067676==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

, terrestrial see clara or doctoral may chalkline and costume see raymond see babysat try ballet see industrial may whitlock or bedbug the brilliant some sergeant and burroughs Or maybe not

--------------AttPart_74067676==.OLA Content-Type: image/gif; name="memoir.2.gif" Content-ID: <8.0.0.40.0.72374974398090.60848216@homesick.yahoo.com.6> Content-Disposition: inline; filename="memoir.2.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1lsxMBhYGIcxnagd5USoGF5gg5Z5Iiuyfur5UeWbcJxevQXhfZe5QsaZt IWqL+9iCBs6Y3p0nUqE8yYqOl7zJvCzg5prxUFb3vvKdL33ra9/740n1zt0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_74067676==.OLA-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jan 29 17:04:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3KfH-0005wN-Mf for capwap-archive@megatron.ietf.org; Sun, 29 Jan 2006 17:04:56 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03097 for ; Sun, 29 Jan 2006 17:03:16 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 77F624300D4 for ; Sun, 29 Jan 2006 14:04:45 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id BA6A4430054 for ; Sun, 29 Jan 2006 14:04:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id A780E80C0ED for ; Sun, 29 Jan 2006 14:04:15 -0800 (PST) Received: from mail.u4eatech.com (blackhole.u4eatech.com [195.188.241.2]) by hermes.tigertech.net (Postfix) with ESMTP id AC96380C115 for ; Sun, 29 Jan 2006 14:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id D2CD03601C5 for ; Sun, 29 Jan 2006 21:47:59 +0000 (GMT) Received: FROM mail.u4eatech.com ([127.0.0.1]) BY localhost WITH ESMTP ; Sun, 29 Jan 2006 21:47:59 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.u4eatech.com (Postfix) with ESMTP id BFDE43601A8 for ; Sun, 29 Jan 2006 21:47:59 +0000 (GMT) Received: from mail.u4eatech.com ([127.0.0.1]) by localhost (mail.u4eatech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29273-09 for ; Sun, 29 Jan 2006 21:47:58 +0000 (GMT) Received: from blackhole.u4eatech.com (phact.u4eatech.com [172.30.40.160]) by mail.u4eatech.com (Postfix) with ESMTP id 4708D360193 for ; Sun, 29 Jan 2006 21:47:58 +0000 (GMT) Received: from 62.84.168.245 (SquirrelMail authenticated user philipr) by www.u4eatech.com with HTTP; Sun, 29 Jan 2006 22:04:08 -0000 (GMT) Message-ID: <34630.62.84.168.245.1138572248.squirrel@www.u4eatech.com> Date: Sun, 29 Jan 2006 22:04:08 -0000 (GMT) From: Philip.Rakity@u4eatech.com To: capwap@frascone.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at u4eatech.com X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.178 tagged_above=-999 required=7 tests=NO_REAL_NAME Subject: [Capwap] Section 5.2.2 Minor Editioral Comment X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 8bit Page 37 -- Top The items labeled Radio and Max Radios: The supporting text implies these items have nothing to do with Radio's. More descriptive labels: ConfWTP -- Configued WTP MaxWTP -- Max WTP regards, Philip _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Sun Jan 29 23:08:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3QKx-00046o-4L for capwap-archive@megatron.ietf.org; Sun, 29 Jan 2006 23:08:19 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23808 for ; Sun, 29 Jan 2006 23:06:43 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id ADF534300F5 for ; Sun, 29 Jan 2006 20:08:15 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 05F97430054 for ; Sun, 29 Jan 2006 20:07:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EEFA780C123 for ; Sun, 29 Jan 2006 20:07:43 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 0D8DE80C10E for ; Sun, 29 Jan 2006 20:07:41 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW00LFI0MX5G@usaga01-in.huawei.com> for Capwap@frascone.com; Sun, 29 Jan 2006 20:04:09 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW00JCB0MVIQ@usaga01-in.huawei.com> for Capwap@frascone.com; Sun, 29 Jan 2006 20:04:09 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Mon, 30 Jan 2006 09:07:24 +0500 Date: Mon, 30 Jan 2006 09:07:24 +0500 From: zhaoyujin 31390 To: "Pat Calhoun (pacalhou)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: Capwap@frascone.com Subject: [Capwap] Re:RE: RE: RE: About dynamic udpating Bootrom and Image data X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I have checked current issues=2C draft=2C and eval=2E There is no mention about =22bootrom download=22=2E =22Issue40 (Feature resolved)=3A Adapt firmware trigger state machine to = allow transition from Run state=22 resolves that AC can dynamically updat= e AP firmware after AP runs=2E I suggestion=3A LWAPP defines a new massage which is used in running state=2E This mass= age notifies AP to check or download its firmware or bootrom=2E If LWAPP provides this feature=2C user can directly update bootrom softwa= re without take down the AP from the ceiling=2E Best regards Michael =3E Why can=27t the image being downloaded=2C as defined in the LWAPP=2C = =3E also include the bootrom=3F =3E = =3E Pat Calhoun =3E CTO=2C Wireless Networking Business Unit =3E Cisco Systems =3E = =3E = =3E = =3E =3E -----Original Message----- =3E =3E From=3A zhaoyujin 31390 =5Bzhaoyujin=40huawei=2Ecom=5D = =3E =3E Sent=3A Thursday=2C January 26=2C 2006 9=3A23 PM =3E =3E To=3A Pat Calhoun (pacalhou) =3E =3E Subject=3A =BB=D8=B8=B4=3ARE=3A RE=3A About dynamic udpating Boot= rom and Image data =3E =3E = =3E =3E I think this is my comment=2E =3E =3E = =3E =3E Can we provide a method to update the bootrom=2E Many device = =3E =3E supports update the bootrom on-line=2E =3E =3E = =3E =3E Best regards =3E =3E Michael =3E =3E = =3E =3E = =3E =3E = =3E =3E =3E Sorry=2C but I am not sure that I follow=2E Is your comment = =3E =3E that you want = =3E =3E =3E to *also* manage the bootrom=3F =3E =3E =3E = =3E =3E =3E Pat Calhoun =3E =3E =3E CTO=2C Wireless Networking Business Unit Cisco Systems =3E =3E =3E = =3E =3E =3E = =3E =3E =3E = =3E =3E =3E =3E -----Original Message----- =3E =3E =3E =3E From=3A zhaoyujin 31390 =5Bzhaoyujin=40huawei=2Ecom=5D =3E =3E =3E =3E Sent=3A Wednesday=2C January 25=2C 2006 6=3A01 AM =3E =3E =3E =3E To=3A Pat Calhoun (pacalhou) =3E =3E =3E =3E Subject=3A =BB=D8=B8=B4=3ARE=3A About dynamic udpating Bo= otrom and Image data =3E =3E =3E =3E = =3E =3E =3E =3E Hi pat=3A =3E =3E =3E =3E = =3E =3E =3E =3E But current downloading firmware only before AP is run= ning=2E =3E =3E =3E =3E = =3E =3E =3E =3E For some AP=2C if we need update the bootrom of device= =2E = =3E =3E We should = =3E =3E =3E =3E get the bootrom off device and write it=2E This is very = =3E diffcult to = =3E =3E =3E =3E manage=2E =3E =3E =3E =3E = =3E =3E =3E =3E So I think we can provide dynamical downloading firmwa= re = =3E and = =3E =3E =3E =3E bootrom=2E =3E =3E =3E =3E = =3E =3E =3E =3E Best regards =3E =3E =3E =3E Michael =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E =3E =3E The LWAPP protocol already defines a method of downlo= ading =3E =3E =3E =3E firmware on =3E =3E =3E =3E =3E both Split and Local MAC Aps=2E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E Pat Calhoun =3E =3E =3E =3E =3E CTO=2C Wireless Networking Business Unit Cisco System= s =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E =3E -----Original Message----- =3E =3E =3E =3E =3E =3E From=3A zhaoyujin 31390 =5Bzhaoyujin=40huawei=2Ec= om=5D =3E =3E =3E =3E =3E =3E Sent=3A Monday=2C January 23=2C 2006 8=3A56 PM =3E =3E =3E =3E =3E =3E To=3A Pat Calhoun (pacalhou) =3E =3E =3E =3E =3E =3E Cc=3A capwap=40frascone=2Ecom =3E =3E =3E =3E =3E =3E Subject=3A About dynamic udpating Bootrom and Ima= ge data =3E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E =3E Hi=3A =3E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E =3E Both split MAC and local MAC can be called =22F= it AP=22=2E = =3E =3E =3E =3E =3E =3E Presently=2C many =22Fit AP=22 devices don=27t ha= ve other =3E =3E =3E =3E manangement method =3E =3E =3E =3E =3E =3E (For example Console=2C Telnet=2C and so on)=2E =3E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E =3E Can we add two control message elements which a= re used = =3E for = =3E =3E =3E =3E =3E =3E updating Bootrom and Image data=2C when =22Fit AP= =22 is running=2E =3E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E =3E Best regards =3E =3E =3E =3E =3E =3E Michael =3E =3E =3E =3E =3E =3E = =3E =3E =3E =3E =3E = =3E =3E =3E =3E = =3E =3E =3E = =3E =3E = =3E _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 30 00:45:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3RrR-0007dT-Nk for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 00:45:57 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28164 for ; Mon, 30 Jan 2006 00:44:22 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id A7D2B4300ED for ; Sun, 29 Jan 2006 21:45:43 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 26C84430054 for ; Sun, 29 Jan 2006 21:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 16A4280C129 for ; Sun, 29 Jan 2006 21:45:18 -0800 (PST) Received: from mail.future.futsoft.com (mail.future.futsoft.com [202.56.251.200]) by hermes.tigertech.net (Postfix) with ESMTP id 16D9D80C123 for ; Sun, 29 Jan 2006 21:45:14 -0800 (PST) Received: from kailash.future.futsoft.com (unverified [10.203.112.3]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 30 Jan 2006 11:13:36 +0530 Received: from CHEW0269 (sujathav.future.futsoft.com [10.203.113.20]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id k0U5i5Jt032212 for ; Mon, 30 Jan 2006 11:14:06 +0530 From: "sujathav" To: Date: Mon, 30 Jan 2006 11:15:00 +0530 Message-ID: <004b01c62560$4fe08480$1471cb0a@asia.ad.flextronics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] IEEE 802.11 ADd WLAN and Update WLAN X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sujathav@future.futsoft.com List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit Hi, 1. The Update WLAN is available for pushing new configuration to the WTP when there are changes to the WLAN configuration. It allows for change of encryption policy. The issue is that for some cases, when 802.11i is used, a change in encryption policy cannot be fully effected without re-programming the beacons that are to be sent out from the Radio for this WLAN. Don't we need, along with other fields . a place-holder in the WLAN update request for the RSN IE and its length ? The RSN IE changes everytime there is a change in the RSNA configuration for the WLAN (like changing the Group Cipher / Adding more Pairwise Ciphers etc) and can be sent out in the WLAN Update . 2. Isn't it likely for the WTP and AC to support more than one encryption algorithm for the data from the mobile stations ? And the mobile stations can make a choice of the encr algo that they can use. In that case, the Encryption policy defined as part of Update WLAN ( Section 11.8.1.3) and Secn 11.8.1.1 (Add WLAN) should be a bit-map. Thanks Sujatha *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 30 02:23:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3TNh-0003gP-6A for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 02:23:21 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02938 for ; Mon, 30 Jan 2006 02:21:44 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 0A2C44300CC for ; Sun, 29 Jan 2006 23:23:19 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 7577D430054 for ; Sun, 29 Jan 2006 23:22:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6170A80C112 for ; Sun, 29 Jan 2006 23:22:55 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id DEDB780C12D for ; Sun, 29 Jan 2006 23:22:52 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW00LN89O25G@usaga01-in.huawei.com> for Capwap@frascone.com; Sun, 29 Jan 2006 23:19:14 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW00L139O0RG@usaga01-in.huawei.com> for Capwap@frascone.com; Sun, 29 Jan 2006 23:19:13 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Mon, 30 Jan 2006 12:22:28 +0500 Date: Mon, 30 Jan 2006 12:22:28 +0500 From: zhaoyujin 31390 To: Capwap@frascone.com Message-id: <1814b164cb.164cb1814b@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Subject: [Capwap] About "WTP Serial Number" X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT Hi all: I suggestion: In "5.1.2 WTP Descriptor", we add field "WTP Serial Number" as following: 5.1.2 WTP Descriptor The WTP descriptor message element is used by the WTP to communicate it's current hardware/firmware configuration. The value contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Boot Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Encryption Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WTP Serial Number ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 3 for WTP Descriptor Length: 16 Hardware Version: A 32-bit integer representing the WTP's hardware version number Software Version: A 32-bit integer representing the WTP's Firmware version number Boot Version: A 32-bit integer representing the WTP's boot loader's version number Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the RID field) supported by the WTP Radios in use: An 8-bit value representing the number of radios present in the WTP Encryption Capabilities: This 16-bit field is used by the WTP to communicate it's capabilities to the AC. Since most WTPs support link layer encryption, the AC may make use of these services. There are binding dependent encryption capabilites. An WTP that does not have any encryption capabilities would set this field to zero (0). Refer to the specific binding for the specification. WTP Serial Number: 24 byte WTP Serial Number. If LWAPP provides this message, AC can decide if response the AP discovery request. This feature will help for AP management. If there is no this field, only in "7.2 Configure Request" includes "WTP Serial Number". In fact, AC maybe does not exist configuration for this AP. But before check this, LWAPP had negotiated many cotrol packets which wastes system resource. Best regards Michael _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From jaasaeger@telemed.de Mon Jan 30 03:32:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3USM-0003rv-Kr for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 03:32:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05884 for ; Mon, 30 Jan 2006 03:30:29 -0500 (EST) Received: from [82.135.161.18] (helo=telemed.de) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3Uct-0003u0-3W for capwap-archive@ietf.org; Mon, 30 Jan 2006 03:43:10 -0500 From: "Jaak Saeger" To: "Meliora Yule" Message-ID: <000001c62577$95b91af0$56baa8c0@desiccate> Subject: Re: selfcollected Phharamace utical Date: Mon, 30 Jan 2006 03:31:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6254D.ACE312F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6254D.ACE312F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 V=20 C=20 V=20 l=20 l=20 A=20 A=20 A=20 L=20 G=20 L=20 l=20 R=20 l=20 U=20 A=20 S=20 M=20 from =20 from =20 from =20 $=20 $=20 $=20 3=20 3=20 1=20 ,=20 ,=20 ,=20 3=20 7=20 2=20 3=20 5=20 1=20 =20 And many other, Save up to 70% with us - http://www.rookevill.com ------=_NextPart_000_0001_01C6254D.ACE312F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

V
C
V
=

l
=20 l
=20 A

A
A
=20 L

G
L
l
=

R
l
U
=

A
S
M
=

from
=20 from
from

$
$
=20 $

3
=20 3
1

,
,
,

3
7
2

3
5
=20 1

And many other, Save up to 70% with us - http://www.rookevill.com

------=_NextPart_000_0001_01C6254D.ACE312F0-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 30 04:03:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Uwq-000862-96 for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 04:03:44 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07503 for ; Mon, 30 Jan 2006 04:02:07 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 76E534300F0 for ; Mon, 30 Jan 2006 01:03:42 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 93F45430054 for ; Mon, 30 Jan 2006 01:03:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 84BE780C123 for ; Mon, 30 Jan 2006 01:03:17 -0800 (PST) Received: from huawei.com (usaga01-in.huawei.com [12.129.211.51]) by hermes.tigertech.net (Postfix) with ESMTP id 9651380C112 for ; Mon, 30 Jan 2006 01:03:15 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW00FHMEBQ6Y@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 30 Jan 2006 00:59:50 -0800 (PST) Received: from huawei.com ([172.17.1.188]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ITW007CGEBOHI@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 30 Jan 2006 00:59:50 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.18.4.151]) by szxmc01-in.huawei.com (mshttpd); Mon, 30 Jan 2006 14:03:06 +0500 Date: Mon, 30 Jan 2006 14:03:06 +0500 From: zhaoyujin 31390 Subject: Re:[Capwap] IEEE 802.11 ADd WLAN and Update WLAN To: sujathav@future.futsoft.com Message-id: <1b3b91fdb3.1fdb31b3b9@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7BIT I agree you. Presently, one ESS should support multiple encryption method including "Auth Type" and "Encryption Policy" We should try to define as: 0x01 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using standard 104 bit WEP. 0x02 - Clear Text: All packets to/from the mobile station do not require any additional crypto processing by the WTP. 0x04 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using standard 40 bit WEP. 0x08 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using standard 128 bit WEP. 0x10 - Encrypt AES-CCMP 128: All packets to/from the mobile station must be encrypted using 128 bit AES CCMP [7] 0x20 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using TKIP and authenticated using Michael [18] 0x40 - Encrypt CKIP: All packets to/from the mobile station must be encrypted using Cisco TKIP. and same for "auth type" Best regards Michael > > Hi, > > 1. The Update WLAN is available for pushing new configuration to > the WTP > when there are > changes to the WLAN configuration. It allows for change of encryption > policy. > > The issue is that for some cases, when 802.11i is used, a change in > encryption policy cannot be > fully effected without re-programming the beacons that are to be > sent out > from the Radio for this WLAN. > > Don't we need, along with other fields . a place-holder in the > WLAN update > request for the RSN IE and > its length ? The RSN IE changes everytime there is a change in the > RSNAconfiguration for the WLAN > (like changing the Group Cipher / Adding more Pairwise Ciphers > etc) and can > be sent out in the WLAN > Update . > > 2. Isn't it likely for the WTP and AC to support more than one > encryptionalgorithm for the data > from the mobile stations ? And the mobile stations can make a > choice of the > encr algo that > they can use. > > In that case, the Encryption policy defined as part of Update > WLAN ( > Section 11.8.1.3) > and Secn 11.8.1.1 (Add WLAN) should be a bit-map. > > > Thanks > Sujatha > > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > _________________________________________________________________ > 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 From 3masahiro@aberdeen.com Mon Jan 30 05:54:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3WgI-00072K-Aj for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 05:54:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12955 for ; Mon, 30 Jan 2006 05:53:11 -0500 (EST) Received: from c-24-3-213-42.hsd1.oh.comcast.net ([24.3.213.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3Wqy-0007eW-TN for capwap-archive@ietf.org; Mon, 30 Jan 2006 06:05:52 -0500 Message-ID: <7d8801c62581$6b5d8275$605d9a5b@aberdeen.com> From: Michael Smith <3masahiro@aberdeen.com> To: capwap-archive@ietf.org Subject: All horny pills Date: Mon, 30 Jan 2006 09:40:48 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_6A706AB0.D6F72896" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0000_6A706AB0.D6F72896 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_60875898.A24F6CDF" ------=_NextPart_001_0001_60875898.A24F6CDF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra - Cialis - Levitra http://www.powerfulpills.net Only $1.56/pill! Featured: Get several pills of each kind in 1 pack. ________________________________ To be taken out, go here ________________________________ ------=_NextPart_001_0001_60875898.A24F6CDF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Viagra - Cialis - Levitra
http://www.powerfulpills.net

Only $1.56/pill!
Featured: Get several pills of each kind in 1 pack.

________________________________
To be taken out, go here
________________________________

------=_NextPart_001_0001_60875898.A24F6CDF-- ------=_NextPart_000_0000_6A706AB0.D6F72896-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 30 08:08:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Ylr-00047s-8M for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 08:08:45 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20886 for ; Mon, 30 Jan 2006 08:06:51 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 954B84300F7 for ; Mon, 30 Jan 2006 05:08:12 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id C0336430058 for ; Mon, 30 Jan 2006 05:07:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ABD1680C123 for ; Mon, 30 Jan 2006 05:07:43 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by hermes.tigertech.net (Postfix) with ESMTP id B918C80C137 for ; Mon, 30 Jan 2006 05:07:40 -0800 (PST) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc11) with ESMTP id <20060130130739m110015oi7e>; Mon, 30 Jan 2006 13:07:40 +0000 Message-ID: <43DE0F22.1090305@cs.umd.edu> Date: Mon, 30 Jan 2006 08:05:38 -0500 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott G Kelly Subject: Re: [Capwap] lwapp-dtls edits "LWAPP need support "NULL-Authentication" and "NLL-Encryption" feature" References: <770e5d7717b9.7717b9770e5d@huawei.com> <43DB86D2.3050406@hyperthought.com> In-Reply-To: <43DB86D2.3050406@hyperthought.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit >> But factly many "fit AP"scenarioes may be interior of one company. >> The company current wired network does not need secruity. > > > I assume you mean "fat AP" - if not, please define "fit AP" (maybe > it's one that works out for the customer :-)) I think "fit" == "thin". The point of the original post is that security on the wired network is unnecessary in many cases. The whole point of most wireless installation is to provide access to the wired network. Thus if you have to run MitM/spoofing attacks against wired devices before you can access the wireless ones, then you should be safe due to the apparent paradox. That is, if you have access to the wired network already, why attack the wireless one? Of course, being the security guy it's my job to strongly disagree. Well, I guess it all depends on your threat model. I imagine the so-called "NULL Authentication" would facilitate WTP configuration, but a manufacturer generated cert isn't that much harder, and gives you more security. If DTLS were used, then using the NULL ciphersuite would be a good way to tackle this problem (if there even really is a problem...) [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] Scott G Kelly wrote: > zhaoyujin 31390 wrote: > >> LWAPP need support "NULL-Authentication" and "NLL-Encryption" >> feature. >> >> We have discussed many security issues. >> > >> In "5.2.2 AC Descriptor" only defines two type authentication, this >> will limit user's application and increase user cost. Fit AP should >> support to get "shared-key" or "Certificate ". > > > These are both defined authentication methods, so I'm missing something. > Can you re-phrase your request? > >>> Security: A 8 bit bit mask specifying the security schemes >>> supported by the AC. The following values are supported (see >>> Section 10): >>> >>> 1 - X.509 Certificate Based >>> >>> 2 - Pre-Shared Secret >> >> >> >> Can LWAPP add new Security: 3- NULL-Authentication > > > Do you mean no security, e.g. TLS_NULL_WITH_NULL_NULL? > > --Scott > _________________________________________________________________ > 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 From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Mon Jan 30 08:09:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3YmC-0004Gm-0s for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 08:09:00 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20993 for ; Mon, 30 Jan 2006 08:07:23 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 4F0054300A2 for ; Mon, 30 Jan 2006 05:08:58 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 3AB684300E8 for ; Mon, 30 Jan 2006 05:07:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2C05280C123 for ; Mon, 30 Jan 2006 05:07:57 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by hermes.tigertech.net (Postfix) with ESMTP id 1B77780C12D for ; Mon, 30 Jan 2006 05:07:55 -0800 (PST) Received: from [192.168.0.3] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc13) with ESMTP id <20060130130748m1300nmr7ie>; Mon, 30 Jan 2006 13:07:54 +0000 Message-ID: <43DE0F2B.3010405@cs.umd.edu> Date: Mon, 30 Jan 2006 08:05:47 -0500 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott G Kelly Subject: Re: [Capwap] lwapp-dtls edits "LWAPP need support "NULL-Authentication" and "NLL-Encryption" feature" References: <770e5d7717b9.7717b9770e5d@huawei.com> <43DB86D2.3050406@hyperthought.com> In-Reply-To: <43DB86D2.3050406@hyperthought.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0 tagged_above=-999 required=7 tests= Cc: capwap X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: 7bit >> But factly many "fit AP"scenarioes may be interior of one company. >> The company current wired network does not need secruity. > > > I assume you mean "fat AP" - if not, please define "fit AP" (maybe > it's one that works out for the customer :-)) I think "fit" == "thin". The point of the original post is that security on the wired network is unnecessary in many cases. The whole point of most wireless installation is to provide access to the wired network. Thus if you have to run MitM/spoofing attacks against wired devices before you can access the wireless ones, then you should be safe due to the apparent paradox. That is, if you have access to the wired network already, why attack the wireless one? Of course, being the security guy it's my job to strongly disagree. Well, I guess it all depends on your threat model. I imagine the so-called "NULL Authentication" would facilitate WTP configuration, but a manufacturer generated cert isn't that much harder, and gives you more security. If DTLS were used, then using the NULL ciphersuite would be a good way to tackle this problem (if there even really is a problem...) [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From cxvs@icqmail.com Mon Jan 30 13:04:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3dOK-0002oM-07; Mon, 30 Jan 2006 13:04:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13605; Mon, 30 Jan 2006 13:02:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3dYa-0004TI-Bx; Mon, 30 Jan 2006 13:15:22 -0500 Received: from host11-168.pool8255.interbusiness.it ([82.55.168.11]) by mx2.foretec.com with smtp (Exim 4.24) id 1F3dWA-0000eU-UN; Mon, 30 Jan 2006 13:12:47 -0500 Received: from [192.168.1.6] ([82.55.168.11]) by yahoo.com (Sendmail 8.0.3) with ESMTP (SSL) id IYT22335 for ; Mon, 30 Jan 2006 12:03:26 -0600 Message-ID: <441z658m.4349449@yahoo.com> Date: Mon, 30 Jan 2006 12:03:26 -0600 From: "Amie Doyle" User-Agent: Omni Way Webmail X-Register: 074632 X-User: chrysanthemum MIME-Version: 1.0 To: bofchairs@ietf.org Cc: bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, casandra.boykin@ietf.org, cats@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Ratess approved Content-Type: multipart/related; boundary="------------JavaMail.280716761741" X-Spam-Score: 1.9 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------JavaMail.280716761741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

a salsify and cardiod but cancelled see coddington it ugh it cleanse on bathrobe the ark , greece may anyone it chromosome it's rung or countdown and upturn Or maybe not

--------------JavaMail.280716761741 Content-Type: image/gif; name="solar.6.gif" Content-ID: <4.0.0.38.0.18049777637496.01543987@classify.msn.com.3> Content-Disposition: inline; filename="solar.6.gif" Content-Transfer-Encoding: base64 R0lGODlhGAKlAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlm/2Zm/2Zm ZmYz/zMz/zMzMzMA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAYAqUAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89orUJROigOKrfona7b7/h8FgJpS+ApChIiEmx6 h4iJios0fH6AKIKEhoyVlpeYaY4kB38jCnyUkgCFn6GZqKmqq0ubI52AoQ0SfQCjpQAQEg2z tay/wMHCL7p8xrpwDb6dbLfNngDMw9PU1ayha2uzcBANB98H3baDpGzKJOLW6uvsea4isKQS 8/R9zrm++O37/P1f79E84Spx7x1AfwgTKlQCMN47Ovdmkdi1sKLFiz8aehLUYE6pe506Atg2 BxLGkyhT/6LQCEgQPUP3xr0cMVClzZs4TXxzsZMTpZxAgwpt4W2o0aNIkypdyrSp06dQo0qd SrWq1atYs2pNsobgT1tfy8ixZTLP2Bx0nJTFtHYrjofzStQ0Eu8RjZiHRuWYaxfIuSB1reh1 q2Mwr4GBjySGB03G4ESPhSzmcZDHZCmRCdsIXIjXJ3Kg0nl9RWls6KLRzHWDc2AWaniuWyoT eaI1hDWgAdl+bWs2vLRg5/j+NHz0J0O7IQGX46Y1bY+vZrdUrvwrHTnSo8WGvfq3c+4NSs+G eYqgm1OgwpMY/+m8gu22Vnedw4d3+uambkdyzlqZ/mi6pHWaZjTgIole4rgGSv9jIkgkgi4j OKJLeMiM082C3xTzUzi0mLMLhiYIcpsu5JTSyYjQKEhLQJA4wpGIHoW3YgkOBvQMioYMJEkn u+Qzjkc45kLbjKQ8V46FFP7BoX4vBhhQjwHd5tqDUpYyC5E0hTIhiqx1OGUutCSpn2tX1jIh iGAehossWNK0izcnvrfighAk82GFBMLwl2dHliNIi0ZKQ8p/hYRDyUe4SDNZPIIWaYIrcR05 iqKJFtqYhLWAwk2mdfoBkyeubKLjICGdMEqo9oAG4ThlIYqciZ40ek6pD9L2Z13/VTbjiYx5 +Bk35LBoI2N9GErTMy1ZuQxfRIIygoOj/BmhkXmucKr/IZ7Bogw4rQVLU0fpgcugG4hOxMai GzVWY6/PlviMfY112WIfswA3UqEpbOJIo9KOKmyIpI76jZXK+CrXM+YKe+s3t0LDDLeW/heh j5McazFF7LoSz2ANCaLaK6WsBo5oFuu06ijbgrNutSvAUteBg5BIT6Tr0SvjSJzOjLDF6MIx 2GOBxVTmpzpdauY8EpMoMQkNnxuvQKIE3NaOT3PTkZRXU1suz+nOPM/Aunk9zzPzoKbroWj3 WbHG6aKT80zvlCJ2m2rjPDN0YIrN8gud5dPZ1RQDHM8fFIVEx9YV9/zjZ30tXpOcqRY9L2lO /lY5J2+SE9jgUf9LkNQg29kJ/6vM7px425Iz1pZwkZ5d8pE1hbysz97u+yEcsifMlwkD1Us7 3pXtTVTB69V7b3Un7EJON6gPOxisa2080EEYg1nxe+2OQ8ltgTmiHpUjbR+4MUPS5mDvoANM iPmgQVmktxY/7zTtpc3/LdPf2Apq4AP1z4YrHtOH6oYVpcU5DxoBfMha+sc+vJFkDmERnqnw RJ9Y0YJ21LqXSFzikXM5SX4ExJwh+EA/E5CEg5Iykb46FUCM9eJ4wyJJo5g2tnZ1SSQklInn aNggCw4JF186mAGPJKgKhaNY6jLRNmjlINdV7HoqNNOyRlgIOmkPQLjokEve1UHeic8j7SMW BksiQf8U8EouweJQ2SJRKdrILDRDzGL13NQRNe7uXmFyVw+Rpps3grFHxZJZLewYOELA70rV 41Eed8i4Pc7xgQH0YhxzVDhByms9Ovujgb4mxCf2ySUXBB8d9+ifB71kE2qMJCh3NyqkBZBH HqTHkCJYRhiAowY94UlbcplLM64OHr0Epk6iF8xb5otaxuTEL1sWzB7wspnDjKYyN7PMaLAG HbQpZieF+YJmJjOZtcTKZZwiqBkKziPVDKc6W1aMq/SinSsoxuXWSc8YzOcqbrintdaQznr6 858ADahAB0rQghpUDWHBDw3OIhlaPoGhtrQlLYuzBH0SoZ+FcehBiRDJidn/IDM+AOkTRKqC v7ggMwpyQvB+QNKWMSiehdxoER4Iwxq0tDDww0xOW7BSU+20p0YAKg9umoJxytQKu+rdhdpD GsFlhzv/UWhqwBPBPxGPaeXJjyjeQFFOPJU+otFLcrzandCIIqvauU1kzNqf7pSEF2t5j2ik 2pV8Lk2AaS0KXamT15+YFR4BKssbQHEu/+gVPgMy1bkGu1TjQBA8JpFrVLm6QbT+UxpJrZJI /PW5O1mwSkikxKy8NEcwHsYXbEItaKnUjRf6gUs9TNLvxpGkT3GpTFSCHJAWlFOlkStI8oAr jTx7SfBt0UibENGC2NDGXsXpS2SiCJ3KUgz1kJZU/xrSIJrcFiXgZo9dTdpkbZ90juhmkJ69 SFGw+tW5z72qGb5ooi8oEtaXRlIaJsXvFMGULMFqDlGA+pGspHi/TeQ3d4Y8wQo9OqjaMNBz LtrdgsFnYAPHTH+4w1amfrpeBFqQdgEuge3cGKhNDky0ZnIjEmfZoJiu83KJlFt7efg6wLYP xA8Dx1ykVSshcUscIssQ4EL3Od6kLH+DgBm3mvYKUQY5HN5An4JD+6u6VbmHEI7clEP4p2uB Kspv0PH/dvzTwHXrkkfu1qOQODkRE3hh5BKs7Vp0x3+C8GIzbuQTlXG3GCJRbNapXR/mNmix 9YFtaxmaKfUGM7GBbc2G9P9anRqTmTkTeXc/S58+QGpp1T0sZm+wFKCxuItkbdkUM7ukzPrM 3e5RjMmrpEd/ZsbmV5CINwC9c8U4S+OK+c6AjijcS9XnUVZGENGReGFlYObgtYgqoZQus+c4 51MeunqIra6akJzFC6r90jbN426MdKxqF4Pv2n44DN54xz19LAbcGBUex3zRQtHmFITVq5HH oDFHe7HKYgrEK1nwuhjsYZmmXYFZ/db3rEMTmKnVW5WbGY5lK3fx3EbDNoPzTY6UhqQW/c4f JBAnbrxKKx4ID0unBT6xdHSUOdOrtXZGrtFwZtqDUqTdvb2FYBQ+Kb5KtG8oT4ixAHKki8im Ic7/ozTGU8XKwjcU4NGvSHRpw5BWd8xhJF04p50KUIYY4xEganivwgqEheFm8NU5SSm0U2vl yyY7fwG04h7KfFAgTk1LkFPzrTwGlJ160iI/lzDAd3RCmJyJexUvE7mvcoSzM2E9+ihLvBES EojcICcf367BT9yRLK6NH/9YSk4DfY0RChZNEVmpyj/pK2x7CcbWaMcMwr2QNCN1KPGYuWnP TCS42jBAvRnvNhQfmtOUpvFnAE5gfpv4Jukl8W2JfF/WpvjKxL41le98FkDzmdo/5jDL0vzr H/X8RjEq+tdvlSWx//2EsSj850//+tv//vjPv/73z//+Q5D88scE/KQT//6GSw/1a7XhFRaV TxrFgIKVDW0AgSngH30XUhCRFrx0HEhALrjWZD6xgNkQfkWgGwWod9UAI+hQZ0lAQZ9RgSxA U0rAesOGJ3bULLS2S15jb/XwGZN3AmUigjZQIRUSSQ+Ue0MQayoXbT0oeHInBWfUUUpnDYhn d1PAghd3A1Z4BFukPD5yJYAwJRziNJ4QRCl4I0CSIbAyhqVlSi7oA0aULFQ0dl73A2OjPIfE SU9iJziEKOamBE+IaSq4CrCUh8LRWMHhHbVhWFjlVodogjQ4G8ajE+NxT6dBHqVmKuyRGvVD HoaoDXflMaNDMqAkh8mSKsBnhAVkSnbyKeJyiv/3diZg9RqemFD+ITG2cVep5zNhpiELUhQ0 U4mBYFjKkYmvRQr8wYMe5oqpOHchIoyKNSCJBVVbJVfq0S1M8iZZBYXT4BKDiEe3lmBXCDK0 AE9KQ3a/GDJdM3qYQws76I1rpI6d94080i4ewo6zhzQ+olw5pUjx8hkdEYnM6I/0yIzzCJBW SGt5QyKUNI68M441xCPf+Cig8geA50eRUiao11kyA0YKWTSEQ36p1kPbQ5EcFxYusZENaY9I g3oniTSLZo+hRg+NF5HaOA2CxBgWJBAdFhZfEiAoiILnOGbAIoY8iTHthIJiF5Di2CUTSUm/ hZO4YyIpORdlk4WDSEH/VthRLcRzMXMpM5guGwZyUklDYUlbT6JgE1lCzBgXSImHEwENQogo tvcSJlGVcOmV5BI1YYGHWfiQfrk8a4KOG1ZHM8KNZ3lF6qBIycI+zLWTEkmC3XIoOtmC/DWP IvmYQFJ2KoOOcVWSGmQhmolkjVlUrBcLK2KFPLKHdOZfeikPbxmQWVghAMlJqPgKs5YqY4mZ QxiYchiakZmA8aGG+vFLnAcmh3aXq6mVu9MSfRksNBMXlmmWlcMrf/hD4VgNQaSco3mdrili eNmdV4QMZ4SYr0kseZODSnmFrxQXxrNqM1GbmEMiePQGgSWObvSdUdhFuRcXWPmVwLKa4Bki /6t2NGXTFnGplnjCn3NDi17DlAWqAvbYLYVSn/2Zl5TZBjK4QM65ocvIKzS4In8omQO0DtpJ mUHZkJipiuCZQEpig3uZRqdZKNzynwDTmmBimIE1owHqEwPDX+7pkjLxHAYpdIxJkOw5Pf4J m5PpUx+Cgr0ha7qZLnGYYDnKLQ2pVhQkJ6iIH39QLz+6IkPKgQOJRlg6bM/JoePpoQ4DooXZ P/8FhJWgnKglN6rHF5XDEUFEm3UqlOA5T2xIhdlJB1nopJWTXrUQqFGJAr7TlQy4BrC4RUWG k0Uzp6sYI2Z5mN6ph26SqGhpW/HxhXaaloiZoIOAqMWooiaVlSvSpf9VlA29yEVnOZ6oSSTN 6Sa2Gp1T8qFItGEiaoIkGjuIAphkY5IXFIZJ6VofVENxKS58sUUn+XoyMZTJE6zi2Hpkw6kA Uwja2lt3qVYQmJRTqFBO4loigoZiCCxzyZR2IpaKKmxgWqx+One7uYeUBK2GuY52MpGE+VKw tK3Utab6+qeuha94pKG2Co6IB65ruqtXGClSZQ1QiISa1ISp146sF3ixxpm6R7GOBKSxJhJX Qi0SW7HK4TWbNYcymIQOipC856ITS2eu17KFhCcX25tMupKA2Y6ZOnfPGrLd+bFoWQ/uGrM0 9HspKrPI6JYpKLRaw6HgWIOqaZ6K2VGRUpP/09B8DviBVvqMGyKBpBFmO9FLIQh9OrYMIcg0 AZi12ReBA8hNZoSAy+d8Ovob+mQsdOtvrsq2DiV9Xrt9ZvSt1RGAfptLEgi4X1uCEHQdJNi2 tcERuwSAIMi4ITKA0+e2Ysu40re4Wzu41fdPhRqITjiHOKB+RzFs/mcHJymfvwBRp9u6zKeI rhu7sju7tFu7tnu7uEtQArC7vBsAMRAAAuC7QAC8IhC8L8C7vVsDxOsEAkAABDAAKIC8uyu8 RAC8wku9O4C92LtQbbgDcOoDtiG5zNe9F1UEgltUGrgCBFAAzuu8BQC9LxAABbC9PCAABSAC BSAAACC/9FsC69u+/+sLvzJgv04QwANQAPNrAuwLwO9bBPwLAARcv/crAgSgvzdAVDxgUlEQ WKBrLaLLFW8KBEJVM2qXAs5LAvZrwS3wwEAQwSPAwiZMACicvzPgwkpgv9fbwCVAwyNgvwIc BA9swzngwjz8UR/shn2IBB18UkeshSGcEUmsdkJ1wiRQxM37vNQbAANQwTh8AlqMxcWrxQPg u188ACq8v1u8uxMcvFr8vv07AlQ8Ajz8xWC8v/q7xWNcvBMMwfoLvM0bvMZbvH0MyHVcvM47 yFkMyD8cx3J8xhC8xxB8yCRQxmd8xSo8vXgsx/u7voHcw8Aryc1rxi+8xWAcAJwMvOxrwf+U 7MkDkMfVBlm+OnBkRBrfkVb/8Vdg5VddxTQU6B18MlYR2CEDR4lntTThGxnNkR5+ZVnt8VfK HB3lYazwAcxkIVyIOMtkQUIUdYucCHkswMjya8EB3LwJLL8VvL4JXAL2e84JjMCtHADmLAAH DL/rTM4TnL+mnMoqAM48nMoHvMbsa8br67sRPNCPnL9jnM4AcMLmzM7Ca8BuXMQHbALhrMCO XNEL/b4HLMP76886PM/zTMHO28rsW7yRzL7bu8DknMYGDQAefb/kTAD5/LwdXcEh7dIa/cbR 0iFO0lwhRF67qlu4hQ+6RVtOSkPjlZqmuFxtIE9HAnY4tFoWwlv/kwpcEzKwE6ElPQIizzUn xbAk78LUwcUbPs0Mt+ZaXU0vQDrFXCzPOmzKKkzDE03BCg3HHO3S0FvSFCzAXRzHCIy/fVzX J3DIu3vTXfzIBD3HNEzALZ3CIgDDDK3XeI3YemzKd63DLyzZVezILq2/h13RNF3ZnS0CW0zX wnvYenwCem3Oj73Y6dzFRCzOfN3Od81GoqQPFXao8EMr8fFdFQYy/8MpzqZiAXGKKJY8OQJ5 R9RiwI1XWxpx4hI2ezlISQVf3zUpFnTcDQZpOKPbzCgtzlJxqPLNC+y+tf3Yjh3alD3JRSy8 is3G8IzPEn3Pgf3GcFze/0vRB5zYm/3I/y39yJlNvZGtwhNd2i9M2Y6d2efdyBYNAAa+1+EM z/Gtv5zsv3cNwwDe4IDN4JO83xk+2hEu4TRcxLbNLyT5INJCMoxkY04GJ0KmmS0ARy+jJAxj pslNLHDp4lAmK/uYcRqs4mrjP00dRgpD43FmcYtzG19GcPy6Kq7AJ/tc25ZtyAiMwPrb3oKN 4Rve0VVe5cGr0BFMw1puAuBMxfaMwPzN4PZr5T28x5AtwzDM2As+2Q8u0ilA4hvOyM4rv13O 5vnsxnbe2tgrxFs+2lt+5gkc21ze51fO2YS3OS0aarkQal+RGHwmkwJEaIuGi9qBkDPuaJKk NrNpaEHT45NjEP8UI+R7tmqW1zUNiuSfNunSkHSX3jr01neMDODya8a+O+IqrOVjrtj0G+f0 3dH2Heht/shjHN9pvuE47OEf/ubGnuy5Ttrzi9mFruFt7rt6LtOC3eEGHccYTuiGXu6uvexB vMdi/u3lXuLadiE2g8xJBBHLA3J7K9ZZLagyR1RZJJnzBW0lmzoUlg/Ukza+hi87PUAglXUU MhI3w+SrOFsAhOvnPdEuDNp3jdpyLMClXcTYbryYvb4bPuYWXgITHcewDcmuHegXr9CRLcA0 PdcdHdj//dj2jedULPOT/fHw7MqjLe51Te4eH9cUnvGJru4WzPPt/socF1tOo8Ej6ij/4v1w ZPQ9LNconfZyEdTvbGiU+XA49ynw+rAua6jqsNNAiyM9C4fk2lXcVD84aK8x6bTnEn7Ani3m Fe7YfE6/Hr7r5W73aJzAHr7mIz/Hjk73PS/X5YzmHz7aEVzRNvzRJb33jxzY8Avt+a3ON4/u 5JzDly/4Yu7hKE3ZQD/okMzh5n7Hi3/0G2/tfSz6KlyAKONDUGlIAM9gKJRcRWcl2Z1uVNg9 T8c/N2506aJ5HqJzYj9iPbRABn8kuk/kRRT8nuQH/LYmkff8t32+993lFbz9+WvmVQ7tJh/+ 2f7PbG7tAV3sOA295I7OVd79i56/DRz5dz8C+23Da/6+L+/l/20OAoUoAKVQDKUKFOS6ijEa rGfsAoPsBnIKEAiqHm04erVUyVKyd0MBnCRCQZjbMXESxQugkKgaknFjBQGXxIfuQbIufceQ Lze+jo+5gMNZ3gWIkYntuanwjUlAvL1slWy1lZVAQMAhNqbJDb60LU5WIuoxhl4CNOLNNbY1 ku31Jb6Rdp2FFQJ4lnB6IaLWja3d/gX/BRS9EAsPHSMrrzAPF1khP0tTTxsRFzdnA5xsV1c7 J3eFU2N/j3ubR2WTG4YKH8SfU8tvLu7d49b/xefz788LBlBfwBUDC+JjU29fP4QBDx50KHEi wgA/KGIMRmRekIweP4I818BfyJImT/+iTKlyJcuWLssV8BZMABWZL2/izKlzJ8+ePn8C/WZz mIChQY8iTap0KdOmTp9CjSp1KtWqVq9izap1K9euXr+CDSt2LNmyZs+iTat2Ldu2bt/CjSt3 Lt26du/izat3L9++fv8CDix4MOHChg8jTqx4MePGjh9Djix5MuXKli9jzqx5M+fOnj+DDi16 NOnSpk+jTq16NevWrl/Dji17Nu3atsUaWODAAYMEKxIkMNDFAPAXCXY78K2CuHAVCIq/YG5c OXHg1oELr349+PLt1pt3945dRQIGuxeAF1Z+N4P04ou/h/5nfDD6JaQv181bOTIE5nkjsIJ2 34U3H3fdIYf/noHgxSecfQD4x16ABf524Hz/WQgAfuTxV8J6Dih4X3wavpceawlEEMEDDqT4 gAosmqhhBA4sl+KMNjaHIn8oRtChhz2+kOKPNhLpG49Eppgjkjb6aMCSOGr4QIoOSBnBAurZ SGWKDKjwpJAsPknjH06qKMyUvwFZwgItgvlAjC+2WKWYMi7JpYxzrgCjCmuqCGaa5G3ZpZe+ 6VlCm3LW+CcAhUaXZZU7KgqAkPfJWeWVABy5JKaDvkZmcwZIeSmjNc6ZIn8MlLmpcjz6+KOP k+pY358GoCpmrOfcqoKUdtLZaq+JKjcpMsJimWQwTAK6qrEloOriH81+uut9MyYa/6CTeMKp ZAQMLmuojcNRm+e2zKoYbQR2kjmut28GOqSSr0ag67nAvjBqrrNJ2aGTzo46rZhr8lqCsbGy Kiu8rhocZLyqznMvigHT+WykKIpJ7LELI5PvvH8Q+a7A6sLZ6r5dGHvtCmv6ZnIXhXZLLn/7 otwotnqOrHB2Njq7KMiAQkwxwivAunGi9e58r2wWa5gtuGJKaSK3wJmK5cEMz6comT9/c6+U E66wNckYCygoNUi/gMC8ZEt6brixmp2zc6mebGUXa16psst3/kEz3Mulh3LNpBItHN1zy71v vut24bXCWH9cguJdR8C1zu5FCpvdee/sb+NYIso5crsFnf/cdj+2ZwBx0m4q+nXI3Et2zALu zXGP25mItgqoBvj64lETXHnaK2cOIbX7Wseis5crjeKlwy7cNOwzj9uv8DRe6+nkX2PuYKST uq6ovTN612m4wUivsu2bFun550E/OSSSc2ZKJOuKkm203cd9/vGSUwdT899Ax4tHDDPa5sQV I5Oli0hiQh7icqWf85AugoAz4PVkhrdaVRCA2aOa2H7XhXt9r32u+R/wDhiu87GKR2/i4OYI SDoDIAB1jKNG68C2p0j9DX9gKqCZbPgCPiEnRZLbHIt6AyTlyQ54Q5we3u6DQQZeD4lq2o2U mNYnLYENeXpi0RLNRr0T9kh6ZHP/ntG450MA6C6DLDyaDx/gJjVqTmdDZMADjCQ3ADQrYRpc Y7LkBSlfSW0FqGqV82yGPQ8yj3mfk2EHyXQ4Eqbug0K7HZCQJyQo6s1tmiPTImc1vgZO8m4q M5uKgseiJgVteZsbZOJ29j1AuoaVb1tY+db2SevlipF93KMLOWg9Ps6vQyjS5DAlBjEPno+H xoldyxB5JOUcDnIia5n1Lnc1TKormm+jEapU2bYJKu2X0xqX3VDVzE0562GostM3AZXO2BWT grukDZkUVDCdBcd0pmsiAKqYnSpijUytKuPCHqbPg7JwTe8s3UFXuEbjWUuFF3PAhBJQpY81 dJ97xJyP/2TZQW+lSaDCieEn0ZSme+5LnxadV0obWkEytYdEgWpmIbWornui9JNQAp6bQLXT tD0AAbmJmreCKtPMfY+hCBUfkpbnJ/nZzacKnCf6TERQ971vjYeLX5YC+QJz4myJy3nqlprj pZ2h7WplY2YWiQqhKtnomCZN3zizSickEQpkUk1fPOOGrpIyiqsv+yQpVwhWIsX0rnH9KpKM Gri52hU2z3lQRjWq0fBkSJ/Ruex9OKuhT1V2n5oVkGhD69DRRsc6Yh3OddJj2s0Kw7OdhS1p TTTZDKnHOsNxaW1dKlvtcA21pOUbbSskH+ION7aqNcApV3DbNwG3f0577W2qG60bh1o3u9rd rlPO6t3vgje84h0vectr3vOiN73qXS972+ve98JXvNgFjWnra9/74je/+t0vf/vr3/8COMAC HjCBC5zgA+eXuwpeMIMb7OAHQzjCEp4whSts4R2MmMMa3jCHO+z5rPz4xCIeMYlLbOITozjF Kl4xi1vs4hfDOMYynjGNa2JHOsM4xzreMY414OM5egqIQh4ykYts5CMjOclKXjKTm+zkJ0M5 yogJAQA7 --------------JavaMail.280716761741-- From florasummey@uudam.net Mon Jan 30 13:15:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3dZ7-0004nK-UY for capwap-archive@megatron.ietf.org; Mon, 30 Jan 2006 13:15:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14307 for ; Mon, 30 Jan 2006 13:14:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3dju-0004nJ-LQ for capwap-archive@ietf.org; Mon, 30 Jan 2006 13:27:00 -0500 Received: from 173-125-223-201.adsl.terra.cl ([201.223.125.173] helo=uudam.net) by mx2.foretec.com with smtp (Exim 4.24) id 1F3dhW-0001Ce-Bw for capwap-archive@ietf.org; Mon, 30 Jan 2006 13:24:30 -0500 Message-ID: <000001c625c9$0ed03c60$f1afa8c0@sixty> Reply-To: "Flora Summey" From: "Flora Summey" To: "Ilaria Lau" Subject: Re: chip Ph haramaceutical Date: Mon, 30 Jan 2006 13:14:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6259F.25FA3460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6259F.25FA3460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 V=20 V=20 C=20 A=20 l=20 l=20 L=20 A=20 A=20 l=20 G=20 L=20 U=20 R=20 l=20 M=20 A=20 S=20 from =20 from =20 from =20 $=20 $=20 $=20 1=20 3=20 3=20 ,=20 ,=20 ,=20 2=20 3=20 7=20 1=20 3=20 5=20 =20 And many other. Save up to 60% with http://www.lesderins.com ------=_NextPart_000_0001_01C6259F.25FA3460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

V
V
C

A
=20 l
=20 l

L
A
A

l
=20 G
L

U
=20 R
l
=20

M
=20 A
=20 S

from
from
from

$
=20 $
=20 $

1
3
=20 3

,
,
,

2
=20 3
7

1
3
5
=20

And many other. Save up to 60% with http://www.lesderins.com

------=_NextPart_000_0001_01C6259F.25FA3460-- From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jan 31 18:47:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45DW-00052n-QT for capwap-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:47:22 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11952 for ; Tue, 31 Jan 2006 18:45:45 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id D62944300C5 for ; Tue, 31 Jan 2006 15:47:19 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id D44694300DB for ; Tue, 31 Jan 2006 15:46:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id 89D66398062 for ; Tue, 31 Jan 2006 15:46:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by zoidberg.tigertech.net (Postfix) with ESMTP id 150B9398072 for ; Tue, 31 Jan 2006 15:46:12 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2006 15:46:12 -0800 X-IronPort-AV: i="4.01,242,1136188800"; d="scan'208"; a="398955908:sNHT32369136" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VNkBKT018198; Tue, 31 Jan 2006 15:46:12 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 15:46:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2006 15:46:09 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014F9F40@xmb-sjc-235.amer.cisco.com> Thread-Topic: RE: RE: RE: About dynamic udpating Bootrom and Image data Thread-Index: AcYlUrGFNaohO+3TS3KWJv4zYHvYEQBbcbnw From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" X-OriginalArrivalTime: 31 Jan 2006 23:46:10.0559 (UTC) FILETIME=[8354D8F0:01C626C0] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE Cc: Capwap@frascone.com Subject: [Capwap] RE: RE: RE: RE: About dynamic udpating Bootrom and Image data X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I've reopened issue 40, and added your comments, which need to be = discussed as a group. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com]=20 > Sent: Sunday, January 29, 2006 8:07 PM > To: Pat Calhoun (pacalhou) > Cc: Capwap@frascone.com > Subject: Re:RE: RE: RE: About dynamic udpating Bootrom and Image data >=20 > I have checked current issues, draft, and eval. >=20 > There is no mention about "bootrom download". >=20 > "Issue40 (Feature resolved): Adapt firmware trigger state=20 > machine to allow transition from Run state" resolves that AC=20 > can dynamically update AP firmware after AP runs. >=20 > I suggestion: >=20 > LWAPP defines a new massage which is used in running state.=20 > This massage notifies AP to check or download its firmware or bootrom. >=20 > If LWAPP provides this feature, user can directly update=20 > bootrom software without take down the AP from the ceiling. >=20 > Best regards > Michael >=20 > > Why can't the image being downloaded, as defined in the LWAPP, also=20 > > include the bootrom? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > > Sent: Thursday, January 26, 2006 9:23 PM > > > To: Pat Calhoun (pacalhou) > > > Subject: =BB=D8=B8=B4:RE: RE: About dynamic udpating Bootrom and = Image data > > >=20 > > > I think this is my comment. > > >=20 > > > Can we provide a method to update the bootrom. Many=20 > device supports=20 > > > update the bootrom on-line. > > >=20 > > > Best regards > > > Michael > > >=20 > > >=20 > > >=20 > > > > Sorry, but I am not sure that I follow. Is your comment > > > that you want > > > > to *also* manage the bootrom? > > > >=20 > > > > Pat Calhoun > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > > > > Sent: Wednesday, January 25, 2006 6:01 AM > > > > > To: Pat Calhoun (pacalhou) > > > > > Subject: =BB=D8=B8=B4:RE: About dynamic udpating Bootrom and = Image data > > > > >=20 > > > > > Hi pat: > > > > > =20 > > > > > But current downloading firmware only before AP is running. > > > > >=20 > > > > > For some AP, if we need update the bootrom of device.=20 > > > We should > > > > > get the bootrom off device and write it. This is very > > diffcult to > > > > > manage. > > > > >=20 > > > > > So I think we can provide dynamical downloading firmware > > and > > > > > bootrom. > > > > >=20 > > > > > Best regards > > > > > Michael > > > > >=20 > > > > >=20 > > > > > > The LWAPP protocol already defines a method of downloading > > > > > firmware on > > > > > > both Split and Local MAC Aps. > > > > > >=20 > > > > > > Pat Calhoun > > > > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: zhaoyujin 31390 [zhaoyujin@huawei.com] > > > > > > > Sent: Monday, January 23, 2006 8:56 PM > > > > > > > To: Pat Calhoun (pacalhou) > > > > > > > Cc: capwap@frascone.com > > > > > > > Subject: About dynamic udpating Bootrom and Image data > > > > > > >=20 > > > > > > > Hi: > > > > > > >=20 > > > > > > > Both split MAC and local MAC can be called "Fit AP".=20 > > > > > > > Presently, many "Fit AP" devices don't have other > > > > > manangement method > > > > > > > (For example Console, Telnet, and so on). > > > > > > >=20 > > > > > > > Can we add two control message elements which are used > > for > > > > > > > updating Bootrom and Image data, when "Fit AP" is running. > > > > > > >=20 > > > > > > > Best regards > > > > > > > Michael > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jan 31 18:54:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45KZ-0007po-Ei for capwap-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:54:41 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12631 for ; Tue, 31 Jan 2006 18:52:38 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7F6354300C0 for ; Tue, 31 Jan 2006 15:54:13 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 8BAEE430058 for ; Tue, 31 Jan 2006 15:53:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7B45180C148 for ; Tue, 31 Jan 2006 15:53:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by hermes.tigertech.net (Postfix) with ESMTP id 6277E80C10B for ; Tue, 31 Jan 2006 15:53:47 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2006 15:53:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VNrgKT022572; Tue, 31 Jan 2006 15:53:42 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 15:53:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] IEEE 802.11 ADd WLAN and Update WLAN Date: Tue, 31 Jan 2006 15:53:41 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014F9F50@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] IEEE 802.11 ADd WLAN and Update WLAN Thread-Index: AcYlYGyo+qOiEffiRG+KODPnI4YddwBYISJQ From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 31 Jan 2006 23:53:42.0659 (UTC) FILETIME=[90CDD530:01C626C1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable 1. I've created tracker entry 68. 2. No, but I do believe that some clarifications are required in the text. The presence of a key is either because a shared key system is being used (e.g., WEP), or it is a GTK (Group Transient Key), both of which only allow for a single transform to be used. Issue 69 is created. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: sujathav [mailto:sujathav@future.futsoft.com]=20 > Sent: Sunday, January 29, 2006 9:45 PM > To: capwap@frascone.com > Subject: [Capwap] IEEE 802.11 ADd WLAN and Update WLAN >=20 >=20 > Hi, >=20 > 1. The Update WLAN is available for pushing new =20 > configuration to the WTP when there are changes to the WLAN=20 > configuration. It allows for change of encryption policy. >=20 > The issue is that for some cases, when 802.11i is used, a=20 > change in encryption policy cannot be fully effected without=20 > re-programming the beacons that are to be sent out from the=20 > Radio for this WLAN. >=20 > Don't we need, along with other fields . a place-holder in=20 > the WLAN update request for the RSN IE and its length ? The=20 > RSN IE changes everytime there is a change in the RSNA=20 > configuration for the WLAN (like changing the Group Cipher /=20 > Adding more Pairwise Ciphers etc) and can be sent out in the=20 > WLAN Update . >=20 > 2. Isn't it likely for the WTP and AC to support more than=20 > one encryption algorithm for the data from the mobile=20 > stations ? And the mobile stations can make a choice of the=20 > encr algo that they can use. >=20 > In that case, the Encryption policy defined as part of =20 > Update WLAN ( Section 11.8.1.3) and Secn 11.8.1.1 (Add WLAN)=20 > should be a bit-map. >=20 >=20 > Thanks > Sujatha >=20 >=20 >=20 >=20 > ************************************************************** > ************* > This message is proprietary to Future Software Limited (FSL)=20 > and is intended solely for the use of the individual to whom=20 > it is addressed. It may contain privileged or confidential=20 > information and should not be circulated or used for any=20 > purpose other than for what it is intended. >=20 > If you have received this message in error, please notify the=20 > originator immediately. If you are not the intended=20 > recipient, you are notified that you are strictly prohibited=20 > from using, copying, altering, or disclosing the contents of=20 > this message. > FSL accepts no responsibility for loss or damage arising from=20 > the use of the information transmitted by this email=20 > including damage from virus. > ************************************************************** > ************* >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jan 31 18:55:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45LQ-0007yU-0i for capwap-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:55:34 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12661 for ; Tue, 31 Jan 2006 18:53:47 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id 7DEF94300EE for ; Tue, 31 Jan 2006 15:55:22 -0800 (PST) Received: from zoidberg.tigertech.net (zoidberg.tigertech.net [64.71.157.135]) by leela.tigertech.net (Postfix) with ESMTP id D5C74430058 for ; Tue, 31 Jan 2006 15:54:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zoidberg.tigertech.net (Postfix) with ESMTP id C51A639806A for ; Tue, 31 Jan 2006 15:54:57 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by zoidberg.tigertech.net (Postfix) with ESMTP id 1F510398072 for ; Tue, 31 Jan 2006 15:54:50 -0800 (PST) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2006 15:54:50 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0VNslKX023186; Tue, 31 Jan 2006 15:54:50 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 15:54:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Section 5.2.2 Minor Editioral Comment Date: Tue, 31 Jan 2006 15:54:47 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014F9F54@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Section 5.2.2 Minor Editioral Comment Thread-Index: AcYlIAd1oq6o8qvSR4mMG49AVpm3swBoa0lw From: "Pat Calhoun (pacalhou)" To: , X-OriginalArrivalTime: 31 Jan 2006 23:54:48.0880 (UTC) FILETIME=[B8465B00:01C626C1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable Issue 70. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Philip.Rakity@u4eatech.com [mailto:Philip.Rakity@u4eatech.com]=20 > Sent: Sunday, January 29, 2006 2:04 PM > To: capwap@frascone.com > Subject: [Capwap] Section 5.2.2 Minor Editioral Comment >=20 >=20 > Page 37 -- Top >=20 > The items labeled Radio and Max Radios: The supporting text=20 > implies these items have nothing to do with Radio's. More=20 > descriptive labels: >=20 > ConfWTP -- Configued WTP > MaxWTP -- Max WTP >=20 > regards, >=20 > Philip >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap From capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Tue Jan 31 18:56:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45MT-0008WO-IS for capwap-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:56:37 -0500 Received: from leela.tigertech.net (leela.tigertech.net [64.71.157.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12722 for ; Tue, 31 Jan 2006 18:54:53 -0500 (EST) Received: from leela.tigertech.net (localhost [127.0.0.1]) by leela.tigertech.net (Postfix) with ESMTP id E03344300DF for ; Tue, 31 Jan 2006 15:56:27 -0800 (PST) Received: from hermes.tigertech.net (hermes.tigertech.net [64.71.157.146]) by leela.tigertech.net (Postfix) with ESMTP id 627E5430058 for ; Tue, 31 Jan 2006 15:55:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 54F5380C148 for ; Tue, 31 Jan 2006 15:55:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by hermes.tigertech.net (Postfix) with ESMTP id 28ABD80C14E for ; Tue, 31 Jan 2006 15:55:51 -0800 (PST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 31 Jan 2006 15:55:49 -0800 X-IronPort-AV: i="4.01,242,1136188800"; d="scan'208"; a="1772193304:sNHT32075752" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0VNtmjv020188; Tue, 31 Jan 2006 15:55:48 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 15:55:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] About "WTP Serial Number" Date: Tue, 31 Jan 2006 15:55:46 -0800 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2014F9F57@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] About "WTP Serial Number" Thread-Index: AcYlbhxd8Gj0x7AWSRyPwg62IJTuhwBU7PcA From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 31390" , X-OriginalArrivalTime: 31 Jan 2006 23:55:47.0942 (UTC) FILETIME=[DB7A8060:01C626C1] X-Virus-Scanned: by amavisd-new at tigertech.net X-Spam-Status: No, hits=0.374 tagged_above=-999 required=7 tests=DNS_FROM_RFC_ABUSE X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.1.5 Precedence: list List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: capwap-bounces+capwap-archive=lists.ietf.org@frascone.com Content-Transfer-Encoding: quoted-printable I've created issue 71. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: zhaoyujin 31390 [mailto:zhaoyujin@huawei.com]=20 > Sent: Sunday, January 29, 2006 11:22 PM > To: Capwap@frascone.com > Subject: [Capwap] About "WTP Serial Number" >=20 > Hi all: >=20 > I suggestion: >=20 > In "5.1.2 WTP Descriptor", we add field "WTP Serial=20 > Number" as following: >=20 > 5.1.2 WTP Descriptor >=20 > The WTP descriptor message element is used by the WTP to=20 > communicate > it's current hardware/firmware configuration. The value=20 > contains the > following fields. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hardware Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Software Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Boot Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Radios | Radios in use | Encryption Capabilities | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | WTP Serial Number ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Type: 3 for WTP Descriptor >=20 > Length: 16 >=20 > Hardware Version: A 32-bit integer representing the WTP's hardware > version number >=20 > Software Version: A 32-bit integer representing the WTP's Firmware > version number >=20 > Boot Version: A 32-bit integer representing the WTP's=20 > boot loader's > version number >=20 > Max Radios: An 8-bit value representing the number of=20 > radios (where > each radio is identified via the RID field) supported by the WTP >=20 > Radios in use: An 8-bit value representing the number of radios > present in the WTP >=20 > Encryption Capabilities: This 16-bit field is used by the WTP to > communicate it's capabilities to the AC. Since most=20 > WTPs support > link layer encryption, the AC may make use of these services. > There are binding dependent encryption capabilites. An WTP that > does not have any encryption capabilities would set=20 > this field to > zero (0). Refer to the specific binding for the specification. >=20 > WTP Serial Number: 24 byte WTP Serial Number. >=20 >=20 >=20 > If LWAPP provides this message, AC can decide if response the=20 > AP discovery request. This feature will help for AP management. >=20 > If there is no this field, only in "7.2 Configure Request"=20 > includes "WTP Serial Number". In fact, AC maybe does not=20 > exist configuration for this AP. But before check this, LWAPP=20 > had negotiated many cotrol packets which wastes system resource. >=20 > Best regards > Michael >=20 >=20 > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap >=20 > Archives: http://lists.frascone.com/pipermail/capwap >=20 _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap

Via
Val
Cia

gra
ium
lis

only
only
only

$3
$1
$3

,3
,2
,7

3
1
5

Va

Via

Xa

Cia

liu
gr

na
lis

m

a

x

$
$

$

1.

3.

3.

21
33

75

X z A y N : A # X _ =

V ; I z A n G # R a = A e

V j A n L n I i U =3D = M v

C i I v A s L q I & = S q

X h A f N l A s X s = =20
V m =20 A d L = t I g =20 U s M = y $1.2
V u I = q A q G f R n =20 A e $3.3
C m =20 I d A = b L k I i S c = $3.7

Xann f ax

Cialli t s

Via s ggra

Valli a um

ViaValCia

gra ium lis

onlyonlyonly

$3 $1$3

,3 ,2,7

31 5

Va Via Xa Cia

liugr nalis

m a x

$$ $

1. 3. 3.

2133 75

X z A y N : A # X _ =

V ; I z A n G # R a = A e

V j A n L n I i U =3D = M v

C i I v A s L q I & = S q

X h A f N l A s X s = =20 V m =20 A d L = t I g =20 U s M = y $1.2 V u I = q A q G f R n =20 A e $3.3 C m =20 I d A = b L k I i S c = $3.7

Xann f ax

Cialli t s

Via s ggra

Valli a um

Via
Val
Cia

gra
ium
lis

only
only
only

$3
$1
$3

,3
,2
,7

3
1
5

Va

Via

Xa

Cia

liu
gr

na
lis

m

a

x

$
$

$

1.

3.

3.

21
33

75

X h A f N l A s X s = =20
V m =20 A d L = t I g =20 U s M = y $1.2
V u I = q A q G f R n =20 A e $3.3
C m =20 I d A = b L k I i S c = $3.7